Fri, Mar 22
oh yes. quite the breaking error ;)
@Yaron_Koren still no good?
Thu, Mar 21
Wed, Mar 20
@Yaron_Koren done :)
Feb 13 2019
@Yaron_Koren this better?
Jan 11 2019
Dec 22 2018
@Yaron_Koren is there still a problem with the patch? please let me know...
Nov 23 2018
Oct 12 2018
@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.
Jul 1 2018
Jun 9 2018
May 7 2018
According to  you should be able to use
Mar 13 2018
Mar 6 2018
Feb 20 2018
Jan 16 2018
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.
Jan 13 2018
Jan 12 2018
Jan 11 2018
Aug 3 2017
Aug 2 2017
Jul 28 2017
Apr 18 2017
Oh, my bad. I overlooked the query form part. sry.
Have you thought about using HeaderTabs ? Or a collapse template ?
Mar 30 2017
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:
Mar 28 2017
Patch has been submitted to gerrit https://gerrit.wikimedia.org/r/#/c/345104/
Feb 17 2017
Concerning the missing Tab: In your LocalSettings.php, did you account for the name-changes of the configuration settings, as well?
Nov 10 2016
$wgGroupPermissions['User']['autocreateaccount'] = true;
in LocalSettings.php worked for me. (core 1.27.1, LdapAuth on master)
Sep 7 2016
Sep 2 2016
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.
Sep 1 2016
Aug 31 2016
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.
Jul 19 2016
Darn. I really hoped that refreshing the cache would sufffice.
Jul 13 2016
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)
Jul 1 2016
May 30 2016
May 17 2016
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. :(
May 12 2016
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!
May 8 2016
Apr 26 2016
Apr 8 2016
Mar 7 2016
A workaround I used was setting delimiter to a different value in my form's field-definition.
Mar 3 2016
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.
Feb 29 2016
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:
Feb 28 2016
Feb 22 2016
All works well, thank you very much. Awesome work. You're the best! :)
Feb 21 2016
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
Feb 19 2016
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.