Extension talk:Page Forms/Archive April to June 2020

Improve "checkboxes" input type

In a form I made has a for template field has 26 values for while set to use input type checkboxes. When rendered at certain resolutions, the checkbox and value can be broken by a line break. Prehaps surround the checkbox and corresponding value with "white-space:nowrap" CSS?

Also, it might be worth looking into setting up columns or some form of separation, so it's easier to differentiate which checkbox goes to which value.

SageVarq (talk) 16:23, 12 April 2020 (UTC)

Hi - are you using the very latest Page Forms code? About a month ago, the display of the checkboxes input type was improved. I just want to make sure you're looking at the current state of the input. Yaron Koren (talk) 02:36, 13 April 2020 (UTC)

My apologies, it seems the site I'm using isn't updated to the latest version (v4.5.1 vs. v4.8). I'll try contacting the admins to see if we can get it updated.SageVarq (talk) 03:35, 13 April 2020 (UTC)

Gerrit change 561990 breaks MW 1.29 compatibility

Hi Yaron, Gerrit change 561990 replaces \MediaWiki\suppressWarnings() with Wikimedia\suppressWarnings(), which doesn't exist in MW 1.29 - it still uses at-ease 1.1.0. This also seems to apply to MW 1.30, which uses the same version of the library.

I can see a couple of options going forward:

• Remove support for MW 1.29 (and 1.30, I assume)
• Add another lovely elseif - try both "Wikimedia\SuppressWarnings()" and "MediaWiki\SuppressWarnings()".

While option number 2 is good for me personally, I think it would make more sense to drop support for MW 1.29 and 1.30, as both are EOL.

What do you think?

Thanks for letting me know about that; I remember wondering how far back Wikimedia\suppressWarnings() went. I went with a third option, which was to replace the Wikimedia\suppressWarnings() fallback with \MediaWiki\suppressWarnings(). Hopefully all the supported versions are now truly supported... although maybe it doesn't matter that much, since no one complained about it until now, which suggests that no one is using those MediaWiki versions anyway! Yaron Koren (talk) 01:16, 20 April 2020 (UTC)

As always, thanks for the quick reponse, Yaron! I thought that would cause you to lose compatibility with MW 1.34, because it uses at-ease 2.0.0, but I now see that while it removes the MediaWiki namespace, it adds the AtEase namespace too - so that works out. I guess nobody should be using MW 1.29, me included, but I am... so thanks for that!

Oh, I didn't understand that you're using MW 1.29. Well, I'm glad to hear it works! Yaron Koren (talk) 14:54, 20 April 2020 (UTC)

"Simple upload" option

Hi all, I checked out the option "$wgPageFormsSimpleUpload = true;" in my wiki since I have issues with the standard Java based file upload dialogue. The problem that I have with this is as follows: In many cases I actually don't upload the file when using the form, but I paste the name of an available file into the text field in front of the "Upload file" link. Obviously this is only possible with the standard Java based file upload but not with the simple upload option!? At least I only see an upload button and no text field to paste something into. Is there any way to change this for the simple upload option?

Thanks & kind regards, Tom

That's an interesting question - it would require some coding, but it's probably possible. (It's JavaScript, by the way, not Java.) Yaron Koren (talk) 21:40, 29 April 2020 (UTC)

Pass parameter from URL in query string?

Hi Yaron, thanks for all your work and support. You give so much to the MediaWiki community!
We use #forminput together with query string=. We have external data that needs to go into the form. This data is given to the form by means of a URL parameter (domain.com/wiki/Form:TheForm?Parameter=ExternalData). Is there any way we can pass ExternalData in the query string - is this possible with some additional JavaScript? I could hire a coder for that, but I'm not sure the Wiki syntax allows interventions at that point...
--Stefahn (talk) 09:15, 30 April 2020 (UTC)

What do you mean by "external data"? Yaron Koren (talk) 15:34, 30 April 2020 (UTC)

[OPEN] #formlink using "popup" option freezing

I'm using:

• Page Forms Page Forms 4.6 (95fc81e) 02:29, 4 October 2019 with
• MediaWiki 1.34.1 (3bdc458) and SAML SSO Integration via
• PluggableAuth 5.7 (17fb1ea) 03:20, 13 September 2019 and
• SimpleSAMLphp 4.5 (e6154d8) 03:31, 25 August 2019

and I use the "popup" feature of the "formlink" parser function provided by Page Forms.

The problem I'm reporting here is that more that 50% of the time, when someone clicks on a popup formlink, it always starts the popup process of greying the screen and showing the swirling "loading" icon, but 50% of the time it just hangs there and the form page never pops. There is also no way to cancel except to refresh the page.

Is this a sessions issue maybe?

It's a bummer because it makes the whole popup feature unusable because it's not reliable.

I Hope there is a simple explanations and remedy to this.

/Rich

I would try upgrading to the latest version of Page Forms - maybe this is no longer an issue; I don't know. Yaron Koren (talk) 15:36, 30 April 2020 (UTC)

Are you advocating that I use the master branch? /Rich

Sure, although you can also just download version 4.8 if you prefer. Yaron Koren (talk) 17:38, 30 April 2020 (UTC)

Actually, by coincidence, I just released version 4.9 - you should get that instead. Yaron Koren (talk) 19:03, 30 April 2020 (UTC)

Upgrading to 4.8 seems to have made the pop form reliable. Thx. I'll upgrade to 4.9 in the next planned upgrade cycle. Thanks Yaron! - Revansx (talk) 13:19, 1 May 2020 (UTC)

Still having his issue - Revansx (talk) 16:20, 24 May 2020 (UTC)

[SOLVED] Issue with #autoedit not working in MW34

Can anyone confirm that #autoedit works in MW34and Page Forms 4.6 (95fc81e) 02:29, 4 October 2019 without any implementation or permission changes ffrom MW31?

It appears to work. It generates the confirmation message in the page it is in, but there are no edits being made.

The exact code used to work on my MW 31 site and now doesn't on MW 34.

Please advise :-)

I would try a more recent version of Page Forms. Yaron Koren (talk) 17:39, 30 April 2020 (UTC)

I upgraded to PF 4.8, but it turns out that that wasn't the issue. Turns out I discovered that autoedit only works on properties already defined in the form. If the {{{field|... doesn't exist the autoedit will execute with a false positive and no actual edit. Adding thee desired field to the form solved this issue. Now I know. Cool. Thanks! - Revansx (talk) 04:32, 1 May 2020 (UTC)

[OPEN] Automatic jump to top of form when selecting fields using popups

I'm using:

• MediaWiki 1.34.1 (3bdc458) with
• Page Forms Page Forms 4.8

and I use #formlinks with the "popup" option.

My forms are often longer than will fit in the popup display window and so it's great the users can scroll down the form in the popup window.

The issue is that when a user selects a field, the form automatically scrolls back up to the top of the form which makes it impossible for users to keep their place in editing the form.

Is anyone else experiencing this?

Any obvious causes or solutions? - Revansx (talk) 13:26, 1 May 2020 (UTC)

This is very strange behavior. Are you saying that, as soon as a user clicks on an input, the form scrolls up? Does this happen for every input type? Yaron Koren (talk) 15:12, 1 May 2020 (UTC)

Yes. Every input type. I have isolated it to only happening when I use the Metrolook Skin. There is some odd interaction between Skin:Metrolook and Page Forms Popups - It's got something to do with "User agent stylesheets" from dynamic CSS that gets added when I click on the element. The CSS is: ":focus { outline: -webkit-focus-ring-color auto 1px; }

fwiw, I've created a live public demo page to show this bug at https://emw-meza.site/fbtest/Metrolook_PF_Popup_Issue
and I've submitted a bug to Metrolook in phabricator at https://phabricator.wikimedia.org/T251679
-- That said, I'm not sure if this is a bug in metrolook or if the there is attribute that could be added to the formlink popup iframe that would be the best solution to the issue? - Revansx (talk) 14:09, 2 May 2020 (UTC)

[SOLVED] Hierarchy in PageForms

Dear all, I am using PageForms & PageSchemas to create a questionnaire. This questionnaire will be quite detailed, so I would like to build a hierarchy of questions, subquestions, etc... Playing with it for a while (using sections and templates), I don't think this is possible (or am I wrong ?) Additionally, is it possible to control how sections and templates are numbered in the TOC? ie, I wish that some templates and fields not be numbered?

In short, I have difficulty understanding how the form's hierarchy is rendered. Ta.

What is it that you think won't work? And if there's a section that you don't want included in the TOC, give its header an HTML tag, like "<h2>My section</h2>" instead of "==My section==". Yaron Koren (talk) 13:33, 5 May 2020 (UTC)

Thanks. Yes I just thought about this. But:

• fields in templates are still numbered in TOC, irrespective of "being" in a section, is this correct? (as you can see, I am not --yet-- very familiar with PageForms)
• I still don't understand how hierarchy is formed: suppose I build a form as

- add section level 1

- add template A

- add section level 2

- add template B

• It appears that template B still is shown at level 1, and not at level 2.

ok, my apologies, I now understand how TOC is formed for templates/fields.

so I am still left with my second question about hierarchy. Thanks.

Is there a specific form you tried creating, which led to problems? If so, could you put the form definition in pastebin, and link to it here? Yaron Koren (talk) 15:24, 5 May 2020 (UTC)

here it is: https://pastebin.com/jj1pA6d9 . Thanks a lot in advance, I am obviously missing something. I can't even get the TOC numbering working (;) ). Cheers.

Okay, thanks. In general, it's not a good idea to alternate between templates and sections - I'm not sure that that's what is causing the issues you're seeing, but it can lead to problems when editing existing pages with the form. But it may be easier - for both editing and display - to avoid section tags altogether, and just use templates. You can have the templates add their own section headers to the page. Yaron Koren (talk) 16:53, 5 May 2020 (UTC)

Thanks for this. Will do.

I eventually managed to achieve what I was looking for; see https://pastebin.com/3GtPAYzV . Thanks!

Very clever! I'm glad you got it working with Page Schemas, since it's not that flexible a system. Yaron Koren (talk) 13:29, 7 May 2020 (UTC)

[SOLVED] RunQuery ERROR due to URL length

I'm using "Special:RunQuery" [1] to provide Query filter options for a run query I have implemented and I'm running into a problem where the query is failing when I search due to limitation of the URL string length from either the browser or the server (or both!) .. the total length of the RunQuery URL is turns out to be: ( (the form name length) + (property names lengths) + (value string lengths) times the number of fields). Turns out this recipe makes it easy to exceed the 8,000 character limit of the URL max string length resulting in an apache error.

The wisdom of the web says that the problem is likely that the form is using the GET method rather than the POST method.

My question is:

• What method does the RunQuery Form Link use? GET? or POST?
• What do the authors of this extension recommend?

- Revansx (talk) 17:21, 5 May 2020 (UTC)

[1] https://www.mediawiki.org/wiki/Extension:Page_Forms/Creating_query_forms#Preloading_data_in_the_query

Special:RunQuery uses GET. I wouldn't say it's easy to exceed 8000 characters in the query string, but it's certainly possible. Out of curiosity, how many fields do you have in the query form? Yaron Koren (talk) 17:29, 5 May 2020 (UTC)

About 30 in all - Revansx (talk)

https://mysite.nasa.gov/w/index.php?title=Archived_Record_Search_(XAR)
&pfRunQueryFormName=XAR
&XAR%5BFinds+Building%5D=1234
&XAR%5BShows+Building%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Building%5D%5Bvalue%5D=1
&XAR%5BFinds+Room%5D=
&XAR%5BShows+Room%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Room%5D%5Bvalue%5D=1
&XAR%5BFinds+File+Cabinet%5D=
&XAR%5BShows+File+Cabinet%5D%5Bis_checkbox%5D=true
&XAR%5BShows+File+Cabinet%5D%5Bvalue%5D=1
&XAR%5BFinds+File+Cabinet+Drawer%5D=
&XAR%5BShows+File+Cabinet+Drawer%5D%5Bis_checkbox%5D=true
&XAR%5BShows+File+Cabinet+Drawer%5D%5Bvalue%5D=1
&XAR%5BFinds+File+Cabinet+Drawer+File+Folder%5D=
&XAR%5BShows+File+Cabinet+Drawer+File+Folder%5D%5Bis_checkbox%5D=true
&XAR%5BShows+File+Cabinet+Drawer+File+Folder%5D%5Bvalue%5D=1
&XAR%5BFinds+Description%5D=
&XAR%5BShows+Description%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Description%5D%5Bvalue%5D=1
&XAR%5BFinds+Contents%5D=
&XAR%5BShows+Contents%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Contents%5D%5Bvalue%5D=1
&XAR%5BFinds+Record+Year%5D=
&XAR%5BShows+Record+Year%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Record+Year%5D%5Bvalue%5D=1
&XAR%5BFinds+Record+Author%5D=
&XAR%5BShows+Record+Author%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Record+Author%5D%5Bvalue%5D=1
&XAR%5BFinds+Contract%5D=
&XAR%5BShows+Contract%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Contract%5D%5Bvalue%5D=1
&XAR%5BFinds+Status%5D=
&XAR%5BShows+Status%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Status%5D%5Bvalue%5D=1
&XAR%5BFinds+Reviewers+Notes%5D=
&XAR%5BShows+Reviewers+Notes%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Reviewers+Notes%5D%5Bvalue%5D=1
&XAR%5BFinds+Reviewers+Rating%5D=
&XAR%5BShows+Reviewers+Rating%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Reviewers+Rating%5D%5Bvalue%5D=1
&XAR%5BFinds+Document+Admins+Notes%5D=
&XAR%5BShows+Document+Admins+Notes%5D%5Bis_checkbox%5D=true
&XAR%5BShows+Document+Admins+Notes%5D%5Bvalue%5D=1
&XAR%5BResults+Sorted+By%5D=Modification+date
&XAR%5BResults+Order%5D=desc
&XAR%5BFinds+Max+Results%5D=20
&pf_free_text=
&wpRunQuery=Run+query

It's strange that each checkbox leads to three query string values on your system - for me, it only leads to two. It might be some Apache configuration. Anyway, you could shorten all the field names, but at some point you'd run into this same maximum limit anyway. The only real solution, I think, is to allow Special:RunQuery to use POST instead of GET, as you suggested. You could try it on your system and see if that approach works for you - you just need to change "get" to "post" around line 140 of /specials/PF_RunQuery.php. Yaron Koren (talk) 20:11, 5 May 2020 (UTC)

Yes, That worked! Thank you! - Revansx (talk) 21:24, 5 May 2020 (UTC)

Do you think you'll update the official version to use POST now? I don't have access to gerrit, so I made this patch in github for you: https://github.com/wikimedia/mediawiki-extensions-PageForms/pull/4/commits/08dd2b9ddddd3af4d16dfc49a51793e0602ce2d9

I'm glad that worked for you. No, I'm not planning to change it to POST, but I might add a configuration option to let admins do it - or maybe better yet, a form parameter, like "query form at top". Yaron Koren (talk) 22:10, 5 May 2020 (UTC)

A form parameter that defaults to GET would be ideal. Until then I have to track a local change, and that's never fun with meza ;-) - Revansx (talk) 00:36, 6 May 2020 (UTC)

Error from line 599 of ... /extensions/PageForms/includes/PF_ParserFunctions.php: Call to a member function getTimestamp() on null

I updated some of my wikis last night, new versions are MW1.34.1 (b1f6480), SMW3.1.6, Cargo 2.5 (4a45c7a), PF 4.9. Two wikis both run overnight maintenance scripts that include calls to SMW rebuildData, Cargo cargoRecreateData and mediawiki RebuildAll. Last night, the maintenance scripts ran without error on one wiki, but threw variations of the following error when running each of these rebuild scripts:

[baf8de625274fbe257cabbd4] [no req] Error from line 599 of /home/.../extensions/PageForms/includes/PF_ParserFunctions.php: Call to a member function getTimestamp() on null

Backtrace:

1. 0 /home/.../includes/parser/Parser.php(3816): PFParserFunctions::renderAutoEdit(Parser, string, string, string, string, string, string, string, string)

rest of stack trace

1 /home/.../includes/parser/Parser.php(3519): Parser->callParserFunction(PPTemplateFrame_Hash, string, array) 2 /home/.../includes/parser/PPFrame_Hash.php(254): Parser->braceSubstitution(array, PPTemplateFrame_Hash) 3 /home/.../includes/parser/Parser.php(3697): PPFrame_Hash->expand(PPNode_Hash_Tree) 4 /home/.../includes/parser/PPFrame_Hash.php(254): Parser->braceSubstitution(array, PPFrame_Hash) 5 /home/.../includes/parser/Parser.php(3330): PPFrame_Hash->expand(PPNode_Hash_Tree, integer) 6 /home/.../includes/parser/Parser.php(1489): Parser->replaceVariables(string) 7 /home/.../includes/parser/Parser.php(593): Parser->internalParse(string) 8 /home/.../extensions/Cargo/includes/CargoUtils.php(564): Parser->parse(string, Title, ParserOptions) 9 /home/.../extensions/Cargo/maintenance/cargoRecreateData.php(162): CargoUtils::parsePageForStorage(Title, string) 10 /home/.../extensions/Cargo/maintenance/cargoRecreateData.php(66): CargoRecreateData->recreateAllDataForTable(string, boolean) 11 /home/.../maintenance/doMaintenance.php(99): CargoRecreateData->execute() 12 /home/.../extensions/Cargo/maintenance/cargoRecreateData.php(171): require_once(string) 13 {main} [baf8de625274fbe257cabbd4] [no req] Error from line 599 of /home/.../extensions/PageForms/includes/PF_ParserFunctions.php: Call to a member function getTimestamp() on null Backtrace: 0 /home/.../includes/parser/Parser.php(3816): PFParserFunctions::renderAutoEdit(Parser, string, string, string, string, string, string, string, string) 1 /home/.../includes/parser/Parser.php(3519): Parser->callParserFunction(PPFrame_Hash, string, array) 2 /home/.../includes/parser/PPFrame_Hash.php(254): Parser->braceSubstitution(array, PPFrame_Hash) 3 /home/.../includes/parser/Parser.php(3330): PPFrame_Hash->expand(PPNode_Hash_Tree, integer) 4 /home/.../includes/parser/Parser.php(1489): Parser->replaceVariables(string) 5 /home/.../includes/parser/Parser.php(593): Parser->internalParse(string) 6 /home/.../includes/content/WikitextContent.php(368): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer) 7 /home/.../includes/content/AbstractContent.php(555): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput) 8 /home/.../includes/Revision/RenderedRevision.php(264): AbstractContent->getParserOutput(Title, integer, ParserOptions, boolean) 9 /home/.../includes/Revision/RenderedRevision.php(236): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached(WikitextContent, boolean) 10 /home/.../includes/Revision/RevisionRenderer.php(215): MediaWiki\Revision\RenderedRevision->getSlotParserOutput(string) 11 /home/.../includes/Revision/RevisionRenderer.php(152): MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, array) 12 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}(MediaWiki\Revision\RenderedRevision, array) 13 /home/.../includes/Revision/RenderedRevision.php(198): call_user_func(Closure, MediaWiki\Revision\RenderedRevision, array) 14 /home/.../includes/Storage/DerivedPageDataUpdater.php(1290): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput() 15 /home/.../includes/Storage/DerivedPageDataUpdater.php(1312): MediaWiki\Storage\DerivedPageDataUpdater->getCanonicalParserOutput() 16 /home/.../includes/Storage/DerivedPageDataUpdater.php(1606): MediaWiki\Storage\DerivedPageDataUpdater->getSecondaryDataUpdates(boolean) 17 /home/.../includes/page/WikiPage.php(2145): MediaWiki\Storage\DerivedPageDataUpdater->doSecondaryDataUpdates(array) 18 /home/.../maintenance/refreshLinks.php(276): WikiPage->doSecondaryDataUpdates(array) 19 /home/.../maintenance/refreshLinks.php(199): RefreshLinks::fixLinksFromArticle(integer, boolean) 20 /home/.../maintenance/refreshLinks.php(84): RefreshLinks->doRefreshLinks(integer, boolean, string, boolean, boolean) 21 /home/.../maintenance/rebuildall.php(60): RefreshLinks->execute() 22 /home/.../maintenance/doMaintenance.php(99): RebuildAll->execute() 23 /home/.../maintenance/rebuildall.php(67): require_once(string) 24 {main}

Running php cargoRecreateData.php manually I see it process several tables without problems, I see that this is the last thing processed before the error:

Recreating data for Cargo table workdays in 5 seconds... hit [Ctrl]-C to escape.

Deleting and recreating table...

Handling template that adds to this table: Workday

Saving data for pages 1 to 114 that call this template...

This table is created by a template called Workday. When I try to go to that template page I get the following error on the wiki:

[XrLNSa3siTcAAAv6zboAAAAE] 2020-05-06 14:44:26: Fatal exception of type "Error"

When I turn on debugging in LocalSettings I get a version of the same stack trace as above, starting with

[XrLOMq3siTcAAG5fWQsAAAAC] /index.php?title=Template:Workday Error from line 599 of /home/.../extensions/PageForms/includes/PF_ParserFunctions.php: Call to a member function getTimestamp() on null

Backtrace:

1. 0 /home/.../includes/parser/Parser.php(3816): PFParserFunctions::renderAutoEdit(Parser, string, string, string, string, string, string, string, string)

Here is the content of the template page. Sorry about the run-on presentation, see it in edit mode for better readability.

the template page

<noinclude> This is the "Workday" template. It goes at the top of [[Category:Workday]] pages that are part of the [[Work schedule]]. It should be called in the following format: <pre> {{Workday |Collector= |Location= |WorkDate= |WorkdayType= |ManagerApproval= |TimeKeeperProcessed= }} </pre> Edit the page to see the template text. ==Cargo declaration== {{#cargo_declare: _table = workdays |Collector=page |Location=page |WorkDate=date |WorkdayType=page |ManagerApproval=text |TimeKeeperProcessed=text }} [[Category:Work schedule wiki infrastructure]] ---- </noinclude>__NOTOC__ <div style="float:right;clear:both;"> {| class="wikitable" ! Collector | [[{{{Collector|}}}]] |- ! [[Locations |Location]] | [[{{{Location|}}}]] |- ! Work Date | {{#formatdate:{{{Work Date|}}}|ISO 8601}} |- ! [[Workday types | Workday type]] | [[{{{WorkdayType|}}}]] |- ! {{#autoedit:form=Workday |target={{PAGENAME}} |link text=Set manager approved |link type=button |summary=autoedit by button to put ~~~~ into [[Template:Workday]] manager field |tooltip=Click this button to set Manager approval. Of course you should only do that if you are the manager. |query string=Workday[ManagerApproval]=~~~~|reload}} <!--~ is a tilde, these generate a [[User:Ttenbergen|Ttenbergen]] ([[User talk:Ttenbergen|talk]]) 23:37, 2019 May 4 (CDT) to sign--> | {{{ManagerApproval|}}} |- ! {{#autoedit:form=Workday |target={{PAGENAME}} |link text=Set timekeeper processed |link type=button |summary=autoedit by button to put ~~~~ into [[Template:Workday]] timekeeper field |tooltip=Click this button to set Manager approval. Of course you should only do that if you are the manager. |query string=Workday[TimeKeeperProcessed]=~~~~|reload}} <!--~ is a tilde, these generate a [[User:Ttenbergen|Ttenbergen]] ([[User talk:Ttenbergen|talk]]) 23:37, 2019 May 4 (CDT) to sign--> | {{{TimeKeeperProcessed|}}} |}</div> <includeonly><div style="display: none;"> <!--{{DISPLAYTITLE: }} this hides the title --> Cargo storage: {{#cargo_store: _table = workdays |Collector={{{Collector|}}} |Location={{{Location|}}} |WorkDate={{{Work Date|}}} |WorkdayType={{{WorkdayType|}}} |ManagerApproval={{{ManagerApproval|}}} |TimeKeeperProcessed={{{TimeKeeperProcessed|}}} }} [[Category:Workday]] </div> </includeonly>

When I paste this template into the wiki that doesn't have errors in the scripts I get the same "Internal Error" message.

Sorry about that! This was a major bug I accidentally introduced last week. I just checked in a fix for it. I'll have to release a new version of Page Forms... Yaron Koren (talk) 20:59, 6 May 2020 (UTC)

The update fixed the issue. Thanks Yaron, always amazed how quickly you fix stuff!

I'm glad that worked. It's always easier to fix bugs that I myself created. :) Yaron Koren (talk) 23:05, 6 May 2020 (UTC)

[OPEN] Episodic "400 Bad request - Your browser sent an invalid request" on RunQuery

• MediaWiki 1.34.1 (b1f6480) 18:15, 30 April 2020
• PHP 7.2.30 (apache2handler)
• PageForms 4.8 (2e84936) 09:37, 4 March 2020

I have implemented a RunQuery form which works >90% of the time. The other <10% of the time it results in a "400 Bad Request - Your browser sent an invalid request" response from the browser. But oddly, I can click on the address bar and press enter to submit it a second time it always returns the correct healthy response.

• There is nothing in the apache or php error logs that relates to this
• There are no modifications to the form submit method (I'm not using a POST method, I'm using Page Forms exactly as it is downloaded from github)
• I've confirmed that the URL is well within the max URL length limit.
• The queries always produce the correct results and when I have to submit the query URL mentally after the browser error.
• It only ever happens with a RunQuery! and it is completely unpredictable.
• It does seem to correlate with changing the query options, but once a set of query options is selected, and i have worked through one round of the issue, it seems to become stable. Re-submitting the same query never seems to cause the issue.

Any idea what could be causing this episodic behavior?

• Could it be a network glitch?
• A caching issue?
• A session glitch?
• An apache bug?
• A corrupted cookie?

.. Please help me diagnose this.

Thanks! - Revansx (talk) 20:48, 7 May 2020 (UTC)

[SOLVED] Is there a size limit to the xml file used in PageSchemas to create forms, etc...

Hello,

I am able to create questionnaires using PageSchemas: I generate the xml file it using a parser (awk for example). But now I am running in an other problem: it appears that the xml files I am generating are too large (when loading them --cut&paste-- into a new category page and attempting to create the schema. I am pretty certain this is the problem: as soon as I get the file smaller, it works (ie, it is a valid xml file). The PHP error shows as simplexml_load_string(): [....] extensions/PageSchemas/includes/specials/PSEditSchema.php on line 756. I also tried to play with simplexml_load_string( $pageXMLstr, 'SimpleXMLElement', LIBXML_PARSEHUGE ), but no luck. Any ideas ? many thanks.

I can upload the example xml file in pastebin if it helps.

I have no idea. What's the full PHP error? And are you sure that the longer XML is fully valid Page Schemas XML? Yaron Koren (talk) 15:12, 14 May 2020 (UTC)

- the xml file is valid (using emacs for that purpose)

- actually, the file is not *that* big: 1677 lines, 67K

- the log:

May 14 17:41:53 localhost apache2: PHP Warning:  simplexml_load_string(): Entity: line 1415: parser error : EndTag: '</' not found in [...]/w/extensions/PageSchemas/includes/specials/PSEditSchema.php on line 756
May 14 17:41:53 localhost apache2: PHP Warning:  simplexml_load_string(): originales (non anonymisées ou non pseudonymisées) seront-elles supprimées en in [...]/w/extensions/PageSchemas/includes/specials/PSEditSchema.php on line 756
May 14 17:41:53 localhost apache2: PHP Warning:  simplexml_load_string():                                                                                ^ in [...]/w/extensions/PageSchemas/includes/specials/PSEditSchema.php on line 756

- unless I've done a idiotic mistake, what makes me think about size issues is that the 'parser error:' always occurs at the same line (here 1415), irrespective of the (valid) xml declarations by this point (the end tag '</' truly occurs on line 1415; see https://pastebin.com/ZP7w80CR)

I'll keep looking, but I am a bit baffled. Any help much appreciated! Thanks.

I don't think it's the size. I'm guessing that it's some specific bit of the XML that's causing the problem. Or does removing any part of the XML cause the errors to go away? Yaron Koren (talk) 18:44, 14 May 2020 (UTC)

Removing any part beyond this '1415' line still gave the error; removing everything after that line worked; when removing unnecessary spaces, the error line shifted by 200. The one thing I should have done is removing stuff above the 'offending' line, and see what happens. I'll do it asap, and reporting here.

I just did that, and under a certain size (roughly 68000 chars) it does work *phew*.

There is news: actually it is the pp_value (datatype blob) in the page_props table that is the culprit. The blob datatype is limited to 2^16 bytes, which fits what I am witnessing. (I checked this assertion by dumping the content of page_props, and lo and behold, pp_value showed a 'truncated' schema)

Now the problem is to modify the schema for that table. But is this reasonable? I am not a mediawiki expert, so I wonder if there is an easier way of getting this to work or even if the diagnostic is correct???

That does seem like the right diagnosis. I guess no one has ever tried creating a schema quite this massive before! I don't know what the right solution is, other than modifying Page Schemas to maybe use something other than page_props. Actually, one thing you can do is to modify the MediaWiki page_props table to change the type of the pp_value column from "BLOB" to "MEDIUMBLOB". That type is 256 times bigger, and should handle basically any schema you want to define. This may be risky... so I would recommend backing up the current page_props table before doing it (or maybe the entire database), but I think it would work. Yaron Koren (talk) 20:41, 18 May 2020 (UTC)

Ok, I did change the table page_props, and --cross fingers-- things seem to work (had I been using another db than mysql this wouldn't have happened as postgres and others only know about one blob type). I simply couldn't find an opensource tool allowing me to create and manage a questionnaire, while retaining all control. Hence the idea of using PageForms, which wasn't certainly designed with that in mind.

I must say, I don't quite understand the use of the table page_props, it seems that not all pages are recorded there? Anyway, I've got what I want, but I am not sure that was the best way to go about... Thanks. Paulette Lieby

Great, I'm glad that worked. page_props is basically a mechanism to store data that can't be stored anywhere else in the existing DB structure. Yaron Koren (talk) 13:53, 19 May 2020 (UTC)

I've flagged the issue as solved, as afterall I managed to do what I wanted. And no issues with the revised page_props. Cheers! Paulette Lieby

Special:RunQuery losing the title parameter and returning to the main page

I'm having trouble using Special:RunQuery with Cargo -- the problem seems very similar to those discussed here and here. Using Page Forms v4.9.1. The form rendered to the page by Special:RunQuery contains action="/index.php?title=Special:RunQuery/<my_form>", but when the button is clicked the browser is directed to /index.php?pfRunQueryFormName=<my_form>&...&wpRunQuery=Run+query. I suspect I too could probably solve it with short URLs, but I'd like to know what's wrong. Can you help?

Okay, I just checked in a fix for this - it turns out that Special:RunQuery simply wasn't supporting the default URL structure, for maybe a long time. If you get the latest code, it should work now. Yaron Koren (talk) 15:03, 22 May 2020 (UTC)

Is it possible to set up a many-to-many relationship?

I have an Organization object and a Container object; one of the properties of the Container is a list of Organizations (using a tokens field). Right now this is edited & saved in the Container page; but I would very much like to be able to edit the data from the Organization page - that is, to go to an Organization page, and set all the lists it should belong to.

I assume this might be a limitation of the data residing in wikitext, as it only physically in one page, and to do so the Organization form will have to edit many Container pages - but it looks like Special:MultiPageEdit already does something of the sort. Is this possible? In any sort of way? Thanks!

FFS ^Talk 22:30, 21 May 2020 (UTC)

Well, of course it's already possible to set up a many-to-many relationship; the tricky thing is to be able to edit a relationship from both sides. Yes, Special:MultiPageEdit is probably the closest thing to what you're asking about. Though I should note that, if you find yourself wanting to edit the data more from Organizations than from Containers, it may make sense to store the relationship in the reverse direction. Yaron Koren (talk) 15:11, 22 May 2020 (UTC)

Hi Yaron, thanks for your answer! We would probably switch to edit from the Organization side, then. Do you know how the caching will work in such a case? If I edit the Organization page, will the container page get refreshed? FFS ^Talk 14:39, 24 May 2020 (UTC)

That depends on your setup. If you're using Cargo, see here. If you're using SMW, the set of options is pretty similar. Yaron Koren (talk) 15:17, 27 May 2020 (UTC)

So no good solution... I do have multiple layers of cache. I will trying setting up a templatelink using a parser function, to force purging, or maybe try to smart guess somewhere inside Cargo. Thanks for your many patient answers. FFS ^Talk 20:15, 27 May 2020 (UTC)

The __NOCACHE__ option is not that bad... Yaron Koren (talk) 02:18, 28 May 2020 (UTC)

I get a lot of pageviews, so that's not really possible - but I'll find a workaround. Thanks you! FFS ^Talk 23:16, 1 June 2020 (UTC)

[SOLVED] pfautoedit doesn't include field-name nor field values for multiple instances templates

Hi Yaron, all,

I'm following instructions for pfautoedit: api.php?action=pfautoedit&form=form-name&target=page-name&template-name[field-name-1]=field-value-1&template-name[field-name-2]=field-value-2

All works well (thank you for this functionality!) except when I try to include values for fields in multiple instance templates. It still generates a new page, does capture all values for fields of single instance templates but if won't include any of the field name or field values for multiple instance templates. Do I do something wrong, e.g. do these templates need different syntax from described above to define template-name, field-name and field-value?

Version of PF: 4.8 (https://csdms.colorado.edu/wiki/Special:Version) --Albert Ke (talk) 22:51, 25 May 2020 (UTC)

Sorry for the delay. Yes, the syntax is a little different: instead of "template-name[field-name-1]=field-value-1", it should be template-name[instance-num][field-name-1]=field-value-1". Yaron Koren (talk) 15:47, 27 May 2020 (UTC)

That did the trick!! As always, thank you Yaron, problem solved!

[Solved] Tokens field HTML-escaped quote marks when using Cargo autocomplete

I have a tokens field, and whenever I select an entity (page) that includes a quote mark, say <Shi"l> (Hebrew abbreviations), it's saved to the page as <Shi&quot;l>. By itself, that not so bad, but it prevents me from using ";" as a delimiter for the fields. I can't use a comma because page names include it, and other delimiters are just not as well-understood for non-programmers (~, anyone?).

Upon further inspection, it seems this only happens for a field that uses a Cargo lookup: cargo table=local_service_center|cargo field=organization, and not for a field that uses a simpler "values=".

I think this is due to the "htmlspecialchars()" function in line 1543 of CargoSQLQuery.php, as that's what CargoAutocompleteAPI uses - but I have no idea what to do about it... Any thoughts? FFS ^Talk 23:52, 1 June 2020 (UTC)

I should note that there's nothing wrong with using "~" as a delimiter - if you're using the "tokens" input, and #arraymap for displaying the values, users will never have to see the delimiter, so it can be anything. However, that particular HTML-encoding is annoying. Thanks for finding the source of it. I ended up checking in a "fix" for it in Page Forms, so if you get the latest Page Forms code, quotes should remain unescaped in values. Yaron Koren (talk) 18:01, 2 June 2020 (UTC)

Thank you, Yaron! I guess my problem with using a tilde is that it does shows on Special:MultiPageEdit, but apparently that's a separate bug, one which I've started work on. FFS ^Talk 12:03, 18 June 2020 (UTC)

[Solved] 0 is not a valid form when using Edit with form

This error goes back a ways, I posted a question about it back here but then we stopped using the extension.

In a nut shell, I'm receiving error: "0 is not a valid form" when attempting to use the default Edit with form action created by Page Forms (4.9.3) on MW 1.33 and 1.34.

Yaron, you kindly replied asking for a db query:

"That's very strange! I don't know if I've seen that error before. Are you using a custom ID for the PF_NS_FORM namespace?"

No

"Have you made any changes to the local Page Forms code?"

No

"If neither of those - if you have access to the SQL database for your wiki, it would be great if you could run the query "SELECT * FROM page_props WHERE pp_propname = 'PFDefaultForm'" on that database, and let me know what it outputs."

I ran the SQL query and received (note: this is a very old database) and the names appear with 0:

pp_page	pp_propname	pp_value	pp_sortkey
29346	PFDefaultForm	0	NULL
29349	PFDefaultForm	0	NULL

I found a mention of issues with Page Forms with old databases on the Edutech Wiki under Namespace Conflicts With Used Namespaces but I'm not finding any namespace entries for NS 106 or 107 that don't correctly belong to Page Forms. Any idea what might be happening with the names? If installed and run on a clean database it works as expected. If I re-import my current db over the clean db and then run update.php, then the same result of the "0 is not a valid form" so it has to be related to the database. I just have no idea how to fix it other than to export all pages, import all pages into a clean site (which we'd rather not lose all of our page histories etc.).
Edit: Just found Manual:DumpBackup.php to use as a last resort.
-TiltedCerebellum (talk) 17:13, 2 June 2020 (UTC)

Right, I remember that discussion. And that database output looks as expected - pp_value bizarrely has a value of 0 in both cases. If you resave the #default_form call in both category pages, does this problem still happen? Yaron Koren (talk) 18:04, 2 June 2020 (UTC)

Yes, unfortunately re-saving the category page with the default form set still results in the same on our test wiki when trying to edit or create a page in that category (feel free to create whatever or test there, it is merely an upgraded clone of our production site). - TiltedCerebellum (talk) 20:01, 2 June 2020 (UTC)

I don't know... let me quote myself and say, "that's very strange!". My new theory is that you have some other piece of code on the wiki - another extension, maybe - that's interfering with Page Forms' ability to save to the page_props table. I would try temporarily uninstalling the other extensions on the wiki, to see if that has any impact. Yaron Koren (talk) 22:02, 2 June 2020 (UTC)

I thought the same thing, which is why when I installed MW 1.34 I started with no plugins except for Page Forms, I even disabled all of the default plugins. The only thing enabled was uploads and Page Forms (and I re-imported the database) and same result. For whatever reason, each new time a class is created, it has a default title of 0. If you'd like me to disable all extensions again and delete all add-on javascript again I can do that, though I will have to lock the site to editing to prevent the massive spam attacks that happen when the spam plugins aren't enabled. Also, this same thing happened on MW 1.33, 1.34.0 and 1.34.1 TiltedCerebellum (talk) 04:18, 3 June 2020 (UTC)

Edit: I have now disabled all extensions except for page forms, deleted all site javascript addons, and changed the theme back to vector which we have never modified, after doing a minor edit on the category page, same result when attempting to edit a form "0 is not a valid form" when using "Edit with form" TiltedCerebellum (talk) 04:31, 3 June 2020 (UTC)

Any idea where I should go from here in trying to figure out/troubleshoot the issue? TiltedCerebellum (talk) 16:31, 4 June 2020 (UTC)

Well, if you gave me access to your system, I could try to look into it myself. Beyond that, I don't know. Yaron Koren (talk) 16:55, 4 June 2020 (UTC)

I sent you 2 emails (one is automated from my webhost to give you account details in case you want to take a look using phpMyAdmin) and the other is the shortcut information that you might need to have a look at the database via ssh etc. All user data except mine has been wiped out of the User table. Thanks in advance if you get a chance to take a look! You can do/try whatever is needed on the db or site since it is a clone. TiltedCerebellum (talk) 21:17, 4 June 2020 (UTC)

Sorry testing it to find out why is going to have to go on pause now. We have an issue on the primary site where we have to switch to the secondary one for a bit.

We had an unexplained similar issue with the TemplateData extension, so I did a bunch of testing, logging etc. No useful errors. TemplateData extension was storing information also as false (0), so I now suspected the culprit to be the database itself (already disabled all extensions, base theme, all javacript/gadgets/widgets gone. I'm currently in the process of dumping all the pages, importing, importing files and TemplateData now works on a clean DB with all that was there re-imported. I suspect this will also fix my PageForms issue. Way back several years ago, a previous bureaucrat attempted to upgrade the site (presumably without a db backup) and it borked the db. Yes, can confirm, was a database issue. Exporting all pages and importing into a fresh MW solved it, Page Forms now works fine (as well as the other extension with the similar issue) TiltedCerebellum (talk) 01:39, 10 July 2020 (UTC)

Ah, that's great to hear! It's not totally surprising, since I had never heard of this happening on another wiki. I'm glad you have this fixed now, and can move on. Yaron Koren (talk) 19:15, 10 July 2020 (UTC)

[SOLVED] including wiki syntax in text fields will expose brackets of field after saving page

Hi Yaron, all,

(MW, PF Versions: https://csdms.colorado.edu/wiki/Special:Version)

When using PageForms to generate a page, wiki syntax that gets entered in a text field (e.g. something like [https://external.link/etc link]) will expose brackets ("[[" at the beginning, and "]]" at the end) of the field after the page is saved. An example can be seen at under Introduction at: https://csdms.colorado.edu/wiki/Lab-0015. Does anyone have a suggestion on how to solve this? Thanks --Albert Ke (talk) 16:45, 5 June 2020 (UTC)

That sounds like a Semantic MediaWiki question. Yaron Koren (talk) 19:34, 5 June 2020 (UTC)

You're right, on the SMW help site it is pointed out that data type "Text" accepts some MW markup (see also: https://www.semantic-mediawiki.org/wiki/Help:Type_Text). Tried a few things like html code for [ ] (%5b, %5d) but that didn't work either. I'm interested if anybody knows a work around. Thanks! (I marked this solved as it is not a PF issue) --Albert Ke (talk) 20:14, 5 June 2020 (UTC)

@Albert Ke: I just stumbled over your question by chance since I do not watch this page. You probably have added some code to the field that cannot be stored with an in-text annotation. I suggest to look into the "template" parameter to the #set parser function to make annotations fail safe. --[[kgh]] (talk) 16:08, 15 June 2020 (UTC) PS Also check if you allowed links in values (SMW_PARSER_LINV) via configuration.

All template arguments shown, i.e. also for the fields not filled

I just upgraded from 4.8 to 4.9.3 and now realize that all template arguments are added to a page even if one did not fill the respective fields, basically back to the behaviour we had a couple of years ago e.g. {{MyTemplate |MyField1=foo |MiyField2= |MyField3=Bar }} vs. {{MyTemplate |MyField1=foo |MyField3=Bar }}. Since I will have to update a couple of templates I'd like to know if this was an intended or unintended change? --[[kgh]] (talk) 15:59, 15 June 2020 (UTC)

Yeah, probably you have no clue which was a bit the expected outcome to my question. Does not matter any longer. I will change the templates in a way that it does not matter if it works this way or the other depending on the version of PF used. Cheers --[[kgh]] (talk) 14:32, 17 June 2020 (UTC)

I've also had this problem in 4.9 and 4.9.1. It is a serious problem for me because it stops default values in template arguments from working, and some of my default values are not empty strings. Working around it would require more #if tests which wouldn't be necessary if Page Forms went back to the old behaviour (eg 4.3) of only displaying arguments in the page source if they have values.--DrGavinR (talk) 07:24, 20 June 2020 (UTC)

Oh dear, how can we get the previous behaviour back (other than my reverting to an earlier version of PF)? Cavila 19:55, 22 June 2020 (UTC)

Sorry about that - this was a bug that accidentally got into version 4.9. I just checked in a fix for it. Yaron Koren (talk) 02:55, 23 June 2020 (UTC)

Thanks. I didn't report it earlier because I went straight from 4.3 to 4.9 so didn't know when the bug first appeared.--DrGavinR (talk) 07:01, 23 June 2020 (UTC)

Thanks! Cavila 09:14, 23 June 2020 (UTC)

WikiEditor not loading

In einem Privaten Wiki habe ich PageForms installiert, doch scheinbar lädt der WikiEditor nicht in Formularen. Ein dauerhafter Ladekreis wird angezeigt. Ich kann nicht so gut englisch, wenn ein deutschsprachiger Helfer hier ist, würde ich mich freuen. I installed Page Forms in a private Wiki, but the extension WikiEditor does not loading in Forms. An permanent loadingsymbol is there. --2.205.76.108 15:48, 19 June 2020 (UTC)

What version of Page Forms are you running? Yaron Koren (talk) 16:35, 19 June 2020 (UTC)

Pageforms 4.7 at Mediawiki 1.31.0/SMW 3.1.3 --2.205.76.108 17:07, 19 June 2020 (UTC)

Issue with tokens field refusing to become empty (resolved)

Starting with 4.8 I'm having a strange issue with the tokens field. When I've selected an option from the autocomplete list but then decide to remove it again, the field is automatically filled with another value, typically or invariably the first one on the list. In other words, it has become impossible to empty the tokens field. I had to go back to version 4.7 to get it working again. Looks like this is happening when there is a limited number of selectable options. Cavila 20:12, 22 June 2020 (UTC)

Are you sure the problem came about in version 4.8 and not 4.9? If it was 4.9, then this is a bug that I believe was fixed last week. I'm hoping to release another version soon that has this and other fixes. Yaron Koren (talk) 20:43, 22 June 2020 (UTC)

Well, I'm not so sure now, haha. I can't rule out that it may have been a matter of headstrong browser caching at the time of testing. Will look into it. Cavila 09:21, 23 June 2020 (UTC)

Now checking out fine in PF 4.9.4. Cavila 13:28, 12 July 2020 (UTC)