Last modified: 2009-12-30 19:48:12 UTC
On my wiki I have pages 'related' to each other so that they appear automatically in an 'Other Pages' section. The in-line query is quite simple and it works for all my pages with one exception. The page name has a '&' character in it and the in-line query fails to find the pages marked with the right smw property. To test I moved the page with the in-line query to remove the '&' and changing the property on a target page and it appeared. In another test, I changed the property on the target page, it also has a '&' in the title, to relate it to another page without the '&' character in the title and it worked as expected. The details: In-line query: {{#ask:[[Relatedpage::{{PAGENAME}}]] [[:+]] |format=ul |default=::''No related pages at this time'' }} I'm running: MW 1.15 SMW 1.4.3 MySQL 5.0.77 (although Special:Version reports 5.0.45) PHP 5.2.5 CentOS Linux 5.4
I tried to reproduce the error but couldn't. I created a page with a & in its name, another page that relates to the "&" page with some property, and I then put the query that you give above on that page: the results were as expected. Could you try to recreate the error on http://sandbox.semantic-mediawiki.org?
I couldn't reproduce it in the sandbox. I'm sure it used to work on my site as well but I think it stopped working after an upgrade of MySQL to version 5.0.77 from 5.0.45. I've rebuilt the semantic data using the admin function and even gone so far as to blow away the semantic tables in the database and rebuild it all from scratch. Nothing clears it up. When I couldn't reproduce it I went back and tried it on my site again. I confirmed that changing just the '&' symbol in the target page name and in the property results to a positive query result but as soon as I put them back in it fails.
This bug might be related to Bug 21926, and the workaround described there might work for you as well. I suspect some change in MediaWiki's escaping behaviour to be the reason for this problem.
Sounds similar but I tried the workaround in Bug 21926 but it didn't work.
