Extension talk:Page Forms

Include SMW inline query in info tag "page name" parameter?
Hi there. I would like to design a form that generates the value of the pagename parameter from a combination of
 * 1) a template field value (  ) AND
 * 2) the result of an SMW inline query

Is this doable? How would the syntax look like? -- 11-G3n (talk) 09:06, 5 December 2018 (UTC)


 * I think the only way to do this is programmatically, using the "PageForms::SetTargetName" hook. Yaron Koren (talk) 19:55, 5 December 2018 (UTC)


 * Thanks! 11-G3n (talk) 18:47, 6 December 2018 (UTC)

input type "datetime" loses time zone info on editing
If I have a PageForm defined with a datetime input with "include timezone" set, I can enter the date, time, and timezone and save correctly. However, when I go to edit the page with the form again the timezone gets changed to UTC and the date/time get converted to UTC (I think it may actually change to the server's time zone). I think the issue is related to PF_DateTimeInput.php line 81, as the call to date just takes in the integer timestamp. I wonder if maybe line 69 should be tweaked to use date_create_from_format or some other code to parse out the timezone string from the template value. --PCChris23 (talk) 07:38, 5 October 2018 (UTC)


 * s/date_create_from_format/DateTime::__construct/ should I create an issue in Phabricator? I am not very familiar with PHP or with the codebase of MediaWiki or this extension, but I could try to fix it if this general approach seems reasonable. Or is there some other workaround you can suggest? Thanks, PCChris23 (talk) 06:26, 13 October 2018 (UTC)


 * Sorry about the problem, and that was a good idea on the solution. I just checked in what I think is a fix, using the PHP DateTime class as you suggested. Yaron Koren (talk) 03:09, 15 October 2018 (UTC)


 * Thanks,, that did the trick! --PCChris23 (talk) 23:54, 28 October 2018 (UTC)

Combobox/Text with autocomplete: Possibility for indented items or separators for separating content?
Heya,

is there a possibility to format the content of a combobox or text with autocomplete in a way that it shows indented items (like "*", "**" etc. for "tree" input type)?

If not, is there a way to insert a horizontal rule or a blank line in order to group the list items?

Thank you!

--Sochin67 (talk) 20:06, 5 October 2018 (UTC)


 * Unfortunately, no. Yaron Koren (talk) 20:20, 5 October 2018 (UTC)


 * Okay - thank you, Yaron! --Sochin67 (talk) 20:31, 5 October 2018 (UTC)

Set custom attr or ID on a field
I'm writing some pre-save errorchecking for a form in JS, and it would be really convenient if I could define an attribute like  for each field, particularly for dropdowns but also in general. Could something like  be added as an available option for any input field if it's straightforward enough to do? Similar for setting a custom ID. --RheingoldRiver (talk) 09:34, 10 October 2018 (UTC)


 * What about just putting a "div" or "span" tag around the input, and setting one or more classes for it - would that be good enough? Yaron Koren (talk) 15:51, 10 October 2018 (UTC)


 * I have 7 sets of data that correspond to different stats, and some of the fields are dropdowns so I have to monitor their values with .change. So what I'm able to do is pretty awkward if I want to do any kind of for loop. If I could set an attr I could look up its value and then define what changed with that as the key, and it would be a lot cleaner. But yeah this request is probably only needed for dropdowns, for any other input type I think just a parent class is fine (and has been so far). --RheingoldRiver (talk) 21:47, 10 October 2018 (UTC)

Bug with "show on select" radiobutton labels when using Multiple instances
Hi Yaron, hi Friends,

I am using Page Form [REL1_31 (June 24)] (Maybe this bug has already been fixed, if yes, sorry for that..)

When I use "show on select" with radiobuttons when using Multiple instances, the label of the radiobuttons are not clickable on every instance.

I have noticed that:
 * When I formedit a page, for each new multiple instance added, the radiobutton's labels have a "For" target empty (in that case the label is NOT clickable because the For is empty)
 * When I save the page and go back to formedit, the radiobutton's labels of the pre-existing instances doesn't have a "For" target at all (in that case the label is clickable)

I assume the best way to fix this is to add a target to each "For". Am I doing something wrong? Have you seen that bug before?

Thanks a lot --ClemFlip (talk) 10:15, 11 October 2018 (UTC)


 * Okay, I just checked in a fix for this (with your help :) ). Yaron Koren (talk) 19:09, 26 October 2018 (UTC)

Bug in fields textarea with editor = wikieditor: the field can not be empty.
Hi there, With PageForms 4.3.1, a textarea field with editor=wikieditor generates a bug when the field isn't filled : "« | » is not allowed except inside or ...."  --Megajoule (talk) 09:01, 12 October 2018 (UTC)


 * Is the problem still there in PF 4.4? Yaron Koren (talk) 04:45, 14 October 2018 (UTC)


 * Yes, it is... Megajoule (talk) 13:15, 8 January 2019 (UTC)

Textarea on multiple-instance templates while using IE turns placeholder text in to actual text
Hello!

When using the multiple-instance template and setting a field to use the "textarea" input type, the placeholder text (in the "textarea") populates as actual text. This only seems to happen on Internet Explorer, is there a way to fix this?

I'm experiencing this on:
 * MW: 1.31.1 (a4c8065)
 * SMW: 2.5.8
 * PF: 4.4-rc1 (b4c29bd)

Thanks in advance,

V brooks (talk) 18:12, 18 October 2018 (UTC)


 * Yes, that's a known problem, already listed here. Is there any way you can upgrade to MS Edge? Yaron Koren (talk) 19:03, 18 October 2018 (UTC)


 * Sounds good, majority of my users use Chrome so I'll suggest the IE users to use Chrome for now. Thanks! --V brooks (talk) 15:46, 19 October 2018 (UTC)

mapping cargo table ampersand encoding
If I have a cargo table "sweets" with a field "sweetName" and if I have a form that allows you to pick a sweet from this list like this...

M&Ms would be displayed as M&amp;amp;Ms in the option list. i.e

Have I missed a trick or is there a bug? JamesDriscoll (talk) 17:29, 1 November 2018 (UTC)


 * Further to this problem, I think I've tracked the issue down to double encoding in PF_DropdownInput::getHTML

Here is a fix for my own use case but I dont' know enough about the code to know if $label will also need decoding on line 91 and there may be similar issues in other forminputs.

If $label also needs decoding on line 91 maybe changing $innerDropdown .= Html::element( 'option', $optionAttrs, $label ); to $innerDropdown .= Html::rawElement( 'option', $optionAttrs, $label ); will have the desired outcome without having to call html_entity_decode?

I hope this helps JamesDriscoll (talk) 10:46, 10 November 2018 (UTC)

Create Property link missing
Hi

I have several installations of MediaWiki with Page Forms installed on all of these installations.

But one of the installations I am not seeing the create property link. I have run the update script, but still not seeing anything.

Not sure what I have done wrong.

Any help is appreciated.

Gary

--Squeak24 (talk) 13:04, 2 November 2018 (UTC)


 * It only shows up if Semantic MediaWiki is installed on that wiki. Yaron Koren (talk) 13:49, 2 November 2018 (UTC)


 * Thanks Yaron, I have Semantic MediaWiki installed, but it still isn't showing. The only SMW related extension I don't have installed at the moment is Semantic Compound Queries. Do I need that installed as well?

This is what I have so far:

--Squeak24 (talk) 10:22, 7 November 2018 (UTC)


 * What version of Page Forms are you running? Yaron Koren (talk) 17:13, 7 November 2018 (UTC)


 * Hi Yaron, apologies for the delay. I am using version 4.3. But now you mention that, this is the only Wiki I have that I am running SMW 3.0. I will try 2.5x --Squeak24 (talk) 10:55, 15 November 2018 (UTC)

WikiEditor strange timing bug
I'm trying to track down a bug where the wikieditor doesn't always display the file upload and other icons on a form edit. instead of



it's opening like this



I discovered an error that I'm hoping is related(though I'm not entirely convinced) the console is reporting

the offending line in PageForms.js is   called from (in PageForms.js)

with a param of null in this...

including &purge=true&debug=true in formedit url is very likely to repeat the bug. I've never got the icons to fail to load on a action=edit ,it's only happening on pageforms action=formedit. I hope this is usful info

JamesDriscoll (talk) 11:59, 3 November 2018 (UTC)


 * Sorry for the very long delay. This might have been fixed a while ago; I'm not sure. Yaron Koren (talk) 15:36, 12 February 2019 (UTC)


 * the initFunction error has gone but the fileupload doesn't always appear in a random way for users (often, but not always, a page refresh will fix it). loading a page with &action=formedit&debug=true  is still a pretty good way of reproducing the error (sadly on a company intranet so I can't point you at the problem) JamesDriscoll (talk) 14:51, 15 February 2019 (UTC)

$wgPageFormsAutocompleteOnAllChars = true; not working?
I have not tried earlier versions but since 4.3 minimum and every later version on php 5.6 setting this configuration parameter has no effect. I can only autocomplete on the first chars of a word and not on chars within a word. --91.64.58.124 16:13, 7 November 2018 (UTC)


 * I just tried it - it looks like it works with the "tokens" and "combobox" input types, but not with "text with autocomplete". What input type(s) are you trying it with? Yaron Koren (talk) 17:20, 7 November 2018 (UTC)


 * Yes, I am using it with "text with autocomplete". --91.64.58.124 19:43, 7 November 2018 (UTC)


 * Alright - well, this is a bug that should be fixed. I should note that I've been thinking for a long time of getting rid of "text with autocomplete" (and "textarea with autocomplete"), keeping just "tokens" and "combobox". I would recommend switching one of those two, since I think their interface is better anyway. Yaron Koren (talk) 20:29, 7 November 2018 (UTC)


 * At least "tokens" does not work as a way out. No acceptance for it from the editors and it is not working on skin Foreground. I will have to look at "combobox" but in the end I do not like to loose "text with autocomplete" and "textarea with autocomplete" at all. These are the best to use. --91.64.58.124 21:33, 7 November 2018 (UTC)

Input type "datepicker" only shows after reloading the form a second time

 * Setup:
 * PHP 7.0
 * MediaWiki 1.27.5
 * PageForms 4.4.2
 * Header Tabs 1.2

The datepicker only shows after reloading the form for a second time. The error shown in browser console for Firefox is:
 * Issue

TypeError: initFunction is not a function TypeError: "initFunction is not a function" PageForms_registerInputInit https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=ext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csubmit%2Cwikieditor%7Cext.pageforms.fancybox.jquery1%7Cjquery.checkboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Cuser%7Cmediawiki.api.user%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Csite%7Cuser.defaults&skin=monobook&version=737e8768c86e:72:20 fire https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:104 add https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:656 ready https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:49:63 https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=ext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csubmit%2Cwikieditor%7Cext.pageforms.fancybox.jquery1%7Cjquery.checkboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Cuser%7Cmediawiki.api.user%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Csite%7Cuser.defaults&skin=monobook&version=737e8768c86e:97:529 https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=ext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csubmit%2Cwikieditor%7Cext.pageforms.fancybox.jquery1%7Cjquery.checkboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Cuser%7Cmediawiki.api.user%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Csite%7Cuser.defaults&skin=monobook&version=737e8768c86e:67:104 runScript https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:163:74 fire https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:104 add https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:656 always https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:46:865 runScript https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:162:944 checkCssHandles https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:163:774 cssHandle https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:163:904 fire https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:104 fireWith https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:46:431 fire https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:46:474 fireCallbacks https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:157:607 addEmbeddedCSS https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:158:681 cssBufferTimer https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:157:832 load.php:178:449 log https://www.example.com/w/load.php:178:449 handler https://www.example.com/w/load.php:155:380 fire https://www.example.com/w/load.php:45:104 fireWith https://www.example.com/w/load.php:46:431 fire https://www.example.com/w/load.php:46:474 track https://www.example.com/w/load.php:155:162 runScript https://www.example.com/w/load.php:163:400 checkCssHandles https://www.example.com/w/load.php:163:774 cssHandle/< https://www.example.com/w/load.php:163:904 fire https://www.example.com/w/load.php:45:104 fireWith https://www.example.com/w/load.php:46:431 fire https://www.example.com/w/load.php:46:474 fireCallbacks https://www.example.com/w/load.php:157:607 addEmbeddedCSS https://www.example.com/w/load.php:158:681 addEmbeddedCSS/cssBufferTimer< https://www.example.com/w/load.php:157:832

Perhaps this is also related to HeaderTabs. This is why I incuded the info, too. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 11:37, 16 November 2018 (UTC)


 * I think you already reported that issue before, but it's still a problem, unfortunately. Yaron Koren (talk) 16:24, 16 November 2018 (UTC)


 * Well, it indeed somehow appeared familiar to me. Keeping fingers crossed for a fix. --&#91;&#91;kgh&#93;&#93; (talk) 18:58, 16 November 2018 (UTC)


 * This may be fixed now; I'm not sure. Yaron Koren (talk) 15:47, 23 January 2019 (UTC)

pfautoedit - 2 suggestions/requests
Hi,

1) Could you add a summary field for this action so I can let people know what's going on in RC?

And 2) Not sure how doable this is, but I often run this action on a set of 4k+ pages (all our player pages). Based on how long it takes to run, I assume it's blank editing every page if there are no changes. Would it be possible to have an option to say "skip if no changes" ? This would save me a ton of time since usually at most 300-500 of the pages need to be changed.

Thanks --RheingoldRiver (talk) 04:26, 24 November 2018 (UTC)

Auto complete on all pages
Auto completion can be enabled only on specific properties: name space, categories etc, but cannot be set for all pages in all namespaces (unless declared by Cargo which is not always possible or relevant), or not even to multiple name spaces. When working with wikis that use multiple content namespaces, there's a need to have autocompletion for all pages just like the autocompletion of the VE template-data feature (i.e. with a property "values from=allpages" which will use the "allpages" API query). Completion from content namespaces will be even better, but is not crucial.Wess (talk) 16:54, 26 November 2018 (UTC)


 * I should note that there's currently no way to autocomplete on either all namespaces, or all content namespaces, within Page Forms, even if Cargo or SMW are being used. Autocompleting on all content namespaces seems like a much more useful feature than autocompleting on every single page in the wiki. Another option would be to allow multiple values for "values from namespace", so that you could have something like "values from namespace=Main,Project,Help". Yaron Koren (talk) 22:27, 27 November 2018 (UTC)


 * You are right. Both options will solve this need. Wess (talk) 09:49, 3 December 2018 (UTC)


 * I added in this feature a few days ago - if you use the latest code, you can now specify multiple values for "values from namespace=", separated by commas. Yaron Koren (talk) 16:23, 30 December 2018 (UTC)

Width of tokens input type [PROPOSED SOLUTION]
The tokens input type doesn’t work well within a “formtable” class form on the iPhone any more. It expands beyond the intended width of the td element and makes the whole table too wide. I know tables aren’t great on mobile anyway but I’m sure it used to work ok. I’ve not looked into it but see that min-width is set by javascript as 6*size, ie default 600, and wonder if this is relevant. The input element flashes up the right width then changes as the page loads. I worked round the problem for now by using a wikitable with th and td on alternate rows (so that the width of the tokens input type doesn’t cause any problem). Best wishes. Jonathan3 (talk) 09:55, 26 November 2018 (UTC)


 * Yes, I've run into this problem too. What do you suggest doing? Yaron Koren (talk) 04:22, 27 November 2018 (UTC)


 * I'd need to look into it. Giving it its own row seems to work for now, though. Maybe use a responsive grid format for the forms, so that on a computer it's two-column but on a phone it's one? Or add a "width" parameter which the Javascript will respect when setting "min-width"? Jonathan3 (talk) 14:39, 27 November 2018 (UTC)


 * I did the following to set widths on fields for a birthday input with comboboxes (I didn't want to use date input type since we allow year only or month-day only entry):

.select2-choices, .select2-choice{ min-width: 0; } width: 100px; }
 * 1) content .form-ip-year .select2-container{

width: 120px; }
 * 1) content .form-ip-month .select2-container{

width: 70px; }
 * 1) content .form-ip-day .select2-container{

.form-ip-day, .form-ip-month, .form-ip-year { display:inline-block; } --RheingoldRiver (talk) 01:42, 29 November 2018 (UTC)


 * Thanks, both of you. For the tokens type, here is a solution in MediaWiki:Common.css: . It should be possible just to stop setting   in Page Forms by removing line 122 of ext.pf.select2.tokens.js which sets min-width:  . Jonathan3 (talk) 13:52, 23 February 2019 (UTC)

Issue with PHP 7.2
With PHP 7.2 Page Forms throws the following Warning in Special:FormEdit in a form with Field Typ Date Warning: count: Parameter must be an array or an object that implements Countable in /var/www/html/extensions/PageForms/includes/forminputs/PF_ComboBoxInput.php on line 146

Version is current as of today in master branch (07cfd57).


 * Sorry about that - I just checked in what I think is a fix for this problem. Yaron Koren (talk) 04:54, 29 November 2018 (UTC)

editor=wikieditor does not work anymore with a Semantic Property
Hello. It seems that  in a form does not work anymore. We are upgrading our wiki to MW 1.31 and found this problem.

I made an example on the SMW sandbox where the same thing happens.

see: https://sandbox.semantic-mediawiki.org/wiki/TestForm

Thanks and regards. --Felipe (talk) 13:44, 18 December 2018 (UTC)


 * I found the problem. In the past we wrote:
 * It should now be:
 * It should now be:


 * --Felipe (talk) 14:48, 18 December 2018 (UTC)

Composer Install of Semantic Forms 3.4.2 fails
https://github.com/BITPlan/docker-semanticmediawiki has a docker image to install an older Mediawiki/SMW and Semantic Forms version. now the issue https://github.com/BITPlan/docker-semanticmediawiki/issues/13 has come up. I seems that renaming the extension has led to this situation. How can this be fixed? --WolfgangFahl (talk) 04:49, 30 December 2018 (UTC)


 * I don't know - I know very little about Composer, or Docker. Yaron Koren (talk) 16:16, 30 December 2018 (UTC)

Field Defined with "values from property=" Limited to What's Been Used
I have a generic property called "Has payment method". This property is used by several forms.

The property has many allowed values, including: ACH Bitcoin Cash Check Credit Card

If any one of the pages that use the form is updated with a payment method, then that payment method is the only one available to any of the other forms (including the one just used).

E.g., if I select "Check" when updating one page, then any page using a form that calls this property is limited to just "Check". None of the other options appear any more.

Is this an expected behavior of properties? Would I be better off creating a "Payment Method" category, with individual pages or sub-pages for each payment method? I can see some benefit of that, as it could provide a place to keep additional information about each payment method, but my first thought was that using properties would be somehow cleaner. Now I'm not so sure.

dvicci (talk) 19:28, 31 December 2018 (UTC)


 * That's very odd. When you go to the page for that property ("Property:Has payment method"), do you see all the values there? If so - what versions of MediaWiki, SMW and Page Forms are you running? Yaron Koren (talk) 20:14, 31 December 2018 (UTC)


 * I know, right? All the values remain in the property - the form isn't altering the property at all.  All that's changing is what is being displayed.  I'm running the following:
 * MediaWiki 1.31.1
 * PHP 7.0.33-0+deb9u1 (apache2handler)
 * MariaDB 10.1.37-MariaDB-0+deb9u1
 * Semantic Forms Select 3.0.0
 * Semantic MediaWiki 3.0.0
 * Semantic Result Formats 3.0.0
 * Page Forms 4.4.2
 * Page Schemas 0.4.8
 * dvicci (talk) 20:34, 31 December 2018 (UTC)


 * This isn't a public wiki, is it? Unfortunately, I don't have development access to a wiki running SMW 3.0, and I actually rarely use any version of SMW these days. When you say the property has many allowed values, do you mean it literally defines allowed values using the "Allows value" special property? If so, it's even stranger that this would fail. Yaron Koren (talk) 21:28, 31 December 2018 (UTC)


 * Correct, this isn't a public wiki. And also correct, I'm literally defining the allowed values in the Property, e.g.  .  Under the circumstances, I think using categories may be a better option anyway, though I may struggle a bit with page name collisions.  Using subpages will get around that, but then I have the issue of potentially very long page names.  1st world problems...


 * It sounds like this is a pretty major bug with SMW 3.0, but unfortunately I don't know if I can debug it unless I get access to a wiki where this problem is occurring. Yaron Koren (talk) 18:20, 2 January 2019 (UTC)

tag 'create title' parameter not displaying parser function values correctly
I use the following info tag in my form definition:

When adding a new page using the form, on the form edit page, the form headline becomes: you|edit title=you

If i remove the parser function only from the 'create title' param it works fine (also when editing an existing page with PageForms)

Any clues why this is happening and/or how it can be fixed?

--Schtom (talk) 16:54, 2 January 2019 (UTC)

PageForms 4.4.2 and MW 1.31.1
Is PageForms 4.4.2 compatible with MW 1.31.1? I'm getting JQMIGRATE warnings in the Chrome console when I use FormEdit. Those warnings do not show up when simply viewing the page. The problem I am encountering is when using FormEdit to add multiple uploadable files to a page, clicking on the Upload button does not activate the popup for choosing files. However, the "Change file" does work for an existing file. I assume these jquery warnings are interfering with the upload function? Here is my setup:

MW 1.31.1 PageForms 4.4.2 Cargo 2.0.1 PHP 7.2.11 MySQL 8.0.13

I have tried to rule out other extensions as the problem.

Here are the JQMIGRATE warnings:

JQMIGRATE: jQuery is not compatible with Quirks Mode This page is using the deprecated ResourceLoader module "jquery.ui.widget". This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use OOUI instead. JQMIGRATE: jQuery.fn.bind is deprecated This page is using the deprecated ResourceLoader module "jquery.ui.position". JQMIGRATE: jQuery.fn.delegate is deprecated JQMIGRATE: jQuery.unique is deprecated; use jQuery.uniqueSort JQMIGRATE: jQuery.fn.removeAttr no longer sets boolean properties: disabled

Longphile (talk)


 * Those warning messages need to be dealt with (by copying jQuery UI files into Page Forms), but I don't think they're related to any actual errors. After you click on "Upload", does anything else show up in the console? Yaron Koren (talk) 14:26, 6 January 2019 (UTC)


 * I don't see anything else showing up in the console after clicking "Upload". I went back and realized that the Upload button stopped working when I started using "$wgPageFormsSimpleUpload = true;".  When I go back to the default upload function, the upload popup does work (despite the JQMIGRATE warnings still present).  So it seems to be due to the SimpleUpload feature being turned on.  Again, the SimpleUpload window does show up for an existing uploaded document but not when adding a new document.  Is this something that is fixable?  Longphile (talk) 02:42, 7 January 2019 (UTC)


 * That sounds like a bug - or maybe two bugs. And yes, I'm guessing they're fixable. Yaron Koren (talk) 18:58, 7 January 2019 (UTC)


 * I think the likely culprit is in PageForms/libs/PF_simpleupload.js. Starting with line 28, the jquery code to trigger the click on the upload button does not function because of a security issue with .trigger('click').  Here's the relevant line:

$( ".simpleupload_btn" ).click(function {                $(this).parent.find("input[type='file']").trigger('click');        });


 * There is a post in stackoverflow about this issue: https://stackoverflow.com/questions/793014/jquery-trigger-file-input.  I don't know the fix for this but hopefully this could help point you in the right direction.  Would be great if simple upload works.  Longphile (talk) 04:25, 18 January 2019 (UTC)


 * Can you please test if this works for you? https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageForms/+/487489/

Nischayn22 (talk) 13:04, 1 February 2019 (UTC)

Empty parameters in forms
I'm facing issues with empty parameters in forms. Based on my research, this problem exists since 2012 (Query parameters not passed) and I haven't come across any solution yet.

In a nutshell, if you have your template like this:

The empty values of popis4, dadav4 and Predchproc4 are parsed into the wiki article as an empty line/character. It's visible that a page section grows in length when the parameters are missing. So I tried several ways of getting rid of the issue with templates, parser functions or deleting the variable from the template definition but it did not help either - if a variable is missing from the definition, it will show up in the wiki text as " " so that's a no go either.

I'd like to ask whether there is some kind of a solution to this issue?

Thank you,

Peter


 * That doesn't sound like the 2012 problem. And actually, I'm not sure this is a forms issue at all. What does the relevant part of the template look like, though? Yaron Koren (talk) 18:59, 7 January 2019 (UTC)


 * Okay, I was playing around with it a bit and it seems like the issue is not with Page forms but with the wiki parser. I was able to resolve it using parser functions like this:
 * but I still need to fill in the form some character, in this case it is "-" that I can substitute for something else. In this case it's a paragraph " " and I added a CSS class with "display:none" attribute. It does the job. Thanks.


 * My guess is that there's a much easier way of doing what you're trying to do, but - whatever works. Yaron Koren (talk) 18:42, 8 January 2019 (UTC)

Problems generating a tree input structure using a Cargo query
Hi

I have a form that uses a tree input. Originally I had entered the tree structure as wiki text onto another page on the wiki (in this case called 'Risk Taxonomy') and was able to get it to successfully load into the tree structure using:

structure = {(:Risk Taxonomy}}

I then created a Template (in this case called 'Generate Risk Taxonomy') to generate the tree structure using a Cargo query. This generates a bulleted list in wiki code which is stripped of all HTML (I checked this with the Expand Template special page). I placed this template as the sole text in the 'Risk Taxonomy' page but now the tree input field display nothing. I also tried referencing the new template directly as follows, but this didn't work either:

structure =

I wonder if there is something else I have to do to get the tree input to load when using a cargo query to generate the structure or is this something that's not possible?

Many Thanks, Duncan (11 Jan 2019)


 * Adding "|no html" to the Cargo query may help, if you don't have it there already. Yaron Koren (talk) 21:12, 11 January 2019 (UTC)


 * Thanks Yaron, that did, indeed, solve my problem. I'd started there but removed the 'no html' when I introduced CONCAT to strip out the html code! I now see both are needed. Many thanks, Duncan 14 Jan 2018

RFE: Assigning red-link forms based on a new special-property annotating other properties
I want to make a suggestion for rather "integrated" enhancement to both SMW & PF extensions based on the following problem:

I'm using semantic-templates that render their field-values based on #ask queries, so as to have them properly formatted (think of "record/reference properties"). To apply the #formredlink: function on these formatted values, i need to pass along also the unformated valuem, or else, the 'target' parameter will not work, and this is cumbersome.

Would it make sense for PF to introduce a special-property that can annotate properties with which form to use for all their values, and retrofit the SMW-code to use that when rendering red-links?

Should i file a new RFE in github?


 * Well, Page Forms used to do it that way, back when it was called Semantic Forms - there were special properties called "Has default form" and "Has alternate form", which were applied to regular properties, among other things. I'm not planning to re-introduce them, because, among other things, they would only work when SMW is installed, and I want to keep Page Forms a more generic solution. I'm sorry that it's cumbersome, and I hope you can get everything working. Yaron Koren (talk) 17:36, 14 January 2019 (UTC)

Formlink does not return to refreshed page
In my form template Template:MyForm I included a formlink to the edit form Form:MyForm for the page:

After editing, it returns to the page where the template is included as expected, but that page does not show the update. Only after I ask my browser to refresh the page, the updated data is shown.

I tried disabling caching in the browser as well on server side, but this does not help. I removed the "link type" parameter as recommended in an old response, displaying it as a pure link only, did not work. I added a |returnto=, did not help either (in fact, if I set the returnto to some other page, that does not work either, I still return to the original page). Also, if I omit the |target=, I see an error message stating that no target page has been defined, contradicting the formlink documentation.

In one old response I saw that "returnto" seems to be used as part of the "query string", in the form "&returnto=", and not as "|returnto=" parameter to formlink. Would that help? And how should the query string then look like?

Any suggestions?

I found a solution: when I remove the "popup", it works; makes sense, witha popup, when closng the popup, the underlying page is not reloaded.


 * Sorry for the delay. If you specify "popup", there's actually a parameter called "reload" for both #formlink and #forminput, which causes the main page to reload once the popup form has been submitted. Unfortunately, this was missing from the documentation for some reason - I just added it. Please try adding the "reload" parameter, and see if that works for you. Yaron Koren (talk) 04:39, 23 January 2019 (UTC)


 * Great, that works! Thank you very much!

#formredlink does not use the invocation's query string
When I call #formredlink with both a 'query string' argument (to specify a value to prefill in the template) and the 'create page' argument to automatically create the page, the expected behavior is for the page to be auto-generated with those query string arguments specified. However, this is not the case; the page is generated with a completely blank form. EliteMasterEric (talk) 04:52, 21 January 2019 (UTC)


 * What do you mean by a blank form - is the generated page blank? Yaron Koren (talk) 04:39, 23 January 2019 (UTC)


 * The form being auto-created contains one template which powers the entire page. It contains one mandatory/hidden ID field (which I am using with other modules/templates to generate the majority of the page) and several optional Notes fields; the Page Forms extension will allow them to easily edit these fields without disturbing the rest of the template. My #formredlink call contains this mandatory ID as part of the query string.


 * By "blank form," I mean the created page contains the template associated with the form, but does not include the argument specified in the query string. This leaves the generated page as incomplete until the form is manually fixed to add the correct ID, and if I do that, there is no point in using the "create page" option at all. EliteMasterEric (talk) 15:05, 23 January 2019 (UTC)


 * Oh, I see. What does the "query string=" value look like? Yaron Koren (talk) 15:35, 23 January 2019 (UTC)


 * I have a template called  that contains  .   is replaced with the template argument, the template populated by the form is , and   uses a module to convert the name provided into the value of the mandatory ID field (which is used by other modules/templates called by Form Troop to populate the infoboxes etc in the page). Even if I replace   with a hardcoded ID, when the page is generated it only contains   even though I expect it the query string to make it   or something similar. If I don't use 'create page', clicking the link populates the ID field as expected. EliteMasterEric (talk) 03:42, 24 January 2019 (UTC)

No valid JSON response, 400 Bad Request

 * MW 1.27.5
 * PHP 7.0.32-0ubuntu0.16.04.1
 * MySQL	5.7.24-0ubuntu0.16.04.1

I'm mass uploading ~5 pages/second through MWs API. This worked fine before https://github.com/wikimedia/mediawiki-extensions-PageForms/commit/8cb76e3cd7caa28fbb218012a8a2dacf824df35c.

Since this change, I get '''400 Bad Request, Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit.'''. The error is reproducible and occurs always after ~200 pages. These pages has nothing to do with forms (in my case these are MediaWiki system messages). [E] [0218/0996] [EDIT]    Property:Subregion [E] invalidjson: No valid JSON response {   "code": "invalidjson", "info": "No valid JSON response", "response": "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n \n 400 Bad Request \n  \n Bad Request \n Your browser sent a request that this server could not understand. \nSize of a request header field exceeds server limit. \n  \n" } Error: invalidjson: No valid JSON response at rawRequest.then (C:\Users\Alex\Workspace\mobo\node_modules\mwbot\src\index.js:249:31) at tryCatcher (C:\Users\Alex\Workspace\mobo\node_modules\bluebird\js\release\util.js:16:23) at Promise._settlePromiseFromHandler (C:\Users\Alex\Workspace\mobo\node_modules\bluebird\js\release\promise.js:512:31) at Promise._settlePromise (C:\Users\Alex\Workspace\mobo\node_modules\bluebird\js\release\promise.js:569:18) at Promise._settlePromise0 (C:\Users\Alex\Workspace\mobo\node_modules\bluebird\js\release\promise.js:614:10) at Promise._settlePromises (C:\Users\Alex\Workspace\mobo\node_modules\bluebird\js\release\promise.js:693:18) at Async._drainQueue (C:\Users\Alex\Workspace\mobo\node_modules\bluebird\js\release\async.js:133:16) at Async._drainQueues (C:\Users\Alex\Workspace\mobo\node_modules\bluebird\js\release\async.js:143:10) at Immediate.Async.drainQueues (C:\Users\Alex\Workspace\mobo\node_modules\bluebird\js\release\async.js:17:14) at runCallback (timers.js:672:20) at tryOnImmediate (timers.js:645:5) at processImmediate [as _immediateCallback] (timers.js:617:5) <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> 400 Bad Request Bad Request Your browser sent a request that this server could not understand.

Size of a request header field exceeds server limit.

Can the above mentioned change be modified to be not breaking for mass uploading through API? Btw. same issue occures with current dev-master of PF as well as MW 1.31.

--Planetenxin (talk) 12:03, 21 January 2019 (UTC)


 * Sorry about that, and thanks for isolating the problem. I just checked in what I think is a fix - if you can, please get the latest code and let me know if it works better now. Yaron Koren (talk) 15:37, 23 January 2019 (UTC)


 * Thanks for having a look into this. I'll have a look at your changes and let you know. --Planetenxin (talk) 10:11, 28 January 2019 (UTC)


 * I have tested 83b17aa8710166dd3aca66c5ee4431fa559d639e which works now. Many thanks for the fix, Yaron! --Planetenxin (talk) 10:18, 30 January 2019 (UTC)

Why settings in "Project:" namespace
In The "edit with form" tab based on namespace, the method described is to save a setting in a page in the "project:" namespace.

What's the rationale behind this choice?

In the light of this namespace being used for content that is human readable, while settings intended for machine processing are usually saved in the "mediawiki:" namespace.


 * For some reason I never really thought to use the "MediaWiki:" namespace for this - now I don't remember why. This decision was made a long time ago; I'm not sure how I would do it now if I had to design it over again. Maybe a single page, in the MediaWiki: namespace, which held all of the namespace-to-form mappings in CSV format, or some such. Yaron Koren (talk) 01:46, 5 February 2019 (UTC)

editor=wikieditor not working [RESOLVED IN NEXT TOPIC]
When I use  it just shows up the same as when I don't include. How can I change this? Thanks. Jonathan3 (talk) 22:25, 3 February 2019 (UTC)

editor=wikieditor messes up tree input type [RESOLVED]
When I include  in a textarea input type, the tree input type in the same form doesn't display properly... it all shows up behind the text inputs etc, doesn't get sized, and can't be clicked on. Also, as mentioned in the topic above, the Wikieditor doesn't appear either (whether or not the tree input type is in the form). What am I doing wrong? Thank you. Jonathan3 (talk) 22:27, 3 February 2019 (UTC)

Just spotted that it prevents all Javascript from working, e.g. the tokens type. Jonathan3 (talk) 14:19, 4 February 2019 (UTC)


 * Is there a JavaScript error message in the console? And if so, could this be the same error causing the problem in the section above? Yaron Koren (talk) 14:25, 5 February 2019 (UTC)


 * Yes, I think it is the same (I just mustn't have noticed the other problems when I typed that one). Here is the error:


 * It looks the same when I use the Vector skin too. Jonathan3 (talk) 14:39, 5 February 2019 (UTC)


 * Just checked, and editor=wikieditor works fine on my test wiki... could I email you a link to my website, if necessary? Jonathan3 (talk) 14:43, 5 February 2019 (UTC)


 * Sure. By the way, does this happen every time, or only some of the time, you load the form? Yaron Koren (talk) 18:44, 5 February 2019 (UTC)


 * Every time so far (though not at all in the test wiki so I guess something else is causing the problem). 19:00, 5 February 2019 (UTC)


 * I was using an older version of Page Forms so, as you suggested, updated and it worked all right. Thanks. Jonathan3 (talk) 08:39, 6 February 2019 (UTC)

PageForms + TinyMCE: make "MinimizeOnBlur" configurable
Hi Yaron,

we are using PageForms together with TinyMCE (for textareas and free text inputs). This works really great but there is one thing that we wanted to change: the automatic hiding and showing of the TinyMCE editor controls! The thing is that first we don't like it and second it doesn't always work - on Firefox the controls get hidden but do not reappear when the field is clicked.

So I would like to propose a change to PageForms that makes this behaviour configurable. This is how I implemented it and how it works for me: diff --git a/extension.json b/extension.json index 0629870..8c388dc 100644 --- a/extension.json +++ b/extension.json @@ -460,6 +460,7 @@               ]        },        "config": { +              "PageFormsTinyMCEMinimizeOnBlur": true, "PageFormsUseDisplayTitle": true, "PageFormsSimpleUpload": false, "PageFormsMaxAutocompleteValues": 1000, diff --git a/includes/forminputs/PF_TextAreaInput.php b/includes/forminputs/PF_TextAreaInput.php index 4a67809..cb7e42b 100644 --- a/includes/forminputs/PF_TextAreaInput.php +++ b/includes/forminputs/PF_TextAreaInput.php @@ -70,7 +70,12 @@ class PFTextAreaInput extends PFFormInput { $this->mEditor = 'tinymce'; global $wgTinyMCEEnabled; $wgTinyMCEEnabled = true; +                       $newClasses = 'mceMinimizeOnBlur'; +                      global $wgPageFormsTinyMCEMinimizeOnBlur; +                      if ( $wgPageFormsTinyMCEMinimizeOnBlur == false ) { +                              $newClasses = ''; +                      }                        if ( $input_name != 'pf_free_text' && !array_key_exists( 'isSection', $this->mOtherArgs ) ) { $newClasses .= ' mcePartOfTemplate'; } Now if I add  to my LocalSettings.php the TinyMCE controls stay visible all the time.

What do you think? Are you willing to include this into your code?

Greetings

HermannSchwärzler (talk) 09:33, 4 February 2019 (UTC)

Unchecking doesn't work in sub-items
Hello,

I use Page Forms to enter new words in this Dictionary. When I edit words to change the category (for example https://dicoado.org/wiki/index.php?title=dilemme&action=formedit). I have to uncheck the selected one and check another one. If the new category is a subcategory (which is listed as a sub-item), the unchecking isn't registered and I get two categories : the subcategory and the main one (that was previously used on that word).

Any idea how to correct this ?

Thanks.

--DSwissK (talk) 06:26, 5 February 2019 (UTC)


 * I'm not exactly sure what the problem is, but you're using a somewhat old version of Page Forms. Maybe upgrading will fix the problem? Yaron Koren (talk) 14:17, 5 February 2019 (UTC)


 * Updated to 4.4.2, it works now. Thanks ! :) Is there a changelog anywhere ? I couldn't find it. DSwissK (talk) 13:41, 6 February 2019 (UTC)
 * Nevermind, there it is : https://www.mediawiki.org/wiki/Extension:Page_Forms/Version_history DSwissK (talk) 13:43, 6 February 2019 (UTC)

Tree input type has two check boxes per item in Foreground skin
There's a  (which should appear, I think), a   (which I don't think adds anything), and within   there's an   (which I imagine should be hidden but isn't).

When you click on the left box, it ticks both boxes. When you tick on the icon it does nothing. When you click on the right box it ticks the left box (but not the right box itself). When you click on the title text it ticks both boxes.

It works fine when I use the Vector skin, so I guess there's something about the Foreground skin that's causing the problem. Maybe it does something different with the a  class? When I add style="display:none" to the input tag it works the way it should. Any ideas? Thanks. Jonathan3 (talk) 08:55, 6 February 2019 (UTC)

Lines 201-207 of PF_TreeInput.php make the checkbox look like :

Lines 448-451 of foreground.css sets, which seems to prevent Page Forms from using   and   to make it  :

It's possible to get round this by adding the following to Common.css:

An alternative is to add the following to the Page Forms code on line 205 above:

I'm using an old version of the Foreground skin - 1.2.0 (44667e9) - so I don't think they'd change the skin just for this. Maybe you have similar views about your code! :-) Jonathan3 (talk) 21:17, 6 February 2019 (UTC)


 * I'm happy to add more CSS to Page Forms, if it doesn't break anything else... but why are you using an old version of the Foreground skin? Maybe this problem no longer exists in the current version? Yaron Koren (talk) 00:45, 7 February 2019 (UTC)


 * Thanks. I'm postponing upgrading the skin until I finally upgrade MediaWiki (which entails rewriting some PHP 5 code that's on the same website)... Jonathan3 (talk) 12:06, 7 February 2019 (UTC)


 * I now have the latest version of PF and Foreground and the same problem arises (and can be dealt with in the same way). Jonathan3 (talk) 23:49, 10 February 2019 (UTC)

Line returns within checkboxes and radiobutton input type
I'm sure that someone asked how to add line returns within the radiobutton input type (as otherwise the options appear one after the other, like a paragraph). But I can't find the question now... Anyway, this should work, in MediaWiki:Common.js, though I guess it may have unintended consequences (I don't know how whether the class is used elsewhere in MediaWiki):

Jonathan3 (talk) 14:07, 6 February 2019 (UTC)

I found the original question, on the main Page Forms page, and will cut and paste it below: Jonathan3 (talk) 21:27, 6 February 2019 (UTC)

QUESTION [SOLVED]: Default behavior produces an inline list of checkboxes. How does one force a "break" after each option to result in a left justified listing? User:rkevans Me too. Tenbergen (talk) 19:16, 5 February 2019 (UTC)
 * SOLUTION - to making checkboxes display in list for is by css found here: http://smw.referata.com/wiki/Display_form_checkboxes_in_an_orderly_table .. see also: http://smw.referata.com/wiki/Category:Tips :-)

update on cross-template (spreadsheet-like) editing
With SMW & Page Forms & SRF - is it possible to generate a semantic results table that is editable like a spreadsheet.. and hit save on the whole query?

I have users who like to edit a standard wikitable in VE because they can edit and save the whole thing at once.. but I'd like that data to be the result of a Semantic query (format=wikitable) which requires them to visit a different page to edit each rows data.. is it possible to have it both ways somehow?

(word on the street is that Yaron is working on this capability.. Any truth to that User:Yaron Koren? :-)


 * Check out the page Special:MultiPageEdit for something sort of like what you're asking about. Yaron Koren (talk) 01:30, 8 February 2019 (UTC)

Datepicker limits selectable year
Unless I can't figure something out, when I use the datepicker, by default it seems to limit the years available to ±10 years (2009-2029) and there doesn't seem to be a way to extend the range using the scroll bar. Using the parameters values, first date, or last date to modify the range only allows me to further limit the range. Once a date is selected though, the year can then be modified in the text area and then the scroll bar will have a new range around the new selection (±10 years). --Bryandamon (talk) 10:50, 17 February 2019 (UTC)

DatePicker will not popup Resolved

 * Mediawiki 1.32 php7.0 I have tried multiple skins and versions of pageforms via git or extension distributor.  I cannot get the datepicker to pop up, it appears a a basic text field.  When I inspect the page I get a bunch of jquery.ui messages in yellow, and the following in red Uncaught TypeError: initFunction is not a function.  Everything was working flawlessly in 1.29 so I am assuming its not an issue with syntax. Blyoak (talk) 23:06, 21 February 2019 (UTC)
 * This started working today with the latest iteration of pageforms, however autocomplete based on values from namespace stopped working 192.12.184.7 17:23, 26 February 2019 (UTC)
 * switching from text with autocomplete to combobox has fixed the autocomplete.


 * Great! I'm guessing that it started working due to the fix from yesterday. I can't reproduce that problem with "values from namespace", though. Do you see any error messages in the JavaScript console when that happens? Yaron Koren (talk) 20:29, 26 February 2019 (UTC)

Datetime input type and Foreground 2.1.0 skin [RESOLVED]
Originally each of the six fields showed up stacked on top of each other, with the hours-minutes-seconds each being 100% width. The following seems to fix it, in Common.css (though there may be better ways):

Best wishes, Jonathan3 (talk) 14:20, 23 February 2019 (UTC)


 * Do you know if this CSS change works fine with other skins, most notably Vector? Yaron Koren (talk) 17:17, 25 February 2019 (UTC)

Update on issue saving form with hotkey after previewing issue
A while ago I reported an issue that when you edit a form page (e.g. Form:Infobox Player), and then preview it, and press Alt+Shift+S, it won't actually save the page - you thought it was a Gamepedia-only problem, but it turns out I think that it's a Firefox-only problem, it works fine for us in Chrome.

Steps to reproduce - make any page in Form namespace, then preview, then press Alt+Shift+S. I think that the save button from the form's preview is interfering with the save of the form itself. --RheingoldRiver (talk) 11:15, 28 February 2019 (UTC)

Cannot get autoedit to work. Strange error on namespace and not updating
I am trying to use autoedit to update a page with no success. This is the an example where I have hardcoded the write to test it. First I put this:



CN00002 is in the main namespace, but I get this error: "Error: Invalid namespace ""; only content namespaces are allowed for #autoedit." .

So I give the the path to the page I want to edit like so:



That clears the error with the content namespace issue, but doesn't carry out the update. So the form "Manage Company" is the form I used to create the page, the target is the page name and the template is called "Manage Company". The template variable is called "companyname" and is the cargo table field name too, although I appreciate the cargo element should be irrelevant. I've tried "form=Manage_Company" as I thought it might not like spaces. I tried setting up a form name with no spaces, with no success. Michaeldakin (talk) 20:36, 3 March 2019 (UTC)


 * The second of those definitely won't work. The first one should work, though. Have you modified $wgContentNamespaces in LocalSettings.php? Yaron Koren (talk) 19:00, 4 March 2019 (UTC)


 * No I haven't changed $wgContentNamespaces in LocalSettings.php. I am on a wikifarm (Miraheze), so I don't have access to change it. I can follow up with Miraheze and see if they have being doing anything. Although they are very good, so I can't imagine they will have done anything like that. Let me go check my other Wiki on Miraheze and get back to you. Interestingly I have noticed that the two wikis have some differences that I wouldn't have expected. For example on one wiki the php setting allows me to use to completely change the title, while the other wiki works in the Parser out of the box way, where you can only change capitalisation. Michaeldakin (talk) 19:42, 4 March 2019 (UTC)

Upload file (Special:UploadWindow) and MediaWiki 1.31.0+
Ran into an issue trying to upload images from a Page Form in MW 1.32.0. The pop-up window would throw a ConfigException. Turns out that EnableAPI was deprecated in MW 1.31.0 and removed in 1.32.0. I commented out the check for that config setting on line 350 of PF_UploadForm.php to get it up and running for me at the moment but wanted to pass the info along to you for a proper fix. Thanks for the incredibly useful extensions!