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?


 * That's great to hear! You can change the width manually by adding "|cols=", and also by adding "|class=" and then setting the width via CSS, for whatever class name you chose. If neither of those solve this problem, I hope you still love it at least 90%. :) Yaron Koren (talk) 12:55, 1 September 2013 (UTC)

Special:CreateClass SF 2.5.3 broken in the latest "master" combo ?
Hello,

I filed a bug report about Special:CreateClass and Special:CreateForm.

[Wed Aug 28 12:12:57 2013] [error] [client 129.194.30.22] PHP Fatal error: Cannot use object of type SFTemplateInForm as array in /export/data/portails/mediawiki/extensions/SemanticForms/includes/SF_Form.php on line 100, referer: http://edutechwiki.unige.ch/en/Special:CreateClass

[Wed Aug 28 12:38:33 2013] [error] [client 129.194.30.22] PHP Fatal error: Call to a member function getDBkey on a non-object in /export/data/portails/mediawiki/extensions/SemanticMediaWiki/includes/BasePropertyAnnotator.php on line 106, referer: http://edutechwiki.unige.ch/en/Special:CreateForm This bug appears only in combination with the latest MW/SMW and other SMW code in the "master" branch. Special:CreateClass for SF 2.5.3 does work on scratchpad.referata

I hope that this is a bug and not some systematic misconfiguration. That being said, I could replicate this in another (independent) wiki on the same machine and in another wiki that sits in a different machine. It's not a showstopper bug, since I could create the forms and properties manually, e.g. I did this after the bug started appearing. Sorry for not knowing, but I have no clue after which upgrade of what extension the bug crept in. I was trying to get semantic maps going and didn't create any form while switching to the latest master code. To summarize, if you "git pull" the latest code of MW, SMW and other needed extensions from master branch, then it seems to be broken

Versions: MediaWiki 1.22alpha (f857f0c) 08:46, 25 August 2013 PHP 	5.3.10-1ubuntu3.7 (apache2handler) MySQL 	5.5.32-0ubuntu0.12.04.1 Semantic MediaWiki (Version 1.9 alpha-2)

Accessible wikis for details:
 * http://edutechwiki.unige.ch/en/Special:Version
 * http://edutechwiki.unige.ch/fr/Special:Version

Finally the questions:
 * Anyone has an idea what magic combo would work and if yes, could I backtrack to older versions without negative effects. As I said, this but is not mission critical for me so I'd rather wait for the problem to be solved :)
 * Do you see a problem with my configurations, i.e. is it really a bug ?

- cheers ! - Daniel K. Schneider (talk) 19:40, 31 August 2013 (UTC)

Extension:Semantic Forms/Creating query forms
Exampeles in Extension:Semantic Forms/Creating query forms do not work
 *  Fatal error: Call to a member function replace on a non-object in /home/ngrandy/public_html/w/includes/parser/Parser.php on line 4991

-- 87.177.139.177 07:18, 1 September 2013 (UTC)


 * Thanks for letting me know - I just fixed the problem. Yaron Koren (talk) 12:50, 1 September 2013 (UTC)

Fatal error: Class 'ParserHook' not found in SemanticMediaWiki\includes\parserhooks\SMW_SMWDoc.php on line 15
Although this extension works fine, when I run the update.php by going to mysite.com/wiki/mw-config/, I am getting the following error:

Fatal error: Class 'ParserHook' not found in localhost\wiki\extensions\SemanticMediaWiki\includes\parserhooks\SMW_SMWDoc.php on line 15

I recently had to run a database update when I was installing another extension (actually it was another awesome extension written by you: Approved Revs) and thats when I noticed this error. Once this error shows up, I was unable to access any wiki pages. So I had to comment the Semantic Extension in my LocalSettings.php, run the database update (which works once the Semantic extension was commented) and then added the Semantic Extension to my Localsettings.php once again after its done. Do you know what may have cause this issue? I am using Mediawiki 1.21.

Cheers!


 * That sounds like a Semantic MediaWiki issue, not a Semantic Forms issue. Yaron Koren (talk) 21:43, 1 September 2013 (UTC)

Fatal error: Call to a member function getNamespace ...
Trying to create a class using the 'CreateClass' form fails with the error

Fatal error: Call to a member function getNamespace on a non-object in /var/lib/mediawiki/includes/job/JobQueue.php on line 353

There were also warnings from SemanticTasks, but these disappeared after I disabled that extension.

My config:
 * Semantic Bundle (Version 1.8.0.4)
 * Semantic Forms (Version 2.5.2)
 * MW 1.19.2

I'm happy to provide any other details required to troubleshoot the issue.