Extension talk:Page Forms

namespace showing up on values from category
I maintain a closed wiki within our company, thus i cant give any access to the real pages. I have some fields that are supposed to hold the users login name e.g. Brownc for Charles Brown. All the users have their own semantic userpage where organisational data (phone, room, building, etc) is stored. The users can create subpages to their userpage to test/implement/store information that is mostly for themselves. Now i want to use all those real userpages to autocomplete on the users loginname. The Userpages are categorized as Category:Userpage. I did an autocomplete on the category:

Now, as autocomplete starts, it prepends a "User:" to the loginnames. I would want to have something in the input field like "Brownc" and get "User:Brownc". Can the namespace that is prepended somehow be suppressed? I dont need it in my property either. Regards Ciannicay (talk) 14:48, 2 August 2013 (UTC)


 * You could try "autocomplete on namespace=User" instead. Yaron Koren (talk) 15:11, 2 August 2013 (UTC)


 * This would lead to vast numbers of pages showing up in autocomplete that are in no way userpages. To explain it a little more: Our users have to fill out a form that generates a "homepage" for the user. But what the user does below (using subpages) his userpage (=his homepage) is completely up to him/her. We do have users that made 120 pages below their userpage just for themself. These pages would all show up in autocomplete, and thats unwanted. We did an upgrade leap from Mediawiki 1.12.0 (SF 1.3.6) to Mediawiki 1.17.5 (SF 2.2.1) recently. I am trying to get back some old behaviour cause we cannot upgrade our other tools in near future. Ciannicay (talk) 10:32, 6 August 2013 (UTC)


 * Hi - actually, I believe namespace autocompletion is "smart" and doesn't include subpages, although I don't know if that was the case in the SF version you're using. In any case, if you're using forms, and thus templates, there's a simpler option: to the main template being used for user pages, add something like " Has username:: ". "Has username" should be a String property, and then you should add "|values from property=Has username" to the original form field tag. Yaron Koren (talk) 15:53, 6 August 2013 (UTC)


 * You made my day. I already set exactly the property you used as example. *facepalm* I was missing the forest through the trees. Your solution works like a charm. Thanks a lot. And keep up your great work! Ciannicay (talk) 14:37, 7 August 2013 (UTC)

Bug? When creating a page through a form in IE the preview button disappears.
Hi,

I have a wiki that can launch a form with the following code:

When I create an article with chrome using this process everything is fine, but IE loses the show preview button. I would appreciate any thoughts.


 * Is this related to #forminput? Or does the same issue happen if you just go directly to the form URL? Yaron Koren (talk) 15:04, 7 August 2013 (UTC)


 * This happens when I go to the form directly as well 17:31, 7 August 2013 (GMT)

Page name formulas
I would like the user to enter a value in the page name text box, the one on the creation page, but then change the name they chose. For example they should be able to enter an incident number like "12345" and I would like to force the resulting page to have the name "Incident_12345". How can I accomplish this? Thanks, Pete.


 * You can't do that - you would have to go through the one-step process to change the entered name in any way. Yaron Koren (talk) 14:20, 8 August 2013 (UTC)

Bug: Uploading files doesn't work with Internet Explorer (v9), can anyone un-/confirm this as a bug?
Bug: Uploading files doesn't work with Internet Explorer (v9), can anyone un-/confirm this as a bug?

Steps to reproduce the problem:


 * 1) Create a form with a file upload field.
 * 2) Create a new page from the form
 * 3) Click "upload file" on the upload field, a javascript modal panel will appear.
 * 4) Upload a file and submit.

The expected behavior:

The modal panel closes, setting the filename in the file-upload text field.

The actual behavior:

Modal panel never closes and goes blank (only white background showing). Closing the modal panel with X icon, closes it, but underlaying form is broken. Text is not set in the file-upload text field.


 * What versions of MediaWiki and Semantic Forms are you using? Yaron Koren (talk) 13:06, 21 August 2013 (UTC)


 * MediaWiki-1.19.7, PHP-5.4.4, Semantic Forms-2.5.3 --netbrain (talk) 16:00, 21 August 2013 (UTC)


 * Okay. Unfortunately I only have IE 10, and I just tried it with that version and it's working fine for me. I'll try to find IE 9 somewhere. What operating system are you on, by the way? (I assume it's Windows something.) Yaron Koren (talk) 20:56, 21 August 2013 (UTC)

Need for an Append Form to add instances (multiple template) to a page only
Forms are well-suited to add/edit/delete/sort instances of a multiple template included on a page. However if the number of instances gets significant (e.g. above 200) the time to open the form increases dramatically. This is quite annoying when you ONLY wish to add/append an instance (no need to see existing instances). Is it possible to create a form that can only append/add new instances for a multiple template (without having to process existing instances)?

To give you an example. We use semantic mediawiki to manage the metadata of our measurement system that consistent of many locaties (stations) with deployed instruments. For these locations or stations many pictures, documents, historical scanned material etc is available that is added as internal objects containing a timestamp/file reference and a description field. If someone wishes to add an additional document is takes very long to open the form because all existing attachements (internal objects) have to be processed and displayed first. This hampers the contribution of information!

Thanks in advance.

Jan Willem


 * Unfortunately, no... I can't think of a solution to this problem given the current software, other than to (a) just tell people to use the regular edit page, instead of the form, or (b) change the data structure so that each location/station has its own page. Yaron Koren (talk) 18:07, 21 August 2013 (UTC)


 * Thanks for your prompt response. FYI:there are pages for each station/location. I might go for option (b) which implies that each page attachment gets its own page....Jan Willem Noteboom (talk) 6:46, 22 August 2013 (UTC)


 * Oh, oops, I misread what you wrote. Right, pages for each attachment... if those are already stored as an uploaded file (in the "File:" namespace), you could in theory put the semantic data (and form) directly on that File: page, instead of creating a new page - people have done it both ways. Yaron Koren (talk) 13:00, 22 August 2013 (UTC)


 * Thanks for your suggestion. Perhaps the extension UploadWizard meets our needs. it offers the ability to add information templates...Jan Willem Noteboom (talk) 19:46, 22 August 2013 (UTC)

Populating red links does not work witch #set
Hi Yaron,

thanks for your fabulous work!

We are using Semantic Bundle 1.8.0.4 on MW 1.21. I am passing values to a template creating properties as follows:

Definition of Property:Tag: has type::Page Creates pages with form::Tagsnip

Still it does not populate red links automatically, which it reliably does for other pages with Tag::Value. When I change the template accordingly, all works well.

Is this a bug?

Regards

--92.50.70.114 07:28, 22 August 2013 (UTC)


 * I doubt that the fact that the properties are being set via a template per se has anything to do with it - by the time they're queried by SF, they look the same regardless of how they were set. If you look in the "Browse properties" link in the sidebar for a page that uses the template, is "Tag" being stored correctly? Yaron Koren (talk) 13:06, 22 August 2013 (UTC)


 * I tried tho above on our test Wiki (MW-1.22wmf12, SMW-1.9 alpha) and it works just fine. Are you sure you created the following pages:

has type::PageCreates pages with form::Tagsnip Tag::Blabla1Tag::Blabla2Tag::Blabla3Tag::Blabla4Tag::Blabla5Tag::Blabla6
 * Property:Tag with:
 * Template:Tagsnip with:
 * Form:Tagsnip with:
 * A random page with:


 * The page names (assigned to the properties) should then be added to the job queue. Depending on how long the queue is it might take a while for the pages to actually be created. If your Wiki is not busy just keep hitting ctrl-F5 and you will see that the page links will miraculously turn from red to blue. Hope this helps. Regards --Jongfeli (talk) 13:43, 22 August 2013 (UTC)


 * Hi Yaron and Jongfelli,
 * Yes, the properties showed up in Browser Properties as expected, apart from staying red. Jongfeli, I started runJobs.php multiple times to force the page creation - without success. I used the tags in other templates as well without using set, it always worked well.
 * Still, it is no problem for me to use Tag::Value, so I don't think I will be able to spend more time on it. I will update the wiki after the stable release of 1.9 and might check for it then. Thanks for your assistance anyway!

Fatal error when creating article from linked form.
Similar to this previous discussion, I'm getting a fatal error when attempting to submit an article from a linked form (MW 1.21.1, SMW 1.8.0.5, SF 2.5-2.5.3). The error varies depending on which version of SF I'm using.

SF 2.5: PHP Fatal error:  Call to a member function exists on a non-object in / /extensions/SemanticForms/specials/SF_FormEdit.php on line 273

SF 2.5.3: PHP Fatal error:  Call to a member function getArticleID on a non-object in / /extensions/SemanticForms/includes/SF_AutoeditAPI.php on line 687

The referring URL is of the form: http://example.com/wiki/Special:FormEdit/Article/?Article%5BHas+Title%5D=Something

The form includes a statement, at the top:, which appears to make no difference.

If the form is provided with an article name, e.g. http://example.com/wiki/Special:FormEdit/Article/ Foo ?Article%5BHas+Title%5D=Something, the submission will succeed and the article will be created.

Normally, I'd assume that I'd just done something stupid and I'd find a workaround. However, I had a wiki last year or so that I could swear had this exact type of bookmark, and I didn't encounter any errors with it.

Thoughts?
 * 16:28, 22 August 2013 (UTC)


 * The "&lt;count&gt;" in the "page name" value looks suspicious... could that be the source of the error? Although, as F.trott pointed out in his response, a crash like that is never the right behavior. Yaron Koren (talk)
 * Sorry Yaron, that was a typo on my part. It's not present in my markup for the affected form.


 * I'm really puzzled by this because I swiped the code from Jamie Thingelstad back in the day. I checked and his bookmarklet still has the same sort of URL, and he's running bleeding-edge everything on that wiki.  I'd expect him to be seeing the same bug, but it doesn't appear that he is.


 * 23:01, 22 August 2013 (UTC)


 * Could you reproduce this on a public wiki, like http://scratchpad.referata.com? Yaron Koren (talk) 00:15, 23 August 2013 (UTC)

Sure, except it seems to work there :-/


 * Consider the form: http://scratchpad.referata.com/wiki/Form:Bug_Demonstration
 * Editing with a provided title: http://scratchpad.referata.com/wiki/Special:FormEdit/Bug_Demonstration/Whee
 * Results in a valid article: http://scratchpad.referata.com/wiki/Whee
 * A URL opening the page without a provided title but with the field used to create the article populated: http://scratchpad.referata.com/wiki/Special:FormEdit/Bug_Demonstration/?Demonstration%5BTitle%5D=Wheeee
 * Results in a valid article: http://scratchpad.referata.com/wiki/Wheeee

Maybe I'm cracking up, Yaron. I guess I'll report back if I figure out what's going on.

The only thing I can think of is that I keep my form templates in a special namespace, Stencil. So instead of calling, I'm calling. There isn't a problem elsewhere, AFAICT: my URLs for populating the fields work correctly ( &Stencil:Article%5BTitle%5D= ), my other scripts (I'm using F. Trott's dynamic defaults javascript, for example) work correctly, etc. So far as I can tell, everything works correctly except that the title object doesn't seem to be constructed when the form is submitted.
 * 14:12, 23 August 2013 (UTC)

Issue with partial forms
I'm having an issue with partial forms using Semantic Forms 2.5.3. Whenever I edit a page through Special:FormEdit/ThePartialForm/ThePage only new parameter-value pairs are added to the template on the page. Any existing values that are changed through the form are never updated. When the partial form uses a multi-instance template, not even new values are added and the page is never changed at all.

You can verify this behaviour here (on the example page that the SF partial forms documentation links to). Just change some of the items and/or add another and then choose 'show changes'. The result will be empty, i.e., no changes are being seen.

I've been poking around a bit in the code of, and found that around l.830, after executing the variable  contains the right values, however the correct contents of   appear not to be transfered to the   variable, which is used to edit the page around l.900:

I am stuck here, since I'm unsure how  and   are supposed to be related. Can anyone with a better grasp of the SF code design and its inner workings help me solve this issue?

--Remco de Boer 09:12, 26 August 2013 (UTC)

Defining relationships in templates and being able to query on those relationships.
Is it possible to define a form with multiple-instance where i then can use a ask query to fetch properties from the multiple-instance form/template?

Example: Say i have a form Book and a subform/multiple instance Author, where one book may have many authors.

How would i go about setting this up? and how can i create an ask query to fetch me basic data about the book aswell as the names of each author?


 * You need to use either the #subobject parser function, or #set_internal from the Semantic Internal Objects extension, within that multiple-instance template, in order to store the data. I hope that helps... Yaron Koren (talk) 13:35, 26 August 2013 (UTC)

Minor edit not marked as such when using a free text field
Hi Yaron, I really like your extension a lot. It helps me do some great thinks for our wiki. :-) Now I'm not sure if I found a little bug. I use a "free text" field in my form. But then the minor edits are no longer marked as minor. Without the free text it works as planned. I'm I using it wrong or is there a work around? Thanks! - Dadai12 (talk) 14:38, 26 August 2013 (UTC)


 * Hi - this was a bug in SF 2.5.2, but I thought it was fixed in 2.5.3. What version are you using? Yaron Koren (talk) 13:33, 26 August 2013 (UTC)


 * Hi, thanks for the quick reply. Great to hear - I'm currently using 2.5.2. Sorry, I haven't seen there was a new version. I will update tomorrow and let you know about it. :-) - Dadai12 (talk) 15:44, 26 August 2013 (UTC)


 * Good morning - I did the update today and now it works perfectly again - thanks! - Dadai12 (talk) 9:04, 27 August 2013 (UTC)


 * The same goes for the parameter preload, isn't it? It does not preload my page in the free text input area. Does the 2.5.3 resolve the problem? Silkwood (talk) 09:46, 30 August 2013 (UTC)
 * OK! Tested. It works. Silkwood (talk) 09:56, 30 August 2013 (UTC)

Problem with Autogrow Parameters
Hi,

First of all, This is an EXCELLENT EXTENSION! and I love it 100%!!

However, I just noticed that there is a problem when adding the Autogrow Parameters to textarea. Not sure if its a bug or if its reported somewhere before. Anyhow, what happens is when the autogrow parameter is added to the text area, the textarea's min width becomes too long in lower resolution screens. Meaning, the width is too long that it goes beyond the borders of its parent div in lower resolutions. I noticed this because for my site I have a minimum width of 650px for the bodycontent section excluding the sidebar. So when the screen is reduced to 650px wide for bodycontent, the textarea doesnt resize and the width overlaps over the sidebar on the right. This is not noticeable in higher resolution screens. When I remove the "autogrow" parameter, the width of the textarea resizes properly for smaller screens. Unfortunately without the autogrow parameter it doesnt increase in height and shows an ugly scrollbar but with autogrow it looks even worse with the textarea going outside its body area in smaller resolutions. Can this be fixed? How can I fix this?