Extension talk:Page Forms/Archive January to March 2014

IE10 Explorer and autocomplete

Since we installed the IE10 combobox, and text with autocomplete don't work any longer. We can easily fix this by running the IE 10 in compatibility mode, but this will be an issue to tell this to everybody. Is this a known problem and how can I fix this. --Trossruc (talk) 15:21, 6 February 2014 (UTC)

Both of those input types work fine for me in IE10 - my guess that it's actually some unrelated Javascript error, possibly from some other extension or from the skin, that's breaking Javascript on the page. Unfortunately, IE JS debugging is pretty poor. Is this on a public wiki? If not, what versions of MW and SF are you using, and are you using a custom skin? Yaron Koren (talk) 16:39, 6 February 2014 (UTC)

Thank you for the help. Looks like it is a JS problem. We managed to get the functionality back as expected, nevertheless the layout looks a little different. No problem for us anymore. --Trossruc (talk) 15:00, 7 February 2014 (UTC)

Unused 'show on select' field gets it's argument name saved

When using the 'show on select' field option, fields never used (hence hiding them) still show up in the saved article. For instance, say the field arg2 stays hidden and never filled out. On saving the article, I still get:

|arg1=whatever this was set to
|arg2=

Is there a way to keep the |arg2= from showing up in the article? It makes reviewing article source tedious when there are tons of them. Thanks! - Lbillett (talk) 22:49, 24 January 2014 (UTC)

Are you using the latest SF version? I thought this problem had been fixed, but I could be wrong. In any case - no, it's not something that can be fixed, other than by changing the PHP code. Yaron Koren (talk) 13:19, 27 January 2014 (UTC)

Ah. I'm still on v2.5.1. At least for now, till that queryform bug is worked out. Thanks! - Lbillett (talk) 01:43, 28 January 2014 (UTC)

After upgrading to 2.7, this problem persists. Perhaps there is something in the form definition I am doing wrong? - Lbillett (talk) 14:22, 25 April 2014 (UTC)

edit with semantic form automatically

Hi all I have a very large wiki site of about 70,000 pages. I want to make some radical changes in the way the pages look. is there any way to edit all of them automatically via a new form?

Thanks, Asaf

MediaWiki 1.22.0

PHP 5.4.0 (apache)

MySQL 5.0.67-log

Semantic Forms (2.6.1)

Asaf bareket (talk) 07:34, 28 January 2014 (UTC)

No - you'd have to use a bot script or something. (Though if it's radical changes you want, I doubt a form would help anyway.) Yaron Koren (talk) 14:03, 28 January 2014 (UTC)

Thanks for the reply. So do you have an idea of how I can work this through? the changes are not so radical... I just want to move the image from side to side and add a couple of templates. Asaf bareket (talk) 14:26, 28 January 2014 (UTC)

Forms are probably not what you're looking for. If you just want to display something on every article (and not necessarily change the actual contents of each article) you could output a template on all articles. If you're 'moving' some existing image on each article, the text replace extension might be a big help. You could modify the image attributes by adding "|right" (or whatever you're trying to do). - Lbillett (talk) 14:55, 28 January 2014 (UTC)

Ok to Use Separate Forms for Different Templates on Same Article?

I intend(ed) to use articles containing multiple templates and figured I could create different forms to edit these templates. However, if I link to a form specifying a target page in which the target template does not (yet) exist, I get an error message with "Warning: This page already exists, but it does not use this form."

Is there a way to disable this warning? Is it bad 'form' to have multiple templates intended for modification by different forms on the same article? I expect it the warning is being generated because the form didn't find the target template on the already-created page (hence my curiosity about what's proper). Thanks! - Lbillett (talk) 20:46, 28 January 2014 (UTC)

Every form that edits a certain page should include the same set of templates, even if the set of fields is different - so for templates that you don't want modified by that form, you should just include a "{{{for template|...}}} {{{end template}}}". Yaron Koren (talk) 23:47, 28 January 2014 (UTC)

Got it. Didn't catch that intent. Keeps templates saved in right order too! Thanks so much! - Lbillett (talk) 04:20, 29 January 2014 (UTC)

Semantic Forms and MW 1.22.2

We have tried SF 2.5.3 and 2.6.1 with MW 1.22.2 and SMW 1.9. There appears to be incompatibility when it comes to support for multiple-instance templates (add multiple). Formlink also seems to be broken. Is SF compatible with MW 1.22.2? Has anyone had success with this setup?

Thanks,

Longphile (talk) 19:04, 3 February 2014 (UTC)

I'm not aware of any issues among any of those versions. What's the error you're seeing? If it's a Javascript problem, could you use a Javascript console to see the specific error message? Yaron Koren (talk) 20:25, 3 February 2014 (UTC)

I'm using MW 1.22.2 and SMW 1.9.0.2. I do not seem to have problems with multiple instance templates. However, my queryformlinks do not seem to work--the links go to the Special:Runquery page, but the visualization never emerges-- it stays "Loading..." Patelmm79 (talk) 20:34, 3 February 2014 (UTC)

What visualization is it? And is #queryformlink really the issue? If you go to that same URL without using #queryformlink, does the problem no longer happen? Yaron Koren (talk) 20:38, 3 February 2014 (UTC)

So, I tried to copy the URL that queryformlink generates, and paste it into another browser tab-- same problem. The visualization is timeseries, which does successfully work in other parts of the wiki. I did test the specific query that is supposed to generate the timeseries chart, and it does show up correctly. Patelmm79 (talk) 21:10, 3 February 2014 (UTC)

Alright. Well, as above, you should try to look at a Javascript console for the page and see what the error message is, if any. Yaron Koren (talk) 21:34, 3 February 2014 (UTC)

So I don't know if I'm doing this correctly, but I added a "debug=true" to the end of the URL, and entered the browser Java console by hitting Ctrl-Alt-J. The only error I can see is "jquery.cookie.js 406 (Not Acceptable)" and a warning that "event.returnValue is deprecated. Please use the standard event.preventDefault() instead. ". Patelmm79 (talk) 00:01, 4 February 2014 (UTC)

That 406 error might be the issue, but I don't know anything more than that. Is this viewable on a public wiki, or can you replicate the problem on a public wiki, like http://scratchpad.referata.com ? Yaron Koren (talk) 01:02, 4 February 2014 (UTC)

I have another setup with MW 1.21, SF 2.5.3, and SMW 1.8.05 and everything works fine. When I upgraded to SMW 1.9, I was able to reproduce the same problems I saw in my above MW 1.22.2 setup. The forms show up weird with certain drop downs missing their inputs, adding another template instance does not work, and my HeaderTabs also are not rendered correctly. DynamicSidebar with GumaxDD was working before but now it does not work either. Again SF formlinks does not work. Clicking one directs me to the MainPage rather than opening up FormEdit. I am wondering if the problems are all related to SMW 1.9 somehow (and not MW version, or SF) and its dependencies. Could ParamProcessor in Validator be at fault here? Don't know about it enough to comment. Longphile (talk) 02:15, 4 February 2014 (UTC)

I'm guessing it's one or more Javascript errors responsible for all of these issues - see above. Yaron Koren (talk) 02:37, 4 February 2014 (UTC)

For my issue, I have done some debugging and have traced it to Semantic Result Formats (both version 1.8 and 1.9). Removing this seems to fix the issues related to SF, Dynamic Sidebar, and HeaderTabs both in MW 1.21 and MW 1.22.2. I will post on the SRF discussion board and see if there is any workaround. Thanks. Longphile (talk) 04:55, 4 February 2014 (UTC)

I have set up a demo from on http://scratchpad.referata.com/wiki/Demo:Timeseries/Seismic_activities. There is a query form link at the top of the page. The chart is currently produced correctly there, but note that scratchpad is running older versions of MW, SMW, and SRF. Patelmm79 (talk) 15:44, 4 February 2014 (UTC)

I was able to replicate the problem, on a wiki with more recent software. This was a tricky one! But I think I was able to solve it. If you get the latest SF code from Git, the problem should hopefully go away. Yaron Koren (talk) 16:34, 6 February 2014 (UTC)

We have been able to resolve our other issues above (Header Tabs, Dynamic SideBar) which were not related to SF or SRF as I suspected. I tried your new fix Yaron which does not resolve our formlink problem. In our wiki (MW 1.22.2, SMW1.9+, SF 2.6.1), clicking on a formlink button brings us to the main page. I looked in the Chrome console and see no errors reported on a TestPage with a formlink button to a form that has worked in the past on MW 1.21 and SMW 1.8. Using Special:FormEdit in the url for the same target page works fine. In addition, using link type=text also works. link type=button does not work. Longphile (talk) 04:10, 7 February 2014 (UTC)

I'm not surprised that my fix didn't solve your problem - it was for a separate issue. There are at least four different issues discussed in this section, and maybe more. For the #formlink problem you're seeing, I'm guessing it's the third item listed here. Yaron Koren (talk) 04:36, 7 February 2014 (UTC)

Yes "post button" works! Thanks. Everything is working now. 74.61.193.243 22:35, 7 February 2014 (UTC)

Errors when embedding multiple Special:RunQuery forms

When I insert a single Semantic Form AskQuery into a page everything works as intended.

However adding more than one results in the form (and resulting page) causes things to be rendered incorrectly.

Section headings and forms are replaced with strings such as "?UNIQ244e3f3e0b0ae732-item-5--QINU?"

I recall reading of a similar issue, but can't seem to find any documentation. Is it possible to include multiple Special:AskQuery forms in a single page?

MW 1.23wmf11, SMW 1.9.0.2, SF 2.6.2-alpha (547b184)

I'm not surprised that it fails - there have been various problems with embedding Special:RunQuery into pages. This will hopefully get fixed at some point before too long. Yaron Koren (talk) 20:31, 10 February 2014 (UTC)

I'm glad I'm not crazy in thinking that I've seen this before. Should I submit a bug? --Ckoerner (talk) 21:33, 10 February 2014 (UTC)

Hi CKoerner, no need. A report was filed in July (bugzilla #49302). For the time being you could revert to SF 2.5.2 or do not embed query forms if you can avoid it. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 21:57, 10 February 2014 (UTC)

SemanticForms and Imagegallery

Hello, within a form a like to create a imagegallery using

<gallery>
File:file1.jpg|description
File:file2.jpg|anotherdescription
</gallery>

This works fine. But if I like to edit this page using the form, the text is truncated at the pipe-symbol (|). Using the common "hack" by creating a template {{!}} with only the pipesymbol won't work here. No image is displayed then.

Is there a way to realize a imagegallery with description in a semanticform?

fin swimmer

This may work instead:

{{#tag: gallery|
File:file1.jpg{{!}}description
File:file2.jpg{{!}}anotherdescription
}}

Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 11:47, 11 February 2014 (UTC)

I doubt that will work, because, if nothing else, it contains a pipe as well. I would suggest one of two things: either have the user put that text inside a "section", as opposed to a template field; or (maybe better yet) have the user just enter the data about file names and captions, preferably using a multiple-instance template, and then display the images using the SRF 'gallery' format (#subobject and/or #set_internal would most likely have to be involved). Yaron Koren (talk) 13:28, 11 February 2014 (UTC)

Thank you all for your answers. The parser-function from Cavila seems to work perfectly.

--Finswimmer (talk) 08:25, 13 February 2014 (UTC)

That's surprising. Yaron Koren (talk) 12:36, 13 February 2014 (UTC)

Allowing multiple instances of template in form leads to error

Whenever I include the 'multiple' parameter for a particular template on my wiki, nothing of that template shows up in the resulting form except the 'Add another' button. Templates show up fine in forms as soon as the 'multiple' parameter is removed. Clicking the 'Add another' button in a form has no effect whatsoever, but Firebug's console reports 'ReferenceError: sfgShowOnSelect is not defined', apparently in reference to load.php. I'm a very green user and don't know what that means or what to do with it - thanks in advance for any help!

Example non-working form here. I'm using Semantic Forms 2.6.1, installed using Semantic Bundle.

MediaWiki 1.19.11

PHP 5.3.27 (cgi-fcgi)

MySQL 5.1.39-log

It's great that this is on a public URL. However, I need to log in in order to see the problem, and registration is closed. Could you create an account for me and send me (yaron57@gmail.com) the password? Yaron Koren (talk) 16:23, 12 February 2014 (UTC)

Done! Unjapanologist (talk) 13:09, 13 February 2014 (UTC)

Okay, we figured out the problem "offline" - it turned out to be the Configure extension that was causing a JS error, directly or indirectly. I just added a note about that to the "Known bugs" section. Yaron Koren (talk) 17:19, 17 February 2014 (UTC)

Automaticly add a prefix to page name

Hello, is there a way to automaticly add a prefix to a given page name within a formular, when the page is created? --Finswimmer (talk) 08:36, 13 February 2014 (UTC)

Are you using #forminput, or #formlink? Yaron Koren (talk) 12:34, 13 February 2014 (UTC)

Currently i'm using #forminput. But if this should only be possible with #formlink I can switch I guess --Finswimmer (talk) 13:29, 13 February 2014 (UTC)

You can do it with #forminput, sort of - if you pass in to #forminput the parameter "query string=super_page=pageName", the page name will be prepended with "pageName/", and if you pass in "query string=namespace=namespaceName", the page name will be prepended with "namespaceName:". If you don't want a slash or colon in there, unfortunately I don't think there's a solution, other than switching to #formlink. Yaron Koren (talk) 20:52, 13 February 2014 (UTC)

Performance debug of Edit with Form

Hi,

I have a relatively complex form with about 35 fields in them, using mostly regexp and list field types, and pressing edit with form is taking a long time to complete when editing existing forms.

I can see that the delay appears to be server side, but I can't find any documentation of how to debug and/or tune the cause of the delays. Can anyone provide me with any hints? I've recently upgraded to MW 1.22 and SemanticBundle 20130929 but that doesn't seem to be much better.

Thanks in advance for any help

The debugging toolbar may help here - I'm not sure. Yaron Koren (talk) 19:05, 18 February 2014 (UTC)

Thanks for pointing out that toolbar it was very helpful. It turns out that HTTP is running at 100% CPU processing the PHP, and taking about 30 seconds to complete. The DB was really very fast to respond to the queries. I actually have a lot of spare CPUs on this machine - but I assume there's no way to make the form processing run multi-threaded. If you know of any other way to speed this up I'd be grateful - otherwise I think I have to live with it.

Multi-threading is not an option, but increasing the amount of memory for PHP might help. Yaron Koren (talk) 14:13, 25 February 2014 (UTC)

I already have 512 MB set in LocalSettings.php( ini_set( 'memory_limit', '512M' ); ) although I've noticed that it's limited to 128 MB in the php.ini. Not sure which limit will apply here. I also have the $wgMaxShellMemory = 512000; Anything else I should check or change?

The settings in LocalSettings.php should override whatever is in php.ini. I don't know, then... could you try copying the form and template to a public wiki, like http://scratchpad.referata.com (I'm assuming this is on a private wiki right now), to see if the same slowness problem exists there? If so, it'll be a lot easier to analyze. Yaron Koren (talk) 03:36, 26 February 2014 (UTC)

Formlink and default values

Hello, is there any way to set default values for form parameters within the "formlink" syntax? For example, if there is a parameter "Geography" and I want to set it automatically to "Haiti" within the created page. I know there is a way to do this within the form itself, but I'd like to specify within the "formlink" as this value changes quite often.Patelmm79 (talk) 21:13, 21 February 2014 (UTC)

Yes - use the "query string" parameter. Yaron Koren (talk) 21:23, 21 February 2014 (UTC)

Hi Yaron. Looks like the query string parameter is broken in SF version 2.7 using MW 1.22.3 and SMW 1.9.1.1, i.e. the default values are not passed to the form. Version 2.6.1 doesn't have this problem. After upgrading a production server to 2.7, I had to backtrack.

Broken example: http://edutechwiki.unige.ch/t/SF-formlink

Working: same MW/SMW version, but older SF 2.6.1 code: here (button to the right, one page down)

greetings ! - Daniel K. Schneider (talk) 14:09, 17 March 2014 (UTC)

That's pretty bad! Although thankfully not as bad as it sounds. The bug was actually added in to the SF code in Git a month ago, after the release of version 2.7. I just checked in a change that I believe fixes it. Thanks for letting me know about this problem. Yaron Koren (talk) 15:47, 17 March 2014 (UTC)

thanx for fixing it. Just tested. Works :) - Daniel K. Schneider (talk) 18:47, 24 March 2014 (UTC)

Pointing red links to a form by namespace

Hello, i would like to point red links to a form by namespace. For custom namespaces it works using the "Has default form" property by creating a page in the Projectnamespace with the the namespace as pagetitle.

But now I would like to do that with the main-Namespace and it doesn't work. I'm using a german localisation and MediaWiki:Blanknamespace told me the name would be "(Seiten)". But neither Projekt:Seiten nor Projekt:(Seiten) works.

What's the right way?

Thanks a lot. --Finswimmer (talk) 10:57, 25 February 2014 (UTC)

Hi - it's actually set by the message 'sf_blank_namespace', which for German appears to be 'Startseite'. Which might be a bad translation. Actually, I'm not even sure why SF has its own blank namespace message, instead of just using "blanknamespace"... perhaps that message didn't exist yet when I needed one for SF. Yaron Koren (talk) 14:19, 25 February 2014 (UTC)

Thank you! With Projekt:Startseite it works wonderfull. But 'Startseite' is indeed a bad translation. --Finswimmer (talk) 09:04, 26 February 2014 (UTC)

Special:FormStart and #forminput / page name scheme

Hello, I have a form using automatically generated names ("page name = ..." in info tag). The manual points out "Note that users must be sent to the page "Special:FormEdit/form-name" for this automatic page-setting to work; if they somehow end up at a #forminput call and are prompted for a page name, that name will override whatever the automatic page name would be." That is clear, but how do I prevent users from using special pages, i.e. prevent them from going to Special:FormStart, assigning a proprietary name and then selecting the form from the dropdown list? Is there a way to prevent a given form name to be shown on this list? Or disable the page input field upon selection of a given form? Or adjust the Text of this special page ("Attention, users, for a new so-and-so-document please click HERE ...")? Best, --Hans Oleander (talk) 12:40, 3 March 2014 (UTC)

I don't think there's any way, but if it's any consolation, I think it's pretty rare for users to go to that page unless they're directed there. Yaron Koren (talk) 13:41, 3 March 2014 (UTC)

Hi, as I faced a similar issue I decided to write my own extension to avoid page overriding. It is called FormInputMik and you can find it here. The concept is simple: if the page name specified in the input exists (it is also possible to specify a specific namespace where to search) user will be redirected to the edit, otherwise to a form for creating the page. It also allows the autocomplete of the input text, in order to user to know if the page (or a similar one) already exists. I hope this might help. Mik (talk) 14:35, 6 May 2014 (UTC)

How to install SF 2.6+ in SMW 1.9+ (composer, MW 1.22+)?

(1) The composer installation process may be comfortable in the future but right now the documentation is confusing. It's not clear that composer takes all responsibility in loading extensions and that no old include_once is necessary, I guess. But using composer extensions and old include_once extensions the maintenance/update script does not work any more. Following installation of SMW 1.9+ my question is at which of those numbered list items should I add include_once( "$IP/extensions/SemanticForms/SemanticForms.php" );? The maintenance/update script does not work when enableSemantics() is active nor does the script SMW_refreshData.php. It stops with Fatal error: Call to undefined function enableSemantics(). But when I watch Special:Version I see that SMW is loaded.

(2) If every attempt to upgrad SMW fails, how do I reinstall SMW + SMW extensions from scratch? Are all SMW data lost then? Thanks for the help --Andreas P. 17:20, 3 March 2014 (UTC)

Heiya Andreas,

To answer the first part of your first question: Yes, you have to invoke the extensions which are not installed via Composer just as it was done before. So you have to do this for SF after setting "enableSemantics" in your "LocalSettings.php". Composer just cares for the extensions installed via it. In fact you cannot even prevent the extensions from being automatically invoked when doing so, which is even more painful in some cases. I will have to add a not about this somewhere on the wiki.

To answer the second part of your first question: I guess this problem is covered by the third item "Fatal: Call to undefined function enableSemantics() …" in the troubleshooting section. Adding "enable semantics" does not have anything to do with the invocation of the extension itself. This is why you see it on "Special:Version".

Your attempt to upgrade should not fail now you got more insight. However you could reinstall SWM and related extensions without a problem. The data itself is stored on wikipages and SMW takes it to the store. However this is painful if you are on shared hosting. Just run SMW_setup.php and SMW_refreshData.php as explained and you should be fine.

Cheers --[[kgh]] (talk) 18:27, 3 March 2014 (UTC)

I just added information about invoking non-Composer extensions. I just realise that I have misunderstood you question. Add the "require_once ..." after "enable semantics". Cheers --[[kgh]] (talk) 18:56, 3 March 2014 (UTC)

Thanks for your answer, I read the troubleshooting section. If I update SMW-extensions via composer and disable "enableSemantics" and disable SF and any other SMW non-composer extensions, I can run the maintenance/update script. OK. But, if I add SF via include_once below "enableSemantics" the maintenance/update script stops by complaining that Semantic MediaWiki must be installed for Semantic Forms to run! ("enableSemantics" is disabled) or Fatal error: Call to undefined function enableSemantics() ("enableSemantics" is enabled). It seems that I can only run the maintenance/update script if I have not activated the non-composer SMW extensions, so it does not know about the auto load of composer. SMW_setup.php can't be run either ("enableSemantics" enabled or disabled) it says You need to have SMW enabled in order to use this maintenance script! or Fatal error: Call to undefined function enableSemantics() if "enableSemantics" is enabled. So I am back to square zero :-/ … How do I tell SMW_setup.php to look for composer autoloads or how do I get the maintenance/update script get to work with composer-managed and not composer-managed SMW extensions? In fact I don't get the maintenance/update script run properly. The Wiki seems to work but the maintenance/update script seems not. --Andreas P. 19:17, 3 March 2014 (UTC)

Admittedly I currently have no clue what is going on at your end. There is something in the water but I do not know what it is. Currently I have only one wiki using SMW 1.9 and it works like charm when doing "enableSemantics" and then "include_once ...". However it is late today. I will sleep over it. --[[kgh]] (talk) 21:57, 3 March 2014 (UTC)

I am still puzzled why this is not working for you. On my test wiki MW 1.22.3 the working configuration is just as follows (disregarding additional extension specific configuration):

enableSemantics( 'example.org' );

include_once "extensions/SemanticForms/SemanticForms.php";

I assume that you deleted the old source code before installing the new one via Composer as explained and followed the other steps, so I am lost too. Perhaps try to install SMW without SF and other SMW related extensions and add their calls afterwards (will not work for SD though), but this only tries to avoid the problem and not to solve it. Is there something specific about your SMW configuration?

Cheers --[[kgh]] (talk) 10:07, 4 March 2014 (UTC)

I don't know if this is the solution: realising that the maintenance/update.php script doesn't know about the composer autoloads I put before

if (is_readable("$IP/vendor/autoload.php")) require( "$IP/vendor/autoload.php");

enableSemantics( parse_url( $wgServer, PHP_URL_HOST ) );

// further SMW settings and other SMW-extensions not managed by composer

Now the maintenance/update.php script runs smoothly. I guess it is not the correct way but unless it's not wrong it works for me. I wonder if I missed something concerning the documentation of composer or SMW-installation. --Andreas P. 18:10, 4 March 2014 (UTC)

I'm not sure about your MW version because MW-core already takes care of the vendor autoload using WebStart.php and doMaintenance.php which is before any extension or LocalSettings are recognized. --MWJames (talk) 18:36, 4 March 2014 (UTC)

Just a note: I have MW 1.22.3 but it only did auto load for the web view not for the maintenance scripts. Kind of strange but the upper hack works for now. --Andreas P. 11:51, 8 March 2014 (UTC)

Allowed input types for data type "telephone number" and "temperature"

The respective section does not explicitly list these two datatypes, but I think that "telephone number" is like "URL" and "temperature" like "number". I always set a custom length for telephone number and never used "temperature" so I am not absolutely sure about the default. Perhaps these two may be added to the section, too. Cheers --[[kgh]] (talk) 21:30, 7 March 2014 (UTC)

What do you mean by "like" - do you mean that they should be handled the same way, or that they already are handled the same way? Yaron Koren (talk) 22:43, 7 March 2014 (UTC)

Should be. I am not sure what the actual setting is right now. --[[kgh]] (talk) 07:47, 8 March 2014 (UTC)

Well, the only thing that's different about the handling of the URL and Number types (other than the exact input length) is the validation - URLs have to start with "http" or the like, Number values have to be numbers. That wouldn't work for either of those other types. ("Temperature" also includes a unit, I think.) Yaron Koren (talk) 02:23, 10 March 2014 (UTC)

I think it might be nice to indicate in the documentation the default size to be expected for the respective fields in the form, e.g. 10, 35 or 100. I do not think that this information is related to the validation performed by the data type itself. --[[kgh]] (talk) 12:25, 10 March 2014 (UTC)

I just looked a the code in "SF_TextInput.php". If I interpret it correctly the input type for both is "text" with a default size of "35". Basically this is all I wanted to know. --[[kgh]] (talk) 12:55, 10 March 2014 (UTC)

Default type for String

Hi, after upgrading to MW 1.22.3, SMW 1.9.1.1 and SF 2.7 String fields appear as textareas in the form. Is textarea indeed the default input type for String types and should 'input type=text' be added to the form? --84.105.211.99 12:31, 10 March 2014 (UTC)

Hi - yes to both questions. In SMW 1.9, the "String" and "Text" types were merged into one type, that can hold an unlimited number of characters, so by default it's always edited with a textarea. Yaron Koren (talk) 12:38, 10 March 2014 (UTC)

Hi, the manual says the default input type for Text (SMW >= 1.9) is text not textarea. Is there a mismatch? Suzler (talk) 08:15, 8 May 2014 (UTC)

Oops! That was an error in the documentation. I don't know how it stayed in place for so long. Thanks for pointing that out. Yaron Koren (talk) 13:26, 8 May 2014 (UTC)

How to add a semantic property to automatic get the PAGENAME

I want to create a form and contain a semantic property to automatic get the PAGENAME. I don't know how to do it. Anybody can help me? Thank you!~

You can just add something like "[[Page name::{{PAGENAME}}]]" to the template - no need to add anything to the form. Yaron Koren (talk) 15:57, 14 March 2014 (UTC)

Storing multiple instance templates as individual records

We have many multiple instance templates within our forms, and have now created Querys to extract the information. When the query is run the multiple instance data is all outputted into the one field. Each instance shows separated by a comma ','. Is there a way to make this information store separetly. My thought was I need to add a unique number field to the templates. Appreciate any sugguestions for this.

Within each of those multiple-instance templates, the semantic data should be stored not via regular SMW tags but with #subobject or #set_internal - see here. Yaron Koren (talk) 13:41, 26 March 2014 (UTC)

Headers Being Duplicated when saving with forms

Hello, I am having an issue with semantic forms when trying to save a page edited with forms that has Sections (doesnt matter what level they are). If it matters, i created everything with PageSchemas.

Basically it is transcluding things from the form more than once, and only when editing with forms. I have under each section a template that can have multiple instances.

EDIT- this only happens on sections that do not have any information entered into the template itself under each section

Is this happening on a public wiki? If not, could you replicate this problem on a public wiki, like http://scratchpad.referata.com? Yaron Koren (talk) 03:15, 27 March 2014 (UTC)

It is on an internal wiki. I could not generate the pages from the schema on that wiki, but the schema source has been copied and pasted here

Also, on a side note, is there any way to specify the width of the column where the field name is in a form?

Yes, there are various ways to do it, via CSS. Yaron Koren (talk) 20:40, 30 April 2014 (UTC)

Showing preloaded values in read-only mode

Hi I am using the query string argument to preload values of date and time, like this

{{#formlink:form=Booking|link text=Book|link type=button|query string=Booking[date]=2014/04/14&Booking[time]=13:00}}

Is there a way to show the values of date and time (read-only) in the Special:FormEdit page which pops up when user presses the button? In the Form:Booking page a statement {{{field|date}}} shows the value but the user can change it. So, I tried {{#vardefineecho: thedate| {{{field|date|hidden}}}}} but this does not seem to work.

thanks for any suggestion! Tomy

ps: I searched for some time now and could only see light to get the values from the pagename via SemanticFunctions.

I don't know why you would want to do that, but you can probably do it using the UrlGetParameters extension. Yaron Koren (talk) 13:24, 27 March 2014 (UTC)

Thanks for the quick reply! I wanted the user to see the date of the booking while she is filling the booking form. I would be very glad if you could suggest a different/better way to achieve this using semantic forms.

Yes - use UrlGetParameters within the form. Yaron Koren (talk) 19:41, 30 March 2014 (UTC)

Multiple instance form very slow

We have a form that tends to get very slow with an increasing number of instances of the multiple instance templates.

The page itself takes 5 seconds to load, which is quite acceptable for a larger page. The form however takes 30 seconds. What could be a good approach to speed it up? --AdSvS (talk) 16:01, 27 March 2014 (UTC)

At the moment, I think the only solution would be to change from using a multiple-instance template to having separate pages for those entities. Yaron Koren (talk) 16:08, 27 March 2014 (UTC)

The form is much too popular for that! Are there things to avoid in the forms because of their impact on performance?--AdSvS (talk) 16:45, 27 March 2014 (UTC)

Well, lots of instances - I don't know how many instances you have on the slow pages, but after 20 or 30 or so, performance starts to be noticeably affected. Yaron Koren (talk) 19:29, 27 March 2014 (UTC)

How to allow a list within a field

I would like to allow users to create a list within several of the fields on my form. However, when I attempt to create a list using asterisks, the plain text, not the bullet point list that I want, is displayed. Is there a special way to create a list in Semantic Forms? Is it not possible to create a list in Semantic Forms?

You need to use #arraymap within the template for the field to hold a list - see here. It's not clear to me if you want it to be a bulleted list in the wikitext or the displayed page, or both, but in any case you'll need to change the "delimiter" and/or "new delimiter" parameters so that it's not just separated by commas. Yaron Koren (talk) 19:45, 30 March 2014 (UTC)