Extension talk:Page Forms/Archive March to June 2019

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:

{{#autoedit:form=Manage Company|target=CN00002|link text=Select|link type=button|query string=Manage Company[companyname]=itzmemichaeld }}

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:

{{#autoedit:form=Manage Company|target=https://foo.bar.org/wiki/CN00002|link text=Select|link type=button|query string=Manage Company[companyname]=itzmemichaeld }}

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 {{DISPLAYTITLE}} 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:

{{#autoedit:form=OpenDemocracy Article|Target=OD000123|link text=Select|link type=button|query string=Auto Add Article[articleauthor]=Mikeyd}}

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)

@Yaron Koren: Another upload issue with REL1_32: when using $wgPageFormsSimpleUpload = true;, 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 <gallery> 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 {{PAGENAME}} 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 Page Forms/Archive March to June 2019. 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 <translate><!--T:2-->Text to edit</translate> 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
./includes/wikipage/PF_WikiPageTemplateParam.php
./includes/PF_FormField.php
./includes/PF_FormPrinter.php
--Andreas P. 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 <translate><!--T:2--> </translate>-tags --Andreas P. 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?

1. Header template, free text, footer template; or
2. Single template containing header, field for the text, footer?

I'd be happy to provide further information if needed. Thanks. Jonathan3 (talk) 14:37, 25 March 2019 (UTC)

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:

{{{field|fieldname|input type=tokens|values from namespace=Category}}}

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 input type=text with autocomplete 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#Category_pages,_Special:Whatlinkshere_and_file_usage_aren't_being_updated. 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#Simple_service_to_run_jobs, 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.

diff --git a/includes/PF_FormEditAction.php b/includes/PF_FormEditAction.php
index e12eb5aa..dd127727 100644
--- a/includes/PF_FormEditAction.php
+++ b/includes/PF_FormEditAction.php
@@ -65,6 +65,15 @@ class PFFormEditAction extends Action {
 		}
 
 		$form_names = PFFormLinker::getDefaultFormsForPage( $title );
+
+		// The global variable $wgPageFormsCurrentForms is set with the
+		// desired forms by the 'default_form' parser function when used on
+		// a normal page (not in a category page).
+		global $wgPageFormsCurrentForms;
+		if ( !is_null( $wgPageFormsCurrentForms ) ) {
+			$form_names = array_unique( array_merge( $wgPageFormsCurrentForms, $form_names ) );
+		}
+
 		if ( count( $form_names ) == 0 ) {
 			return true;
 		}
@@ -99,10 +108,16 @@ class PFFormEditAction extends Action {
 		}
 
 		$class_name = ( $obj->getRequest()->getVal( 'action' ) == 'formedit' ) ? 'selected' : '';
+		if ( count( $form_names ) == 1 ) {
+			$form_edit_href = $title->getLocalURL( 'action=formedit&form=' . $form_names[0] );
+		} else {
+			$form_edit_href = $title->getLocalURL( 'action=formedit' );
+		}
+
 		$form_edit_tab = array(
 			'class' => $class_name,
 			'text' => wfMessage( $form_edit_tab_msg )->text(),
-			'href' => $title->getLocalURL( 'action=formedit' )
+			'href' => $form_edit_href
 		);
 
 		// Find the location of the 'edit' tab, and add 'edit
@@ -278,7 +293,14 @@ class PFFormEditAction extends Action {
 	static function displayForm( $action, $article ) {
 		$output = $action->getOutput();
 		$title = $article->getTitle();
-		$form_names = PFFormLinker::getDefaultFormsForPage( $title );
+		$request_form = $action->context->getRequest()->getValues()['form'];
+
+		if ( !is_null( $request_form ) ) {
+			$form_names = [$request_form];
+		} else {
+			$form_names = PFFormLinker::getDefaultFormsForPage( $title );
+		}
+
 		if ( count( $form_names ) == 0 ) {
 			// If no form is set, display an interface to let the
 			// user choose out of all the forms defined on this wiki
diff --git a/includes/PF_ParserFunctions.php b/includes/PF_ParserFunctions.php
index 922c64cd..51df5f12 100644
--- a/includes/PF_ParserFunctions.php
+++ b/includes/PF_ParserFunctions.php
@@ -182,9 +182,16 @@ class PFParserFunctions {
 			$defaultFormPageLink = "[[$defaultFormPageText|$defaultForm]]";
 			$text = wfMessage( 'pf_category_hasdefaultform', $defaultFormPageLink )->text();
 			return $text;
+		} else {
+			// It's not a category - add form to global variable to be used later
+			// by the displayTab hook function (in PF_FormEditAction.php).
+			global $wgPageFormsCurrentForms;
+			if ( is_null( $wgPageFormsCurrentForms ) ) {
+				$wgPageFormsCurrentForms = [$defaultForm];
+			} else {
+				$wgPageFormsCurrentForms[] = $defaultForm;
+			}
 		}
-
-		// It's not a category - display nothing.
 	}
 
 	public static function renderFormLink( &$parser ) {

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

When using Visual Editor, {{#formlink}} & {{#formredlink}} 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)

This is due to the Visual Editor not parsing the <a> tags generated by Page Forms. The solution is written here.

So you have to add the <a> tag to the config/WikitextConstants.js file of Parsoid (installation path may differ) and restart the parsoid service (sudo systemctl restart parsoid).

--Platinops (talk) 12:08, 16 November 2020 (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".

{{{field|StepImage|uploadable|image preview|fancybox|default filename={{#titleparts: {{FULLPAGENAME}} | 1 | 1 }}-{{#titleparts: {{FULLPAGENAME}} | 1 | 2 }}-PackStep-{{#time: U | now }}.jpg }}}

I have also tried:

{{{field|StepImage|uploadable|image preview|fancybox|default filename={{#titleparts: {{FULLPAGENAME}} | 1 | 1 }}-{{#titleparts: {{FULLPAGENAME}} | 1 | 2 }}-PackStep-{{#vardefine: pvCounter | {{#expr: {{#var: pvCounter}} + 1 }} }}{{#var: pvCounter}}.jpg }}}

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 {{Link Troop}} that contains

{{#formredlink:target={{{1|}}}|form=Troop|link text={{{1|}}} (create page)|create page|query string=Form_Troop[id]={{Troop Id|name={{{1|}}}}}}}.

This template is intended to take the argument and create a page using the Form Troop form to automatically create the linked Troop page if it does not exist. {{Troop Id}} 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 {{Form Troop|id=1234}}

However, even if I drop the template and hardcode the value in the query string, the page automatically generated by PageForms simply contains {{Form Troop}}. 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: {{#formredlink:target={{{1|}}}|form=Troop|link text={{{1|}}} (create page)|create page|query string=Form_Troop[id]={{Troop Id|name={{{1|}}} }} }}.

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 data-sort-type="text" to the date table header columns, everything is working as expected. ! style="text-align:center" data-sort-type="text" | Approved Date 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 default=. 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:

{{{field|CellImage|size=5|uploadable|image preview|fancybox|default filename={{#idprovider-increment:
  |prefix={{#titleparts: {{FULLPAGENAME}} | 1 | 2 }}-Image-
  |padding=6
  |skipUniqueTest=true
}}.jpg}}}


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 .jpg from the default= and have an option like file extension=from file or extension=match.
It would be nice to be able to have an auto-increment feature built into the default= or uploadable 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. @Yaron Koren: 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 {{PAGENAME}} 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! {{#forminput:form=Mysuper/form|super_page=MyMainPage}}

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 "{{#concept: [[Category:myCategory1]][[Category:myCategory2]]}}". 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 "{{{field| myProperty| input type=combobox| values from concept=myConcept}}}" .

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 {{{field| myProperty| placeholder=bla bla bla| input type=combobox| values from category=myCategory }}}

It work fine even with Russian symbols.

Now I've changed autocomplete souce {{{field| myProperty| placeholder=bla bla bla| input type=combobox| values from concept=myConcept }}}

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.

{{{field|reference id|input type=dropdown|values={{#cargo_query:tables=indicator|fields=item_id|where=belongs_to_project="{{#var:pageID}}"|no html}} }}}

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

{{{field|reference id|input type=dropdown|values=0}}}

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 Undefined variable: values in ...extensions/PageForms/includes/PF_FormField.php on line 354 (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)