Extension talk:Page Forms

Mandatory and input type=tree
From my testing looks like  doesn't work in conjunction with. Is there a way to force the user to select a value (or in case of  at least one)? PeterBodifee (talk) 10:25, 1 February 2017 (UTC)


 * I don't think so... if that doesn't work, it sounds like a bug. Yaron Koren (talk) 03:50, 2 February 2017 (UTC)


 * This is my construct in the form  : it allows me to save the page without selecting a value for Context. Should I report the bug (and where)? We use   PeterBodifee (talk) 08:00, 2 February 2017 (UTC)


 * That's a pretty old version. I'd recommend upgrading to the latest version, i.e. switching to Page Forms - it's possible that this bug has been fixed already, and I think it's a good idea anyway. Yaron Koren (talk) 14:37, 2 February 2017 (UTC)


 * Ok finally got IT to upgrade our test wiki to Page Forms 4.1, which runs now on MW 1.27.1, SMW 2.4.2. Still can save pages with fields being empty when values are to be selected from  in combination with  . Actual code:


 * Leaving Editor empty doesn’t allow to save page, not selecting a value for Scope is not stopping the page to be saved.


 * Oh well - I guess it's a real bug. You can consider it reported, although if you want you can also create a task for it on Phabricator. Yaron Koren (talk) 02:16, 8 March 2017 (UTC)


 * https://phabricator.wikimedia.org/T160007  PeterBodifee (talk) 23:52, 8 March 2017 (UTC)

Query using only some of the fields
Hi. My problem is this: I have a semantic form with 3 fields, but, if want to use the query I have to write the values for all the 3 fields. Is there a way to query using only some of the values and leaving the rest in blank? Thanks.


 * I don't know whether you're doing the query with SMW or Cargo, but whichever it is, this sounds like a question for that extension, not for Page Forms. Yaron Koren (talk) 03:00, 9 February 2017 (UTC)

using a form to edit a template call and leave rest of page alone
We have an established wiki that has used templates and SMW ad-hoc for some time. I am trying to add forms to edit where templates are used. What I am finding is that the template is yanked to the top of the page, and any surrounding text is put around it. What I had hoped is that it would stay in place. Have I set up my form incorrectly, or is this the nature of the beast and I can't use it this way? Thanks! Tenbergen (talk) 03:52, 10 February 2017 (UTC)


 * I assume you meant "put below it". You might be able to avoid this by using partial forms, though personally I would recommend making your pages more structured and less ad hoc. Yaron Koren (talk) 16:06, 10 February 2017 (UTC)


 * Your point is taken, Yaron: if I were to re-design the wiki or add new concepts I would use forms more comprehensively. I am trying to introduce them slowly into a live environment for now. If I can show the benefits of having them for my template that involves dates then I think people will come on board for bigger changes. The template I am working with is usually used in the middle of a page; within its own section, but still in the middle of a page. I think the "partial form" tag is just what I need.
 * When I add the "partial form" tag, my preview stops working. The example given in partial forms is this. However, that uses cargo, so I can't simply steal from there. Should the preview work using just SMW?
 * Also, when I save from the form with the partial form tag, I end up with an empty page. Works without the partial form tag.


 * The latter sounds like a major bug - sorry about that. Partial forms are a very under-used and under-tested feature, so it's not surprising (though disappointing) that it might have a bug like this. Hopefully it'll get fixed. (I assume you're using a recent version of Page Forms.) Yaron Koren (talk) 15:34, 15 February 2017 (UTC)
 * I am using Page Forms version 4.0.2 (fbecc9f) 2016-12-19T15:47:40 . I have created a task in Phabricator. Tenbergen (talk) 17:37, 15 February 2017 (UTC)

Namespace collision with Scribuntu extension for Italian language
Can you please check if you can replicate/confirm this?

PageForms extension defines the following namespaces: SemanticForms/includes/SF_Hooks.php: defines( 'SF_NS_FORM', 106 ); SemanticForms/includes/SF_Hooks.php: defines( 'SF_NS_FORM_TALK', 107 ); The namespace translation in Italian is: SemanticForms/languages/SF_Namespaces.php:  SF_NS_FORM           => 'Modulo',

Hence, a form named Test would correspond in italian to the article Modulo:Test rather than Form:Test.

Scribuntu extension defines the following namespaces: Scribunto/Scribunto.php: define( 'NS_MODULE', 828 ); Scribunto/Scribunto.php: define( 'NS_MODULE_TALK', 829 );

The same extension defines the following in the Scribunto.namespaces.php configuration file: ... $namespaceNames['it'] = array(       828 => 'Modulo',        829 => 'Discussioni_modulo', ); ...

The id of the two namespaces is different (106 vs 828) but having the same "label" for the namespace (Modulo) does not allow to create Forms (they will be parsed according to Scribuntu and expect some lua scripting code in it..).

I will eventually try to change the Scribuntu configuration using a different "label", and see if this can work around the issue.. ..can you please check this? Eventually other languages might be impacted.

thanks Mik


 * Ooh, that's a problem - "modulo" indeed seems to be the Italian word for both "form" and "module". I don't know if there's such a problem in any other language. I looked it up, and it seems like "formulario" is an alternate word in Italian for "form". Maybe that could just be used instead for the Page Forms namespace? Is it a common word? Yaron Koren (talk) 14:43, 16 February 2017 (UTC)


 * In my case, I handled the issue changing the configuration on Scribuntu extension side.. but this was simply because I had not so much time and there were less configuration to change. In my opinion, the keyword should remain "Form" whatever the language is (indeed this is what is currently done for the Template). This would simplify things and also solve other problems (eg. I saw people following english tutorial and creating Form:Something on other languages wiki, ending up with extension not working or duplicate forms, one in english one in their own language..; also, imagine to export/import the forms among different languages.. do they need to be moved according to the language?). Thanks. Michele.Fella (talk) 24 February 2017


 * Are you sure about that problem? I think that, if you go to the page "Form:ABC" on a wiki in any language, it will bring you to the correct form namespace in that language. In any case, what do you think about "Formulario"? Yaron Koren (talk) 13:58, 24 February 2017 (UTC)


 * You are right Yaron: being allowed to create both Form:ABC and Modulo:ABC is just another effect of this issue. About the translation in Italian, if you really don't want to keep the word "Form" for Italian.. a good translation would be "Maschera di inserimento"; Hence, I think "Maschera" would be a better word than "Formulario" in this case. Michele.Fella (talk) 25 February 2017


 * Ah, "input mask" - that's pretty neat. I looked it up, and "maschera" does seem to get used for computer entry forms, so that seems like a good solution. I just changed it in the code. Thank you! Yaron Koren (talk) 02:54, 27 February 2017 (UTC)

input types
Extension:Page_Forms/Input_types lists a bunch of options. Not a lot of info is given on how to use them. For example, how do I even put options into a dropdown? Can I populate them from categories or queries? I have looked at some of the wikis listed in Extension:Page Forms/Sites that use Page Forms, but what I have found is pretty generic, looks like most came from the automatic generator. Is there more documentation elsewhere? Is there a wiki that has actually made some more advanced use of these input types? Tenbergen (talk) 23:09, 16 February 2017 (UTC)


 * The answer to that specific question is here. Yaron Koren (talk) 03:15, 17 February 2017 (UTC)
 * Thanks Yaron, yes, I did find that. I was wondering about some more elaborate examples. For example, can I use a query to populate a listbox, that sort of thing. I think I just understand code better by looking at some examples. Tenbergen (talk) 17:55, 18 February 2017 (UTC)


 * If you're using SMW, you can basically do that with "values from concept", or, I believe, with the Semantic Forms Select extension, though I haven't tried it. I agree that more examples would be helpful. Yes, there are wikis that make advanced use of these input types. Yaron Koren (talk) 03:05, 19 February 2017 (UTC)

requirements for #rating
I'm testing the new rating input: just prints No stars. Am I missing any requirements? Using Page Forms 4.1 (39557fb) and Semantic MediaWiki 2.4.6 on MediaWiki 1.28.0 C Wagner (talk) 09:57, 17 February 2017 (UTC)


 * The #rating function isn't defined by Page Forms - that's from the Semantic Rating extension; you'll have to install that. Yaron Koren (talk) 15:50, 17 February 2017 (UTC)

Autocomplete with characters limit?
I am using Page Forms 4.1 and I have a problem with an input like this:

The values are "cut" at the end of the strings, see. I realized it is happening not only with "text with autocomplete" input type, but also with "textarea with autocomplete", "tokens" and "combobox" (I did not test with other input types).

The values are coming from here, which are all fine. So, is this a bug, or did I forget to set some configuration for character limit in autocomplete? Jaider msg 12:39, 18 February 2017 (UTC)


 * It should be "values from property=Review". Maybe that's the issue? I'm surprised that it works for you at all... Yaron Koren (talk) 03:06, 19 February 2017 (UTC)


 * Ops, true. I corrected to "values from property=Review" but the same behaviour happens. Jaider msg 12:16, 19 February 2017 (UTC)


 * Yes, indeed - I don't know how it worked with "values from property:", but that's another story. You can see the underlying problem here. I have no idea why this is happening, and I've never seen this kind of problem before. I'm guessing that it's some kind of database encoding issue. I don't remember if you have a coding background, but if so, you could try adding some debugging calls to getSMWPropertyValues in /includes/PF_ValuesUtils.php, to see if you can find out where the problem is coming from. Yaron Koren (talk) 13:37, 19 February 2017 (UTC)


 * Unfortunately, I don't have a coding background... But, I can confirm this exactly form worked fine about one year ago. However, for testing purpose, I just have downgraded to SF 2.6 (in a MW 1.28.0 instance) and the problem still happens. So, maybe MW or SMW have something to do with that. Jaider msg 15:21, 19 February 2017 (UTC)


 * Ah. I wouldn't be surprised if this is an issue in SMW, one that got added in a somewhat recent version. Yaron Koren (talk) 16:54, 19 February 2017 (UTC)


 * I'm not of much help here, but I was wondering about that myself when seeing the same kind of hashed string in another situation sometime last year (perhaps it's the number of characters per string, or the number of separate strings that the autocomplete feature tries to load or a coding issue to do with specific characters). Cavila 13:47, 19 February 2017 (UTC)


 * Did it also happen with "values from property"? Yaron Koren (talk) 14:40, 19 February 2017 (UTC)
 * It did yeah. Cavila 21:57, 19 February 2017 (UTC)

input list links
I am trying to use a listbox to let a user chose several pages in a category. Since these are pages, it would be nice to show them as links. However, instead of page1, page2 it saves page1, page2 which of course just shows as a redlink. Is there a way to get it to show the choices as links? Thanks! Tenbergen (talk) 06:22, 20 February 2017 (UTC)


 * Yes - call #arraymap in the template; see here. Yaron Koren (talk) 14:11, 20 February 2017 (UTC)
 * That did it. Had seen the arraymap info on that help page before but could not make any sense of it then. Thanks again!Tenbergen (talk) 23:32, 20 February 2017 (UTC)

Associating a From Based on namespace does not work
I followed the instructions and created a page with the Name of the target namespace in the namespace number 4, which is the "Project" namespace in english default installs. But it didn't work. We are using a german install and have our own name for namespace number 4 (MW 1.27.1, 4.1 (0cce6dc), 1.3 (7f66a6f), but not using Page Schema). Any hints how to make this work?


 * What exactly did you do? Yaron Koren (talk) 14:02, 21 February 2017 (UTC)


 * I followed the instructions on the main page Extension:Page_Forms/The_"edit_with_form"_tab: I installed Page Forms and Cargo, set up the namespace X: in LocalSettings.php, created a Form 'X' and created a Page 'X' in the 'Project' namespace, which is identified by namespace id 4. On this page I added


 * That does sound like it should work... so for pages with a name like "X:pagename", no "Edit with form" tab shows up? And have you gotten "Edit with form" to show up in any other way? Yaron Koren (talk) 14:17, 21 February 2017 (UTC)


 * I found out: It now works on our real install where we acces the Pages with /wiki/PAGENAME but it does not work on the test install, where we access the Pages with /mediawiki/index.php?title=PAGENAME. There we did not set $wgArticlePath in LocalSettings.php. Maybe this gives a hint what went wrong.


 * I can't think of why that would cause the problem... is there any other difference between the two wikis? Yaron Koren (talk) 14:36, 22 February 2017 (UTC)

Adding Categories
Is it possible to create a form that allows users to add categories from dropdown menus? What I would like to do is have a form that displays all of the categories and subcategories on the wiki as lists, and allows the user to pick multiple selections. Whatever is selected should end up at the bottom of the newly created page as a category.


 * Yes, use the "tree" input - see here. Yaron Koren (talk) 13:27, 26 February 2017 (UTC)


 * I have tried to use it, but cannot seem to figure out how to make it work. Could you give me an example of code that uses tree with the array function?


 * Is the problem in the form, or the template, or both, do you know? Yaron Koren (talk) 21:38, 26 February 2017 (UTC)

Cargo Tables with holds template / embed in fields
Hi, folks. I've been struggling to make a template that holds Cargo data from other templates. I found the example below, but can't figure out how to integrate Cargo fields into a template like this.

Can anyone edit/update the code below to store data in three existing Cargo tables - for example these?

In my scenario the MAIN template by itself creates a new page the the pagename set to the person's preferred name, so the page named "Sparky" would have the first, middle, and last names of Bob Howard Lee. I want to include the page name in the overall form as well.

Code copied from https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_December_2011#Template_in_a_template



{| class="formtable"
 * First name:
 * Middle name:
 * Last name:
 * Last name:
 * Last name:

Thanks! --Brilligtove (talk) 20:23, 28 February 2017 (UTC)


 * Sorry, I don't understand. #cargo_store (and #cargo_declare) go into the template, while what you have below that is the form definition. Do you understand how forms and templates work together? Or maybe I just misunderstood your question. Yaron Koren (talk) 22:15, 28 February 2017 (UTC)


 * I'm new with both Page Forms and Cargo, so my understanding is not great. In the Form, will the fields all write data to the relevant Cargo Tables automatically? I'm just beginning to grok the way these fit together. (Sorry to be a pestering noob!) --Brilligtove (talk) 23:28, 28 February 2017 (UTC)


 * Okay, that explains it. The form just saves template calls to a page - it doesn't directly store Cargo data. It's the template that stores the data. Yaron Koren (talk) 00:58, 1 March 2017 (UTC)

input type "openlayers" not working
Heiya,


 * Setup
 * MediaWiki 	1.27.1 (2f9cdcc) 17. Feb. 2017, 17:23
 * PHP 	5.6.29-0+deb8u1 (apache2handler)
 * Page Forms	4.1 (f97847f)

The map does not display in the form for  and console emits the following ReferenceError:
 * Issue

ReferenceError: OpenLayers is not defined load.php:119:1430 setupMapFormInput https://www.example.org/w/load.php:119:1430 https://www.example.org/w/load.php:122:547 .each https://www.example.org/w/load.php:5:226 jQuery.prototype.each https://www.example.org/w/load.php:2:215 https://www.example.org/w/load.php:122:502 jQuery.Callbacks/fire https://www.example.org/w/load.php:45:104 jQuery.Callbacks/self.fireWith https://www.example.org/w/load.php:46:431 .ready https://www.example.org/w/load.php:49:400 completed https://www.example.org/w/load.php:49:925

A fix will be great. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 15:47, 2 March 2017 (UTC)


 * Could you add "debug=true" to the URL to see if you can get a more meaningful error message? Also, in the "Network" tab (if your browser has such a thing), do you see it trying to contact openlayers.org? Yaron Koren (talk) 17:45, 2 March 2017 (UTC)
 * here we are:
 * There is no attempt to cantact openlayers.org, at least I did not see any. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 18:19, 2 March 2017 (UTC)


 * Alright, that's very helpful - the problem is that it's looking for /extensions/libs/PF_maps.js, not /extensions/PageForms/libs/PF_maps.js. Though I don't know why. Are you loading Page Forms via wfLoadExtension? Yaron Koren (talk) 18:57, 2 March 2017 (UTC)


 * Indeed, but changing to classic invocation does not mitigate the issue. Still searching in the wrong spot: --&#91;&#91;kgh&#93;&#93; (talk) 08:32, 3 March 2017 (UTC)


 * I have recreated the issue on smw.sandbox Cheers --&#91;&#91;kgh&#93;&#93; (talk) 12:08, 9 March 2017 (UTC)


 * Okay, thanks. My new guess is that this happens when Page Forms is installed via Composer. Hopefully there's an easy fix. Yaron Koren (talk) 18:11, 13 March 2017 (UTC)


 * I believe it must be something else since the wiki on which I originally detected the issue has a Git-setup without involving Composer. Keeping fingers crossed. --&#91;&#91;kgh&#93;&#93; (talk) 19:47, 13 March 2017 (UTC)

Line breaks with a textarea
Is there a way to retain line breaks in a textarea. I have a user that wants to enter a list of "topics" in a Topic Field in a form. When the data is rendered on a page the line breaks are removed and the text is mashed together. I tried using the bullet wikicode (*) but the first line doesn't render properly. Thanks!


 * You should use bullets, and you can get the first line to render properly by editing the relevant template and putting the parameter that holds this text on its own line. If that makes sense. Yaron Koren (talk) 22:43, 2 March 2017 (UTC)


 * Do you mean the template that gets created in the Create a Class special page? I'm not super smart about templates.  Where would the bullet go?


 * Thanks Yaron for the assist. --Konjurer (talk) 15:05, 3 March 2017 (UTC)


 * Oh, I didn't realize that this was a list field. Given that, why are there line breaks in the first place? Users are supposed to be separating the topics by commas. Yaron Koren (talk) 16:04, 3 March 2017 (UTC)

Problem with autocompletion while values are taken from a category
Hi. I'm trying to implement a form which takes autocompletion values from a category. And it works as long as I use as a source an old category (i.e. a category which has been existing for months or years). But when I use as a source newly created category it does not work. Below you can find details:
 * input type = text with autocomplete
 * values from category = some category
 * MW & extensions version can be found here
 * recently I have updated MW from 1.24 to 1.28 and updated SMW to the newest version
 * I ran all possible maintenance scripts to refresh / rebuild data but it did not help

Thanx in advance for any hints and help. Pawel Niemczuk (talk) 20:25, 3 March 2017 (UTC)


 * Given that this is a public wiki, can you point to the form with the non-working field? Yaron Koren (talk) 20:29, 3 March 2017 (UTC)


 * Yes, that's a public wiki. That's a test form, I'm using it to learn how to build forms so if you wish to change or edit anything - pls feel free to do so. You can edit as an IP. You can find the form here: enkol:Form:Testks. Oh, I've just noticed that when I change input type to "tokens" autocompletion works perfectly well ... Pawel Niemczuk (talk) 20:40, 3 March 2017 (UTC)
 * I've tested a few options and the observations are as follows:


 * The problem emerges when I choose "text with autocomplete" and "combobox" and the source of data is a new category
 * When I choose "tokens" everything works properly regardless or the chosen source of data
 * When I choose a property as a source of data everything works fine
 * Everything seems to work fine with a namespace as a source of data though I haven't tested that option extensively Pawel Niemczuk (talk) 12:11, 5 March 2017 (UTC)


 * Yes, you uncovered a bug that was added a few months ago, where "values from category" doesn't work with local autocompletion. Sorry about that. I just checked in a fix - you can either get the latest code from Git, or add this change in to your code directly. Yaron Koren (talk) 22:34, 5 March 2017 (UTC)


 * Thank you for your help and hints. I'll make use of them. And in the meantime I've chosen to use "values from property" and this solution seems to be even better for my needs than "values from category". Best regards! Pawel Niemczuk (talk) 22:27, 6 March 2017 (UTC)

4,000 commits!
Source: https://github.com/wikimedia/mediawiki-extensions-PageForms. In reality, it's probably more than that, but congratulations anyway! Cavila 08:57, 6 March 2017 (UTC)


 * Great! I'm guessing the majority of those are i18n commits, but still, that's a nice number. Yaron Koren (talk) 13:47, 6 March 2017 (UTC)

Simple upload problem with default filename
Simple upload is an awesome feature. I can't get however the 'default filename' to work with an iPad. The filename is always 'Image.jpg' and the existing picture with that name is shown and not the picture that has been shot with the iPad. We are using Page Forms 4.1.

The field definition looks like this: