Extension talk:Page Forms/Archive January to February 2013

Forms in "values="

I try to get a selection in a dropbox, build by #ask and set by template.

Working with a template works for me with "default={{Date}}", before I found the option "now".

So I define "values={{Result}}", but even $argvalue is set and passed the recursive-parser (as I testet), I still get the string "{{Results}}" in my selection.

Any ideas? --Letofred (talk) 10:56, 30 January 2013 (UTC)

That should work, I thought... what version of SF are you using? Yaron Koren (talk) 14:17, 30 January 2013 (UTC)

(Version 2.5.1) - I don't understand, why it's not working - as far as I can see, it should. --Letofred (talk) 15:26, 30 January 2013 (UTC)

If I place my "{{Results}}" anywhere else within the {{{for template|.}}} ... {{{end template}}} the template get rendered the right way. Even If I replace the #ask with a constant string like "1, 2, 3, 4" it shows the "{{Results}}" in my selection.

I have no more ideas. --Letofred (talk) 16:00, 30 January 2013 (UTC)

Ah, now I remember - the "values=" parameter still doesn't parse its value (though it probably should), though there's a new parameter in version 2.5.1, "values from query=", to which you can add the "filter" part of an #ask query - i.e., something like "[[Category:People]][[First name::John]]". I don't know why it's not listed in the documentation yet. Anyway, you should try that. Yaron Koren (talk) 16:18, 30 January 2013 (UTC)

Thanks so far. I tryed it and seems to work the way you told. But I have to #ask for a property of an Internal Objekt. To send parameters to the query seems not to work. (tryed: [[Object::+]]{{!}}? MyProperty) - any ideas? --Letofred (talk) 20:39, 30 January 2013 (UTC)--

Oh, I see. That might not be possible, unfortunately. But can't you just do "values from property=MyProperty"? Yaron Koren (talk) 19:29, 30 January 2013 (UTC)

No, that doesn't work. To ask for a SIO you have to ask for the object-property and output the subtyp.

In my testcase I just want get propertys from the same site (maybe its not fine to search in editmode for propertys of the same unsaved site - but works through caching - and might be usefull if SF get the editsection-form ;-)

Anyway, even if the propertys might be on other sites, you might have other querys to do, which should not list in output and put into the selection. It might be difficult to get all the parameters into "values from query=" - this might be better solved by a template ;-)

If you find a solution or idea (primary for the template) - let me now! Thanks a lot. --Letofred (talk) 20:39, 30 January 2013 (UTC)

Did you actually try "values from property=MyProperty"? I still think it would work. Yaron Koren (talk) 20:46, 30 January 2013 (UTC)

I did. No results. Not with [[MyProperty::+]] and not with MyProperty. If I leave the [[Object::+]] nothing will be found. Sorry. --Letofred (talk) 21:03, 30 January 2013 (UTC)

That's too bad - I just tested it out, and "values from property=MyProperty" worked for me, on a property that's only held by internal objects. If you go the page "Property:MyProperty", do you see values there? Yaron Koren (talk) 22:01, 30 January 2013 (UTC)

"embed in field" for Internal Objects

As far as I see, Internal Objects can not embedded, cause you have to name the field. What for? The fields are also marked by "holds template". Therefor it could be possible to embed a complete Internal Object. Am I right?

--Letofred (talk) 10:56, 30 January 2013 (UTC)

Sorry, I don't understand the question. If by "embedded", you mean having multiple template calls in another template call, then... I actually don't see the connection to internal objects. Those go into templates; they're not a part of forms. Yaron Koren (talk) 14:20, 30 January 2013 (UTC)

You're right! As far as I understand, the great advantage of the embed-in-field is to store a multible property in a normal form. It just would be quite nice to enbed an Internal Object, which is defined with a "multible" Template, into an other form-template.

For example you could add a Internal Object like {{Person}} with the propertys LASTNAME, NICKNAME, BIRTHDATE (or something like that) in just one "normal" form-template for a project with more than one PERSON.

You may realise this by different normal form-templates in combination with a multi-template, but maybe this would be a quite nice idea for a futur version.

Did I explain it? Did I get the meaning of the embend-in-field? --Letofred (talk) 15:47, 30 January 2013 (UTC)

PS: Thank you for your fast reply ;-)

You can already do that - just put the #set_internal call in a template, and then, in the form definition, embed that template in another template. Yaron Koren (talk) 16:19, 30 January 2013 (UTC)

But you have to declare a fieldname in template name[field name], havn't you?

You might be able to store a lot of LASTNAMEs, NICKNAMEs & BIRTHDATEs by 3 different multible form-templates, wich embed the propertys in a different template, but lost the dependency (of the SIO). You can't find out, wich NICKNAME refers to the depending LASTNAME.

Am I right? For a single SIO it might be possible to store the propertys in a different template, but for a multible SIO I can't find the solution - just have to think it over --Letofred (talk) 20:56, 30 January 2013 (UTC)

It appears to me that you may not fully understand the difference between forms and templates, and how they work together - is that possible? Yaron Koren (talk) 22:03, 30 January 2013 (UTC)

No that's not the problem. But I got it! Just confuses the embend in field and holds template by it's meaning. Sometimes its usefull to read (and understand - if in different language) the whole documentation.

The way it's used to be, works fine and is a quite nice feature to store 2 or more multible properties in just one template.

Thank you for understanding! --Letofred (talk) 07:42, 31 January 2013 (UTC)

"embed in field" and Header Tabs

Yet another problem: According to <this> the forms for multiple fields seems to put befor definitions of "single"-fields ...

{{{for template|Test}}}
=Values=
{{{field|Values|holds template}}}
=Infos=
{{{field|Info|holds template}}}
=others=
{{{field|others|holds template}}}
{{{end template}}}

{{{for template|Values|embed in field=Test[Values]}}}
...
{{{end template}}}
{{{for template|Info|embed in field=Test[Info]|multiple}}}
...
{{{end template}}}
{{{for template|others|embed in field=Test[others]|multiple}}}
...
{{{end template}}}

... it apears to an empty Values-Header folled by a correct Info-Header and a others-header with the Value-Fields at the bottom. I assume the multiple ones are really "embed", the normal ones later in their definition.

placing the =Values= within the for template for Values seems to put the forms in the right header.

Still the multiple ones apears first: <Info><others><Values>

Any workaround available? --Letofred (talk) 19:28, 31 January 2013 (UTC)

The fact that the "Values" template is not multiple-instance might be causing problems; I don't know how well embedding works for single-instance templates. Yaron Koren (talk) 20:19, 31 January 2013 (UTC)

Seems to work fine. I used this way, cause I would put all existing templates in one, without renaming all entrys on existing sites or templates. It's just a cool feature SF put all "old" Templates in the new one.

It even makes sence to use this to group some propertys (like in my case for chemical propertys, physical propertys, warnings and so on - pure chemikal elements may have both forms & templates, mixtures like solutions may not have chemical propertys like protons, electrons and so on) - you may use the same template for infoboxes and setting propertys for both categories.

As you assumed: If I set Values to multiple, the order is correct. But you may understand, thats a "dirty" solution - I don't want the user to config two chemical propertys. (Maybe if I disable the Add-Button by Css - but dirty anyway)

Maybe you find a way to fix this in a further version or you have another idea - let me know. --Letofred (talk) 21:59, 31 January 2013 (UTC)

Indeed your placeholder for Values can be found in HTML - it seems not to be replaced, because it's not multiple - to much code (thought of something around line 1460 in SF_FormPrinter) - maybe you can tell me, where the decision is made not to replace it (and offer a solution). --Letofred (talk) 23:15, 31 January 2013 (UTC)

Well, short of fixing the SF code, I would think the easiest solution is to just merge the "Values" template stuff into the "Test" template - so that no embedding of calls is needed. Yaron Koren (talk) 16:18, 1 February 2013 (UTC)

Make restricted fields only editable by sysop

Hey, I was wondering if there was a way to make the restricted fields in a form only editable by sysops, and not for regular logged on users. Right now it only removes editing for Anonymous users. Thanks

Oh, and just curious if there was an ETA of the new semantic forms version?

The restricted parameter by default limits to sysop. If regular users are able to edit restricted fields, then they probably have the editrestrictedfields right (can verify in Special:ListGroupRights). Kodene (talk) 22:10, 3 January 2013 (UTC)

There's no ETA on version 2.5.2 of SF, by the way, but hopefully in the next month or two. Yaron Koren (talk) 23:23, 3 January 2013 (UTC)

Different values for "value" and "label" in <option> tags?

Hi Yaron, is there any way to have a listbox get generated with different values for the "value" and "label" attributes of an <option> tag? For example, in a bug tracking application that automatically generates page titles such as: BUG-0001, BUG-0002, etc. Each page has a "short description" property and a list of "related bugs" which point back to the bug page titles. The select list right now can easily be created to render with the page titles like this:

<option value="BUG-0001">BUG-0001
<option value="BUG-0002">BUG-0002
<option value="BUG-0003">BUG-0003

However to the user seeing "BUG-0001" in the list isn't really helpful - it would be great if we could display the short description in the label as well, but keep the value strictly to the page title, like so:

<option value="BUG-0001">BUG-0001: NullPointerException when entering foo
<option value="BUG-0002">BUG-0002: OutOfMemoryError when bar
<option value="BUG-0003">BUG-0003: DivideByZeroError when bazz

Is this possible? If not I think this could be a really useful feature, perhaps by making use of a supplied template to generate the label? Arcarlucci (talk) 16:54, 4 January 2013 (UTC)

This is already possible, using a hack - see here. Hopefully there will be a less hack-ish way to do this in the future - ideally the aliases will be defined in the property page itself, so that the right value can be displayed when the regular page is viewed as well. Yaron Koren (talk) 19:46, 4 January 2013 (UTC)

Thanks Yaron! I took your example a step further and made a JSON web service call to the Ask API to obtain the description property of all the pages, and dynamically update each option. Arcarlucci (talk) 17:01, 7 January 2013 (UTC)

Confused about "values dependent on"

Hi Yaron. I think I'm confusing myself on how to use "values dependent on". I haven't been able to get it to work. As a test to try it out, I've done the following:

Property:CPUMake

[[Has type::String]]
 [[Allows value::Intel]]
 [[Allows value::AMD]]

Property:CPUModel

[[Has type::String]]

Template:CPU

<includeonly>
 [[CPUMake::{{{cpumake|}}}]]
 [[CPUModel::{{{cpumodel|}}}]]
 </includeonly>

Form:CPU

<noinclude>
 {{#forminput:form=CPU}}
 </noinclude><includeonly>
 {{{for template|CPU}}}
 {{{field|cpumake|property=CPUMake}}}
 {{{field|cpumodel|input type=combobox|values dependent on=CPU[cpumake]}}}
 {{{end template}}}
 </includeonly>

TestPage

[[CPUMake::Intel]]
 [[CPUModel::i3]]
 [[CPUModel::i5]]
 [[CPUModel::i7]]

I've even created pages with only a single CPUModel defined, but no matter what I do the cpumodel field never shows any values regardless of what I select in cpumake. Ultimately, I'm trying to get a 3 tier selection (where C "depends on" B "depends on" A) with finite values (users can't add new ones). I think I've confused myself on how this is supposed to work. Any insights? Kodene (talk) 17:47, 6 January 2013 (UTC)

I don't know - that seems like it should work. It could be that "values dependent on" only works if both fields are an autocomplete or combobox, as opposed to (I'm guessing) a dropdown for the first field in your case; I can't remember now. Yaron Koren (talk) 21:09, 6 January 2013 (UTC)

I've tried combox for the first field as well, still no dice. Odd thing is that on a whim I copied Template:CPU to Template:CPU2 and updated the cpumodel to point to CPU2[cpumake]. After that I got values appearing in the cpumodel field, but it shows all values set everywhere and doesn't limit based on the selection of cpumake. Guess I'll start going through the source and see if I can get a feel for what it's doing behind the scenes. Thanks for the quick reply. Kodene (talk) 05:30, 7 January 2013 (UTC)

SF 2.5.1 incompatibility with Bitnami Mediawiki 1.20.2 Ubuntu VMWare stack?

Hi,

Previously we were using SF 2.5.1 with a Bitnami MW 1.20.0 installation and everything seems to work.

Recently we migrated to a Bitnami MW 1.20.2 Ubuntu VMWare stack and are running SF 2.5.1 on it. Autocompletion on dropdowns now show for example 10+ instances of several previously entered property. For example, for a state property, we would see MA (previously entered on about 10 different pages) 10 times in the dropdown. Perhaps a problem with deduplication of previously entered values for the property?

A second problem relates to values depend on. On 1.20.0, things were working smoothly. We migrated over the exact template and forms from the 1.20.0 system to the 1.20.2 system and now it is broken as well. The values depend on 2nd field now show all possible values for the property to be triggered by a specific value in the first field. It worked fine in 1.20.0.

We tried reverting back to SF 2.4.2 on the new MW 1.20.2 system w/o any improvement. We also looked at the change log going from MW 1.20.0 to 1.20.2, thinking that perhaps one of the bug fixes affected SF but am unsure what to do. We would like to maintain the new 1.20.2 build and was wondering about potential solutions. Perhaps an alpha or beta version of SF that would be more compatible with MW 1.20.2?

Thanks,

Long

That's very strange. Was the only thing that changed the MediaWiki code, that went from version 1.20 to 1.20.2, or did the database change as well, and/or the code for other extensions? And what SMW version are you using? Yaron Koren (talk) 14:40, 10 January 2013 (UTC)

The first was a Bitnami MW 1.20.0 stack install onto a Ubuntu system running SMW 1.8 beta2. The second is a fresh Bitnami Unbuntu VMWare running MW 1.20.2 and SMW 1.8 final release. The two systems were independently setup except for a full copy over of the extensions folder and LocalSettings.php. Database updates were performed for extensions that require it (SMW, AbuseFilter, AntiSpoof, etc.). Could the difference in SMW cause this? -Long- 16:08, 10 January 2013 (UTC)

Yes, the upgrade of SMW seems like the much more likely culprit. In SMW 1.8, the entire database structure changed, along with a lot of the code. Not that that should have caused SF to fail, though. Just to clarify, does everything else with SMW seem to be working fine, other than forms? Yaron Koren (talk) 19:00, 10 January 2013 (UTC)

Even with SMW 1.8 beta2 vs. 1.8 final? We assumed it would not be a huge difference. Everything else seems to work fine with regard to SMW, including our heavy usage of subobjects. We modified subobjects to be similar to SIO in terms of syntax. We are puzzled why a pipe was chosen as a delimiter for subobjects compared to the the better choice of commas which is used in SIO. Essentially subobjects behave similarly to SIO in our system.

Is there a alpha or beta version of SF that is more compatible with SMW 1.8 final?

-Long- 19:14, 10 January 2013 (UTC)

Well, I think the big difference between those versions is that in the "final" 1.8, SQLStore3 (the new database structure) became the default setting - that's why you had to update the database (I think). This isn't a public wiki by any chance, is it? As for subobjects and SIO - this isn't really the place to discuss it. :) Yaron Koren (talk) 20:53, 10 January 2013 (UTC)

Any easy workaround for that? We mostly care about correct unique presentation of autocompletion elements, values depend on, and autoediting functions in SF. -Long- 21:26, 10 January 2013 (UTC)

Well, it's hard for me to diagnose a fix if I can't see the problem, unfortunately. I'm guessing this isn't a public wiki, then. Is there any way I can get access to it? Yaron Koren (talk) 17:06, 11 January 2013 (UTC)

So I changed the SMW backend to SMW_SQLStore2 using SMW_setup.php on a clone of the VMware. SF appears to work. Now I need to decide whether to run in SMW_SQLStore2 vs. SMW_SQLStore3. When will the next version (I am interested in even alpha or beta) of SF be out that would be compatible with SMW_SQLStore3? If just 1-2 months we may bear with the issues we have now. If 6 months or so, we may go with SMW_SQLStore2 to get full functionality. Thanks for all your help. Longphile (talk) 07:00, 15 January 2013 (UTC)

Hi - well, SF is currently mostly compatible with SQLStore3 - the only thing that doesn't work, as far as I know, is remote autocompletion. On the other hand, these issues of yours do sound like problems in SF, assuming that everything else is working fine for you with SQLStore3. I can't really guarantee a date by which any particular bug will be solved, but getting SF to work fully with SQLStore3 is definitely a priority for me. Yaron Koren (talk) 22:51, 15 January 2013 (UTC)

SQLStore3 is working for us except for this bug: [1]. SF2.5.1 for us is not fully functional with SQLStore3. Autocomplete pulls in all instances for certain properties and does not deduplicate into a unique list. In addition, radiobuttons are presented with 10+ copies of a particular choice even though there are only two unique choices. Value depends does not work either. We will eagerly wait for the next SF version then. Thanks for your help. Longphile (talk) 09:39, 16 January 2013 (UTC)

Example links are currently not helpful

Most links to examples on discoursedb.org are useless because they block editing from anonymous users.

In mw:Extension:Semantic_Forms/Defining_forms#.27field.27_tag within the show on select text there is a link to http://discoursedb.org/wiki/Special:FormEdit/Source/Some_Source saying "for an example of this feature in use (note what happens when you select different values for the "Publication type" dropdown),". But its not possible to test it, because all input controls are disabled.

Please find some other wikis for linking examples to.--HMichael (talk) 16:35, 10 January 2013 (UTC)

Sorry about that - I had changed the settings in Discourse DB in order to test out a feature, but forgotten to change them back. It's fixed now. Yaron Koren (talk) 16:48, 10 January 2013 (UTC)

Text Input Field Size

Hi, I've noticed that text input fields are displaying as different widths in different browsers. This stems from the fact that browsers implement <input size=X> inconsistently. I'd like to solve this problem by adding a width attribute to the <input> tag. This overrides the size setting in the browsers I've tested. However I don't know enough to actually make this change in SemanticForms. Would someone be able to point me toward how to add a width argument to the {{{field}}} call that will end up setting style="width:X" in the html? Or is there a better solution to this problem? Part of the reason the field widths matter so much for me is that I want to have links immediately following fields to collapse them. Here is an example of what I'm working with. Thanks for any help! -- Mw.clearish (talk) 19:12, 16 January 2013 (UTC)

You can use the "class=" parameter to set the HTML class, and then add the appropriate CSS for that class elsewhere, like in the page MediaWiki:Common.css. Yaron Koren (talk) 16:30, 17 January 2013 (UTC)

Cool, thanks! That's a much cleaner solution than I'd been imagining. -- Mw.clearish (talk) 16:44, 17 January 2013 (UTC)

independent fancybox upload window

Hi Yaron,

Sorry for the possible off-topic question. Is there any way I can get the fancy box upload windows to work independently of semantic forms? Loaded all semantic forms scripts and css into resource loader (and I mean all), added the classes sfFancyBox and sfUploadable into "upload" link, added this: $wgEditPageFrameOptions = 'SAMEORIGIN'; but still the upload window opens like an "unfancy" normal page Any tip would be greatly appreciated!

That seems like it should work... I would add "&debug=true" to the URL, and look at the page with Firebug or Chrome, to see if any errors appear in the Javascript console. Yaron Koren (talk) 01:26, 20 January 2013 (UTC)

Finally got it to work (was totally my fault - didn't included all js scripts) Thanks so much Yaron!

Duplicate values in checkboxes when values are from a property

After upgrading to SMW 1.8 and to SQLStore 3, checkboxes in forms are displaying duplicate of values WHEN their values are from a property.

You can see the problem here

Any idea ?

Thanks

Nicolas NALLET (talk) 20:39, 19 January 2013 (UTC)

This sounds like the same bug that Longphile was describing, above - I guess this will need fixing in SF. Yaron Koren (talk) 01:27, 20 January 2013 (UTC)

Yes this sounds like the same SF bug we saw with SQLStore3. It occurs with checkbox, radiobuttons, or dropdown. Longphile (talk) 21:56, 26 January 2013 (UTC)

I finally looked into this, and found a solution: the issue is a bug in SMW itself. I added a suggested patch in the sixth item, here. Yaron Koren (talk) 22:35, 19 February 2013 (UTC)

Major bug in Special:RunQuery Special:Ask

Hi Yaron. I'm using Special:RunQuery to crawl through 7000+ bibliographic records. Recently, having upgraded to SMW 1.8, I noticed that Special:RunQuery is missing a lot of results that should have been there. With some further testing it appears that it's always the last part of the string (still under 255 characters) that is ignored by the query. I can't give you precise figures, but it looks as if only the first 60 characters or so are queried. Note that I'm not sure if this behaviour is a recent issue related to SMW 1.8 or SF 1.5.1 - it's only now that I've become aware of it. User:Cavila ^{MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.8, SF 1.5.1} (talk) 09:35, 21 January 2013 (UTC)

Actually, the same problem occurs with Special:Ask, so at its heart, this bug is a SMW issue (not SF). Cavila ^{MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.8, SF 1.5.1} 10:10, 21 January 2013 (UTC)

Yes, I think in SQLStore3 properties of type "Text" can only be queried on their first 60 characters, but - is that worse behavior than what was there before? I thought that in previous versions, you couldn't query on "Text" properties at all - only display them. (And yes, this is not an SF issue.) Yaron Koren (talk) 13:57, 21 January 2013 (UTC)

Actually, it happens with properties of type "String" and the first characters that are queried may be even fewer than 60. But yes, it's SMW - the bug has been reported to Bugzilla. Cavila ^{MW 1.19.2, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.1} 08:39, 22 January 2013 (UTC)

Hidden default text?

Is there any way to hide the default text that appears in the textarea? I'm applying a timestamp to each new table and when my users click on 'Add Another' (it's a multi-instance template) I don't want them to be able to see that text already in the box. Example code: {{{field|Remarks|default=timestampcodegoeshere}}}

This generates a 'Remarks' textbox with the timestamp code in it by default, but I don't want the timestamp code to be visible in the box, I just want it to appear blank and the user types in their remark but then after clicking Save Page it has the timestamp along with the remark. I've tried typical things like <span style="visibility:hidden;">default=timestampcodegoeshere</span> and the like, nothing seems to work. Grimes (talk) 21:37, 31 January 2013 (UTC)

I don't think that's possible. It seems like you're using SF for a comments section, by the way - why not use dedicated software for that, like LiquidThreads? Yaron Koren (talk) 02:40, 4 February 2013 (UTC)

Creating article with form

Hi,

I try to create a page using a form. On the form I just want to the user to write his name, date and and a couple more compulsory information. Then when the user saves, I want a page automatically generated with the information he entered on the form + a predetermined layout (with a logo, pre format..etc). I managed to create this form and when the button saved is pressed then a page is created in addition to the logo and other pre format. Now the problem I have is that if I press on "edit" button on the created page I cannot manually modify what is written. Is there a way? I think I basically want to copy a template on my page and have access to what is actually written instead of the template call.

Thanks.

I don't understand - why can't you edit the information? Yaron Koren (talk) 02:42, 4 February 2013 (UTC)

Comments in default text?

Hi, is there a way to have default text contain a comment? I tried the following but the < and > become &lt; and &gt;.

{{{standard input|free text|default=Here is some text. <!-- And here is a comment. -->}}}

Thanks for any help! -- Mw.clearish (talk) 04:07, 3 February 2013 (UTC)

That seems like a bug. You might have better luck using "preload=" instead, though. Yaron Koren (talk) 02:44, 4 February 2013 (UTC)

Ah thanks, "preload=" worked. -- Mw.clearish (talk) 04:01, 4 February 2013 (UTC)

Double clicking submits multiple forms

Is there any way to modify the {{{standard input|save}}} element (or something else) to help my I-think-I-have-to-double-click-everything-to-make-things-work users? I recall this being possible when defining form elements from scratch. Anything like it in SF? Thanks! - Lbillett (talk) 12:23, 7 February 2013 (UTC)

No, there's no way to do that, unfortunately. I assume you're using the one-step process, with an automatically-generated page name? Otherwise, it shouldn't matter if the user saves the page more than once. Yaron Koren (talk) 15:38, 7 February 2013 (UTC)

Ah, yes. The form is a one-step that generates a new article w/ name on each submit. It's not a huge problem, but it makes for weird entries in the log sheets that have to be deleted. I'll just put a reminder beside the submit button to not double click it. Guess it's true what they say. You can make something fool proof, but you can't make it damn-fool proof. Thanks for the help. - Lbillett (talk) 16:00, 7 February 2013 (UTC)

Set property for order of multiple instance forms

Is there a way to set a property for the order of a multiple instance form? I need to be able to query for the data (set by a Semantic Internal Object) then order it in the same way the user ordered it. Sometimes it comes in the same order, sometimes it does not.

I just thought as I was writing this: can I sort by the semantic internal object name? I'll try this later today and let you know how it works out.

--Jamesmontalvo3 (talk) 18:40, 11 February 2013 (UTC)

So that didn't work. Sorting by the Internal Object property name gave me the order:

• Page Name#7
• Page Name#13
• Page Name#2
• Page Name#8
• Page Name#3
• Page Name#9
• and so on

Furthermore, I realized if it did "work" it would have sorted like 1,10,11,13,2,3,4,5,6,7,8,9 since it's alphabetical. So any suggestions? --Jamesmontalvo3 (talk) 22:25, 11 February 2013 (UTC)

Solution to my own problem: My solution to this problem was to modify SemanticForms.js as shown below...Yaron, let me know if I've done something terrible. I've marked each changed line with "//Jamesmontalvo3: description of change". Basically I defined a method "indexMultipleTemplate" which is called whenever a new template instance is added, removed or moved. When called it updates the value of a field of class "multipleTemplateIndex" within each template, in ascending order. Unfortunately it appears you cannot add a class to hidden elements in Semantic Forms, so instead my field looks like:

<div style="display:none;">{{{field|Index|class=multipleTemplateIndex}}}</div>

Changes to SemanticForms.js, starting at about line 965:

/**
 * Initialize all the JS-using elements contained within this block - can be
 * called for either the entire HTML body, or for a div representing an
 * instance of a multiple-instance template.
 */
jQuery.fn.initializeJSElements = function( partOfMultiple ) {
    this.find(".sfShowIfSelected").each( function() {
        jQuery(this)
        .showIfSelected(true)
        .change( function() {
            jQuery(this).showIfSelected(false);
        });
    });

    this.find(".sfShowIfChecked").each( function() {
        jQuery(this)
        .showIfChecked(true)
        .click( function() {
            jQuery(this).showIfChecked(false);
        });
    });

    this.find(".sfShowIfCheckedCheckbox").each( function() {
        jQuery(this)
        .showIfCheckedCheckbox(true)
        .click( function() {
            jQuery(this).showIfCheckedCheckbox(false);
        });
    });

    this.find(".remover").click( function() {
        // Remove the encompassing div for this instance.
        jQuery(this).closest(".multipleTemplateInstance")
        .fadeTo('fast', 0, function() {
            jQuery(this).slideUp('fast', function() {
                jQuery(this).remove();
            });
        });
        jQuery(this).indexMultipleTemplate();  //jamesmontalvo3: call indexMultipleTemplate when removing an element
    });

    this.find('.autocompleteInput').attachAutocomplete();
    this.find('.sfComboBox').combobox();
    this.find('.autoGrow').autoGrow();
    this.find('.sfFancyBox').fancybox({
        'width'         : '75%',
        'height'        : '75%',
        'autoScale'     : false,
        'transitionIn'  : 'none',
        'transitionOut' : 'none',
        'type'          : 'iframe',
        'overlayColor'  : '#222',
        'overlayOpacity' : '0.8'
    });

    // @TODO - this should ideally be called only for inputs that have
    // a dependent field - which might involve changing the storage of
    // "dependent fields" information from a global variable to a
    // per-input HTML attribute.
    this.find('input, select[class!="sfComboBox"]').each( function() {
        jQuery(this)
        .setAutocompleteForDependentField( partOfMultiple )
        .blur( function() {
            jQuery(this).setAutocompleteForDependentField( partOfMultiple );
        });
    });
    // The 'blur' event doesn't get triggered for radio buttons for
    // Chrome and Safari (the WebKit-based browsers) so use the 'change'
    // event in addition.
    // @TODO - blur() shuldn't be called at all for radio buttons.
    this.find('input:radio')
        .change( function() {
            jQuery(this).setAutocompleteForDependentField( partOfMultiple );
        });
}

//jamesmontalvo3: defined indexMultipleTemplate, finds fields of class 
//multipleTemplateIndex within a multipleTemplateWrapper and gives them
//an incrementing value
jQuery.fn.indexMultipleTemplate = function() {
    this.closest(".multipleTemplateWrapper").find(".multipleTemplateIndex").each(function(index,element){
        $(element).val(index);
    });    
}

var num_elements = 0;

// Once the document has finished loading, set up everything!
jQuery(document).ready(function() {
    jQuery('body').initializeJSElements();

    jQuery('.multipleTemplateInstance').initializeJSElements(true);
    jQuery('.multipleTemplateAdder').click( function() {
		jQuery(this).addInstance(); 
		jQuery(this).indexMultipleTemplate(); //jamesmontalvo3: call indexMultipleTemplate when adding an element
	});
    jQuery('.multipleTemplateList').sortable({
        axis: 'y',
        handle: '.rearrangerImage',
        stop: function ( event, ui ) { jQuery( ui.item ).indexMultipleTemplate(); }  //jamesmontalvo3: call indexMultipleTemplate when moving an element
    });


    // If the form is submitted, validate everything!
    jQuery('#sfForm').submit( function() {return validateAll();} );
});

--Jamesmontalvo3 (talk) 05:36, 12 February 2013 (UTC)

Hi - this is great! People have been asking about being able to have an "index" field for a long time. I should note that, in your case, it's not 100% necessary, since you can in fact sort on the internal object name, and if you use version 0.7.1 or later of SIO, the sorting will work correctly for up to three digits. However, if you were to also upgrade to version 1.8 of SMW, then sorting would once again not work, since SIO will call #subobject, which just assigns a random number to each row. I think the ideal solution is to create a new parameter, probably just called "index", that both hides the field and assigns the right class to it; so you could just have "{{{field|Index|index}}}". Feel free to try your hand at modifying the PHP to handle this; otherwise, I can look into it. Yaron Koren (talk) 13:34, 12 February 2013 (UTC)

I'm currently using SF 0.6.8, so that's my problem with the sorting issue. But that functionality will go away with upgrading SMW...so I guess I'll take a hack at modifying the PHP. It also might be a good idea to just put a javascript hook on the add/remove/move functions of the multiple instance form...so people could easily tap into it via common.js. Create an onchange event of sorts. --Jamesmontalvo3 (talk) 17:15, 12 February 2013 (UTC)

"Save and continue" does not work with embedded query forms

Hi Yaron. As you may or may not know, it's perfectly possible to embed a query form in MW:Sitenotice, so that one or multiple semantic search boxes can be an integral part of the user interface. Which is obviously great. However, I noticed that doing so also causes a conflict (jquery?) with the "Save and continue" button when a semantic form is loaded. This button then remains greyed out (unresponsive to further changes), and so will not work. The reason, by the way, why this is important to me is because changes are sometimes lost using the standard "save" button. Cavila ^{MW 1.19.2, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.1} 23:42, 11 February 2013 (UTC)

MobileFrontend compatibility

I have a wiki with a form. I just installed MobileFrontend, and the form appears blank on the mobile version. Is there a compatibility issue between these extensions? it would be really useful to have forms to my mobile users as well. You can see this here http://wiki.red-fans.com/index.php?title=%D7%9E%D7%99%D7%95%D7%97%D7%93:RunQuery/Gamesearchfoot&useformat=mobile

I'm using MW 1.18.0, SMF 2.3.2, SMW 1.6, PHP 5.3.10. Thank you Osishkin (talk) 15:32, 17 February 2013 (UTC)

Hi - I don't know what the issue is; I've never tried using SF with MobileFrontend, and I haven't heard of anyone else trying it yet either. If you try running this form as a "normal" (non-query) form, does it work? In other words, does this URL work? Yaron Koren (talk) 23:52, 17 February 2013 (UTC)

No, it doesnt. I've used the Item form example to test this, and as you can see here it doesnt work. It's a shame, mobile traffic is growing in my wiki (and generally). I hate seeing a useful feature relying on Semantic Forms being inaccessible for 30% of my visitors Osishkin (talk) 13:45, 21 February 2013 (UTC)

Multiple instance template in multiple instance template

I have defined a few templates which should have the possibility of multiple occurences. I have embedded these in a main template called Run. This all works fine until I want to have multiple instances of this Run template in one form. The underlying code is changed but visually I do not see any new fields for entry. Is there any way to achieve this?

I don't think so. Yaron Koren (talk) 13:16, 18 February 2013 (UTC)

Thanks for your response. We shall find another way

FormStart doesn't forward/redirect

I'm having an issue with my installation of Semantic Forms, when a user goes to the form page (ie Form:My_New_Form) and enters the page name they are redirected to Special:FormStart?page_name=Test&form=MyForm and the process stops there, the information is correctly inserted into the URL but the user is then not forwarded to Special:FormEdit/My_New_Form/:Test to fill in the form. If the information is filled in again on the Special:FormStart page then they are taken to Special:FormEdit.

From the documentation I assume this isn't by design and it doesn't appear to occur on any of the other wiki's using Semantic Forms I've since tried, apologies if this is mentioned some where in the documentation I've done my best to attempt to find a resolution before posting here. MediaWiki: 1.18.1, Semantic Forms 2.5.1, Semantic MediaWiki 1.8.0.1. Thanks for any help --NachoDuck (talk) 13:02, 20 February 2013 (UTC)

Hi - no, I haven't heard of this problem happening elsewhere. My guess is that it's a Javascript problem; see the 5th item here for how to see the error message, if there is one. Yaron Koren (talk) 14:04, 20 February 2013 (UTC)

Thanks for the swift reply. I've tried the instructions from that page with the debug option on both the Form page and FormStart page but the console remains blank on both Firefox and Chrome, as the article suggests it could be caused by extensions of a modified skin I tried disabling all the extensions I had other than the Semantic MediaWiki ones and tried it on a skin I haven't applied any custom styles to but the same thing happens. I've tested it on a test Wiki I have which is on a later version (although I don't think it makes any difference) and the form works so it must be a problem with how this one is setup although I'm not sure what exactly could be wrong with it, unless you have any ideas yourself? Thanks again for the help so far --NachoDuck (talk) 16:56, 20 February 2013 (UTC)

I assume this isn't a public wiki? If not - is there any unusual punctuation in either the form or page names? Yaron Koren (talk) 17:28, 20 February 2013 (UTC)

Correct it's an internal wiki so it's not open. The only odd thing I've noticed about the page names is that when I move forward from the FormStart page the FormEdit page has a URL ending like this Special:FormEdit/My_New_Form/:Test01 notice the colon after the form name, this doesn't appear on my test wiki where you are correctly redirect from the Form page, or any of the others I've tried. I didn't set the wiki up initially so I'm not sure if there has been a setting added that would cause this but I'll have a look through my LocalSettings.php. Thanks for your help so far --NachoDuck (talk) 08:31, 21 February 2013 (UTC)

Managed to get around to looking at this today, it turns out the short URL rewrite rules had been incorrectly configured. Since I've updated this to the recommended configuration the redirect on form creation is now working. Apologies for wasting your time on this Yaron and thanks for the help you provided anyway --NachoDuck (talk) 12:34, 25 February 2013 (UTC)

No problem - I should have guessed URL rewriting, actually, since I've seen that cause other problems with form handling. Yaron Koren (talk) 14:18, 25 February 2013 (UTC)

Embedding the same template in more than one field

I'm trying to embed the same template ('Person') in two fields ('Officers' and 'Soldiers') of 'Crew' template:

{{{for template|Crew}}}
{{{field|Officers|holds template}}}
{{{field|Soldiers|holds template}}}
{{{end template}}}

{{{for template|Person|multiple|label=Officers|embed in field=Crew[Officers]}}}
...
{{{end template}}}

{{{for template|Person|multiple|label=Soldiers|embed in field=Crew[Soldiers]}}}
...
{{{end template}}}

I can create page, add values to fields and save page. Saved page looks as it should - both fields have values as defined in form. But when I try to edit this page with form again, all calls of Person template are duplicated: whole list is linked to each field. For example,

{{Crew
|Officers={{Person|1}}{{Person|2}}
|Soldiers={{Person|3}}{{Person|4}}{{Person|5}}
}}

after editing with form and saving:

{{Crew
|Officers={{Person|1}}{{Person|2}}{{Person|3}}{{Person|4}}{{Person|5}}
|Soldiers={{Person|1}}{{Person|2}}{{Person|3}}{{Person|4}}{{Person|5}}
}}

Is it bug or I miss something?

It works fine with different embedded templates. Will it help if I will make different template pages that redirect to 'Person'? Thanks

Yes, you can't embed the same template into more than one field, and yes, having one or both of these templates instead be a redirect template will probably fix the problem. Yaron Koren (talk) 14:30, 25 February 2013 (UTC)

Making redlinks in the main namespace (NS_MAIN) use a form

You just have to edit Project:<NS_MAIN> and define a default form there. You can get the name of NS_MAIN in your wiki's language by going to MediaWiki:sf_blank_namespace