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)

[SOLVED] #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)

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

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)

[MAYBE SOLVED] 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)


 * [POSSIBLE EXPLANATION AND SOLUTION] - I made a change that seems to have solved (and identified) the problem. Turns out that the page in my wiki with the Run Query code (say, PageX) was commonly being arrived at from a redirect. So when the page first loads, Mediawiki shows the little redirect notice below the page name. The problem is.. when the users selects some options and clicks "Run Query", PAge forms redirects to the special page Special:RunQuery where the run query work is done. Somehow, the combination of the initial run from the initial page load from the redirect with the user having set variables selection variables.. triggers PF to generate a malformed URL that the server then rejects as "Error 400". Since I eliminated the redirect, the Run Query has yet to produce the error .. If I don't see the error again over the course of the next week, I'll come back and mark this as SOLVED.. until then.. *fingers crossed* - Revansx (talk) 22:41, 15 May 2020 (UTC)

[SOLVED --SORT OF] 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)

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)