Extension talk:Page Forms/Archive January to February 2019

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

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)

FYI, Schtom created patch to fix this, which was checked in a few weeks ago. Yaron Koren (talk) 21:07, 4 March 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:

{{Proces
|vstup4=Some value      
|popis4=      
|dodav4=      
|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,

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:

{{#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

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

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:

{{#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

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

• 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)
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<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>
</body></html>

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 {{{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]

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

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?

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 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',
				'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="radio"],
input[type="checkbox"] {
  display:inline;
}

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

input[type="radio"].hidden,
input[type="checkbox"].hidden {
  display:none;
}

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)

Thanks for letting me know; your suggested fix was just checked in to Page Forms. Yaron Koren (talk) 20:50, 4 March 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):

$( "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

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 or tokens 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)

I see a lot of deprecated ResourceLoader module, and a Uncaught ReferenceError: mwTinyMCEInit is not defined. These errors are constant on all forms though, not just ones with values from namespaces. 192.12.184.7 18:01, 11 March 2019 (UTC)

I am updating with composer these days; when I just ran a composer update, no update to pageforms came down. Do I misunderstand that composer should get these updates? Tenbergen (talk) 17:11, 8 March 2019 (UTC)

I don't know how Composer works; maybe someone else does. Yaron Koren (talk) 17:21, 8 March 2019 (UTC)

I believe that the most recent updates are from Git. I would recommend using this for Pageforms. 192.12.184.7 18:01, 11 March 2019 (UTC)

Yes - I've only used composer for the vendor directory, not for extensions, but Page Forms here seems not to have the latest version. Jonathan3 (talk) 22:56, 25 March 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):

.dayInput, 
.monthInput, 
.yearInput,
.hoursInput,
.minutesInput,
.secondsInput,
.ampmInput {
    display: inline !important;
    width: inherit !important;
}

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)

Sorry for the delay. I've checked with &useskin=vector and it works fine. (It worked fine to begin with on Vector, but the CSS to get it working on Foreground hasn't broken it on Vector.) Jonathan3 (talk) 14:54, 25 March 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)