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)

= Transclusion of forms (i.e., treating them like templates) =

I've created a test form, Form:A. There's nothing special about Form:A; it contents are typical. Now I create a second form, Form:B. The contents of Form:B are: Now when I visit Form:B, the expected behavior would be that I'd see precisely the same thing that I'd see if I visited Form:A. But that's not the case.

Here I've treated Form:A like a template, "transcluding" it into Form:B. We might like to go farther and perform additional substitution on Form:A, giving it parameters like any template. Why would one want to do such a thing? For situations when it is necessary to dynamically generate a form:
 * Complicated data-entry scenarios
 * Data pre-processesing steps
 * Multi-step data "wizards"
 * etc.

My specific use-case requires that I do some complicated pre-processing in order to decide a page name. So, I'd like to have an initial form take care of the page-name-entry steps and dynamically generate a second form where the user inputs the remaining data. Sadly, it seems that forms cannot be treated as templates. Am I correct in this? It is certainly possible that I'm missing something in my attempts to make form transclusion work. If I'm indeed correct, are there any work-arounds or maybe some more concise machinery for doing what I want to do?

Thanks all! And great work on this software! 189.153.80.253 04:40, 27 January 2010 (UTC)


 * What you're talking about should work, in theory - see here for what may be the problem. Yaron Koren 04:54, 27 January 2010 (UTC)

= Space in query string #formlink; upload tag not working =

When adding a page via #formlink with a space in the query string the upload tag doesn't work. For an example see this form.  The Formlink is: " http://www.referata.com/wiki/Special:AddData/Formlinktest?Setpagetitle[City]=City with space in name " The floatbox doesn't appear. I noticed a related bugfix in version 1.2.5. My current SF version 1.8.5. -JosCo 14:41, 29 January 2010 (UTC)


 * My guess is that you're using the IE browser - is that true? This seems to be a problem on IE (which I always forget to test on), but not in any other browser. Yaron Koren 16:23, 29 January 2010 (UTC)


 * Yeah, that's true. I see now in FF it works fine, but I'm afraid I can't really expect all users in the company to change the browser because of this. Would it be possible to make a fix for it, or maybe can you think of a possible workaround for this issue? -JosCo 15:59, 30 January 2010 (UTC)

= "Edit with form"-Tab missing =

I've just installed a fresh svn version of mediawiki (1.16alpha, r61710), Semantic Mediawiki (Version 1.5h-SVN, r61710) and Semantic Forms (Version 1.5h-SVN, r61710). After that I used "Create Class". Everything looks fine, except that no "edit with form" tab is shown. --ThomasKalka 12:44, 30 January 2010 (UTC)