Extension talk:Page Forms/Archive June to August 2015

Code of "special:CreateCategory

Hello there,

at the moment i want something like the "special:createcategory" page, but which creates a category which has to be a subcategory of a category of a certain category tree. Preferably without the option to choose a form for it.

Using a form, it would be something like: {| class="formtable" ! subcategory: |{{{field|subcategory|input type=tree|top category=Knowledge|depth=1 }}} |}

The problem with forms is that it creates pages, and not categories. How could i do to create a "category creator" with my own restrictions?

Thanks.

A "category" is just defined by a page in the "Category:" namespace. Couldn't you just create a regular form like the one you describe, and use it to create "Category:" pages? Yaron Koren (talk) 18:14, 2 June 2015 (UTC)

A form which creates categories? How come? You can create categories with a form, indicating the page created with your form is member of a category, but is there a way to create a form which just creates categories? Maiser(talk)

Modified form and template - duplicated data

Hello!

I created a few pages with a form, then I modified the form and the template (I added 5 properties to them in a table). Then on a page when I click on the edit with form button, enter the new inputs and click on save, the data is duplicated on the edited page. The first table doesn't have any values, the second table is filled out with the data I entered, and all other sections are duplicated too. Does anyone know how to solve this problem? 13:53, 5 June 2015 (UTC)

It sounds like you renamed the template at some point? If so, you can use the Replace Text extension to modify all the existing pages to use the new template name - or just edit them manually, if there aren't too many. Yaron Koren (talk) 18:10, 5 June 2015 (UTC)

Thank you for your quick response, but that's not the case, I didn't rename the template, I just added a few new properties to it. What else could be the problem? 13:24, 8 June 2015 (UTC)

It would help to see the form and template. Is this a public wiki? If not, could you pastebin them? Yaron Koren (talk) 14:02, 8 June 2015 (UTC)

Of course, though I've already found out what the problem was. This was the bad one: http://pastebin.com/mNVhqppy and this is the working one: http://pastebin.com/iF1HwA4K 14:19, 9 June 2015 (UTC)

Okay, great! Yaron Koren (talk) 14:50, 9 June 2015 (UTC)

Show on select on Multiple-instance templates

Hello!

I would like to ask the experts how can I use "show on select" when using multiple-instance templates.

If I use "show on select" it this way, it does not work

{{{for template|DescripciondelaRuta|multiple}}}
{| 
| {{{field|DuracionSeccionONOFF|input type=radiobutton|mandatory|default=Sí|show on select=Sí=>DuracionSeccionDiv}}}
|-
|<div id="DuracionSeccionDiv">{{{field|DuracionSeccion|input type=textarea}}}</div>
|}
{{{end template}}}

But if I remove the multiple instance, then the "show on select" works.

{{{for template|DescripciondelaRuta}}}
...
{{{end template}}}

Any hints?

Thanks in advance!

That should work... what versions of SF and MW are you using? And do you see any JavaScript errors if you look in the "console"? Yaron Koren (talk) 14:47, 9 June 2015 (UTC)

Thanks for your help Yaron, we really appreciate it .

I am using:

- Semantic Forms (Versión 3.2),

- Semantic MediaWiki (Versión 2.1.1),

- MediaWiki 1.22.15

I do not see any error in the console, though I am a begginer in this fields. Here's the link to our form just in case

You've definitely found some sort of bug in Semantic Forms - I'm looking into it. Yaron Koren (talk) 18:58, 15 June 2015 (UTC)

I believe I've fixed this issue, in Git - if you try out the new code, please let me know if it worked for you. Yaron Koren (talk) 19:05, 16 June 2015 (UTC)

I upgraded to the new SemanticForms (3.3) and it worked!, Yaron Koren you are a genius and super hiper helpful. Thanks! 21:40, 20 June 2015 (UTC)

That's great to hear! Yaron Koren (talk) 12:37, 21 June 2015 (UTC)

missing icons in multiple form

hi there, using sf 3.2 and mw 1.23.9: the multiple form doesn't show the icons for new instance and delete instance. Same problem in firefox (v38) and ie (v9). What to do? File:Missing icons.png

Is this a public wiki? If not - I'm guessing that this is a file permissions issue. The "delete instance" icon, for instance, should be viewable from the browser at /extensions/SemanticForms/skins/SF_remove.png in the wiki directory, like here. Can you see it on your wiki? If not, you probably need to make one or more of those directories world-readable. Yaron Koren (talk) 12:57, 15 June 2015 (UTC)

Thanx for your advise; we use a central directory, were we save all extensions to simplify administration, because we have a lot of wikis on our server. I've made a directory extensions/SemanticForms/skins and put the .png into - works. Very fine.

Is it possible, that you use absolute path instead of relative path, to fetch the icons? Maybe you can change it, it might be more comfortable to administrate extensions for lots of wikis. Thank you.

No, the icons are already included with a relative path, from the file /skins/SemanticForms.css. Yaron Koren (talk) 17:20, 15 June 2015 (UTC)

Special Pages: Create Template...

Hi Yaron - I'm finding that when I try to create a template, the properties combobox will populate only for the first field, but the succeeding ones do not. Is there a "fix" for this? Thanks again for all your work with Semantic Forms. Dmlddsoms (talk) 15:16, 13 June 2015 (UTC)

What do you see in the additional ones? Yaron Koren (talk) 12:58, 15 June 2015 (UTC)

The combo-box is empty upon drop down, whereas in the first field, it's completely populated. Dmlddsoms (talk) 14:22, 16 June 2015 (UTC)

What versions of SF, MW and SMW are you using? And do you see any error messages in the JavaScript "console"? Yaron Koren (talk) 18:29, 16 June 2015 (UTC)

MW 1.23.9, SB 1.9.2, SMW 1.9.2 SF 2.7. I'm going to claim ignorance on the JavaScript "console"...Dmlddsoms (talk) 01:46, 20 June 2015 (UTC)

Ah, you're using the version of Semantic Forms from Semantic Bundle. I don't know if I can help with that - it's an old version. You could always upgrade SF manually... or just wait for the next SB. Yaron Koren (talk) 12:36, 21 June 2015 (UTC)

Ok, thanks.Dmlddsoms (talk) 13:22, 23 June 2015 (UTC)

Create a form with multiple input fields

Hey, like I wrote above, I would like to create a forminput with multiple input fields. I want to do
that because our workers always mess up the form Name and put in to many spaces 
or delete the commas. I hope you understand what I mean, if not I try to explain it better with this:
Currently our Forminput looks like this
{{#forminput:Installation|70|Installation: Ort,Projektname,Rechner1}}
and after that comes the rest of the form.
Now this is only one input row, and I want three input rows where each contains a part of the title.
Ort:
Projektname:
Rechner:
If it stays like this our workers keep messing up the title names and sometimes the names are full of underlines.
Sorry for my bad english, if there is something not clear I try my best to edit it.

So, this is what I already wrote on the Semantic Mediawiki Talk Page but they sent me over here. They also said I should try the info Tag but somehow I cant get it to work.

When I put this in my code: {{{info|page name=Installation: <Installation[Ort]> <Installation[Projektname]> <Installation[Rechner]>|add title=Installation erfassen|edit title=Installation bearbeiten}}}

It only prints out what is in the first bracket: page name=Installation: <Installation[Ort]> <Installation[Projektname]> <Installation[Rechner]>

Hopefully someone can help me out with this problem.

Make sure that you are going to the form with #formlink, not #forminput - that might be the issue. Alternatively, instead of the whole page name formula thing, you could try the AssembleFormLink extension - it's still experimental, but it is what you're asking about. Yaron Koren (talk) 12:53, 18 June 2015 (UTC)

New Features

Hi Yaron,

I’m very excited about SF 3.x. In combination with SMW and MediaWiki this is the most powerful knowledge management platform in the world. Thank you very much for your enthusiastic engagement.

I would like to ask you about some ideas:

• What about free2use parameters in forms? I.e. one could pass them to the form with query string=par1=val1 and so on. This would be very helpful for flexibilization and will reduce the number of forms needed.
• In SMW there is a significant difference beetween the notation [[device::server,client,notebook]] and [[device::server]], [[device::client]], [[device::notebook]].

For most of the users is it to difficult to discern, that this requires different requests, like {{#ask: [[device::~*client*]]}} using the first notation vs. {{#ask: [[device::client]]}} using the second.

What about a field type, which can take a comma separated list of values and save them in the second notation?

• #autoedit is a great feature; can you give it a new function like user or usergroup with which one can restrict the access to change values?

Hi - it's great that you like the system! I wish more people shared your opinion. :)

For #1 - I doubt that's doable. Remember that everything in a form has to go into a template - and those are even less flexible.

For #2 - do you know about #arraymap?

For #3 - a nicer solution might be to use the #ifgroup function from the RightFunctions extension, to only display the #autoedit button in the first place if the user belongs to the right group. Yaron Koren (talk) 14:03, 24 June 2015 (UTC)

Thanks for your quick support and hints, i'll try it next days.

For #1 - i only need it calling the form with #formlink or #forminput, maybe this will be doable?

Sorry, I don't understand. Yaron Koren (talk) 00:13, 26 June 2015 (UTC)

Ok, i'll try to explain:

{{#forminput: form=hardware|link text=new hardware item|query string=hardware[type]=printer&department=personal management&typeList=listOfPrinterTypes}}

{{#forminput: form=hardware|link text=new hardware item|query string=hardware[type]=clients&department=north-west-branch&typeList=listOfClientTypes}}

in both cases i use the form named hardware; the (free2use) parameter typeList should be used in values from property={{{typeList}}}

so it is possible to give the form different list types depending from the value of typeList

Second example:

same like above with another free2use parameter called typeDescription. Serves the user an information about correct data capturing for the defined type.

I tried it using the values you can give to the form with query string; in the example above using {{#ifeq: hardware[type] ...}}, but this doesn't work.

Ah, that makes more sense. I'm still not sure I fully understand, but - perhaps either "show on select" or "values dependent on" could help with this? Yaron Koren (talk) 14:08, 26 June 2015 (UTC)

1. Right, show on select can help, but every used div must be content of the form;
2. Right, but i tried to use values dependent on several times without success... It tried it with the example on discourseDB, too; even without success... :-(

SF Upgrade Errors..

Hi Yaron,

I upgraded SF and am getting errors on Edit with Form of existing pages, not with adding new.

Error is:

           ext.semanticforms.main: Error: Module ext.semanticforms.main has failed dependencies
           Prevent this page from creating additional dialogues

Dmlddsoms (talk) 13:56, 24 June 2015 (UTC)

There's a problem with multiple-instance templates that's happening for some people; I hope to have it fixed soon. Yaron Koren (talk) 14:04, 24 June 2015 (UTC)

Ok, thanks. Dmlddsoms (talk) 14:12, 24 June 2015 (UTC)

Hi again Yaron - has this error been resolved with 3.3.2? Dmlddsoms (talk) 15:10, 15 August 2015 (UTC)

I don't fully remember this error, but probably. Yaron Koren (talk) 23:43, 16 August 2015 (UTC)

Position of Form Fields and Template resp. to free text

Hello,

I am trying to setup a form to create new wikipages. Is it possible to have free text and form fields in a different order than wikipage text and template? What I am trying to do is the following:

Form: Free text input field in between other form fields:

{{{for template|Template}}}
{{{field|...}}}
{{{standard input|free text|...}}}
{{{field|...}}}

Wikipage: Template above the text:

{{Template
|...
}}
My text

However, I get the text above the template. Is it possible to change this?

Thank you for your help!

--82.83.211.13 21:48, 24 June 2015 (UTC)

No, I don't think you can have a free text input displayed between two fields of the same template. If you really wanted that kind of display, perhaps you could use CSS or JavaScript in some way to move the free text display up... Yaron Koren (talk) 19:53, 25 June 2015 (UTC)

Okay, thanks all the same! I'll come up with something. --82.83.217.225 21:38, 25 June 2015 (UTC)

Add unique number if user is not logged in

Hi everyone!

Is there a way to add a unique number to the page title only when the user is not logged in?

I use a form to let users add a rating for certain items. Currently, I have the following code at the top of the form to create the page name (passing the user (which is either the user name or "anonymus" if not logged in) and the item to be reviewed):

{{{info|page name=<Review[User]>/Review/<Review[Item]> <unique number;start=1>}}}

However, I only want to add the unique number if the user is not logged in.

As the help page stated that parser functions can be used in the "page name", I tried something like this (using the MyVariables extension, where CURRENTLOGGEDUSER returns either the user name or an empty string):

{{{info|page name=<Review[User]>/Review/<Review[Item]> {{#if: {{CURRENTLOGGEDUSER}}||<unique number;start=1>}}}}}

But when trying to save a new review I get an error stating that the page "..._}" cannot be saved. So I guess the if statement does not get resolved correctly...

Is there any other way to achive what I planned to do? Thanks! --145.253.178.241 12:48, 25 June 2015 (UTC)

If you remove "start=1", the unique number will only show up if the title is a duplicate. Maybe that's a good enough solution? Yaron Koren (talk) 19:59, 25 June 2015 (UTC)

Thanks for your suggestion. The aim was to prevent at least logged-in users from giving multiple reviews for the same item. I think that would still not work after removing the "start=1" . --145.253.178.241 06:49, 26 June 2015 (UTC)

Set a field value silently when using form for editing [Solved]

I'm trying to set a field to a known value when editing. I can do this easily when the form creates a new page with the default= option. However when using a different form to edit the article I can no longer do this (default= for a hidden field only seems to work on page creation). I tried setting the field as mandatory|values=myknownvalue|hidden but this doesn't have an effect either. I ended up making a normal mandatory field declaration with one value for values=. This has the desired effect except that I'd rather it not be displayed in the form! Ideas? - Lbillett (talk) 19:25, 3 July 2015 (UTC)

Ok, by the time I finished articulating my problem, I think I found a workaround. If you wrap the field tag in a <div style="display: none;">{{{field|fieldname|values=knownvalue|mandatory}}}</div> it will hide the whole input field but the form will set the field as specified. move along! - Lbillett (talk) 19:25, 3 July 2015 (UTC)

Dropdown Box?

I used to have a code that allowed you to pick a category from a dropdown box. This was with MediaWiki 1.19.4 and Semantic Forms 2.5.2 It looked like this:

{{{field|1|mandatory|input type=category|top category=2015 Logs|height=200|hideroot|use dropdown}}}

I'm working on a new wiki installation now, and it's my understanding that the category input type disappeared with Semantic Forms 2.7. I can use tree, but can't find any documentation about dropdowns. Did dropdowns also disappear? Is there a way to replicate what I was doing with this older installation?

--Aekki99 (talk) 23:40, 10 July 2015 (UTC)

Ah, "use dropdown", I forgot about that. I think the answer is no, unfortunately. Yaron Koren (talk) 19:32, 12 July 2015 (UTC)

This is my super duper sad face. Alas! Maybe it will show up in a future update. Thanks for the reply! --Aekki99 (talk) 22:31, 16 July 2015 (UTC)

That is sad... what's wrong with the "tree" input? Yaron Koren (talk) 15:43, 17 July 2015 (UTC)

Show on select on Multiple-instance templates ==> Edit with form

Hello !

I use "show on select" on multiple-instance templates and it does not work when I try to edit a page with the form (no problem during the creation of the page or when I remove the "multiple" parameter). My form allows to create recipes with multiple steps and the user has to choose a type of media on a dropdown with "show on select" :

{{{for template|Step|label=Step|add button text=New step|multiple}}}

{| class="formtable"
! Type: 
| {{{field|Type|mandatory|input type=dropdown|values=Screenshot,Video,Code|default=Screenshot|show on select=Screenshot=>screenshot;Video=>video;Code=>code}}}
|}

<div id="screenshot">
{| class="formtable"
! Screenshot: 
| {{{field|Image|uploadable}}}
|}
</div>

<div id="video">
{| class="formtable"
! Service : 
| {{{field|Service|input type=dropdown|values=youtube, dailymotion, vimeo, asciinema, slideshare, ted, teachertube|default=youtube}}}
|- 
! Video ID : 
| {{{field|Video}}}
|}
</div>

<div id="code">
{| class="formtable"
! Code : 
| {{{field|Code|input type=textarea}}}
|}
</div>

{{{end template}}}

When I try to edit with the form, the first instance appears normally (only the good "div" is displayed) but I can't change the type of media. On the following instances, all the "div" are displayed and I can't hide them changing the type of media.

I am using: - Semantic Forms 3.3 - Semantic MediaWiki 2.2.1 - MediaWiki 1.25.1

I don't see any JS error on the console.

Any help would be great !

Thank you in advance.

Try upgrading to SF 3.3.1 - the problem may or may not be fixed there. Yaron Koren (talk) 19:15, 16 July 2015 (UTC)

Thank you for the quick response, unfortunately the upgrade did not fixed the problem.

Alright. What do you mean by "I can't change the type of media"? You can't select a different value in the dropdown? Yaron Koren (talk) 15:42, 17 July 2015 (UTC)

I can select a different value but it has no effect on the hiding or displaying of the fields. You can see a page I have created with my form here. Feel free to edit it with form. Here are the form and the template.

Oops! It looks like the fix I put in actually made things worse for your wiki, due (I think) to your PHP configuration. I just checked in another fix; could you try updating again? Yaron Koren (talk) 14:56, 20 July 2015 (UTC)

Updating done, I don't see any change. Again, thanks for your help. Eliott B 17:35, 20 July 2015 (UTC)

Okay, thanks. That change did improve things but there was still an issue, which I think I fixed just now. Could you try updating again and see if it works now? Yaron Koren (talk) 17:20, 20 July 2015 (UTC)

It seems to work perfectly! Many thanks!

That's great! Yaron Koren (talk) 23:44, 21 July 2015 (UTC)

And thanks for this, whoever you are! I wasn't aware that "show on select" was even possible with multiple instances of a template. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 08:23, 22 July 2015 (UTC)

It even works with fields holding templates. Great! Eliott B 09:29, 22 July 2015 (UTC)

This was indeed a pretty big issue and thank you for your fix of 2015-07-20 which indeed works! The nasty thing about this bug was not just not showing the other fields on the second edit of the page but to also automatically removing the contents added via the multi-instance template in the first place at the time of the second edit. Thus I suggest doing a new release at your convenience rather earlier than later. Cheers --[[kgh]] (talk) 16:02, 27 July 2015 (UTC)

That's a good idea. Yaron Koren (talk) 17:48, 27 July 2015 (UTC)

Show on select on does not work on Semantic Forms 2.7

Hello!

Just to let you know that Show on Select does not work in Semantic Forms 2.7

I upgraded to version 3.3 and it did work immediately

Semantic Forms 2.7 is the version used in SemanticBundle 1.9.2 which was the last version in 10 july 2015

Good luck and thanks for this great extension

Duplicate checkbox ID using Tree Input

Bit of a difficult one to explain - I have a long tree and I've discovered that adding some entries early in the listing will automatically select later entries and submit these. Having used Google Chrome element inspector it seems to be because the hidden checkboxes IDs are being repeated further down the page (and if one checkbox in the tree is clicked it will automatically check its partner further down). I don't know how this works - I've looked at the source and there is an ins element that might have something to do with it... Any help, suggestions or otherwise appreciated.

Are there any duplicate values in the tree? Is this part of a multiple-instance template? And what version of SF are you using? Yaron Koren (talk) 23:43, 21 July 2015 (UTC)

thanks for your quick response. There are no duplicate values (the values are academic disciplines from the JEL classification scheme with unique prefixes). There is a multi instance template elsewhere in the form but not here. 3.3.1.

Well, there go all of my theories. :) Is this on a public wiki? If not, could you try to replicate the problem on a public wiki, like http://scratchpad.referata.com? Yaron Koren (talk) 01:10, 22 July 2015 (UTC)

I've put it at http://scratchpad.referata.com/wiki/Special:FormEdit/Study/Example_Study_(2015). The problematic field is JEL Disciplinary Classification(s). If you select for example A12: Relation of Economics to Other Disciplines it will automatically also add K2: Regulation and Business Law, seemingly because their corresponding checkboxes share an ID. A13 in turn shares with K3 etc etc. Please ignore the errors which I don't think are relevant (I use another extension to be able to embed links in my tool tips). Also, I assume you don't need to see my templates since the issue seems to correspond with how the form sends the data. Maybe I'm doing something totally wrong (hope so, that would be progress to know it!). I've also tested on a previous version of the wiki from a backup and the issue has been around from earlier SMW/MW/Semantic Forms versions. Really appreciate your help, and your fantastic free software.

Think I've found the issue and a fix - in SF_TreeInput.php (line 157) $key_id = str_replace( ' ', '-', "$key_prefix$index" ); means that you end up with checkbox ids of the form chb-Source[Discipline]key11113. However, that means a clash between, what are, for example, essentially key 1,1,1,1,3 and key 1,1,11,3. To resolve I've replaced that line with $key_id = str_replace( ' ', '-', "$key_prefix-$index" ); so each individual index is hyphenated, like chb-Source[Discipline]key-1-1-1-1-3 and chb-Source[Discipline]key-1-1-11-3. Please let me know if this is a sensible change or if it will break my wiki (I'm not an expert coder by any means)!

What you're saying seems reasonable... on the other hand, I can't actually see the problem you're talking about, on the Scratchpad wiki. Can you? (K2 is already pre-selected on that page you created, but you probably knew that.) Yaron Koren (talk) 13:15, 22 July 2015 (UTC)

I've deselected it now so no checkbox is selected. If you try to select just A12 and either save then edit or hit show changes you'll see that K2 is added as well. I'm not that keen to go out of step with the shipped Semantic Forms code, so would be great if you could acknowledge that I'm not going mad (or that I am doing something wrong which is more likely!). Thanks!

Oh, I get it - it's not that the other checkbox gets checked right away, it's that its value shows up when you submit the form. Well, both your diagnosis and your fix were spot on - I just checked in your fix, and it seems to be working a lot better now. Thank you! Yaron Koren (talk) 19:14, 22 July 2015 (UTC)

Create page based off form input

I am working on a project where it would be really useful to have the form set the target page based off user input in the form. Is there a way I can do that? Nunabas (talk) 15:07, 22 July 2015 (UTC)

What do you mean by "based off"? Yaron Koren (talk) 18:27, 22 July 2015 (UTC)

If I wanted to pick say a date, and location the resulting page title would be location/date as the page title, and then be able to fill in a template for the page content. Nunabas (talk) 10:23, 23 July 2015 (UTC)

Have you seen this section? It may be what you're looking for. Yaron Koren (talk) 13:50, 23 July 2015 (UTC)

Stop browser from 'focusing' on #forminput field after page load?

When loading a regular article that has a #forminput element on it, chrome seems to immediately put browser focus on it. In some cases this is ideal, but it also creates some un-desired cases in that the user's view can be immediately scrolled halfway down a page if there's a field there (when what they wanted to see was the top). Is it possible to adjust this behavior? IE9 does not do this, not sure if that helps identify the cause. - Lbillett (talk) 14:17, 30 July 2015 (UTC)

The focus was done on purpose, actually, in this change. I didn't think there would be a downside to it, but evidently there is. I guess this will have to be another parameter for #forminput. Yaron Koren (talk) 14:25, 30 July 2015 (UTC)

Ah, ok. It's not a big deal, I can move it up higher in my template so it output's earlier, or replace it with a #formlink process or something (just means one extra step, which in this case is totally fine). I'll probably do that. Cheers - Lbillett (talk) 14:33, 30 July 2015 (UTC)

Multiple instances: Removing edit buttons and dragging

Hello guys. I've looked through the archives and nobody seems to have wanted to do this before.

I have a page with 84 instances of a template. When editing with form, I dont want my engineers to be able to add/remove entries or drag them around, because the order corresponds to the order in a legal document. Is there any way to get rid of these features for this page/form only, without hardcoding the whole thing?

I've tried defining {{{for template|EssentialRequirementsEntry|multiple|strict|minimum instances=84|maximum instances=84}}} in the form as workaround. So far, the form is unimpressed and still lets me add more entires. SMW 1.6.2, SF 2.2.1 --212.103.80.194 08:18, 4 August 2015 (UTC)

I can't think of an easy way to do it just for one page. You could just hide the "edit with form" tab for that page... or even disable editing on it altogether. Or you could use the Approved Revs extension to allow you to check any edits made to that page before they actually take effect. Yaron Koren (talk) 14:33, 4 August 2015 (UTC)

Hi, thanks for your answer. I do want them to use the form! I just don't want them to be able to add or remove instances or move them around (I only want them to change the contents using the form). But maybe you're right. We do have a document release system in place and I'll just have to trust people not to delete anything.. Is there a possibiliy to remove the drag-feature systemwide? --212.103.80.194 15:07, 4 August 2015 (UTC)

No, there's no way to disable dragging. That seems... extreme, even for your use case. The implementation of min/max depends on the SF version - I think in recent versions, those params truly do prevent you from adding/removing, even before the form is submitted. Though I still don't see how that would work for you, given that it's only one page you want to have this restriction for.

More generally, now I'm curious: why would your users want to add/remove/rearrange the template instances on this page, given that the underlying data (whatever it is) presumably hasn't changed? Yaron Koren (talk) 15:17, 4 August 2015 (UTC)

Because they can ;-)

The EU Medical Device Directive defines 84 requirements. For each one our engineers must decide whether that particular one applies to our device or not, this has an impact on the device's development. I've just created a new form which will greatly simplifly this for them. However, some engineer might decide to just delete an instance he feels doesn't apply instead of just marking it as not-applicable. This is a problem because it would create a gap in our documentation. Instead of explicitly being marked as not-applicable it would be undefined - The FDA would not like that at all. Thats why I want to prevent people from (accidently) deleting instances of my form.

I've just tested the Min/Max on a testserver with a higher version. These settings wont prevent the user from deleting an instance, but it will prevent them from saving, at least. --212.103.80.194 15:34, 4 August 2015 (UTC)

Oh - so every page that uses this form has 84 instances, and always in the same order? If that's true, maybe you should just hardcode all the fields, instead of using a multiple-instance template. Yaron Koren (talk) 17:31, 4 August 2015 (UTC)

Well thanks so much for taking your time. Im a bit worried that hardcoding every element of every instance might seriously slow down loading times. I'll give it a shot and test it and weigh them up to each other :) Have a great day --212.103.80.194 07:17, 5 August 2015 (UTC)

Extension:Semantic Forms/Quick start guide. Example problem. [Solved]

I am trying to set up the Semantic Forms-based books and author wiki from scratch, https://www.mediawiki.org/wiki/Extension:Semantic_Forms/Quick_start_guide.

When I try to create the template for author and fill in the "Aggregation" fields as described in the example I get: Notice: Undefined property: SFTemplate::$mAggregatingLabel in ...\extensions\SemanticForms\includes\SF_Template.php on line 358.

I am using:
MediaWiki 1.25.1
PHP 5.4.26 (cgi-fcgi)
MySQL 5.6.17
Lua 5.1.4

Semantic Forms 777ed50
Semantic MediaWiki 2.2.2

Running on a Windows Small Business Server 2011

--Olht (talk) 21:46, 4 August 2015 (UTC)

Oops! That bug has apparently been in place for a long time. Thanks for letting me know; I think I just fixed it. Yaron Koren (talk) 23:46, 4 August 2015 (UTC)

Thank you, but sorry, the problem still exists. I have downloaded Semantic Forms again and updated my SMW installation. The problem can be shown in my website: http://www.hattebol.no/Spesial%3AOpprett_mal.

My localsettings.php:
include_once "$IP/extensions/SemanticForms/SemanticForms.php";
enableSemantics('hattebol.no'); /** Adjust to yours.*/
setlocale( LC_ALL, "en_US.UTF-8" );
$smwgNamespacesWithSemanticLinks[NS_TEMPLATE] = true;
--Olht (talk) 12:32, 5 August 2015 (UTC)

Are you sure you upgraded SF? It looks like you're still on 777ed50. Yaron Koren (talk) 13:52, 5 August 2015 (UTC)

I used git clone https://git.wikimedia.org/git/mediawiki/extensions/SemanticForms.git. I thought that would give me the latest version. --Olht (talk) 14:27, 5 August 2015 (UTC)

I really don't know... perhaps you did get the latest version of the code, but didn't put it in the right place? Yaron Koren (talk) 14:37, 5 August 2015 (UTC)

That was it, thanks for the help, kudos to you. However my version of Semantic Forms still show 777ed50. --Olht (talk) 15:08, 5 August 2015 (UTC)

WikiEditor no longer working in SF after upgrade

Hi, after upgrading MW to 1.25 (from 1.19) and upgrading SF to 2.7 I no longer can get WikiEditor working for free text fields in Forms. If a form contains this:

{{{standard input|free text|autogrow|editor=wikieditor}}}

I get this popup:

ext.semanticforms.fancybox: Error: Module ext.semanticforms.fancybox has failed dependencies

and no WikiEditor toolbar appears. Any ideas? SzymonS (talk) 10:00, 6 August 2015 (UTC)

OK, disregard that; apparently the problem was with SF 2.7 (installed as part of SemanticBundle) and has been fixed by upgrading SF to current (3.3.2).

Semantic forms and inputbox bug

I am trying to get an input box where users can input a new title and SF takes the user to that page and prompts them to create the form via a defined SF. However I get the source editor. Is there any way to fix that?

I don't know... why not just use #forminput? Yaron Koren (talk) 16:52, 19 August 2015 (UTC)

Tree Input Structure appears broken in 3.3.3

Upgrading SF from 3.3.1 to 3.3.3 seems to break Tree Inputs that use the Structure option. Only the uppermost parents are displayed, no child options/checkboxes. Thanks!

Sorry about that - I just checked in a fix for this bug, here. Yaron Koren (talk) 20:04, 25 August 2015 (UTC)

MWException in RunQuery

Not sure if I'm alone in this problem, but I'm getting the following error on RunQuery pages after upgrading to the newest version.

MWException from line 639 of ***\extensions\SemanticMediaWiki\includes\SemanticData.php: Data for a subobject of RunQuery cannot be added to RunQuery_dummy_title.

I changed the exception error line to ignore RunQuery_dummy_title for the mean time and everything seems ok, but of course a better fix would be better.

Does this happen with any form that you "plug in" to Special:RunQuery, or only one? And did you mean the newest version of SF, or SMW? Yaron Koren (talk) 18:46, 25 August 2015 (UTC)

Hey Yaron. It seems to happen with any forms, and they're pretty varied in their functions. I recently updated everything to the newest versions, including SF, SMW, and MW.

Alright. My guess is that it's an issue with SMW - there hasn't been a change to the operation of Special:RunQuery in a while. Yaron Koren (talk) 13:24, 26 August 2015 (UTC)

Alternate fix is changing line 515 of Semantic Form's SF_FormPrinter.php to "$this->mPageTitle = Title::newFromText( 'RunQuery' );" That way the two match up. Not sure if this would cause any other problems, but looks like an easy fix.

Does that work for you? Yaron Koren (talk) 13:11, 4 September 2015 (UTC)

Yes, the fix appears to work. The SMW error is complaining that expected RunQuery title is not the same as RunQuery_dummy_title set by that line. Changing it to just RunQuery fixes that. Hope this helps. Thanks

Alright, I just put in a similar fix in the code. Thanks for that suggestion. Yaron Koren (talk) 16:48, 11 September 2015 (UTC)

div id for 'show on select'

Just a question. I've noticed that using 'show on select' in SF 3.3.1 you cannot reuse a 'div id' in a form. This is not necessarily a problem because you can always create a second 'div id' in its stead. Something to add the documentation perhaps, but I recall that reusing 'ids' was actually possible in an earlier version of SF. So is this a minor regression? Cavila 11:16, 27 August 2015 (UTC)

Oh, there's mention of a HierarchyRequestError in the browser console, which sounds like it could be the party pooper responsible for this. I can't find anything about javascript conflicts that could be causing this, unfortunately. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 11:38, 27 August 2015 (UTC)

How could having the same div ID more than once in a form have worked before? How could the system know which div to show/hide? Yaron Koren (talk) 13:46, 27 August 2015 (UTC)

Good question, I've no idea. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 18:30, 27 August 2015 (UTC)

ConfirmEdit no longer working with SF

It looks like the ConfirmEdit extension is no longer working with Semantic Forms. When a user goes to save the page it throws a mwexception which I traced back to line 471 in SF_AutoeditAPI.php. The confirm edit hook throws an expected error, and SF fails. Before, saving the form would take the user to a regular edit page with the semantic form's updated info, the user would fill out the captcha, and the edit would be saved. Is there any way I could get the old behavior back, or maybe an improved behavior? Thanks!

What's the exception, and what versions of SF, CE and MW are you using? Yaron Koren (talk) 20:14, 31 August 2015 (UTC)

it happens at line 471 "case EditPage::AS_HOOK_ERROR_EXPECTED: // A hook function returned an error" and throws the sf_autoedit_fail at line 480. Versions are MW:1.25.1, CE 1.3, and SF 3.3.2. What I assume is happening is, SF goes to edit the page, but CE blocks it because of captcha. If I turn off confirm edit or log in, it saves the page fine.

This is now tracked on Phabricator. Yaron Koren (talk) 20:23, 3 September 2015 (UTC)

Added the code listed in the change and it looks like it works for editing forms. Thanks! One problem I noticed that is still an issue, is editing using an {{#autoedit:}} link. For those it notifies the user that their IP will be logged and claims to succeed, but no changes are made or pages are created. Before, these edits were allowed to be made without filling out the captcha, which is fine with me since they are more structured. Any way we could have this behavior returned? Thanks again Yaron!

I'm glad the last issue was fixed. This new one is now tracked on Phabricator too, here. Yaron Koren (talk) 15:23, 11 September 2015 (UTC)