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)