Extension talk:Page Forms/Archive January 2015

How to show an Enumeration with Checkboxes using newlines, rather than comma-separated list

Hi! I figured out how to create an enumeration that shows up with checkboxes in the form; and with a comma-separated list in the displayed template. I'm using

{{#arraymap:{{{Categories|}}}|,|x|[[Has Category::x]]}}

In the template and {{{field|Categories}}}

In the code. The problem is that the categories tend to be long, so I would prefer the display to use a newline-separated list both in the form and in the display. If I change the separator from comma to '\n\n', which the documentation seems to suggest, then the form still shows the categories on one line, and the result display just gives an error (something like 'invalid value for field'). How do I accomplish showing the combo boxes on top of one another, and the result display also on top of one another.

For the form, see here. For the template, it's not the "delimiter" parameter that you should set to "\n\n" (that one should stay as a comma), but the "new delimiter" parameter, which needs to be added at the end. Yaron Koren (talk) 17:11, 30 January 2015 (UTC)

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 :

{{{for template|ItemSuite|label=Tomes de la suite |multiple|minimum instances=1|add button text=Ajouter un tome dans la suite}}}

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 [1]) is used in extension Vector (see [2]). 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)

Spot on : I just had to edit out the call to Vector from my LocalSettings.php file, and everything started to work fine as before. Namely adding the // in : // require_once( "$IP/extensions/Vector/Vector.php" ); . Many thanks. 92.128.41.51 21:51, 16 February 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

{{Special:RunQuery/Form1}} {{Special:RunQuery/Form2}}

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ː

{{{field|Virtual Host|input type=combobox|mandatory|default=None|values from namespace=Machine}}}

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 "<noinclude>" 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 User::matchEditToken fails and got the following as the first failure:

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

	public function getEditToken( $salt = '', $request = null ) {
		if ( $request == null ) {
			wfDebug(" *** getEditToken w/o request \n");
			$request = $this->getRequest();
		}

		wfDebug(" *** getEditToken before user check\n");
		if ( $this->isAnon() ) {
			return self::EDIT_TOKEN_SUFFIX;
		} else {
			$token = $request->getSessionData( 'wsEditToken' );
			wfDebug(" *** getEditToken token: $token\n");
			if ( $token === null ) {
				$token = MWCryptRand::generateHex( 32 );
				$request->setSessionData( 'wsEditToken', $token );
				wfDebug(" *** getEditToken was null got $token\n");
			}
			if ( is_array( $salt ) ) {
				$salt = implode( '|', $salt );
			}
			wfDebug(" *** getEditToken returning $token \n");
			return md5( $token . $salt ) . self::EDIT_TOKEN_SUFFIX;
		}
	}

	public function matchEditToken( $val, $salt = '', $request = null ) {
		$sessionToken = $this->getEditToken( $salt, $request );
		if ( $val != $sessionToken ) {
			wfDebug( "User::matchEditToken: broken session data $val != $sessionToken ($salt)\n" );
			$e = new Exception();
			wfDebug( $e->getTraceAsString() );
		}

		return $val == $sessionToken;
	}

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):

<noinclude>
{{#formlink:form=Sandbox test|link text=    Submit an idea     |link type=button}}
</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{standard input|summary}}}
{{{info|page name=sandbox}}}
{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
</includeonly>

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+\ ()
#0 includes/EditPage.php(1237): User->matchEditToken('3514833eb1ab236...')
#1 includes/EditPage.php(798): EditPage->tokenOk(Object(FauxRequest))
#2 extensions/SemanticForms/includes/SF_AutoeditAPI.php(374): EditPage->importFormData(Object(FauxRequest))
#3 extensions/SemanticForms/includes/SF_AutoeditAPI.php(900): SFAutoeditAPI->setupEditPage('')
#4 extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction()
#5 extensions/SemanticForms/specials/SF_FormEdit.php(92): SFAutoeditAPI->execute()
#6 extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm('Sandbox_test', '', NULL)
#7 includes/specialpage/SpecialPage.php(363): SFFormEdit->execute('Sandbox_test')
#8 includes/specialpage/SpecialPageFactory.php(562): SpecialPage->run('Sandbox_test')
#9 includes/MediaWiki.php(275): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#10 includes/MediaWiki.php(584): MediaWiki->performRequest()
#11 includes/MediaWiki.php(435): MediaWiki->main()
#12 index.php(46): MediaWiki->run()
#13 {main} *** getEditToken w/o request
 *** 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+\ ()
#0 includes/EditPage.php(1237): User->matchEditToken('3514833eb1ab236...')
#1 extensions/SemanticForms/includes/SF_AutoeditAPI.php(461): EditPage->tokenOk(Object(FauxRequest))
#2 extensions/SemanticForms/includes/SF_AutoeditAPI.php(908): SFAutoeditAPI->doStore(Object(EditPage))
#3 extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction()
#4 extensions/SemanticForms/specials/SF_FormEdit.php(92): SFAutoeditAPI->execute()
#5 extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm('Sandbox_test', '', NULL)
#6 includes/specialpage/SpecialPage.php(363): SFFormEdit->execute('Sandbox_test')
#7 includes/specialpage/SpecialPageFactory.php(562): SpecialPage->run('Sandbox_test')
#8 includes/MediaWiki.php(275): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#9 includes/MediaWiki.php(584): MediaWiki->performRequest()
#10 includes/MediaWiki.php(435): MediaWiki->main()
#11 index.php(46): MediaWiki->run()
#12 {main} *** 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
 *** getEditToken w/o request
 *** getEditToken before user check
 *** getEditToken token: 368f4813db995d79921958378cc7eaa9
 *** getEditToken returning 368f4813db995d79921958378cc7eaa9

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 task T53505 and added my comments to task T87173.

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)

I'm using VisualEditor as well, but I don't know what you're talking about with a_ru-Extension. Are you saying that the if-condition allows SemanticForms to work? (That would seem really odd, but I ask to be sure.) -- ☠MarkAHershberger☢(talk)☣ 23:00, 3 February 2015 (UTC)

Oh, and fwiw, I think this is a problem with the Auth_remoteuser extension and some bug that it has that Semantic Forms triggers. -- ☠MarkAHershberger☢(talk)☣ 23:02, 3 February 2015 (UTC)

I submitted a patch for this issue here. --Ike @ WikiWorks 00:53, 10 February 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 --[[kgh]] (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 {{CURRENTTIMESTAMP}} should work but the filename would not be very meaningful. At least it is unique. Probably a matter of compromise --[[kgh]] (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 --[[kgh]] (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)

That's great, thank you. It somewhat worked for us as we now have a list of authors. However, this one seems to indicate that there is some error in our code because the last listed coauthor of a study is not listed. It might be because we use templates in templates with the form.? At least the array structure as described here and as we tried to copy from the example did not quite work. When we used the code as we thought we should we always ended up with two extra "]]". I guess there should also be some option to create all those author pages automatically via the category rather than adding the template to each one by hand? ReplicationWiki-fan (talk) 19:54, 3 February 2015 (UTC)

I didn't understand everything you wrote, but: you should remove the string "[[Article authors::" from that template, it serves no purpose; and you can add a #forminput tag to the category page. Yaron Koren (talk) 20:06, 3 February 2015 (UTC)

Ok, I deleted that string. Still for the last two of three co-authors [3] their study is not listed on their pages while for the first one it works and I don't understand why.

I tried to include a #forminput tag on the category page but the result didn't make sense to me. Would I have to create a new form for this? And could I then fill the empty pages automatically with [[Creates pages with form::Authors]]? ReplicationWiki-fan (talk) 23:28, 3 February 2015 (UTC)

It looks like you're querying on a different property than the one you're setting, for one thing - I don't know if that's the whole issue. What's the issue with the #forminput call? It looks fine to me. Yaron Koren (talk) 00:09, 4 February 2015 (UTC)

Hello User:ReplicationWiki-fan. Looking on this page it seems the following is happening:

1. First template call to [[Template:New Replication]]: |articleauthors=David Porras, Melissa Griswold
2. Second template call to [[Template:Article/replication/entry]]: | Authors = {{{articleauthors}}}
3. Where you set the property: {{#arraymap:{{{Authors|}}}|,|x|[[Authors::x]]}}

It is not clear to me how David Porras, Melissa Griswold end up in [[Property:Article authors]] because you seem to assign them to [[Authors::...]] but that is a property that does not seem to exist. You are also doing calls to templates and setting properties inside of a wikitable, this is possible but when you are debugging you should exclude anything that can break what you are trying to achieve. If you want to test a form you could start with a test page where you set your properties in the first template call, just setting the values no tables or anything else. Use non capitalized parameter names, this prevents any typos. When doing it like this you can be sure that your form will recognize the parameters you want to use. If that works just start adding what you want step by step and make sure it keeps working. In your form you could also use something like this:

{{{field|articleauthors|size=50|list|delimiter=,|values from property=Article authors|input type=text with autocomplete|mandatory|placeholder=Mandatory}}}

You can then set the property with [[Article authors::{{{articleauthors|}}]]. Regards, --Felipe (talk) 08:30, 4 February 2015 (UTC)

Ok, I see I had mixed up something with "Article authors" and "authors". To be honest I just don't understand what a template call really is and how it works together with the forms and the category. I tried some changes [4] [5] [6] but then it seemed no authors were listed any longer. What makes things difficult to understand for me is that I know sometimes changes don't work immediately, one must wait until jobs are done and I do not know how long to wait or what to do.

The guy who set up the wiki for us is no longer with us and now I have to make adjustments although I lack the necessary qualifications. So I need to learn or find someone who could help out. Ideally a bit of both.

The reason why the example you had chosen did not work seems to be related to the fact that it uses the Form:New Replication. I thought that since things don't yet work properly I had so far made the changes to Form:New Study lacking replication only. Checking now I see I haven't changed anything in the forms or their templates, only in the Template:Article/replication/entry, which is called by both forms. However, when they worked the categories for the property entries only listed the studies that used the Form:New Study lacking replication.

I guess with what you wrote I can already make progress and just have to invest some time that I cannot take right now. I will keep trying. Thank you! ReplicationWiki-fan (talk) 13:02, 4 February 2015 (UTC)

Ok, after trying out a couple of things I see that some things work and some others don't and some work but only after some time (I guess that has to do with the job queue). I'm getting closer to a solution because the arrays now worked in the form and also the category with the template for the property listed its entries when I used the syntax like in the template of the form (articleauthors) also for the template of the entry (| {{#arraymap:{{{Authors|}}}|,|x|[[articleauthors::x]]}}). Why the property is then called Article authors remains unclear to me. One small and quick thing, Felipe, when you wrote I can set the property with [[Article authors::{{{articleauthors|}}]], is there a { too much or should the | be replaced by a }? And where should I set the property? On the property page, in the template of the entry, in the template of the form, or in the form? The whole confusion comes from the use of Authors/Article authors/articleauthors and my failure to understand which means what. ReplicationWiki-fan (talk) 18:51, 6 February 2015 (UTC)

How to define a form for a category but use another on the same category page? (SF 3.0+)

I want to

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

How can I do this?

• {{#default_form: category properties}} on project page {{ns:project}}:{{ns:form}} would define 1) but
• {{#default_form: another-form}} on the category page itself overrides of course the global definition

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)

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. 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. 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. 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 {{#default_from: form:category properties}} (BTW: it prints out nothing) and categories work with that form. Good so far. And on a (CP) category page I set {{#default_from: task}} (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. 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 sudo php /usr/local/bin/composer.phar update mediawiki/semantic-forms 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. 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:

{{template
|type=Option 3 of 5
|description=Text for Option 3, modified by user
|description=Text for Option 3, modified by user
|description=Text for Option 3, modified by user
|description=Text for Option 3, modified by user
|description=Text for Option 3, modified by user
}}

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:

{{template
|type=Option 1 of 5
|description=Text for Option 3, modified by user again, set Type to Option 1 and edited description
}}

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)

That just happend in the course of development. I generate the fields that differ in the create and edit mask automatically. So basically the form just includes for fields and the template (or more precisely the lua module behind it) decides, whether it should render the "edit fields" or the "create fields".-- Tobias Oetterer (talk) 07:10, 3 February 2015 (UTC)

Now I'm even more confused - you have different fields that show up when creating vs. editing a page? Why is that? But as to your first question, I have no plans to add a "value on select" parameter; for what it's worth, I don't remember anyone asking for that feature before. Yaron Koren (talk) 13:55, 3 February 2015 (UTC)