Extension talk:Page Forms/Archive February to March 2017

Mandatory and input type=tree

From my testing looks like mandatory doesn't work in conjunction with input type=tree. Is there a way to force the user to select a value (or in case of list 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 {{{field|Context|input type=tree|structure={{ComponentContextValues}}|mandatory }}} : it allows me to save the page without selecting a value for Context. Should I report the bug (and where)? We use Semantic Forms 3.6-alpha (77c4a3b) 17 apr 2016 22:18 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 input type=tree in combination with mandatory. Actual code:

{| class="formtable"
! Editor: 
| {{{field|Editor|mandatory}}}
|-
! Context:  {{#info: {{Help:InfoContext}} }}
| {{{field|Context|input type=tree|structure={{ComponentContextWaarden}}|mandatory }}}
|}

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:

{{#rating:
  {{#ask:
   [[Category:Reviews]]
   [[Item::{{FULLPAGENAME}}]]
   | ?Rating
   | mainlabel=-
   | format=average
  }}
}}

just prints

{{#rating:3.2}}

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:

{{{field|review|input type=text with autocomplete|values from property:Review}}}

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)

I don't know if realated, but I'm getting this.source is not a function with any input type=text with autocomplete. I'll try to review further... --Toniher (talk) 15:08, 20 March 2017 (UTC)

Someone else reported that problem too, though I can't reproduce it myself. (I don't think it's related to the above, but who knows.) Is this on a public wiki? Yaron Koren (talk) 20:30, 20 March 2017 (UTC)

Okay, I was able to reproduce it, and I think I just checked in a fix for it. I still don't think it's related to the above, though. Yaron Koren (talk) 04:04, 21 March 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#Based on namespace: 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

{{#default_form:X}}

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)

My mentor on it recommended using arrays rather than tree inputs, since I would possibly be putting in multiple categories. Can't for the life of me figure out how the hell to do that though myself. KMjolnir (talk) 11:31, 31 March 2017 (UTC)

Trees can handle arrays (as you noted in you original question). Are you using #arraymap in the template? Do you know how it works? Yaron Koren (talk) 13:54, 31 March 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?

{{#cargo_store:_table=MAIN|...}}
{{#cargo_store:_table=ADDRESS|...}}
{{#cargo_store:_table=CONTACT|...}}

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

<includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Create person}}}

{{{field|Main|holds template}}}
{{{field|Add address|holds template}}}
{{{field|Contact info|holds template}}}

{{{end template}}}

{{{for template|Individual data|embed in field=Create person[Main]}}}
{| class="formtable"
| First name:
| {{{field|First name|input type=text|size=25}}}
| Middle name:
| {{{field|Middle name|input type=text|size=25}}}
| Last name:
| {{{field|Last name|input type=text|size=25}}}
{{{end template}}}

{{{for template|Add address|label=Address|embed in field=Create person[Add address]}}} 
{|
|'''Address Line1:''' {{{field|Address Line1}}
|- 
|'''Address Line2:''' {{{field|Address Line2}}
|-
|'''City:''' {{{field|City}}}
|'''State:''' {{{field|State}}}
|'''Zip:''' {{{field|Zip}}}
|}
{{{end template}}}

{{{for template|Contact info|multiple|embed in field=Create person[Contact info]}}}
{|
|'''Contact type:''' {{{field|Contact type}}
|'''Contact:''' {{{field|Contact}}
|}
{{{end template}}}
{{{standard input|summary}}}
{{{standard input|minor edit}}} {{{standard input|watch}}}
{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
</includeonly>

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)

Issue

The map does not display in the form for {{{field|LokalKoordinaten|input type=openlayers}}} and console emits the following ReferenceError:

ReferenceError: OpenLayers is not defined load.php:119:1430
	setupMapFormInput https://www.example.org/w/load.php:119:1430
	<anonym> 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
	<anonym> 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 --[[kgh]] (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:

[Thu Mar 02 18:13:09.074063 2017] [:error] [pid 4133] [client 91.45.247.234:60459] PHP Warning:  md5_file(/.../w/extensions/libs/PF_maps.js): failed to open stream: No such file or directory in /.../w/includes/OutputPage.php on line 3874, referer: https://www.example.org/w/index.php?title=My_Page&action=formedit&debug=true
[Thu Mar 02 18:13:09.074748 2017] [:error] [pid 4133] [client 91.45.247.234:60459] PHP Warning:  OutputPage::transformFilePath: Failed to hash /.../w/extensions/libs/PF_maps.js [Called from OutputPage::transformFilePath in /.../w/includes/OutputPage.php at line 3876] in /.../w/includes/debug/MWDebug.php on line 300, referer: https://www.example.org/w/index.php?title=My_Page&action=formedit&debug=true

There is no attempt to cantact openlayers.org, at least I did not see any. Cheers --[[kgh]] (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:

[Fri Mar 03 08:27:34.319337 2017] [:error] [pid 9433] [client 91.57.234.224:62285] PHP Warning:  md5_file(/.../w/extensions/libs/PF_maps.js): failed to open stream: No such file or directory in /.../w/includes/OutputPage.php on line 3874, referer: https://www.example.org/w/index.php?title=My_Page&action=formedit&debug=true
[Fri Mar 03 08:27:34.320484 2017] [:error] [pid 9433] [client 91.57.234.224:62285] PHP Warning:  OutputPage::transformFilePath: Failed to hash /.../w/extensions/libs/PF_maps.js [Called from OutputPage::transformFilePath in /.../w/includes/OutputPage.php at line 3876] in /.../w/includes/debug/MWDebug.php on line 300, referer: https://www.example.org/w/index.php?title=My_Page&action=formedit&debug=true

--[[kgh]] (talk) 08:32, 3 March 2017 (UTC)

I have recreated the issue on smw.sandbox Cheers --[[kgh]] (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. --[[kgh]] (talk) 19:47, 13 March 2017 (UTC)

Never mind, then! So much for my theories. Maybe I can fix it without knowing the actual cause. :) Yaron Koren (talk) 22:12, 13 March 2017 (UTC)

Well, currently these are under normal circumstances the usual suspects when it comes to such an issue. :) --[[kgh]] (talk) 22:54, 13 March 2017 (UTC)

Okay, I just checked in what may be a solution... I can't test it, but if possible please update your code and let me know if it worked for you. Yaron Koren (talk) 22:06, 15 March 2017 (UTC)

Regrettably it did not work out. --[[kgh]] (talk) 23:41, 15 March 2017 (UTC)

What error message do you see? Yaron Koren (talk) 01:44, 16 March 2017 (UTC)

The JavaScript error is the same. I believe to have "uncached the page however I will give it another shot. --[[kgh]] (talk) 10:25, 19 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?

{| class="wikitable"
! Date of Meeting
| [[Date of Meeting::{{{Date of Meeting|}}}]] 
|-
! Topics
| {{#arraymap:{{{Topics|}}}|,|x|[[Topics::x]]}}
|}

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: {{{field|Photo|input type=text|uploadable |default filename=<page name>.jpg }}}

PF_UploadForm.php introduces fatal error when $wgMaxUploadSize is an array

The document of $wgMaxUploadSize (https://www.mediawiki.org/wiki/Manual:$wgMaxUploadSize) suggests it can be set to an array, thus offering the ability to vary url max upload size from direct max upload size.

In the page form upload window, however, if wgMaxUplaodSize was an array, a fatal error would be thrown by

 wfMessage( 'upload-maxfilesize',
	$this->getLanguage()->formatSize( $wgMaxUploadSize )
)->parse() . ' ' . wfMessage( 'upload_source_url' )->escaped(),

since the message handler couldn't deal with the array parameter. This can be easily reproduced in Page Form master branch as of March 14th, 2017. Reasno (talk) 09:46, 14 March 2017 (UTC)

Sorry about that - I believe this problem is now fixed in the latest version of the code in Git. Yaron Koren (talk) 01:18, 20 March 2017 (UTC)

No type was specified for this property

I create a property using Special:CreateProperty, and set the type to Text. The property successfully is created, and the page consists of the text "This is a property of type Has type::Text." However, in Special:Properties, it shows up as type "Page", and shows the tooltip: "No type was specified for this property, assuming type Page for now." And if I attempt to use it in a template, it is, in fact a page type. How do I set the type?

• MediaWiki 1.28.0
• PHP 5.6.28 (fpm-fcgi)
• MySQL 5.6.34
• ICU 52.1
• Lua 5.1.5
• Page Forms 4.1 (22cc121) 15:25, 9 March 2017
• Semantic MediaWiki 2.4.6

Never heard this one for your set up, however there are issues with SMW 2.4.6 and MW 1.28 so upgrading to SMW 2.5.0 should help. Just tested successfully that is is working. --[[kgh]] (talk) 08:43, 15 March 2017 (UTC)

Thanks. Is there anything I need to do after updating to refresh the db? I did run rebuildData.php. Now when I create a property, it does not show up at all in Special:Properties ... Gstupp (talk) 20:08, 15 March 2017 (UTC)

No it does not immediately show due to caching. You can see it at special page "Special:PrefixIndex" and immediately use it. What happened when you added a annotation to that property? Should look like this and when browsing like that. --[[kgh]] (talk) 21:42, 15 March 2017 (UTC)

Well, I just gave up and nuked the entire thing and restarted.. and now its working =D (using SMW 2.5.0) Thanks again Gstupp (talk) 23:03, 15 March 2017 (UTC)

I think I figured out the problem. Its something wrong with the LinkedWiki extension. When I install it, all of the links on the Special:Properties page break, and no new properties show up. Uninstall it, and I can create new props again.

There is always a reason. Thanks for reporting back. --[[kgh]] (talk) 10:24, 19 March 2017 (UTC)

"formredlink" parser function

I have two questions about the "formredlink" parser function:

1. I construct a link like [[Hello - {{{World}}}|{{{World|}}}]] and is does not seem to be possible to define an alternative label for a link using "formredlink" so I additionally added <div style="display: none">{{#formredlink:target=Hello_-_{{{World}}} |form=HelloWorld |create page }}</div> to the template. Is there a better way?

2. I have not really figured out how to use "formredlink" to create a category page from a constuct like [[Category:Hello - {{{World}}}|{{{World|}}}]]so I additionally added <div style="display: none">{{#formredlink:target=:Category:Hello_-_{{{World}}} |form=CategoryHelloWorld |create page }}</div> to the template. Is there a better way for this, too?

In both cases the pages get created however I feel like doing the wrong thing for the right reason. Perhaps I am thinking to complicated to find the sane solution. Cheers --[[kgh]] (talk) 08:52, 15 March 2017 (UTC)

I think you can use "link text=", or a combination of "link text=" and "existing page link text=", for both - unless I'm misunderstanding the questions. Yaron Koren (talk) 14:39, 15 March 2017 (UTC)

Yes, for question 1 link text works, so {{#formredlink:target=Hello_-_{{{World}}} |form=HelloWorld |link text={{{World}}} |create page }} works perfect. Probably too easy to understand. :) When it comes to question 2 is was unable to automatically create a page in namespace "Category" and add the page to it. "link text=" and "existing page link text=" both seem to somehow create a link within the text rather than adding a category at the bottom of the page. So back to what I fiddled. If there is another solution I would love to learn it ... --[[kgh]] (talk)

Oh, I get it - you want it to be a category tag, not a link to the category; I thought it was the other way around. In that case, what you originally had for #2 actually seems reasonable; though you might be able to do with "link text=" with a blank value instead of the "display: none" approach. Not that it's much different. Yaron Koren (talk) 22:05, 15 March 2017 (UTC)

Thanks for the info. No, setting "link text=" with a blank value does not work. Guess we found the solution. Cheers --[[kgh]] (talk) 22:12, 15 March 2017 (UTC)

Mapping property for the tree format

Hi Yaron, would it be possible for you to extend the use of mapping properties to the tree format? That would be really great. Cavila 09:18, 15 March 2017 (UTC)

Interestingly, I just discovered that it's already possible in a somewhat expected way: if the tree structure contains the values of the mapping property (rather than the actual pages), pages are saved correctly, that is, with the page titles filled in. Cavila 14:49, 15 March 2017 (UTC)

Sorry, I don't understand - what exactly did you do? Yaron Koren (talk) 16:26, 15 March 2017 (UTC)

Sorry if anything was unclear. I used a mapping property in the form field and what I added to "structure" is a bulleted tree (generated by a query) whose individual items hold values of this mapping property. When a user selects something from this tree and goes on to save the page, it is not the selected value that gets added to the source text but the name of the page holding this value. This is a very useful feature and good news if you need to know how to use 'display titles' with the tree input. Cavila 21:44, 15 March 2017 (UTC)

Errors on remote autocomplete

I am trying to troubleshoot why PageForms autocomplete works for small sets of values and not for large ones. That lead me to using the call to the api to test autocompletion from Page Forms and this is where I found this error message:

{

   "error": {
       "code": "internal_api_error_DBQueryError",
       "info": "[66caa3a9331c1c82e9623ffa] Database query error",
       "*": "#0 /app/datamap/mw/includes/libs/rdbms/database/Database.php(912): Database->reportQueryError(string, integer, string, string, boolean)\n#1 /app/datamap/mw/includes/libs/rdbms/database/Database.php(1254): Database->query(string, string)\n#2 /app/datamap/mw/extensions/PageForms/includes/PF_AutocompleteAPI.php(244): Database->select(string, string, array, string, array)\n#3 /app/datamap/mw/extensions/PageForms/includes/PF_AutocompleteAPI.php(47): PFAutocompleteAPI::getAllValuesForProperty(string, string)\n#4 /app/datamap/mw/includes/api/ApiMain.php(1434): PFAutocompleteAPI->execute()\n#5 /app/datamap/mw/includes/api/ApiMain.php(509): ApiMain->executeAction()\n#6 /app/datamap/mw/includes/api/ApiMain.php(480): ApiMain->executeActionWithErrorHandling()\n#7 /app/datamap/mw/api.php(83): ApiMain->execute()\n#8 {main}"
   }

}

Is that something you have encountered before? I am not sure what else to test from here.

If that makes any difference, the wiki I am troubleshooting is set up with https. --Lalquier (talk) 20:37, 20 March 2017 (UTC)

Adding "$wgShowSQLErrors = true;" to LocalSettings.php may help to show the actual error... I hope. Yaron Koren (talk) 21:14, 20 March 2017 (UTC)

Thanks. The debug statement added this bit of missing info - 'Table 'smw_rels2' doesn't exist'. I did run Maintenance/update again to be sure. Running the initialize/upgrade admin command for SMW doesn't list anything about that table. Edit: According to this thread, that table should be deprecated. --Lalquier (talk) 18:00, 21 March 2017 (UTC)

Okay, that's very helpful. What do you have the global variable $smwgDefaultStore set to? If it's blank or null, try setting it to "SMWSQLStore3". Yaron Koren (talk) 02:25, 22 March 2017 (UTC)

My default store is set to "SMWSQLStore3". I am seeing the same error on another wiki set up directly to "SMWSQLStore3" but an older wiki that went through "SMWSQLStore2" and then "SMWSQLStore3" is working fine. It looks like not having that table as a legacy/obsolete table is an issue at this time. --Lalquier (talk) 13:29, 22 March 2017 (UTC)

Looking at the Page Forms code, I don't see how that's possible... the only lines that mention smw_rels2 are line 217 and 245 of /includes/PF_AutocompleteAPI.php, and neither of those should be getting called if you're using SMWSQLStore3. Could you add some debugging calls or something to see if either of those lines are getting called? Yaron Koren (talk) 13:46, 22 March 2017 (UTC)

Thanks for verifying. Once again, it was user error. Too many config files and too many config parameters. I was looking at the wrong file when I checked for SMWSQLStore3. Turns out that wiki is still at SPARQLSTORE (and throwing an error when I tried to upgrade to SMWSQLStore3.. maybe linked to using Fuseki). Anyway... this is no longer your problem. Thanks again - --Lalquier (talk) 15:26, 22 March 2017 (UTC)

Okay, great. Yaron Koren (talk) 16:52, 22 March 2017 (UTC)

Back to the drawing board. I wasn't paying enough attention to what I was doing. Bottom line - If I switch to SMWSQLStore3, the API for autocomplete with Page Forms works. If I switch back to SMWSPARQLstore (which is what I need since I am using a triple store for many other things), then the API for autocomplete for Page Forms throws that error about that missing table. So the problem remains. That seems to be pointing to the SPARQLSTORE interface, doesn't it? If that is the case, it is still not your problem but I thought you would want to know that development. --Lalquier (talk) 04:44, 23 March 2017 (UTC)

Okay, I get it - this was indeed a bug in Page Forms, where it was still treating SMWSQLStore2 as the default SQL store for SMWSPARQLStore. I think I just fixed it, so if you get the latest code, hopefully it will work. Yaron Koren (talk) 14:40, 23 March 2017 (UTC)

Happy to confirm it is working now. Thanks for the quick fix! --Lalquier (talk) 15:08, 23 March 2017 (UTC)

No impact for 'link text' and 'existing page link text' in #formredlink

Hi again - I am trying to fill a list of red links with an arraymap. The target parameter works well and the link are indeed created but I haven't had any luck so far with the 'link text' and 'existing page link text' parameters so far. I followed this syntax from the help page {{#formredlink:form=|link text=|existing page link text=|...}} but the link still appear in their raw form, without being renamed by the value I put in the parameters. If that can help, here is what I have for arraymap:

{{#arraymap:{{{Data classes definitions|}}}|,|x|<li> {{#formredlink:form=Data class|link text=x|existing page link text=x|target={{SUBJECTPAGENAME}}/x}}}} 

Edit: Also, I just noticed the 'title' parameter is added only on links to existing pages, not on red links. --Lalquier (talk) 17:32, 28 March 2017 (UTC)

This is an interesting one. :) It took me a while to figure it out, but the issue here is that the use of the variable "x" messes things up, because "link text" and "existing page link text" both contain "x". So switching to "xx" or anything else would probably solve the problem. I should probably change the #arraymap examples, since #arraymap and #formredlink now get used together a lot. Yaron Koren (talk) 17:59, 28 March 2017 (UTC)

Good catch! I didn't think of the x interferening with it. I just tested it and the workaround is working as expected. Thanks again. --Lalquier (talk) 18:34, 28 March 2017 (UTC)

Combining multiple instance and partial forms causes duplication

I'm finding that in Semantic Forms 3.7, if I use {{{info|partial form}}} in combination with {{{for template|ExampleTemplate|multiple}}}, then the form appends to the end of the existing instances of ExampleTemplate in the page, instead of replacing them, creating duplicate data. It didn't do this in 2.4. Is this a bug, or a design change? Do we know when this change might have been made? Unfortunately it's a feature we can't do without on the wiki I'm trying to upgrade, so if it's not fixable we'll have to go back to an earlier version. L Andy (talk) 12:21, 30 March 2017 (UTC)

That sounds like a bug. It probably happened in version 3.4.2, when the main form-handling code was modified significantly. Yaron Koren (talk) 14:14, 30 March 2017 (UTC)

Thanks for replying Yaron. After some hours tearing my hair out trying to get different Forms versions to work on MW1.27, I eventually realised it's not a bug, it was my wiki markup *facepalm*

FYI and in case anyone else hits the same issue, here's the fix.

My form was actually something along the lines of:

{{{info|partial form}}}
{{{for template|PreviousTemplate}}} {{{end template}}}
{{{for template|RepeatingTemplate|multiple}}}
...
{{{end template}}}

where "PreviousTemplate" was the template used on the page immediately before the multiple instances of "RepeatingTemplate". I think including that in the form may have been a workaround for some issue in Forms 2.x. Removing it from the form solved the duplication problem. Phew! L Andy (talk) 16:50, 30 March 2017 (UTC)

Damn, scratch that, I realised why I included PreviousTemplate in the form: it ensures that if you have no instances of RepeatingTemplate, and you use the form to add one, it gets inserted in the page after PreviousTemplate instead of at the top of the page. So I do need it. Does the fact that removing it fixes the duplication give any clue about how the problem might be fixed? L Andy (talk) 16:56, 30 March 2017 (UTC)

Oh well. What might help is to use what I like to call a "pseudo-partial" form - a regular form that holds all the same templates as the main form, but only has field tags for one template (the multiple-instance one, in this case); the other "for template" tags would not hold any fields. Does that make sense? If so, it may work in this situation. Yaron Koren (talk) 17:29, 30 March 2017 (UTC)

I did look at doing a pseudo partial form, but it didn't work for us because in reality, our page has several sets of different repeating templates, each with their own multiple-form. So we don't know in advance what all the other templates on the page are. L Andy (talk) 17:36, 30 March 2017 (UTC)

I have been wondering about having 2 forms: one to use when there are no instances of RepeatingTemplate (which would contain the reference to PreviousTemplate) and one to use when there are existing instances of RepeatingTemplate. But I can't quite see how to conditionally display the link to the correct form. L Andy (talk) 17:47, 30 March 2017 (UTC)

I still think you could do a pseudo-partial form, and just include all the templates. If the issue is getting rid of those "Add another" buttons, I think you can just put a <div display="none"> around each multiple-instance "for template"/"end template" combination. Yaron Koren (talk) 17:49, 30 March 2017 (UTC)

Ah, yes, I see. Thanks, I'll try it. L Andy (talk) 18:01, 30 March 2017 (UTC)

It works, more or less :) When I included all the other multiple templates in the form, I found I had to also include all the fields in each one, otherwise the values get deleted when you save. They don't seem to behave like non-multiple templates, where fields omitted from the form definition are preserved. That gives me a bit of a maintenance headache, because now if I add a field to one of those templates, I have to remember to add it to all the pseudo-partial forms. Also if I add a section to the page, again it has to be added to all the forms. So a true partial forms fix would be preferable, but I have a workaround for now. Thanks for your help Yaron. L Andy (talk) 14:09, 31 March 2017 (UTC)

Well, that's half good news... alright, good to know. Yaron Koren (talk) 15:06, 31 March 2017 (UTC)

DatePicker disappearing after running query

I have a datepicker field on a query form that I'm running using RunQuery. When the form is initially loaded, the datepicker button displays correctly. After running the query, the field no longer has the button, and also doesn't have the javascript magic that prevents entry of non-date characters. I've noticed the HTML input element no longer has the "hasDatepicker" CSS class after running the query.

I've seen there were a couple of threads on the semediawiki-user mailing list about this issue last year, in July/August and in December, but they were inconclusive. Was there ever a resolution for it? I'm using SF3.7, SFinputs 0.10.1, MW1.27.1. L Andy (talk) 17:35, 31 March 2017 (UTC)

I don't know, but upgrading to the latest Page Forms (which now defines "datepicker" itself, so no more need for Semantic Forms Inputs) may possibly solve the issue. Yaron Koren (talk) 17:48, 31 March 2017 (UTC)

It is indeed fixed in PageForms 4.1. Unfortunately most of my other forms seem to be incompatible with PageForms in pretty major ways, so it looks like I may be stuck with this one. L Andy (talk) 18:39, 31 March 2017 (UTC)

Looks like Semantic Forms Inputs is not required for the DatePicker even in SF3.7, it was removed from SFI in v0.10.0 according to the version history. I tried comparing the SF3.7 and PF4.1 versions of the ...DatePickerInput.php and ...datepicker.js files but nothing leapt out as an obvious fix, they're pretty similar. L Andy (talk) 19:00, 31 March 2017 (UTC)

Oh yeah, "datepicker" was actually added in version 3.5. Yaron Koren (talk) 19:10, 31 March 2017 (UTC)