Extension talk:Semantic Forms

From MediaWiki.org
Jump to: navigation, search
An archive box Archives 

§googlemaps field[edit | edit source]

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.
{{{field|location|input type=googlemaps|width=700|height=500|zoom=8|autozoom=off}}}
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[edit | edit source]

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[edit | edit source]

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{{#forminput:form=Event
|button text=Create
|query string= super_page={{PAGENAME}}

I have 2 different categories and on each category page I am using [[Has default form::…]]. 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:
| colspan="2" align="center" | {{#ask: [[{{BASEPAGENAME}}]] | ?Has coordinates | format=googlemaps | width=240 |height=240 }} <br /> Open the [[World map of events]].

[[Category:Festival event]]</includeonly>


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 {{{for template}}} 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.[edit | edit source]

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? 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?[edit | edit source]

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[edit | edit source]

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

{{#formlink:form=Glog Update|link text=Update Glog: {{PAGENAME}}|link type=post button|query string=Glog Update[Glog]={{urlencode:{{PAGENAME}}}}|popup}}


{{#formlink:form=Glog Update|link text=Update Glog: {{PAGENAME}}|link type=post button|query string=Glog Update[Glog]={{PAGENAME}}|popup}}

this value loads into a combobox input. ex1 gives me: Jon&#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 &#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 "{{PAGENAME}}" 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[edit | edit source]

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:

Internal error [deb202c1] 2015-02-16 01:08:58: Fatal exception of type SMW\InvalidPropertyException

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[edit | edit source]

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"[edit | edit source]

(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 {{{filed|myfield|show on select=value-1=>ID-1-in-this-multiple-form;value-2=>ID-2-in-this-multiple-form;}}}? The background is that in a multiple-instance template called {{Lead}} – 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 {{Lead}} 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 {{Lead}}? Thank you! --Andreas P. Icon External Link E-Mail.png 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 {{{for template|Lead}}} but I want it to be multiple like {{{for template|Lead|multiple}}} 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)
<!-- Minimum example -->
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Lead}}}<!-- I want it to be {{{for template|Lead|multiple}}} -->
Details for: {{{field|detail property class|input type=dropdown|values=plant,bird|show on select=plant=>plant_properties;bird=>bird_properties;}}}
{{{field|detailed properties|holds template}}}
{{{end template}}}
{{{for template|Lead/detailed properties|embed in field=Lead[detailed properties]}}}<!-- is this 'multiple' automatically? -->
<div id="plant_properties">
Organism size: {{{field|organism size}}}
<!-- many more parameters -->
<div id="bird_properties">
Wing span: {{{field|wing span}}}
<!-- many more parameters -->
{{{end template}}}
{{{standard input|summary}}}
{{{standard input|minor edit}}} {{{standard input|watch}}}
{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
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 …
{{Key Start|…|…}}
|detailed properties={{Lead/detailed properties|…|…}}
|detailed properties={{Lead/detailed properties|…|…}}
{{Key End}}
… 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={{Lead/detailed properties|…|…}}.
(1) I wonder: is the {{{for template|Lead/detailed properties|embed in field=Lead[detailed properties]}}} 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 {{Lead}} 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 |embed in field= in conjunction with holds template 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 {{Lead}} 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[edit | edit source]

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[edit | edit source]

After changing the language of a smw wiki i get:

Notice: Use of undefined constant SF_NS_FORM - assumed 'SF_NS_FORM' in /var/www/mediawiki/mediawiki-1.24/extensions/SemanticForms/languages/SF_Namespaces.php on line 22

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[edit | edit source]

I think this is not picked up:

SemanticForms.php:	define( 'SF_NS_FORM', 106 );
SemanticForms.php:	define( 'SF_NS_FORM_TALK', 107 );

§StackTrace[edit | edit source]

Call Stack
#       Time    Memory  Function        Location
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)

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?[edit | edit source]

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' .[edit | edit source]

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()[edit | edit source]

 Warning: Missing argument 2 for WikiEditorHooks::editPageShowEditFormInitial(), called in /home/ccc/htdocs/w/extensions/SemanticForms/includes/forminputs/SF_TextAreaInput.php
on line 155 and defined in /home/ccc/htdocs/w/extensions/WikiEditor/WikiEditor.hooks.php on line 147

SF 3.2 ... updated today.

Complete output of xdebug:

 Warning: Missing argument 2 for WikiEditorHooks::editPageShowEditFormInitial(), called in /home/ccc/htdocs/w/extensions/SemanticForms/includes/forminputs/SF_TextAreaInput.php
on line 155 and defined in /home/ccc/htdocs/w/extensions/WikiEditor/WikiEditor.hooks.php on line 147
Call Stack
#	Time	Memory	Function	Location
1	0.0009	250032	{main}( )	../index.php:0
2	0.2515	22811832	MediaWiki->run( )	../index.php:46
3	0.2515	22812288	MediaWiki->main( )	../MediaWiki.php:435
4	0.2524	22877096	MediaWiki->performRequest( )	../MediaWiki.php:584
5	0.2541	22935472	SpecialPageFactory::executePath( )	../MediaWiki.php:275
6	0.2550	23012000	SpecialPage->run( )	../SpecialPageFactory.php:584
7	0.2550	23012080	SFFormEdit->execute( )	../SpecialPage.php:363
8	0.3193	29298440	SFFormEdit->printForm( )	../SF_FormEdit.php:43
9	0.3303	30795920	SFAutoeditAPI->execute( )	../SF_FormEdit.php:88
10	0.3313	30812872	SFAutoeditAPI->doAction( )	../SF_AutoeditAPI.php:116
11	0.3440	31763656	SFFormPrinter->formHTML( )	../SF_AutoeditAPI.php:877
12	0.5786	36525768	SFFormPrinter->formFieldHTML( )	../SF_FormPrinter.php:1422
13	0.5858	36529840	call_user_func_array ( )	../SF_FormPrinter.php:1945
14	0.5858	36530552	SFFormInput::getHTML( )	../SF_FormPrinter.php:1945
15	0.6045	37406208	SFTextAreaInput->getHtmlText( )	../SF_FormInput.php:367
16	0.6045	37406208	SFTextAreaInput->getTextAreaAttributes( )	../SF_TextAreaInput.php:232
17	0.6045	37406288	WikiEditorHooks::editPageShowEditFormInitial( )	../SF_TextAreaInput.php:155

and while I am at it, this would be a second error that I am getting right now:

Notice: Undefined property: SFTextAreaInput::$contentModel in /home/ccc/htdocs/w/extensions/WikiEditor/WikiEditor.hooks.php on line 148
Call Stack
#	Time	Memory	Function	Location
1	0.0002	260240	{main}( )	../index.php:0
2	0.0517	6524496	MediaWiki->run( )	../index.php:46
3	0.0517	6524952	MediaWiki->main( )	../MediaWiki.php:435
4	0.0526	6589784	MediaWiki->performRequest( )	../MediaWiki.php:584
5	0.0541	6648136	SpecialPageFactory::executePath( )	../MediaWiki.php:275
6	0.0549	6723632	SpecialPage->run( )	../SpecialPageFactory.php:584
7	0.0549	6723712	SFFormEdit->execute( )	../SpecialPage.php:363
8	0.1162	13001448	SFFormEdit->printForm( )	../SF_FormEdit.php:43
9	0.1267	14498080	SFAutoeditAPI->execute( )	../SF_FormEdit.php:88
10	0.1280	14518384	SFAutoeditAPI->doAction( )	../SF_AutoeditAPI.php:116
11	0.1393	15468680	SFFormPrinter->formHTML( )	../SF_AutoeditAPI.php:877
12	0.3653	20338016	SFFormPrinter->formFieldHTML( )	../SF_FormPrinter.php:1422
13	0.3717	20342088	call_user_func_array ( )	../SF_FormPrinter.php:1945
14	0.3717	20342800	SFFormInput::getHTML( )	../SF_FormPrinter.php:1945
15	0.3892	21217184	SFTextAreaInput->getHtmlText( )	../SF_FormInput.php:367
16	0.3892	21217184	SFTextAreaInput->getTextAreaAttributes( )	../SF_TextAreaInput.php:232
17	0.3892	21217264	WikiEditorHooks::editPageShowEditFormInitial( )	../SF_TextAreaInput.php:155

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