Thank you for the pictures!

Useful documentation for qqq.json can be found here: https://www.mediawiki.org/wiki/API:Localisation#Message_documentation

It was not recorded. See me tomorrow (Sunday) morning in the Las Vegas room (will be gone after lunch).

There is the extension EnhancedUpload that gets rid of this and also other options of VE.

just a side note (because it is only addressing a set of extensions based around SMW), but there is a crowdfunding now for Semantic MediaWiki using Open Collective Europe: https://opencollective.com/smw

Hmm. Strange. Cannot reproduce this bug anymore. Thus closing.

@Pastakhov

Thank you. Everything worked great!

This has been discussed here also: https://www.mediawiki.org/wiki/Topic:Urwm08465wtkzk5c

see also https://www.mediawiki.org/wiki/Topic:Rac8gqq6a6igx7r8
@Kghbln fyi

Step1: Identify current and past members

possibly. I actually don't need either. I was wondering why there is a difference in the insert menu at all and how I could configure which insert options are there.

In the regular one I have
images and media, template, table, comment, gallery, code block, your signature

VisualEditor 0.1.2
MediaWiki 1.35.9

I don't think this is true. If you look at an old version of the page and hit edit (or edit source), the url points to .../w/index.php?title=Wiki_Extensions&action=edit&oldid=624

sure, that's what I did. Just was wondering why embedding it here did now work when it works everywhere else...

Well the use case is that I don't want users to use the Special:Upload, but want them to use e form with additional fields for uploading documents.
As MediaWiki is pointing a lot of things to this special page, it seemed like a good idea to be able to embed (not only link) a form on special:upload.

Actually I think that removing the "edit with form" tab altogether if the user is looking at al old revision of a page is a very good idea!
I understand (and did not think of) the problem that oder revisions might have been done by older forms versions.

I think this should be configurable. While I agree that on public wikis with public comments it is a very useful feature, there is a very valid second use-case: a wiki where the user discussions should only be visible for users of the wiki. There it would be beneficial to not have them in recent changes or via API...

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.