I was not even aware that this feature exists. However, I agree with @Samwilson comment above. It can be set to true or false by default. Third party users will not care as they can set it according to their needs.
But it should be possible to set it to false to make it simpler for users of smaller wikis who probably don't need this feature.

Sorry for the late reply. You can see an example here
https://www.geschichtewiki.wien.gv.at/index.php?title=W%C3%A4hrungsabk%C3%BCrzungen
The page should not be visible, because there are not approved versions yet:

added a warning to the Extension page. https://www.mediawiki.org/w/index.php?title=Extension:WhosOnline&oldid=7864496

Bug still there in latest version and MW 1.39.

@Kghbln can you give translatewiki committ access to the repo, please?

Slides: https://upload.wikimedia.org/wikipedia/commons/7/7d/Semantic_MediaWiki_-_building_a_knowledge_graph_with_MediaWiki.pdf

There are no deprecations or errors on installting SMW extensions in 1.43, see https://test2.knowledge.wiki/Spezial:Version

It was rescheduled to 11:45 today (Friday)

That is a great idea. There are PHP libraries available and several other CMS do already have plugins: https://webmention.net/implementations/
So a WebMentions extension would be a great benefit for many users!

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