fixed

[ikiwiki.git] / doc / bugs / parsing_for_WikiWords_should_only_be_done_outside_html_tags.mdwn

diff --git a/doc/bugs/parsing_for_WikiWords_should_only_be_done_outside_html_tags.mdwn b/doc/bugs/parsing_for_WikiWords_should_only_be_done_outside_html_tags.mdwn
index 84da4cf6989c93dbc58059b2b410eb74eb504e1f..44938c7547a2942c516c4d5defecf493b470e5ef 100644 (file)
--- a/doc/bugs/parsing_for_WikiWords_should_only_be_done_outside_html_tags.mdwn
+++ b/doc/bugs/parsing_for_WikiWords_should_only_be_done_outside_html_tags.mdwn
@@ -1,3 +1,17 @@
 When having a link to e.g. http://www.chumba.com/media/Chumbawamba-EnoughIsEnough.mp3 inside an anquor tag ikiwiki seems to parse EnoughIsEnough as WikiWord and breaks the link with that.  As a general rule I would suggest that inside tags there should never be any WikiWord parsing, this is just asking for problems.
 
-You can see an example of the breakage on <http://wiki.debian-community.org/planets/de/> - scroll down to the Chumbawamba entry.
\ No newline at end of file
+You can see an example of the breakage on <http://wiki.debian-community.org/planets/de/> - scroll down to the Chumbawamba entry.
+
+>> There's a great workaround for this bug: Disable the
+>> [[plugins/camelcase]] plugin. :-) I really don't recommend using that
+>> plugin. _Especially_ not when aggregating third-party content as you do
+>> in the example.
+>> 
+>> Fixing this at the html parsing level would involve making ikiwiki 2
+>> times slower, not even counting the html parsing overhead, since it
+>> would have to fully render pages in the "scan" pass.
+>>
+>> All I can do is improve the regexp it uses to try to avoid false
+>> positives. Which I've now [[done]].
+>> 
+>> --[[Joey]]