Extension talk:Page Forms

Append "Media:" before the names of uploaded files
After a file is uploaded, I want to create a link to the uploaded file automatically. For example, if you upload a file named "hoge.jpg" and save the page, then the page contains a red link to "hoge.jpg". But, we cannot see the uploaded image by clicking the link. So, I want to change the link to "Media:hoge.jpg". Does anyone have a good idea to do that?

You could achieve this using an Array Map Template. First, create a template with a form that updates a parameter in a template (which you probably already have done). In the example below, this parameter is called files, and the Array Map Template (which is a standard wiki template) is called Formfile.

Then I created a template called Formfile which looks like this:

The way the template above works a user can either upload the file using Semantic Forms, or just type the name of the file into the field. If the file exists (they uploaded it) it will display a link. Otherwise they'll get a "click to upload" message. --Gkullberg 15:21, 5 January 2010 (UTC)

Autocompletion for multiple properties/namespaces?
Is it possible have autocompletion for more than one property or namespace? For example, it would be nice to be able to have autocompletion on the main namespace and another namespace called "Activity" like this:

autocomplete on namespace=,Activity

Is this possible? --Gkullberg 21:37, 5 January 2010 (UTC)


 * Unfortunately, no... and I can't think of any hacks around it, either. Yaron Koren 21:56, 5 January 2010 (UTC)

Issue with query string and the two steps process with #forminput
Hi Yaron

I am having difficulties getting #forminput to work with pre-set query strings. I would like to use a #forminput to force certain values to a form (namely, a login name).

If I use a page name that already exists, the query string seems to be lost once the form switched to Edit instead of Add.

If I do add a new page, the query string is preserved and the form fields are populated with the values from the query string.

Is that an intended behavior ?

I am using version 1.8.6

- Laurent Alquier


 * Hi, yes, this is intended behavior - you can't override what's in the page already using the form. The principle is that just going to the form and hitting "save" should never change the data in an existing page. If you disagree with that, we can talk about that. Yaron Koren 04:11, 7 January 2010 (UTC)


 * Thanks for the clarification. I agree with the principle - it is safer that way. However, some features of the forms already break that principle (having a field of type List overwrites values in the field that do not match the list for example), and I can see cases where it is beneficial to have a form provide values by query string in edit mode. Maybe having a check for empty values before overwriting with query string parameters could help ? - Laurent


 * It's true that the principle sometimes gets broken... though that, by itself, isn't a reason to break it further. I'm confused, though: do you agree with the principle or not? Yaron Koren 04:34, 7 January 2010 (UTC)


 * I do agree it is safer to have this default behavior :) - Laurenr

Return Free Text with #ask
I would like to be able to return the value in Free Text when using #ask to create a table or a map.

For a little more background: I started out with a description field of the type text. It was having problems with wrapping and displaying content. The Free Text field works really well, but I do not know how to access that data outside of calling the form.


 * Unfortunately, you can't do that - you'll have to go back to using the "Text" type. What were the problems you had with displaying content? It could be that using $smwgLinksInValues could help. Yaron Koren 16:59, 7 January 2010 (UTC)

Upload file tag broken via #formlink
When I add a page by setting an automactic page name, using #formlink, the floatbox to upload a file doesn't appear after clicking the 'upload file' link behind the field.

I made an example of this problem on referata.com: If you fill out the form the usual way the regular floatbox does appear. However if you add a page with #formlink: http://www.referata.com/wiki/Linkformlinktest Clicking 'upload file' opens the upload window as whole page instead of a floatbox.

Is there a way to make the floatbox appear? -JosCo 09:50, 12 January 2010 (UTC)


 * That's odd, although it's a bit of a minor bug, since the query string you have in there (the last parameter) is incorrect - it's just "Formlinktest", but it needs to be either empty or of the form "template-name[field-name]=value", etc. Yaron Koren 23:10, 14 January 2010 (UTC)


 * Thanx for the help. It works like a charm indeed. -JosCo 14:48, 16 January 2010 (UTC)

Page content showing up at bottom of form after upgrading to latest version of SF
In my old version of SF, when I'm in a form and I view the source of the page I see a hidden variable like this:



Note: I can't seem to get the above text to display without wiki evaluation so you will need to edit this comment to see what I'm talking about.

However, after upgrading to the latest version, I see a bunch of page content down at the bottom of the form coming from the page that the form is editing. When I view the source of the page it seems that this content is from a hidden form variable that item isn't converting the {'s and ['s to their HTML equivalents anymore:



Any idea what's wrong? --Gkullberg 20:40, 12 January 2010 (UTC)


 * You've indeed found a bug - this will be fixed in the next version of SF, but it can be fixed now by changing line 1183 of /includes/SF_FormPrinter.inc from:


 * to:

Yaron Koren 19:20, 21 January 2010 (UTC)

Class 'SMWPropertyValue' not found
After adding the include_once-line to LocalSettings.php I got: Fatal error: Class 'SMWPropertyValue' not found in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_LinkUtils.inc on line 79

With error_reporting set to E_ALL I get: Notice: Use of undefined constant SF_NS_FORM - assumed 'SF_NS_FORM' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183 Notice: Use of undefined constant SF_NS_FORM_TALK - assumed 'SF_NS_FORM_TALK' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183 Notice: Use of undefined constant SF_NS_FORM - assumed 'SF_NS_FORM' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183 Notice: Use of undefined constant SF_NS_FORM_TALK - assumed 'SF_NS_FORM_TALK' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183 Notice: Use of undefined constant SF_NS_FORM_TALK - assumed 'SF_NS_FORM_TALK' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 153 Warning: Cannot modify header information - headers already sent by (output started at /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php:183) in /usr/share/mediawiki/includes/WebResponse.php on line 10 Warning: Cannot modify header information - headers already sent by (output started at /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php:183) in /usr/share/mediawiki/includes/WebResponse.php on line 10 Fatal error: Class 'SMWPropertyValue' not found in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_LinkUtils.inc on line 79

Any ideas what could be wrong?

I took the MediaWiki from stable debian package and it's version 1.12.0. The SemanticMediaWiki is also from stable debian package and it's version is 1.2. The SemanticForms is version 1.8.7. I've set the mediawiki to be finnish (not sure if it has something to do with this.)

-- Tero Laxström, 26 January 2010


 * Hi, the issue is that SF no longer supports versions of SMW before 1.4. I would recommend upgrading your version of SMW (upgrading MediaWiki itself wouldn't hurt either); and if you have any contact with the Debian people, please tell them they're packaging an old version. Yaron Koren 18:03, 26 January 2010 (UTC)