Extension talk:Page Forms

googlemaps field
after hitting submit on a query form. the googlemaps field re-draws but forgets the zoom parameter it had before you hit submit. see:http://juanitospeppers.com/wiki/Special:RunQuery/GlogQuery


 * That's not surprising - there's no easy way for the system to remember what the zoom was. But if you think the default zoom should be different anywhere along the way, I'm curious to hear it. Yaron Koren (talk) 20:32, 2 February 2015 (UTC)


 * shouldn't it find and use the zoom param i have on the form field.


 * No - the map inputs in SF, unlike their counterparts in Semantic Maps, don't support the "zoom" parameter. It's my fault for not explaining that in the documentation. But I set it that way on purpose, because it didn't make sense to me that a certain zoom level would be the best one for one form, or one wiki, but not for another. But perhaps the current defaults could be improved. What do you think? Yaron Koren (talk) 00:07, 3 February 2015 (UTC)

Using {{#set:... with multiple properties
I noticed that a form will not recognize semantic properties that are set in "one go": You need to set them "one by one" like:

Is this behavior correct? I simplified a template and used the the "one go" approach but then the properties that are used in the form "break" in the form. I needed to set those properties used in the form "one by one". I must say that I combined this with  {{#external_value:  but all properties are filled with the  {{#external_value:  call with  {{#autoedit:...  before you can use the form. Regards, --Felipe (talk) 08:57, 4 February 2015 (UTC)


 * It's true that Semantic Forms' template parsing is not perfect. If the form ever doesn't identify the property for a field, the easiest approach is just to hardcode the connection, by adding a "property=" parameter to that field's tag in the form definition. Yaron Koren (talk) 14:09, 4 February 2015 (UTC)


 * Wel it is not a problem. My logic tells me that the "one go" approach is less expensive for the wiki engine but that is probably not true anyway :). I will give "property=" a go in combination with the "one go" approach but in almost all the forms we use the Semantic Forms decides which property it is supposed to use. This works all the time. Thanks --Felipe (talk) 14:26, 4 February 2015 (UTC)

[RESOLVED] Wrong category/form for subpages created with #forminput
Hello, I try to create location pages and subpages for annual events at these locations. (Location and Location/Event 2015, Location/Event 2016...). For both location and event I have form & template each and in the location template (which produces an infobox) included is the following code for creating an event subpage directly from the location page:
 * Create a new event subpage

I have 2 different categories and on each category page I am using  to define the default form.

But now, when creating the event subpage, it gets automatically sorted into the category of the superpage, thus also using its (wrong) form.

Any ideas what I could be missing? Or could there be a better way of creating the subpages with the prepended location pagename via forms? --Zabien (talk) 01:08, 6 February 2015 (UTC)


 * So you have a "locations" category and an "events" category, but events are showing up in the "locations" category? Do they also show up in the "events" category? Or am I misunderstanding things? Yaron Koren (talk) 03:26, 6 February 2015 (UTC)


 * No, that's exactly what happens. The events only show up in the locations's category, but not in the events category (where they only should be). --Zabien (talk) 11:31, 6 February 2015 (UTC)


 * Could it be that the "event" template just has the wrong category tag? Yaron Koren (talk) 15:32, 6 February 2015 (UTC)


 * This was my first thought, too, but double and triple checked that, it's correct there. --Zabien (talk) 15:45, 6 February 2015 (UTC)


 * Could you pastebin, or include here, the contents of that template? Yaron Koren (talk) 16:33, 6 February 2015 (UTC)


 * Sure: pastebin of "location" template (don't get confused, I simplified the example here). The event template is similar, its last lines:

Open the World map of events.
 * colspan="2" align="center" |
 * colspan="2" align="center" |
 * }

Zabien (talk) 17:18, 6 February 2015 (UTC)


 * I'm still guessing that the issue is in the "event" template (it would have been more helpful if you had pastebin'ed that one), but anyway, this doesn't seem like a Semantic Forms issue - it's an issue of pages somehow being tagged with the wrong category. Yaron Koren (talk) 18:05, 6 February 2015 (UTC)


 * Okay, so I'll have to look further, create new from scratch and see if I can find the troublemaker somewhere in the template. Thank you for your help! --Zabien (talk) 11:41, 9 February 2015 (UTC)


 * For the record: It was a mistake in the event form, not the template. In the form, the  call was directing to the wrong template.  --Zabien (talk) 21:58, 2 March 2015 (UTC)

Using Tree input for multiple category selection, doubles up on catebories.
It works. As double ups have no consequence on actual category definition. But it is a pain to have multiple edits also providing multiple entries of the same category.

An example can be seen here.

Is there a way to limit the creation of duplicates, or perhaps a simple method of maintaining such a thing?

As a quick edit to this, there is more of an issue. Removing a category, when one has previously been saved to the page, simply results in it outputting the new categories again, minus the removed one. But the removed one still exists in the list from the previous edit and so it doesn't actually get removed. The only fix I can see in this case is to go into source and remove the duplicates and missing ones that way... There must be a way for the form input to clear out the category and refresh it on save surely? 103.13.11.118 11:53, 9 February 2015 (UTC)


 * That's not good! The issue seems to be that the "Software" category shows up three times in the tree. Is there any way you could simplify your category structure so that "Category:Software" only has one parent? Yaron Koren (talk) 14:32, 9 February 2015 (UTC)

Assign Unique Subobject ID's from Multiple Embeded Form?
I've a great use-case for a multiple instance template that creates subobjects. However it includes the possibility that a subobject with exactly the same property values get entered, meaning the anonymous identifier is also the same, seeing the duplicate object(s) ignored!. Is there a workaround for this? I tried the NumerAlpha extension per this thread but it's output blows up with UNIQ1b9902e25ef3ef0b-in-00000000-QINU stuff under MW 1.23.2 when used in the templates. I can adjust the form to use a ton of statically numbered fields, but the multiple option is so much more elegant when it comes to applying instance-specific mandatory fields, regex filters, and the like. Maybe this is more of a SMW question? Thanks! (SF 3.1) - Lbillett (talk) 19:23, 10 February 2015 (UTC)


 * I can't think of another solution; yes, this does sound like more of an SMW question. Yaron Koren (talk) 21:45, 10 February 2015 (UTC)


 * Ok, thanks. I'll keep it multiple-instance based and just try to cope by communicating the limitations to those using the form. Curious...instead of using a subobject in my template, would a #cargo_store call accomplish pretty much the same thing? Without this duplication limitation? (the template being called multiple times from the same article?). It's not critical the the data be in subobjects and I've been meaning to try Cargo out... heard the author hangs out around here too. - Lbillett (talk) 02:48, 12 February 2015 (UTC)


 * Yes, he does hang around here from time to time. :) That's true, maybe I should have mentioned Cargo - yes, Cargo would work better in this instance, in my opinion. It stores all template calls the same, as just a row in a table, whether there's one or more in a page, and whether the contents of one match the contents of another or not. Yaron Koren (talk) 14:17, 12 February 2015 (UTC)


 * I the interim I made a teeny-tiny parser function that returns output from the php mt_rand function and set it as the name for the subobject(s). Seems to do the job. Using something like the random number template would have been nicer, but it has another purpose and gives the same output everywhere it's called on a page save. My target pages typically only have half a dozen objects on them... if mt_rand sets two of them the same... I'll eat my hat. - Lbillett (talk) 15:27, 23 February 2015 (UTC)

query string special characters
Hey i tried the url encode and it works better but doesn't really give me what i want. In this case we use pagename = Jon's Grow or

this value loads into a combobox input. ex1 gives me: Jon&amp;#39;s Grow | ex2 gives me: Jon

how do i get the form to translate the url encode into ' ?


 * What version of SF are you using? And did you try this with a link type of "link" or "button" instead? One of those might work better. Yaron Koren (talk) 14:19, 12 February 2015 (UTC)


 * 3.2alpha 2nd feb. just tried with link and button and its the same. tried switching between combobox, text input, both show the &amp;#39;. form here http://juanitospeppers.com/wiki/Form:Glog_Update and formlink on http://juanitospeppers.com/wiki/Template:Glog


 * Okay, thanks. It looks like the issue is with "PAGENAME" itself (though I guess I knew that before). This page offers a workaround, which is to simply wrap the " " call in a call to #titleparts, from the ParserFunctions extension. Yaron Koren (talk) 16:57, 12 February 2015 (UTC)


 * Oh nice, didn't think there would be a bug in magicwords. i changed urlencode and seems to work.


 * Cool. It's not a bug, exactly, just behavior that only makes sense some of the time. Yaron Koren (talk) 17:47, 12 February 2015 (UTC)

Fatal exception of type SMW\InvalidPropertyException - Create Form
I have a fresh SMW / SM-Forms installation:

Product 	Version MediaWiki 	1.24.1 Semantic Forms	3.2-alpha (2255e7c) Semantic MediaWiki 2.1 PHP 	5.6.3 (apache2handler) MySQL 	5.6.21

When I want to use Special:CreateForm.php I get the error:

after I selected a template in the select menu.

Any ideas? Thank you for help Martin 15 Feb 2015


 * Could you add the following to LocalSettings.php:

$wgShowExceptionDetails = true;
 * ...so you can see the full error details? Yaron Koren (talk) 01:46, 16 February 2015 (UTC)

No constraints for autocomplete with remote autocompletion
Just an additional comment to "Autocomplete on Outside Values Doesn't Constrain", posted by Lbillett on 8 December. I haven't tested this in any detail, but in one case I did notice that the issue he/she raised also holds true for "remote autocompletion". Hope that helps if you didn't know already. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 21:59, 18 February 2015 (UTC)

Multiple-instance templates and forms and "show on select"
(1) Is there a way to use the field option "show on select" in the very multiple form itself properly so that each specification of "show on select" is pointing to let's say ? The background is that in a multiple-instance template called – for statements, media, details etc. in determination keys of organisms and things – I want the detail information to be handled by a sub-template because of various groups demanding for different details: “birds” need other details than “plants” or “plastic waste” etc. and I thought using a sub-template for detail information instead of increasing the  parameters would do the trick but I fail to implement that in consonance with "show on select". (2) Is there another way to implement this strategy of detail information as a sub-template in multiple forms or only the possibility to increase template parameters in ? Thank you! --Andreas P. 10:05, 20 February 2015 (UTC)


 * If you're just asking about using "show on select" in multiple-instance templates, that should work. What is the form text that's failing? And do you see any JavaScript errors there? Yaron Koren (talk) 13:55, 20 February 2015 (UTC)
 * In my case I might have 2 nested multiple-instance template-forms, which do not work because it is documented so. The minimum example below works only if I have specified but I want it to be multiple like  and this case I can not get to work. Is there a way to get it working differently or have I missed something from the documentations? --Andreas P. Icon_External_Link_E-Mail.png 15:46, 23 February 2015 (UTC)


 * Great. I believe the structure of your form is incorrect: the "Details for" input should be in the "detailed properties" template, and it's that template that should be multiple-instance, not the "Lead" one. Yaron Koren (talk) 20:47, 23 February 2015 (UTC)
 * Moving the "Details for" does not really help, I do have a template structure like this …




 * … and I thought it would be possible to handle this with a complex form but so far I did not succeed for the nesting issue of |detailed properties= . (1) I wonder: is the automatically a multiple-instance even though I did not set it? (2) Is there a way to get this complex template design get to work or is this impossible?  To find a viable solution, the only compromise I can think of right now is to skip this nesting-idea and instead expand the template parameters of  to suit the detailed property information. Or do you see another solution? --Andreas P. Icon_External_Link_E-Mail.png 22:06, 23 February 2015 (UTC)


 * You can't have two levels of multiple-instance templates in a form. One obvious possibility is to have a separate page for each "lead"... Yaron Koren (talk) 00:55, 24 February 2015 (UTC)


 * So the construction of  in conjunction with   is always considered to be a multiple-instance, even if it is not set extra? --Andreas P. Icon_External_Link_E-Mail.png 11:59, 24 February 2015 (UTC)


 * Sorry - now I understand the whole thing. I'm not used to single-instance templates being embedded. I don't know if SF supports what you're trying to do, unfortunately; you may just need to put everything into the "Lead" template, instead of splitting things up. Yaron Koren (talk) 13:57, 24 February 2015 (UTC)


 * OK, I see. Well, to make the many new parameters in  conveniently editable I can at least use something like Extension:Header Tabs. Thanks --Andreas P. Icon_External_Link_E-Mail.png 14:09, 24 February 2015 (UTC)

Creating pages using API. Issue with default values giving empty values
I'm creating pages using the api. However forms there by default has a value set are empty when using the API. If created from wiki using the form they are filled in. Anyone know a solution to this or had the same issue


 * Are you using the 'sfautoedit' API action? Yaron Koren (talk) 18:39, 20 February 2015 (UTC)

undefined constant SF_NS_FORM when switching wiki language
After changing the language of a smw wiki i get: What should i do about it? --Seppl2013 (talk) 10:34, 24 February 2015 (UTC)


 * Do you have SMW installed? And what versions are you running of SF, MediaWiki and (possibly) SMW? Yaron Koren (talk) 14:32, 24 February 2015 (UTC)

Hi Yaron - Seppl2013 is Wolfgang Fahl so you know my SMW environment: Semantic Form 3.2-alpha (46b6df3) 17:00, 30. Jan. 2015 SMW 2.1

The problem happens in the WikiFamily where some Wikis are "de", others are "en". When I switch a wiki from one language to another the problem appears. I assume the LocalisationCache is the issue as shown in the stacktrace. How do I reset that cache?

definition in SemanticForms.php
I think this is not picked up:

StackTrace
Call Stack 1	0.0003	641664	{main}	../index.php:0 2	0.0005	675496	require( '/var/www/mediawiki/mediawiki-1.24/includes/WebStart.php' )	../index.php:43 3	0.0693	9021328	require_once( '/var/www/mediawiki/mediawiki-1.24/includes/Setup.php' )	../WebStart.php:121 4	0.0990	13370696	Language::factory	../Setup.php:594 5	0.0990	13370696	Language::newFromCode	../Language.php:161 6	0.1126	15223232	Language::getFallbacksFor	../Language.php:202 7	0.1151	15806560	LocalisationCache->getItem	../Language.php:4287 8	0.1151	15806560	LocalisationCache->loadItem	../LocalisationCache.php:257 9	0.1151	15806560	LocalisationCache->initLanguage	../LocalisationCache.php:323 10	0.1257	17041248	LocalisationCache->recache	../LocalisationCache.php:449 11	0.1628	18134920	LocalisationCache->readPHPFile	../LocalisationCache.php:859 12	0.1632	18157160	include( '/var/www/mediawiki/mediawiki-1.24/extensions/SemanticForms/languages/SF_Namespaces.php' )	../LocalisationCache.php:514 --Seppl2013 (talk) 06:38, 25 February 2015 (UTC)
 * 1) 	Time	Memory	Function	Location


 * I doubt it's directly related to the localization cache - these are constants that need to be set, and they're the same constants regardless of the language. Due to an "accident of history", it's SMW that sets these constants, if SMW is installed. Could it be that SMW is being called after SF? That might lead to a strange problem like this. Yaron Koren (talk) 13:54, 25 February 2015 (UTC)

Add Title Prefix Without Using One-step Process?
I'd like to add a prefix to the title supplied to a formlink field when creating an article. Using namespace=mynamespace sets the namespace great. I can do it in the one step process, but that leaves a field behind that I never use again. Is there another way? - Lbillett (talk) 13:26, 28 February 2015 (UTC)


 * I don't think so, unfortunately. Yaron Koren (talk) 23:00, 1 March 2015 (UTC)

Still got problem like is mentioned here 'Serialization of 'Closure' is not allowed'.
Hi I think that semantic forms is very useful extension. I got the same problem like is mentioned there 'Serialization of 'Closure' is not allowed'. I can create form, error occurs when I try create page out of that form. It prints out message like is in linked topic. I have mediawiki 1.20.2. Please advise.

--Petrsorbo (talk) 16:36, 1 March 2015 (UTC)


 * What version of Semantic Forms are you using? Yaron Koren (talk) 23:00, 1 March 2015 (UTC)

Warning: Missing argument 2 for WikiEditorHooks::editPageShowEditFormInitial
SF 3.2 ... updated today.

Complete output of xdebug:

and while I am at it, this would be a second error that I am getting right now: --Temptuousinsolence (talk) 09:52, 2 March 2015 (UTC)


 * Ah, it looks like the header for that WikiEditor function was changed in July 2014, which appears to be responsible for both of those errors. No one pointed out this problem until now! I just checked in a change to SF that should hopefully solve everything. Yaron Koren (talk) 14:39, 2 March 2015 (UTC)
 * That appears to solve the issue. I have added your fix to my SF version and tested it. No errors for the moment. --Temptuousinsolence (talk) 08:54, 3 March 2015 (UTC)