Extension talk:Page Forms/Archive October to November 2011

Where do forms get stored or loosing forms through update?

MediaWiki 1.17, Semantic Forms (Version 2.2.1), Semantic MediaWiki (Version 1.5.6)

Might it happen, that through updating from SF 1.8 to SF 2.2.1 I have lost my forms? Are there any update scripts that I should run and I'm not aware of? Where are forms stored (in case I'd like to re-create them from a backup)? Thanks a lot in advance,


Each form is stored in its own page in the "Form:" namespace. There shouldn't be any danger of losing forms. Yaron Koren 23:16, 23 October 2011 (UTC)Reply[reply]
Thanks for answering Yaron. Still in http://en.wiki-products.org/Special:Forms the forms that originally were there are missing. Should I recreate each form individually or is there a way I can retrieve them from a backup? For instance there should be a form called "deodorant". I'm using the $sfgNamespaceIndex = 150 maybe there is a mistake. Compare [[[Extension talk:Semantic Forms/Archive January to April 2009#Namespace .22Form.22 in SMW 1.4.0|Namespace in V1.4]]] --Francis
Ah - I guess try removing that setting, and see if the forms show up again. This sounds like a namespace issue. (Though I don't know why upgrading from 1.8 to the most recent version would have caused it...) Yaron Koren 14:43, 24 October 2011 (UTC)Reply[reply]
Unfortunately not. So coming back to my former question: Can I retrieve forms from a database backup and if yes, where shall I look for it (given access with phpmyadmin). I think I would hand copy the about 10 forms from the database and create new forms again.


The relevant database tables are "page" and "archive" - maybe the easiest solution is to find the relevant rows in those tables, and change the namespaces to the right value (either 106 or 150, I assume). Yaron Koren 19:16, 24 October 2011 (UTC)Reply[reply]
Thanks Yaron, I have looked into that and could at least see, which articles are effected and that the namespace should be 150. Another point is: In SF (Version 1.8.5) which I had installed before, I called include_once( "$IP/extensions/SemanticForms/includes/SF_Settings.php" ); from the localsettings.php. Now in 2.2.1 I'm calling include_once("$IP/extensions/SemanticForms/SemanticForms.php"); and SF_Settings.php is not existent anymore. Is there the mere possibility that $sfgNamespaceIndex should be called differently from Version 2.2.1. (because I couldn't find in the extension any occurrence where the extension would use $sfgNamespaceIndex). --Francis

First of all it seems a very rare problem, since nobody else seems to have it. Whatever might be the legacy reasons... Anyway my Namespace for SF was set to 150, so I had to get it set to 150 again to get my forms back. In SF (1.8.5) SF_GlobalFunctions.php contained those lines, to set the namespace

function sffInitNamespaces() {
	global $sfgNamespaceIndex, $wgExtraNamespaces, $wgNamespaceAliases, $wgNamespacesWithSubpages, $wgLanguageCode, $sfgContLang;

	if (!isset($sfgNamespaceIndex)) {
		$sfgNamespaceIndex = 106; 

	// these namespaces are defined in versions 1.4 and later of SMW
	if (! defined('SF_NS_FORM'))
		define('SF_NS_FORM',       $sfgNamespaceIndex);
	if (! defined('SF_NS_FORM_TALK'))
		define('SF_NS_FORM_TALK',  $sfgNamespaceIndex+1);

These are missing in SF 2.2.1. I have now put these lines directly into the LocalSettings.php so they don't get overwritten by future updates of Semantic Forms. For the moment this is not a solution, but a hack. Thanks again for your comments. --Francis

"Minor edit" and "watch" Buttons in form do not work

My settings:
MediaWiki 1.16.1, Semantic Forms (Version 2.2.1), Semantic Forms Inputs (Version 0.4.1), Semantic MediaWiki (Version 1.6), WikiEditor (Version 0.2.0), Vector (Version 0.2.0). When editing a page with a form the buttons don't show up but some html-code like

<html><meta http-equiv="content-type" content="charset=utf-8"/><p>minor edits</p></html>

Could there be some incompatibility with another extension? Some "neighbor-wiki" of ours does not have this problem, the do have older versions of Semantic Forms and SMW. Thanks --Eilan Ardanos 14:42, 7 October 2011 (UTC)Reply[reply]

Hi - that's bad. Could you try temporarily un-including the WikiEditor and/or Vector extensions, and see if the problem persists? My guess is that it's the interaction with one or both of those that's causing it. Yaron Koren 14:45, 7 October 2011 (UTC)Reply[reply]
Hi, thanks for the quick response. I enabled WikiEditor: same problem. Then I enabled Vector: same problem. Then I enabled both: still same problem. Maybe I should enable all my extensions one by one and see if any other extension is causing it. I will try next week again and report my findings. --Eilan Ardanos 15:00, 7 October 2011 (UTC)Reply[reply]
Okay, that's helpful. Though I assume you meant "disabled". :) Here's another question: do you have more than one form on your wiki, and if so, does this problem happen for all of them? Yaron Koren 15:44, 7 October 2011 (UTC)Reply[reply]
Oh, sorry, I did mean "disabled". I do have more then one form and the problem appears in all of them. --Eilan Ardanos 11:50, 10 October 2011 (UTC)Reply[reply]

Unclear includeonly/noinclude behavior for preload

Hi, I would enjoy the 'onlyinclude free text' tag in a form if it would mean that only the freetext is included in the preload of the free text on another form. But that doesn't happen. It seems that only the 'noinclude' tag in a page prevents parts of the page to be included in a preload. Other tags such as includeonly and onlyinclude (why having these two tags anyway?) don't seem to have any effect.

My favorite would be that the 'onlyinclude free text' feature does the trick, because it is easy then to create preload pages with a form that takes care of the semantic properties of that preload page.

--AdSvS 06:54, 11 October 2011 (UTC)Reply[reply]

Heads-up regarding autoedit and Abuse Filter

This is just a heads-up regarding Extension:AbuseFilter; it seems that if you have a rule setup that will trigger on an autoedit, and which rule either kills an edit OR prompts a notice, an attempt to use #autoedit will fail with "Error: A MediaWiki extension prevented the modification of the target page." I was testing the autoedit functionality when I discovered this, whereas I have a rule setup to notify users who haven't entered edit summaries. I'm not yet sure how to circumvent this problem since it doesn't appear that SF will allow me to specify an edit summary for autoedits, or since AbuseEdit can't differentiate and allow this type of edit.    Thorncrag   21:39, 11 October 2011 (UTC)Reply[reply]

So I've been thinking about this, and it seems to me that it would make sense that the autoedit should leave some kind of edit summary - that seems to be the standard. Also it makes sense from a page history perspective, to ascertain which edits were made by the automated process and which were not. What do you think about adding summary as a parameter to the autoedit parser?    Thorncrag   17:44, 12 October 2011 (UTC)Reply[reply]
Good idea. Will do that. Cheers, F.trott 08:38, 17 October 2011 (UTC)Reply[reply]
In the latest SVN you can now use the summary parameter with the autoedit parser function. If you omit it, a standard summary is inserted. F.trott 07:24, 18 October 2011 (UTC)Reply[reply]
Just tested this and it works perfectly - thanks! By the way, this solves some issues I had finding a way to better automagically create pages with templates so double thanks.    Thorncrag   17:14, 18 October 2011 (UTC)Reply[reply]

Okay so I'm here brainstorming. I'm thinking about splicing the functionality of forminput and autoedit. The goal would be to have a form input where you specify the target page (instead of having it hard-coded in the autoedit tag) and the autoedit which makes the automatic editing for that page. This could have numerous useful applications like quickly creating new lightweight tools such as for maintaining pages. Is this something that can be cobbled together already?    Thorncrag   17:34, 18 October 2011 (UTC)Reply[reply]

That's an interesting idea, though somewhat weird - it would basically apply the same set of changes to any page name that was typed in, even a string typed in in error. Maybe a better idea would be to put add one or more #formedit links to each of the relevant pages, via a template, so that users can apply those automatic edits only to pages where it makes sense to do it? Yaron Koren 18:16, 18 October 2011 (UTC)Reply[reply]
There are two examples I can think of - and perhaps there's already a better way of doing this that I'm not grasping. One would be, let's say you wanted to create candidate and ballot pages, you would enter the name of the page (the candidate) and the page would be created automatically. Another example might be to create report pages so that the input would be the name of the page to be created.    Thorncrag   16:46, 19 October 2011 (UTC)Reply[reply]
That's reasonable, yes - though, in both cases, wouldn't there be a good chance that the user would want to add some information in about the candidate/report/etc. at the same time? Yaron Koren 16:51, 19 October 2011 (UTC)Reply[reply]
That's a fair point. I think I'm stuck on the notion that the created page might transclude other templates and pages with bits of information. In my case, I was thinking of a way of guiding the user through a process where they would create a "landing page" using the autoedit process, and that landing page would guide them through a series of other processes and components. But I suppose that's not a very common way of using these features.    Thorncrag   17:00, 19 October 2011 (UTC)Reply[reply]

Fatal error: Unsupported operand types

MW 1.17/Semantic Forms:2.2.1

I am trying to create an upload field and get the following error when I upload an image:

Fatal error: Unsupported operand types in /home/offgrido/public_html/foreclosurepedia/includes/parser/LinkHolderArray.php on line 41

My code is:  ! Image | {{{field|Image|input type=text|uploadable}}} |-

I run the wiki on https and the lock does appear next to the upload button. My site is here. The form cannot be accessed by the public though. Any help would be appreciated! --Coffeehound 03:58, 17 October 2011 (UTC)Reply[reply]

Spoke with Yaron on #MediaWiki and was told this may have something to do with an issue surrounding Semantic Maps and may be corrected by the next build in Semantic Bundle. Will report back when I install the new build. --Coffeehound 04:32, 17 October 2011 (UTC)Reply[reply]

Upload fancyBox asking me to log in?

When i click upload next to my field for an image, i get fancy box showing the message "You must be logged in to upload files" with a login link. If i click the link i get a blank fancy box window. I had this working somehow earlier on a different form but deleted it. My Property type is text is that ok? Heres my field code...

! Image: | Image

Image property is set to "This is a property of type Has type::String." does this need to be anything special for a file? I sometimes get session data dropped while i'm working but don't know how to track it down, that is the only other thing i could think would cause it. I tried using admin, sysop, and user logins and all had the same problem.


Multiple and "show on select" not working together

I've got a form that includes a dropdown field that gets filled with certain values based on selection from another dropdown field. I'm using on show on select= and have div id sections, and it works fine.

But when I indicate multiple for the form, the first record works fine, but the next few records show the fields cleared.

I created an example of what I’m talking about on Referata:

Perhaps with multiple there are some instance problems, perhaps label issues that keeps this from working while editing. Is there any way to do the equivalent of what I'm doing with multiple, or do I have to change to saving my records on separate pages and using a query to make them appear on the same page? Is this a bugzilla candidate?

Thanks --Salquint 02:37, 22 October 2011 (UTC)Reply[reply]

Hi - I see what you're trying to do, and unfortunately it can't be done. You can't include the same template field in a form more than once. I'm pretty sure that what you're trying to achieve is different allowed values for a "secondary" field based on a "primary" field. That unfortunately won't be possible until there's a "values dependent on" parameter, which is right at the top of the current planned features list. I don't know when it'll get done, though. Yaron Koren 16:15, 23 October 2011 (UTC)Reply[reply]
Thanks for the verification Yaron, that makes sense. I'll skin this cat another way for now. --Salquint 21:41, 23 October 2011 (UTC)Reply[reply]

Show on select not working

Hi all,

I can't get the "show on select" to work. II simply do not get a drop.-down menu but a simple text input. at the same time all the diifferent section are rendered. I have tried this with the code of the discoursedb, too. It is not working either.

I am running MW 1.16.0 and Semantic Forms 2.2.1

I have used firebug to copy some of the code from my wiki and from discoursedb.

My Wiki

<th> Publication type: </th>
<span class="inputSpan">
<input id="input_2" class="autocompleteInput createboxInput ui-autocomplete-input" type="text" autocompletesettings="Publication type" tabindex="2" size="35" value="" name="Source[type]" autocomplete="off" role="textbox" aria-autocomplete="list" aria-haspopup="true">
<div id="circulation">
<div id="unique-visitors">


<th>Publication type: </th>
<span class="inputSpan">
<select id="input_3" class="createboxInput sfShowIfSelected" name="Source[type]" tabindex="2">
<div id="circulation" style="display: none;">
<div id="unique-visitors" style="display: none;">

I seems that in my wiki the wrong class for the field is used. I am no programmer, so I have no idea whre to go from here :-(

Any Help is appreciated,

Moritz, Karlsruhe, Germany 24.10.2011 14:15 GMT+1

If the input is a text input, not a dropdown, then "show on select" won't work - so that's the problem. You need to set the SMW property for that field to have a set of "allowed values" - maybe that's the issue? Yaron Koren 13:38, 25 October 2011 (UTC)Reply[reply]

I got it working, thanks Yaron. For those, having the same problem as I had: The solution is ti set the "Allows Value" property for the property linked to the field to the same values as the input values for the "show on select" → see here

Moritz, 14:17, 25 October 2011 (UTC)Reply[reply]

MultipleValues Input Types

Hi all, I stumbled upon a problem setting up a semantic form:

I want to allow for a field in the form to have multiple values. But I just want to suggest some (most common) values. The user should also be able to add a non suggested value. The user could then choose values by clicking checkboxes and add a non listed term at the same time. Theoretically I could use input type text with autocompletion, but then the user wont see a checkable list of the most common values, maybe not even considering them

An Input type such as "checkboxplustext" would be great. Predefined values will be displayed as checkboxes followed by a textfield. Using two different fields eith the same name, but different Input types doesn't work. Or better yet a combobox allowing multiple values.

any help is much appreciated. Thanks, Markus. 16:16, 25 October 2011 (UTC)Reply[reply]

Input Similar to that found in Semantic Search

In the Special:Ask form on my site, the Additional data to display box uses an input format that would be very useful on some of my forms. It forces each entry to be on a new line and includes an autocomplete on properties. Is such an input format available somehow through SF? Thanks. --Salquint 09:25, 29 October 2011 (UTC)Reply[reply]

Well, it depends on how similar you want it to be, but in the "textarea with autocomplete" input type, I think you can have "delimiter=\n" instead of the default, which is a comma. Yaron Koren 02:07, 4 November 2011 (UTC)Reply[reply]

Radiobutton input

For the edit with form, when people can input witha radiobutton, is it posible to allow selection of more than one? So, if the radiobutton gives the option of TPL, JAK3 and a few others, can it be made so the editor can select both?--Technobliterator 19:44, 29 October 2011 (UTC)Reply[reply]

For that, you should use the "checkboxes" input type. (Or "listbox", but that's more like a dropdown.) Yaron Koren 20:17, 30 October 2011 (UTC)Reply[reply]

Field Tag Mandatory Parameter not working

Mandatory Fields are not working. It would flash "cannot be blank" but continues to save.

That sounds like it's due to a Javascript error. Is this on a public wiki? If not, try looking at the Javascript in the console - either with Google Chrome or with Firefox using the Firebug plugin - to try to catch the Javascript error that shows up before the form gets submitted. And if you're using an old version of Semantic Forms, try upgrading. Yaron Koren 02:06, 4 November 2011 (UTC)Reply[reply]

Using query forms with multiple values for properties


I'm having a problem trying to formulate the syntax needed for an #ask query run from a query form and template.

There is a property I wish to filter the query results by and it can contain multiple values (ie is an #arraymap) and is restricted to a list of options.

When using a listbox on the form and selecting just one option it all works as expected. However if multiple values are selected the #ask query does not work, as it checks all the values at once and does not delimit them. I want to check if the property contains value1 OR value2 but the error returned is "value1, value2" is not in the list of possible values (value1, value2, value3, value4).

Does the #ask function support checking more than one value in an arraymap from the form? If not is there a simple way to combine things so that this can be achieved. I couldn't find any example in the documentation, apologies if I missed it.

MediaWiki 1.17.0 Semantic MediaWiki 1.6.1 Semantic Forms 2.2.1

Thanks --James uk 20:24, 4 November 2011 (UTC)Reply[reply]

You can do an "or" within queries using "||" (check the SMW documentation for the exact syntax), but I don't know if you can create such a query using #arraymap - my guess is no. Yaron Koren 03:45, 7 November 2011 (UTC)Reply[reply]

Just in case...

I just updated to the latest SVN and the formlink type button, the form action appears to be broken. It seems to leave out the Special:FormEdit/ part of the URL/form action. Maybe it was just me?    Thorncrag   16:28, 7 November 2011 (UTC)Reply[reply]

Did a quick check and it worked for me. What does your call look like? I tried {{#formlink:form=Event|link type=button|target=123|link text=Edit 123}}
Cheers, F.trott 20:00, 7 November 2011 (UTC)Reply[reply]
Here's the string I use, another that is similar to this call also had the same exact problem, so I assumed it struck all of them: {{#formlink:link text=Create Data Security|link type=button|query string=form=DS_Application&target=DS:{{PAGENAME}}}}. It makes sense that query string might be the culprit.    Thorncrag   22:51, 7 November 2011 (UTC)Reply[reply]
That's an invalid #formlink call - the "form=" parameter has to be set. I think maybe you just misunderstood the syntax - "form" and "target" should be separate parameters, not part of the query string. Yaron Koren 22:58, 7 November 2011 (UTC)Reply[reply]
Yaron, you are right of course. However, that's actually caused it to work even less now... Per your suggestion I changed the call to this:
{{#formlink:form=DS_Application|link text=Create Data Security|link type=button|target=DS:{{PAGENAME}}}}
--- but now the formlink just loads the main page of the wiki. The form action looks correct:
<form class="" method="get" action="/knowledgebase/index.php?title=Special:FormEdit/DS_Application/DS:Foobar"><input type="submit" value="Create Data Security"></form>
I can't tell what I'm doing wrong.
What's interesting is that it was working prior to updating. The NON-working rev is r100116, the working is rev r91012.    Thorncrag   23:29, 7 November 2011 (UTC)Reply[reply]
As a follow-up, after fixing the form and target parameters per Yaron's suggestion, which broke in the SVN version, I reverted back to the last stable and it worked just fine. *shrug*    Thorncrag   23:35, 7 November 2011 (UTC)Reply[reply]
Hi - that's very strange, since (a) it works for me, and (b) that HTML indeed looks correct. Maybe you have some custom Javascript that's interfering? Yaron Koren 02:39, 8 November 2011 (UTC)Reply[reply]
Could be that that colon upsets the handler. I'll check. F.trott 12:23, 8 November 2011 (UTC)Reply[reply]
Could not find anything specific. Then again there were a lot of changes in this area, current revision is 102423. Could you try upgrading again? F.trott 19:22, 8 November 2011 (UTC)Reply[reply]
No change with (r102453) -- also no change removing the colon. Also in case I was not clear, changing link type to text (removing link type parameter) causes it to work fine. I think Yaron might be right it must be something in my environment. I will keep looking and will post if I figure it out.    Thorncrag   23:27, 8 November 2011 (UTC)Reply[reply]

Query form using AND, OR and NOT

Hi Yaron, I realise that this might be a bit of an open question, but would it possible, using Semantic Forms, to create a query interface like the one sketched below:

[AND/OR/NOT] Criterion 1
[AND/OR/NOT] Criterion 2
[AND/OR/NOT] Criterion 3
[AND/OR/NOT] Criterion 4


  1. for each criterion, the user decides from a list box which logical operator (AND, OR or NOT) is used in the query
  2. criteria could be pages, properties, categories, etc.

Straightforward as that looks, it seems mighty difficult to squeeze the OR operator as an option into a query using parser functions for multiple criteria (the choice is between OR and Semantic Compound Query). If anything like it could be achieved, the syntax is likely to be highly complex so that it would be worth adding an example to the documentation.

Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 11:39, 14 November 2011 (UTC)Reply[reply]

I don't know if such an interface would even make sense - what would be the order of operators in, say, "A AND B OR C NOT D"? And whatever it was, could users figure it out? But this type of question is probably better directed to the mailing list. Yaron Koren 13:55, 14 November 2011 (UTC)Reply[reply]
What I meant is the case of a restrictive AND = "must match value" and a broadening OR = "yields results if user entry matches value, but is otherwise ignored". The order would be irrelevant if OR operates on all elements of the query together. In this way, "A AND B AND C OR D" (= "A AND B OR D AND C") would produce either "A AND B AND C AND D" or "A AND B AND C", which isn't terribly unusual. But yeah, that sort of thing probably goes beyond the functionality of SF alone. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 15:24, 14 November 2011 (UTC)Reply[reply]
I think there's an error in your logic there. Yaron Koren 16:38, 14 November 2011 (UTC)Reply[reply]
It may be impractical, but there is nothing illogical about such an inclusive OR. See, for instance, (and http://www.llrx.com/features/flareindexextended.htm), where precisely this kind of interface has been implemented. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 22:12, 14 November 2011 (UTC)Reply[reply]
Sorry - I meant, I think there was an error in the specific logic you stated, with A through D. Not that it really matters, since I still think this is better for the mailing list. Yaron Koren 23:33, 14 November 2011 (UTC)Reply[reply]
It depends on whether you're talking about wiki syntax or the connectors of the search interface, but OK thanks, I won't ramble on about it on this page. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 14:18, 15 November 2011 (UTC)Reply[reply]

Feature request 'values from properties'

In cases where the value used as a parameter of an inline query is associated with two (or more) different properties and you simply want to include that value regardless which of these properties is associated with it, you can use OR, as in:

{{#ask: {{#if: {{{A|}}}|[[Property1:: {{{A|}}}]] OR [[Property2::{{{A|}}}]]}}}}

Another solution would be to make those properties subproperties of Property X, so that only the 'parent property' would need to be included in your inline query.

{{#ask: {{#if: {{{A|}}}|[[Property X::{{{A|}}}]]}}}}

Either way, SF does not currently allow you to set up a combobox which takes its values from multiple properties, nor of course, does the parent property pass on the values of its subproperties if value from property=Property X. So could we, if it's not unreasonable, please have an option to specify multiple properties in values from property (and perhaps likewise, multiple categories in values from category), preferably with a semi-colon as delimiter? Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 14:18, 15 November 2011 (UTC)Reply[reply]

That's a reasonable idea - though I'm pretty sure you can already do that by creating a "concept" that matches that set, then using "values from concept". Yaron Koren 15:19, 15 November 2011 (UTC)Reply[reply]
Ah, I hadn't thought of that, but the problem with concepts in this particular case is that they do not support inverse properties. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 20:47, 15 November 2011 (UTC). I just checked Bugzilla and it appears that the problem has been reported. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 20:52, 15 November 2011 (UTC)Reply[reply]

[BUG] Autocomplete with values taken from an URI property

Hi! I found a strange bug with SF 2.2.1 (used with MW 1.17 and SMW 1.6.1): a field with autocomplete taken from values of an URI property was displaying mad choices (p/a/u/0/JqnR1SR_Gig, p/a/u/0/bv0hezyFpbc, and so on). I corrected the code, and it now works:

Index: includes/SF_Utils.php
--- includes/SF_Utils.php	(revision 96836)
+++ includes/SF_Utils.php	(working copy)
@@ -86,7 +86,7 @@
 			$values = array();
 			foreach ( $res as $value ) {
 				if ( $value instanceof SMWDIUri ) {
-					$values[] = $value->getFragment();
+					$values[] = $value->getURI();
 				} else {
 					// getSortKey() seems to return the
 					// correct value for all the other

I don't know why getFragment was used instead of getURI, but it doesn't work anymore. FlooD 16:57, 16 November 2011 (UTC)Reply[reply]

Thanks for this fix - I just checked it in. Yaron Koren 17:56, 16 November 2011 (UTC)Reply[reply]

Feature idea: Required fields... or not

I am constructing a form that I want users to be able to save and complete at a later time. I would like to make require fields, but these two goals are not compatible as far as I know, the way the system works. What do you think about adding a conditional element to the form that would trigger required fields if that condition is met? For instance, adding a field to the form "Are you finished?" - if set to yes, enable other required fields, if set to no, do not require the fields.    Thorncrag   19:50, 18 November 2011 (UTC)Reply[reply]

It's an interesting idea - though it seems to me that you could mostly accomplish the same thing, with a lot less effort, with just some text at the top that said "Please take special care to fill out the fields...". But I guess it depends on the specific circumstances. Yaron Koren 23:12, 18 November 2011 (UTC)Reply[reply]

standard input free text between a normal template and embed templates results in free text loss

The problem is reproduced at http://example.referata.com/wiki/Some_Person and http://example.referata.com/wiki/Another_Person where the first has currently only one template stored following the free text Something about the person. and the second has free text This is another story. between two templates. In both cases edit form does not pick up the free text and upon saving the free text gets lost. This can be seen also when clicking on "Show changes" after opening the editing form. Joosep-Georg 03:03, 19 November 2011 (UTC)Reply[reply]

Multiple Parameter Not Working

The SF 'multiple' parameter was not working on my installation. I upgraded using the semantic-bundle with Semantic Forms 2.4 alpha and Semantic Mediawiki 1.7 alpha on MW 1.16.0. The 'multiple' parameter is still not working. Below is the code for my forms template.

{{{for template|Update|label=Update - Date / Notes|multiple}}}
|align="top"|{{{field|Date|property=CmDate|input type=date|default=now}}} 
{{{end template}}}

Any thoughts on how to further isolate the problem?

UPDATE -- I upgraded to MW 1.17.0 and the problem resolved itself. On my 1.16.0, I was experimenting with the deployment framework from ontoprise, which might have introduced some conflicts when it patched various files to make MW compatible with both the deployment framework and several of the ontoprise extensions. This is all speculation on my part but makes the most sense as I am no longer using the deployment framework.

Paul Ramer November 24, 2011

Preload property value supplied in form "call"

I would have liked to be able to supply a preload property value in the "call" of a form (Form:<form name> ...) in stead of in the specification of the form (#forminput). If a form is called in a page in order to add an element to a filtered query in the same page, it would be appropriate to preload by the property filter value. --Even Thorbergsen 14:40, 28 November 2011 (UTC)Reply[reply]

Do you mean that you want to preload a value in the form definition? If so, you can use the "default=" parameter. Yaron Koren 14:55, 28 November 2011 (UTC)Reply[reply]
I have no information about the default value until I actually use the form in a page. This page is mainly a filtered query (property value condition). Below the query there is a call to the form in order to add a new element (template-based page) that will be visible in that query if it satisfies the filter value (achieved by preloading this value in the form).
Example: A number of pages for people based on Template:Person with two properties Name and Allergy. Another number of pages for each allergy based on Template:Allergy what queries all Person-pages filtering by Allergy:{{PAGENAME}}. In the Allergy pages you want to be able to add persons with the corresponding allergy, and these only, by using a general Form:Person preloading the proper value, i.e. {{PAGENAME}}, into Property:Allergy. --Even Thorbergsen 10:02, 29 November 2011 (UTC)Reply[reply]
I'm not sure I understand, but you might be asking about being able to put queries into the "default=" parameter, so it looks like "default={{#ask:...}}". Maybe that can be done already, though? I don't remember what the current status of that is. Yaron Koren 04:42, 30 November 2011 (UTC)Reply[reply]
We tried |input type=combobox|default={{#ask:[[...::+]]|format=list|headers=plain|sep=,|link=none|offset=0|limit=20}} but instead of a default list, the error message Invalid argument supplied for foreach() in ...\lab\wiki\extensions\SemanticForms\includes\forminputs\SF_ComboBoxInput.php on line 69 appears because somehow #ask generates text that contains <a href="/lab/wiki/index.php/Special:Ask/-26-2391 --MWJames 07:02, 30 November 2011 (UTC)Reply[reply]

Feature Request - new input type

Dual list boxes! --Dgennaro 02:34, 30 November 2011 (UTC)

Could you... elaborate? :) Yaron Koren 04:44, 30 November 2011 (UTC)Reply[reply]
It is probably just easier if I attach an image. --Dgennaro 05:05, 30 November 2011 (UTC)
Oh, that's interesting. You tend to see those more in desktop applications than on the web, I think. If you can find a Javascript library that supports it (ideally one based on jQuery UI), there's probably a much better chance of an SF input being made for it. Yaron Koren 15:40, 30 November 2011 (UTC)Reply[reply]
Here is a link to a plugin listed on the jQuery website....and here is an example.
And here are two more (just in case):D
--Dgennaro 17:36, 30 November 2011 (UTC)
I like this idea because you can use the DPL extension to pull a list of potential items to appear in a list. It could perhaps even use the multi-template option, although that's getting more complicated :-)    Thorncrag   19:31, 30 November 2011 (UTC)Reply[reply]

What would this have to do with DPL? It's just a different way to modify a list of values - akin to "listbox" or "checkboxes". Yaron Koren 22:17, 30 November 2011 (UTC)Reply[reply]

One could make the available list dynamic instead of hardcoded based on some criteria.    Thorncrag   19:25, 8 December 2011 (UTC)Reply[reply]

SForms 2.3 broken with MW 1.18.0

SForms 2.3 release is broken with MW 1.18.0 release. Yaron mentioned in IRC you have to upgrade to a later version of SForms or go with SVN.--Olivier Beaton 15:37, 30 November 2011 (UTC)Reply[reply]

Return to "Page Forms/Archive October to November 2011" page.