This bug has gotten worse in SMW 1.7, and will now cause the page to fail to display completely. I have made a demo here (login with Demo/test):

http://www.coincompendium.com/w/index.php/Sandbox/Bug_32955

I have also increased this to "critical", since it disrupts the page display now, instead of merely producing erroneous queries.

I also updated the demo to be compatible with the breaking changes in the query format done in 1.7:

http://wikimedia.7.n6.nabble.com/Semantic-Result-Formats-1-7-released-tp2799845p3504612.html

I tested this in SMW 1.7.0.2 and the bug demo still works the same as in 1.7.

I tried to work around this problem with type Text, but it seems text cannot be queried by property:

http://semantic-mediawiki.org/wiki/Help:Type_Text

I also tried type String, but that is limited to only 255 characters. Many URLs are often much longer.

It appears the only workaround is to break up URLs into pieces and query for each piece. That will take a lot of semantic data overhead and substantial amounts of code, and I have decided not to do it.

I will keep thinking to see if I can come up with a workaround until this is fixed. I just tested SMW 1.7.1 Beta/RC1 and discovered this bug has not been fixed in the upcoming release.

It looks like in 1.7.x it is the page layout that is broken. I'm not sure how that happened.

(In reply to comment #4)

I tried to work around this problem with type Text, but it seems text cannot be
queried by property:

http://semantic-mediawiki.org/wiki/Help:Type_Text

I also tried type String, but that is limited to only 255 characters. Many URLs
are often much longer.

This will be an independent problem for you then. The SMW database backend can only store 255 characters for any data value that is not Text or Code. String reports a problem, but URL has the same limitation (and may not report it). This is independent from this bug, but gave me an idea on how to improve the handling of long strings in general; I filed this as bug 34511.

Thanks for catching and reporting that issue for me, I was not aware of it yet.

Is bug 34511 a blocker for this bug? I don't think it is, since this bug is only about one problematic "=" character. But, even if that is fixed, correct behavior won't be reliable until bug 34511 is fixed. And, maybe the implementation details of how bug 34511 is fixed will affect how this one is fixed.

Bug 34511 is not related to this bug. They are completely independent. The bug reported here is related to parsing input of the #ask function; bug 34511 is related to the database API. They should not affect each other at all.

The problem in the given bug is that "=" is a special character in #ask for denoting parameter values. There needs to be some mechanism to prevent SMW mistaking your input for a parameter assignment.

I do not know how and why #ask queries with this behaviour have a negative effect on your page layout, but if they do then this should not be related to the problem with =. Probably similar layout problems occur for all queries, or for all queries that have some error messages. The = bug in turn should occur for all data values that include =, not just for URLs. I will update the title accordingly.

Actually, yes, I have noticed layout problems in other queries. But, I had thought it was a problem with my code, not in SMW. Now that I know that it may be a valid bug in SMW, I'll test the cases I have where I'm experiencing it to see if I can isolate a demo for a bug report.

Once again, thanks for so generously sharing your insights. It is much appreciated, and very helpful for me in my bug testing efforts. I wish everyone were so considerate as you are.

• Bug 36351 has been marked as a duplicate of this bug. ***

Fixed with pull request 640 [1]. Thus closing as RESOLVED FIXED.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/640