Extension talk:Page Forms/Archive August to December 2023

Special:UploadWindow example?

Is there documentation with examples of how I would include Special:UploadWindow in a pageform? Thanks!Tenbergen (talk) 02:21, 10 August 2023 (UTC)

I'm guessing you mean the file upload option, which calls Special:UploadWindow. The documentaton for that is here: Extension:Page Forms/Input types#Uploading files. Cavila 10:58, 10 August 2023 (UTC)

Unregistered users can't edit with forms (solved!)

Hello!

We have a wiki using PageForms and unfortunately we have a strange problem with it: Both registered and unregistered users should be able to create and edit pages of a certain namespace using a form. For registered users it works without problems. For unregistered users creating pages with the form works, too. However, when they try to edit a page using the form and try to save their edit, they get an error message: "Die Änderung von <a class="mw-selflink selflink">(name of the page)</a> ist fehlgeschlagen." It's a German wiki, but the text seems to be from MediaWiki:Pf autoedit fail, if that helps.

(I don't know why the link isn't properly parsed but displayed as HTML.)

I don't even use the #autoedit parser function or something like that, just a normal form.

Does anyone here by chance know what might be the reason for this error and how to get rid of it? Timo Müller (talk) 18:36, 18 August 2023 (UTC)

Hi Timo. In MediaWiki in general, 'createpage' and 'edit' are two seaprate user rights and Page Forms depends on the settings for them. Is it possible that anonymous users only have the 'createpage' permission? Cavila 06:58, 19 August 2023 (UTC)

Thank you for your reply! But as far as I understand without the "edit" permission they shouldn't be able to edit at all? They can edit pages (even in that namespace) without using the form. The error only occurs when they use the form to edit the page. Timo Müller (talk) 19:41, 19 August 2023 (UTC)

We tested some more. We deactivated all extensions with exception of Page Forms and Semantic Media Wiki. I created a very simple form with only one field and a simple template with only one parameter and tested it in both the namespace we use and the main namespace. We tried to reverse all changes we made to the localsettings.php. No matter what, the error still occurs. Timo Müller (talk) 23:15, 19 August 2023 (UTC)

We solved the problem! For some reason I don't understand (maybe some bug in Page Forms?) it seems like there is an edit conflict occurring whenever an unregistered user edits a page with a form (even if there is in fact no edit conflict as no other user edits the page at the same time). As diff3 wasn't working in our wiki, the "conflict" couldn't be resolved. Now that diff3 works, the error disappeared. Timo Müller (talk) 00:06, 20 August 2023 (UTC)

Good to hear you solved it! Cavila 10:05, 20 August 2023 (UTC)

Field Defaults and Free Text input stopped working with lastest Page Forms update

Miraheze recently updated to the latest version of Page Forms. After doing so Default settings for all Fields and Free Text inputs stopped working. They worked properly before updating. Specifically before updating, all default settings and free text inputs would load as they should; now fields using them remain blank as if they didn't exist. After reporting the issue to Miraheze's support team, they confirmed being on the latest update of Page Forms and suggested I report the issue here. Ertosiangel (talk) 23:01, 4 September 2023 (UTC)

Ooh, that's really bad - this turned out to be a real bug, due to a change I made two months ago. Sorry about the problem, and thanks for pointing it out. I just checked in the one-line (actually one-character) fix, here. Yaron Koren (talk) 13:30, 5 September 2023 (UTC)

Thank you for the quick reply. All of your work is appreciated; Page Forms is such a great extension! Ertosiangel (talk) 01:18, 7 September 2023 (UTC)

Bots and Page Forms

Is there a way for bots to interact with Page Forms? I'm trying to write a bot that will adjust a form value on the articles it interacts with. Some of the articles already have this value set, some do not. Is there a recommended way for my bot to edit these articles? 70.160.223.43 11:26, 18 September 2023 (UTC)

You can use the "pfautoedit" API action. Yaron Koren (talk) 13:16, 18 September 2023 (UTC)

Thank you very much! I didn't see that before.

I went through its documentation, and I've been able to add a value to a field on an existing page, but I ended up blanking the rest of the page. I thought maybe it was because of not using the preload, but that failed too.Would you be able to tell me what I'm doing wrong?

api.php?action=pfautoedit&form=Form-Name&target=Page%20Name&query=Form-Name[field]=value

api.php?action=pfautoedit&form=Form-Name&target=Page%20Name&preload=Page%20Name&query=Form-Name[field]=value 70.160.223.43 22:55, 18 September 2023 (UTC)

What version of Page Forms are you using? There were some bugs with field handling that were in the code from about mid-July to early September. Yaron Koren (talk) 02:03, 19 September 2023 (UTC)

I'm using version 5.6.1. I can download the latest version from github and try again later today. Could you tell me if the top or bottom line above is correct? 70.160.223.43 09:00, 19 September 2023 (UTC)

If it's really version 5.6.1, i.e. from April, then I don't know what would be causing this problem. But trying out the latest code could help, yes. The first one is correct - there's no need to use "preload". Yaron Koren (talk) 12:59, 19 September 2023 (UTC)

Bug regarding checkboxes and properties

In any form where you take checkbox, checkboxes or a dropdown and assign a property (values from property=) to them it doesn't work. A list with manual entries works. This bug has been already fixed in master branch, but not yet in 5.6.1. When is a release of 5.6.2 planned? Thank you! Driedmueller (talk) 07:54, 27 September 2023 (UTC)

Hopefully soon - it's definitely overdue. Yaron Koren (talk) 13:57, 27 September 2023 (UTC)

Data is not updated after editing

Hello!

I'm a beginner at MediaWiki.

After editing a form using the PageForms extension and clicking the 'Save page' button, the data is not updated in the 'Read' tab. This is relevant for Chrome, Safari (requires one more page refresh to get the correct content). Everything works fine in Firefox.

If I use Xdebug the data is saved correctly in any browser (I think this is due to the delays that occur when using Xdebug).

Notes:

• MediaWiki 1.39.2

• Page Forms 5.6

• Semantic MediaWiki 4.1.1

P.S. If I am the only one with this problem, please tell me in which code fragment I should look for the cause of this problem. Mikasa7 (talk) 08:28, 29 September 2023 (UTC)

Does the underlying wikitext look correct right after the edit? It sounds like yes - in which case this is not a Page Forms issue. I'm guessing your infobox template is structured in such a way that the page is querying itself (via SMW, in your case) to get its own data. If so, hopefully that's not actually necessary to do. But if it is, I'm not sure there's anything you can do to get around that problem of the data initially being old. Yaron Koren (talk) 13:27, 29 September 2023 (UTC)

I met the same situation as you last time when I use this "Page Forms" with "Cargo" together and try to create a new model page. And it turns out that I forget to update the cargo's database by using the commang "php update.php"in mediawiki's maintanance directory.As the Semantic MediaWiki is somekind the same as cargo, hope it will make some help for you and orther newcoming people. 240E:3B7:324B:7A10:3151:75E7:7B23:9364 13:28, 11 January 2024 (UTC)

{{#autoedit: deletes parameters which are not called

After updating from MW 1.35 to 1.39.5 and all other extensions it seems that the behavior of {{#autoedit: has changed.

The below example (which is called by a template) increases a counter parameter on a page. This works but by doing so it now deletes al other parameters in the template.

{{#autoedit:form=Some form|target={{FULLPAGENAME}}|link text=Update Page|link type=button|reload|minor|query string=Some template[count]={{#expr:{{{ttcount|}}} + 1}}}}

This was not the case before the update. The count parameter value was increased but the rest of the parameters where left alone.

I do not know if this is intended behavior but for the moment I solved this by passing all the parameters to the template so they stay on the page.

Could it have something to to with Field Defaults and Free Text input stopped working with lastest Page Forms update? We are running Page Forms version: (95b9a3a) and PHP version: 8.1.24.

Thanks and regards, Felipe (talk) 05:31, 3 October 2023 (UTC)

I did some more digging and found out that the below commit for PF_AutoeditAPI.php actually causes the above problem.

https://github.com/wikimedia/mediawiki-extensions-PageForms/commit/b93629951cfe3fb4d62fb4cf17cb659eb09c81aa

If I run 5.6.1 it works just fine like on the SMW sandbox website (also running 5.6.1).

I made an example on the SMW sandbox but as said it still runs 5.6.1 so the problem is not present. The number is increased when you press the Button but the other parameters are left alone.

So when I rollback the above commit on Master it is working again.

I hope this helps, thanks Felipe (talk) 07:41, 9 October 2023 (UTC)

Sorry about this (pretty major) problem, and thanks for the detective work. I just checked in what I think is a fix for it. Yaron Koren (talk) 17:25, 10 October 2023 (UTC)

This indeed fixes the problem but while testing I noticed another one which I missed before. It also (still) deletes all other text on a page which is outside the template. We use autoedit on pages which are completely created by the template, there is no "free text" so I did not notice this before. But on some pages we added the Category manually outside the template call and on those pages the Category calls where deleted. Yaron, I think it is not easy to maintain a piece of software in an ever changing environment Like Mediawiki and Page Forms (among others) is one of the more powerful extensions for it. So I want to thank you for your time and effort :-) Felipe (talk) 05:57, 11 October 2023 (UTC)

Yes, that was a real bug - thank you for pointing this out, and thanks for the kind words. I just checked in what I think is a fix. Yaron Koren (talk) 19:38, 11 October 2023 (UTC)

That fixed it thanks again :-) Felipe (talk) 05:39, 12 October 2023 (UTC)

MobileFrontend and datepicker

Does PageForms date picker work with MobileFrontend (really Minerva Neue I guess)? I've had a form working pretty well with an old MW 1.30 site, which didn't use datepicker. I've upgraded to 1.35, added a datepicker field which works just fine in the desktop version, but freaks out in the mobile version with JS errors such as "Skipped unresolvable module ext.pageforms.main" followed by "Error: Unknown module: mediawiki.action.edit". Tried upgrading PageForms to latest version to no avail, still not working. -

Is PageForms known to have such issues with MobileFrontend? MW 1.35 PHP 7.4.33 PF 5.6.3 EDIT: notably, when I remove the datepicker field, and replace it with simple dropdowns (year, month, etc) everything works but in the mobile version I get an annoying "spinning" animation on the screen, indicating that something has gone wrong indeed somewhere in the Javascript.

109.186.103.99 06:03, 28 October 2023 (UTC)

I'm surprised that this is failing - Page Forms was fixed a while ago to load all its JS in MobileFrontend as well. It could be that that strange "Unknown module: mediawiki.action.edit" error is somehow the cause of it. Maybe upgrading MediaWiki would fix the problem? Version 1.35 is somewhat old already. Yaron Koren (talk) 15:53, 30 October 2023 (UTC)

Good news: upgrading to 1.40 finally resolved it. Bad news: only after several new errors occurred, which were resolved in a very dirty way. I disabled all other extensions, so this really seems just PageForms-related. The first error was some infinite loop even for an empty form. The second was a weird error message on "Accessing $wgHooks directly is deprecated". Both were resolved after upgrading PF to the version for MW 1.41. Third, and more crucially, the server kept screaming about a misplaced <br /> tag. Only resolved after I manually switched all <br /> tags in specials/PF_CreateForm.php to <br>. All this was really just really dirty and amateurish debugging. I have no idea if what I did is sustainable. But I'm pretty sure all these errors shouldn't have happened. 109.186.103.99 20:40, 31 October 2023 (UTC)

Options for each input type other than "text" not appearing at Special:CreateForm

This afternoon, on my creative-venture wiki, I returned to Special:CreateForm for my first new form since earlier this year. So far, so good, right? Although PF may have already been refreshed, its CreateForm function (at this writing) does not bring up any other options beyond those for the default "text" input type, when any of those are chosen via dropdown. After those defaults get set up, the correct types are reflected in the "Show preview" output.

Which brings to mind a similar filing from back in late 2021:

Back on the desktop interface, adding the name and template successfully goes through--but once you select an input type other than "text", the "Other parameters" sections are immediately disabled, and you can't unhide them with the little "[+/-]" button on the top left. Javascript issues, I assume? Or maybe this began with last month's update?

Any word or hint on what's causing this season's deficiency, @Yaron Koren? Or did I miss a simple step in the process?

(MW 1.40/PHP 7.4.33)

--Slgrandson (talk) 23:04, 27 October 2023 (UTC)

Apparently it may be my browser (MS Edge 117.0.2045.47 on Windows 10 [Dell Laptop]), because the deficiency is still present even after the usual cookies-and-cache clearing. On mobile Chrome (on my Galaxy Tab A), the options show up just fine, so I guess I'll have to use CreateForm there until further notice (or my Edge/Windows install upgrades). As for the Edge issue, Koren, any further comments? --Slgrandson (talk) 06:40, 28 October 2023 (UTC)

This turned out to be a bug in Page Forms, from 2021 (I should have looked more into it when you first reported it). It wasn't browser-specific, the problem was across all browsers. I just checked in a fix for it - if you get the latest code, hopefully everything in Special:CreateForm will work. Yaron Koren (talk) 14:13, 30 October 2023 (UTC)

"Summary" field is available with {{#autoedit}}, but not {{#formredlink}} for some reason

In its current state, {{#formredlink}} does not leave a summary behind, not even with the "|summary=" field filled in. Can you look into implementing this in a future update?

And before you ask, Miraheze does not support $wgPageFormsAutoeditNamespaces at this writing, but it doesn't hurt to see if we can ping their currently short-staffed Phabricator team for help/advice. (Second filing by yours truly in the past 18 hours). --Slgrandson (talk) 15:18, 28 October 2023 (UTC)

There's no "summary" parameter for #formredlink. Which makes sense, I think - it's up to the user to set the summary during their edit. Yaron Koren (talk) 13:10, 30 October 2023 (UTC)

MultiPageEdit - No deleting existing parameter values?

How can I delete existing parameter values in (Page Forms 5.6.3) MultiPageEdit?

I can:

• Add pages, their templates/params/values (works great).
• Change a page's param values (works great).

However, I cannot:

• Delete an existing parameter's value.
  • Anytime I click a cell and delete a previously entered/saved value, it appears deleted (cell is empty) but several problems appear:
    • If deletion was the only operation for that page/line, no check mark to save appears.
    • Example: For one single page/line, I change cell-A parameter value to a different value, then its cell-B I delete its value. The check mark appears for that line, but after checking it to commit the change, only cell-A's value changes, cell-B's deletion is not made, the value remains as it was previously entered.

Is this a bug? If not, how is value deletion done in PageForms (latest version)?

• MediaWiki: 1.39.4; PHP: 8.0.28 (cgi-fcgi); MySQL: 8.0.28-0ubuntu0.20.04.3
• Page Forms 5.6.3

Thanks! ~ FrozenPlum (talk) 22:37, 30 October 2023 (UTC)

After reverting to Page Forms 5.6.1 deletion works, perhaps this is a bug unintentionally introduced in a recent change. Thought this info might help! 23:00, 30 October 2023 (UTC)

Further testing shows:

• PageForms 5.6.2 deletion works (grabbed today, and version I'll use for now).
• PageForms 5.6.3 deletion is broken (grabbed today).
• PageForms master deletion is broken (grabbed today).

I can't spot the change that broke it, hopefully this helps. ~ FrozenPlum (talk) 00:58, 31 October 2023 (UTC)

Sorry about the bug, and thank you for the diagnosis. I can't replicate the problem with the check mark not appearing - maybe you just need to hit Enter after blanking the value? But the main problem, with blank values not getting applied, was a real one. I just checked in a fix for it here; hopefully it works fine now. Yaron Koren (talk) 16:34, 7 November 2023 (UTC)

MultiPageEdit deleting content outside its template

Per the above, I'm using * MediaWiki: 1.39.4; PHP: 8.0.28 (cgi-fcgi); MySQL: 8.0.28-0ubuntu0.20.04.3; Page Forms 5.6.2 (as 5.6.3 can't delete values).

After deleting parameter values for a single page, and pressing the MultiPageEdit check mark to commit the change, I check the page diff and see the category formerly in the page, directly below/outside the template, was also deleted. I'll try going back a version again and see if this issue resolves (can't go forward per above). FrozenPlum (talk) 15:47, 31 October 2023 (UTC)

• Confirmed this issue emerged also in PageForms 5.6.2, reverted to the 5.6.1 which appears to be the "safe" version to use currently.

~ FrozenPlum (talk) 16:06, 31 October 2023 (UTC)

Max-width for combobox

I want to make the input fields of my comboboxes as wide as the selected value, but I can't figure out how to remove the large empty space (padding-right) after the text, which seems to increase the longer the input value is. The comboboxes are not infusable, so I need to use CSS, but I'm not sure which of the many combobox elements I should target for this, or what CSS properties to apply. Is there an "autogrow" equivalent to comboboxes as there is for textarea (height) in Page Forms? Tahoma403 (talk) 05:28, 1 November 2023 (UTC)

Sorry, these sound like OOUI questions (combobox is implemented via OOUI); and I don't know much more about OOUI than what's in their documentation, and what I've been able to change around through trial-and-error. I should note that there is a long-term plan to switch combobox - along with most of the rest of Page Forms' inputs - to use MediaWiki's Codex library, which may help with some of the display. Yaron Koren (talk) 18:50, 1 November 2023 (UTC)

VisualEditor not working in textareas

This problem manifested when I upgraded from MW 1.35 to 1.39. I currently have PageForms 5.6.3 (e725a1a) installed (downloaded today using the command git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/PageForms.git).

When edit with form is used and the form includes {{{standard input|free text|editor=visualeditor|class=toolbarOnTop}}} the free text box is displayed in the form, but it only has raw wikitext, and the contents of the free text box are greyed out--the user cannot edit the text. Then if "Save" is selected, the page saves as if the text box were completely blank.

VisualEditor otherwise functions normally.

I have these lines in the LocalSettings file.

$wgDefaultUserOptions['visualeditor-enable'] = 1;

$wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";

I enabled debug data and I don't see any errors. Any suggestions would be much appreciated. Lost Student (talk) 21:59, 15 November 2023 (UTC)

What version of VEForAll are you running? Yaron Koren (talk) 22:05, 15 November 2023 (UTC)

I should've checked that before I posted. I thought it was the most recent, but upon checking, it wasn't.

It was 0.4 (f3084d1). I updated to the most recent (0.5.1 (f3084d1)) and that solved it. Thanks! Lost Student (talk) 22:30, 15 November 2023 (UTC)

Great! Yaron Koren (talk) 01:42, 16 November 2023 (UTC)

Auto create other page when submitting form

I've read the documentation about #autoedit, but instead of creating a clickable link for this function, can I automatically create a new page when a form is submitted?

The form I'm using (with Cargo) has different fields, including "Year". If a user submits data through the form and there's no existing page with the title of the year entered, I want to create it automatically. Is this possible with Page Forms or would I need an extension like AutoCreatePage? Tahoma403 (talk) 10:34, 25 November 2023 (UTC)

Yes, thankfully - you can do it with a call to #formredlink in the template, with the "create page" parameter. Yaron Koren (talk) 16:22, 27 November 2023 (UTC)

Uploadable file description

I want to allow users to upload images that will be displayed as an embedded gallery in specific pages. Is there a way with an uploadable field to also let users include a description for an uploaded image, so that the description will be automatically the image's description in the wiki? 109.186.125.163 11:20, 25 November 2023 (UTC)

Yes - you can do it with a multiple-instance template in the form, where the template holds a single image as well as a description field. If you're using Cargo or SMW, any other page can then query and display that data in a gallery format. Yaron Koren (talk) 16:26, 27 November 2023 (UTC)

Prevent same value in field1 and field2

Can I trigger an error if the user enters the same value in two separate fields? Tahoma403 (talk) 05:04, 31 December 2023 (UTC)

I don't think so, unfortunately - other than with custom JavaScript. (Though the only reason I can think of that someone would want to do that is if there are fields like "Skill 1", Skill 2", etc. - and if that's the case, it's better to just have a single field called "Skills", with comma-separated values.) Yaron Koren (talk) 18:27, 1 January 2024 (UTC)