Extension talk:Page Forms/Archive November to December 2016

Errors loading the extension in LocalSettings.php

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

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

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/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

Hi

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:

<noinclude>
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}}

</noinclude><includeonly>
{{{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}}}
</includeonly>

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.
</noinclude><includeonly>
<nowiki>{{{for template|Page_properties|label=Page Properties}}}
</nowiki>
{| class="formtable"
! Title: 
| <nowiki>{{{field|Title}}}
</nowiki>
|-
! Description: 
| <nowiki>{{{field|Description}}}
</nowiki>
|}
<nowiki>{{{end template}}}
</nowiki></includeonly>

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

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,

Gero

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}}

</noinclude><includeonly>
<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}}}

'''Freitext:'''
{{{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}}}
</includeonly>

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

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

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

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

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

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” ?

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. 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}}<!--
-->|,|§|[[Dc:creator::§]]<!--output
-->|<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
-->}}<!--
--></div>

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. 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?

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

(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:

{{Test
|Scope(architectuurbesluit)=Programma
|Onderwerp(Architectuurbesluit)=Context
|Onderwerp(Architectuurbesluit)=Context
|Onderwerp(Architectuurbesluit)=Context
|Onderwerp(Architectuurbesluit)=Context

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

Hi,

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

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

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

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

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

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 [solved]

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

Hi,

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

Hi,

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)?

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)

I've not thought this through fully, but would it be possible to have a "Captcha" input type which somehow communicates with ConfirmEdit... so if the Captcha is solved correctly on the form page then that is sufficient? Jonathan3 (talk) 22:29, 9 December 2016 (UTC)

Uploadable form not working

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?

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)

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

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 [solved]

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) {
				googleMapsSetMarker(event.latLng);
			});

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)

Thanks for this patch! It definitely improves things. I just checked it in. For good measure, I also added support for double-clicking (which leads to a re-center and zoom), which was missing before. Yaron Koren (talk) 00:54, 5 December 2016 (UTC)

Use textinput "Address" field as input for googlemaps "look up coordinates" button

In Extension_talk:Cargo#Display map from address rather than coordinates? I wondered whether it would be possible for the address box in the googlemaps input type to save the address. I have done it the other way round on my site, by getting the googlemaps input type "look up coordinates" button to use the contents of an "Address" text input type, instead of the googlemaps input type's own address box.

PF_TextWithAutocompleteInput.php:

		#New bit
		if (preg_match("#\[Address\]#", $input_name)) {
			$inputAttrs['class'] .= " pfAddressInput";
		}
		#End of new bit
		$text = "\n\t" . Html::input( $input_name, $cur_value, 'text', $inputAttrs ) . "\n";

PF_maps.js:

		/*var addressText = inputDiv.find('.pfAddressInput').val(); */
		var addressText = document.getElementsByClassName('pfAddressInput')[0].value;

Rearranged PF_GoogleMapsInput.php:

		$fullInputHTML = <<<END
<div style="padding-bottom: 10px;">
$addressLookupButton
</div>
<div style="padding-bottom: 10px;">
$coordsInput
</div>
$mapCanvas
<!--$addressLookupInput-->
<!--$mapUpdateButton-->
END;

The changes to PF_TextWithAutocompleteInput.php and PF_maps.js work on my site because I have an autocomplete-text input type called "Address" just before the googlemaps input type. The changes to PF_GoogleMapsInput.php suit my site because I don't need the "address lookup input" input any more, and don't need the "map update" button because my users won't ever input coordinates by hand (I guess that is a separate issue).

Although these changes wouldn't suit everyone, I think they might be a good option for some people - would there be any way of making more generic changes to the extension, and adding options along similar lines? Jonathan3 (talk) 01:05, 6 December 2016 (UTC)

I remember looking into trying to come up with a solution for this and not succeeding; but if you can figure one out, that would be great. Of course, the address field name cannot be hardcoded; but maybe there's a way to pass the field name in as a parameter or something. (I think part of the problem, maybe a big part of the problem, is that the address is not necessarily in one field: there could be separate inputs for street address, city, country, etc. Though I suppose a limited solution is better than no solution at all.) Yaron Koren (talk) 05:07, 6 December 2016 (UTC)

It's getting late so I can't perfect this, but...

The idea is that you can edit any form, and for any field you can add |class=pfForMaps. (It would be possible create a new parameter for $other_args but this would have taken me much longer.) I've tested it with text and textarea fields.

If the Maps javascript finds any elements with the pfForMaps class, it now concatenates them and uses this address for geocoding - otherwise it did what it did before and takes the address from the text box ($addressLookupInput) provided by the googlemaps input type. This means that the form creator can decide how the addresses are saved in Cargo (in the usual way), and which fields the googlemaps input type uses for sending to Google for geocoding.

In order to avoid duplication I added a new global configuration variable, $wgPageFormsDisableAddressLookupInput, which defaults to null but can be set to true if the form creator wants the googlemaps address input box not to show up.

Separately, as my users will not be entering coordinates, and would find the "set marker" button confusing, there's another configuration variable, $wgPageFormsDisableMapUpdateButton, which works similarly.

It would be good also to add the option of sending (PAGENAME + ADDRESS) for geocoding, to improve geocoding accuracy when the wiki page name is the place name. I guess this would be easy but I haven't time today!

PF_maps.js:

	function doLookup() { 
		/*delete: var addressText = inputDiv.find('.pfAddressInput').val(); */
		if (document.getElementsByClassName('pfForMaps').length!=0) {
			var addressText = "";
			var allAddrs = document.getElementsByClassName('pfForMaps');
			for(var i=0; i<allAddrs.length; i++) {
				if (addressText!="") {
					addressText += ", ";
				}
				addressText += allAddrs[i].value;
			}
		} else {
			/*This line is what this if clause replaced*/
			var addressText = inputDiv.find('.pfAddressInput').val(); 
		}
		alert("Looking up coordinates for: " + addressText); //for testing

PF_GoogleMapsInput.php:

	public static function getHTML( $cur_value, $input_name, $is_mandatory, $is_disabled, $other_args ) {
		...............
		global $wgPageFormsDisableAddressLookupInput; #new line 
		global $wgPageFormsDisableMapUpdateButton; #new line 
		...............
		#Replace $fullInputHTML = <<END with the following
		$fullInputHTML = '<div style="padding-bottom: 10px;">';
		if (!($wgPageFormsDisableAddressLookupInput)) {
			$fullInputHTML .= $addressLookupInput;
		}
		$fullInputHTML .= $addressLookupButton;
		$fullInputHTML .= '</div><div style="padding-bottom: 10px;">';
		$fullInputHTML .= $coordsInput; 
		if (!$wgPageFormsDisableMapUpdateButton) {
			$fullInputHTML .= $mapUpdateButton; #"set marker"
		}
		$fullInputHTML .= '</div>';
		$fullInputHTML .= $mapCanvas;

PageForms.php:

#Customise googlemaps input type
$GLOBALS['wgPageFormsDisableAddressLookupInput'][] = null;
$GLOBALS['wgPageFormsDisableMapUpdateButton'][] = null;

I hope this is useful but am standing by for you to point out obvious errors or omissions! Jonathan3 (talk) 01:54, 7 December 2016 (UTC)

This is interesting... I assume this won't work if there's more than one such input on the page? Not that that's necessarily a dealbreaker; just making sure. Yaron Koren (talk) 14:25, 7 December 2016 (UTC)

Thanks. If there are multiple inputs then they are concatenated, with commas, before being sent for geocoding. Here are extracts from a form on my test wiki:

| {{{field|<fieldname1>|input type=text|class=pfForMaps}}}
...
| {{{field|<fieldname2>|input type=text|class=pfForMaps}}}
...
| {{{field|Coordinates|input type=googlemaps}}}
...
| {{{field|fieldname3|input type=textarea|class=pfForMaps}}}

Fieldname1, 2 and 3 could be Street, Town, Postcode, or whatever. The textarea content contains line breaks - these would be easy to remove, and maybe replace with commas, but Google doesn't seem to mind. I've not tried it with other input types but expect anything with a useful "value" would work. Jonathan3 (talk) 00:10, 8 December 2016 (UTC)

Ah, that's clever - I hadn't thought of finding all the relevant text fields and just concatenating them. Somehow I had thought more coordination would be needed. My question was actually about having multiple map inputs on a page, but this is also good to know. Yaron Koren (talk) 05:29, 8 December 2016 (UTC)

You're right. As it stands, if there any "pfForMaps" inputs on a page, together with multiple googlemaps inputs, each googlemaps input would take the same "pfForMaps" data and send it for geocoding. To get round that you'd need to have separate classes (e.g. pfForMaps1, pfForMaps2) for each set of inputs, and pass a parameter from the googlemaps field of the wiki form to doMarkup() to associate that googlemaps field with the relevant set of inputs. Jonathan3 (talk) 12:37, 8 December 2016 (UTC)

P.S. Sending a parameter to doMarkup(), if this is possible, could also allow a mixture of "old" and "new" googlemaps input types, as the old pfAddressInput class name could be passed in the same way.Jonathan3 (talk) 12:46, 8 December 2016 (UTC)

I think I've got this to work! Just choose a name for each map, e.g. mapone and maptwo. Set the class of the input(s) containing the address to the relevant name (e.g. {{{field|Location|input type=text|class=mapone}}}), and the id of the relevant googlemaps input to the corresponding name (e.g. {{{field|Coordinates|input type=googlemaps|id=mapone}}}. You can have any combination of these, e.g. multiple inputs for one map, overlapping inputs for any map. The $addressLookupInput "Enter address here" box does not display when an id has been set for that input (as the address is being obtained from outside the googlemaps input itself). For the other issue, you can choose to hide the $mapUpdateButton "Set marker" button for selected googlemaps inputs from the Form page, e.g. {{{field|Coordinates|input type=googlemaps|id=mapone|hidesetmarkerbutton}}}. I'll work on a diff and send it to you for review. Jonathan3 (talk) 23:44, 11 December 2016 (UTC)

Rather than cut and paste more here, I have tried to use Phrabricator. The link is: https://phabricator.wikimedia.org/T153032 Jonathan3 (talk) 01:14, 13 December 2016 (UTC)

Is there any way to have the page title included in the form as a hidden element? If I could do that then including the title in the geocoding could be an option. Thanks. Jonathan3 (talk) 23:44, 11 December 2016 (UTC)

I found one way of using the page title but was surprised to find that including the place name sometimes led to no geocoding result at all, so abandoned this idea. Jonathan3 (talk) 01:14, 13 December 2016 (UTC)

How do I use sfAddResourceLoaderModules hook?

Hi,

I'm trying to add a javascript resource and use it with the query page. How do I correctly use this hook to add a resource?

I tried:

$wgHooks['sfAddResourceLoaderModules'][] = "ext.LinkTarget";

You need to have something like:

$wgHooks['sfAddResourceLoaderModules'][] = "myAddRLModules";
function myAddRLModules( &$otherModules ) {
        &$otherModules[] = "ext.LinkTarget";
}

Note that, if you upgrade to the latest version (i.e. Page Forms), the hook names have all changed slightly. Yaron Koren (talk) 14:40, 7 December 2016 (UTC)

Thanks, Yaron. This really cleared things up for me. Xephyr826

Returning to a different page following an edit using a form

Hi

I'm using Page Forms 4.0.2, Cargo 1.2 and MW 1.26.4. I am listing a number of pages as rows in a dynamic table. Each row terminates with an 'Edit' link to the form to edit the page listed in that row. I can achieve this using the following field statement in the cargo query:

|fields=CONCAT( '[[User:', Member, ']]' )=User,Start_date=Start Date,End_date=End Date,CONCAT( '[[Special:FormEdit/Group_Member/', _pageName, '|Edit]]' )=

However I'd quite like to return to the original page with the dynamic table when the form edit is saved. What I'm trying is the following:

|fields=CONCAT( '[[User:', Member, ']]' )=User,Start_date=Start Date,End_date=End Date,CONCAT( '[[Special:FormEdit/Group_Member/', _pageName, '/query string%3Dreturnto%3D{{FULLPAGENAME}}|Edit]]' )=

However, rather than taking me to the correct page to edit it now taken me to the form for creating a new page where the page name includes the target page name plus "/query string=returnto" plus the name of the original page. I also tried a variant of this with a similar result as follows:

|fields=CONCAT( '[[User:', Member, ']]' )=User,Start_date=Start Date,End_date=End Date,CONCAT( '[[Special:FormEdit/Group_Member/', _pageName, '&returnto%3D{{FULLPAGENAME}}|Edit]]' )=

I wonder if there is any way to get the Special:FormEdit link to return to the calling page when the form is saved or cancelled?

Many thanks

Duncan

I think the issue is just that - as it seems like you've discovered - you can't pass in a query string within a double-brackets internal link (unfortunately). So the correct solution may involve using the "fullurl" parser function, and having the CONCAT call create the entire HTML link tag - or having it be an external link, i.e. with single brackets. Yaron Koren (talk) 18:14, 12 December 2016 (UTC)

InstantCommons and forms

If we want to include images from Wikimedia Commons in a page via forms, there is a way to facilitate it to users? Something like an autocomplete based on a category name in Commons, for instance. --Dvdgmz (talk) 22:09, 11 December 2016 (UTC)

Unfortunately, no - but that sounds like a good idea. The closest thing is the Semantic Image Input extension, and I think that one needs to be updated to work with Page Forms - plus it's not exactly what you're asking about. Yaron Koren (talk) 18:22, 12 December 2016 (UTC)

Customize upload form

How to customizing upload form in the page form input. For example: there is no destination filename and license input box in the form? Or how to redirect to Special:BatchUpload for example? Thanks

There's no way to do such a thing, unfortunately; though I'm surprised that you're not seeing either of those two inputs in the upload form. Yaron Koren (talk) 17:07, 14 December 2016 (UTC)

In the Upload Form default from Mediawiki, it will automatically set the destination filename as soon as the upload file is set. How to set this too on upload form in the page form input? Thanks

That should be happening automatically... what version of this extension are you using? Yaron Koren (talk) 16:35, 15 December 2016 (UTC)

Return to a different page from formlink

Hi

This may be related to the question above on returning to a different page. I have a post button that creates a new page. On completion I wish to return to the page that has the post button rather than the page created. Unfortunately it doesn't work. The parser function I'm using is:

{{#formlink:form=Group Member|link text=Add a new Group Member|link type=post button|tooltip=Click on this link to add a new member to this Group using a form. |query string=Group Member[Group]={{PAGENAME}}&returnto={{FULLPAGENAME}} }}

However if I remove the link type parameter all together so it's just a hyper link then it works fine:

{{#formlink:form=Group Member|link text=Add a new Group Member|tooltip=Click on this link to add a new member to this Group using a form. |query string=Group Member[Group]={{PAGENAME}}&returnto={{FULLPAGENAME}} }}

I wondered if this was a constraint of using post button or if you have any suggestions how I might get this to work?

Many thanks

Duncan, 16th December 2016

I'm guessing that it's a constraint, i.e. that you can't pass in values via POST and GET at the same time. Yaron Koren (talk) 16:22, 16 December 2016 (UTC)

Control structures in semantic forms

I am curious whether Semantic Forms supports control structures. I would like to express something like: if value given to field A is X then field B will allow values X,Y,Z;

Perhaps it is something that can be easily achieve with Javascript, simply hiding/showing set of possible values, based on values chosen for another field.

Thanks! Castroblop (talk) 21:45, 16 December 2016 (UTC)

Yes - see the "values dependent on" feature. Which may or may not solve your specific problem. Yaron Koren (talk) 18:09, 20 December 2016 (UTC)

Repo blanked

Was the decision to break Git installs on update by blanking the repo instead of deprecating it discussed anywhere? If so, where? -71.36.99.196 04:43, 22 December 2016 (UTC)

Sorry about that - I wasn't the one who blanked the repository, and I'm trying to convince the people who did it to restore the code. For the moment, you should be able to get all the code back by calling the following:

git commit reset --hard HEAD^

Or, of course, you can switch over to Page Forms, though I'm not trying to force anyone to do that just yet. Yaron Koren (talk) 14:37, 22 December 2016 (UTC)

Rendering placeholder text in freetext input

Hi Yaron

I'm using transclusion from another page to provide place holder text for a freetext input box (which uses the wikieditor). This works in that the page data is displayed however it displays the html markup codes (eg for paragraphs etc) rather than rendering them. I wonder if there is a way to get the content of the placeholder to render correctly?

Many thanks, Duncan 30 Dec 2016

I don't know. Though I should note that it's unusual to have more than one sentence of placeholder text - let alone more than one paragraph. Yaron Koren (talk) 14:57, 30 December 2016 (UTC)

Using Page Forms, data is not stored

Hi Yaron, all,

I'm running into problems storing the actual data when using Page Forms, using the 'one-step process'. I can fill out the defined form, but data never gets stored. Use SMW for data storage. Started with a SF older form that I used before. Form: http://csdms.colorado.edu/wiki/Form:Annualmeeting Output: http://csdms.colorado.edu/wiki/Annualmeeting:2017_CSDMS_meeting-001 (displaying the templates used, missing all property values)

Any hint on how to trouble shoot this? Albert.

Versions: MW 1.27.0 SMW 2.4.1 PF 4.0.2 Cargo 1.2 $smwgEnabledCompatibilityMode = true;

I can confirm that there are identical or similar issues with PF 4.0.2 on a MW 1.28 installation. After I tried to edit a page through a form, I also found that all template fields but one were removed. I did not experience such behaviour with PF 4.0.1, so it must have been something that got introduced with 4.0.2. Cavila 14:40, 31 December 2016 (UTC)

I don't know - I can't reproduce this problem. Are you using the very latest PF code? Version 4.0.2 came out a month ago, so maybe the problem has been fixed since then... if that's not it, what version of PHP are you running? It could be anything, I suppose. Yaron Koren (talk) 14:47, 1 January 2017 (UTC)

PF 4.0.2, just downloaded this version ~4days ago. PHP 5.6.29 (fpm-fcgi), mysql: 5.6.23-log. Rest: http://csdms.colorado.edu/wiki/Special:Version. What would be the safest way to 'de-install' Cargo, including removing it from MW tables completely? I want to make sure that PF isn't somehow affected by Cargo. --2601:281:8701:2FE2:5D02:6998:9A98:32A7 02:30, 2 January 2017 (UTC)

Alright. I don't think there's any way that Cargo is affecting this (or SMW, for that matter) - the issue is that the wikitext itself is not being set correctly. If possible, could you create an account for me on that site, so I can test it out myself? Yaron Koren (talk) 04:16, 2 January 2017 (UTC)

Thanks for the account. My current theory is that it's the presence of one or more other extensions that's causing the problem - my strongest guess is that it's WikiEditor, ConfirmEdit, or the combination of the two. Could you try briefly un-including those two extensions, and see if that fixes the problem? Yaron Koren (talk) 02:46, 3 January 2017 (UTC)

Thank you for looking into this Yaron. I un-included the two extensions, tried the form, but get the same behavior, no properties and their data is saved. I have no clue where to start but could there be something off with the namespace indexing of the wiki, that it somehow doesn't see the 'Property' namespace? The reason I'm asking is because I noticed that I have set the form to be used for this namespace (http://csdms.colorado.edu/wiki/csdms:Annualmeeting). However, when saving an entry and than re-editing it with forms it didn't come up with the right form (gave me a list of options). I had to force it by including "#default_form:Annualmeeting" in a template (http://csdms.colorado.edu/wiki/Template:CSDMS_meeting_personal_information_template-2014). Normally a namespace defined form is enough. Having said that, I don't see an issue with the namespaces: http://csdms.colorado.edu/mediawiki/api.php?action=query&meta=siteinfo&siprop=namespaces. Thanks again, Albert. --2601:281:8701:2FE2:D0C0:B895:59F:2016 03:12, 3 January 2017 (UTC)

I don't think there's a connection between those two issues. Yaron Koren (talk) 04:42, 3 January 2017 (UTC)

PageForms is saving its properties for me as well now, so great fix! I'm still having issues database related. Special:RecentChanges is not updating anymore. The runJobs.php never empties the job queue and seems to hang on SMW once in a while (now turned off the SMW extension to see if that helps). Anyway, not there yet but the problem with PF seems to be solved. Thanks Yaron!

--128.138.87.14

I have the same issue (MW 1.26.2, SMW 2.4.4, PF 4.0.2). Till yesterday I used to have SMW 2.4-alpha and Semantic Forms 3.? (I don't really recall) when I run across the edit-with-form namespace issue so I upgraded to latest PF 4.0.2 in order to check if the issue persists. After reporting it I noticed that a form didn't save any fields so I upgraded SMW too (and anything else that comes with composer) but still, when I save a page with a form, no fields are saved except the plain template: {{some template}}. --Ioannis Protonotarios 16:57, 4 January 2017 (UTC)

This is clearly a serious issue, though I can't reproduce it myself. I think I need command-line access to a server on which this is happening in order to debug the issue - I hope to have that within a week or so, although if anyone can get me access sooner than that, I can look into it earlier. Yaron Koren (talk) 17:40, 4 January 2017 (UTC)

I have given you access to my server; please check your email. --Ioannis Protonotarios 22:05, 4 January 2017 (UTC)

Thank you! I was able to debug the issue, and I checked in a fix. Sorry to everyone affected by this - this was due to a patch that someone else contributed about a week ago, but I should have been more vigilant about checking its possible side effects. Yaron Koren (talk) 05:45, 5 January 2017 (UTC)

Thank you!! Forms now save pages as expected (and you left me with a 9K jobs qeue :-P More feedback only after qeue finishes). --Ioannis Protonotarios 15:40, 5 January 2017 (UTC)