Extension talk:Page Forms

From MediaWiki.org
Jump to: navigation, search
An archive box Archives 

Errors loading the extension in LocalSettings.php[edit]

I'm getting the following in error_log when I insert the line

wfLoadExtension( 'PageForms' );

in the LocalSettings.php file:

[03-Nov-2016 22:16:42 Europe/Zurich] PHP Fatal error:  Uncaught exception 'InvalidArgumentException' with message 'The value for 'load_composer_autoloader' sho
uld be an array' in (...)/w/includes/registration/ExtensionProcessor.php:348
Stack trace:
#0 (...)/w/includes/registration/ExtensionProcessor.php(173): ExtensionProcessor->storeToArray('load_composer_a...', true, Array)
#1 (...)/w/includes/registration/ExtensionRegistry.php(202): ExtensionProcessor->extractInfo('(...)/...', Array, 1)
#2 (...)/w/includes/registration/ExtensionRegistry.php(127): ExtensionRegistry->readFromQueue(Array)
#3 (...)/w/includes/Setup.php(39): ExtensionRegistry->loadFromQueue()
#4 (...)/w/includes/WebStart.php(137): require_once('(...)/...')
#5 (...)/w/index.php(38): require('(...)/...')
#6 {main}
  thrown in (...)/w/includes/registration/ExtensionProcessor.php on line 348

Meanwhile the browser will display a 500 error upon loading any wiki page. Commenting out the line removes the problem. Am I doing something wrong? Our is a MediaWiki 1.26 and in the error log above I manually replaced parts of the paths with (...). The PageForms package I downloaded is the one here. The link was found in this page.

Kind regards -- manu3d (talk) 22:27, 3 November 2016 (UTC)

Ah... more problems with extension.json... it looks like the handling of 'load_composer_autoloader' changed quite a bit from MW 1.26 to 1.27. What happens if you just remove that 'load_composer_autoloader' line from extension.json (it's near the top)? Yaron Koren (talk) 22:46, 3 November 2016 (UTC)
Good catch Yaron! Removing the line solves the problem: pages load correctly, PageForms is listed in Special:Version and the special pages it adds are available and seemingly working. I haven't created an actual form with it yet but everything seems to be in order except... the issue reported below this one. =) From my perspective this problem is solved though. Thank you! -- manu3d (talk) 13:44, 4 November 2016 (UTC)

Error loading the "Run query" special page[edit]

When I load the Run query page I get, in red, the following message:

Error: No form was found on page "".

Perhaps I'm wrong but it doesn't look like the intended behavior of this page. -- manu3d (talk) 13:44, 4 November 2016 (UTC)

It's not an ideal message, but it's fine that the page is displaying an error message, because users shouldn't be going directly to Special:RunQuery - it should always be Special:RunQuery/FormName. The current message is not very helpful, though. Yaron Koren (talk) 14:01, 4 November 2016 (UTC)
Understood. Thank you. -- manu3d (talk) 14:03, 4 November 2016 (UTC)

Details on Phabricator[edit]

The link to clone in the Details section shows http://phabricator.wikimedia.org/diffusion/EPFM/extension-pageforms.git twice. Usually the first line shows the gerrit link like it is also documented on the page about installing https://gerrit.wikimedia.org/r/p/mediawiki/extensions/PageForms. It will be nice to get this as it is happening for the other extensions in Phabricator. Cheers --[[kgh]] (talk) 15:32, 4 November 2016 (UTC)

Multiple 'for templates' in forms results in nested boxes[edit]


My form has multiple 'for template' tags with 'label=' parameters. What I was trying to achieve is that each template would have its own box around its fields and that these boxes would all be at the same level. However, what is happening is that the box for each subsequent template is nested in the box for the previous template. The current code of my form is:

This is the "Article" form.
To create a page with this form, enter the page name below;
if a page with that name already exists, you will be sent to a form to edit that page.

{{#forminput:form=Article|autocomplete on category=Articles}}

{{{info|page name=AR<unique number;start=0000001>|create title=Create article}}}
{{Form:Sub Page}}
{{{for template|Article|label=Page Actions}}}
{{{end template}}}
{{{standard input|free text|label=Article Content}}}
{{{standard input|save}}} {{{standard input|cancel}}}

Where the template {{Form:Sub Page}} contains:

<noinclude>Sub-form for entering Page properties
This sub-form contains code for processing the Page Properties template which captures the data required for use by Semantic Title.  This allows re-use by forms that create pages that make use of Semantic Title to display a tile based on the Title property capture by the form. It is invoked by including the following in the parent form:

 <nowiki>{{Form:Sub Page}}</nowiki>

Note: form elements in triple braces have to be bracketed by nowiki tags, except parameters passed to the form.
<nowiki>{{{for template|Page_properties|label=Page Properties}}}
{| class="formtable"
! Title: 
| <nowiki>{{{field|Title}}}
! Description: 
| <nowiki>{{{field|Description}}}
<nowiki>{{{end template}}}

I have tried several variations on this form. I tried without using the template {{Form:Sub Page}} and inserting its code directly into the main form. I also tried without the Article Template, which has no fields, but it always nests the boxes.

My apologies if I've overlooked something basic - I've also tried search in the discussion archive but haven't come across this issue. I do hope you can help?

Many thanks

Duncan, 4 November 2016

What version of this extension are you using? Yaron Koren (talk) 17:54, 4 November 2016 (UTC)
Hi Yaron - I'm on V4.0 of Page Forms, and V1.26.4 of Mediawiki. Many thanks, Duncan, 5/11/16.
Yes, this was an actual bug: the issue was that you're using "label=" with a template that's not multiple-instance, which I guess not many people do - even though there's nothing wrong with it. I just checked in what I think is a fix. Yaron Koren (talk) 18:12, 6 November 2016 (UTC)
Thanks Yaron, that did indeed fix it . Guess I'm a bit pernickety liking boxes round different sections of my form - looks nice though. Duncan 11 Nov 2016

Problem with #formredlink and auto create[edit]

Hi everyone,

I'm having a problem with #formredlink and the automatic creation of red links pages.

On my site, visitors can add companies via a form and add one or more sectors. I added the #formredlink to the Template:Company

{{#arraymap:{{{Sector|}}}|,|x|{{#set:inSector=x}}{{#formredlink:target=x|form=Sector|create page}}}}

and created Form:Sector and Template:Sector. Form:Sector does not have any actual input fields, only the free text (with preloaded text), and Template:Sector only adds a category.

Now, when I create a new company and add one or more non-existant sectors, the respective pages are created but are completely empty... I expected the preloaded text and the category to show up. However, when I manually create a new sector via the input box on Form:Sector, it works as intended.

Anyone got an idea why it doesn't work when using #formredlink and auto create?

Thanks in advance and kind regards,


Could you paste here, or pastebin, the contents of your "Form:Sector" page? Also, what version of this extension are you using? Yaron Koren (talk) 15:21, 7 November 2016 (UTC)
Hi Yaron, I'm using MediaWiki 1.27.1 and Page Forms 4.0 (b3d10f5) (and Semantic MediaWiki 2.4.1, but I guess that is not important here). Here's the paste (German version, Form:Sector = Formular:Branche, template is named Vorlage:Branche accordingly):
Um eine Seite mit diesem Formular zu erstellen, gib den Seitennamen in das Eingabefeld unten ein.
Sofern bereits eine Seite dieses Namens vorhanden ist, wirst du automatisch zum Bearbeitungsformular der Seite weitergeleitet.
{{#forminput:form=Branche|autocomplete on category=Branche}}

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

{{{standard input|free text|rows=10|preload=Vorlage:BrancheGliederung}}}

{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
Yes, this is a real problem. This turned out to be two bugs in one... I just checked in a fix for one of the bugs, so now if you try it with the latest code you should get the "Branche" template to show up, but the preloaded free text still won't show up. That bug seems to have been around for longer, and it may take longer to fix. Yaron Koren (talk) 18:40, 7 November 2016 (UTC)
Thanks, works as you described. The page is created, including the category from the template but without the preload text. Best regards, Gero
Okay, I think I just fixed the free text preload part too. It looks like this never actually worked with #formredlink page creation. Yaron Koren (talk) 14:25, 8 November 2016 (UTC)

Adapting upload form[edit]

Heiya, when clicking on a field for uploading files (uploable) one gets a pop-up window allowing to actually upload the file, add source and license information etc. Is there any chance to somehow adapt the look and feel of this window. So far it looks like a plain html form with no possibility to adapt. I tried to add to MediaWiki:Common.css e.g.

form#mw-upload-form.visualClear {
    font-family: sans-serif;

Nothing, even after clearing the browser cache. :( --[[kgh]] (talk) 22:23, 7 November 2016 (UTC)

Yes - in order to not have the skin (including the sidebar, etc.) appear in the upload window, it's just raw HTML that's displayed - meaning no CSS files get loaded. It might be possible to have the code just load MediaWiki:Common.css, though - that seems like it could open up a lot of possibilities. Yaron Koren (talk) 02:23, 8 November 2016 (UTC)
Ah, this explains it. Fair enough with regard to the reason for the current behaviour. Indeed it would be great to be able to manipulate the look and feel of this part of the interface, too. Having "MediaWiki:Common.css" at hand together with some more fine-grained classes would be utterly awesome. Cheers --[[kgh]] (talk) 08:34, 8 November 2016 (UTC)

Wraning message ext.pageforms.datepicker[edit]

Hello all,

I have the following warning message when I create a form with a field using input type=datepicker Warning: OutputPage::getModuleStyles: style module should define its position explicitly: ext.pageforms.datepicker ResourceLoaderFileModule [Called from OutputPage::getModuleStyles in C:\xamppfarm\apps\mediawiki\htdocs\includes\OutputPage.php at line 623] in C:\xamppfarm\apps\mediawiki\htdocs\includes\debug\MWDebug.php on line 300

I'm using Page Forms 4.0.2-alpha, MediaWiki 1.26.2

Any ideas how to solve that?

You must be loading Page Forms with wfLoadExtension(). I put in a fix a while back for this when the extension is called via "require_once", but not for the other approach. Sorry about that! I think I just fixed it. Yaron Koren (talk) 01:55, 14 November 2016 (UTC)

request for enhancement[edit]

Hi Yaron

I'm really enjoying using Page Forms. I did wonder if it would be possible to port the datetimepicker from Semantic Forms Inputs as using the datetime input is a little more complex for my users?

Many thanks

Duncan, 11 Nov 2016

I hope to do that at some point soon - it was a mistake not to include "datetimepicker" in the initial batch of inputs that were transferred from SFI to SF/PF. Yaron Koren (talk) 01:55, 14 November 2016 (UTC)

How to use the mapping template parameter[edit]

From reading the docu I get no idea on how to use this parameter. I have a field {{{field|Licence|input type=dropdown|mandatory|mapping template=Licences}}} and the template "Licences" holds just {{{1|}}} as instructed. So how is the mapping done, i.e. how do I e.g. store "C" and display "Copyrighted" for selection? Cheers --[[kgh]] (talk) 23:11, 13 November 2016 (UTC)

Maybe the documentation should be clearer, because the template definitely shouldn't look like just "{{{1|}}}". It should instead look like "{{#switch:{{{1|}}}|C|Copyrighted|...}}" or something. Yaron Koren (talk) 01:58, 14 November 2016 (UTC)
Probably. Now I know that I am presumably not as clumsy as I thought I am. Trying to do the mapping in the template using the "switch" parser function was one of the things I tested. However without success. Still thanks for confirming that the mapping is done within the assigned template. I have created a setup at smwsandbox which is also not working: form, template, mappingtemplate and property. Perhaps I still do something wrong or there is something in the water. Cheers --[[kgh]] (talk) 14:59, 14 November 2016 (UTC)
You're missing a curly bracket in the mapping template... I don't know if that's the only issue. Yaron Koren (talk) 16:19, 14 November 2016 (UTC)
Oops, indeed. Still it is not working so I will now back off from trying to use it. Continues to be a nice idea behind the feature. Probably once there is a live working example somewhere I will give it a shot again. Cheers --[[kgh]] (talk) 16:33, 14 November 2016 (UTC)

using formredlink and semantic properties[edit]

Hi, I need to store some values in a semantic property, and at the same time, if a redlink is shown the users may select from two forms to create a new page. What I did:

[[NombreParticipante::{{#formredlink:target={{{Nombre|}}}|alt_form[0]=Persona|alt_form[1]=Grupo}} ]]

"NombreParticipante" is the semantic property that stores a participant's name. "Nombre" is the field, and "Persona" and "Grupo" are the two forms. This seems to work fine, but an error tooltip is displayed saying "(value) can't be used as a page name in this wiki"

How can I solve this? Thanks!

The #formredlink call and the property setting should be separate. One way you could do it is:
{{#formredlink:target={{{Nombre|}}}|alt_form[0]=Persona|alt_form[1]=Grupo}} {{#set:NombreParticipante={{{Nombre|}}}}}
Yaron Koren (talk) 02:00, 14 November 2016 (UTC)

Query results or #arraymap concatenated by a final “and” ?[edit]

Hi, is there a smart way to print out a final “and” or “or” before the last value, when using #ask queries or #arraymap ? It would be nice to have a switch parameter or so. I know other possibilities:

  • using #pos: & #sub constructs
  • using #explode constructs
  • using extension:Arrays

… but if there would be a “last sep”-parameter or so, please let me know. Thanks, --Andreas P. Icon External Link E-Mail.png 14:39, 14 November 2016 (UTC)

Since SMW 2.3.0 there is actually an alternative provided by the "set" parser function ("template" parameter) which provides detection of last elements. See the docu on this. I currently cannot recall if something like this is possible with "arraymap". Cheers --[[kgh]] (talk) 15:05, 14 November 2016 (UTC)
Only the #arraymap question is relevant here - there's no way to do it right now, but maybe there should be. Shouldn't it always be "and", though? Maybe there's no need to make the user specify the actual string. Yaron Koren (talk) 16:21, 14 November 2016 (UTC)
I am sorry for having interfered here. Please disregard my answer. --[[kgh]] (talk) 16:35, 14 November 2016 (UTC)
No problem - he did ask about both. Yaron Koren (talk) 02:10, 15 November 2016 (UTC)

A simple work around could be:

  • to loop through only once via #arraymap
  • to use CSS for the display of different list displays

The example uses extension: Variables:

{{#vardefine: authorList
|Kazumu Kuramitsu, Atsuya Kosaki, Teruhito Ishihara, Hideo Yamada, Kyohei Watanabe
--><div class="list-comma-sep list-show-last-and"><!--
-->{{#arraymap: {{#var: authorList}}<!--
-->|<span class="separators"><!--
  --><span class="sep-semicolon">;&nbsp;</span><!--
  --><span class="sep-comma">,&nbsp;</span><!--
  --><span class="sep-and">&nbsp;and&nbsp;</span><!--
--></span><!--output sep

With the following CSS one can switch between display of “and”, “;” or “,” or display a last “and”:

.list-comma-sep .sep-and { display:none; }
.list-comma-sep .sep-semicolon { display:none; }
.list-comma-sep.list-show-last-and .separators:last-child .sep-and {  display: inline; }
.list-comma-sep.list-show-last-and .separators:last-child .sep-comma {  display: none; }

The parsed list after applying #arraymap:

Kazumu Kuramitsu; ,  and Atsuya Kosaki; ,  and Teruhito Ishihara; ,  and Hideo Yamada; ,  and Kyohei Watanabe

… would, after applying the CSS, result in:

Kazumu Kuramitsu, Atsuya Kosaki, Teruhito Ishihara, Hideo Yamada and Kyohei Watanabe

I know it is just a kind of patch, but it works. --Andreas P. Icon External Link E-Mail.png 10:19, 28 November 2016 (UTC)

Wow! Pretty clever. Yaron Koren (talk) 15:34, 28 November 2016 (UTC)

Show on select not working as expected?[edit]

The code below is based on the example here but I can't get it to work. Field labeled Onderwerp in all div sections is shown, was hoping only the div section selected in the 'show on select' (for field Scope) would show, others would be hidden.

{{{for template|Test}}}
{| class="formtable"
! Scope: 
| {{{field|Scope(architectuurbesluit)|show on select:Enterprise=>enterprise-onderwerp;Domein=>domein-onderwerp;Programma=>programma-onderwerp;Project=>project-onderwerp}}}

<div id="enterprise-onderwerp">
! Onderwerp:
| {{{field|Onderwerp(Architectuurbesluit)|input type=dropdown|values={{EnterpriseArchitectuurOnderwerpen}}|mandatory}}}
<div id="domein-onderwerp">
! Onderwerp:
| {{{field|Onderwerp(Architectuurbesluit)|input type=dropdown|values={{DomeinArchitectuurOnderwerpen}}|mandatory}}}
<div id="programma-onderwerp">
! Onderwerp:
| {{{field|Onderwerp(Architectuurbesluit)|input type=dropdown|values={{ProgrammaArchitectuurOnderwerpen}}|mandatory}}}
<div id="project-onderwerp">
! Onderwerp:
| {{{field|Onderwerp(Architectuurbesluit)|input type=dropdown|values={{ProjectArchitectuurOnderwerpen}}|mandatory}}}

(I am on MW 1.26.2 and SMW 2.3 alpha) PeterBodifee (talk) 23:09, 15 November 2016 (UTC)

It should be "show on select=", not "show on select:" - maybe that's the issue? Yaron Koren (talk) 00:57, 16 November 2016 (UTC)
Awesome, that solves the issue of the field Onderwerp being displayed 4x on the form (Thanks Yoran!) however when saving the data with the form, I get the parameter mentioned 4x in the template call on the resulting page:

I studied the corresponding template of the example here, however it is based on Cargo and I use SMW. PeterBodifee (talk) 09:09, 16 November 2016 (UTC)

Great. Ah, I didn't notice that all the field names were the same. I see what you're trying to do, but unfortunately it can't be done - Page Forms can't correctly handle having the same field more than once in a form. One possible alternate approach is to use "values dependent on" instead - it's intended for this sort of thing, although it can't work with dropdowns (only "combobox" and "tokens") and it might not be exactly what you're looking for anyway. Another approach is to just have four different fields instead of one. You could have the same property across all four, if you want. Yaron Koren (talk) 15:37, 16 November 2016 (UTC)
Currently I have a tree with values for Onderwerp(architectuurbesluit). But this is error prone, as all values are visible and the subset of valid values is dependent on what is chosen for Scope(architectuurbesluit). The editors find it acceptable, but I don't want to see data entry errors. Where do i find more info about "values dependent on"? PeterBodifee (talk) 20:56, 16 November 2016 (UTC)
See here. Yaron Koren (talk) 21:30, 16 November 2016 (UTC)

Question on default filename parameter when uploading files[edit]


When using the parameter uploadable with the optional parameter default filename set to default filename=image for <page name>, a notice shows up complaining about a missing variable$page_name (FormField.php line 306). Plus, it does not replace the variable.

Not a big deal, just reporting it (I hope to be able to fix those someday :-). Frdpnl (talk) 11:46, 17 November 2016 (UTC)

I can't replicate this problem. What version are you using? Yaron Koren (talk) 02:00, 18 November 2016 (UTC)
Ah? I'm using MW 1.27, and SemanticForms 3.6.
Logged is: Undefined variable: page_name in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_FormField.php on line 306Frdpnl (talk) 08:44, 21 November 2016 (UTC)
You have a relatively old version of Semantic Forms - that might be the issue. I would recommend upgrading to the latest version of this extension, which is now called Page Forms. Yaron Koren (talk) 13:37, 21 November 2016 (UTC)
Ok. Thanks, I will upgrade then. Frdpnl (talk) 12:35, 23 November 2016 (UTC)

Problem with query string=namespace=xxx in #formlink:form[edit]

Hi there. I'd like to create a page in a specific namespace using the formlink one step approach but the pages created are in the main namespace. I'm using Page Forms 4.0.1. My code for this is:

{{#formlink:form=Code|query string=namespace=Admin|link text=Add a new Code|link type=post button|tooltip=Click on this link to add a new Code using a form.  To edit a Code go to its page and select Edit from the menu}}

Apologies if I've misunderstood but would you advise if I have?

Many thanks, Duncan, 19th Nov 2016

As far as I know, the "namespace" parameter only makes sense for #forminput, not for #formlink, since with the #formlink one-step process, the page title is generated entirely from the "page name" formula. You may be able to hack something by adding a call to #urlget (from the UrlGetParameters extension) to the page name formula, but I'm not sure. Yaron Koren (talk) 13:35, 21 November 2016 (UTC)

Links in Docu broken[edit]

e.g. http://arthropodgenomes.org/w/index.php?title=Africa_Gomez&action=formedit --Seppl2013 (talk) 14:11, 19 November 2016 (UTC)

I don't know what you mean by "links in docu", but that wiki has a lot of issues (I'm guessing caused by mismatched versions), and my guess is that fixing those issues will make the form problems go away also. Yaron Koren (talk) 23:09, 20 November 2016 (UTC)

Fatal error: Call to a member function exists() on a non-object in /home/ngrandy/public_html/w/extensions/PageForms/specials/PF_FormEdit.php on line 81[edit]

http://discoursedb.org/w/index.php?title=Special:FormEdit&target=Environment_America_Research_%2526_Policy_Center&alt_form%5B0%5D=Source&alt_form%5B1%5D=Magazine&alt_form%5B2%5D=Online%20magazine --Seppl2013 (talk) 15:38, 19 November 2016 (UTC)

That's an invalid "target" value, since it's doubly URL-encoded. It looks like it was caused by entering an invalid value, "Environment_America_Research_%26_Policy_Center", in a "Source" field - it should have been "Environment America Research & Policy Center". Yaron Koren (talk) 23:11, 20 November 2016 (UTC)

Problem with setting a Categorie[edit]

After i install a Site with a Form i cant put the Site too any Category every Time it will be deltree. With normal createt Sites there is no Problem, only with createt Site from Form. What can i do?

I'm not sure I understand - you add a "Category" tag in the form, and it gets deleted? In any case, the Page Forms philosophy is that users should not be adding category tags directly - that should be done by the template, and there should usually be only one category per page. Yaron Koren (talk) 15:27, 22 November 2016 (UTC)

Thx for the Help: It was a Problem with the Hoster so all is working now, without problems. And i give you a feedback for that extension. It is one of the most usefull extension i have in use. Many thx.

That's great! Yaron Koren (talk) 15:16, 23 November 2016 (UTC)

input type "listbox" - completely deselect[edit]

Heiya, this is probably a feature request. Once a person has selected a value via a field using the "listbox" input type there seems to be no way to completely deselect, i.e. a minimum of one selected value is always in the field and passed to the template when saving. This it will be nice to have an option to clear the field from all values. Cheers --[[kgh]] (talk) 17:25, 22 November 2016 (UTC)

You should be able to deselect any value by just pressing "Ctrl" and clicking on that value. Yaron Koren (talk) 18:10, 22 November 2016 (UTC)
Indeed, that's it though I would never have tried this. I guess it will be nice to note this since I believe that most people will not discover this option right away. --[[kgh]] (talk) 20:22, 22 November 2016 (UTC)
Oh, I thought it was more obvious than that. Did you know about using "Ctrl" to select items, like if you want to select the 1st and 3rd item or something? Yaron Koren (talk) 21:56, 22 November 2016 (UTC)
Yes, and this is how I did it. Since deselecting works also without pressing "Ctrl" I ended up with one selected item and did not think further. So this may come to one's mind by perhaps not intuitively. Admittedly I hardly use "listbox". Maybe a "senior moment" thingy too. A pretty bad one the longer I think about it. --[[kgh]] (talk) 22:08, 22 November 2016 (UTC)
Alright. To be fair, I don't think many other people are using "listbox" either! Yaron Koren (talk) 15:18, 23 November 2016 (UTC)

Googlemaps input type not using tabindex[edit]

It seems that in v4.0.2 (7b95a65) the googlemaps input type isn't making use of $wgPageFormsTabIndex so when you tab down the form the two googlemaps input boxes are skipped. This is a pain as it means it also skips all the way down past the map too. If I knew how to use git I would, but here are the changes necessary in PF_GoogleMapsInput.php:

  1. At the start of public static function getHTML, add: global $wgPageFormsTabIndex;
  2. In the same file, change this line: $coordsInput = Html::element( 'input', array( 'type' => 'text', 'tabindex' => $wgPageFormsTabIndex, 'class' => 'pfCoordsInput', 'name' => $input_name, 'value' => $parsedCurValue, 'size' => 40 ) );
  3. And this line: $addressLookupInput = Html::element( 'input', array( 'type' => 'text', 'tabindex' => $wgPageFormsTabIndex, 'class' => 'pfAddressInput', 'size' => 40, 'placeholder' => wfMessage( 'pf-maps-enteraddress' )->parse() ), null );

This means that both input boxes have the same tabindex, but as far as I can tell they are prioritised in order of appearance. Thanks for a great extension. Jonathan3 (talk) 22:09, 22 November 2016 (UTC)

Thanks for pointing that out! And for these hints. I just added a tab index to the "googlemaps" input type, as well as to "openlayers", which was missing it too. Yaron Koren (talk) 16:19, 23 November 2016 (UTC)

4.0.2 problems with messages[edit]


When upgrading (from SemanticForms 3.6) to PageForms 4.0.2 (on a MW 1.27), some messages are not showing properly. I see strings such as: <pf_category_hasdefaultform> (for the default_form PF in a category), <formedit>, instead of their normal values.

LocalSettings include: $wgLanguageCode = "en";, and $wgCacheDirectory is set.

What could I be doing wrong? Thanks! (Frdpnl (talk))

I don't know... but it does sound like it might be a caching issue, either with the i18n cache or the overall MediaWiki cache. Yaron Koren (talk) 17:11, 24 November 2016 (UTC)
Ok, thanks for the suggestion. Frdpnl (talk) 14:05, 30 November 2016 (UTC)

Error opening Special:SpecialPages[edit]


I have installed SemanticForms (PageForms-REL1_26-c514c90.tar.gz) on a MW 1.26.2 (languageCode=es) and when I try to enter to Special:SpecialPages, appears "Fatal error: Class 'SFCreateProperty' not found in /var/www/vhosts/urbipedia.org/httpdocs/includes/specialpage/SpecialPageFactory.php on line 382"

What can I do?

Thanks --Gafotas (talk) 10:16, 26 November 2016 (UTC)

My guess is that upgrading to the latest Page Forms code will fix the problem. In general, you shouldn't use the "Extension Distributor" downloads, because they just represent a random snapshot of the code. I really should remove that "Extension Distributor" download link from the main page, because it seems to only cause problems. Yaron Koren (talk) 15:32, 28 November 2016 (UTC)

Best way to avoid spam (ConfirmEdit)[edit]

ConfirmEdit with ReCaptcha NoCaptcha works to an extent with Page Forms, but not entirely well. When there is a ReCaptcha required, it does not appear on the Form edit page, but on a subsequent source edit page which has a "Incorrect or missing CAPTCHA" error messsage at the top and a ReCaptcha at the bottom. Is there any way to get ConfirmEdit (or something similar) to show the Captcha on the form edit page? Or what alternative do you recommend? Thanks. Jonathan3 (talk) 01:43, 29 November 2016 (UTC)

Uploadable form not working[edit]

I set on the form like this ! Upload file: | {{{field|Upload file|uploadable}}}

when i click link upload file, i got error like this

Fatal error: Call to undefined method OutputPage::getHeadScripts() in /var/www/xxxx/extensions/PageForms/specials/PF_UploadForm.php on line 327

anyone know why? Thanks

This is an error with MW 1.28, that was fixed a few week ago. If you can get the latest version of Page Forms, that will fix the problem; if not, you can just apply this change directly. Yaron Koren (talk) 17:31, 29 November 2016 (UTC)

Automatik give a Kategorie to Form created Site?[edit]

Automatik give a Kategorie to Form created Site is there a Way to do this?

Yes - just put a "Category" tag in the template that the form edits. Yaron Koren (talk) 16:19, 30 November 2016 (UTC)

Textarea in responsive skin (when editing using a form)[edit]

CSS for an "autogrow" textarea is set as width=auto (and cols=90 by default) but this was too wide for my form using the Foreground skin. It had the knock-on effect of making the googlemaps input equally (too) wide. Changing PF_TextAreaInput.php line 211 to set the CSS as width=100% fixed it on my iPhone. I don't mind that it changed the columns from 90. I can see that someone who manually sets cols= may not want CSS to override that, but it would be good if there were a way not to have to set cols= for autogrow fields at all. In the meantime I added .createboxInput {width: 100% !important} to MediaWiki:Common.css. Jonathan3 (talk) 21:50, 1 December 2016 (UTC)

Does the autogrow still work if the width of the textarea is a percentage of the browser width? If I remember correctly, the autogrow JS didn't know exactly when to lengthen the textarea unless the width was defined in advance. Have you tried the autogrow part? Yaron Koren (talk) 05:06, 2 December 2016 (UTC)
Yes it works fine (checked on iPhone, and Chrome on the PC). I think the problem (as mentioned in your comments) is that allowing width=100% overrides the column number setting - but it doesn't prevent autogrow from working. Jonathan3 (talk) 21:15, 2 December 2016 (UTC)

[Solved] How to add a new row in Spreadsheet-style editing[edit]

Using last version (4.0.2) of PF I don't find a way to add new rows, when adding the "|display=spreadsheet", the button "Add another" disapears.

Thanks, cheers

Nicolas NALLET Wiki-Valley.com, Semantiki.fr (talk) 09:22, 2 December 2016 (UTC)

You need to hit the "+" icon at the top right-hand corner - sorry that it's not more obvious. Yaron Koren (talk) 12:58, 2 December 2016 (UTC)
Thank you, it works, but the "+" icon is totally invisible on my screen, I don't know why :( Nicolas NALLET Wiki-Valley.com, Semantiki.fr (talk) 16:14, 2 December 2016 (UTC)
That is strange... is this visible publicly? Does it happen with more than one browser? Are you using a skin other than Vector? Yaron Koren (talk) 21:53, 2 December 2016 (UTC)
It was only a server config issue, server returns 403 for this image (it is on a private wiki, security policy was too restrictive). Thanks!
By the way, I didn’t know this spreadsheet-style feature, it’s great! ~ Seb35 [^_^] 09:42, 3 December 2016 (UTC)

Dragging marker in Google Maps does not change the coordinates[edit]

I mentioned this problem in passing in Extension talk:Cargo#Display map from address rather than coordinates? - 'On the "googlemaps" input type, if I click a new location it updates the coordinates, but if I move an existing red pointer it doesn't update the coordinates.' I think I've now come up with the solution, at least one that works for me. I'll cut and paste below:

	function googleMapsSetMarker(location) {
		if (marker == undefined){
			marker = new google.maps.Marker({
				position: location,
				map: map,
				draggable: true
			google.maps.event.addListener(marker, 'dragend', function(event) {

The new bit is the final three lines, adding a listener for "dragend". I'd love to be able to use gerrit, but it seems a huge learning curve! Jonathan3 (talk) 00:32, 3 December 2016 (UTC)