Extension talk:Page Forms

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)

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)

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)

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)