Extension talk:Page Forms

Adding a subcategory in the URL
Hi, this is probably an easy one to solve but I can't find the documentation. I would like to create a form that will create a new page under a specific (sub)URL.

For exemple :
 * Creating the page Wood using the form form:species
 * Will create a page with the URL : /index.php/species/Wood

Thanks. ClemFlip (talk) 16:54, 4 July 2016 (UTC)


 * That's a subpage, not a subcategory - you can do that by adding "|super_page=species" to either the #forminput or #formlink call, depending on which one you're using. Yaron Koren (talk) 04:26, 6 July 2016 (UTC)


 * Thanks. ClemFlip (talk) 11:43, 6July 2016 (UTC)

Extension:Translate and Semantic Forms
Hi, we would like to use the Extension:Translate to allow translations of pages created with forms. But we are having troubles and I would like to understand if Semantic Forms is compatible with this extension.

First, we can't insert the &lt;languages />&lt;translate>&lt;/translate> tags in templates in order to automatically embed the strings / value in field that will be translatable.

The only way to use Extension:Translate with Semantic Forms is to, once a page has been created thought the form, go to the edit page "&action=edit" and add manually the &lt;languages />&lt;translate>&lt;/translate> tags.

Then, we can't translate Property. Well, in fact it's possible to translate a Property page but when I go to a page that use a property and I switch language, system says that the translated words doesn't belong to the list of authorized values. For the system, only the original values (untranslated) are authorized.

Do you confirm that or is there a doc that I haven't seen? Thanks a lot. ClemFlip (talk) 13:38, 22 April 2016 (UTC)


 * I've never tried using Translate and Semantic Forms together, so there's not much I can contribute here. Maybe someone else reading this knows more. I will say that in part this is also a Semantic MediaWiki question; and more generally, it's an issue inherent to these extensions, in that none of them were designed to work on multi-lingual sites (that's part of why a new extension, Wikibase, was needed in order to power Wikidata). I do think that the handling needs to be different for fields that have a set list of allowed values, vs. those that can take in any sort of value. But I haven't really looked into any of it. Yaron Koren (talk) 19:02, 22 April 2016 (UTC)

Multiple instance forms for long tables
We are using a multiple instance template to add rows to a table. The table has 17 columns, so the form fails at around row 62 - assuming due to the php field input limit of 1000. This limit, along with the fact that loading time for the form get long after 20 or 30 multiple instances or so, suggests Semantic Forms may not work for this use case (managing large tables). We can't split information across multiple pages.

Could something like this work: a query-based display page (Cargo) that calls a single instance form for each row of the table, showing in a pop-up, so that each row is stored semantically as individual page in the background, but the person using the table never sees it. Maybe include a button/action in each row to "edit row", and another for "delete row". I think I can see how editing rows might work, I don't know about deleting them.

The goal obviously is a better UI for maintaining mediawiki tables. We can't use Visual Editor right now due to our custom skin. We would prefer to keep content stored in the wiki (as opposed to just pulling, say, Google Docs onto the page) so that we can use our draft/published control and permissions scheme (supplied by Ponydocs Extension).

Anyone have a magic solution we haven't thought of yet?

--Bgrenon (talk) 12:57, 13 April 2016 (UTC)


 * There's actually a new feature coming in SF 3.6 that might make the handling of large tables more doable - spreadsheet-style editing. 3.6 will hopefully get released in the next few weeks, so that might be worth trying out. On the other hand, I don't know how well it would display on the screen, with 17 columns. Unfortunately, there's no way to isolate a single instance of a multiple-instance template in a form. Why wouldn't the multiple-pages thing work? Yaron Koren (talk) 15:28, 13 April 2016 (UTC)


 * The spreadsheet editing feature is fantastic. Is there any drop-down functionality available for it?  The documentation mentions if there are multiple values, you'll get a dropdown, but I can't get that to work (using text or checkbox or unspecified input type).  (--Bgrenon (talk) 13:26, 13 June 2016 (UTC))


 * Yes - the easiest way to get a dropdown to appear is to add a "values=" parameter. Yaron Koren (talk) 16:50, 14 June 2016 (UTC)


 * Thanks for the response. This is not working for us (text field and checkbox only, no dropdown).  It may be a conflict between our custom skin and SF css.  That's where we'll look next anyway. --Bgrenon (talk) 14:17, 16 June 2016 (UTC)

Undesired effects of query form on page title and section headers
Using a query form in a page started to have undesired effects after updating Semantic Forms.

I have a page Sandbox with the following code: = a = == aa == === aaa ===

The page title (first line in the page) is displayed as Spezial:RunQuery/QueryAuflage instead of Sandbox and the section headers are displayed as UNIQ70028b3423b19709-h-0--QINU a, UNIQ70028b3423b19709-h-1--QINU aa, and UNIQ70028b3423b19709-h-2--QINU aaa.

(MediaWiki 1.21.2, Semantic MediaWiki 1.8.0.4, Semantic Forms 3.6-alpha) LambdaB (talk) 12:58, 14 April 2016 (UTC)


 * Hi LambdaB, this is a known issue and one for which there is no fix I'm afraid. Best advice is to ensure that any embedded query form comes first in the page's syntax. You can sort of cheat around this though by using CSS to lower the embedded form. Cavila 19:03, 26 May 2016 (UTC)

Size in percentage for text input boxes?
This is admittedly a request, but would it be possible to make the size parameter for text input boxes to be a percent of the container rather than number of characters (or to have that option)?

The reason I ask is that I have such a pain trying to edit the CSS appropriately for these, especially if I'm trying to build multiple instance templates. Character numbers are quite difficult to work with for different browser window sizes or anything responsive. If I'm missing an easy trick, I'd love to hear that also of course.

Thanks for the consideration! --Joshkking (talk) 14:13, 16 April 2016 (UTC)


 * It would be nice if there were a way to do that directly, although you can instead use the "class=" parameter, and set the width in the CSS. Although maybe you knew about that one, given that you mentioned CSS. Have you tried this? If so, what's the difficulty? Yaron Koren (talk) 13:23, 17 April 2016 (UTC)

Multiple loading of SemanticForms Extension
During initial setup using index.php (when LocalSettings.php is absent), if you choose the SemanticForms extension, the setup will add two lines

The first line ```# wfLoadExtension( 'SemanticForms' );``` should not be included or it checks for certain things (version, flags, etc) that it should abort loading.

I encountered this issue

After I commented the first line, its work fine now.

Yoonghm (talk) 06:00, 17 April 2016 (UTC)


 * What setup process are you using? I didn't know there was a MediaWiki setup process that also added extensions. Yaron Koren (talk) 13:20, 17 April 2016 (UTC)

Enable links to forms
I followed the instructions of your example in the quick start guide exactly. This works great. After I altered the template as described in the 'enable links to forms' section, something strange occurs.

When you create a new book, the values of Genres are stored in the Authors field and those of Authors in Genres. Why is that?

--C Wagner (talk) 08:37, 18 April 2016 (UTC)


 * Where is the error - in the underlying wikitext, in the display of the page, or in the values stored by Semantic MediaWiki or Cargo? Yaron Koren (talk) 16:44, 18 April 2016 (UTC)


 * The error is visible in the wikitext, the display of the page and in the values stored by Semantic MediaWiki. C Wagner (talk) 14:16, 3 May 2016 (UTC)


 * Great - it sounds like the error is in the form. Could it be that, in the form, you have something like "Authors: ", i.e. the wrong labels for the fields? Yaron Koren (talk) 15:05, 3 May 2016 (UTC)


 * No that's not the case. In Form:Book there is "Authors: " C Wagner (talk) 10:48, 4 May 2016 (UTC)


 * Alright. Could it be that you just entered the data in the wrong fields when filling out the form? Yaron Koren (talk) 13:51, 4 May 2016 (UTC)


 * I reinstalled again and the problem seems to be gone now. Thanks anyway. C Wagner (talk) 11:53, 3 June 2016 (UTC)

Error using datepicker
When I use the  input type, I get the following error:

Warning: OutputPage::getModuleStyles: style module should define its position explicitly: jquery.ui.datepicker ResourceLoaderFileModule [Called from OutputPage::getModuleStyles in /w/includes/OutputPage.php at line 623] in /w/includes/debug/MWDebug.php on line 300

Using:
 * MediaWiki: 1.26.2 (f465524)
 * PHP: 5.6.20 (cgi-fcgi)
 * Semantic Forms: 3.6-alpha (77c4a3b)

Jaider msg 18:31, 22 April 2016 (UTC)


 * Sorry for the long delay. This is due to a MediaWiki bug - I just added a note about it (including a fix) here. Yaron Koren (talk) 18:54, 28 April 2016 (UTC)
 * Thank you, Yaron. Do you know if there is an open bug report on Phabricator to follow up on this issue? Jaider msg 23:20, 2 May 2016 (UTC)


 * No idea. I actually don't even know if the error still shows up in MW 1.27 - I seem to remember that it doesn't, but I could be wrong about that. Yaron Koren (talk) 00:13, 3 May 2016 (UTC)

Spreadsheet mode with combobox
The new spreadsheet-style editing approach is really nice, but it's missing combobox support. Are you planning to add it?


 * It would be great to have autocompletion within the spreadsheet display, but I have no specific plans to add it. It would require custom JS programming - how much of it, I don't know. Yaron Koren (talk) 16:04, 18 May 2016 (UTC)

Force unnamed parameter for template?
Hi,

is there a way to force unnamed parameters to always be printed out? By the way I did not find any section for the  configuring variables. --Andreas P. 09:19, 24 May 2016 (UTC)


 * Do you mean print something like "1=ABC" instead of just "ABC"? I don't think so. The documentation for the $sfg global variables is scattered around in different sections - perhaps there should be one central list of them. Yaron Koren (talk) 14:39, 24 May 2016 (UTC)
 * "1=ABC" instead of just "ABC"? yes. With SF 3.4.1 there is the problem: adding an equal sign into the form field, e.g. "ABC=lorem ipsum" to an unnamed template parameter it does not transform to "|1=ABC=lorem ipsum" but to "|ABC=lorem ipsum", which distorts the template structure --Andreas P. Icon_External_Link_E-Mail.png 22:56, 24 May 2016 (UTC)


 * That's true. Why not just give the fields names, then? Yaron Koren (talk) 00:34, 25 May 2016 (UTC)
 * Well I guess I understand what you're pointing at, but I'd like the extension to take care of it to transform (always) to the unnamed parameter, e.g. "|1=lorem ipsum" --Andreas P. Icon_External_Link_E-Mail.png 08:27, 25 May 2016 (UTC)
 * That's a fair point; I guess the real solution is for the form to add the number if the value contains an equals sign? Yaron Koren (talk) 11:43, 25 May 2016 (UTC)

Autocomplete glitch
Thanks for the SF 3.6 release, Yaron and everyone else who made this possible. One thing I noticed is that autocomplete did not work properly on pages in a namespace other than the 'main' one - using textarea with autocomplete: the dropdown only shows me possible values when the namespace prefix has been entered. More specifically, it is just the first word of a value (after the prefix) for which this issue exists. Say, for instance, that there is a page called "Wiki:Cars for rent". No matching values are found if the user types "Cars", but things are okay if he/she types "Wiki:Cars" or "for" or "rent". I don't think I've seen this using SF 3.4. Cavila 18:57, 26 May 2016 (UTC)


 * That's odd. Is "Wiki" (or whatever the text you're actually using is) a "true" namespace? If you go to the talk page for that page, does its title look like "Wiki talk:Cars for rent", or "Talk:Wiki:Cars for rent"? Yaron Koren (talk) 11:32, 29 May 2016 (UTC)


 * It certainly is, even though it is a custom namespace (with SMW enabled) and I did not create a talk page to go along with it. Perhaps I should also mention that $wgCapitalLinkOverrides has been set to 'false' for this particular NS and pages in this NS are not viewable by anonymous visitors. If I replace 'values from concept=...' with 'values from namespace=...', I do get results but they are shown without the namespace prefix. Cavila 19:36, 30 May 2016 (UTC)


 * Oh... you didn't mention that this was for "values from concept". That explains it. I think this behavior has been in place since the beginning, although it's not ideal - hopefully I or someone else can fix it. Yaron Koren (talk) 20:18, 30 May 2016 (UTC)


 * Looking back, I think it did work in 3.4, if only to an extent because not all values were retrieved from the DB. Anyway, I've had more luck trying an alternative approach, which is to switch to "tokens" and use a mapping template to strip away any namespace prefix. As far as I can tell, that seems to do it (!), although "tokens" isn't my preferred choice of input. Cavila 08:11, 24 June 2016 (UTC)

Autocomplete does't work

 * Confirm this bug in namespace (V. 3.6 (c7c5c0e)), autocomplete doesn't work in most fields. 3.4. works fine. Any help for this? Thanks a lot. --Tom Jac (talk) 11:16, 25 July 2016 (UTC)


 * Is this happening for fields that use "values from concept"? Otherwise, it's a separate issue. Yaron Koren (talk) 12:14, 25 July 2016 (UTC)


 * No. Here an example: (own wiki) Thanks a lot. --Tom Jac (talk) 06:37, 27 July 2016 (UTC)


 * Okay, this is unrelated. There could be any number of things going wrong; one possibility is that the form doesn't know where to get the values from. Assuming the autocompletion values are supposed to come from either SMW or Cargo, you should add either "property=" or "cargo table=" and "cargo field=" parameters to the field tag, to make it explicit. Yaron Koren (talk) 12:46, 27 July 2016 (UTC)


 * Like this? - doesn't work. The problem has existed for the last updates. Previously everything worked. The crazy thing is that other fields with the same parameters are still working. Using a German localisation. --Tom Jac (talk) 14:28, 27 July 2016 (UTC)

Randomizing letter combinations
With the one-step process for form creation, one can create the page title automatically during the creation of the form. There is the option to randomize numbers and adding letters to this number combination in a format like "abc12345", e.g. BBC04385. I would like these letters "abc" also randomized, is there any way to do so? --Zabien (talk) 17:12, 1 June 2016 (UTC)


 * That's interesting - no, I don't think it's possible, and I don't think anyone has asked for this before. What format do you want the random string to be - always three letters and five numbers, or something more random? And why? Yaron Koren (talk) 17:31, 1 June 2016 (UTC)


 * I would love to have the choice! I like the usage of something like  or  . But as far as I know, a page title cannot start with a number ("due to a bug in SF"), so one would have to add a letter combination in the beginning . Letters exponentiat by 26, numbers only by 10, so the random combination would simply be shorter when it's also including letters.


 * Of course it can't be something like  to use it like , this surely wouldn't work easily. But could it not simply be defining an entire string by letter positions? (Something along this, general this.) It thought there'd be a parser function for these string calculations, but can't find it. The freedom to work with combinations like "abc12345abc" or even wilder would also be possible – though I agree their usefulness would be hard to argue for.


 * I'm guessing that that SF bug still applies even if the random number/string starts with a letter and not a number, unfortunately... though I could be wrong. But if there indeed is an advantage to having letters in there, I think this would have to be done via a hook - i.e., a hook gets added to the relevant function in the SF code (makeRandomNumber), and then some outside code gets added that creates its own random string according to its own rules. I could take care of adding the hook part. Yaron Koren (talk) 20:17, 1 June 2016 (UTC)


 * Sounds good! :)) --Zabien (talk) 16:47, 3 June 2016 (UTC)

Popup - Idle-Symbol doesn't disappear
Hi Yaron and thanks for the great work on Semantic Forms. I just have one little issue: after creating a record with a SemanticForms popup, the record is stored. This is fine. But the idle symbol from the popup doesn't disappear after clicking the save button. When I refresh the browser I'm back on the articel from where I called the Popup. I'm using: Also in the JavaScript console there is no error. Do you have any ideas?
 * MediaWiki 1.26.3
 * Semantic MediaWiki 2.3.1
 * Semantic Forms 3.6
 * PHP 5.5
 * MySQL 5.5

Thanks in advance. --DirkCogno (talk) 15:50, 6 June 2016 (UTC)


 * Do you mean this image? Are you sure it's supposed to appear after hitting "Save"? I only remember it displaying when the popup form is being loaded. Yaron Koren (talk) 14:08, 6 June 2016 (UTC)


 * Yes, exactly this image. It really appears after hitting "save". --DirkCogno (talk) 16:36, 6 June 2016
 * Have the some problem with SF 3.2 sometimes. In some cases i get a small window (1x1 cm²) with the only content "undefined". No hints at JS Console. With SF 2.7 everything works fine. With 3.6 popup i have the problem, that empty mandatory fields are not recognized. --SnowlDD (talk) 17:31, 6 June 2016 (UTC)


 * Sorry about these problems. Thankfully, I was able to reproduce the issue on my own wiki - I guess I just haven't tried out popup forms in a while. Anyway, I just checked in what I think is a fix; if you get the latest code from Git, the problems will hopefully go away. Yaron Koren (talk) 02:03, 7 June 2016 (UTC)


 * Thank you very much. That helps us a lot. :) --DirkCogno (talk) 09:52, 8 June 2016

Combobox mandatory
I'm using combobox in combination with 'values from property' and there doesn't seem to be a way to clear the field after it has been filled before.

This makes it automatically mandatory, which is nog what I had in mind. Is there a way to go around this? --AdSvS (talk) 08:34, 10 June 2016 (UTC)


 * For a combobox, you just need to click on the top (blank) value in the dropdown to clear the input. Does that not work for you? Or are you asking about something else? Yaron Koren (talk) 11:39, 10 June 2016 (UTC)

Populating a listbox with page names and a property of these pages
We're currently using a form to create a page for different measurements, e.g. temperature tests. In this form, we select the test equipment which was used to perform the test, e.g. a thermometer. Unfortunately, the test equipment is described on pages with IDs as the page title, e.g. TestEquipment:1234. On these pages, there is more information about the test equipment, e.g. type, device name or serial number.

Currently, we only populate the test equipment listbox with the page title (values from category=test equipment). As the page titles are only the IDs of the devices, it is hard to see which device you have selected, you'd have to check the corresponding wiki page to make sure you've got the right one.

Is there any way to display a property, like the name, together with the page name in this listbox? Something like this would be great:
 * TestEquipment:1234 (Thermometer TX250)
 * TestEquipment:1235 (Humidity Sensor HX3000)
 * 

-- Novac1993 (talk) 09:19, 10 June 2016 (UTC)


 * You probably need to use a "mapping template" - see here. Yaron Koren (talk) 11:41, 10 June 2016 (UTC)


 * Thank you! I created a new template and added it to the listbox via "mapping property=" "mapping template=". The template looks like this:


 * Now, the listbox entries look like my example above. -- Novac1993 (talk) 08:04, 13 June 2016 (UTC)


 * However, when I save the page with an entry selected, the page will get saved with the displayed string (e.g. TestEquipment:1234 (Thermometer TX250) ) instead of the page name (e.g. TestEquipment:1234). Is there a way to make this behave like the "mapping property" (displayed string != saved string)? -- Novac1993 (talk) 08:13, 13 June 2016 (UTC)


 * That sounds like a major bug. Did you mean "mapping template" above, by the way, when you wrote 'via "mapping property="'? Yaron Koren (talk) 13:28, 13 June 2016 (UTC)


 * Whoops, I meant mapping template, yes. The selected list entry is saved just as it is displayed in the listbox (e.g. "TestEquipment:1235 (Humidity Sensor HX3000)" ) instead of the correct value of the field (e.g. "TestEquipment:1235"). -- Novac1993 (talk) 13:53, 13 June 2016 (UTC)


 * Alright. What version of SF are you using? Yaron Koren (talk) 15:16, 13 June 2016 (UTC)


 * We're still on MW 1.23.13 with SMW 2.3 and SF 3.4. We're planning to upgrade MW and all extensions as soon as 1.27 is out. -- Novac1993 (talk) 15:37, 13 June 2016 (UTC)


 * Ah. It's possible that this bug has been fixed already. Yaron Koren (talk) 16:42, 13 June 2016 (UTC)


 * I'll try this again after the upgrade, thank you for the help! -- Novac1993 (talk) 08:18, 14 June 2016 (UTC)


 * Just FYI, upgrading to MW 1.27, SMW 2.4.1 and Semantic Forms 3.6 fixed the problem! -- Novac93 (talk) 12:52, 11 August 2016 (UTC)


 * Great! Yaron Koren (talk) 13:24, 11 August 2016 (UTC)

Default value ignored in field
During updating our test wiki we stumbled on an issue with Semantic Forms. When using the following syntax in a Form  the   is ignored. Defaultvalue1 is of the type Text. This is working in SF 3.4.1. Is this a bug or did I miss something in the documentation? See example on the SMW sandbox wiki: http://sandbox.semantic-mediawiki.org/wiki/Defaulttest

We are testing on:
 * MW 1.26.3
 * PHP 7.0.7
 * SMW "dev-master"
 * SF "dev-master"
 * open-layers "dev-master"

Thanks, --Felipe (talk) 13:04, 10 June 2016 (UTC)


 * I think it's just because you're editing an existing page - the default value only applies when creating new pages. By the way, it's cool that you're using the OpenLayers extension - I didn't know if anyone had tried that out yet. Yaron Koren (talk) 14:46, 10 June 2016 (UTC)


 * Hello Yaron, thanks for the quick responds. When properties are added or changed in a template we often set a default value. We do this all the time and as long as I can remember the default value in a form always worked, on new pages but also on existing pages. This is a very powerful feature. Wen adding new properties it is not possible anymore to fill in a default for mandatory fields. What happens in the current situation is that users now need to set all the new fields manually before they can save the page, this is not very user friendly. You can also see this happening in the examples when you try to save the page. In the past you never had the option on a mandatory field with a set default to select "nothing" and now you have this option. This new behavior more or less breaks our wiki. Is it possible to revert back to the old behavior where the default can be used on all pages existing and new? Btw,  for a date input because it is not working in SF dev-master. I am not sure if what I did is the correct way but it seems to be working fine. See phabricator for details in attached file. --Felipe (talk) 12:05, 13 June 2016 (UTC)

Sematic-forms (dev-master) requires open-layers when installed via composer
It is mentioned in a previous topic but I made a new one to not mix stuff up. When installing SF via composers it requires open-layers to be installed. result: Problem 1 - Installation request for mediawiki/semantic-forms dev-master -> satisfiable by mediawiki/semantic-forms[dev-master]. - mediawiki/semantic-forms dev-master requires mediawiki/open-layers dev-master -> satisfiable by mediawiki/open-layers[dev-master] but these conflict with your requirements or minimum-stability. Is this correct? --Felipe (talk) 08:45, 14 June 2016 (UTC)


 * I don't know much about Composer, but it looks like the addition of the OpenLayers extension as a requirement in SF's composer.json (which somebody else added) was probably a bad idea. Yaron Koren (talk) 16:02, 14 June 2016 (UTC)


 * It was not done by accident but with a purpose see here. Is this not something that should be in SemanticResultFormats or does SF really depend on OpenLayers? --Felipe (talk) 06:33, 22 June 2016 (UTC)


 * Yes, I know it was done on purpose. SF can make use of the OpenLayers extension, for its "openlayers" input type, but it probably shouldn't require the extension in Composer. Yaron Koren (talk) 13:41, 22 June 2016 (UTC)

Randomiser () broken in SF 3.6?
I'm not sure if it's me but either the page ends up being saved without a number or it isn't saved at all. Is this perhaps a bug specific to 3.6? Cavila 07:41, 27 June 2016 (UTC)


 * We use  and that works just fine. Also tried   which also works ok.
 * We are using SF 3.6 master, SMW-2.4.0-rc1 master and a whole bunch of other extensions on MW-1.26.3. Maybe when you try to isolate the problem by disabling all other extensions. --Felipe (talk) 09:35, 27 June 2016 (UTC)


 * Yes, this bug was fixed on June 1, so it exists in version 3.6 but not in master. I plan to release a 3.7 at some point soon... Yaron Koren (talk) 13:41, 1 July 2016 (UTC)


 * Thanks! Cavila 13:45, 1 July 2016 (UTC)

Download Links broken
Actually all download-links (zip + git) under "Download and Installation" are broken. Could you please fix this? Used https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticForms for git clone. RacingRalf (talk) 08:46, 1 July 2016 (UTC)


 * Ah, yes - the removal of git.wikimedia.org threw everything off. I just updated the links for SF; now I have to do it for all my other extensions... Yaron Koren (talk) 13:39, 1 July 2016 (UTC)


 * Thx! RacingRalf (talk) 12:13, 4 July 2016 (UTC)


 * Download works but installation is broken (extension-semanticforms vs SemanticForms) C Wagner (talk) 10:45, 4 August 2016 (UTC)


 * Yes, that's true - sorry. I just changed the git clone URL, so if you use this one, the directory should have the right name. Yaron Koren (talk) 14:57, 4 August 2016 (UTC)

Only 1 datepicker is shown in a form
Hello, I noticed that when using SF 3.6, SMW 2.3.1 in MW 1.23.x (PHP 5.4.x) if two datepickers are included in a form, only the first one is shown. --Toniher (talk) 20:53, 8 July 2016 (UTC)


 * I can't reproduce this problem. Are you seeing any JavaScript errors in the console? And do you have Semantic Forms Inputs also installed, and if so, what version? Yaron Koren (talk) 13:26, 12 July 2016 (UTC)

Spreadsheet-style editing : one empty row is created at every form edit
even if we dont edit the spreadsheet part of the form.

Any has the same behaviour ? have found a workaround ?

Thanks,

Nicolas NALLET (talk) 13:02, 11 July 2016 (UTC)


 * You found a bug in the handling of spreadsheets - it looks like it was introduced on May 31. Sorry about that. I just checked in what I think is a fix. Yaron Koren (talk) 02:42, 13 July 2016 (UTC)

Error 500 on any Form
Hi, y'all.

Any time I attempt to access anything to do with a Form, I generate an HTTP Error 500. This includes all the Forms special pages, and the forms I've attempted to create manually. I also seem to be missing the #default_form parser hook, though I don't know if that's related or not, and I can't seem to find any info on what to do to get that hook installed on its own anyway. I'm running:

Product	Version

MediaWiki	1.27.0

PHP	5.5.9-1ubuntu4.14 (apache2handler)

MySQL	5.5.47-0ubuntu0.14.04.1

ICU	52.1


 * What version of Semantic Forms are you running? Also, this may help. Yaron Koren (talk) 12:07, 22 July 2016 (UTC)

Getting the latest entry via forms
I was wondering whether it would be possible to access the latest entry of a forms submission via query without changing forms. Basically something like a submission timestamp. Could it be done via cargo?


 * I don't understand. What do you mean by "without changing forms"? Yaron Koren (talk) 21:49, 24 July 2016 (UTC)

Remote autocomplete and mapping property don't work together
Hi all,

I've been using Semantic MediaWiki extensively on our Intranet and I've hit a snag.

I've frequently been using URLs of the form "Object:" to store semantic pages, and then using the Semantic Titles extension for useful display titles. For autocomplete values on Semantic Forms, I use the mapping property parameter to specify the title property so that the friendly title is displayed to users. This works well for small autocomplete lists; however, I have discovered that when remote autocomplete is in action (when there are a large number of possible values for autocomplete), the mapping property parameter is ignored.

I'm using SF 3.4.

Is there a fix for this already?


 * Unfortunately, no. What you can do, though, is increase the size of $sfgMaxLocalAutocompleteValues (by default, it's 100), to make remote autocompletion occur less. Yaron Koren (talk) 13:01, 5 August 2016 (UTC)


 * Thanks a bunch for the suggested workaround. Unfortunately the category I'm trying to autocomplete has over 16,000 pages so I'm not sure how practical that will be but I'll give it a go. User:Kriegfrj2
 * Oh... that doesn't sound practical at all. Yaron Koren (talk) 02:19, 7 August 2016 (UTC)

#time parser function SMW 2.4.1
The #time parser function described in seem to be broken with Semantic MediaWiki 2.4.1

How can I manually set the display format for dates? C Wagner (talk) 13:57, 5 August 2016 (UTC)


 * What do you mean by "broken"? It's not part of SMW - it's part of the ParserFunctions extension - and as far as I know, it still works fine. Yaron Koren (talk) 14:41, 5 August 2016 (UTC)


 * I have in a SMW template but it keeps formatting Y/m/d since upgrade to SWM 2.4.1 C Wagner (talk) 15:01, 5 August 2016 (UTC)


 * I don't see any way that the SMW version would have an impact on this. Did you also upgrade MW? Maybe you need to also upgrade ParserFunctions? Yaron Koren (talk) 17:53, 5 August 2016 (UTC)


 * Thanks a lot for the tip. Solved. You're doing a great job! Even solving problems not directly connected to your extension. C Wagner (talk) 07:19, 6 August 2016 (UTC)

Using a template to hold a form parameter value
I would like to use the same tree structure on several forms, and have it be relatively easy to add elements to that tree structure -- i.e. I don't want to have to edit each form to keep them all in sync. This could be done by setting up categories for all the tree nodes, but I'd prefer to avoid creating all those categories. I've tried using the following:

where Template:Hierarchy is looks something like:


 * Root
 * Child 1
 * Child 2

... but when the form is rendered, this gives a blank box with a stray }} afterwards.

Should it be possible to use templates to provide form parameter values? If so, how should I do it? If not, can you suggest another way to approach this? (The HierarchyBuilder extension looks good, but unfortunately we're using Cargo, rather than SMW.)

Many thanks! Paul T (talk) 14:51, 9 August 2016 (UTC)


 * I first thought this was a more complex problem, but actually it's just due to the 2nd issue described here. If you put a space before the three closing brackets, it should work. Yaron Koren (talk) 17:35, 9 August 2016 (UTC)


 * Thank you. Adding a space fixes it. Apologies for overlooking that. Paul T (talk) 10:50, 10 August 2016 (UTC)

undefined SF_Namespaces with German language code
in our german mw $wgLanguageCode = "de"; (switch to "en" -> no warnings)

i got warnings of not defined SF_NS_FORM and SF_NS_TALK in SF_Namespaces.php.(since mw125)

so i have to wrote in begin of extensions/SemanticForms/languages/SF_Namespaces.php

(like it was done in Maps/Maps.i18n.namespaces.php for the layer-namespace)

Is this a known problem? - Flexmaen (talk) 21:59, 10 August 2016 (UTC)


 * That's strange - I haven't heard of that one before, I don't think. What version of Semantic Forms and MediaWiki are you running? And are you running Semantic MediaWiki as well, and if so, what version? Also, are you calling SF after SMW in LocalSettings.php (assuming you're using SMW)? Yaron Koren (talk) 02:30, 11 August 2016 (UTC)


 * MW 1.27, SMW 2.4.1, Semantic Forms 3.6. Installed via composer which first calls for SMW and then for SF. - Flexmaen (talk) 11:09, 11 August 2016 (UTC)


 * Ah - the use of Composer is probably the issue. SF fails in different ways when it's installed with Composer; I believe that with the very latest version of SF, Composer is now disabled. I would uninstall SF with Composer and then download/install it in the "normal" way. Yaron Koren (talk) 13:23, 11 August 2016 (UTC)


 * This problem also exists when SF is installed the "normal" way. This was not our first installation - we installed SF many times now, but this time had this problem with the specific versions. So maybe someone could check if this is not a general problem rather than a mistake in the installation procedure. - Flexmaen (talk) 10:53, 13 August 2016 (UTC)


 * Alright. My new guess is that this behavior is due to changes in SMW 2.4.1, which was just recently released, which is why no one else has pointed out this error yet. Anyway, I just checked in what I think is a fix, based on your fix - it does seem to be a more reliable solution. Thanks! Yaron Koren (talk) 19:03, 14 August 2016 (UTC)

Classes for links and buttons
Hi Yaron, I was wondering if you could add a small new feature to the next release of SF. Those default grey buttons are not exactly eye-candies so it would be wonderful if the #forminput, #formlink and #autoedit parsers let you add a text and button class. I'm sure that others would appreciate this. Cavila 08:24, 15 August 2016 (UTC)


 * Are you talking about setting the appearance of those buttons across the wiki, or just in individual pages? If it's the former, most of those inputs already have classes you can use. Yaron Koren (talk) 15:49, 15 August 2016 (UTC)