Tue, Feb 20
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.
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
Feb 16 2016
One more thing: #autoedit on a field on the main template erases all the multi instance templates. :(
Feb 15 2016
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.
Feb 14 2016
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(-)
Feb 12 2016
can confirm. wikieditor is back online! thank you for fast response and the good work! :)
Just tested with deactivated SFI. Still there:
Jan 11 2016
Oct 27 2015
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...
Oct 3 2015
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.
Oct 2 2015
ah, ok, sorry. thought, this could be used to post feature request. will do, thanks for the advise!
Sep 29 2015
ok, no problem. My workaround is using a category as well as an individual namespace. that works fine. I just wanted to mention this behaviour.
Sep 28 2015
Sep 23 2015
Aug 24 2015
I would prefer the static label "Seiten" and not the content of MediaWiki:Blanknamespace.
Aug 19 2015
I just tried to rename the namespace. Again, matching pages in namespace User by creating "Projekt:Benutzer" works, with main namespace (after creating "Projekt:Seiten" it doesn't. (I ran jobs and purged the pages in between). And as I understand it, with this in my LocalSetting: "$wgMetaNamespace = "Project";" it should be "Project:Seiten", or am I wrong here? Special:AllPages also uses "Project" as name for the project namespace.