Extension talk:Page Forms

From MediaWiki.org
Jump to navigation Jump to search


Include SMW inline query in info tag "page name" parameter?[edit]

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 (<GuidelineArticle[FieldnameXy]>) AND
  2. the result of an SMW inline query {{#show:{{{Fieldname|}}}|?PropertnameXy}}

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

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()/ @Yaron Koren: 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, @Yaron Koren:, 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?[edit]


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

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 data-stat="Strength" for each field, particularly for dropdowns but also in general. Could something like |attr=stat,att2,att3|attr_values=Strength,val2,val3 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[edit]

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.[edit]

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


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

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

{{{for template|Prize}}}
{| class="formtable"
! Pick you sweet prize!
|{{{field|sweetPrize|values from category=Sweets|mapping cargo table=sweets|mapping cargo field=sweetName}}}
{{{end template}}}</nowiki>

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

<option value="M&amp;amp;Ms">M&amp;amp;Ms</option>

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
78 		foreach ( $possible_values as $possible_value ) {
79 			$optionAttrs = array( 'value' => $possible_value );
80 			if ( $possible_value == $cur_value ) {
81 				$optionAttrs['selected'] = "selected";
82 			}
83 			if (
84 				array_key_exists( 'value_labels', $other_args ) &&
85 				is_array( $other_args['value_labels'] ) &&
86 				array_key_exists( $possible_value, $other_args['value_labels'] )
87 			) {
88 				$label = $other_args['value_labels'][$possible_value];
89 			} else {
90 				$label = $possible_value;
91 			}
92 			$innerDropdown .= Html::element( 'option', $optionAttrs, $label );
93 		}

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.

78 		foreach ( $possible_values as $possible_value ) {
79 // prevent double-encoding, value has already been HTML-encoded 
80 // and it will get encoded again by Html::element() - 
81 $possible_value = html_entity_decode( $possible_value );
82 			$optionAttrs = array( 'value' => $possible_value );
83 			if ( $possible_value == $cur_value ) {
84 				$optionAttrs['selected'] = "selected";
85 			}
86 			if (
87 				array_key_exists( 'value_labels', $other_args ) &&
88 				is_array( $other_args['value_labels'] ) &&
89 				array_key_exists( $possible_value, $other_args['value_labels'] )
90 			) {
91 				$label = $other_args['value_labels'][$possible_value];
92 			} else {
93 				$label = $possible_value;
94 			}
95 			$innerDropdown .= Html::element( 'option', $optionAttrs, $label );
96 		}

If $label also needs decoding on line 91 maybe changing

$innerDropdown .= Html::element( 'option', $optionAttrs, $label );


$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[edit]


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.


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

Semantic extensions
Extension Version Licence Description Authors
Semantic Drilldown 2.0.2 (2252e92)06:10, 14 April 2018 GPL-2.0-or-later A drilldown interface for navigating through semantic data Yaron Koren and others
Semantic Forms Select 2.2.0-alpha GPL-2.0-or-later Allows to generate a select field in a form whose values are retrieved from a query Jason Zhang, James Hong Kong, Toni Hermoso Pulido, Thomas Mulhall and others
Semantic Internal Objects 0.8.2 (2b195cf)04:25, 10 March 2018 GPL-2.0-or-later Setting of internal objects in Semantic MediaWiki Yaron Koren

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

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

Uncaught TypeError: initFunction is not a function
    at HTMLDocument.<anonymous> (PageForms.js?18121:330)
    at mightThrow (load.php?debug=true&lang=en-gb&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=0ri47ih:3583)
    at process (load.php?debug=true&lang=en-gb&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=0ri47ih:3651)

the offending line in PageForms.js is

330     $(function() {initFunction ( input.attr("id"), param );});

called from (in PageForms.js)

1530     	$( '#' + inputID ).PageForms_registerInputInit( getFunctionFromName( initFunctionData[ inputID ][ i ][ 'name' ] ), initFunctionData[ inputID ][ i ][ 'param' ] );

with a param of null in this...

Pd free text.png

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?[edit]

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. -- 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". -- 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. -- 21:33, 7 November 2018 (UTC)

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

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

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

Perhaps this is also related to HeaderTabs. This is why I incuded the info, too. Cheers --[[kgh]] (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. --[[kgh]] (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[edit]


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

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

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;
#content .form-ip-year .select2-container{
  width: 100px;

#content .form-ip-month .select2-container{
  width: 120px;

#content .form-ip-day .select2-container{
  width: 70px;

.form-ip-day, .form-ip-month, .form-ip-year {

--RheingoldRiver (talk) 01:42, 29 November 2018 (UTC)

Issue with PHP 7.2[edit]

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

Hello. It seems that editor=wikieditor 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:
{{{field|test|input type=textarea|rows=20|editor=wikieditor}}}
--Felipe (talk) 14:48, 18 December 2018 (UTC)

Composer Install of Semantic Forms 3.4.2 fails[edit]

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

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. Allows value::Cash. 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)

{{{info}}} tag 'create title' parameter not displaying parser function values correctly[edit]

I use the following info tag in my form definition:

{{{info|create title={{#explode:And if you tolerate this| |2}}|edit title={{#explode:And if you tolerate this| |2}}|page name=Test}}}

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

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 () {
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[edit]

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:

|vstup4=Some value      
|Predchproc4= {{Nothing}}

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 "{{variablename}}" 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,


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:
{{#ifeq:{{{dodav4}}} |-| <p class="dontshow"></p> | {{{dodav4}}} }} 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 "<p class="dontshow"></p>" 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[edit]


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 = {{:Generate Risk Taxonomy}}

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

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

In my form template Template:MyForm I included a formlink to the edit form Form:MyForm for the page:

{{#formlink:form=MyForm |link text=edit this page |link type=post button |tooltip=Edit "{{PAGENAME}}" |target={{PAGENAME}} |popup }}

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={{PAGENAME}}, 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={{PAGENAME}}, 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[edit]

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 {{Link Troop}} that contains {{#formredlink:target={{{1|}}}|form=Troop|link text={{{1|}}} (create page)|create page|query string=Form_Troop[id]={{Troop Id|name={{{1|}}}}}}}. {{{1}}} is replaced with the template argument, the template populated by the form is {{Form Troop}}, and {{Troop Id}} 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 {{Troop Id}} with a hardcoded ID, when the page is generated it only contains {{Form Troop}} even though I expect it the query string to make it {{Form Troop|id=1234}} 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[edit]

  • 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<html><head>\n<title>400 Bad Request</title>\n</head><body>\n<h1>Bad Request</h1>\n<p>Your browser sent a request that this server could not understand.<br />\nSize of a request header field exceeds server limit.</p>\n</body></html>\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)
<title>400 Bad Request</title>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Size of a request header field exceeds server limit.</p>

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

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

When I use {{{field|...|input type=textarea|mandatory|rows=2|autogrow|editor=wikieditor}}} it just shows up the same as when I don't include editor=wikieditor. How can I change this? Thanks. Jonathan3 (talk) 22:25, 3 February 2019 (UTC)

editor=wikieditor messes up tree input type [RESOLVED][edit]

When I include editor=wikieditor 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:
TypeError: Cannot read property 'wikieditor' of undefined TypeError: Cannot read property 'wikieditor' of undefined
    at getFunctionFromName (eval at <anonymous> (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:4), <anonymous>:167:448)
    at HTMLDocument.eval (eval at <anonymous> (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:4), <anonymous>:167:765)
    at fire (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:45)
    at Object.add [as done] (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:45)
    at jQuery.fn.init.jQuery.fn.ready (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:49)
    at eval (eval at <anonymous> (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:4), <anonymous>:167:250)
    at mw.loader.implement.css (eval at <anonymous> (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:4), <anonymous>:168:501)
    at Object.<anonymous> (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:161)
    at fire (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:45)
    at Object.add [as done] (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=0x4orro:45)
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[edit]

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 $wgPageFormsTinyMCEMinimizeOnBlur = false; 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?


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

Unchecking doesn't work in sub-items[edit]


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 ?


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

There's a span.fancytree-checkbox (which should appear, I think), a span.fancytree-icon (which I don't think adds anything), and within span.fancytree-title there's an input#chb-Table-Field-key-n-n-n.hidden (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 hidden 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 <input ... class="hidden" hidden ...>:

			$nodeAttribs = array(
				'tabindex' => $wgPageFormsTabIndex,
				'id' => "chb-$key_id",
				'class' => 'hidden',

Lines 448-451 of foreground.css sets display:inline, which seems to prevent Page Forms from using class="hidden" and hidden to make it display:none:

input[type="checkbox"] {

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

input[type="checkbox"].hidden {

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

				'style' => 'display:none',

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

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

$( "label.radioButtonItem" ).after( "<br/>" );

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

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)