Extension talk:Page Forms/Archive September to December 2014

Loading Screen

I'm having a bit of trouble adding a loading screen for when you click the submit button on image upload in the Special:UploadWindow. That way the user knows something's happening on long uploads. Any ideas on where in SF_UploadWindow.php I can get that work the best? Thanks

"Edit" tab showing when only "Edit with form" should be

Mediawiki 1.18 - SB 1.8.04 - PHP 5.3.21 - Mysql 5.1.73

The "edit" tab was not available until I made some changes to user rights in order to not require email authentication for regular users to edit pages. (Questy Captcha had eliminated all spam so I thought there was no reason to require email authentication)

But now the "Edit" tab is showing for regular users and I can't seem to figure out the right combination of GroupPermissions to make the "Edit" tab NOT show on pages where a form is used.


$wgEnableEmail = true;

$wgEnableUserEmail = true; # UPO

$wgEmailAuthentication = false; // require email authentication for using any email function (except password reminder which works independently from this setting)

$wgEmailConfirmToEdit = false; // Require a confirmed address to edit pages

$wgGroupPermissions['*']['viewedittab'] = false;

$wgGroupPermissions['user']['viewedittab'] = false;

$wgGroupPermissions['sysop']['viewedittab'] = true;

$wgGroupPermissions['*']['edit'] = false;

ConfirmEdit settings:

$wgGroupPermissions['*' ]['skipcaptcha'] = false;

$wgGroupPermissions['user' ]['skipcaptcha'] = false;

$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false;

$wgGroupPermissions['bot' ]['skipcaptcha'] = true; // registered bots

$wgGroupPermissions['sysop' ]['skipcaptcha'] = true;

$wgGroupPermissions['emailconfirmed']['skipcaptcha'] = true;

$ceAllowConfirmedEmail = true;

If anyone can spot where I've gone astray, I would appreciate it.

Thanks in advance!

Are the "viewedittab" settings done after the inclusion of Semantic Forms? Yaron Koren (talk) 23:21, 5 September 2014 (UTC)Reply[reply]
Nope, they we not - but they are now and that did the trick. Thanks Yaron! DaveL (talk) 04:12, 6 September 2014 (UTC)Reply[reply]

Problem with language on wiki family

Hi, we love your extension and use it for our software documentation. Thanks for your great work!

Now I ran into a little problem with some language configurations. We run a wiki family (used method is described here, MW 1.21.1, SF 2.6.1) and now for the first time we set up a wiki in English insteat of German. Now SF seems to be confused by that, because some words are in german (like "This is a property of type Zeichenkette".) I already set $wgLanguageCode to 'en' in the shared LocalSettings.php but it doesen`t seem to work. I know there could be a lot of reasons depending on the configuration of our wiki family, but the other extensions work just fine. So I hope someone has an idea or has experienced this problem before.

Thanks! Prev (talk) 08:38, 10 September 2014 (UTC)Reply[reply]

That really shouldn't happen... could it be that the setting of the language, etc. is being done after the inclusion of Semantic Forms? It should be done beforehand. Yaron Koren (talk) 16:06, 10 September 2014 (UTC)Reply[reply]
Hi Yaron, thanks for the quick reply. That was my first thought too, so I moved the language setting to the shared LocalSettings.php of the wiki family. So it's definitly beforehand, but the problem remained. Prev (talk) 12:02, 12 September 2014 (UTC)Reply[reply]
What do you mean by "the problem remained"? The text you referred to earlier has already been set - it's in the page wikitext. Does the same problem keep happening to you now if you create new properties? Yaron Koren (talk) 12:58, 12 September 2014 (UTC)Reply[reply]
Oh, sorry for being unclear. Yes, the problem remains when I create new properties. Prev (talk) 12:40, 16 September 2014 (UTC)Reply[reply]
Hi Yaron. We finally found the error - after all it was an error in our wiki family configuration. Thanks again for your help and your great extension! Prev (talk) 08:43, 17 September 2014 (UTC)Reply[reply]
Oh, that's great to hear. Yaron Koren (talk) 22:40, 17 September 2014 (UTC)Reply[reply]

Prepend default filename?

I have a multiple instance template for uploading files, and I'd like to use default filename as the beginning of the users filename. So if the user uploads a file called "logo1.jpg", the destination filename will be "subpagename-logo1.jpg". Is this possible to change?

I thought I could add it to this part of the code in sf_uploadwindow, but everything I do just keeps a destination filename from showing at all.

$this->mDesiredDestName   = $request->getText( 'wpDestFile' );
		if ( !$this->mDesiredDestName )
			$this->mDesiredDestName = $request->getText( 'wpUploadFile' );

Would appreciate any help, since users keep overwriting each others images with dumb names like "1.jpg".

Form/Template Data Has to be on the page?

Excuse this newbie question but what I am trying to do is make a wiki for a game and the loot that is dropped by the different creatures in the game. What I want is to simply be able to run a #Ask on the creature page and a list of what loots the creature has will be listed. Works great! BUT http://wiki.afterworld.ru/index.php?title=DaleTest916 Why do I have to produce also each type of loot listed on the page also. Note the page I linked. The template Creature-Loot looks like this to get the screen I currently have on the page:

This is the "Creature-Loot" template.
It should be called in the following format:
|Loot Creature=
|Loot Maturity=
|Loot Version=
|Loot Item=
|Loot Frequency=
|Loot Still=
Edit the page to see the template text.
{| class="wikitable"
! Loot Creature
| [[Loot Creature::{{{Loot Creature|}}}]] 
! Loot Maturity
| [[Loot Maturity::{{{Loot Maturity|}}}]] 
! Loot Version
| [[Loot Version::{{{Loot Version|}}}]] 
! Loot Item
| [[Loot Item::{{{Loot Item|}}}]] 
! Loot Frequency
| [[Loot Frequency::{{{Loot Frequency|}}}]] 


Now I want to eliminate the individual lines of each loot on the DaleTest16 page. So I remove or remark or get rid of the table in the <includeonly> section of the template. Great the lines are now gone but my #Ask on the page is also empty. The DaleTest16 PAge still lists each of the loots with items like

But since the Template does not have the output table in it, the page itself does not have each individual table visible. Make sense. Now comes why im confused. The data for each loot in listed on my page as Creature-Loot just fine. Why do I have to have it be visible for that data to also show up on a #ask statement? Thanks!

|Loot Creature=DaleTest916
|Loot Item=Dale Blood
|Loot Maturity=Small
|Loot Frequency=Often
|Loot Version=
|Loot Still=Yes
That's not a Semantic Forms question, but you can accomplish that by replacing the table with something like "{{#set:Loot Creature={{{Loot Creature|}}}|Loot Maturity={{{Loot Maturity|}}}| ... }}". Yaron Koren (talk) 21:43, 16 September 2014 (UTC)Reply[reply]

Mapping template example

Yaron and others, could you please give me a simple example of the new mapping template functionality in a wiki instance? Jaider msg 00:08, 17 September 2014 (UTC)Reply[reply]

Multiple template: Edit section SOLVED!

Hello, I have a multiple template that's filled with a form. The template fills sections of a page, running text. I have formatted the first parameter as a section heading. Now, there are the usual "Edit" links on the page next to the section headings. But they are redirecting to the template part (the multipliable part) instead of the form. Is there a way to edit those sections with the form? It would be very nice, if you could only click on the one part and don't have to scroll through 20 parts while editing. This is the template (part):

===[[has title::{{{Title|}}}]]===
'''Problem:''' [[has problem::{{{Problem|}}}]] 
'''Solution:''' [[has solution::{{{Solution|}}}]] 

And this the form (part):

{{{for template|Problemsolution|multiple|label=Problemsolution}}}
'''Title:''' {{{field|Title}}} 
'''Problem:''' {{{field|Problem|input type=textarea}}}
'''Solution:''' {{{field|Solution|input type=textarea}}}

Nothing uncommon. Any ideas if editing multiples with forms in single sections is at all possible? --Zabien (talk) 00:08, 18 September 2014 (UTC)Reply[reply]

It's not, and you should put in a "__NOEDITSECTION__" in any one of the templates that appears on that page, so that the "Edit" links don't appear. Yaron Koren (talk) 02:55, 18 September 2014 (UTC)Reply[reply]
I see, and will do exactly that. Thanks for the quick reply! --Zabien (talk) 12:32, 18 September 2014 (UTC)Reply[reply]

Conditional formatting according to properties

Hello, another little question, though I am not sure, if this is the right place to ask it. Is there a simple way of adding conditional formatting to a template that gets filled with a form and annotated properties? Let's say, there is a property:has Priority, and priority A should color the section red, B orange, C yellow… and so on. I've searched and tried a lot, but only found info about conditional formatting for tables.

Goal is to let the user choose an option within a form (+ template) and according to the answer display a certain formatting.

I guess, it's not going to work with the #if parser function, instead I've tried to use #switch like this:

<div style="background-color:#{{#switch:{{{Priority}}}
|#A = faa8a8
|B = facba8
|C = faf1a8
|#default = e1e4e2}};">



It's not reacting at all, if within <span> tags, but gives out the value of #default, when within <div> tags. (I fear I might have totally misunderstood the concept here?)

MediaWiki uses something like this in the Extension template, but it's hard to make out the relevant parts...

Would very much appreciate any hints. --Zabien (talk) 00:29, 18 September 2014 (UTC)Reply[reply]

This is indeed not the right place - it's not a Semantic Forms question. Yaron Koren (talk) 02:57, 18 September 2014 (UTC)Reply[reply]
Okay, thank you, I've tried again there. Should I delete this thread here or just keep it in? --Zabien (talk) 12:47, 18 September 2014 (UTC)Reply[reply]
It's not really an SMW question either... it seems like a ParserFunctions question. But if you can get an answer, no problem. You can either delete this or not - up to you. Yaron Koren (talk) 13:58, 18 September 2014 (UTC)Reply[reply]
Oh boy… to me, everything that has properties, is semantic… but, well, I'll see and will have to dive even deeper into parser functions, then. I'll leave this to keep your nice words. Zabien (talk) 14:58, 18 September 2014 (UTC)Reply[reply]

Multi-instance template with geographic coordinate with input type=map

I can't seem to get it to work inside a multi-instance template, but it seems to work fine in a "regular" form.

screenshot here --Jnatividad (talk) 01:39, 19 September 2014 (UTC)Reply[reply]

Yes, I believe that's a known problem, unfortunately - part of the larger problem of Javascript (other than SF's built-in Javascript) not working in new instances of multiple-instance templates. Yaron Koren (talk) 14:00, 19 September 2014 (UTC)Reply[reply]
Thanks Yaron for the quick reply. Can you suggest a workaround? I was wondering if there's a way for me to prompt for number of instances when a form is first created, and then and then dynamically create the instances when the re-edit the form. As you pointed out, the map input type works just fine for existing instances. --Jnatividad (talk) 21:26, 19 September 2014 (UTC)Reply[reply]

Embedding query forms with wpRunQuery=true

I tried to embed a run query form with wpRunQuery=true


fails with Error: No form was found on page. Is wpRunQuery=true in combination with embedded run query possible in general?

--Planetenxin (talk) 07:41, 7 October 2014 (UTC)Reply[reply]

Hi - I think this is a MediaWiki issue; I don't think a query string can be included in the standard page transclusion. I'm not 100% sure about that, though. Yaron Koren (talk) 21:07, 7 October 2014 (UTC)Reply[reply]
As far as I understood from http://www.mediawiki.org/wiki/Transclusion#Special_pages, this should be possible. --Planetenxin (talk) 12:08, 9 October 2014 (UTC)Reply[reply]
Oh, I see. Well, perhaps the issue is just that you're using "?" and not "|". Yaron Koren (talk) 13:13, 9 October 2014 (UTC)Reply[reply]
Yaron, sorry I did not mention:
will show the embedded query, but the query is not executed automatically (need to click the button first). --Planetenxin (talk) 07:13, 10 October 2014 (UTC)Reply[reply]
Oh. I don't know, then; sorry. Yaron Koren (talk) 13:16, 12 October 2014 (UTC)Reply[reply]

Define output values for checkboxes using templates with boolean type

Hi there,

I have a question concerning the output values of checkboxes.

The problem itself

I am creating pages with a form (based on a template) using several checkbox inputs. The parameters in the template have attributes with the datatype boolean.

In the created pages the values of these inputs should not be displayed by "yes"/"no", "1"/"0", ... as these are not quite noticable.

A preferred solution would be a definition of checkmark and cross (with unicode) or something like that, if possible with some increasing style. Nevertheless I have no idea how i can override the standard boolean values, which obviously needs to be the first step.

My implementation


* [[attSomeAttribute::{{{TemplateParameter}}}]] Description of the parameter


| {{{field|Name of field|input type=checkbox}}}
!style="text-align:left"|Description of the parameter

I hope the description of my problem is quite understandable.

Thanks in advance --Marc

It is quite understandable! You should have something like this in the template:
{{#set:attSomeAttribute={{{TemplateParameter}}} }} {{#ifeq:{{{TemplateParameter}}}|True|...checkmark text...|...cross text...}}
...or, instead of "True" there, whatever the checkbox input type sets the value to, if the checkbox is selected. Yaron Koren (talk) 21:17, 7 October 2014 (UTC)Reply[reply]

Access Parameter Value from Form Article

Having some fun with dynamic form display based on templates. Wondering if it's possible to pass a parameter to the Form (ie. from #formlink) for use in display of the Form (not as a field value). Basically, to use a <template[field-name]> value but outside of the {{{info}}} tag, in the Form article. I guess kind of like how a template behaves.

ie. Specify |myparameter=myvalue in the formlink (or with query string=) and then accessing it with {{{myparameter|}}} in the Form article. I'm trying to pass it the name of a template to use. Would mean I'd only need to maintain one form (instead of 50+) for my application. Thanks! - Lbillett (talk) 01:41, 10 October 2014 (UTC)Reply[reply]

I don't think you can do that, just because the name of the template (defined in the "for template" tag) isn't parsed. Though it's possible that you could add a tiny bit of code to the SF code to get that working... still, it seems strange that you have more than 50 forms, each with a different template, but with the same set of fields for each (if I understand it correctly). Perhaps there's a way to change the whole thing to just one template? Yaron Koren (talk) 13:19, 12 October 2014 (UTC)Reply[reply]
Ah, I figured as much. It's a bit of a weird application. My form defines a bunch of generic fields (item1, attr1, item2, attr2, etc) and populates the default= values for each by calling a template. 'telling' the form which template to use via formlink would've been snazzy, but is by no means a deal-breaker. Aim is to generate multiple checklists that display/hide fields based on the date (or other conditions). I think I can define the specific part(s) of each form and pull in the common body via template as per here. Thanks! - Lbillett (talk) 12:07, 14 October 2014 (UTC)Reply[reply]

Using Semantic Forms with Semantic Title

I am using Semantic Title to set the Title of a page to the value of a Semantic Property on the page. When I use Semantic Forms to select a value from the category with a dropdown it uses the actual name of the page rather than the Semantic Title in the dropdown box. However when the page is saved it shows the Semantic Title in the field, which is what I want. I'd like to be able to show the Semantic Title in the dropdown rather than the actual title and wondered if anyone has tried this and got it to work. The field definition I am using is:

{{{field|Classero|input type=dropdown|values from category=Classeros|existing values only}}}

I've also tried using Semantic Forms Select using a query to work around this problem as follows:

{{{field|Owner|input type=SF_Select|query=((Category:Membres));sep~,;format~list;link~all;headers~hide}}}

If I enter this query directly on a page it correctly shows the Semantic Title with a link to the correct page, but when I use it in semantic forms the dropdown shows a list of semantic property lookups such as:


and the field after the page is saved shows:

[[has Owner::Johny]] 

Where Johny is a link to the correct page but I don't want to have the semantic property mark-up showing in the field.

I've also tried using an alternative query with Semantic Form Select as follows:

{{{field|Owner|input type=SF_Select|query=((Category:Membres));?Has Name;sep~,;mainlabel~-;format~list;link~all;headers~hide}}}

This correctly shows the Semantic Title in the dropdown. Once the page is saved however, it contains the the value of the Semantic Title but not as a link to the correct page. Instead it is a red link as a page doesn't exist with that title.

Any thoughts would be most welcome.


Try using the "mapping template" feature, new in SF 2.8. Yaron Koren (talk) 13:20, 12 October 2014 (UTC)Reply[reply]

Hi Yaron, thanks for your speedy and helpful response. I tried this suggestion but at the moment it doesn't quite work as expected. I have my field definition as follows:

{{{field|Classero|property=Has Name|input type=dropdown|values from category=Classeros|mapping template=GetEntityName|existing values only}}}

And the mapping template contains:


In this case the dropdown contains a list of entries in the form <-!LINK x:xx->. If I select one of these, the field correctly contains the link to the selected page using the SemanticTitle as I wanted.

I then tried the mapping template containing:

{{#semantic-title: {{{1}}}}}

This time the dropdown list correctly showed the semantic names. When I select one, however, the field just contains the text of the semantic name rather than the link.

I wonder if I have misunderstood the function of the mapping template? I expected that the two field statements above would both return a link to the desired page. I expected that the mapping template would just alter the 'alias' of the selected item in the dropdown not the value returned.

I'd be very grateful if you have any further thoughts.


I don't quite understand - could you clarify what appears in the form vs. what appears in the resulting wikitext? Yaron Koren (talk) 18:51, 19 October 2014 (UTC)Reply[reply]

Thanks Yaron for your help and apologies that I wasn't clear before.

I am using Semantic Title on the pages in my wiki. The real title of the page is:


and the Semantic Title of the page, contained in property "Has Name" is:

Uno Metrico

The field definition on the form is defined as follows:

{{{field|Classero|input type=dropdown|values from category=Classeros|mapping template=GetEntityName|existing values only}}}

Example 1

In this example the template GetEntityName contains:


when selected the field dropdown shows:

 <!-- LINK 0:0-->
 <!-- LINK 0:1--> 
 <!-- LINK 0:2-->

and when saved the page shows (as a link to the desired page):

Uno Metrico

and the page source contains:


Example 2

In this example the template GetEntityName contains:

{{#semantic-title: {{{1}}}}}

The field dropdown contains:

Uno Metrico 

The saved page shows (as a redlink):

Uno Metrico

And the page source contains:

|Classero=Uno Metrico

What I want to achieve is that the dropdown shows the Semantic Titles of the pages (as in example 2) but the field when saved contains a link to the selected pages (as in example 1). I wonder if I have misunderstood the function of the "mapping template" as I expected the returned value to be the same in both cases (eg as in example 1)?

Oh, I see. I'm not surprised that either one is failing; though the way in which they're failing is unexpected. But what you need is a #show statement - so if the semantic property that holds the title is called "Title", the template should hold something like "{{#show:{{{1}}}|?Title}}". Yaron Koren (talk) 01:51, 20 October 2014 (UTC)Reply[reply]

Fantastic Yaron, thanks so much - that works perfectly. I hadn't really appreciated the difference between #Ask and #Show in this circumstance, so I must acquaint myself better with these functions. Semantic Forms seems a really powerful Extension so thank you for that too. Duncan

Firstly, thanks for your help so far and apologies because I'm a novice. This worked great last week but when I returned to it this week I found it had gone back to the prior behaviour! I had a dig around in the code and found that the label returned by the dropdown field after selection wasn't matching the label stored in the possible_values array. It seemed to have additional whitespace added. As a result, the erroneous label was returned and stored rather than the associated value from the possible_values array.
I managed to get around this by trimming the $label parameter passed to the labelToValue routine in SF_Utils.php as follows:
$label = trim($label);
and also trimming the $label values used to create the $labels array in the getLabels routine in SF_Utils.php as so:
$label = trim($wgParser->recursiveTagParse( '{{' . $templateName . '|' . $value . '}}' ));

I'm a bit worried about this change in case it could cause problems elsewhere and also means I'm now running non-standard code. I wondered if you had any thoughts why this might be occurring or if the work around I've addopted has any risks associated with it?

Many thanks, Duncan 15th Nov 2014
Hi - it's great that you found a fix! No, I don't think it would cause problems. I just checked in a similar fix, based on your trim() suggestion. If you don't want to run non-standard code, feel free to revert your changes and upgrade to the latest code; and if you do, please let me know if you run into any problems. Yaron Koren (talk) 19:46, 16 November 2014 (UTC)Reply[reply]
Hi Yaron. I did try the latest code but in my case the problem reoccurred so I've reverted to my revised version for now. Hopefully you will be able to incorporate something that solves this in future. Many thanks, Duncan (21st November 2014)
Aha - the latest code DOES work. It was a silly error in my template that was adding the extra lines paces in the first place! Duncan (29th November 2014)

Support for the pattern attribute

Yaron, it would be cool if Semantic Forms could have support for the html5 pattern attribute, don't you think?
Thus, the pattern= parameter in the {{{field}}} tag would just send the regular expression to the pattern= attribute in html. Without the need for JavaScript, etc. Jaider msg 13:57, 12 October 2014 (UTC)Reply[reply]

Yes... although the case for that would be stronger if Safari supported it as well. Yaron Koren (talk) 22:10, 12 October 2014 (UTC)Reply[reply]
Ok, well, at least according to this, Safari "supports the pattern attribute, but do not support form validation, so will not prevent an incorrect value from being submitted, but do support the UI pseudoclasses". So it would not do any harm, I think. And according to this: "Opera 9.5+, Firefox 4+, Safari 5+, Internet Explorer 10 and Chrome 5+ are the only browsers with support for pattern at present [February 26th, 2013]. However, with the browser market moving at a fast pace, the others will soon catch up". Jaider msg 22:40, 12 October 2014 (UTC)Reply[reply]
Oh, okay. You're right that it wouldn't do any harm; maybe it's a good idea. Yaron Koren (talk) 22:55, 12 October 2014 (UTC)Reply[reply]


Mediawiki 1.23.5. I get message "This appears to be a cross-site request forgery; canceling save" when hitting save or preview on page Special:CreateProperty. However if I disable Extension:ShortUrl everything works fine. --StasR (talk) 11:16, 17 October 2014 (UTC)Reply[reply]

Hi - that's unfortunate, although I don't know if there's anything I could do about it. Perhaps the ShortUrl extension's Javascript should be set to not take effect on special pages? Yaron Koren (talk) 16:36, 17 October 2014 (UTC)Reply[reply]
Hi! As far as I can see ShortUrl extension's Javascript is not inserted into the special pages: sample. --StasR (talk) 21:09, 17 October 2014 (UTC)Reply[reply]
Oh. I don't know, then. Yaron Koren (talk) 18:45, 19 October 2014 (UTC)Reply[reply]

textarea didn't parse the first line of the content

mediawiki 1.24wmf21

when i create a form, having a field, it's input type=textarea

then i edit this form, input something like this:


then i got

  • 222
  • 333,

i debug these html code, found that the first line"111" is


is there anyone can help? or tell me witch part of the SemanticFoms'code is handling this process. Extirpate (talk) 18:16, 17 October 2014 (UTC)Reply[reply]

i found that this is not the problem of semanticforms, this is a great extension. My problem is the ul or ol nested in the table cell.
        for example:
        if i make a normal table, and type in 
        the first *1 acts innormal, and i don't know how to fix it .Extirpate (talk) 18:17, 17 October 2014 (UTC)Reply[reply]
You just need to add a newline to the template so that the template parameter that holds that bulleted list is on its own line. Yaron Koren (talk) 18:47, 19 October 2014 (UTC)Reply[reply]
thx very much. I should add a new line in the table cell, it works. And there's another problem, when i am trying to do a semantic search using the {{#ask:}} , if the result format is table, and some of the table cell has

again, the same problem ocurrs. And because this table is made up by the Semantic Extension, i can't do anything to help. 12:55, 13 November 2014 (UTC)Reply[reply]

That's too bad - I thought that problem with the "table" format was fixed, but I guess not. In any case, that's a problem with the Semantic MediaWiki extension, not Semantic Forms. Yaron Koren (talk) 16:43, 13 November 2014 (UTC)Reply[reply]

Work-around for un-populated red link A very long page name error

When using a semantic form to populate a property of type page which is set to "Create pages with form" I get an error if the page doesn't already exist. The title for the page being edited shows "Some very long page name that will hopefully never get created ABCDEF123" and there is a bunch of garbage in the page. After the page is automatically created by a job the error goes away. I confirmed here that this is a known issue: http://www.referata.com/wiki/User_talk:Yaron_Koren#Unpopulated_red_links_create_Some_very_long_page_name_error.

I'm hoping to figure out a work-around if it is possible in my case. I am able to re-create this with a very basic setup as outlined here:

  • Form
This is the "Example Form" form.
To create a page with this form, enter the page name below;
if a page with that name already exists, you will be sent to a form to edit that page.

{{#forminput:form=Example Form}}

<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Example Template|multiple}}}
'''Ex Field:''' {{{field|Ex Field}}}

{{{end template}}}

'''Free text:'''

{{{standard input|free text|rows=10}}}

{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
  • Template
This is the "Example_Template" template.
It should be called in the following format:
|Ex Field=
Edit the page to see the template text.
'''Ex Field:'''  [[Ex Prop::{{{Ex Field|}}}]] 
[[Category:Ex Category]]

  • Category (Ex Category)
[[Has default form::Example Form]]
  • Property (Ex Prop)
This is a property of type [[Has type::Page]]
[[Creates pages with form:: Example Form]]

I can confirm that replacing this line; Creates pages with form:: Example Form, with something that points to en empty form / template; Creates pages with form:: Auto Create F, which doesn't allow for multiple instances still causes the error.

That's pretty bad. I have to confess that I haven't looked into this issue in a while, but my understanding is that, before, it only happened in special cases, and now it seems like it might happen even in basic circumstances. I hope to look at it, but until it's fixed it could be that the best option is just to not use "Creates pages with form", unfortunately. Yaron Koren (talk) 15:31, 27 October 2014 (UTC)Reply[reply]
Thanks, I hope it is an easy fix. In the meantime I'll try to come up with another way to accomplish what I need. SubtleAphex (talk) 00:11, 28 October 2014 (UTC)Reply[reply]

Default Form displacing position of another Template on same page

I currently have two templates on one page. Both have forms but because you can only have one default form the other one is just there without the form as free text. So the free text is Artist info on top and the second template with form is for albums info below artist info (multiple albums). The problem is every time I edit the albums form which is the current default form when clicking edit-with-form, pushes down the artist info template which is in free text to the bottom of the page. So I have to go back to edit-source and move the artist template back to the top to rearrange it. Is there a method to fix this or a way around to this?

You should have both templates in the form - why not have both? Yaron Koren (talk) 19:38, 2 November 2014 (UTC)Reply[reply]

noinclude and includeonly

Hi Yaron, a recent post in the SMW mailing list has made me think again about the benefit of transclusion with SMW. The example I gave there was that you have pages that represent news items and a query with the 'Embedded format' would collect, say, the 10 most recent items on one page, much like a blog; but this is only one of many possible use cases.

To control what should get transcluded and what shouldn't, you'd need at least one of the three tags 'noinclude', 'includeonly' and 'onlyinclude'. Unfortunately, though 'onlyinclude free text' provides a limited opportunity, this is not always possible using SF. What do you think about using 'for template' to surround templates with the noinclude or includeonly tags, e.g.

{{{for template|...|noinclude}}}
{{{for template|...|includeonly}}}

Would this be possible at all? Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 23:47, 3 November 2014 (UTC)Reply[reply]

It sounds like a massive hack. Why not just query the news data semantically, then display it with a template? Yaron Koren (talk) 00:16, 4 November 2014 (UTC)Reply[reply]
Storing everything semantically can be quite expensive and SMW is just not terribly good at storing and reproducing larger chunks of text, e.g. SMW has trouble coping with internal links (there's $smwgLinksInValues but it's risky); 'special' syntax (italics and the like) often does not render on Special:Ask, which you'd need to use for 'further results'; etc. In other words, transclusion through the 'Embedded' result format would actually be less of a hack from the user's point of view if only a semantic form offered a little more leverage. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 08:32, 4 November 2014 (UTC)Reply[reply]
Well, you can get around the links problem by using #set; but that's clearly only part of the issue. Anyway, I don't know if it would be possible; my guess is no, but I've seen stranger things done with SF. Yaron Koren (talk) 16:58, 4 November 2014 (UTC)Reply[reply]
Haha, that's true. What would also help is to be able to have multiple instances of non-template 'free text' so that editors can add the necessary tags themselves (that is, before and after the templates in question). In the current situation, there may be one hack which sort of does this even if it's not ideal: use a 'section' at the top, where an editor can add the opening tag, and 'free text' at the bottom, where the closing tag would need to be added. But of course the first option is much to be preferred. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 23:28, 4 November 2014 (UTC)Reply[reply]
Hello Cavila, i need the same thing that you need, my comment is: if you find the solution, can you tell me how to do something like this? Thanks man! Crystian

Size of the popup window for #formlink

Is there a way to set the size of the pop-up window to such levels that the content is always fully visible and scrollbars do not appear? Where can edit this thing anyway? --Temptuousinsolence (talk) 15:30, 5 November 2014 (UTC)Reply[reply]

It looks like the size of the window is hardcoded in /includes/forminputs/SF_TextInput.php, at around line 122. It really shouldn't be hardcoded, but that's how it is at the moment. Yaron Koren (talk) 17:29, 5 November 2014 (UTC)Reply[reply]

Match Pages of the some namespace to a form

in which page a have to use "[[Has default form::formname]]", i.e, if i want match namespace "X" to a form "formX", where i add the property [[Has default form::formX]] ?

  • in [[MediaWiki:X]]?, or
  • in [[Project:X]]? or where? ("X" is the namespace)...


The second one. Yaron Koren (talk) 01:38, 13 November 2014 (UTC)Reply[reply]
Thanks it works

Autocompletion on values with a more than 31...33 Cyrillic characters

In my wiki some properties with type "text/string" have more than 31...33 characters (or more than three separate words). When I try "remote autocomplete" and "values from property=My property", field return some like "Металлообрабатывающе14af5f1e14a72b9593e2e5ec4d55f73c" instead of "Металлообрабатывающее оборудование - производство". Direct insertion of property values in this field with parameter "values=" do not make any autocompletion effects.

So, what would I make to solve this problem? Is it exist a magic setting to increase number of characters or words in values?Dmitry Russkih (talk) 15:52, 17 November 2014 (UTC)Reply[reply]

Hi - I don't think the number of characters affects things; does it? Also, what do you mean by "31...33" - is the size at which problems start sometimes 31, and sometimes 33? Also, does this problem still happen if you don't use "remote autocompletion"? Yaron Koren (talk) 18:32, 17 November 2014 (UTC)Reply[reply]
I've made some explorations on this issue and 31 or more characters is only my observation (it may be 30 or less, I still haven't reach any regularity). Examining the php-code I've found md5 and hash parameters, both look like ending of large autocompleted values in my wiki (I mean 14af5f1e14a72b9593e2e5ec4d55f73c). As I understand the problem is excess of allowable string limit and replacing part of string with hash as output. Probable cause of this problem lays in interaction of javascript/JQuery and PHP, because problem arises only when javascript or jQuery works (only when autocompletion enabled; in another cases e.g. listboxes, dropdowns, radio etc there are no problem).Dmitry Russkih (talk) 09:13, 24 November 2014 (UTC)Reply[reply]

Message Sf autoedit success

Can i use an autoedit button into the page "Mediawiki:Sf autoedit success"?

I'll explain me better:

I have any page where i have this code:

{{#autoedit:form=Número de Revisión|target={{FULLPAGENAME}}|link text=Revisar|link type=button|query string=Número de Revisión[fecha LC]={{#timel: Y-M-d }}|summary=Revisión}}

so, when i click on this button appears the message that i defined into the page: "Mediawiki:Sf autoedit success"...

i changed the default content of the page: "Mediawiki:Sf autoedit success" by the next:

|Número de Revisión={{#autoedit:form=Número de Revisión Confirmar|target={{FULLPAGENAME}}|link text=Aceptar|link type=button|query string=Número de Revisión[revisión LC]={{#expr:{{#show:{{FULLPAGENAME}}|?Has number of votes}} + 1}}|summary=Aceptar|reload}}
|Número de Revisión Confirmar=Revision was done [[$1]]

so, after i click on the first button, appears the second button which is defined in the page:"Mediawiki:Sf autoedit success"... but when i click on the second button, it does not work... Someone knows why? Crystian

Do you mean that you put in a button *as the success message*? If so, I'm not surprised that that would fail - that seems like a massive hack. What is the goal? Or perhaps I misunderstood your question. Yaron Koren (talk) 04:13, 20 November 2014 (UTC)Reply[reply]
Yes i put a button as the success message in tha page "MediaWiki:Sf_autoedit_success", My intention is to have a button of confirmation, because i have an autoedit button that change a semantic property but i want other button that ask if the user is sure of what he is doing... maybe i'm crazy... is that possible? Crystian
I have no idea if it's possible, though your test seems to indicate that it isn't. Yaron Koren (talk) 17:46, 20 November 2014 (UTC)Reply[reply]
thanks Yaron! i'll try another way.

Using pipes in field default values

I feel sure this question must have come up before so apologies that I haven't been able to find the answer. I have a text field which I want automatically filled by a template using the "default=" parameter as follows:

 {{{field|Identifier|input type=text|default={{GetEntityName|{{{Classo|}}}}}{{{Sail Number|}}}}}}

Where Classo and Sail Number are other fields on the form and GetEntityName is a template that returns a property on a page with title Classo. However the transclusion breaks part way through drawing the form when it reaches the first pipe symbol after "default=". Of course, when the form is saved it also has the wrong information stored in the field. I have tried using a template to substitute a ! for a | as is common on many wikis. I've also tried the PipeEscapee parser function but with similar results.

I can edit the template associated with the form to include the following, which does seem to work:

! Identifier:
| [[ has Name::{{GetEntityName|{{{Classo|}}} }} {{{Sail Number|}}}]] 

The problem with this approach is that I am using PageSchemas to generate and maintain the forms etc. so I would prefer not to have to go in and start manually editing the templates.

I wondered if you had any thoughts of how I could do this?

Many thanks

Duncan (21st November 2014)

The first option seems like a bad idea all around - if the user isn't supposed to edit the field, it shouldn't show up in the form. So yes, I think the 2nd option is the right approach; and sorry about the weakness with Page Schemas. Yaron Koren (talk) 17:31, 21 November 2014 (UTC)Reply[reply]
Ah well - that's good to know so I can move on. Maybe one day Page Schemas will use Semantic Forms then it'll be easier to extend its functionality? Thanks for your ongoing help. Duncan (21st November 2014)
I doubt it, but certainly PS could stand some improvements/additions. Yaron Koren (talk) 18:32, 21 November 2014 (UTC)Reply[reply]
For information for anyone reading this post - the first problem with the default assignment above is the number of "}" braces at the end. There is a documented problem (http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Common_problems) that means having more than three of these at the end breaks the parser function's workings. There needs to be a space before the last three braces. The other problem is in trying to reference another field in the form by bracketing its name in triple braces. The first triple set of closing braces appears to terminate the parser that is interpreting the form field definition. As Yaron points out this is not a sensible thing to be trying to do anyway and Semantic Forms isn't built to support it. Duncan (Nov 23rd 2014)

Using #formlink parser function

In my wiki #formlink parser function has another syntax, than described in page Semantic Forms/Linking to forms:

It works when i type

{{#formlink:FormName|LinkText|LinkType|query string parameters|Target|Tooltip|popup|new window}}

instead of
{{#formlink:form=FormName|link text=LinkText|link type=LinkType|query string=query string parameters|target=Target|tooltip=Tooltip|popup|new window}}

but syntax of #forminput just the opposite and needs "form=", "size=" etc.

Is it only in my wiki or this situation absolutely normal and corresponds to last stable extension release?Dmitry Russkih (talk) 09:17, 25 November 2014 (UTC)Reply[reply]

Hi - that's the old syntax, with unnamed parameters; it was changed a few years ago. The old syntax still works, although it may stop working in the future. Yaron Koren (talk) 18:34, 25 November 2014 (UTC)Reply[reply]

Error with #forminput and some tags

this code appears when i put in some page "#formlink", the same thing happens when i put in the page some tag, like: "<pre>"


any idea about what's happened?

The "UNIQ...QINU" thing basically happens when something gets too complicated for the MediaWiki parser to handle. Could you give the specific wikitext you're using? Also, what versions of SF and MW are you using? Yaron Koren (talk) 20:45, 28 November 2014 (UTC)Reply[reply]

Mapping Template with Combobox input and Values Dependent On with Dropdown input

I'd like to use the "values dependent on" field parameter when also using "mapping template" parameter in order to select a subset of pages when using "values from category" in a form field.

It seems I can get the "mapping template" working with a "dropdown" field but it doesn't seem to recognise the "values dependent on" parameter. Likewise if I use a "combobox" field it doesn't seem to recognise the "mapping template" parameter. I wondered if these combinations are supported or, if not, is there another way to restrict selection when using "values from category"?

Many thanks - Duncan, 29th Nov 2014.

That's quite a combination! Yes, at the moment you can't use "mapping template" together with "values dependent on", for the reason you mention. There is currently a pending change to Semantic Forms, though, that will allow "mapping template" to work with "combobox"; if it works, I'll merge it in, and that should solve your problem. Yaron Koren (talk) 05:23, 1 December 2014 (UTC)Reply[reply]
The patch I mentioned was just recently checked in, so if you get the latest code your original plan should work, hopefully... Yaron Koren (talk) 05:42, 3 December 2014 (UTC)Reply[reply]

Relative Path problem....


I have set
$wgScriptPath = "";
however, I get paths like
<img src="/wiki/extensions/SemanticForms/skins/rearranger.png" class="rearrangerImage" />
in the browser. That is, unless I also change DefaultSettings.php to read
$wgScriptPath = "";
instead of the default
$wgScriptPath = "/wiki";

I assume somewhere the default value is reloaded, although it should have been overwritten in LocalSettings.php.
I also assume, that this is an error.

Heinrich krebs (talk) 15:26, 4 December 2014 (UTC)Reply[reply]

Could it be that you're setting that value after the inclusion of Semantic Forms? Yaron Koren (talk) 15:54, 4 December 2014 (UTC)Reply[reply]

Autocomplete on Outside Values Doesn't Constrain

Been having fun with SF 2.8 (loving the empty parameter fix), however autocomplete on oustide values isn't behaving as expected. The list of values appears to be fetched ok, and shows up in a drop down, but the list does not narrow down (get smaller) as you type (compared to auto completing on a fully specified values=1,2,3.. field or on existing property values). Is it supposed to? Thanks! - Lbillett (talk) 16:56, 8 December 2014 (UTC)Reply[reply]

Sorry about the delay. That does sound like a bug, yes... I hope to look into this at some point. Yaron Koren (talk) 13:47, 16 December 2014 (UTC)Reply[reply]
No sweat. Wasn't sure if maybe there was some kind of trick. Thanks! - Lbillett (talk) 14:01, 16 December 2014 (UTC)Reply[reply]

Form inadvertently deletes the values of semantic properties

I'm trying to create pages where users can change content with semantic forms, while the system records information about each change (e.g., the time when the change was made).

For example, I might have the following template, named Test, which I populate with a form:

<!--If the values of v1 and/or v2, which are edited with the form, are different 
from the ones previously stored, new time values are assigned to LastChanged1 and/or
{{#ifeq:{{{?v1}}}|{{#show:{{PAGENAME}}|?Variable1}}||{{#set:LastChanged1={{CURRENTTIME}} }} }}
{{#ifeq:{{{?v2}}}|{{#show:{{PAGENAME}}|?Variable2}}||{{#set:LastChanged2={{CURRENTTIME}} }} }}

<!--The values of v1 and v2 are stored as semantic properties.-->
{{#set:Variable1={{{?v1}}}|Variable2={{{?v2}}} }}

<!--The values of the variables and when they were last changed are printed.-->
The value of Variable1 is {{#show:{{PAGENAME}}|?Variable1}}. It was last changed {{#show:{{PAGENAME}}|?LastChanged1}}. 

The value of Variable2 is {{#show:{{PAGENAME}}|?Variable2}}. It was last changed {{#show:{{PAGENAME}}|?LastChanged2}}.

The form would look something like this:

{{{for template|Test}}}

{| class="formtable"  style="text-align:left"
| Select value for variable 1: 
| {{{field|?v1|input type=dropdown|default=John|values=John,Mark,Peter|mandatory}}}
| Select value for variable 2:
| {{{field|?v2|input type=dropdown|default=Mary|values=Mary,Jill,Hanna|mandatory}}}
{{{end template}}}

When I use the form to create a page, it functions properly: values are assigned to Variable1 and Variable2, and the time when the page was created is stored into LastChanged1 and LastChanged2. The form also functions correctly if I use it to change the values of both Variable1 and Variable2 on a previously created page.

However, when I change just one of the values, there's a glitch. If I change the value of Variable1 without changing the value of Variable2 (or vice versa), the value of LastChanged1 changes as expected, but simultaneously the value of LastChanged2 is deleted. This glitch happens also when I save a previously created page with the form without changing any values -- both LastChanged1 and LastChanged2 are wiped out.

There's obviously something I don't get about how templates and/or forms work. What's the problem here, and how can I get this to work properly?--Markov1942

Dmitry Russkih (talk) 12:01, 16 December 2014 (UTC) Semantic updates all variables on page when You save it. So, when You change value, you set variables LastChanged1 and LastChanged2. When you don't change value, you don't set any. Just correct your code with following:Reply[reply]
{{#ifeq:{{{?v1}}}|{{#show:{{PAGENAME}}|?Variable1}}|{{#set:LastChanged1={{#show:{{PAGENAME}}|?LastChanged1}} }}|{{#set:LastChanged1={{CURRENTTIME}} }} }}
{{#ifeq:{{{?v2}}}|{{#show:{{PAGENAME}}|?Variable2}}|{{#set:LastChanged2={{#show:{{PAGENAME}}|?LastChanged2}} }}|{{#set:LastChanged2={{CURRENTTIME}} }} }}
Thank you!--Markov1942

Placeholder doesn't allow urls

Hello. The placeholder= option for the field tag doesn't allow URLs. Well, you can put it, but it is shown as "<a href=...>...</a>", very ugly. I tried to add the < nowiki > tag, but it is worst. Any solution? I would like to show a URL as placeholder. Emijrp (talk) 12:16, 18 December 2014 (UTC)Reply[reply]

It's a hack, but what you can do is substitute a similar- or identical-looking character, that's actually different and thus will not be a valid URL. For instance, this URL will work because the 'p' in 'http' is actually from Cyrillic, not the standard 'p': httр://example.com . Yaron Koren (talk) 16:38, 18 December 2014 (UTC)Reply[reply]

autoedit more than one page...

is possible edit more than one page at same time? with "#autoedit"

No... although editing of multiple pages, through #autoedit and otherwise, is definitely something that I would like to see added to Semantic Forms. Yaron Koren (talk) 00:52, 20 December 2014 (UTC)Reply[reply]

Mediawiki 1.24.1 Upgrade not compatible with Semantic Forms?

I believe that all of the problems are caused by some incompatibility between certain SMW extensions (e.g., SemanticForms) and MW 1.24.1. Specifically, a global variable ($sfgIP) is being called as a path variable referenced in the following (from SF 2.6):

 * Initialize a global language object for content language. This
 * must happen early on, even before user language is known, to
 * determine labels for additional namespaces. In contrast, messages
 * can be initialised much later, when they are actually needed.
function sffInitContentLanguage( $langcode ) {
	global $sfgIP, $sfgContLang;

	if ( !empty( $sfgContLang ) ) { return; }

	$cont_lang_class = 'SF_Language' . str_replace( '-', '_', ucfirst( $langcode ) );
	if ( file_exists( $sfgIP . '/languages/' . $cont_lang_class . '.php' ) ) {
		include_once( $sfgIP . '/languages/' . $cont_lang_class . '.php' );

	// fallback if language not supported
	if ( !class_exists( $cont_lang_class ) ) {
		include_once( $sfgIP . '/languages/SF_LanguageEn.php' );
		$cont_lang_class = 'SF_LanguageEn';

	$sfgContLang = new $cont_lang_class();

The PHP error I get after attempting web upgrade to MW 1.24.1 from MW 1.22.0 with SF 2.6:

Warning: include_once(/languages/SF_LanguageEn.php): failed to open stream: No such file or directory in
/home/stepproj/sites/wiki/docroot/extensions/SemanticForms/SemanticForms.php on line 323

Warning: include_once(): Failed opening '/languages/SF_LanguageEn.php' for inclusion
stepproj/sites/wiki/docroot/vendor/phpunit/php-code-coverage:.:/usr/local/lib/php') in
/home/stepproj/sites/wiki/docroot/extensions/SemanticForms/SemanticForms.php on line 323

Fatal error: Class 'SF_LanguageEn' not found in
/home/stepproj/sites/wiki/docroot/extensions/SemanticForms/SemanticForms.php on line 327

The PHP error I get after attempting web upgrade to MW 1.24.1 from MW 1.22.0 with SF 3.0:

[771f7a66] /mw-config/index.php?page=ExistingWiki Exception from line 341 of
/home/stepproj/sites/wiki/docroot/includes/MagicWord.php: Error: invalid magic word 'default_form'


#0 /home/stepproj/sites/wiki/docroot/includes/MagicWord.php(264): MagicWord->load(string)
#1 /home/stepproj/sites/wiki/docroot/includes/parser/Parser.php(5159): MagicWord::get(string)
#2 /home/stepproj/sites/wiki/docroot/extensions/SemanticForms/includes/SF_ParserFunctions.php(161): Parser->setFunctionHook(string, array)
#3 [internal function]: SFParserFunctions::registerFunctions(Parser)
#4 /home/stepproj/sites/wiki/docroot/includes/Hooks.php(206): call_user_func_array(string, array)
#5 /home/stepproj/sites/wiki/docroot/includes/GlobalFunctions.php(3995): Hooks::run(string, array, NULL)
#6 /home/stepproj/sites/wiki/docroot/includes/parser/Parser.php(279): wfRunHooks(string, array)
#7 /home/stepproj/sites/wiki/docroot/includes/parser/Parser.php(291): Parser->firstCallInit()
#8 /home/stepproj/sites/wiki/docroot/includes/parser/Parser.php(5000): Parser->clearState()
#9 /home/stepproj/sites/wiki/docroot/includes/parser/Parser.php(377): Parser->startParse(Title, ParserOptions, integer, boolean)
#10 /home/stepproj/sites/wiki/docroot/includes/installer/Installer.php(631): Parser->parse(string, Title, ParserOptions, boolean)
#11 /home/stepproj/sites/wiki/docroot/includes/installer/WebInstaller.php(676): Installer->parse(string, boolean)
#12 /home/stepproj/sites/wiki/docroot/includes/installer/WebInstallerPage.php(392): WebInstaller->getInfoBox(string)
#13 /home/stepproj/sites/wiki/docroot/includes/installer/WebInstallerPage.php(380): WebInstallerExistingWiki->showKeyForm()
#14 /home/stepproj/sites/wiki/docroot/includes/installer/WebInstaller.php(280): WebInstallerExistingWiki->execute()
#15 /home/stepproj/sites/wiki/docroot/mw-config/index.php(79): WebInstaller->execute(array)
#16 /home/stepproj/sites/wiki/docroot/mw-config/index.php(38): wfInstallerMain()
#17 {main}

New versions of SemanticForms deal with this in a different manner using a different variable (__DIR__) that is compatible with MW 1.24.1 ... however, there are two "magic words" that new versions of SF are using that MW complains about as being "illegal magic words" (forminput and default_form).

I have updated MW at least 5 times in the past without any issues at all, so this is a bit wierd and hopefully related to that variable setting.~z929669   Talk 18:39, 24 December 2014 (UTC)Reply[reply]

Well, this is a few issues in one... I don't know if it's worth debugging the first one, since there's no point in using SF 2.6 any more. Actually, I'm not sure if it's worth debugging the second one, either, if it's an isolated incident; maybe the easiest approach is just to temporarily install SF while you do the MW upgrade? Yaron Koren (talk) 20:48, 24 December 2014 (UTC)Reply[reply]
That is actually a good idea (uninstalling SF, upgrade MW, install SF 3.0 and other). As long as the MW update scripts are being overly conservative, and the problematic Semantic extensions will not cause issues in the final result. Just so you know, the extensions (that I am using) that appear to cause errors due to similar reasons are:
  • SemanticDrilldown
  • SemanticForms
  • SemanticFormsInputs (due to dependency on SemanticForms)
  • SemanticImageInput (due to dependency on SemanticForms)
  • SemanticInternalObjects
I encourage you or anybody else to verify the behavior I have described. Ideally, MW update scripts should not complain, but who knows ... Thanks for the fast response! ~z929669   Talk 21:42, 24 December 2014 (UTC)Reply[reply]
Oh, that's very unusual; I haven't heard of such a thing happening. To clarify - do SD and SIO also lead to errors about invalid magic words? And are you using Semantic Bundle? Yaron Koren (talk) 00:26, 25 December 2014 (UTC)Reply[reply]

<ref></ref> transformed to UNIQ3eab1d1d3f395064-ref-00000000-QINU

I have entered a text inside an input box of SF with the type=textarea.

Inside the text I have made a reference with <ref></ref>.

After saving the work <ref></ref> is transformed to UNIQ3eab1d1d3f395064-ref-00000000-QINU.

Any suggestions?

I assume a property tag is being put around that value in the template? If so, I would try replacing that property tag with a #set call. Yaron Koren (talk) 19:03, 26 December 2014 (UTC)Reply[reply]

There is no property tag arround that Value.

This is the snippet of the Template:

{{#if:{{{Produktklassen|}}}|== Produktklassen ==

And this is the Snippet of the Form

! Klassen: 
| {{{field|Produktklassen|input type=textarea}}}

The problem occurs at the moment, when I press the save button at the bottom of the form. When I have a look at the saved page I see UNIQ3eab1d1d3f395064-ref-00000000-QINU instead of <ref></ref>.

When I change the content form UNIQ3eab1d1d3f395064-ref-00000000-QINU to <ref>></ref> manually (without the form) the result looks good as expected.

What versions of MW and SF are you using? And is this a public wiki? Yaron Koren (talk) 00:25, 27 December 2014 (UTC)Reply[reply]

MW=1.24.1; SMW=2.0; SF=3.0 (9fb3cf8), its my private WiKi but accessible from outside. Would it be useful to grant some rights?

Sorry for the delay. It would be useful if I could see the problem in action, yes. Feel free to email me at yaron57 at gmail.com to discuss this privately. Yaron Koren (talk) 23:27, 30 December 2014 (UTC)Reply[reply]

Multiple edit

is it possible edit several pages at the same time with a form?

i found an old extension Extension:Semantic_Multi_Edit_Extension, but I read that extension is obsolete.

there exist another option?

Crystian Marquez

I don't think there's another option, unfortunately. It would be great to be able to have something like this. Yaron Koren (talk) 23:28, 30 December 2014 (UTC)Reply[reply]
Return to "Page Forms/Archive September to December 2014" page.