Filtered format breaks with properties of type:page #568
Comments
|
When trying to reproduce it in sandbox, first both did not work at all
Then I figured that if you hit ctrl+F5 (clearing cache in FF) resolves the problem. However, after saving the page it was there again and you have to clear the cache every time. Now both 568 and 246 seem to work, but older veresions of 568 still don't: |
I wonder why we are getting mixed content warnings here. |
|
Please forget my stacktrace. I have the feeling it has more to do with Summary Cards extension. I de-installed this one. Currently, when I use format=table or format=filtered on a test page and add &debug=true, both output the same three warnings and no errors: I also tried to rebuild all data in SMW with no effect. |
Just to make sure. This was not a stack trace from sandbox. If it was we need to create an issue with Summary Cards. |
|
no, it was from my testwiki. More important for me at the moment is this issue.... |
Thanks for confirming.
Cool. Make sure to make the website HTTPS only for best test results.
No objection at all. :) |
|
short update: I did everything described here: https://www.semantic-mediawiki.org/wiki/Help:Repairing_SMW%27s_data#Rebuilding_everything and deactivated every extension except SMW and SRF. Still no luck... |
|
A working filtered list shows this in the sourcode with ?debug=true "srfFilteredConfig": {
"gcja438f1c": {
"query": "[[Kategorie:Expertinnen und Experten]]",
"printrequests": {
"dhyp4unk2a880k4w8gc04c0co": {
"mode": 2,
"label": "",
"outputformat": false,
"type": "_wpg"
},
"72mo4x0s0ps0owo4gcgo8go80": {
"mode": 1,
"label": "Geschlecht",
"outputformat": "-",
"type": "_txt",
"property": "Geschlecht"
},
"d0vm12nhw7scs4sogks48gsw": {
"mode": 1,
"label": "Wirkungsraum",
"outputformat": "-",
"type": "_txt",
"property": "Wirkungsraum"
},
"ajfcz5wlgxs08gg4okc8go8ok": {
"mode": 1,
"label": "Position",
"outputformat": "-",
"type": "_txt",
"property": "Position"
}
},
"views": {
"gcja438aks": {
"type": "table"
}
},As soon as I add one printout of a property of type Page, this is missing in the source code and that's why the blue icon does not stop and no results are displayed. |
|
Any JS errors? |
|
no. |
|
Here are some warning messages that appear: "Laden fehlgeschlagen.." = "Loading failed for the script..." |
|
another hint in yet another installation (bitami mediawiki in AWS): SyntaxError: expected expression, got ';'Projects:6:54 row 6 is row 54 is the end of "client-js" If I remove the only property "Organizer" of the query that is of type page, it works and this error does not show up.
|
|
I looked into this a bit and while I did not find the root cause or fix yet, here are some findings already. The bug
The non-working pages missing
My guess is that something is going wrong with the I doubt this has anything to do with PHP version or browser. I also doubt the issue lies in the client side, so think the JS console stuff posted so far is not relevant at this point. |
|
@krabina I don't know what debug config you have in your LocalSettings.php file. Perhaps no error is shown because it is being hidden by MW. You could try adding the following: error_reporting( -1 );
ini_set( 'display_errors', '1' );
$wgShowSQLErrors = true;
$wgDebugDumpSql = true;
$wgShowDBErrorBacktrace = true;
$wgDebugToolbar = true;
$wgShowDebug = true;
$wgShowExceptionDetails = true;Don't do that on a production wiki though, especially not for a longer period, as this is bad for security. |
|
I narrowed down the problem. It is coming from SMWs This method, for whatever reason, is returning text with messed up enconding. Which then causes the whole
Good chance that this is a server specific issue, with the root cause being some config or database issue. Bit weird the messed up encoding is just showing up here though. |
|
I narrowed down the problem. It is coming from SMWs `getSortKey` method on
`DataItem` and can be avoided with this change
There is nothing wrong with the DB or the DataItem because if the
users decides to generated sortkeyes for entities with an uca
collation [0] (see `$smwgEntityCollation` [1]) then entities will
honor that setting by transferring the key that has been generated via
the collator instance for this representation.
[0] https://en.wikipedia.org/wiki/Unicode_collation_algorithm
[1] https://www.semantic-mediawiki.org/wiki/Help:$smwgEntityCollation
…On 4/10/20, Jeroen De Dauw ***@***.***> wrote:
I narrowed down the problem. It is coming from SMWs `getSortKey` method on
`DataItem` and can be avoided with this change
d061308
This method, for whatever reason, is returning text with messed up
enconding. Which then causes the whole `$config` array to not be output to
the page. Example:
Good chance that this is a server specific issue, with the root cause being
some config or database issue. Bit weird the messed up encoding is just
showing up here though.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#568 (comment)
|
|
hmm. Indeed my settings are as I thought they should be in a German language installation. And indeed, in a wiki where the problem did not show, I did not have these set. After setting them and performing The reverse is also true: if I remove those settings and do a So now the question remains, how to set it up correctly for a German (or other) language installation. I'd like the list of pages get sorted correctly... |
|
MediaWiki sets: |
|
I disagree. I couldn't care less what the German Wikipedia does. In an enterprise Wiki, I need the sorting to be as user-friendly as it can get and since this great option is there, I see it as a great opportunity to have correct sorting in any language. You do realize, that I as Austrian did not set de-AT@collation=phonebook ;-) |
|
btw. at least |
Of course, because UCA (Unicode collation algorithm) represents a sorting string of calculated codepoints that may contain "invalid" characters [0] due to UCA using a larger UTF (most common UTF-8, UTF-16, UTF-32 [1]) encoding set to build a sort string (see the provided link for more information about UCA). In case the JS cannot deal with those character representations, you need to transform the sort string into something that is UTF-8 safe which can be done in PHP via [0] https://stackoverflow.com/questions/1301402/example-invalid-utf8-string |
|
Why is this closed? I interpret the comment of @mwjames that some transformaton needs to be done in JavaScript. Adding smwgEntityCollation to the upgrade key matrix is nice, but does not help, since my settings were not incorrect and I did run both update-scripts after changing the collation. IMO it is still a bug that if you set the collation to UCA (a documented feature) the filtered format cannot handle it correctly. |
|
My bad. I did not realize further discussion had happened and was under the impression the root cause was unsupported config. |
|
SMW 3.1.6 + SRF 3.1.0 Thanks @krabina. I may have the same 'spinning wheel in perpetual motion' problem, although removing properties of type page does not help here. Nothing to see in the console or error reporting messages. |
|
did you check your collation settings? the bug goes away if you don't use UCA collation... |
|
Atm, I can't test this I'm afraid. Uca collation is essential to the website and in the absence of a staging environment, I don't have the luxury position where I can simply switch it on and off. It's not a trivial thing either. |
|
we need to make sure to get this covered by tests |
* Added failing test for #568 (filtered format breaks for UCA collations) * Fix filtered format for UCA collations The sort key provided in the UCA case is not to be interpreted as string but as a byte array. To make it JSON serializable, convert it to hexadecimal representation as intended for sorting. * Removed MW-1.31 from CI matrix (according to #682)
|
I looked into this and was able to reproduce the bug in MW 1.35. Upgrading to the latest dev-master of SRF fixes the issue! |
Setup
Issue
Filtered format show the blue "loading" icon and never finishes if a property of type page is in the query.
Reproducing
Errors
Console shows:
The text was updated successfully, but these errors were encountered: