Opened 9 years ago
Closed 9 years ago
#12234 closed defect (fixed)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
Reported by: | anonymous | Owned by: | Ryan J Ollos |
---|---|---|---|
Priority: | normal | Milestone: | 1.0.12 |
Component: | wiki system | Version: | 0.12.3 |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: |
Avoid |
||
API Changes: | |||
Internal Changes: |
Description
Internal Error occurred when I added follow strings in wiki pages.
[[//a ] ]]
Most recent call last:
File "/var/service/python-2.6.6/lib/python2.6/site-packages/trac/wiki/templates/wiki_edit.html", line 136, in <Expression u'wiki_to_html(context(page.resource), page.text)'> ${wiki_to_html(context(page.resource), page.text)} File "/var/service/python-2.6.6/lib/python2.6/site-packages/trac/wiki/formatter.py", line 1501, in format_to_html return HtmlFormatter(env, context, wikidom).generate(escape_newlines) File "/var/service/python-2.6.6/lib/python2.6/site-packages/trac/wiki/formatter.py", line 1456, in generate escape_newlines) File "/var/service/python-2.6.6/lib/python2.6/site-packages/trac/wiki/formatter.py", line 1243, in format result = re.sub(self.wikiparser.rules, self.replace, line) File "/var/service/python-2.6.6/lib/python2.6/re.py", line 151, in sub return _compile(pattern, 0).sub(repl, string, count) File "/var/service/python-2.6.6/lib/python2.6/site-packages/trac/wiki/formatter.py", line 1161, in replace replacement = self.handle_match(fullmatch) File "/var/service/python-2.6.6/lib/python2.6/site-packages/trac/wiki/formatter.py", line 1157, in handle_match return internal_handler(match, fullmatch) File "/var/service/python-2.6.6/lib/python2.6/site-packages/trac/wiki/formatter.py", line 709, in _macrolink_formatter return self._lhref_formatter(match, fullmatch) File "/var/service/python-2.6.6/lib/python2.6/site-packages/trac/wiki/formatter.py", line 540, in _lhref_formatter return self._make_lhref_link(match, fullmatch, rel, ns, target, label) File "/var/service/python-2.6.6/lib/python2.6/site-packages/trac/wiki/formatter.py", line 546, in _make_lhref_link label = ns + ':' + target # use `http://target`
System Information:
- Trac 0.12.3.ja2
- Babel 0.9.5
- Genshi 0.6
- Python 2.6.6 (r266:84292, Mar 1 2011, 20:55:51) [GCC 4.1.2 20080704 (Red Hat 4.1.2-48)]
We create the following patch as a provisional, and have applied it.
-
src/trac/wiki/formatter.py
diff --git a/src/trac/wiki/formatter.py b/src/trac/wiki/formatter.py index 6495550..442b35f 100644
a b class Formatter(object): 542 542 def _make_lhref_link(self, match, fullmatch, rel, ns, target, label): 543 543 if not label: # e.g. `[http://target]` or `[wiki:target]` 544 544 if target: 545 if target.startswith('//'): # for `[http://target]`545 if ns and target.startswith('//'): # for `[http://target]` 546 546 label = ns + ':' + target # use `http://target` 547 547 else: # for `wiki:target` 548 548 label = target.lstrip('/') # use only `target`
Attachments (0)
Change History (8)
comment:1 by , 9 years ago
Milestone: | 1.2 → 1.0.10 |
---|
comment:2 by , 9 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:3 by , 9 years ago
It's a pretty strange edge case. I'm not very familiar with the formatter.py
code though, so maybe someone else could review before I commit.
-
trac/wiki/formatter.py
616 616 def _make_lhref_link(self, match, fullmatch, rel, ns, target, label): 617 617 if not label: # e.g. `[http://target]` or `[wiki:target]` 618 618 if target: 619 if target.startswith('//'): # for `[http://target]`619 if ns and target.startswith('//'): # for `[http://target]` 620 620 label = ns + ':' + target # use `http://target` 621 621 else: # for `wiki:target` 622 622 label = target.lstrip('/') # use only `target` -
trac/wiki/tests/wiki-tests.txt
363 363 [[../parent|See above]] Note: see wikisyntax tests for other parent tests 364 364 [[./sibling|See next]] 365 365 [[...|nothing to see]] [[...]] 366 [[//a ] ]] 366 367 [[//docs|See documentation]] 367 368 [[//images/logo.png|Our logo]] 368 369 [[/]] … … 376 377 <a class="missing wiki" href="/wiki/parent" rel="nofollow">See above?</a> Note: see wikisyntax tests for other parent tests 377 378 <a class="missing wiki" href="/wiki/WikiStart/sibling" rel="nofollow">See next?</a> 378 379 <a class="missing wiki" href="/wiki/..." rel="nofollow">nothing to see?</a> <a class="missing wiki" href="/wiki/..." rel="nofollow">...?</a> 380 <a class="missing wiki" href="/wiki/a%20%5D%20" rel="nofollow">a ] ?</a> 379 381 <a href="/docs">See documentation</a> 380 382 <a href="/images/logo.png">Our logo</a> 381 383 <a href="/">/</a>
follow-up: 7 comment:4 by , 9 years ago
My (possibly wrong) understanding is:
_make_lhref_link
is only used by_lhref_formatter
._lhref_formatter
is the internal_handler for the lhref post-rule.- But
_lhref_formatter
is also used as a fallback by_macrolink_formatter
(the internal handler for the macrolink post-rule) with_creolelink_re
.
- The
lhref
(long-hand reference?) handling is for[...]
links.- Here a
scheme:
(ns
) is required.[WikiStart]
is not valid and not matched by the lhref post-rule.
- Here a
- The macrolink fallback / creole link handling is for
[[...]]
links.- Here a
scheme:
(ns
) is optional.[[WikiStart]]
is valid and matched by_creolelink_re
.
- Here a
In _make_lhref_link
this is ignored. Even the comments there imply [...]
(where ns
is required) is the only handled scenario.
Now how should [[//a ] ]]
be handled? I don't know.
[[a b ]]
links a wiki pagea b
, similar to[[WikiStart]]
.[[/a b ]]
links project-relativeserver/project/a b
, similar to[[/search]]
.[[//a b ]]
links server-relativeserver/a b
, similar to[[//demo-1.1]]
.
But _lhref_relative_target
does not match //a ]
(or /a ]
) as a possible relative target due to the ]
, so:
[[a ] ]]
still links a wiki pagea ]
.[[/a ] ]]
does not link to project-relativeserver/project/a ]
, but instead again links to the wiki pagea ]
. Is that useful?[[//a ] ]]
does not link to server-relativeserver/a ]
. With the proposed fix it would also again link to the wiki pagea ]
. Is that useful?
Maybe _lhref_relative_target
is wrong to reject ]
?
But I think the proposed fix is good in the sense that it is an improvement, and somewhat consistent with already existing fallbacks for other strange links.
The next step IMO would be to mention this in the comments. Last it could be investigated if allowing ]
in relative links is possible, or maybe first if it is useful.
(OT: The documentation on server-relative links are slightly confusing. [/newticket]
is not the same as [[//newticket]]
, e.g. on demo-1.1 [[//newticket]]
points to t.e.o.! [/newticket]
is the same as [[/newticket]]
, and [//newticket]
is the same as [[//newticket]]
.)
comment:5 by , 9 years ago
Milestone: | 1.0.10 → 1.0.11 |
---|
comment:6 by , 9 years ago
Milestone: | 1.0.11 → 1.0.12 |
---|
comment:7 by , 9 years ago
Replying to psuter:
But I think the proposed fix is good in the sense that it is an improvement, and somewhat consistent with already existing fallbacks for other strange links.
Thanks for the detailed look. For now I'll just push the change that prevents the TypeError
. I guess it would be good to sort out the inconsistencies you mentioned, but I can't imagine I'll ever have a need to create a wiki page containing ]
or even [...]
, so I'll wait to see if someone complains before looking further into those issues.
comment:8 by , 9 years ago
Release Notes: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Thanks for the reporting! Reproduced with Trac 0.12.7 and 1.0.9.