Extension talk:Page Forms/Archive January to March 2022

Auto-generated unique page title w/ auto increment ids

Hi, I am struggling with this extension. What I want to create is an issue tracker. If a user visits Form:Issue, there should be an only button that says "New issue" without any text field. If the user clicks the button, Special:FormEdit/Issue/Issue:1 (or Special:FormEdit/Issue/Issue:2 If the page exists) should be opened. I thought {{{info}}}, <unique number> or {{#forminput}} are the key, but now I'm not sure about anything.

Regards. Lens0021 (talk) 08:41, 11 January 2022 (UTC)

You're close - you need {{{info}}} and <unique number>, but {{#formlink}} instead of {{#forminput}}; see here. Yaron Koren (talk) 15:47, 11 January 2022 (UTC)

Thank you!! Lens0021 (talk) 02:42, 12 January 2022 (UTC)

[RESOLVED] Cannot save form after invalid URL entered

When I type an invalid URL (for a URL input type) the must have the correct URL format, starting with "http" message appears correctly but the "Save page", "Show preview", "Show changes", and "Cancel" buttons/links are all greyed out. When you click on the first three (buttons) they return the screen to the top of the page, but do nothing else. The "Cancel" link does work though.

This is on a MW 1.35 wiki (same result for REL1_35 and master branches) using Vector. I don't have the same problem on a MW 1.34 wiki. Disabling the extra extensions from the 1.35 wiki made no difference. Any ideas? Jonathan3 (talk) 09:43, 11 January 2022 (UTC)

I tried this out, and saw some strange behavior that's not quite the same, but maybe due to the same cause. I just checked in a fix - if you can, please get the latest code and let me know if that fixes the problem for you. Yaron Koren (talk) 19:11, 11 January 2022 (UTC)

I'm afraid not. Jonathan3 (talk) 22:03, 11 January 2022 (UTC)

Just tried a blank mandatory field and it had the same effect. Jonathan3 (talk) 22:09, 11 January 2022 (UTC)

Yes, okay - there were two separate problems, and the first one prevented me from seeing the second one. I just checked in another fix; please try it out if you can. Yaron Koren (talk) 18:18, 12 January 2022 (UTC)

It's an improvement, thanks, but still doesn't work... They're not greyed out any more, and "Show preview" works. "Save page" clears the error messages (page, and field-specific) if the field content is now valid, but the fields remain red-coloured, and the page doesn't get saved. "Show changes" does nothing. "Cancel" still works. Jonathan3 (talk) 23:22, 12 January 2022 (UTC)

Sorry again! This was sort of three problems in one. (Well, at least three.) I just checked in another fix - please let me know if that solves the problems. Yaron Koren (talk) 18:54, 13 January 2022 (UTC)

No problem! Thanks for the quick responses. It works well now :-) Jonathan3 (talk) 22:36, 14 January 2022 (UTC)

Textarea input type with "Edit with form" doesn't work as well on mobile as the normal "Edit" box

On the normal MediaWiki "Edit" box you can make the text scroll up and down by moving your finger up and down the mobile screen. The input box itself doesn't move.

On a PF textarea input type, this works the same when no parameters are set (or if only rows= is set).

But as soon as you set autogrow, it's the input box that moves, taking the (unchanged) text with it. So if you go to edit a page which has 100-lines of text in a box smaller than that, it's not easy to scroll through the text.

Is there any way to fix this, or is it just part of how "autogrow" works? Thanks. Jonathan3 (talk) 10:21, 11 January 2022 (UTC)

I don't know. Maybe "autogrow" should just be disabled in the mobile view? Yaron Koren (talk) 19:14, 11 January 2022 (UTC)

I've stopped using it entirely now. It was a pain on the desktop too when it was the wrong size for the text already in the field. It's probably good for a field containing just a few lines. Jonathan3 (talk) 12:11, 17 January 2022 (UTC)

[RESOLVED] Rename Special:RunQuery when embedding form

When a form is embedded on a wiki page using {{Special:RunQuery/query form name}}, is there any way to rename the results page from Special:RunQuery? Thanks. Jonathan3 (talk) 22:34, 14 January 2022 (UTC)

Sorry, I don't understand this question. Yaron Koren (talk) 00:45, 17 January 2022 (UTC)

When a query form is run, including let's say on a page called "My search", the results are shown on a page called "Special:RunQuery". But I've worked out the answer - using DISPLAYTITLE is possible after all, once Manual:$wgRestrictDisplayTitle is changed. I should have checked before asking! Jonathan3 (talk) 12:00, 17 January 2022 (UTC)

[RESOLVED] Modify "This category uses the form" text

I know it's possible to hide and replace it with other text, but is there any way of editing this message site-wide? This would also avoid the problem where spam blacklist objects to hiding via a CSS style Jonathan3 (talk) 19:00, 20 January 2022 (UTC)

Yes - you just need to edit the page MediaWiki:pf_category_hasdefaultform. Yaron Koren (talk) 14:12, 26 January 2022 (UTC)

That worked, thanks. For some reason I didn't see the message page name when using uselang=qqx. Jonathan3 (talk) 17:45, 26 January 2022 (UTC)

Comma-separated field from External Data

When a List (,) of String field with a tokens input type takes its values from an External Data variable (e.g. {{{field|Fieldname|input type=tokens|values from external data=fieldname}}}) and the external data is comma-separated the whole thing gets tokenised (e.g. A, B, C). When the page is saved and re-edited, the form correctly shows the field (e.g. A B C). Is there any way of getting the field to be tokenised as soon as the external data value is selected? Thanks. Jonathan3 (talk) 09:24, 26 January 2022 (UTC)

Multiple "free text" boxes

I am interested in making a page with several forms on it (call them form A, form B, etc.), each of which can appear zero or more times. I was trying to make section titles appear in the published page above the forms, i.e. I would have one section title above all the forms of A, and another for all the forms of B. In addition, I wanted each title only to appear if the form was instantiated at least once.

An idea I had to do this was to add a category or property to the template of A, B, etc. Then, I could show the titles by querying if the published page with all the forms on it has the desired property/category.

The main issue I am encountering is that I cannot figure out how to put text above each one of the forms automatically. I can't put it into the form template, because then the section titles could occur multiple times. I tried using hidden "free text" boxes, but they do not cooperate, I guess I cannot have free text boxes in all these positions unambiguously.

Is there a good way to solve this issue?

By "forms", I think you mean templates, and specifically multiple-instance templates. But you're right that a section can't be put in a multiple-instance template, because there can't be more than one section with the same name - and similarly, you can't have multiple "free text" inputs either. The only thing you can really do is have a template field that's edited with a "textarea" input. Which is not quite as flexible as a section or free text input, but hopefully it's good enough. Yaron Koren (talk) 04:57, 28 January 2022 (UTC)

Namespace integration in multi-word NS titles

Happy New Year, Mr. Koren. As I return to extension bug reporting:

A few days ago, I created a project page for a namespace entitled "From the Author". (Abbreviated as "FTA", this feature serves as a continuation of my long-running social-media feeds, once hosted elsewhere.) Per PF's guide, an "Edit with form" tab should appear above its pages, but doesn't at this writing. (All other namespaces covered by this scheme have single-word titles and display it just fine.)

Unforeseen bug, or lack of support?

P.S. Just letting you know that Referata's been offline since last Thursday, and that's getting in the way of an urgent, months-long import-rescue campaign (slow servers or not). New DNS holdup, I assume?

P.P.S. Another bug report should be forthcoming, entering February.--Slgrandson (talk) 08:17, 28 January 2022 (UTC)

To @Yaron Koren: Bumping (half a month later) with URL details so that this issue might be looked into at some point (as well as Referata's current absence):

• NS project page: https://constantnoble.miraheze.org/wiki/Project:From_the_Author
• Specimen target page: https://constantnoble.miraheze.org/wiki/From_the_Author:2021/End-of-year_report
• NS alias: FTA

--Slgrandson (talk) 22:40, 16 February 2022 (UTC)

Token field does not filter value list

Hi, I created form with a token field, with values from category. Unfortunately, when I start typing, I see the correct list of values but it is not filtered by my input. Moreover, whatever I typed, when I press enter the value is always the first element of the list...

• PF version 5.3.4, MW 1.35
• Tested with Firefox and Yandex browser
• Javascript console contain a warning :

   JQMIGRATE: jQuery.fn.offset() requires an element connected to a document 

problems with autocomplete on property

Hi there, after a very long time my company finally updated our used Wiki thus switching from Semantic Forms to Page Forms. Now we have the problem that "autocomplete on property" stopped working. Furtheremore the Extension isnt listed on Special:Versions of our BlueSpice driven Installation. So sadly i cant name the extensions version. Here is the inputs code: {{{field|OrgE|autocomplete on property=Organisationseinheit}}} Is the behavior intended? Is there a workaround? Kind regards Ciannicay (talk) 16:37, 3 February 2022 (UTC)

Yes, "autocomplete on property" was removed a while ago. Try "input type=combobox|values from property=..." instead. (Or "tokens" in place of "combobox", if the field is meant to hold multiple values.) Yaron Koren (talk) 17:09, 3 February 2022 (UTC)

Thats a bummer. As the number of values exceeds 200 a combobox or similar is not an option. And it is supposed to hold a single value only. Is there any hope this option might come back? Kind regards Ciannicay (talk) 08:30, 4 February 2022 (UTC)

Furthrtmore the code {{{field|Firma|autocomplete on category=Externe Partner}}} does not work either *sigh* any ideas what might be wrong? The site is company internal only so i cant give a link. Kind regards Ciannicay (talk) 08:44, 4 February 2022 (UTC)

What's the option that you're hoping will come back? And "autocomplete on category" was similarly replaced with "values from category". Yaron Koren (talk) 14:11, 4 February 2022 (UTC)

Never mind, i just didnt get it earlier. As i have properties with more than 300 values that were used for autocomplete I dont see that this will be usable with a combobox. Let alone that there wont be the ability to still enter unmatched entries. So i take it there will be no autocoplete anymore at all and no hope that it might come back in future? kind regards Ciannicay (talk) 09:09, 8 February 2022 (UTC)

The "combobox" input type should work fine with any number of autocompletion values - as should "tokens", for that matter. Yaron Koren (talk) 14:44, 8 February 2022 (UTC)

[RESOLVED] Troubleshooting 'Create with form' tab

I couldn't setup the 'create with form' tab. Could anyone help me?

• My wiki: https://wordles.miraheze.org/ (Hosted by Miraheze, thus on MW1.37 and PHP7.4 etc) (verify)
• The targets should show 'Create with form' tab but don't: All pages on the main namespace.
• The parsed content of [[MediaWiki:pf_blank_namespace]]: Main (verify)
• The content of [[Project:Main]]: {{#default_form:App}} (verify)
• The content of [[MediaWiki:Blanknamespace]]: (Main) (verify)
• The pageprops of [[Project:Main]]: { "PFDefaultForm": "App" } (verify)
• Examples don't show 'Create with form' tab: action=view link and action=formedit link
• Note:
  • $wgPageFormsRenameEditTabs and $wgPageFormsRenameMainEditTab are false.
  • The content language of the wiki: English (verify)
  • I am using Project as a metaNamespace by explicitly defining $wgMetaNamespace = 'Project';

Lens0021 (talk) 09:26, 8 February 2022 (UTC)

Thanks for this detailed layout. It looks like the problem is those slashes in the page names - e.g., "https://test.url/" - by default, MediaWiki considers any page whose name contains a slash to be a subpage, and Page Forms doesn't apply the default namespace forms to subpages. So, I see two possible solutions to this: (1) Disable subpages in the main namespace, by adding "$wgNamespacesWithSubpages[NS_MAIN] = false;" to LocalSettings.php; or (2) Change page names to be something other than a URL. Either one should work. Yaron Koren (talk) 14:53, 8 February 2022 (UTC)

First one works for me, Thank you very much! Lens0021 (talk) 15:09, 8 February 2022 (UTC)

Field labels and tab index

I am missing a label-field association as well as a tabindex to get through completing a form using the keyboard. Is there any technique I could use to accomplish this with page forms?

Is tabindex not working for any of the inputs, or just some of them? And if it's just some, are there certain input types that seem to lack it? Yaron Koren (talk) 20:06, 14 February 2022 (UTC)

#forminput: autocomplete on category= is not working

MediaWiki	1.35.2
PHP	7.4.27
Semantic MediaWiki	4.0.0
Page Forms	5.3.4

forminput: autocomplete on category= is not working properly When I start typing the list displays, however is doesn't filter the list based on the characters I'm typing. Is there something I'm missing?

Wow! This was a bug introduced a few months ago, but somehow no one pointed it out until now. Sorry about that; I just checked in a fix for it. Yaron Koren (talk) 20:05, 14 February 2022 (UTC)

All good now, thanks Plegault3397 (talk) 12:48, 15 February 2022 (UTC)

@Yaron Koren, I tried this on another server and I'm not able to get the patched version again to fix the autocomplete. Plegault3397 (talk) 15:02, 14 March 2022 (UTC)

You mean, you can't get the right version, or you have the right version but it's not working? Yaron Koren (talk) 15:17, 14 March 2022 (UTC)

In the version on the working site I get Page Forms 5.3.4 (27db083) and the site I can't get it to work on just Page Forms 5.3.4. I used composer to install on both sites "mediawiki/page-forms": "^5.3.4",.

Plegault3397 (talk) 16:28, 14 March 2022 (UTC)

Right, this fix was made after version 5.3.4, so you probably can't use Composer to get the code that includes this fix (although maybe you can - I still don't know that much about Composer.) Yaron Koren (talk) 20:22, 14 March 2022 (UTC)

I tried without and received an error, I will try again and see what happens. Plegault3397 (talk) 22:00, 14 March 2022 (UTC)

I tried again this morning and it worked installing it manually. the odd thing is that on my other system I installed that version through composer on our other system using the same version of composer. Plegault3397 (talk) 10:29, 15 March 2022 (UTC)

Where can we find this patch? Manu.wikidebats (talk) 18:31, 15 April 2022 (UTC)

You have to take out of composer.json and download it manually.

git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/PageForms.git

148.74.149.177 18:39, 15 April 2022 (UTC)

Thanks so much! It works perfectly now. Manu.wikidebats (talk) 19:29, 15 April 2022 (UTC)

Ordering radio inputs

How does one order radio-inputs ? The labels seem to be displayed in alphabetical order from what is outputted by my mapping template, but that order does not follow the logic of the form. Rather, it would make sense for the radio inputs to follow the order given by the values field parameter. Thanks ! Tinss (talk) 04:09, 16 February 2022 (UTC)

Size parameter is not included in #forminput

Hi. In Page Forms 5.3.4, I am trying to set the size of a #forminput element and it seems it is being ignored at the moment. The size remains the same (default: 25) regardless of the size value I use in my parser function call. Inspecting the form input element on the page doesn't show any size parameter in the HTML element. --Lalquier (talk) 15:17, 16 February 2022 (UTC)

Yes, "size" is no longer handled for #forminput, since the changeover to OOUI about a year ago; that's a bug. Yaron Koren (talk) 17:26, 16 February 2022 (UTC)

Workaround: change the width directly in the css :

.pfPageNameWithoutNamespace {
  width: 200px;
}

--Megajoule (talk) 06:47, 30 March 2022 (UTC)

Sorry - I forgot to mention it here, but a fix for this was actually checked in later in February - see here. If you have a version of the code from then or later, you should be able to set the width with "size" again. Yaron Koren (talk) 16:37, 30 March 2022 (UTC)

Extremely slow form rendering using autocomplete from large namespace

I have a form field defined as {{field|foo|input type=text with autocomplete|uploadable|values from namespace=File|image preview}}. This pulls in all files as an option in my input. In previous versions of Page Forms, the form would render in a reasonable amount of time, with autocomplete working. In the current version of PF, however, this form takes a very long time to load (over 60s). I tracked it down to a change that causes PF to loop through all possible values for an input server-side (commit: https://github.com/wikimedia/mediawiki-extensions-PageForms/commit/d5c5194107efed2dde70a77c3630a133722eea4c). If I comment out the foreach ( $possible_values as $possible_value ) { block, the form renders fast again, and autocomplete still works. I'm curious if there's a reason for this block to exist, and if there's a better solution than just commenting out code. Sazpaimon (talk) 20:02, 17 February 2022 (UTC)

Given a large-enough number of autocompletion values, the code is supposed to switch from "local" to "remote" (API-based) autocompletion, so that it shouldn't need to cycle through all the values. So this sounds like a bug. However, you're using the "text with autocomplete" input type, which is deprecated - so if you just switch to "input type=combobox", I assume the problem will go away. Yaron Koren (talk) 21:34, 17 February 2022 (UTC)

No luck, even with a "combobox" type it still tries to iterate through every option. I should also note that the resulting final HTML excludes all the options in the output, so something is indeed stripping it out, but it's still doing some sort of processing of the options on the backend request before that. Sazpaimon (talk) 21:54, 17 February 2022 (UTC)

So I looked a bit deeper, and it seems that PFValuesUtils::getAllPagesForNamespace does not take into account the $wgPageFormsMaxAutocompleteValues setting, unlike, for example, PFValuesUtils::getAllPagesForCategory. Adding in that limit improves the performance, but I don't know enough about PF internals to know if that's the correct change. Sazpaimon (talk) 22:03, 17 February 2022 (UTC)

What version of Page Forms are you running? Yaron Koren (talk) 00:55, 18 February 2022 (UTC)

I'm running 5.3.4 Sazpaimon (talk) 01:25, 18 February 2022 (UTC)

Wow, yes! Indeed, that whole loop is unnecessary - and so is the equivalent one for the "tokens" input. I just removed that loop from both, so now loading of forms should go faster for inputs with a huge number of possible values. I don't know how this problem went undiscovered for so long, but I'm glad you caught it; thanks. Yaron Koren (talk) 21:09, 18 February 2022 (UTC)

Thanks! I tested it out, and while it does indeed fix the loading time, it's now not showing a pre-set value when editing an existing page via form. I believe it's because you're now no longer adding the option tag for the selected option because of the $isValueInPossibleValues check. You can probably remove that check altogether. Sazpaimon (talk) 23:17, 18 February 2022 (UTC)

Sorry about that - I didn't realize that this was a problem. I just removed the check. Yaron Koren (talk) 05:16, 21 February 2022 (UTC)

PF and Wikieditor in MediaWiki 1.35.5

Can anybody tell me how to get PF (latest version or even better 5.2.1) working with Wikieditor? I followed the instructions. I am using WikiEditor from git, branch REL1_36 which is working in 1.35 and has already the patch in. It is supposed to work with PF > 5.1, but is not. Does anybody have a working Wiki with Wikieditor in MediaWiki 1.35.5 and tell me how to do this? https://phabricator.wikimedia.org/T284307

Issues with editing form with free text above sections

I have a form defined like this:

{{{info|create title=Add page|edit title=Edit|page name=FreeText}}}
<includeonly>

=== Free Text ===
{{{standard input|free text|rows=10}}}

=== Section 1 ===
{{{section|Section 1|level=2|autogrow|hide if empty}}}

{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
</includeonly>

I create a page with this form with the free text field populated, and "Section 1" empty, the next time I edit this page with the form, the free text area gets included in section 1. This happens in forms with multiple sections as well, with the free text field being thrown into the first empty section. This was not an issue on the previous version of Page Forms I was using (4.8), so I'm not sure if this is a bug or the form definition I'm using was not correct. Sazpaimon (talk) 05:12, 21 February 2022 (UTC)

Is it be possible to have a form that displays rules for editing which if the user accepts gives them the role of "Editor" to edit on the wiki site?

Hello all, I am trying to create a site where I have found it to be useful if a user can only get edit access by reading some rules on editing on the site, to which if they accept the rules then they would get an "Editor" role. For context I have restricted all ordinary users from edit access, and enabled edit access to a role called "Editor". So if someone wants to become an "Editor" and contribute, they must go to the form, read all the rules, and then accept them. I want this because then the users becoming Editors would know the rules of editing, and so that some random users come on can't just do anything without knowing that that they have to abide by said rules. If anyone could tell me if it is possible with this extension and point me in the right direction that would be great. Thanks.

You could have them hit "Save" at the bottom of a form to prove that they read the text, but then giving them edit access would have to be done manually. (Unless you wanted to do some custom coding, to try to automate it.) Yaron Koren (talk) 19:06, 24 February 2022 (UTC)

Combobox autocomplete on sub pages?

Hi. Is possible to lookup sub-pages in a combobox with an autocomplete by Category? I am using Page Forms 5.3.4 and SMW 4.0, and autocomplete only returns the top level pages when sub-pages are involved. (I also tried looking up using a text property with the title of the pages, but I am running into a separate bug which I will report separately after more tests). Lalquier (talk) 20:54, 2 March 2022 (UTC)

Hi - there's no "autocomplete on subpages" setting, so no, I don't think so. Let me ask, though: why do you want to do this? If there's a page that belongs to a category called, say, "People", would a subpage of it also define a person? Yaron Koren (talk) 00:21, 3 March 2022 (UTC)

I have a list of pages about technologies services defined as sub pages to support better navigation and tree views. Values look like this 'Communication/Zoom', 'Communication/MS Teams', 'Software Engineering/APIs', 'Software Engineering/Cloud services' etc... if I look for 'Cloud services' in the combobox, the value 'Software Engineering/Cloud services' doesn't come up. I need the '/' in the value selected because it is an actual page name. That's just one example.. this applies to any sub-page structure in the wiki. Being able to extend the search to include sub-pages would be very useful here. Lalquier (talk) 15:51, 3 March 2022 (UTC)

Alright, that makes sense. It seems to me that the best solution is to just add all those pages to the same category - or a sub-category of it. Yaron Koren (talk) 21:15, 3 March 2022 (UTC)

That's the thing. They already are part of the same category.

If I use listbox, I can see all the values:

{{{field|Service offerings|input type=listbox|values from category=Service offering|size=20}}}

But if I use tokens or combobox, the autocomplete only works when searching in the top level of the page structures and not in the subpages:

{{{field|Service offerings|input type=tokens|values from category=Service offering|size=20}}} Lalquier (talk) 04:39, 4 March 2022 (UTC)

Okay, now I understand the problem - for a page name like "This Is/A Page", Page Forms will autocomplete on "This", "Is" and "Page", but not "A", because it doesn't see that as the beginning of a word. That definitely seems like a bug - slashes should be considered word delimiters, as should maybe other characters like dashes, quotation marks and parentheses. Until that's fixed, you can sort of get around the problem by adding $wgPageFormsAutocompleteOnAllChars = true; to LocalSettings.php. Yaron Koren (talk) 21:57, 8 March 2022 (UTC)

I just checked in a fix for this, by the way, here. Yaron Koren (talk) 16:30, 25 April 2022 (UTC)

"Edit with form" only shows non-existant pages in "tokens" field

I currently have the problem that the "edit with form" page only shows non-existant (red link) pages in my tokens input field. If I use the regular "edit" button, all pages listed correctly in the template.

My pages represent places in a city with different streets assigned to it via page forms. When I create a new page with a form and include "A Street" and "B Street" (for which pages were already created) and "Test Street" (which does not exists yet), only "Test Street" is shown in the tokens input when I want to edit the page on the "edit with form" page. "A Street" and "B Street" are shown correctly in the info box and also on the regular edit page (as parameter in the template: "|Street=A Street, B Street, Test Street")

MW 1.35.5

SMW: 4.0.0

PF: current dev (updated 2021-03-09) 78.35.151.198 12:31, 9 March 2022 (UTC)

Sorry about that! This was due to a poorly-thought-out change I made about three weeks ago. I just checked in a fix for it. Yaron Koren (talk) 01:32, 11 March 2022 (UTC)

Thanks for the quick fix, much appreciated! Works like a charm again. 78.35.151.198 07:44, 11 March 2022 (UTC)

Get value of forminput-value

I currently have the following problem:

I am creating pages with {{#forminput:form=...

When the user enters the page name to the forminput field and create a page, the input value (=page name) should be the default value of a semantic field of the created page.

I imagine something like that:

query string=namespace=Schule&=Page Forms/Archive January to March 2022&Contact[Name]=INPUT-VALUE

==> new Page created, the field "Contact[Name]" should get the name of that page

Do you have a solution for that?

Thanks a lot!

Mrgraw

Mrgraw (talk) 12:56, 9 March 2022 (UTC)

The one-step process (with #formlink instead of #forminput) may be helpful for this case. Yaron Koren (talk) 15:37, 9 March 2022 (UTC)

Thank you for your help. With #formlink it is not possible to enter a page name. It is necessary that the user enters a page name in the #forminput. Mrgraw (talk) 15:42, 9 March 2022 (UTC)

Okay, I misunderstood the question before - now I think I get it. I think the best approach is to put a note in the form, near the field, that says something like "Leave this field blank to set it equal to the page name." Then, assuming you are using Semantic MediaWiki, you could have something like [[Contact name::{{{Name|{{PAGENAME}}}}}]] in the template. Yaron Koren (talk) 16:11, 9 March 2022 (UTC)

Thank you :)

I tried to set a default value for the semantic field in the form because i need so save the value to the semantic attribute:

{{{field|Name|input type=text|default={{PAGENAME}}}}}

The result is a print of two closing curly brackets ( }} ) - so it does not work. Maybe you have an other idea :) ? Mrgraw (talk) 17:29, 9 March 2022 (UTC)

I think my idea is superior, but if you want to try that approach instead, you might just need to put a space between the "}}" and the "}}}". Yaron Koren (talk) 17:50, 9 March 2022 (UTC)

OMG yes, this is the solution. It could be so easy sometimes. Thanks a lot!! :) Mrgraw (talk) 17:57, 9 March 2022 (UTC)

Page forms - input type=tokens

Hello,

I'm currently struggling with kind of a 'mysterious' problem in the context of "Page forms, Input Type Tokens". One input line in my form is defined as as a field "hasInvitationList" of input type=tokens and values(#arrayprint:arrMA|;|@@@@|@@@@). "hasInvitationList" is an attribute of data type Page

The corresponding attribute is placed in the "Incorrect Attributes" list and a warning appears in the associated template. I assume that the limitation is not reached by the number of "tokens", but set by the total length of the string (semicolon-separated array).

Is there a parameter that limits the length of the input field of type Tokens? Or any known work-around? I use: MediaWiki 1.35.5; Semantic MediaWiki 3.2.3 and PageForms 5.3.4.

Thanks for your comments. Dietmar DietmarTrees (talk) 14:42, 9 March 2022 (UTC)

If the issue is a warning message displayed on the page, that sounds like a Semantic MediaWiki problem, no? It doesn't sound directly related to forms. Yaron Koren (talk) 15:39, 9 March 2022 (UTC)

Restricted + datetimepicker/datepicker + default=now => champ=now and restricted doesn't work

MW 1.35.4 / SMW 3.2.3 / PF 5.2.1
{{{field|commentDate|property=commentDate|input type=datetimepicker|date format=DD/MM/YYYY|mandatory|default=now|restricted=FellowshipOfTheWiki}}} does not have the desired effect: the field remains modifiable despite the parameter "restricted" and the value recorded in the template is "now" (even if there is a space behind the "now").

Same problem with datepicker.

Solution found: use datetime and not datetimepicker Megajoule (talk) 15:25, 9 March 2022 (UTC)

You're using a relatively old version of Page Forms; I don't know if that's the issue or not. Yaron Koren (talk) 15:35, 9 March 2022 (UTC)

OK. I'm going to upgrade my system. --Megajoule (talk) 15:48, 9 March 2022 (UTC)

The problem remains with version 5.3.4. --Megajoule (talk) 21:54, 21 March 2022 (UTC)

And version 5.4 --Megajoule (talk) 12:14, 26 April 2022 (UTC)

Better sorting of autocompletion suggestions

I think a good improvement would be that, in case a result is an exact match of what is typed, the exact match be displayed as the first result. So this result would be pre-selected : it really improves productivity as you can simply press Enter after typing what you know is the exact match.

Exemple :

https://cdn3.bbcode0.com/uploads/2022/3/14/724351772f76da031b6e3c76d5452958-full.png Varlin (talk) 15:01, 14 March 2022 (UTC)

I second this suggestion. May214 (talk) 17:27, 16 March 2022 (UTC)

Remote autocompletion failed due to wrong formatted SQL-statement (PostgreSQL and probably others)

Setting

…
$wgPageFormsMaxAutocompleteValues = 10000;
$wgPageFormsMaxLocalAutocompleteValues = 200;
…

in LocalSettings.php, fewer than the defined 200 results were found by local autocompletion and were correctly displayed. Hoewever above 200 results the remote autocompletion got "no results" allways.

In my opinion, the error can be easily fixed by altering file ./PageForms/includes/PF_AutocompleteAPI.php. There were three two errors:

1. Tables and fields where not quoted att all and should be quoted as identifier
2. Literals where quoted as identifier and should be quoted as literals
3. An extra space character had crept in Edit by Barpfotenbaer at 2022-04-01 07:29 – Not an error!

Have a look at the diff:

359c359
< $whereStr = "$baseCargoTable.$baseCargoField = \"$baseValue\"";
---
> $whereStr = "\"$baseCargoTable\".\"$baseCargoField\" = '$baseValue'";
390c390
< $whereStr .= "($cargoField LIKE \"%$substring%\")";
---
> $whereStr .= "(\"$cargoField\" LIKE '%$substring%')";
392c392
< $whereStr .= "($cargoField LIKE \"$substring%\" OR $cargoField LIKE \"% $substring%\")";
---
> $whereStr .= "(\"$cargoField\" LIKE '$substring%' OR \"$cargoField\" LIKE '% $substring%')";

Please be aware, that I changed line 359 in advance without examining the need. Better Yaron should validate it 🙂

The changes in lines 390 and 392 were necessary to solve my problem.

Finally: Thank you for the ingenious extension(s)!

--Barpfotenbaer (talk) 13:12, 31 March 2022 (UTC)

PF-related bug?

Sorry it's taken me forever to contact you again here, and sorry if it's starting to get rather late in the day for this...but on my creative-venture wiki (since early this month), certain pages in a certain custom namespace intermittently fail to load or cannot be created/saved (properly) through Page Forms, complete with browser-specific 500 errors and host-based 502s. (TL/DR: NS in question, "Entry"; affected range, "S"/"T"; form in use, "Entry/RFM".) Details at Topic:Wshlmfa0iofr7no6 (on Project:Support desk) and at Miraheze Phabricator (whose team suggested this may be an upstream issue; Universal Omega (talk · contribs) [in the Support desk thread here] thinks this may be PF-related).

While we're on the subject of PF filings, this report from late January/early February remains to be addressed.

Also bringing in @Bawolff: He might know what may be happening as well.

Sample links: "sepente" (RFM for "weekend"), "sushibe" ("sushi", today's latest affectee), "tulajonar" ("attribute to an author"; scrapped away amid double saves et al. earlier on).

(MW 1.37.1)

--Slgrandson (talk) 22:26, 31 March 2022 (UTC)

Sorry, what specifically is not working? Yaron Koren (talk) 01:02, 1 April 2022 (UTC)

1) To recap, various Entry pages whose title begins with an "S" or "T". Trying to access them, or preview/save them (especially with the "Entry/RFM" form), results in localised 500s/502s.

2) The "Edit with form" tab is inexplicably missing on pages in the "From the Author" namespace, although I followed the setup instructions correctly. Once again, see the NS project page vs. this specimen target page. --Slgrandson (talk) 04:16, 1 April 2022 (UTC)

you should try and get the webserver error logs from miraheze. 500 & 502 usually means some sort of php error but not always, and can mean a lot of things. Bawolff (talk) 06:05, 1 April 2022 (UTC)

Yeah, #1 requires error logging or reporting. It doesn't seem Page Forms-related, though, since it doesn't involve forms. For #2, the issue might be the slash in the page - if MediaWiki thinks this is a subpage, Page Forms won't apply a form to it. If that's the case, subpaging for this namespace can be disabled using $wgNamespacesWithSubpages. Yaron Koren (talk) 13:11, 1 April 2022 (UTC)

For #2, the issue might be the slash in the page - if MediaWiki thinks this is a subpage, Page Forms won't apply a form to it.

Unfortunately, the subpage feature in the FTA system is here to stay (by founder's decision, and as a rule). As far as the hierarchy is concerned, all posts are subpaged by the year and/or era (remember, my feed started out on Google+ almost ten years ago). From here, further outlook is tantamount to an upstream extension patch. Let's see how well that turns out in the Form tab's favour... --Slgrandson (talk) 20:54, 1 April 2022 (UTC)

What about setting the tab via the category instead, then? It looks like you do have a category for all these posts. Yaron Koren (talk) 13:31, 4 April 2022 (UTC)