https://bugzilla.wikimedia.org/show_bug.cgi?id=25718
--- Comment #9 from Kiran Jonnalagadda <j...@pobox.com> 2010-10-31 11:47:34 UTC --- Thank you, Daniel. This is a great explanation. However, the exact same problem exists without the patch, in MediaWiki's default configuration with ugly URLs. Consider the URLs it would generate for an installation in /wiki: /wiki/index.php?title=Example_page /wiki/index.php?title=Example_page&month=11&year=2010 There is no way to use robots.txt to disallow the second URL without blocking the first. This, therefore, is a problem for the Semantic Result Formats extension to fix. It is not introduced by this patch. As far as I can tell, there is no use case within MediaWiki's default configuration that touches line 824 of Title.php -- there is never a URL that includes a query but not an action parameter (apart from the default 'view' action, which also bypasses line 824). Does MediaWiki come with unit tests to verify this? I'm new to the source. It appears that the patch touches an area of code that is rarely used and hence has been long overlooked. The indexing problem it potentially causes with SRF Calendar already exists without the patch. The patch only makes the function behave consistently. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
