Mon, Oct 12
Why would you think that? I agree that it is not very likely, but if you have a lot of data (imagine a company database, e. g.), you might want to filter for all entries with the same URL or e-mail.
Maybe some can be treated the same in drilldown:
- external identifier, URL and Annotation URI are basically the same (at least for filtering)
- quantity, temperature are probably the same as number
- code, monolingual text, keyword, e-mail and telephone number are the same as text
- reference and record might be trickier if you wanted to be able to have sub-filters for the "has fields" annotations
Correction, my mistake. The patch is working fine. Maybe you can add this for type quantity as well?
While I can confirm that after applying the patch, the error message is gone, the filter in Special:BrowseData remains empty. (Before that the filter worked, but the error message was displayed).
BTW I just realized that the same behaviour shows up not only in properties of type external identifyer, but also in properties of type quantity.
Sep 18 2020
oops, sorry. Yes, it's about Page Forms.
I can confirm that this is working in the current version.
Sep 9 2020
solved it for me, thank you!
I can also confirm this. MW 1.31, PF 4.9.5.
Jun 25 2020
great, thank you! I can confirm that this is working now!
Jun 24 2020
I figured this problem does also not exist in PF 3.6, so it must have started after that.
Jun 19 2020
Jun 8 2020
sorry, this is the correct link:
no, it also happens when more optiona are available. then the first one gets re-selected
May 12 2020
Apr 22 2020
yes, this is looking very good!
Apr 16 2020
It showed a much smaller field, you could not click on it and select existing values (none where shown) or add new values.
What I realized with the initial patch: the tokens input was broken in query forms. So this is something to consider. I moved back to master and token inputs in query forms worked again.
Apr 15 2020
Great, I can confirm that this patch works in my wikis. Now a #forminput call on the same page as as filtered result format are working (before that, the tokens input in the filtered result format was broken if both were present on the same page)!
Apr 14 2020
yes, I can confirm this is working now! Tried it on 2 different wikis.
No. When I switch to master the error is gone, but the voting buttons are not operational.
Apr 13 2020
Thank you for working on this. What I did on a testwiki:
Mar 17 2020
$wgSpecialPageLockdown['CommentStreamsAllComments'] = [ 'cs-comment' ];
works, thank you!
Mar 11 2020
Mar 10 2020
I don't know. I was about to write a bug report when I encounterred this one that seems at least to be very related.
Can you please test ancient dates with this?
Feb 25 2020
Feb 18 2020
any plans to upgrade the select2 library?
Jan 21 2020
No, I don't have a MW 1.32 anywhere. Others seem to have the issue as well:
Dec 10 2019
Tried it on another (test)wiki here: https://testwiki.kdz.eu/CommentStreams
first with version 4.4, then with 4.5. Same result.
Dec 4 2019
Maye this helps:
Release notes 3.1.1 https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/3.1.x/docs/RELEASE-NOTES.md
Release notes 3.1.0 https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/3.1.x/docs/releasenotes/RELEASE-NOTES-3.1.0.md
Dec 2 2019
for documentation purposes.
In External Data 2.0 I was not able to reproduce the error even though using MW 1.31.LTS
thank you. sorry for my poor phabricator knowledge :-)
oops. this is a duplicate of https://phabricator.wikimedia.org/T224292
Nov 25 2019
Oct 4 2019
Indeed, if I switch to REL1_31 the error disappears.
Sep 23 2019
furthermore (probably due to the same reasons) the error message displayed from external data cannot be handled with parser function iferror:
Sep 11 2019
Aug 27 2019
Aug 20 2019
any updates on this?
Maybe a hint on how this could be changed in the source code?
Aug 18 2019
Just for reference, some work in annotating text, images and videos has been done here:
Jul 29 2019
I guess the following problem is related to this:
Jun 3 2019
- I don't have a problem with parser functions even if it breaks changes. If you upgrade your wiki, you know that in advance and can change that accordingly.
May 27 2019
It would be even better to suppoort Font-Awesome icons, especially as they are bundled with twitter boostrap 4 (glyphicons in boostrap 3) and there are a lot of skins supporting twitter bootstrap for MediaWiki.
May 24 2019
Oct 17 2018
Jul 17 2018
Jun 9 2018
Mar 26 2018
Nov 3 2017
no, this doesn't work
i tried to wrap the forminput around <span class="form-control"></span>
Oct 16 2017
Jun 20 2017
Sorry, I wasn't specific enough. I was using SG 1.x.
May 19 2017
Jun 9 2016
just upgraded a wiki where this happended to SF 3.6 and SMW 2.3.1. bug still there.
this removes the page names at least temporarily