X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/d46688672cf4f6bf5c464e88e564e79b5e606469..ac386bc7b69a8bf946918c0b46533975d249cf97:/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 84da4cf69..44938c754 100644
--- 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 - scroll down to the Chumbawamba entry.
\ No newline at end of file
+You can see an example of the breakage on - 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]]