Extension talk:Page Forms

From MediaWiki.org
Jump to navigation Jump to search

Cannot get autoedit to work. Strange error on namespace and not updating [Resolved][edit]

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+[edit]

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[edit]

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?[edit]

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. 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.[edit]

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 ?[edit]

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. Icon External Link E-Mail.png 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. 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 <translate><!--T:2--> </translate>-tags --Andreas P. Icon External Link E-Mail.png 11:59, 4 April 2019 (UTC)

Add tag to form edits?[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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

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

Thanks a lot !

Chris

When using Visual Editor, {{#formlink}} & {{#formredlink}} populate the HTML code instead of displaying the page as is[edit]

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[edit]

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[edit]

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[edit]

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.[edit]

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[edit]

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[edit]

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)