correct link: https://installatron.com/mediawiki

This is especially unfortunate in combination with ApprovedRevs:
https://www.mediawiki.org/wiki/Extension_talk:Approved_Revs

Solution for SMW < 4: call PF before SMW
For SMW >4 this it not necessary

Deleted again, checked out REL1_35 instead of 7.2, ran update.php, now it is working.

I deleted the following tables completly:

cs_comments
cs_replies
cs_votes
cs_watchlist

ran update.php. They were then newly created. But still, the error shows up wen trying to add a first test comment.

It is acutally even worse: the error also shows if new comments are added on a page that never had comments before:

I am using WikiEditor REL 1_36 which works in MW 1.35 and already has the patch in.
Still haviing no luck with neither the current PF version nor PF 5.2.1

Maybe the patch does not work in 1.35.5? I have a wiki with 1.35.4 where it is working...

Indeed I did not have this patch in. But after applying this, nothing changes. Still the same messages as above.

Am I the only one with this problem?
Does anybody have the latest PF version working with WikiEditor?

Just checked out PF 5.3.1. Still not working:

tracking this also on github: https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4773

Maybe this helps: it is working inside multiple-instance-templates, but not on regular fields or the free text field

Thank you all for looking into this!

I think this is working now. ED is on 2.4.1

btw I am very confused by this. It did work, but on some wikis this is now broken. From a working wiki, if I copy the PageForms and WikiEditor extension directories to another installation, it still does not work. So it could be related to some other extension or configuration that messes with this. Will try to investigate this further.

I can confirm this. I see this output in the latest PF master version:

for reference, this will be followed up at https://github.com/thaider/Tweeki/issues/223

great, thank you! I added a tipp, because I tried {{FULLPAGENAME}} as an id (which is uniqu in MW) and it worked fine!

I currently see two issues:

Great, this is working perfectly, thank you for the fast fix!

It is not related entirely to SRF, because now I tried deactivating it, resulting in

maybe you want to add SRF to your setup?

yes. I just did the following

Here is a complete stack trace from the first one:

I believe so. Could not try due to https://phabricator.wikimedia.org/T293725

part of it, yes. Uploading in general works now again.
But if you have something like

|default filename={{PAGENAME}}-Logo.jpg

in your uploadable form definition then the suggested name gets passed on the upload dialog (we are talking about $wgPageFormsSimpleUpload = false; here). But as soon as you select a file from your system, the suggested filename gets overwirtten with the filename from the system.
However this filename gets then correctly passed on to the form again, so it is definitely an improvement.

External Data.
I currently don't have the possibility to test this (or go back) on MW 1.35.3

I did checkout master, that's when I ran into the problem. So I had to switch back to REL1_37 becaus it is the version that works.

@Carchaias, can you confirm this?

I don't know where this was fixed, but it seems to be working now in the latest master version.
5.2.1 (865b070) 06:19, 28. Sep. 2021
in MW 1.35.3 and SMW 3.2.3 (5619c2d)

MediaWiki:Smw allows list licenses.json looks like this

Hmm. Does not work for me. If I put values from property=license to a property where this is used, nothing is shown in the autocomplete.

Sorry, I am quite lost here. Is this task now for bundling for MW 1.37 (this was crossed out), so it seems we can discuss here bundling with 1.38? But then why the subtasks that where there when you discussed 1.37? So I guess all of the mentioned above will probably be included in 1.37 if the pass all tests?

Maybe this thread is too old, but as I was redirected here: I think bundling chameleon skin in MW 1.37 (or a later version) would be a good idea since many third party wikis make use of it. https://www.mediawiki.org/wiki/Skin:Chameleon

Is there a chance to bundle the chameleon skin? It is widely used in third-party MW installations: https://www.mediawiki.org/wiki/Skin:Chameleon

after you upload the file and come back to the form the field where the filename should be is still empty

https://wikitech.wikimedia.org/wiki/Tool:Extjsonuploader

It seems this is an issue with 1.35. I have PF 5.2.1 working with 1.31 where the regular upload field is working fine.
Maybe something changed in the MW upload dialog mechanism that PF is using.

oh, sorry. I forgot to tag the extension. Thank you, Aklapper!

In order to have better styling options, CommentStreams could make use of OOUI and/or font awesome icons and OOUI or bootstrap general styling elements (e. g. buttons)

I just realised that the notice only shows on Special:Version, so it's not a big deal...

Thank you, I tried it, but it does not fix the warning. I also tried deactivating other extensions, but without success.

Interesting. Now it is working.

I don't understand the "I don't like Java" argument. Blazegraph - which is in discussion here - is also written in Java als are most (all?) other triplestores or graph databases.

Interesting. From my (limited) experience, neo4j seems to get a lot of attention.

due to the lack of attention for this extension, we funded a rewrite, see
https://github.com/ProfessionalWiki/Network
there are still features lacking so we'd be happy to have some of the VIKI features brought to the network extension

The comination of both is also possible. I did not test this, but certainly using mapping templates together with allows value list will not work.

It is related. T273028 is about the general SMW feature of allowed value list not working (unrelated to mapping templates)
This one is about the mapping templates.

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:
https://www.semantic-mediawiki.org/wiki/Help:List_of_datatypes
e. g.

• 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.

oops, sorry. Yes, it's about Page Forms.

I can confirm that this is working in the current version.

solved it for me, thank you!

I can also confirm this. MW 1.31, PF 4.9.5.

great, thank you! I can confirm that this is working now!

I figured this problem does also not exist in PF 3.6, so it must have started after that.

sorry, this is the correct link:
https://sandbox.semantic-mediawiki.org/wiki/Sp%C3%A9cial:AjouterDonn%C3%A9es/ArticleTest/yyy

https://sandbox.semantic-mediawiki.org/wiki/Sp%C3%A9cial:AjouterDonn%C3%A9es/ArticleTest/yyy
try the test field

no, it also happens when more optiona are available. then the first one gets re-selected

yes, this is looking very good!

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.

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)!
Thank you!