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)

Another upload issue with REL1_32: when using, clicking on the upload button has no effect. The JavaScript console says "pf is not defined". Is it just me? Sophivorus (talk) 23:32, 12 April 2019 (UTC)


 * Could you try using the latest version of Page Forms? You should never really use the "REL_" branches. Yaron Koren (talk) 16:49, 15 April 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)

Want to use 'show on select' for multiple elements in a form
Hi

I'd like to show or hide several different elements on a form depending on input to a field. I've tried 'show on select' which works fine for a single element, but doesn't for multiple elements because the id can only apply to one element I guess. Is there a way round this? If not would it be possible to change PageForms to use class instead of/as well as id?

Many thanks

Duncan 9th April 2019


 * It probably would have been better to use classes instead of IDs... but you can already do something like "show on select=a=>div1;a=>div2;b=>div1", etc. - in other words, it's a many-to-many relationship. Does that help? Yaron Koren (talk) 17:10, 9 April 2019 (UTC)


 * That works just fine - thanks Yaron. Duncan 10th April 2019

Multi Instance fields - parser functions only parse once
Mediawiki 1.29

This is a repost to see if some light can be shed on this. This would be a real big fix for me (and probably others).

I have an uploadable field in a multiple template which I would like to auto-generate filenames to ensure they are unique. I thought using the page name with a timestamp would be simple enough, but the timestamp doesn't update when you "Add Another".

I have also tried: Similar results except that it does increment once. First filename gets a 1. When I "Add Another" the filename there gets a 2, and all added after that remain 2. Is there a way to ensure each uploaded file is unique regardless of the incoming filename. I thought this approach should work, but clearly I'm missing something. Thanks. --Pvodrazka (talk) 21:02, 9 April 2019 (UTC)

formredlink does not use the query string
I submitted this issue a couple months ago, and after providing clarification a fix was not provided.

I have a template  that contains

.

This template is intended to take the argument and create a page using the  form to automatically create the linked Troop page if it does not exist. uses a module to convert the name provided into the value of the mandatory ID field (which is used by other modules/templates called by Form Troop to populate the infoboxes etc in the page).

The intended result is that, when the link is added to the page, a new page would be created (if it did not exist) that contains something like

However, even if I drop the template and hardcode the value in the query string, the page automatically generated by PageForms simply contains. In other words, the query string is completely ignored, even if I replace the TroopId call with a static value. If I exclude the 'create page' option, clicking the link populates the form with the values from the query string as intended, but manually creating each required page would not be viable.

If my syntax is incorrect, or there is an issue with PageForms, advice would be appreciated.

EliteMasterEric (talk) 17:29, 10 April 2019 (UTC)


 * Have you tried to add spaces to separate curly braces. Ex:.

Can't say if this will help, but I have encountered problems in the past with non-separated braces.--Pvodrazka (talk) 16:45, 15 April 2019 (UTC)

Query Form results table - Sorting only works for first 4 columns.
I have a query form with a dropdown to filter the table. When the table is showing all results, all columns can be sorted, but when I filter the list, only the first four of seven columns sort correctly. Clicking to sort the non-working columns does change the sort arrows on the heading row, but the sort does not occur. Video showing my issue - https://youtu. be/Tx62YztFEy8 (spaces added to get around spam filter / I'm not spamming)

Is this a bug?, Or am I doing something wrong? Thanks, --Pvodrazka (talk) 21:32, 11 April 2019 (UTC)


 * Thanks for that video - it's helpful. The two non-working columns are both date fields - do you know if that's the issue, or if it's just because they're after four columns? Yaron Koren (talk) 22:28, 11 April 2019 (UTC)

I'm not sure, but they sort fine before the list is filtered by the query. Thanks.--Pvodrazka (talk) 14:54, 14 April 2019 (UTC)

I decided to look at it again, and by adding  to the date table header columns, everything is working as expected. Thanks. --Pvodrazka (talk) 16:52, 15 April 2019 (UTC)


 * It's great that you got it working, and good to know about that "data-sort-type" option for (I'm guessing) tables of class "prettytable" or "wikitable". Yaron Koren (talk) 18:41, 16 April 2019 (UTC)

remote autocompletion failing on cargo tables with lowercase names
Once the number of tokens exceeds $wgPageFormsMaxLocalAutocompleteValues the remote autocompletion fails.

CargoUtils::getTableSchemas is throwing an exception wfMessage( "cargo-unknowntable", $tableName )

because the incoming table name is capitalised

PFTextWithAutocompleteInput::getAutocompletionTypeAndSource is capitalising cargo table names because of a call at the end of the function to

if ( $wgCapitalLinks && $autocompleteFieldType != 'external_url') { global $wgContLang; $autocompletionSource = $wgContLang->ucfirst( $autocompletionSource ); }

changing the code to

if ( $wgCapitalLinks && $autocompleteFieldType != 'external_url' && $autocompleteFieldType !='cargo field') { global $wgContLang; $autocompletionSource = $wgContLang->ucfirst( $autocompletionSource ); }

fixes the problem.

patch file is: --- PF_TextWithAutocompleteInput.php.original	2019-04-16 14:17:37.617255788 +0100 +++ PF_TextWithAutocompleteInput.php	2019-04-16 14:18:01.903162583 +0100 @@ -97,7 +97,7 @@ 			$autocompletionSource = null; } -		if ( $wgCapitalLinks && $autocompleteFieldType != 'external_url' ) { +		if ( $wgCapitalLinks && $autocompleteFieldType != 'external_url' && $autocompleteFieldType != 'cargo field') { global $wgContLang; $autocompletionSource = $wgContLang->ucfirst( $autocompletionSource ); } JamesDriscoll (talk) 14:48, 16 April 2019 (UTC)


 * Sorry about that bug. But thanks for debugging it! I just checked in your suggested fix. Yaron Koren (talk) 18:58, 16 April 2019 (UTC)

Field option for uploadable - get file extension from incoming file
I have forms with multi-instance templates for users to create documents that includes uploading images. I am trying to make it as simple as possible to automate the naming of the files they upload by using. I have tried many ways to have the number at the end auto-increment at page creation to no avail. I do have it working with the IDProvider Extension which lets me create unique filenames but only if the page has been saved with all of the instances first (no files uploaded on creation). when you edit the page after, the uploaded file names get unique names. Ex:

Currently the default filename includes the extension (.jpg) but this creates a problem when someone tries to add a png and doesn't know to change the extension. I wish I could omit the  from the   and have an option like   or. It would be nice to be able to have an auto-increment feature built into the  or   as well.

I appreciate your work. If any of this is possible, I would be very grateful.--Pvodrazka (talk) 16:55, 18 April 2019 (UTC)


 * The "default filename" feature is indeed not very useful - and I don't know of any workaround to make it more useful, unfortunately. Definitely being able to get the file extension to always be correct would be quite helpful. Yaron Koren (talk) 21:02, 22 April 2019 (UTC)

Subforms formatting
Hi, I have two questions:
 * 1) Is it possible to change the appearance of subrofms and subform-fields? Now they are just grey things which do more or less what they want and not what I do :) (See the example)
 * 2) where could I find sub-form documentation? Once (ca 2 years ago) I found some information about it but I think that this website is now gone.  maybe you could give me a hint? :) Thanks in advance! Pawel Niemczuk (talk) 12:45, 20 April 2019 (UTC)


 * These are known as "multiple-instance templates"; you can read more about them here. There are various tricks you can do with CSS and JS to change their appearance... Yaron Koren (talk) 21:03, 22 April 2019 (UTC)


 * Aaa, as simple as this! I have no idea why but I believed it was a different piece of documentation. Thanks, Yaron, for your help! Pawel Niemczuk (talk) 11:20, 24 April 2019 (UTC)

different versions of jquery.ui.widget.js
Hi Yaron, I've just tried the latest version of Pageforms (I've been using 4.3 (d60a82c) 21:10, 30 August 2018 in production)

Unfortunately, autocomplete on text areas is broken, an error is being thrown and consistently caught by this code change

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/PageForms/+/83b17aa8710166dd3aca66c5ee4431fa559d639e The comment associated with the change is: // Autocompletion (and specifically, the call to // this.menu.element in line 195 of jquery.ui.autocomplete.js) // for some reason sometimes fails when doing a preview of the // form definition. It's not that importatnt, so, in lieu of // showing it to the user (or debugging it), we'll just catch // the error and log it in the console. ...so it's a bigger problem than when previewing the form definition.

In trying to debug the problem I discovered that it all starts working with the inclusion of debug=1 in the url

and finally tracked the problem down to different version of jquery.ui.widget.js in mediawiki core and the one you include in jquery.fancytree.ui-deps.js

When debug=1 is used the mediawi core version of jquery.ui.widget.js is being used and all is well.

Without the debug=1 I assume the minification/combination process is organised in such a way that the version of jquery.ui.widget.js in jquery.fancytrwee.ui-deps.js is overriding the one in core. I'm not actually using fancytree anywhere so have temporarily avoided the problem by not including 'ext.pageforms.fancytree', in the $mainModules array in PF_Utils.php

Clearly this is not a good fix but the comment in jquery.fancytree.ui-deps.js is probably a good clue for you...

//FYI: the first two "classes" defined here, widget and position, // could probably be removed and replaced with loads of // jquery.ui.widget and jquery.ui.position from core MediaWiki. // The others - keycode, scroll and unique - are not included // in core MediaWiki. They could be split off into separate // files here, though - especially if/when jQuery UI gets copied // into Page Forms.

I suspect other people have hit the same problem as I've read reports of things working with debug=1

I hope this is useful. JamesDriscoll (talk) 10:10, 30 April 2019 (UTC)

PF_DatePickerInput.php producing  PHP Warning on  count
since php 7.2.0	count will now yield a warning on invalid countable types passed to the array_or_countable parameter.

PF_DatePickerInput.php is producing these  errors [Thu May 02 10:54:11.870096 2019] [php7:warn] [pid 13668] [client 10.0.1.38:37050] PHP Warning: count: Parameter must be an array or an object that implements Countable in /var/www/html/wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 240, referer: https://my.website.com/

Here is the patch to stop them... --- PF_DatePickerInput.php	2019-05-02 12:17:54.148747899 +0100 +++ PF_DatePickerInput.php.new	2019-05-02 12:01:49.000000000 +0100 @@ -237,7 +237,7 @@ 			} 			// find allowed values and invert them to get disabled values -			if ( array_key_exists( 'possible_values', $this->mOtherArgs ) && count( $this->mOtherArgs['possible_values'] ) ) { +			if ( array_key_exists( 'possible_values', $this->mOtherArgs ) && is_array( $this->mOtherArgs['possible_values'] ) && count( $this->mOtherArgs['possible_values'] ) ) { $enabledDates = self::sortAndMergeRanges( self::createRangesArray( $this->mOtherArgs['possible_values'] ) ); // correct min/max date to the first/last allowed value JamesDriscoll (talk) 13:56, 2 May 2019 (UTC)


 * Sorry about that! There were a bunch of array-related errors in that file - most have been fixed already, but not this one. I just checked in a fix. Yaron Koren (talk) 18:24, 2 May 2019 (UTC)