Extension talk:Page Forms

The 2nd template of a form disappeared when editing with form
Hi ! I have created a from with the Special:CreateForm page.

I have added 2 elements in this form :
 * One template (I will call it template 1)
 * Another template (I will call it template 2)

I clicked on "Allow for multiple (or zero) instances of this template in the created page" for the template 2 only and I saved my form.

Then I used the form. Everything works great :
 * I could enter data on template 1 and on template 2
 * I could also add another instance on template 2 and enter data.

I saved and the results page looks great.

But, when I wanted to modify the data, I clicked on "Edit with form" and, at that moment only the form of template 1 was displayed. The form of Template 2 and its instances had disappeared...

Any idea why ? Thanks a lot.


 * If you go back to the form definition page, are both templates still there? Yaron Koren (talk) 23:43, 28 January 2015 (UTC)


 * Hi Yaron, ok I got it : this is because I forgot to create a Category for my form. Another mistake I may also have made : I had also create 3 forms : One for template 1. One for the template 2. And a last one to combine both templates into one. I don't know if that had an impact on my bug. I assume it shouldn't... In my case, I don't need users to fill the 2 first forms separately so I have created 2 templates and call them into a unique form. Thanks a lot for your great and quick support ! I love your Semantic extension. It's awesome.

My pages Special:CreateProperty and Special:CreateClass don't show up...
Hi ! I have installed the extension on a clean new mediawiki website (English Version) but I am facing the following bugs :

Special:CreateProperty and Special:CreateClass doesn't show up ! I get a "No such special page. You have requested an invalid special page."

Moreover, when I am logged in, I get a 500 error on my page Special:Preferences...

However, I think the Semantic Forms Extension is installed correctly since I get the line into my Installed extensions on the Special:Version page.

Any idea why ?

Version :


 * MediaWiki : 1.24.1
 * SF : 3.0
 * PHP Version : 5.4.34

Thanks for your support.


 * My guess is that you don't have the Semantic MediaWiki extension installed. The Special:Preferences thing seems like a separate error, though. Yaron Koren (talk) 14:50, 7 January 2015 (UTC)

multiple instance template not working anymore after version changes. Any idea why ?
My form http://coetus.eu/wiki/Formulaire:SUITE used to work on mediawiki 1.19, including the template multiple :

Yet after I moved to mediawiki 1.23 and to semantic package, the button "Ajouter un tome dans la suite" is not active anymore, i.e. when I clic on it, nothing happens.

To make sure this is not due to my browser, I tried your sample page on http://discoursedb.org/wiki/Special:FormEdit/Item/An_example_item and that one works perfectly i.e. when I click on any of the two "add another" button, I get the expected behaviour i.e. a new series of fields presented.

Do you have the same problem with my form on your side, and do you have any clue on what I may have done wrong ?

Many thanks, and very best wishes for 2015 to you, and to the semantic wiki community.


 * It's great that the form is publicly available - that makes it much easier to debug with the browser JavaScript console. In your case, you have the error message "Unknown dependency: jquery.collapsibleTabs", which is preventing any other JS from running. I don't know what the source of that error is, though - maybe a custom extension? Yaron Koren (talk) 16:43, 5 January 2015 (UTC)
 * jquery.collapsibleTabs (see ) is used in extension Vector (see ). It doesn't compartible with current version of MW and SMW. Just disable it and enjoy! Dmitry Russkih (talk) 12:01, 28 January 2015 (UTC)

Idem by hdurre
I have the same problem : Button 'Add another' doesn't work / no effect. Same message : JS console => "Unknown dependency : jquery" Same version (the latest) : 1.24.1 Do you have workaroud ?


 * What version of Semantic Forms are you using? Yaron Koren (talk) 23:47, 28 January 2015 (UTC)

Multiple instances of RunQuery being turned into UNIQ ... QINU string
My problem seems to be related to some recent problems described here and here. I want to embed two RunQueries on a single pages (e.g., the page's source code looks something like

  

This works fine and dandy if I include just Form1 or Form2, but if I include them both like this, then Form1 doesn't display at all, and instead just shows a UNIQ ... QINU string like "UNIQ639ef22958a33d50-item-0--QINU". Here is some information about my set-up:


 * MediaWiki: 1.24.1
 * PHP: 5.5.7 (cgi-fcgi)
 * MySQL: 5.0.95
 * Semantic MediaWiki: 2.0
 * Semantic Forms: 3.0

My wiki is publicly accessible if you would like me to e-mail you the link so you can see the problem in action. Thanks in advance!

- 70.48.43.161 13:38, 5 January 2015 (UTC)

Field Auto-completion Filtered By Property
I'm trying to provide a combobox, where the auto-completion provides a list of pages in a namespace that contain a particular property, but I can't figure out if this is possible.

Specifically, I'm hoping to provide a dropdown of Machine's from which the user will select a Virtual Host, these Machine's having the Boolean property, Virtual Server, ticked.

I can get the combobox to display all Machines with the followingː

and I can see that there is documentation on values dependent on= but I can't quite join up if it is possible to use this to provide only other Machine's that have the Virtual Server property equal to 1.

Am I able to achieve what I'm after?

- Adam Carrgilson 11:33, 8 January 2015 (UTC)


 * You don't need "values dependent on", you need to replace "values from namespace" with either "values from category" or "values from concept", and then create a category or concept that matches the set of pages you need. "values from concept" would be the better approach - see the documentation for more information on that. Yaron Koren (talk) 15:55, 8 January 2015 (UTC)

transcluded in another page
Embedding a page that is in a sub-category

I tried the following with no effect, B still becomes a member of the category. Is there any way to fix this? If a page (which we'll call Page A) gets transcluded in another page (which we'll call Page B), and Page A belongs to a category that's associated with a form, it can have the unfortunate side effect of making Page B a member of that category as well, thus giving Page B an "edit with form" tab at the top, even if such a tab is not appropriate. You can solve this problem by putting the category declaration in Page A within a "&lt;noinclude&gt;" block, which will make Page A a member of that category but not Page B.


 * Sorry, I don't know. Yaron Koren (talk) 19:43, 8 January 2015 (UTC)

indexing multiple instance templates
I know this has been asked before, but I am just curious if there is any plan to implement this in the future. I attempted to modify the js file and add in the index field, but it does not work. I am not sure if the patch needs to be updated.

--Dgennaro 19:35, 13 January 2015 (UTC)


 * No, unfortunately there's still not a solution, though I do want to implement one. I think it would be cleaner to do via SIO or subobjects than in the form, but... whatever works. I should also note the order is preserved if the data is stored via Cargo, but that's a whole other story. Yaron Koren (talk) 21:49, 13 January 2015 (UTC)


 * I saw that. I plan to look into Cargo when I can come up for air. --Dgennaro 21:58, 13 January 2015 (UTC)

Multiple-instance template not working anymore (SF 2.7 -> SF 3.1)
I seem to be having this problem after upgrading from SF 2.7 to SF 3.1. In addition, the first combobox disappeared from the form view. When I replace all instances of input type=combobox in the form, the multiple-instance templates are working fine again. There's this in the debugging console:

"TypeError: jQuery(...).data(...) is undefined" TypeError: jQuery(...).data(...) is undefined Stacktrace: jQuery.fn.SemanticForms_registerInputInit@[...]extensions/SemanticForms/libs/SemanticForms.js:379:9 @[...]index.php?title=Form:[...]&action=submit:6921:77 handlePending@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10317:10 runScript/markModuleReady@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10457:8 runScript/nestedAddScript@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10464:9 runScript/nestedAddScript/<@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10469:9 addScript/script.onreadystatechange@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10389:9

Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 11:16, 14 January 2015 (UTC)


 * Update: SF 3.0 has other, combobox-related issues but multiple-instance templates are working fine, so that should narrow down the issue to a fairly recent modification. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 11:48, 14 January 2015 (UTC)


 * I assume this is happening on a private wiki. Could you try to replicate this problem on a public wiki, like scratchpad.referata.com? Also, what are the other combobox issues you're seeing? Yaron Koren (talk) 16:57, 14 January 2015 (UTC)


 * Hi Yaron,
 * 1. Using SF 3.0 (on at least one machine) and 3.1 (on another one), two comboboxes in my form were showing stray placeholders. On further investigation, it looked like the stray content probably came from MediaWiki:Sitenotice, where #formlink is used for ready access to a number of forms. SF's switch to the Select2 library probably helps to explain why this is happening now and not in earlier versions of SF.
 * 2. ...which made me wonder if the unresponsive multiple-instance templates (SF 3.1 only) could also be due to something related to the use of #formlink in MediaWiki:Sitenotice. To cut a long story short, it's the use of #formlink in combination with one or more #formlink parameters (I can't be much more specific I'm afraid) that's causing the trouble. It messes up some of the comboboxes, in turn leading to issues with multiple-instance templates.
 * The solution for me was to simplify #formlink, removing some of the unessential parameters, and the issues were gone! Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 14:25, 15 January 2015 (UTC)


 * Oh, great. And it's good to know that there might be an issue with #formlink - I'll have to look into it. Yaron Koren (talk) 22:21, 15 January 2015 (UTC)

Problem with losing session data while submitting form
I've been trying to work with the Semantic Form, but keep getting the "Sorry! We could not process your edit due to a loss of session data." error.

I've upgraded to 3.1 and (thinking there might be some issue with the Cargo additions) went back to 3.0. No dice.

I've updated in test and, thinking this might be a problem with something there, did an upgrade (to SMForms 3.0) in production just now. I'm still getting the "We could not process..." problem.

I tried instrumenting and tracing the code from where  fails and got the following as the first failure:

User::matchEditToken: broken session data 1f054b3425fd476a1bf9e17304d12282+\ != db0cba2825d4b644ba8a1a0cd2948714+\
 * 1) 0 extensions/SemanticForms/specials/SF_UploadWindow.php(98): User->matchEditToken('1f054b3425fd476...')
 * 2) 1 extensions/SemanticForms/specials/SF_UploadWindow.php(24): SFUploadWindow->loadRequest(Object(WebRequest))
 * 3) 2 includes/specialpage/SpecialPageFactory.php(385): SFUploadWindow->__construct
 * 4) 3 extensions/SemanticForms/includes/forminputs/SF_TextInput.php(111): SpecialPageFactory::getPage('UploadWindow')
 * 5) 4 extensions/SemanticForms/includes/forminputs/SF_TextInput.php(231): SFTextInput::uploadableHTML('input_2', NULL, '', 'test-upload3.sv...', Array)
 * 6) 5 extensions/SemanticForms/includes/SF_FormPrinter.php(1881): SFTextInput::getHTML('test-upload3.sv...', 'Unconventional ...', false, false, Array)
 * 7) 6 extensions/SemanticForms/includes/SF_FormPrinter.php(1334): SFFormPrinter->formFieldHTML(Object(SFFormField), 'test-upload3.sv...')
 * 8) 7 [internal function]: SFFormPrinter->formHTML(' \n<...', true, false, 47989, '', 'Sandbox test', NULL)
 * 9) 8 includes/StubObject.php(105): call_user_func_array(Array, Array)
 * 10) 9 includes/StubObject.php(125): StubObject->_call('formHTML', Array)
 * 11) 10 extensions/SemanticForms/includes/SF_AutoeditAPI.php(870): StubObject->__call('formHTML', Array)
 * 12) 11 extensions/SemanticForms/includes/SF_AutoeditAPI.php(870): StubObject->formHTML(' \n<...', true, false, 47989, '', 'Sandbox test', NULL)
 * 13) 12 extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction
 * 14) 13 extensions/SemanticForms/specials/SF_FormEdit.php(92): SFAutoeditAPI->execute
 * 15) 14 extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm('Unconventional_...', 'sandbox test', NULL)
 * 16) 15 includes/specialpage/SpecialPage.php(363): SFFormEdit->execute('Unconventional_...')
 * 17) 16 includes/specialpage/SpecialPageFactory.php(562): SpecialPage->run('Unconventional_...')
 * 18) 17 includes/MediaWiki.php(275): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
 * 19) 18 includes/MediaWiki.php(584): MediaWiki->performRequest
 * 20) 19 includes/MediaWiki.php(435): MediaWiki->main
 * 21) 20 index.php(46): MediaWiki->run
 * 22) 21 {main}SpecialPage::getContext called and $mContext is null. Return RequestContext::getMain; for sanity

Creating a form without any uploads in it (just a simple text entry) resulted in the same problem.

I poked around and saw other people with similar problems, but no clear solution.

Ideas? -- ☠ MarkAHershberger ☢ (talk) ☣ 22:53, 16 January 2015 (UTC)


 * That does sound like a problem with tokens, in some way. What version of MediaWiki are you using? And does this problem happen on a form with an "uploadable" input? And if so, does it also happen on forms without "uploadable? Also, where have you seen similar problems? I don't remember them, but maybe that would shed some light on this issue. Finally, it's not "SMForms", it's just SForms. :) Yaron Koren (talk)÷ 23:08, 16 January 2015‎ (UTC)
 * SForms... got it.
 * It happens on forms without "uploadable", too. I haven't seen similar problems on this wiki, except when you wait too long to submit.  That isn't the issue here.
 * I've instrumented  and   in the following way:

""
 * And, to demonstrate that this isn't a problem with uploadable, I've created the following simple form (this is copied from another form, since I haven't really dealt with forms before):




 * Submitting this form ends up with the following in the debug log:

*** getEditToken w/o request *** getEditToken before user check *** getEditToken token: MWCryptRand::realGenerate: Generating cryptographic random bytes for User::getEditToken/MWCryptRand::generateHex/MWCryptRand::realGenerateHex/MWCryptRand::generate/MWCryptRand::realGenerate MWCryptRand::realGenerate: openssl_random_pseudo_bytes generated 16 bytes of strong randomness. MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer. *** getEditToken was null got c8477b8f9928be26955e36b0d3295736 *** getEditToken returning c8477b8f9928be26955e36b0d3295736 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 User::matchEditToken: broken session data 3514833eb1ab2367bc008b4bd487873e+\ != 337f3aae3ee72537c5773bd58d2e37b8+\ *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 EditPage::importFormData: Failed token check; forcing preview SFUtils::showFormPreview: enter. Title::getRestrictionTypes: applicable restrictions to Sandbox are {edit,move} *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 User::matchEditToken: broken session data 3514833eb1ab2367bc008b4bd487873e+\ != 337f3aae3ee72537c5773bd58d2e37b8+\ *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9
 * 1) 0 includes/EditPage.php(1237): User->matchEditToken('3514833eb1ab236...')
 * 2) 1 includes/EditPage.php(798): EditPage->tokenOk(Object(FauxRequest))
 * 3) 2 extensions/SemanticForms/includes/SF_AutoeditAPI.php(374): EditPage->importFormData(Object(FauxRequest))
 * 4) 3 extensions/SemanticForms/includes/SF_AutoeditAPI.php(900): SFAutoeditAPI->setupEditPage('')
 * 5) 4 extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction
 * 6) 5 extensions/SemanticForms/specials/SF_FormEdit.php(92): SFAutoeditAPI->execute
 * 7) 6 extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm('Sandbox_test', '', NULL)
 * 8) 7 includes/specialpage/SpecialPage.php(363): SFFormEdit->execute('Sandbox_test')
 * 9) 8 includes/specialpage/SpecialPageFactory.php(562): SpecialPage->run('Sandbox_test')
 * 10) 9 includes/MediaWiki.php(275): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
 * 11) 10 includes/MediaWiki.php(584): MediaWiki->performRequest
 * 12) 11 includes/MediaWiki.php(435): MediaWiki->main
 * 13) 12 index.php(46): MediaWiki->run
 * 14) 13 {main} *** getEditToken w/o request
 * 1) 0 includes/EditPage.php(1237): User->matchEditToken('3514833eb1ab236...')
 * 2) 1 extensions/SemanticForms/includes/SF_AutoeditAPI.php(461): EditPage->tokenOk(Object(FauxRequest))
 * 3) 2 extensions/SemanticForms/includes/SF_AutoeditAPI.php(908): SFAutoeditAPI->doStore(Object(EditPage))
 * 4) 3 extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction
 * 5) 4 extensions/SemanticForms/specials/SF_FormEdit.php(92): SFAutoeditAPI->execute
 * 6) 5 extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm('Sandbox_test', '', NULL)
 * 7) 6 includes/specialpage/SpecialPage.php(363): SFFormEdit->execute('Sandbox_test')
 * 8) 7 includes/specialpage/SpecialPageFactory.php(562): SpecialPage->run('Sandbox_test')
 * 9) 8 includes/MediaWiki.php(275): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
 * 10) 9 includes/MediaWiki.php(584): MediaWiki->performRequest
 * 11) 10 includes/MediaWiki.php(435): MediaWiki->main
 * 12) 11 index.php(46): MediaWiki->run
 * 13) 12 {main} *** getEditToken w/o request
 * A sucessful edit on a non-SForms wiki page ends up with the following in the log:

*** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 User: got user 15838 from cache User: loading options for user 15838 from override cache. Title::getRestrictionTypes: applicable restrictions to User:Hershm are {edit,move} *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9
 * I could see this being a conflict with some other extensions, though. Any pointers there? -- ☠ MarkAHershberger ☢ (talk) ☣ 16:46, 17 January 2015 (UTC)


 * That's a lot of printout! First of all, it's just Semantic Forms or SF, not SForms - sorry about the confusion. As to the issue, I think it's a reasonable guess that the problem is due to some conflict with another extension, but I don't know anything more than that. Maybe try to disable/enable other extensions to try to isolate the problem, or just to make sure that that's not it? Yaron Koren (talk) 01:09, 19 January 2015 (UTC)
 * Just trying to be thorough!
 * I disabled most other extensions in the dev server and still had the problem. I'm using an updated and extended Auth remoteuser to handle SSO.  Like I said, everything else works, so maybe Semantic Forms has exposed a bug in my code or my code has exposed one in Semantic Forms!
 * Or, we could both be winners and each have a bug in our respective code base!
 * I'll go disable the extension now and see if I can get it to work. Thanks for your help. -- ☠ MarkAHershberger ☢ (talk) ☣ 21:32, 20 January 2015 (UTC)


 * Note that I downgraded to 2.7 (from 3.1) and the form submission works now, even with my mods. I don't think the problem only with my code. -- ☠ MarkAHershberger ☢ (talk) ☣ 01:36, 22 January 2015 (UTC)


 * After using git bisect, I tracked it down the patch for and added my comments to.


 * Interesting to see that someone is having the same problem at the same time as we have. Hopefully it can be resolved. But ... I would disagree with the notion that SF would be the only extension that runs wild. The system on which it is installed (SF + auth_remoteuser) has also a VisualEditor installed. The thing is that it is unclear why it works with the a_ru-Extension disabled, but not with an activated one. We have been able to bypass this problem -- and not in an elegant kind of way -- with a if-condition in the localsettings, which throws an error once the update routine is being used; not to mention in the phpunit test environment. We are not entirely sure whether not both mentioned extensions add together, each in their part, something to the problem. --Temptuousinsolence (talk) 11:02, 22 January 2015 (UTC)

Providing a dynamic file name (one-step process)
Heiya, is it possible to dynamically set a default file name for file uploads when using the one-step-process? So far this seems only to be possible when one wants to upload a file directly (file name = page name) and additionally annotate it with further information but not if the file to be uploaded just relates to the page to be created with with form. I do not think that this is if I am not mistaken. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 20:05, 18 January 2015 (UTC)


 * I'm not sure I understand the question, but the "default filename" thing should always be possible to do. However, there's a major flaw in that feature, which is that the uploaded file has to have the same file type as the default filename is set with (like ".gif" or whatever it is); otherwise it won't work. Yaron Koren (talk) 01:31, 19 January 2015 (UTC)


 * Indeed, the file type is another issue. Providing a dynamic default filename based on the page name when creating a page through the one-step process is what I meant. One just ends up the the "Semantic Forms Permission error.jpg" as default filename. This is understandable since the form has now clue what it will be. However, doing it with e.g should work but the filename would not be very meaningful. At least it is unique. Probably a matter of compromise --&#91;&#91;kgh&#93;&#93; (talk) 09:29, 19 January 2015 (UTC)


 * Ah, based on the page name, now I get it. No, it's not possible; the file upload happens before the page is created. Yaron Koren (talk) 15:37, 19 January 2015 (UTC)


 * Thank you for confirming. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 15:56, 19 January 2015 (UTC)

No multiple selection in "tree" input
There are no parameters to enable multiple selection in "tree" input. Proposed example also doesn't show this feature: see example. Dmitry Russkih (talk) 18:05, 20 January 2015 (UTC)


 * There is indeed a problem with that example, although it's due to a temporary issue involving Cargo. Anyway, you can always specify that the tree input should allow multiple values by adding "|list" to the field tag. (Maybe the documentation should be clearer on that.) Yaron Koren (talk) 19:03, 20 January 2015 (UTC)
 * Thanks! I've comlemented help page but I can't edit example page (capcha wonts one name, but system not accepted both 'Kerry' or 'John Kerry') Dmitry Russkih (talk) 00:04, 21 January 2015 (UTC)


 * Thanks. I purposely made that CAPTCHA "incorrect", because it was the only way to fully block spammers. I could just add in "|list" to the form, but instead I plan to fix the issue with template parsing in SF, so that it knows it's a list. To clarify, this particular bug only happens when the Cargo extension is installed. Yaron Koren (talk) 14:47, 21 January 2015 (UTC)

Practical examples
This documentation is really great work. One thing that would make it even more useful to me is if it had more practical examples. We use forms, and code for one of them can be seen here and this is what it looks like when entering new data. What we would like to add is an option to allow multiple values for the same field. This seems to be described here but I just don't get it without a practical example. Could someone point me to one? Thank you so much for your help! ReplicationWiki-fan (talk) 15:43, 24 January 2015 (UTC)


 * The form looks good! As noted in the documentation, the fact that a field holds a list of values is really defined in the template. See the "Cuisine" field here, for example. Yaron Koren (talk) 16:16, 25 January 2015 (UTC)

How to define a form for a category but use another on the same category page? (SF 3.0+)
I want to How can I do this? Is there a solution? In former days using special properties, this was possible, now I have no idea to resolve this. Any ideas? Thanks. --Andreas P. 14:46, 27 January 2015 (UTC)
 * 1) edit the category page using one form (e.g "form:category properties")
 * 2) but define on that very page the form to be used for pages gathered in that category
 * on project page    :     would define 1) but
 * on the category page itself overrides of course the global definition


 * Defining forms for category pages has definitely gotten a lot more limited with the #default_form parser function. I thought about that limitation, but figured that very few people use forms for editing category pages. Maybe I was wrong, though! In any case, if all your category pages use the same form, you can make that the default form by putting a #default_form call in the page Project:Category or its equivalent. Yaron Koren (talk) 15:27, 27 January 2015 (UTC)
 * Well, I see (I'm using the setting in Project:Category already). I would like to have that setting possibility back. We use it on Wikis set on our http://biowikifarm.net, e.g. http://wiki.bayernflora.de, http://offene-naturfuehrer.de and some other. I guess it won't change the implementation anew, would it? ;-) --Andreas P. Icon_External_Link_E-Mail.png 15:41, 27 January 2015 (UTC)


 * So - just to clarify - do you have more than one form for editing different category pages? Yaron Koren (talk) 19:01, 27 January 2015 (UTC)


 * So far only one form for editing (all) categories (i.e. form:category properties defined on the project:category page). The category page itself defines another form for *the pages* gathered in that category page. It seems that before SF 3.0 the setting Has default form::… on a category page just defines for the form usage for main namespace-pages, not the category page itself. --Andreas P. Icon_External_Link_E-Mail.png 12:00, 28 January 2015 (UTC)


 * So is there a problem with #default_form? If there's only one form for all category pages, the whole thing should work. Also, the behavior of "Has default form" didn't change in SF 3.0. Yaron Koren (talk) 15:27, 28 January 2015 (UTC)


 * OK "Has default form" still works, although not as translation (e.g. "Hat Standardformular"), but it works as I want it to be: I can use (1) "form:category properties" on the category page and (2) define on the very same category page the form I want to edit all gathered pages. Anyway, with only #default_form it's not possible. Could this functionality (1 + 2) be kept in SF 3.0+ ? I would appreciate it. Or another solution–maybe not clean–would be, to allow a ranking of used forms in #default_form(s). If I understand it correctly, "Has default form" on a category page defines the form for all the *pages* excluding the category page itself, whereas #default_form defines the form to be use for all the *pages* including the category page itself. So it seems, using "Has default form" won't change the rank of old form settings from before SF 3.0. But I'm worried, because it is marked as deprecated and will be removed at some day and Than I have to rewrite all this stuff. Or I should define #default_form only in the template and not on the category page … --Andreas P. Icon_External_Link_E-Mail.png 15:21, 29 January 2015 (UTC)


 * No, #default_form is not supposed to apply to the category page - if it does, that's a bug. Within the #default_form system, the only way to apply a form to a category page is via the Project:Category page. Are you seeing something different? And does that affect your opinions at all? Yaron Koren (talk) 16:56, 29 January 2015 (UTC)


 * «#default_form is not supposed to apply to the category page» but it does (I use SF 3.1 see special:Version on temporary wiki. As described above, my setting is: on (PP) project page Project:Category (BTW: it prints out nothing) and categories work with that form. Good so far. And on a (CP) category page I set  (BTW: it prints: "This category uses the form task", not nothing) and on CP the form:category properties is overruled by form:task. (The Wiki above has German templates and form names, so I translated them) --Andreas P. Icon_External_Link_E-Mail.png 19:50, 29 January 2015 (UTC)


 * Ah, right you are; sorry about that. I just checked in a fix; you can either get the code from Git, or add this change in manually. For the issue of nothing printed out, removing the "Form:" namespace from the #default_form call might help, though I'm not sure. Yaron Koren (talk) 20:31, 29 January 2015 (UTC)


 * Thank you, Yaron. Does it update also with  for "3.1"? My guess is only when using the "2.8.*@dev" version for the package, right? Or I try it manually by implement the patch. --Andreas P. Icon_External_Link_E-Mail.png 21:56, 29 January 2015 (UTC)


 * I have no idea about the Composer stuff. Yaron Koren (talk) 00:02, 30 January 2015 (UTC)

default values depending on dropdown selection
Hello everyone

I am currently facing a challenge with one of my forms. The problem is not entierly new, I know, but maybe it helps to give it some attention every now and then.

What I have is a form with a dropdown (where users can select a type) and a textarea for a detailed description. What I want is to preload a text in this textarea depending on the user selection (preferably without tinkering with js). What makes matters worse is that I have two types where I don’t want to show the textarea at all but store the default text in a hidden input field.

The solution so far is, I have a form that is build dynamically. The form for creating a page works like this:
 * 1) for every type I generate a textare input field with the corresponding default text enclosed in a div with a unique id
 * 2) the dropdown field gets a rather complex 'show on select' statement
 * 3) for the types where I don't want the textarea to be edited, the textarea field gets a restricted statement with a non existing group

Note: In (3) I tried using hidden fields instead but that breaks as soon as someone selects one of these types. Every entry for "description" will then be filled by the last defined hidden type and not the selected one.

This solution kind of works. Ish. To be more precise, the form produces a template call where I have multiple entries for the textarea field all filled with the same (correct) value. Let me give you an example:

The template processing works correct. And the problem rectifies itself with the first edit, because my edit form looks like that:
 * 1) there is only one textarea field
 * 2) there is an edit notice enclosed in a div with a special id. This note states, that the field will be filled automatically by the template
 * 3) the type dropdown has a much more simpler 'show on select': only for the non editable types the edit note from (2) will be shown

So, after I edit the page, the resulting template call looks like that:

Long story short, here are my questions:
 * Is there an easier way?
 * If not, since it is a faily often asked feature: is there any change any future SF versions will support a "value on select" statement for fields?

Used versions:
 * MediaWiki 1.23.5
 * PHP 5.4.35
 * MySQL: 5.5.40
 * Semantic Forms 3.0
 * Semantic MediaWiki 2.0

Tobias Oetterer (talk) 09:01, 28 January 2015 (UTC)


 * Before we get into the details: why not just have a separate form for each type? Yaron Koren (talk) 15:27, 28 January 2015 (UTC)