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


 * Hi. Yes, this is the expected behaviour. To indicate the form to use, the default_form parser function must be used in a category page or inside a template of a normal page. In the first case (you add default_form to a category page), when you create a page, the page is not actually added to the category right away, but a job is added to the queue to add the page to the category, so it takes some time until the page is actually added to the category in the mediawiki database, see Manual:Errors_and_symptoms. In the latter case (you add default_form to the template), the default_form parser function adds a property to the page to register the default form, but this is also done in a job.


 * I also find this a bit frustrating. In my case, I have a wiki with some uploadable fields. In order to provide default and unique names to the upload files I use the page IDs. Using javascript the uploadable fields are disabled when creating the page and once the page is created the user must edit the page to upload files. So, it's no good if the user has to wait some unknown time for the link to appear.


 * If your wiki is small and you are using a service to run jobs as explained in Manual:Job_queue, If you decrease the sleep time the time until the link appears will be reduced. However, this is not a fix.


 * I have been looking into this and have made a patch that "fixes" the problem if you add the default_form parser function to the page templates. In PageForms, the "edit with form" link is added by the function displayTab, which is called as a hook. The original behaviour of displayTab was to query the mediawiki database to obtain the default form for the page. In my patch, I modified the default_form PHP parser function in a way that it adds the selected form to a global variable. Then, the displayTab function obtains the form to use directly from the global variable that was initialized by the default_form function. I put the patch here, it was done over PageForms version 4.5.1. I think that the usage of a global variable is a bit hacky, but I don't know if there is another way to do it.




 * --Tombolano (talk) 20:58, 16 June 2019 (UTC)

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)


 * Sorry about the problem, and thanks for diagnosing it. I believe this has finally been fixed now, with a change to remove those "widget" and "position" classes from the Page Forms code and just use the ones in MW core. Yaron Koren (talk) 15:48, 22 May 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)

Can I pass a value from a multiple instance form field through the query string via formedit?
I have a form for meeting minutes, which uses multiple instance for meeting topics. Each meeting topic has a few fields. One of those is "Related article". I'm working to add a formlink from this meeting minutes form (within the section where the template for that multiple instance is defined within the meeting minutes form) that will use Special:FormEdit for a new Action form. I have figured out how to pass via the query string and it works okay. But I'd like to also pass the values in the field "Related article" of the multiple instance form for the meeting topic. Is this possible?

I should note that I have gotten this to work using a formfield in the template for the topic from meeting. So when you're viewing the page, you can click the form link and it'll pass the Related article along in the query string. But I'm not able to do this in the "edit with form" view. I'm guessing it's because the values for that field aren't saved anywhere yet, but I figured I'd ask. Maybe the only way is to use javascript to read the contents of that element.

--Darenwelsh (talk) 15:51, 4 May 2019 (UTC)


 * Sorry, I don't understand - what's the difference between the link that works and the link that doesn't work? Yaron Koren (talk) 16:45, 5 May 2019 (UTC)


 * The link that doesn't work is when editing a page with form. The link that does work is when viewing/reading a page. --Darenwelsh (talk) 22:26, 7 May 2019 (UTC)


 * Sorry for the delay. If you're asking about getting some value that the user just typed and putting it into a link, you might be able to do it via some JavaScript, but there's no standard way to do it. Though I still don't understand the idea of linking to a form from within a form... there might be some easier way to do whatever underlying thing you're trying to accomplish. Yaron Koren (talk) 14:21, 13 May 2019 (UTC)


 * No worries, I appreciate any feedback and understand you're busy. I'm envisioning that a user might be in the middle of editing a page with a form (like say a page using the form for meeting minutes) and they realize they want to add an action item. So if there was a link in the form's edit view that popped up a new browser tab with the Action form, it would be nice. I'll keep tinkering. --Darenwelsh (talk) 22:38, 14 May 2019 (UTC)

Auto create subpage from form without having to specify the parent each time
I'm using this and Cargo. I created multiple forms but every time I need to create an article based on it and have it relate to a main topic I have to put "My main article/My subarticle" as the form's name. Is there a way to make sure certain form's articles and up in a specific parent each time without typing it first?

I'm not quite sure if I explained this properly. Thanks! Extarys (talk) 01:51, 24 May 2019 (UTC)


 * I found it, sorry!
 * Extarys (talk) 03:20, 24 May 2019 (UTC)

field Autocomplete using "values from concept" does not work
I need for field autocompleting with pages belong to two categories at same time.

The way to set "|values from category=myCategory" for form field works with one category only.

I haven't found any way to do this, except creation of concept and setting "|values from concept=myConcept" for form field. But it doesn't show me pages of concept.

myConcept content is  "" . I can read list of pages belong to myCategory1 and myCategory2 at same time on concept page.

But form field does not suggest me these pages for selecting

Form field look like this "".

How can I find the bug? I use


 * MediaWiki	1.32.0
 * Semantic MediaWiki	3.0.2
 * Page Forms	4.5

Fix autocomplete filter function for no \w chars.
In the function attachAutocomplete on file libs/PageForms.js, the code overrides autocomplete method filter. This function search with word-boundry \b metacharacter. This is not working for none \w chars. This leads to no results for other langunages (in our case hebrew). To fix, we replaced it with (^|\s|\b) (start of line or whitespace char. Here's link to gerrit.


 * Thank for reply, Anysite
 * I've replaced line matcher = new RegExp("\\b" + $.ui.autocomplete.escapeRegex(term), "i" ); with matcher = new RegExp("(^|\\s)" + $.ui.autocomplete.escapeRegex(term), "i" );
 * But autocompleting behaviour hasn't been changed at all
 * I've tried to create new page without national russian symbol. But this one don't been shown in combobox, too.
 * Have you any idea else?
 * --Smirnoww (talk) 08:17, 27 May 2019 (UTC)
 * UPD: "|values from category=myCategory" works well, but with filter by ONE category
 * Well, it wasn't meant to be comment to your issue, but a new issue.
 * Anyway, maybe you should start with with very simple autocomplete (such like values from namespace) to see if my fix works for russian, then procced from there.
 * Ok! I've start with very simple autocomplete  
 * It work fine even with Russian symbols.
 * Now I've changed autocomplete souce  
 * And I have empty combobox :(
 * So your issue is unrelated (or part related) to my issue. Can we separate them again?
 * of course, as you wish

Dropdown list empty if values parameter in the field definition is a single 0
Hey everybody, I try to populate a dropdown field with the result of a query. In some cases the result of the query is a single 0 with the consequence, that the dropdown list stays empty.

The same problem occurs, if I use a single 0 instead of the query above:

As soon as the query results in at least two values (e.g. 0, 1), the dropdown list is populated as expected (0,1).

Is there maybe any known limitation/bug I am not aware of in using a single 0 as the values parameter.

Thanks in advance


 * Sorry about that problem - I just checked in what I think is a fix for this. Yaron Koren (talk) 20:12, 10 June 2019 (UTC)


 * Thank you very much for the fix. Small addition: I have changed line 354 in PF_FormField.php (10 June 2019) to if ( (! empty( $values )) && ($values != null) ) { Otherwise PHP throws a notice  (not a big problem but filling the log files) MW Kappa (talk) 17:46, 12 June 2019 (UTC)


 * Thanky you very much for providing the fix. Problem on my site is now being resolved --Shuitavsshente (talk) 12:14, 28 June 2019 (UTC)

A database query error has occurred - Function: PFValuesUtils::getAllPagesForNamespace
Dear Yaron Koren,

when using Page Forms Version 4.3 or higher on Mediawiki 1.31.1, I'm getting the following error:

A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT page_title,pp_displaytitle.pp_value AS "pp_displaytitle_value",pp_defaultsort.pp_value AS "pp_defaultsort_value" FROM "page" LEFT JOIN "page_props" "pp_displaytitle" ON ((pp_displaytitle.pp_page = page_id) AND (pp_displaytitle.pp_propname = "displaytitle")) LEFT JOIN "page_props" "pp_defaultsort" ON ((pp_defaultsort.pp_page = page_id) AND (pp_defaultsort.pp_propname = "defaultsort")) WHERE (page_namespace = 6) Function: PFValuesUtils::getAllPagesForNamespace Error: 42703 FEHLER: Spalte »displaytitle« existiert nicht LINE 1: ...age = page_id) AND (pp_displaytitle.pp_propname = "displayti…

I'm using Mediawiki on PostgreSQL 11 and PHP 7.0.33. I've already executed the update-script update.php without errors.

Do you know this error and how to solve it?

This is the Create Table for page:

CREATE TABLE WIKI.page

( page_id integer NOT NULL DEFAULT nextval('WIKI.page_page_id_seq'::regclass), page_namespace integer NOT NULL, page_title character varying(255) COLLATE pg_catalog."default" NOT NULL, page_restrictions text COLLATE pg_catalog."default", page_is_redirect smallint NOT NULL DEFAULT 0, page_is_new smallint NOT NULL DEFAULT 0, page_random real NOT NULL DEFAULT random, page_touched timestamp with time zone, page_latest integer NOT NULL, page_len integer NOT NULL, titlevector tsvector, page_content_model text COLLATE pg_catalog."default", page_links_updated timestamp with time zone, page_lang text COLLATE pg_catalog."default", CONSTRAINT page_pkey PRIMARY KEY (page_id) ) WITH ( OIDS = FALSE ) TABLESPACE pg_default;

Many thanks.


 * What's PSQL - PostgreSQL? Yaron Koren (talk) 13:35, 17 June 2019 (UTC)
 * Yes, it's PostgreSQL. SH73


 * This looks like a PostgreSQL-specific issue. I just checked in what I hope is a fix for this. If you can, please get the latest code and let me know if that fixes the problem. Yaron Koren (talk) 16:44, 18 June 2019 (UTC)
 * Great, the problem is solved now. Many Thanks. SH73

Is it possible to render the form data differently than with wikitables
Instead of a table, I would like the data to be displayed in this format:

== Field name 1 == Field value 1

== Field name 2 == Field value 2

etc...

Thx.


 * Are you talking about the form, or the template? Yaron Koren (talk) 18:57, 20 June 2019 (UTC)

autoedit issue when page has subobjects
Product	Version MediaWiki	1.31.1 PHP	7.1.8 (apache2handler) MySQL	5.6.10 Semantic MediaWiki	2.5.8 Page Forms	4.3.1 (624f2a9) 18:20, 16 January 2018 I'm using auto edit to set a property to a new value on a page. When the page has subobjects and I select the button to change the property 1 of the subobjects disappears.


 * I upgraded page forms to 4.5.1 and that seems to have fixed the issue Legaulph (talk) 11:23, 2 July 2019 (UTC)

No default values for embedded multiple-instance templates
(MediaWiki 1.32.2, Page Forms 4.5.1) I made a query form with a main template and a secondary "embed in field" multiple instance template. It works fine but the fields default values are not set for the secondary template. Tested without "embed in field": defaults are ok.

By the way, "Select all" and "Select none" for checkboxes are not shown in multiple instance layout, I don't know if its made on purpose, still it would be nice to have it also in this context.

I switched skin and browser user-agent, don't know what happens but now defaults are correctly set.

Steph.

Select2 don't work.
When I create a form, I create 'field' tag, which have input type: 'text with autocomplete', 'textarea with autocomplete', 'tokens' or 'combobox', and have 'list' parameter for many values. This field are associated with template field which have SMW-property "Page" and have several allow values ( AllowValues:: . When I try to use this form, I type characters but nothing happens. I don't see autocomplete. At the same time, on my monitor screen, I see spinning boot icon (from the file extension\PageForms\skins\loading.gif). When I change input type on 'checkboxes' or 'listbox', I can select required values in the form without problem. But it is uncomfortable. I think, it is problem into Select2-library. What must I do? MediaWiki 	1.32.1 PHP 		7.3.5 (apache2handler) MariaDB 	10.1.40-MariaDB Windows 10 64 bit FireFox         68.0 Language        Russian

Extension: Semantic Drilldown	2.1 Semantic MediaWiki	2.3.1 Page Forms		4.5.1 DataValues		1.0 DataValues Common	0.2.3 DataValues Interfaces	0.1.5 DataValues Validators	0.1.2 ParserHooks		1.4.0 Validator		2.0.4

Settings in LocalSetting.php: $wgPageFormsAutocompleteOnAllChars = true; $smwgEnableUpdateJobs = false;


 * Could you look in the console on your browser, and see if there are any JavaScript errors? Yaron Koren (talk) 22:54, 18 July 2019 (UTC)


 * Browser console:

[ac0a9dbb1002909f24b58b84] /wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector BadMethodCallException from line 848 of C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php: Sessions are disabled for this entry point Backtrace: Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.main" sortDependencies http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:41 resolveStubbornly http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:42 load http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:53 http://localhost/wiki/mediawiki-1.32.1/index.php/Служебная:FormEdit/Создание_нового_документа/13:9 push http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:76 http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:76 http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:76 load.php:35:662
 * 0 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php(310): MediaWiki\Session\SessionManager->getSessionFromInfo(MediaWiki\Session\SessionInfo, WebRequest)
 * 1 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php(244): MediaWiki\Session\SessionManager->getEmptySessionInternal(WebRequest)
 * 2 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php(194): MediaWiki\Session\SessionManager->getEmptySession(WebRequest)
 * 3 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\WebRequest.php(750): MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest)
 * 4 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(1377): WebRequest->getSession
 * 5 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(447): User->loadFromSession
 * 6 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(5487): User->load
 * 7 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(3174): User->loadOptions
 * 8 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\context\RequestContext.php(336): User->getOption(string)
 * 9 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\Message.php(713): RequestContext->getLanguage
 * 1) 10 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\context\RequestContext.php(426): Message->setContext(RequestContext)
 * 2) 11 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\context\ContextSource.php(171): RequestContext->msg(string)
 * 3) 12 C:\xampp\htdocs\wiki\mediawiki-1.32.1\extensions\SemanticMediaWiki\includes\queryprinters\TableResultPrinter.php(35): ContextSource->msg(string)
 * 4) 13 C:\xampp\htdocs\wiki\mediawiki-1.32.1\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\ResourceLoaderGetConfigVars.php(62): SMW\TableResultPrinter->getName
 * 5) 14 C:\xampp\htdocs\wiki\mediawiki-1.32.1\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\HookRegistry.php(341): SMW\MediaWiki\Hooks\ResourceLoaderGetConfigVars->process
 * 6) 15 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\Hooks.php(174): SMW\MediaWiki\Hooks\HookRegistry->SMW\MediaWiki\Hooks\{closure}(array)
 * 7) 16 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\Hooks.php(202): Hooks::callHook(string, array, array, NULL)
 * 8) 17 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderStartUpModule.php(129): Hooks::run(string, array)
 * 9) 18 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderStartUpModule.php(432): ResourceLoaderStartUpModule->getConfigSettings(ResourceLoaderContext)
 * 10) 19 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderModule.php(708): ResourceLoaderStartUpModule->getScript(ResourceLoaderContext)
 * 11) 20 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderModule.php(675): ResourceLoaderModule->buildContent(ResourceLoaderContext)
 * 12) 21 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderModule.php(812): ResourceLoaderModule->getModuleContent(ResourceLoaderContext)
 * 13) 22 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoader.php(660): ResourceLoaderModule->getVersionHash(ResourceLoaderContext)
 * 14) 23 [internal function]: ResourceLoader->{closure}(string)
 * 15) 24 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoader.php(672): array_map(Closure, array)
 * 16) 25 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoader.php(753): ResourceLoader->getCombinedVersion(ResourceLoaderContext, array)
 * 17) 26 C:\xampp\htdocs\wiki\mediawiki-1.32.1\load.php(51): ResourceLoader->respond(ResourceLoaderContext)
 * 18) 27 {main} load.php:33:47


 * And other analogical errors:

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.submit" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.fancytree" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.imagepreview" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.autogrow" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.checkboxes" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.select2" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.rating" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.fancybox.jquery3" load.php:35:662


 * I have solved this problem by change the skin in my Wiki from 'Vektor' to 'Monobook'. But it isn't good, because 'Vektor' more beautiful then 'Monobook'. I hope this bug will be eliminate in future. Thank you for support. Thiazole


 * Interesting. Is "Vektor" the same as "Vector"? (I assume so.) And do these JS errors show up in every one of your forms, if you have more than one? Yaron Koren (talk) 13:24, 19 July 2019 (UTC)


 * Yes, "Vektor" = "Vector", it is a misprint. I'm sorry. I have several forms, and all of this forms have errors. Thiazole


 * It sounds like there are one or more JavaScript bugs there, which may be unrelated to Select2. Possibly they're coming from Semantic MediaWiki, judging by that console printout. Could you try temporarily disabling SMW and seeing if the JS errors are still there in the forms? Yaron Koren (talk) 01:57, 25 July 2019 (UTC)

Input type "checkboxes": Missing CSS class in span tag?
I am going to use Page Forms in this wiki here in order to create file descriptions for uploaded files by using a page form. I fiddled around with radio buttons and I am now finally able to format and position them with the help of a CSS grid. Therefore I created a CSS class for a special group of radio buttons in Common.css. This works fine. Then I tried the same on checkboxes. Of course with a different CSS class for a special group of checkboxes. That failed at first. I took a look at the HTML source code of such a page form. Every group of radio buttons and every group of chackboxes with their label and input tags is wrapped in a span tag. The span tag of the radio button group includes the CSS class, witch I added to the field tag in the form. The span tag of the group of checkboxes shows no sign of the CSS class as provided by the field tag in the form. Only the label tags of every item in that span tag are carrying this class.

This here is line 107 to 113 from the original PF_RadioButtonInput.php file:

This is line 94 to 97 from the original PF_CheckboxesInput.php

I changed that part in "my" PF_CheckboxesInput.php to: Now the span tag of the group of checkboxes includes the CSS class, witch I added to the field tag in the form. And the CSS grid gets effectiv.

Is this a bug? --Wgkderdicke (talk) 14:13, 20 July 2019 (UTC)

Questions about the input types "radiobutton" and "checkboxes"
While fiddeling around with the above-named input types, I discovered this:

For every value from the values parameter one input element is created. If there is no mapping, the order of the input elements is determined by the order of the values as specified at the values parameter. If the label of the input elements is changed by a mapping template, the order changes. Now the input elements are sorted in ascending alphabetic order on the basis of the values given by the mapping template. And if the mapping template creates dynamic labels, the input elements are going to appear here and there. I think, it is better, if the order is fix and determined by the order of the values as specified at the values parameter. Or there is an extra parameter which provides sorting options.

The default parameter has to be set with one specific value out of the comma separated list from the values parameter. The show on select parameter needs the values given by the mapping template. To retrieve the values from different sources seems odd to me.

It seems that the semicolon separated values of the show on select parameter, the allocation from IDs to values, can not be generated by a template (or maybe all my attempts went wrong because of faulty syntax). Lets presume that the input field holds 90 radio buttons. And every single radio button wants to get an ID to show further information on select of this button. And the pretty long show on select part in the field tag clutters everything in the wiki code of this form... --Wgkderdicke (talk) 21:13, 24 July 2019 (UTC)


 * For the first issue, I didn't understand this part: "if the mapping template creates dynamic labels, the input elements are going to appear here and there". What are dynamic labels? For the second one, I'm guessing that the "show on select" value isn't parsed - not all values are parsed. That seems like a problem in this case, though it doesn't sound like a major one. Yaron Koren (talk) 02:43, 25 July 2019 (UTC)


 * Wrong word. Here in Germany one says: . This means:  . I "translated" this to  . Seems to be a false friend thing. Actually, I mean: if the mapping template creates variable labels, the input elements are going to appear here and there.--Wgkderdicke (talk) 08:01, 25 July 2019 (UTC)


 * I still don't understand what this means. Does the mapping template sometimes create "variable labels" and sometimes not? Yaron Koren (talk) 20:12, 25 July 2019 (UTC)

OK, let's presume one wants to categorize crimes. To choose one of them the form provides this field tag: You get three radiobuttons in this order:. Furthermore, let's presume that the page created by this form needs exactly the A,B,C values at the Crime parameter. So it is unfeasible to change the  parameter.

Now the mapping template named  comes into play with this code: The field tag gets the  option and now the order of the radiobuttons changes to: . Now another mapping template called  is used. This template calls yet another template named, which retrieves the percentage of a specific crime from the last month. The code of the new mapping template: The field tag contains ths:. At the moment the radiobuttons will show us this, for example, and again in a different order: . The percentages of the crimes have changed to 22% for Murder, 33% for Assault and battery and 45% for Robbery. Time passes, it is the next month now, the last month is the former current month, the form now shows this and yet again in a different order: . Depending on a variable value a specific radiobuttion will appear sometimes as first radio button, some other time as second radiobutton and another time as third radiobutton. The button apears here and there.

But perhaps one wants to keep a static order or respectively stick to that order, which is given by the comma separated list at the  parameter. And wants to use the mapping feature. --Wgkderdicke (talk) 21:44, 25 July 2019 (UTC)


 * Aha! Now I understand; thanks for that full explanation. This does seem like a bug - if "values=" is specified, the values should be kept in that order, even if they are mapped. Yaron Koren (talk) 18:27, 26 July 2019 (UTC)

PF namespaces 106 & 107
To begin with, in principle the PF extension seems to run without any problems here in this wiki. In the LocalSettings.php file of this wiki near the top there are four custom namespaces defined (100-103). In the middle of that file the installation of PF happens. After that, near the end of that file, the access to several namespaces is restricted via $wgNamespaceProtection and the Lockdown extension. Now I additionally want to restrict the access to the form namespace PF_NS_FORM. Therefore I added this line beneath the other restriction:

I immediately got this warning:.

Then I added near the top and beneath the other definitions for "my" custom namespaces but before the PF installation line this here:

Now the warning has disappeared. And the restriction seams to get effectiv.

Is this a bug? --Wgkderdicke (talk) 20:42, 25 July 2019 (UTC)


 * How are you loading Page Forms - with PageForms.php, or with wfLoadExtension? Yaron Koren (talk) 18:28, 26 July 2019 (UTC)