Extension talk:Page Forms

Cannot get autoedit to work. Strange error on namespace and not updating [Resolved]
I am trying to use autoedit to update a page with no success. This is the an example where I have hardcoded the write to test it. First I put this:



CN00002 is in the main namespace, but I get this error: "Error: Invalid namespace ""; only content namespaces are allowed for #autoedit." .

So I give the the path to the page I want to edit like so:



That clears the error with the content namespace issue, but doesn't carry out the update. So the form "Manage Company" is the form I used to create the page, the target is the page name and the template is called "Manage Company". The template variable is called "companyname" and is the cargo table field name too, although I appreciate the cargo element should be irrelevant. I've tried "form=Manage_Company" as I thought it might not like spaces. I tried setting up a form name with no spaces, with no success. Michaeldakin (talk) 20:36, 3 March 2019 (UTC)


 * The second of those definitely won't work. The first one should work, though. Have you modified $wgContentNamespaces in LocalSettings.php? Yaron Koren (talk) 19:00, 4 March 2019 (UTC)


 * No I haven't changed $wgContentNamespaces in LocalSettings.php. I am on a wikifarm (Miraheze), so I don't have access to change it. I can follow up with Miraheze and see if they have being doing anything. Although they are very good, so I can't imagine they will have done anything like that. Let me go check my other Wiki on Miraheze and get back to you. Interestingly I have noticed that the two wikis have some differences that I wouldn't have expected. For example on one wiki the php setting allows me to use to completely change the title, while the other wiki works in the Parser out of the box way, where you can only change capitalisation. Michaeldakin (talk) 19:42, 4 March 2019 (UTC)
 * **UPDATE**
 * I tested on my other wiki. The page I wished to update was "OD000123" created by form "OpenDemocracy Article" which is linked to template "Auto Add Article". I added the following line:




 * This resulted in OD000124 being created with only the articleauthor field populated rather than my target being updated. I didn't get an error with content space. Michaeldakin (talk) 20:06, 4 March 2019 (UTC)

Indeed you were correct. I realised that Miraheze have an extension to check NameSpaces and yes their Main Namespace was not set to content. I have changed mine and informed them. Many thanks. Michael 11:02, 11 March 2019 (UTC)

Upload file (Special:UploadWindow) and MediaWiki 1.31.0+
Ran into an issue trying to upload images from a Page Form in MW 1.32.0. The pop-up window would throw a ConfigException. Turns out that EnableAPI was deprecated in MW 1.31.0 and removed in 1.32.0. I commented out the check for that config setting on line 350 of PF_UploadForm.php to get it up and running for me at the moment but wanted to pass the info along to you for a proper fix. Thanks for the incredibly useful extensions!


 * Thanks for diagnosing the problem! I just checked in a change that includes this fix. Yaron Koren (talk) 20:55, 4 March 2019 (UTC)

The gallery CSS module disappears when reviewing changes
I have a form that below the fields displays a gallery from query-results (this is not related to any form tags). But it works only the first time i enter to edit some page - any subsequent reloads of the form (preview, show changes) does not load all CSS modules needed, that is, the `mediawiki.page.gallery` module is gone, and rendering of the images falls back to UList. Any ideas why that might happen, and how can i workaround it?


 * MW: 1.31.0
 * SMW: 2.5.8
 * PageForms: 4.4.2
 * Ankostis (talk) 16:02, 5 March 2019 (UTC)


 * If you don't mind, could you try putting in a standard &lt;gallery&gt; tag in the form, and see if that works in the same conditions? That will help determine if it's a PF or SMW issue. Yaron Koren (talk) 03:15, 7 March 2019 (UTC)

Is there a way to get when I've created the page with formlink?
I have a form for creating journals. I use formlink because I don't want the users to create the name. On the form I have the template set as multiple. The journal is tabular with a row per journal entry. I want them to be able to total up the journal occasionally to ensure they are putting in the figures correctly. This follows the logic that their credit column should add up to the same amount as their debit column.

In respect of getting a total I thought I had it cracked, because Save and Continue writes to the cargo table. Excellent I have what I have entered so far. I add a cargo query and I can have the totals showing at the bottom everytime the user presses Save and Continue. Except I can't get the page name on a formlink with. As you'd expect I get "Page Forms permissions test" returned. If I could get the page name while working in the form I could test that name against -pageName in the cargo table and voila I'd be doing a jig. I cannot go down the forminput route although I know that will get me the page name. I know the page name is there somewhere because I saved and continued and can see the records created in the cargo table.

Any ideas? Is there a better way? Michaeldakin (talk) 14:17, 11 March 2019 (UTC)


 * That's interesting - you want to get the name of the page that will be created by the form, to use in a query. I can't think of a way to do that, unfortunately. Actually, I'm somewhat surprised that "Save and continue" works, although I guess it makes sense. But for this, there would need to be some new parser function or variable added, I would think. Although another option, for your specific use case, is to add in some custom JavaScript, via MediaWiki:Common.js or something, to do the same thing - it wouldn't be querying Cargo, it would just go by the numbers right on the form page. That way you could have the total value get updated in real time, as opposed to requiring the user to press some button to see the current total. Yaron Koren (talk) 13:55, 15 March 2019 (UTC)


 * Yes a script is probably more sensible. My users will do regular saves because they worry about losing data, but querying cargo is heavy handed. Thanks for your reply. Michaeldakin (talk) 20:12, 16 March 2019 (UTC)

Query Form - Clicking back button in browser doesn't bring you back to previous query form.
Mediawiki 1.29.1 PageForms 4.3.1

I use a dropdown to query pages, Then I click on one of the resulting pages, but if I go back (back button), I get this error: Confirm Form Resubmission Is there a way to allow going back without this error? Thanks.--Pvodrazka (talk) 02:38, 9 April 2019 (UTC)


 * That's true - I didn't think about that. It only happens in some browsers, though. Anyway, I just checked in a change so that Special:RunQuery now uses GET, instead of POST, to send its data, so if you get the latest code, this problem should go away. Yaron Koren (talk) 22:39, 18 March 2019 (UTC)

Thanks for the quick reply. I am stuck on MW 1.29 at the moment for a number of reasons. I just tried the latest PageForms 4.5 and all of my query searches return to the MainPage. I'm not sure if this is due to MW 1.29 and PageForms 4.5 not being compatible. I have gone back to PageForms 4.4.1 for now and everything is working fine except for the browser-back bug mentioned above. Any advice is appreciated.


 * Sorry about that. My guess is that your wiki has the default URL structure (with "index.php"), and that that's what is indirectly causing the error. I just checked in what I think is a fix for this. Yaron Koren (talk)

Thank You Yaron! Everything is now working as expected. I appreciate your great work and kind help.--Pvodrazka (talk) 02:38, 9 April 2019 (UTC)

Extension Translate together with Page Form editing ?
Hej-hej,

is it possible to use extension page forms together with extension translate without seeing the translation markers (e.g. instead of  just see “Text to edit”) ? How can this be accomplished? --Andreas P. 22:10, 20 March 2019 (UTC)


 * I don't know. Other people have used Translate along with Page Forms, so hopefully someone out there can answer this. Yaron Koren (talk) 02:29, 21 March 2019 (UTC)


 * I found a clone of extension page forms in Wikifab that has support of extension translate (see https://github.com/Wikifab/PageForms/tree/REL1_32/includes) the files   --Andreas P. Icon_External_Link_E-Mail.png 23:42, 3 April 2019 (UTC) Addendum: They somehow store the translation tags separately in addition to the actual form values, so the person editing the form just sees the values without the  -tags --Andreas P. Icon_External_Link_E-Mail.png 11:59, 4 April 2019 (UTC)

Add tag to form edits?
Similar to how Visual Editor has its own tag, could there be a tag for form edits? Either one generic "Edited with a form" tag or something you can set in a form definition as a per-form thing - mostly I just want to be able to track when people aren't using a form to edit a page, but if edits with a form have any kind of tag I can filter that myself. --RheingoldRiver (talk) 09:40, 22 March 2019 (UTC)


 * This is nearly the opposite of what you want, but what about a hidden "last edited by form" field, Date type, default "now"? Or, even simpler, but maybe less useful, have it as an "edited by form" field, Boolean type, default true. The template could add it to a "edited by form" category if that field is set, or "not edited by form" category otherwise. You could have it as a restricted field so that you could reset it yourself when you've dealt with the page. Jonathan3 (talk) 14:46, 25 March 2019 (UTC)


 * Or what about a separate "Form edits" table that's attached to the main table, and to which the form sends the page name and current date when the page is saved? You know Lua - could that be used to analyse which edits were by form (i.e. on the "Form edits" table) or otherwise (i.e. in page history/recent changes, but not in that table). Jonathan3 (talk) 14:50, 25 March 2019 (UTC)

Free text in middle of page
To have a header, free text, then footer (which takes one parameter: category), which option would you recommend? I'd be happy to provide further information if needed. Thanks. Jonathan3 (talk) 14:37, 25 March 2019 (UTC)
 * 1) Header template, free text, footer template; or
 * 2) Single template containing header, field for the text, footer?


 * Either one should work... the big downside to the latter approach is that you can't have pipes (|) in the text by themselves, outside of template or parser function calls. On the other hand, with the latter approach you can store the text via Cargo or SMW. I don't know if either of those is a factor in your case. Yaron Koren (talk) 16:00, 27 March 2019 (UTC)


 * Cheers. I've gone for option 1. Jonathan3 (talk) 22:05, 27 March 2019 (UTC)

Can't get autocomplete on namespace to work
With the following:

When I type something in the box it suggests every value, nomatter whether relevant to what I've typed. The relevant values have the similar text emboldened, but the irrelevant values should not appear at all. What am I doing wrong? I've tried it with  and on both Foreground and Vector skins. Thanks. Jonathan3 (talk) 14:18, 27 March 2019 (UTC)


 * I can't replicate this problem. If you look in the JavaScript console, do you see any error messages? And what version of Page Forms are you using? Yaron Koren (talk) 16:39, 27 March 2019 (UTC)


 * Okay, I was able to replicate it - it turned out to be a bug specific to the Category namespace. I just checked in what I think is a fix for this problem. Yaron Koren (talk) 02:21, 29 March 2019 (UTC)

Please provide a way to override auto-minimisation of multiple-instance templates
We use multiple-instance templates to track events belonging to series of (usually) 25–30 events. Since display fields when minimized only toggles visibility of individual fields and doesn't allow for changing the order of fields (and, indeed, for fields consisting of multiple input elements, e.g., date fields, provides no way to display the aggregate value, but only the constituent values as individual fields), while also not showing any of the labels, this greatly hurts readability (instead of improving it). Alternatively, make the threshold for automatic minimisation configurable (instead of hardcoding 800px), or support specifying a template for the minimised view. --Akorenchkin (talk) 15:50, 3 April 2019 (UTC)


 * Sorry about that. If you use the very latest code, such a setting has already been added - $wgPageFormsHeightForMinimizingInstances, which defaults to 800. If you set it to a negative number, minimization doesn't happen at all. Hopefully an official version will be released soon, containing this feature. Yaron Koren (talk) 21:21, 3 April 2019 (UTC)


 * Thanks, that'll work for us! --Akorenchkin (talk) 09:01, 4 April 2019 (UTC)
 * Except it doesn't, since PageForms.js#L1768 doesn't read that variable, so all instances start minimised anyways. I've submitted a patch through gerrit. --Akorenchkin (talk) 13:17, 4 April 2019 (UTC)


 * I would love it if I could enable/disable within the form. I love the feature in some of my forms, but need to disable in others. Thanks for all of your help. --Pvodrazka (talk) 02:37, 9 April 2019 (UTC)

Have to wait several seconds before editing a page with the "edit with form" tab
Hi there ! I'm using Mediawiki 1.29 and PageForms 4.1.2. I followed the instructions about "edit with form" tab (based on category). But I have a problem when I create a new page with a form : when I submit it, the page is created but I have to wait several seconds before been able to edit it with the form (by clicking on "Edit with form"). If I click too fast on the "Edit with form" tab, I'm not redirected to the form to edit the page but to the special page that allows to create a page by choosing a form.

Any idea? Is it a problem about job queue ? Is there a kind of indexing of something just after page creation?

Thanks a lot !

Chris

When using Visual Editor, &  populate the HTML code instead of displaying the page as is
I'm experiencing this on:


 * MW: 1.31.1 (a4c8065)
 * SMW: 3.0.0
 * PF: 4.4.1 (730390a)

Thanks in advance,

V brooks (talk) 21:09, 5 April 2019 (UTC)