Okay, I was trying to figure out what was causing this when the problem suddenly disappeared!

It is coming from the WikiEditor extension, in ...\extensions\WikiEditor\modules\jquery.wikiEditor.toolbar.less

Okay, I think I found the "problem". Another form on our wiki was working just fine with Wikeditor. The reason was that it was wrapped inside a table with the formtable class.

Hi Yaron, we use Vector legacy but it also happens in the 2022 version of the Vector skin. After some investigation I do see that when Wikieditor is used in a form the "Preview" and "Switch editor" options are not loaded with <div class="group group-default empty" rel="default"></div>. As of there the height: 100%; is "causing" this issue. When you set it to height: 0%; it works.

Hello Yaron, my mistake, we did not have $wgDefaultUserOptions['visualeditor-enable'] = 1; in LocalsSettings.php, we never did but when it is in there it works just fine. Case of reading the manual again after upgrading because things can change, and did back in February. That said, why does VeForAll use this flag, is it not the same or enough if a user enables Visual editor in their preferences? I assume that this is a VisualEditor and not a VeForAll parameter that is now used to enable VeForAll in forms. Logic tells me that if I use VeForAll I have the intention of using it in forms when needed. Why the extra on off switch?

As for the tags, to prevent any unintended linefeeds or white space from appearing on a page or a form I always put wiki code inline in templates and forms, when possible.

To answer your question, with the below two examples there are no offset messages.

Hello @Yaron_Koren, no problem there is no hurry. Just trying to be better prepared for the next LTS version of MW.

That solved the problem, thanks for the fix. For the next MW LTS version we want to be better prepared and check what is working and what is not. Thanks again :-)

This is now fixed, thank you Alexander

@Nikerabbit, thanks for the fix. This also works in MW-1.35.0

Please see: https://www.mediawiki.org/wiki/Topic:Vpc33mge6vajhi3s

I am a little confused. I remembered this problem but back then (in 2018) it seemed to be fixed by adding the following to a form:

A short update for the people interested. After some testing we found out that when using mod_fcgid.so instead of php7apache2_4.dll to handle PHP it works just fine and more important it keeps working fine.

@smkent could you be more specific on your configuration, which linux distro are you using and which version?

Ok, did some digging again. I tested this on:

Hello @Paladox, thanks for your fix. I understand that restarting Apache helps but only for a short while. After x time the same things happens again.

Ok, I have spend some time trying to debug this one and found out that I can reproduce the above error only when Zend OPcache is enabled. The fault pops up after x time.

When you wrote "most wiki's using SF work exactly as you describe", do you mean that most wikis use default values when editing existing pages?

Hello Yaron, a comment:

Jongfeli: I really don't think it's true that default values were added when editing existing pages, in all SF versions before 2.4.1. In any case, as I've said before, it doesn't matter what SF used to do. (I thought you agreed with me on that, but I guess you changed your mind.)

My work with SMWikis would not be possible and the acceptance in my department for such wikis would not be there without Semantic Forms. Therefore, I am immensly grateful, that this powerful extension exists and that Yaron and others spend so much time maintaining and developing it.

Well you are making it very hard for me here :) The saveblank option was merely a suggestion.

Hello Yaron, are there any plans to get the default value fixed for all pages, new and existing like discussed here?

I understand but in my opinion it is the right behavior because that is where the default value is for. However you are right, in your example Bob will be working in the "wrong" department after Charlie edited his page :) Which is probably incorrect. An SMW wiki is as good as the people who build it:

Ok , you are right, the past is the past :)

Yes that is possible but the feature is to be able to alter the parameters in the field tag including the default in a form and that these changes apply to existing and new pages. This feature has always been part of SF before 2.7, you where always able to alter forms anyway you wanted and this also applied to the defaults.

Ok, well initially the blank value will not be replaced by the default when the page is edited. Only when the page is edited again the default will be used because, by that time, the field is not on the page anymore. Any empty field that is stored on the page will disappear anyway when pages are edited with SF 2.7 and higher.

No I don't think so. Fact is that empty fields are not saved on the page anymore since SF 2.7. To me this seems to be the correct behavior.

No, I do not think it is wise to change this empty field behavior back to he way it was years ago. The default values in the field tag used to work just fine on new and existing pages, it is not a new feature I am merely trying to fix it :)

No, the field is not in the page source when it has a blank value. you can test this in the SMW sandbox by entering a value for Defaultvalue1 saving the page and then blanking the value in the next edit.

Yes I did but I think it is the story of the chicken or the egg. If your example page was created with SF without a value for ABC then it is not saved on the page like ABC= (no value). You can not check something that is not there. If you would manually add ABC= (no value) to the page in the template call and the field has a default value in the form then it will be shown in the form as soon as you edit the page with SF. If you then delete the default value again and save the page with no value for ABC it will be deleted from the template call. I must say that we always use parameters with an empty default on its own like: {{{parameter|}}}.

#1. I don't understand. With the patch applied I tried to replicate this but on our wiki the default values used in the form are showing up in the actual form and on the saved page. The patch seems to be working fine. It works with the edit with form tab (for existing pages) or {{#forminput:... for new and existing pages. I tried this on a blank wiki with the following extensions (installed with composer).

Yes you are right but in the past I tried this under windows but did not succeed but now it seems to have worked, I hope :)

It has been fixed with this commit. Thanks Yaron.

No, no Javascript errors. I do see a difference in the HTML code, maybe that can be of help.

@ori yes I am OK with that, no problem. The problem was that the latest version was in the tar download for MW 1.24.1 but that does not seem to be the case anymore.

See: T85794

SyntaxHighlight version from April 2014 works like expected, it has basically no impact on performance. Below that version compared to Master without any caching enabled. It adds +/- 600 ms to loading times.

Added one more test on the same hardware comparing the same setups but with and without SytaxHighlight enabled on an otherwise "empty" wiki (see: sandbox). It is not a specific HHVM "problem", it affects all solutions except XCache with object caching enabled. It seems that the "cause" is javascript that takes a relatively long time to load (see below).

Small update. What triggered me was the fact that HHVM is faster then any other caching solution we used before. We are running our wiki on a windows server so HHVM is not happening at the moment. To compare and build a case to switch to a Linux OS I compared the different solutions to show what an impact it can have. On a clean wiki HHVM is faster then XCache with object caching enabled but when SyntaxHighlight is enabled this changes dramatically. Posted the results from yesterday in my sandbox.

It has not been brought op on the talk page as far as I know. I have access to our production wiki tomorrow and will do the same test and post the result here, when time permits. But when this is really happening it should be relatively easy to reproduce on any "test" wiki. It would be a good thing if somebody else can confirm the same behaviour.