Extension talk:Page Forms

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)

breaks MW 1.29 compatibility
Hi Yaron, replaces   with , 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  together with. We have external data that needs to go into the form. This data is given to the form by means of a URL parameter. Is there any way we can pass  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: and I use the "popup" feature of the "formlink" parser function provided by Page Forms.
 * with
 * and SAML SSO Integration via
 * and

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: and I use #formlinks with the "popup" option.
 * with

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 "&lt;h2&gt;My section&lt;/h2&gt;" 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:
 * 0 /home/.../includes/parser/Parser.php(3816): PFParserFunctions::renderAutoEdit(Parser, string, string, string, string, string, string, string, string)

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:
 * 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. {| class="wikitable mw-collapsible mw-collapsed" This is the "Workday" template. It goes at the top of pages that are part of the Work schedule. It should be called in the following format:
 * the template page

Edit the page to see the template text.

Cargo declaration
Cargo storage:


 * }

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: '&lt;/' 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 '&lt;/' 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, but when the button is clicked the browser is directed to. 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  (Hebrew abbreviations), it's saved to the page as . 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: , 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:
 * {| class="wikitable"

!pp_page !pp_propname !pp_value !pp_sortkey
 * 29346
 * PFDefaultForm
 * 0
 * NULL
 * 29349
 * PFDefaultForm
 * 0
 * NULL
 * }
 * 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 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)


 * 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 " " parameter to the  parser function to make annotations fail safe. --&#91;&#91;kgh&#93;&#93; (talk) 16:08, 15 June 2020 (UTC) PS Also check if you allowed links in values  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.  vs. . Since I will have to update a couple of templates I'd like to know if this was an intended or unintended change? --&#91;&#91;kgh&#93;&#93; (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 --&#91;&#91;kgh&#93;&#93; (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)

Clicking form edit on page with 100s of template calls results in blank page timeout error
I have a page that uses a pageform to add multiple template calls (which people hold a certain role, in my case). This form worked for a while, but as the size of the wiki has increased, one page now calls over 300 templates. When I click "edit with form" on that page, I just get a blank page. The php log tells me [02-Jul-2020 10:17:26 America/Winnipeg] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /home/.../extensions/PageForms/includes/PF_AutoeditAPI.php on line 1061 If I remove a bunch of the template calls from the page temporarily it works again, but still is very slow to load (>20s).

I realize that one answer to this would be to redesign the data structure how we store this, but that would require edits to hundreds of pages, so I would prefer not to go that route.

Is there a way to make this quicker? Short of that, is there a way to at least get an explicit error rather than a blank page? Or, if on most wikis pageforms breaks at a certain page size, push an error when that is reached and revert to a plain edit? My temporary work-around is to ask people use a plain edit for the page. I might be able to remove the form edit tab from just the big roles. In any case it introduces weird exceptions in the use of the wiki which is lowering acceptance. The whole reason I have them edit this directly is because I have not found a solution for an earlier problem, https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_January_to_March_2020Tenbergen (talk) 21:57, 2 July 2020 (UTC)


 * This might help with the blank page thing. Beyond that, I don't know - there's always going to be a limit, no matter how fast the code is. Yaron Koren (talk) 01:26, 3 July 2020 (UTC)


 * I realize we are doing something strange there, but wanted to make sure it's just legitimate resource depletion and not some bug. I had a look at the link you gave, and an increase in the php execution time allows the page to load. It takes more than 30s, so clearly isn't really a solution, but it's much better than a blank page. Is there a way to block the edit with page explicitly on a single page that uses a template that otherwise has a designated form? Tenbergen (talk) 21:00, 9 July 2020 (UTC)

Using #autoedit from inside a form instead of inside a page
The following is copied from an archived version of this page since no edits should be made there. --- I have written an #autoedit tag to update a page. The tag works as expected when I call it from another page. However, I would like to use the tag from a Form page instead of a page in the regular namespace. When I try to use the link from the form page, I get the error Modifying failed. No form specified. Will try to find the default form for the target page.

No target page specified. The code for the autoedit tag is: Is it possible to use this tag from inside a form and I have the syntax wrong, or is it simply not possible to use this from inside a form?


 * That sounds like a bug. But why include #autoedit in a form? It seems strange to modify a page while in the middle of modifying a different page. Yaron Koren (talk) 03:48, 13 February 2020 (UTC)
 * Sorry, lost sight of this problem. I have a wiki with pages for people and pages for their roles. When I set it up, I pondered if the information about who holds a role should be on the role page or the person page, and decided to put it on the role page. When we first built it that made sense, but of course now, the process is such that a new person arriving will lead to them being in several roles, so each role page would need to be edited to add the person. To make that process a little more straightforward I wanted to add links in the person form to start editing the relevant roles in a different tab. The more elegant solution would be to redesign things to store role holding in the person pages, but that would mean changing hundreds of pages. So that's the use case, but I am open to a different solution to the problem. What I have done for now is provide a cargo driven table that generates a link to edit a given role page, but it doesn't actually generate the required template call to add the current person. The autoedit link I was trying to set can do that, but only from a main page not a form page. As a tangent, some of the role pages are getting big (one has 353 template calls now to add a person to that role) and the page form that opens it now times out. I have started a talk section about that separately, but mentioning it here because this is the reason I came back to the problem today: my work around of a link to a form edit of the page no longer works for some of the roles. Tenbergen (talk) 15:15, 2 July 2020 (UTC)


 * It does sound like storing this information in person pages would make much more sense. I guess I would recommend doing that... Even if it involves editing hundreds of pages, it might only take a few hours to do. Granted, it might not be a pleasant few hours.
 * Also, does this information need to be stored in multiple-instance templates? Can it be done with just a field holding a list of values instead? Or is there more than one column of data involved?
 * Anyway, if you're not going to change the data structure, what I would recommend is to put the #autoedit link into the person template, not the person form - that will work better, and seems less confusing to users also. Yaron Koren (talk) 03:19, 10 July 2020 (UTC)

Default not working in PF 4.9.4
I think I stumbled on a new parsing issue. I have a form for adding multiple-instance templates. Users can add new instances by doing a search first (outside the form) and click the wanted item. What happens next is that the user is sent to the form with the wanted item listed in the url. The form reads the URL parameter and adds it as a default value of one of the form fields. If the user clicks "another instance" (or whatever label it is), that field is automatically filled with the item mentioned. Since the latest version (PF 4.9.4), however, this is no longer working: the field remains empty. Cavila 13:27, 12 July 2020 (UTC)

Field missing from leaflet input type
The leaflet input type used to have two fields, one being a field for holding the coordinates, the other an input for searching places and showing the most probable match on the map. The latter appears to be removed in PF 4.9.4. Was this intentional? I thought it was pretty useful even if it ignored other possible matches for one's search. Cavila 13:38, 12 July 2020 (UTC)