Extension talk:Page Forms

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)

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 "  ". 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

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:

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)

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)

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 ? The maintenance/update script does not work when  is active nor does the script SMW_refreshData.php. It stops with. 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 --&#91;&#91;kgh&#93;&#93; (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 --&#91;&#91;kgh&#93;&#93; (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  ("enableSemantics" is disabled) or   ("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   or   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. Icon_External_Link_E-Mail.png 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. --&#91;&#91;kgh&#93;&#93; (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):
 * 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 --&#91;&#91;kgh&#93;&#93; (talk) 10:07, 4 March 2014 (UTC)
 * 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 --&#91;&#91;kgh&#93;&#93; (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
 * 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. Icon_External_Link_E-Mail.png 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)
 * 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. Icon_External_Link_E-Mail.png 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)
 * 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. Icon_External_Link_E-Mail.png 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 --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (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)