@Hydriz Sorry to bother you, but can you give me a pointer on what to do next? Does this need to be approved? Or do I submit the patch directly?

yeah! next time something less complicated, then. ;)

oh yes. quite the breaking error ;)

@Yaron_Koren still no good?

@Yaron_Koren done :)

@Yaron_Koren this better?

@Yaron_Koren I uploaded a patch for this suggested new feature. I would be happy, if you could have a look at it.

To specify: the target of #autoedit currently must be inside the content namespaces. The new config setting will adapt this scope.

According to [0] you should be able to use

quick question: could the problem mentioned in T142652 be related to T184837?

Using $wgExtensionFunctions (or the equivalent in extension.json) works. That is because /includes/Setup.php evaluates it in line 840 after the call to MediaWikiServices::resetGlobalInstance( new GlobalVarConfig(), 'quick' ); in line 533.

In T114483#3862147, @jayvdb wrote:

The entire problem space has moved, as Wikimedia now uses Pygments. @Oetterer , are you still using the syntax highlighter that uses GeSHi ?

Oh, my bad. I overlooked the query form part. sry.

Have you thought about using HeaderTabs [0]? Or a collapse template [1]?

https://gerrit.wikimedia.org/r/#/c/345524/ has been merged.

some people (me, for instance :)) do not use a directory below the mediawiki core directory as extensions directory. in my case, for example, i have a symbolic link named "extensions" pointing to a directory "parallel" to the core software directory:

Patch has been submitted to gerrit https://gerrit.wikimedia.org/r/#/c/345104/

Concerning the missing Tab: In your LocalSettings.php, did you account for the name-changes of the configuration settings, as well?

Setting

$wgGroupPermissions['User']['autocreateaccount'] = true;

in LocalSettings.php worked for me. (core 1.27.1, LdapAuth on master)

Hey Yaron

For the 2nd one, I'm still curious to hear what you guys think about my "mass field addition" idea. Oetterer - you wrote, "Some thoughts about your suggested workaround", but then you didn't offer any thoughts, as far as I can tell.

Hi Yaron

The problem in earlier versions was, that if a field had a default value and the user deliberately blanked it, on next edit the default would show up in the form again. If an unsuspecting user did not notice this, values would start to creep in again that were unwanted. Back then, I very welcomed this fix. Unfortunately, we have the known problems now instead.

Darn. I really hoped that refreshing the cache would sufffice.

I created a faulty cargo query and the page was correctly sorted in that tracking category on preview and on save (I "accessed" a non existant table for the test). I did not - however - change my database structure and waited what would happen to that page. Still I'm assuming that on next cache refresh the above code would place it correctly in the tracking category.

While working on an other extension I stumbled over $parser->addTrackingCategory('msg-name-for-tracking-category'); (see MediaWiki Class Reference)

Hey Cindy,

Thanks, now I see the problem. Have to think about a proper handling, myself. All I can say for now is that my suggested change would allow you to alleviate that problem by manually adding an alias CONCAT(Vocabulary_Enumerations._pageName)=Vocabulary_Enumerations._pageName would be indexed by Vocabulary_Enumerations._pageName. But that leaves you to manually adding an alias everytime you suspect running into such a problem. :(

Yeah you are right. The page would have to be put into that category without being saved. Thinking back I got the inspiration from the Scribunto Extension, which uses exactly the mechanic you described. Unfortunate but no deal breaker for using Cargo. :) Thank you very much for your time and effort you are putting into this!

A workaround I used was setting delimiter to a different value in my form's field-definition.

Hmm. I just found out, I have to correct myself.

But compared to the ones I issued here, they are negligible for me.

Sadly I was wrong in that regard.

I tried to suggest a patch via gerrit. Since this is my very first use of gerrit, please feel free to reject it, if I did something wrong or out of turn.

Actually, I have the problems mentioned in https://phabricator.wikimedia.org/T38505 as well. :) But compared to the ones I issued here, they are negligible for me.

Hmm. I remember that there was an issue where purposefully blanked input fields would be (wrongfully) populated with the default values on a later edit.
My problem is that I often make heavy use of the "show on select" mechanics and sometimes I have defaults w/o whom users would have to enter quite some text. Also, adding unviable options like "none" to radiobuttons would in some cases have the user set all of them manually to a value accepted by the form (if not, the form refuses to save). I really hope it's not too much of a challange but:

All works well, thank you very much. Awesome work. You're the best! :)

Sorry, I did not find the time to do the tests yesterday. Just updated (to 3a53480) and ran some tests:

• instance removal seems to work now.
• #auotedit with http://homepages.uni-paderborn.de/oetterer/FormExamples/extension.html seems to work
• #autoedit with http://homepages.uni-paderborn.de/oetterer/FormExamples/class.html still not working

yeah. tedious work. I got the implression, we are dealing with multiple sources.

No, you're right. They should all be the same.

I did test on fd24011d98840c65d8a19b8778b159d0e8b4f00c. git pull claims master is up-to-date.

I ran some tests:

• working: recognition of defaults. on create and edit
• working: creating entities with multi-instance templates
• working: adding instances on edit
• working: removing instances on edit except
• not working: removing the last instance (see below)
• not working: #autoedit still removes all the multi-instance templates when I called it to edit the main template

One more thing: #autoedit on a field on the main template erases all the multi instance templates. :(

You can find two examples here. I only included the <includeonly> part. And not just for the pun. Unfortunately, all the user interface text is german.

Just did an update for the master. Seems to me, there are only Localisation updates...

git pull
[..]
From https://git.wikimedia.org/git/mediawiki/extensions/SemanticForms
   72c7267..4131540  master     -> origin/master
Updating 72c7267..4131540
Fast-forward
 i18n/ca.json | 1 +
 i18n/vi.json | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

can confirm. wikieditor is back online! thank you for fast response and the good work! :)

Just tested with deactivated SFI. Still there:

and unfortunately, my code example does more than expected. it did produce a correct mapping on values from namespace but somehow my next field with values (no from namespace or from category) also got the mapping applied. very strange behaviour. I reverted to the original code and used values from categories instead...

I dug a litte into the code and I might have a suggestion. I admit, it's preliminary, since I can't fathom all the implications. Maybe you can comment.

ah, ok, sorry. thought, this could be used to post feature request. will do, thanks for the advise!