Extension talk:Page Forms

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: thrown in (...)/w/includes/registration/ExtensionProcessor.php on line 348
 * 1) 0 (...)/w/includes/registration/ExtensionProcessor.php(173): ExtensionProcessor->storeToArray('load_composer_a...', true, Array)
 * 2) 1 (...)/w/includes/registration/ExtensionRegistry.php(202): ExtensionProcessor->extractInfo('(...)/...', Array, 1)
 * 3) 2 (...)/w/includes/registration/ExtensionRegistry.php(127): ExtensionRegistry->readFromQueue(Array)
 * 4) 3 (...)/w/includes/Setup.php(39): ExtensionRegistry->loadFromQueue
 * 5) 4 (...)/w/includes/WebStart.php(137): require_once('(...)/...')
 * 6) 5 (...)/w/index.php(38): require('(...)/...')
 * 7) 6 {main}

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  twice. Usually the first line shows the gerrit link like it is also documented on the page about installing. It will be nice to get this as it is happening for the other extensions in Phabricator. Cheers --&#91;&#91;kgh&#93;&#93; (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:

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.

Where the template contains:

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:

&lt;nowiki>&lt;/nowiki>

Note: form elements in triple braces have to be bracketed by nowiki tags, except parameters passed to the form. &lt;nowiki> &lt;/nowiki> &lt;nowiki> &lt;/nowiki>

I have tried several variations on this form. I tried without using the template 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 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.



Freitext:


 * 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. :( --&#91;&#91;kgh&#93;&#93; (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 --&#91;&#91;kgh&#93;&#93; (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  and the template "Licences" holds just   as instructed. So how is the mapping done, i.e. how do I e.g. store "C" and display "Copyrighted" for selection? Cheers --&#91;&#91;kgh&#93;&#93; (talk) 23:11, 13 November 2016 (UTC)


 * Maybe the documentation should be clearer, because the template definitely shouldn't look like just " ". It should instead look like "  " 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 --&#91;&#91;kgh&#93;&#93; (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 --&#91;&#91;kgh&#93;&#93; (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:: "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:


 * 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: … but if there would be a “last sep”-parameter or so, please let me know. Thanks, --Andreas P. 14:39, 14 November 2016 (UTC)
 * using #pos: & #sub constructs
 * using #explode constructs
 * using extension:Arrays


 * 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 --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (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: The example uses extension: Variables:  &lt;!--   --&gt;  &lt;div  class= &quot;list-comma-sep list-show-last-and&quot;  &gt;  &lt;!--   --&gt;   &lt;!--   --&gt;  &lt;/div ' &gt; '
 * to loop through only once via #arraymap
 * to use CSS for the display of different list displays

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

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.

(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 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)
 * Scope(architectuurbesluit)=Programma
 * Onderwerp(Architectuurbesluit)=Context
 * Onderwerp(Architectuurbesluit)=Context
 * Onderwerp(Architectuurbesluit)=Context
 * Onderwerp(Architectuurbesluit)=Context


 * 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  with the optional parameter   set to , a notice shows up complaining about a missing variable  (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: Frdpnl (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:

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 --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (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:  (for the default_form PF in a category), , instead of their normal values.

LocalSettings include:  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

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

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

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

PF_maps.js:

Rearranged PF_GoogleMapsInput.php:

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

PF_GoogleMapsInput.php:

PageForms.php:

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:


 * 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. ), and the id of the relevant googlemaps input to the corresponding name (e.g.  . 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.  . 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( '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( '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( '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:

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

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:

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:. --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)

Improving doLookup function
Sometimes the address entered by the user is one that returns ZERO_RESULTS because it contains extra information before the street address (e.g. the name of the place), but would work fine if this information were removed.

There is no simple way to let the user know exactly how the Google geocoding API works, and it would be better to have the software do the work in any event, so I wonder whether it would be possible to change the doLookup function to do one or both of the following:

1. Use a regular expression to extract the postcode from the address (in the UK at least this is fairly easy) and perform a further search on this postcode if the original search returns ZERO_RESULTS.

2. Repeatedly/recursively remove everything up to the first comma (or perhaps also line return if textarea fields are being used) and perform a further lookup on what remains until it is successful. For example, first of all it might remove the place name, then perhaps the street name, until it is just left with the postcode.

Thanks in anticipation, and Happy New Year. Jonathan3 (talk) 01:12, 2 January 2017 (UTC)


 * Those both sound like they would be an improvement over the current state of things. Yaron Koren (talk) 02:12, 2 January 2017 (UTC)


 * Great. If I worked on this and sent you a patch, would you consider adding it to the code? (I wouldn't want to have to add it manually each time I update the extension.) Jonathan3 (talk) 20:25, 2 January 2017 (UTC) P.S. I've taken the liberty of correcting doMarker to doLookup in my previous comment. Jonathan3 (talk) 20:35, 2 January 2017 (UTC)


 * Yes, of course. Yaron Koren (talk) 21:54, 2 January 2017 (UTC)

"Edit with form" tab and "Template" namespace
I have created a Form:Template and a Project:Template page with contents:  but the "Edit with form" tab won't appear to "Template" namespace. PF 4.0.2 --Ioannis Protonotarios 01:42, 4 January 2017 (UTC) Happy New Year!

!P.S. The exact same thing works just fine in "Property" namespace. --Ioannis Protonotarios 01:44, 4 January 2017 (UTC)


 * Happy New Year! Have you defined the "Template" namespace on your wiki? Yaron Koren (talk) 05:04, 4 January 2017 (UTC)


 * What do you mean? It's a standard namespace. I haven't done anything myself, neither in "Property" namespace which is pre-defined too by SMW. --Ioannis Protonotarios 12:42, 4 January 2017 (UTC)


 * Oh, man... that's the last time I try to provide help after midnight. Disregard my last comment, of course. But I have to ask - how can you have a form to edit templates? That doesn't seem workable. Yaron Koren (talk) 16:19, 4 January 2017 (UTC)


 * Well, I've started building a meta-ontology to store data about the semantic structrure of my wiki, i.e. properties, concepts etc. For example, property X is subproperty of property Y, is used in template Z etc. And then I thought, why not assign properties to templates too? E.g. template A is used in template B, has template type C etc. All property definitions should obviously go inside a  tag and the template code inside a   tag. Then I thought, why not use forms? Since a form puts its wikitext in the begining of the page, and plain wikitext goes right after that, I figured that the workaround would be to use no   tags and wrap the actual template code in a   tag. Which I did and it worked! So now I can edit templates with forms just fine! The template code appears in the free text box. See example: Template:1080p view code view form. The only problem is what I've reported, that there is no "Edit with form" tab and that the   doesn't work. It asks "which form to use?", even though the form is defined in Project:Template. --Ioannis Protonotarios 17:39, 4 January 2017 (UTC)


 * That's strange - I can't replicate this issue; it works fine for me. I don't know what's causing it on your wiki. Try resaving the "Project:Template" page, maybe? Yaron Koren (talk) 17:54, 4 January 2017 (UTC)


 * Yes, the infamous "null edit"! But it doesn't work. Moreover, after rebuilding semantic data after the upgrade, now it seems that all "Edit with form" tabs have disappeared! --Ioannis Protonotarios 22:10, 4 January 2017 (UTC)


 * P.S. Auto-creation of pages has stopped working too. --Ioannis Protonotarios 22:14, 4 January 2017 (UTC)


 * This I think I've found it. I use the obsolete "Creates pages with form" property but I if undestand correctly I must now use the #formredlink function instead, right? --Ioannis Protonotarios 15:29, 5 January 2017 (UTC)


 * Okay, now that I've looked at your wiki, I'm pretty sure what the issue is for most of your forms - you're defining the relationship of form to category via Page Schemas, and within each schema, the "semanticforms_Form" tag (both closing and opening) needs to be modified to be "pageforms_Form". Sorry that this has been poorly documented. Yaron Koren (talk) 05:49, 5 January 2017 (UTC)


 * I've added a side note to Page Schemas documentation. Page Schemas is a very helpful extension for newbies because it easily creates a working semantic structure but I think I will completely remove it since creating things manually gives more control and you know what you are doing. As for the template/form issue maybe it's because of my MW 1.26.2 version. I think I saw somewhere a mention of compatibility issues with latest SMW. The problem is that Media Temple, my hosting provider, is still stuck in PHP 5.3.x (MW 1.27 requires PHP 5.5.9) and they won't tell us when and if they will ever upgrade it to 7. I've filed support requests on that and they always say that they are working on it. So right now I am stuck with MW 1.26.2. --Ioannis Protonotarios 15:29, 5 January 2017 (UTC)

regexp
Hi,

I am trying to improve increase validation on one of my forms with regexp but I don't seem to be getting any errors. I am competent with Page Forms but have never used regexp before. The example extract below is taken from a partial form (template)

|

I would have expected to get an error if I only entered a number but I get no error and the field is being passed back as though the regexp has had no effect. Can anyone advise?

MW 1.27.1, PF 4.0.2

Regards,

Mark


 * Oops! It looks like the "regexp" input hasn't worked since at least version 4.0, i.e. the extension rename, and maybe even earlier. I just checked in some fixes, so if you get the latest code it should work. Yaron Koren (talk) 16:05, 6 January 2017 (UTC)

"UNIQ" and "Some very long page name" strings
Hi Yaron, me again. I've started replacing "Creates pages with form" property with the #formredlink function as I said two threads above and it works (almost*) fine but while in the process of creating the new pages, some weird stuff appear on page: After all red link pages have been created, things go back to normal and appear as expected.
 * 1) #formredlink calls (red or blue) that are before the last #formredlink-to-be-created appear as "UNIQ--item-2--QINU, UNIQ--item-3--QINU, UNIQ--item-4--QINU, UNIQ--item-5--QINU, etc". #formredlink calls (blue) that follow the last #formredlink-to-be-created appear OK.
 * 2) At the same (i.e. while there are red link pages under creation), other links, that they are property declarations of type URL, appear as "Some very long page name that will hopefully never get created ABCDEF123".

Similar past issues:
 * 1) Work-around for un-populated red link A very long page name error (27 October 2014)
 * 2) "Create pages with form" and sfEditFormPreloadText (4 November 2013)

Notes:  *  I say "almost" because I haven't managed to employ "query string" parameter yet but I am still looking at it and if I don't succeed I will come back to report it officially.

--Ioannis Protonotarios 09:20, 6 January 2017 (UTC)

Relocating standard inputs to a different area of the page
Hi Yaron

Some time ago I seem to remember seeing an example of using Page Forms (or Semantic Forms as it then was) to relocate the standard inputs to a different location (eg the top) of the form. Was I just imagining this or, if not, would you be able to point me in the right direction?

Many thanks

Duncan 8th Jan 2017


 * Ah I think I've worked this out. I created a 'sub' form (as a template) and just transcluded this before the other parts of the form.  Seems to work anyway.  Many thanks.  Duncan


 * I think there is no need for a 'sub' form. You can just place any of the  anywhere you like in the form and multiple times if you like. For instance, in big forms I usually put the two main buttons save and preview  both at the top and at the bottom of the form, so as to be handy. --Ioannis Protonotarios 19:08, 8 January 2017 (UTC)

Have global settings changed with the move from SF to PF
Hi all, Yaron,

I'm facing some MW database issues that I'm trying to solve by cleaning my LocalSettings.php as much as possible. As such I came across $sfgNamespaceIndex which namespace I had set to 150. Is this variable still used in PF or renamed or is it save to remove this? Thanks, --Albert Ke (talk)


 * It was renamed - all the global variables had the "$sfg" in their name replaced with "$wgPageForms". I'm guessing you will still need to include that line in LocalSettings.php. Yaron Koren (talk) 19:40, 9 January 2017 (UTC)


 * Ok., so the variable becomes $wgPageFormsNamespaceIndex. I had the old SF variable directed to namespace 150 so set this new PF variable to it as well. However, when including this under the wfLoadExtension ('PageForms'), save and exit, then do a touch LocalSettings.php, even an php update.php in the maintenance folder, namespace 150 doesn't show up in the list: http://csdms.colorado.edu/mediawiki/api.php?action=query&meta=siteinfo&siprop=namespaces. Or did I miss anything? Thanks! --Albert Ke (talk)


 * Oh, never mind - looking through the code now, it looks like the namespace IDs are hardcoded and can't be changed, and it has been that way for a long time. I guess I had forgotten. So I think you can just remove that line. Yaron Koren (talk) 20:28, 9 January 2017 (UTC)


 * OK., perfect another potential database problem that is ruled out. Thanks, --Albert Ke (talk) 20:40, 9 January 2017 (UTC)

Internal Error:
Just updatet to newest MW & SMW. New PageForms causes Error, while old SemanticForms instead still works. Any ideas?

[9851f6842c7da4f513efdf25] /index.php/Hauptseite MWException from line 176 of C:\QMSSERV\htdocs\includes\Hooks.php: Invalid callback PFHooks::initProperties in hooks for smwInitProperties Backtrace:


 * 0 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\PropertyRegistry.php(420): Hooks::run(string)
 * 1 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\PropertyRegistry.php(79): SMW\PropertyRegistry->registerPredefinedProperties(boolean)
 * 2 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\includes\dataitems\SMW_DI_Property.php(86): SMW\PropertyRegistry::getInstance
 * 3 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\DataItemFactory.php(42): SMW\DIProperty->__construct(string, boolean)
 * 4 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\PropertyAnnotator\DisplayTitlePropertyAnnotator.php(66): SMW\DataItemFactory->newDIProperty(string)
 * 5 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\PropertyAnnotator\PropertyAnnotatorDecorator.php(61): SMW\PropertyAnnotator\DisplayTitlePropertyAnnotator->addPropertyValues
 * 6 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\ParserAfterTidy.php(117): SMW\PropertyAnnotator\PropertyAnnotatorDecorator->addAnnotation
 * 7 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\ParserAfterTidy.php(87): SMW\MediaWiki\Hooks\ParserAfterTidy->updateAnnotionsForAfterParse(SMW\PropertyAnnotatorFactory, SMW\SemanticData)
 * 8 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\ParserAfterTidy.php(53): SMW\MediaWiki\Hooks\ParserAfterTidy->performUpdate
 * 9 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\HookRegistry.php(126): SMW\MediaWiki\Hooks\ParserAfterTidy->process
 * 1) 10 [internal function]: SMW\MediaWiki\Hooks\HookRegistry->SMW\MediaWiki\Hooks\{closure}(Parser, string)
 * 2) 11 C:\QMSSERV\htdocs\includes\Hooks.php(195): call_user_func_array(Closure, array)
 * 3) 12 C:\QMSSERV\htdocs\includes\parser\Parser.php(1397): Hooks::run(string, array)
 * 4) 13 C:\QMSSERV\htdocs\includes\parser\Parser.php(444): Parser->internalParseHalfParsed(string, boolean, boolean)
 * 5) 14 C:\QMSSERV\htdocs\includes\content\WikitextContent.php(330): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)
 * 6) 15 C:\QMSSERV\htdocs\includes\content\AbstractContent.php(497): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)
 * 7) 16 C:\QMSSERV\htdocs\includes\poolcounter\PoolWorkArticleView.php(140): AbstractContent->getParserOutput(Title, integer, ParserOptions)
 * 8) 17 C:\QMSSERV\htdocs\includes\poolcounter\PoolCounterWork.php(123): PoolWorkArticleView->doWork
 * 9) 18 C:\QMSSERV\htdocs\includes\page\Article.php(651): PoolCounterWork->execute
 * 10) 19 C:\QMSSERV\htdocs\includes\actions\ViewAction.php(71): Article->view
 * 11) 20 C:\QMSSERV\htdocs\includes\MediaWiki.php(495): ViewAction->show
 * 12) 21 C:\QMSSERV\htdocs\includes\MediaWiki.php(289): MediaWiki->performAction(Article, Title)
 * 13) 22 C:\QMSSERV\htdocs\includes\MediaWiki.php(851): MediaWiki->performRequest
 * 14) 23 C:\QMSSERV\htdocs\includes\MediaWiki.php(512): MediaWiki->main
 * 15) 24 C:\QMSSERV\htdocs\index.php(43): MediaWiki->run
 * 16) 25 {main}


 * I'm guessing you downloaded Page Forms via the Extension Distributor. You shouldn't do that - you should always download PF (or any of my extensions) via the main download link on the page. I wish the ED link weren't there at all. Sorry about that. Yaron Koren (talk) 17:51, 10 January 2017 (UTC)


 * solved this Problem. Thanks --Letofred (talk) 12:31, 11 January 2017 (UTC)

File-Upload and Handling
1) Got a probleme with uploding files via PageForms (4.0.2 on MW 1.28.0 SMW 2.4.4) ending in a Fatal error: Call to undefined method OutputPage::getHeadScripts in *****\extensions\PageForms\specials\PF_UploadForm.php on line 327

2) I have a form like this:

Creating a Page with this Form works fine. Edit this Page with formedit causes following problem: If I select the "Page" or "File" whitch is the first kind of it works as expected. If I select "Form" or "PDF / Pic" he wont get the "Pagename" or "Filename".

I used this way to schow a different Icon. This may helpful for users to know if its a internal (Page) or external Link (URL) or if he can view this in browser or need a different kind of program to view. I suspect, your just try to set the "pagename/filename" to the first field found. May I request to set every field found to the given "pagename/filename"?

My workaround would be to name them pagename1, pagename2 etc ... It wount satisfy me, if I upload first and later change the "kind" I forgott to set ... --Letofred (talk) 13:04, 11 January 2017 (UTC)


 * Hi - for #1, just delete that line - it was deleted a while ago in the main PF code, but I guess not before version 4.0.2 was released. Sorry about that. For #2, yes, you can't have more than one "field" tag for the same field name, even if only one of them is shown at a time - that's a limitation of PF. So yes, the easiest solution is to have different field names. Potentially, you could also turn those last three rows into just one row, and have "show on select" apply to just the "label" cell instead of the whole row - and then add three more "show on select" values, all applying to the same "field" cell. Does that make sense? Yaron Koren (talk) 15:10, 11 January 2017 (UTC)


 * #1 solved
 * #2 Think about your solution ... atm there seems no way to avoid a second selection. If I correctly read your suggestion, just giving the ID to the "label" / Picture will allways show the input field for the file - even if I dont select a kind of file - i.e. a page ... not the way it should look like ...
 * The use of classes instead of ID would be a nice solution. I could use {Class A} Pic1 {Class B} Pic2 {Class C} Pic3 {Class A B C} Form-Tag. Maybe a suggestion for a next version? Would cause problems with compatibility? --Letofred (talk) 17:32, 11 January 2017 (UTC)


 * No, the input field would not always be shown - but maybe it's too difficult to explain. Yes, it would have been better to go with class instead of ID, but yes, it would break compatibility at this point. Yaron Koren (talk) 17:36, 11 January 2017 (UTC)