Extension talk:Page Forms

From mediawiki.org

Auto-generated unique page title w/ auto increment ids[edit]

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)[reply]

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)[reply]
Thank you!! Lens0021 (talk) 02:42, 12 January 2022 (UTC)[reply]

[RESOLVED] Cannot save form after invalid URL entered[edit]

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)[reply]

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)[reply]
I'm afraid not. Jonathan3 (talk) 22:03, 11 January 2022 (UTC)[reply]
Just tried a blank mandatory field and it had the same effect. Jonathan3 (talk) 22:09, 11 January 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
No problem! Thanks for the quick responses. It works well now :-) Jonathan3 (talk) 22:36, 14 January 2022 (UTC)[reply]

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

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)[reply]

I don't know. Maybe "autogrow" should just be disabled in the mobile view? Yaron Koren (talk) 19:14, 11 January 2022 (UTC)[reply]
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)[reply]

[RESOLVED] Rename Special:RunQuery when embedding form[edit]

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)[reply]

Sorry, I don't understand this question. Yaron Koren (talk) 00:45, 17 January 2022 (UTC)[reply]
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)[reply]

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

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)[reply]

Yes - you just need to edit the page MediaWiki:pf_category_hasdefaultform. Yaron Koren (talk) 14:12, 26 January 2022 (UTC)[reply]
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)[reply]

Comma-separated field from External Data[edit]

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)[reply]

Multiple "free text" boxes[edit]

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)[reply]

Namespace integration in multi-word NS titles[edit]

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)[reply]

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):
--Slgrandson (talk) 22:40, 16 February 2022 (UTC)[reply]

Token field does not filter value list[edit]

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

[RESOLVED] Troubleshooting 'Create with form' tab[edit]

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)[reply]

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)[reply]
First one works for me, Thank you very much! Lens0021 (talk) 15:09, 8 February 2022 (UTC)[reply]

Field labels and tab index[edit]

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)[reply]

#forminput: autocomplete on category= is not working[edit]

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)[reply]
All good now, thanks Plegault3397 (talk) 12:48, 15 February 2022 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
I tried without and received an error, I will try again and see what happens. Plegault3397 (talk) 22:00, 14 March 2022 (UTC)[reply]
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)[reply]
Where can we find this patch? Manu.wikidebats (talk) 18:31, 15 April 2022 (UTC)[reply]
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)[reply]
Thanks so much! It works perfectly now. Manu.wikidebats (talk) 19:29, 15 April 2022 (UTC)[reply]

Ordering radio inputs[edit]

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)[reply]

Size parameter is not included in #forminput[edit]

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)[reply]

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)[reply]
Workaround: change the width directly in the css :
.pfPageNameWithoutNamespace {
  width: 200px;
}
--Megajoule (talk) 06:47, 30 March 2022 (UTC)[reply]
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)[reply]

Extremely slow form rendering using autocomplete from large namespace[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
What version of Page Forms are you running? Yaron Koren (talk) 00:55, 18 February 2022 (UTC)[reply]
I'm running 5.3.4 Sazpaimon (talk) 01:25, 18 February 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

PF and Wikieditor in MediaWiki 1.35.5[edit]

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

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)[reply]

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

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)[reply]

Combobox autocomplete on sub pages?[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I just checked in a fix for this, by the way, here. Yaron Koren (talk) 16:30, 25 April 2022 (UTC)[reply]

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

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)[reply]

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)[reply]
Thanks for the quick fix, much appreciated! Works like a charm again. 78.35.151.198 07:44, 11 March 2022 (UTC)[reply]

Get value of forminput-value[edit]

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&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)[reply]

The one-step process (with #formlink instead of #forminput) may be helpful for this case. Yaron Koren (talk) 15:37, 9 March 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
OMG yes, this is the solution. It could be so easy sometimes. Thanks a lot!! :) Mrgraw (talk) 17:57, 9 March 2022 (UTC)[reply]

Page forms - input type=tokens[edit]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]
OK. I'm going to upgrade my system. --Megajoule (talk) 15:48, 9 March 2022 (UTC)[reply]
The problem remains with version 5.3.4. --Megajoule (talk) 21:54, 21 March 2022 (UTC)[reply]
And version 5.4 --Megajoule (talk) 12:14, 26 April 2022 (UTC)[reply]

Better sorting of autocompletion suggestions[edit]

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)[reply]

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

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

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)[reply]

PF-related bug?[edit]

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)[reply]

Sorry, what specifically is not working? Yaron Koren (talk) 01:02, 1 April 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

[RESOLVED] No display of a jqplotchart query called from a form[edit]

MW 1.35.6 / PHP 7.4.27 / MariaDB 10.1.48 / SMW 3.2.3 / PF 5.3.4

My SearchPeople query form calls the SearchPeople template which contains the following query (which I have simplified for testing): {{#ask:[[Category:People]]|?unit|mainlabel=-|format=jqplotchart|distribution=1|charttype=pie}}

The request does not succeed (a spinning logo rotates indefinitely) when I go through the form that I also simplified for testing: {{{for template|searchPeople}}}{{end template}}

Yet the template page does display the graphic.

In a previous version of my MediaWiki system (MW 1.31, SMW 2.5.8, PF 4.3.1), this works (with exactly the same code and more complex form/template duos).

PS1: To see if this changed anything, I switched the type of the form button from GET to POST by changing line 149 in PF_RunQuery.php. Nothing changed.

PS2: Since the upgrade to PF 5.3.4, I also get this type of warning: Notice: Uninitialized string offset: 37 in /var/www/mediawiki/extensions/PageForms/includes/PF_FormPrinter.php on line 1009

I can add the bug in Phabricator if necessary. Megajoule (talk) 11:09, 1 April 2022 (UTC)[reply]

Do you see any JavaScript errors, if you look in the browser console? To see a clear error message, you may need to add "&debug=true" to the URL. Yaron Koren (talk) 13:12, 1 April 2022 (UTC)[reply]
In the meantime, I'm debugging the upgrade from SMW 3.2.3 to SMW 4.0.1. which messes up my wiki by blocking all javascript.
I've just noticed that the jqplotchart problem and the problems related to the migration to SMW 4.0.1 are naturally solved when I remove the display errors:
# ini_set( 'display_errors', 1 );
Does this little # allow SMW 4.0.1 to work and thus the query form leading to a jqplot ask to succeed? I don't know and I don't care (yet). Thank you in any case Yaron for forcing me to go deeper into the debugging. --Megajoule (talk) 21:58, 1 April 2022 (UTC)[reply]

editor=wikieditor in a field crashes the form[edit]

MW 1.37.2 / PHP 7.4.27 / SMW 4.0.1 / PF 5.3.4

Specifying editor=wikieditor in a textarea field causes the form to crash when trying to create a new page with that form. This is the error message for a form called MyForm:

WikiPage constructed on a Title that cannot exist as a page: Spécial:AddData/MyForm

The form does not crash when modifying a previously created instance.

The problem was not seen with MW1.35.4 and SMW3.2.3

Megajoule (talk) 21:02, 2 April 2022 (UTC)[reply]

I'm using the same version of MW and PageForms. But I'm not able to see this error while creating a page. Techwizzie (talk) 02:55, 17 April 2022 (UTC)[reply]

Embedding query forms broken[edit]

All of a sudden embedding query forms does not work any longer "

{{Special:RunQuery/PageQueryKeyword}}

leads to

Special:RunQuery?pfRunQueryFormName=PageQueryKeyword&PageQueryKeyword[keyword][]=foo+bar&PageQueryKeyword[keyword][is_list]=1&wpRunQuery=&pf_free_text=

The error I am now getting: "You must specify a form name in the URL; the URL should look like "Special:RunQuery/<form name>".


The form looks like this:

<includeonly>{{{info|query title=Query for pages with the given keyword:}}}
{{{for template|PageQueryKeyword}}}
{{{field|keyword|input type=tokens|values from property=Has keyword|max values=1}}}
{{{standard input|run query|label=Start search}}}
{{{end template}}}</includeonly>

Last time I used this about 4 weeks ago it was still working. In the meantime nothing was updated for the wiki, i.e. it is on MW 1.31.16 and PF 5.0.1. Now updating to PF 5.2.1 did not help. Any suggestions that may help to find out why it is no longer working. 2003:F1:C725:6300:4094:E81D:9963:3FBA 08:34, 12 April 2022 (UTC)[reply]

Embedding a query form actually works fine for me. It's strange that your URL has Special:RunQuery as (I assume) the name of the page, and not the actual page that the form is embedded in. Why is that, do you know? Yaron Koren (talk) 18:38, 18 April 2022 (UTC)[reply]
Yes the URL is as posted and not containing the name of the originating page. Since the error message claims that Special:RunQuery should be part of the URL it did not realize that this could be the issue. Still, worked before and not sure why this happens all of a sudden. Now using queryformlink to provide the search though not as nice. --Marbot (talk) 07:30, 20 April 2022 (UTC)[reply]

Preload field in free text not working with {{#autoedit:...[edit]

On Page Forms master

Product Version
MediaWiki 1.35.5
PHP 7.4.22 (cgi-fcgi)
MariaDB 10.4.11-MariaDB
ICU 66.1
Lua 5.1.4

You can preload data for the free text input which works fine when used with {{#formlink:.... but it does not seem to work with the {{#autoedit:... parserfunction.

I tried to figure out what is going wrong but the below simple Form works fine when used with the formlink parserfunction but when used with the autoedit parserfunction the content of the Load autofill page is ignored and does not end up on the created page.

<includeonly>{{{info|query form at top|onlyinclude free text}}}{{{for template|Aaaa}}}

* {{{field|Equipment}}}

 {{{end template}}}

{{{standard input|free text|input type=textarea|editor=wikieditor|rows=25|preload=Load autofill}}}</includeonly>

I am not sure if this is on purpose or if there is something wrong. We only used preload for template parameters until now but we want to be able to preload the free text on a page. Thanks and regards, Felipe (talk) 12:40, 12 April 2022 (UTC)[reply]

I believe it's on purpose, although maybe it's not ideal; parameters like "preload=" and "default=" only apply when creating a new page, not when editing an existing page, and I think that holds true even when using #autoedit. If that's true, then there may be no way to modify the free text from within #autoedit, although there probably should be. Yaron Koren (talk) 18:33, 18 April 2022 (UTC)[reply]
Hello Yaron, the above applies when generating a new page not an existing one with formlink or autoedit. I understand and agree (we had that discussion in the past) that it does not apply for editing existing pages. To me it seems that autoedit is not "aware" or ignores the standard input|free text field in the form when it automatically generates the new page. It only "looks" in-between the {{{for template|.... and {{{end template}}} calls. Felipe (talk) 11:18, 21 April 2022 (UTC)[reply]

Table Error in textarea field[edit]

"|" is not allowed, except within {{...}}, [[...]], or special tags 

Pageforms5.4.3Textarea.png

I am getting the above error. My fields are set for textarea.

Not sure if cargo field matters but it is wikitext.

I am using PageForms 5.3.4 and mediawiki 1.35 Thanks, Margaret Issiegainsley (talk) 13:58, 16 April 2022 (UTC)[reply]

The pipes are used within the template to separate the parameters with their values. Any table added to the parameter like you describe would "break" the template. You can still add tables to to a parameter but you need to replace all the pipes "|" used in the table with the magic word {{!}} . See: Help:Magic_words#Other.
{{{!}} class = "wikitable" width = " 30%"
! Header 1
! Header 2
! Header 3
{{!}}-
{{!}} Some text
{{!}} align = "center {{!}} Some more text
{{!}} align = "right {{!}} And even more
{{!}}}

Would result in:

Header 1 Header 2 Header 3
Some text Some more text And even more
Felipe (talk) 08:33, 18 April 2022 (UTC)[reply]

The combobox fields are not user-friendly[edit]

When a value has been previously entered in a combobox field, the list of other possible values is not displayed. ComboboxProblemSample.jpg

To change the value, the user must delete the old value with the Delete or Backspace keys. The user may then have the impression that it is impossible to change the value.

Megajoule (talk) 08:35, 17 April 2022 (UTC)[reply]

Mandatory parameter does not work in combobox[edit]

With the last version of Page Forms 5.3.4, the mandatory condition does not apply if input type=combobox. The warning message does not appear and the user can save the form even if the field is blank. An example here. Manu.wikidebats (talk) 18:57, 18 April 2022 (UTC)[reply]

This was fixed here. Yaron Koren (talk) 17:15, 21 April 2022 (UTC)[reply]
Thanks! It works. Manu.wikidebats (talk) 21:54, 21 April 2022 (UTC)[reply]

Any suggestion to troubleshoot 'autocomplete on URL'?[edit]

Hi - I believe I followed all the steps described at this page to set up an external source for autocomplete. I can go to the URL and look up a value manually and the page returns a JSON object that matches what is described in the documentation. Once I am in the form, I am not getting any value using the mapping I defined in LocalSettings. Do you have tips to debug what is going on? I am not seeing any error in the browser console or in the form itself. Lalquier (talk) 20:17, 20 April 2022 (UTC)[reply]

One thought about it - does Page Form expect a particular Mime Type or header for the JSON content produced by the remote URL? Another possibility is an interference with a single sign on extension we are using. In any case, a way to have some kind of trace or log of what Page Form is doing with autocomplete would be helpful. Lalquier (talk) 22:43, 20 April 2022 (UTC)[reply]

Property parameter does not work for combobox[edit]

With the last version of Page Forms 5.3.4, property (or values from property) parameter does not work if input type=combobox. No autocompletion applies (but it does for values from category). An example here. Manu.wikidebats (talk) 21:59, 21 April 2022 (UTC)[reply]

Looks like property values ​​don't like property names with an apostrophe. I took the liberty of doing a test on your wiki with a property with a "more suitable" name (Property:TestAttribut) and it worked. I advise you to rename your attributes and retest. Megajoule (talk) 08:03, 23 April 2022 (UTC)[reply]
Thanks! Now the titles are displaying... but if they are long, the end of the title is of this kind: A la différence des ordres d'exécution pfe27252df55cf9ac6e3d1f5d512ec765.
So, it's still not working :(. Manu.wikidebats (talk) 17:17, 24 April 2022 (UTC)[reply]
Now it's working. I had to change the property declaration: [[Has type::Text]] to [[Has type::Page]].
But why? This property does not refer to pages but to text. Manu.wikidebats (talk) 17:32, 24 April 2022 (UTC)[reply]
Again, I took the liberty of testing on your wiki by changing the type of the page attribute to text (I reset page after my tests...). Indeed, when the value exceeds 72 characters, cryptic characters are displayed after the 40th character. A quick search of the SMW docs shows that there are indeed differences in the treatment of Text and Page types.
Can you modify the $smwgFieldTypeFeatures parameter to see if the SMW_FIELDT_CHAR_LONG setting fixes the problem? --Megajoule (talk) 11:27, 27 April 2022 (UTC)[reply]

A concrete example of the use of the promising "values dependent on" functionality?[edit]

I feel like I'm digging up an old topic but I haven't found a clear answer to this question in the documentation of the Page Forms extension or in the talk archive.

Is there an example of the implementation of the "values dependent on" feature somewhere on the web? My tests didn't give me much and despite what the documentation says, the example given (restaurant, country, city) doesn't shed any light on how this parameter works.

My hidden hope is that this will overcome the current malfunction of the Semantic Forms Select extension. Megajoule (talk) 07:11, 28 April 2022 (UTC)[reply]

You can see an example here, using this form - the values for "Position" are dependent on the value for "Topic". Thankfully you can modify these values even when logged out. Yaron Koren (talk) 13:58, 28 April 2022 (UTC)[reply]
OK. Thank you for this example. I have the same type of code except that the form is not multiple and I am not using Cargo but SMW. I have a class instance that registers the City and Country properties. However the choice of country in the form does not show the city...

Template:Restaurant

* Country: [[Country::{{{Country|}}}]]
* City : [[City::{{{City|}}}]]

Form:Restaurant

{{{info|page name=Test Values dependent on}}}
{{{for template|Restaurant}}}
{{{field|Country|property=Country|input type=combobox}}}
{{{field|City|property=City|input type=combobox|values dependent on=Restaurant[Country]}}}
{{{end template}}}

Property:City and Property:Country

[[Has type::Text]]

La Tour d'Argent

{{Restaurant
|Country=France
|City=Paris
}}

Megajoule (talk) 07:17, 29 April 2022 (UTC)[reply]

There may be a bug with the handling of "values dependent on" in SMW - it's been a long time since I tested it. Yaron Koren (talk) 13:14, 29 April 2022 (UTC)[reply]

_run table display bug[edit]

Adding _run onto a query string results in an odd display bug with tables. To reproduce:

  1. Click this link
  2. Now click "run query" on the same page, and the table difference will be obvious. Frybread (talk) 04:48, 29 April 2022 (UTC)[reply]

Combobox - A non-numeric value encountered[edit]

I'm not sure if this is an error with my form or an error with PageForms, any ideas on how to remedy (other than not using Comboboxes)?
MediaWiki - 1.35.6
PHP - 7.4.25 (cgi-fcgi)
MySQL - 8.0.28-0ubuntu0.20.04.3
PageForms 5.4

ErrorException from line 99 of /home/username/website.com/w/extensions/PageForms/includes/forminputs/PF_ComboBoxInput.php: PHP Warning: A non-numeric value encountered

  1. 0 /home/username/website.com/w/extensions/PageForms/includes/forminputs/PF_ComboBoxInput.php(99): MWExceptionHandler::handleError(integer, string, string, integer, array)
  2. 1 /home/username/website.com/w/extensions/PageForms/includes/forminputs/PF_ComboBoxInput.php(196): PFComboBoxInput::getHTML(string, string, boolean, boolean, array)
  3. 2 /home/username/website.com/w/extensions/PageForms/includes/PF_FormPrinter.php(2042): PFComboBoxInput->getHtmlText()
  4. 3 /home/username/website.com/w/extensions/PageForms/includes/PF_FormPrinter.php(1408): PFFormPrinter->formFieldHTML(PFFormField, string)
  5. 4 /home/username/website.com/w/includes/StubObject.php(116): PFFormPrinter->formHTML(string, boolean, boolean, integer, string, string, NULL, boolean, boolean, boolean, array, User)
  6. 5 /home/username/website.com/w/includes/StubObject.php(142): StubObject->_call(string, array)
  7. 6 /home/username/website.com/w/extensions/PageForms/includes/PF_AutoeditAPI.php(978): StubObject->__call(string, array)
  8. 7 /home/username/website.com/w/extensions/PageForms/includes/PF_AutoeditAPI.php(129): PFAutoeditAPI->doAction()
  9. 8 /home/username/website.com/w/extensions/PageForms/specials/PF_FormEdit.php(103): PFAutoeditAPI->execute()
  10. 9 /home/username/website.com/w/extensions/PageForms/specials/PF_FormEdit.php(44): PFFormEdit->printForm(string, string, NULL)
  11. 10 /home/username/website.com/w/includes/specialpage/SpecialPage.php(600): PFFormEdit->execute(string)
  12. 11 /home/username/website.com/w/includes/specialpage/SpecialPageFactory.php(635): SpecialPage->run(string)
  13. 12 /home/username/website.com/w/includes/MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext)
  14. 13 /home/username/website.com/w/includes/MediaWiki.php(945): MediaWiki->performRequest()
  15. 14 /home/username/website.com/w/includes/MediaWiki.php(548): MediaWiki->main()
  16. 15 /home/username/website.com/w/index.php(53): MediaWiki->run()
  17. 16 /home/username/website.com/w/index.php(46): wfIndexMain()
  18. 17 {main}

TiltedCerebellum (talk) 05:10, 12 May 2022 (UTC)[reply]

I figured it out, apparently size must be set to some numeric value, but nowhere is that stated in the docs, nor does it fail gracefully, warn, or have a default. Imo there should be a default to prevent exceptions, or at the very least a warning on save. At some point we had a user change or delete the value, and it kicked this error TiltedCerebellum (talk) 05:20, 12 May 2022 (UTC)[reply]
"size" doesn't have to be set, although it did lead to a PHP warning if it was set to a non-numeric value (like "50px" instead of "50"). I just checked in a fix for this. Yaron Koren (talk) 13:56, 12 May 2022 (UTC)[reply]

Card Suit Symbols in {{#queryformlink:form=|link type=button|link text=♠♥♦♣

I am creating a card game wiki and would like to have the queryformlink button text show card suit symbols (Spades/♠, Hearts/♥, Diamonds/♦, Clubs/♣).

I have tried to use Unicode and HTML-codes for these symbols and also a link to an image. None of these seem to work. (PageForms 5.4, MW 1.35.2). Also I do not see any card suit icons in the OOUI set which would be an option I could live with (assuming I can figure out how to change the button icon from '> next').

Pre OOUI usage this was possible (ie. I can do this in PageForms 4.6).

Am I missing something fundamental that would allow me to have this more user friendly interface?

Thanks in advance, Gregg GMShimokura (talk) 02:35, 13 May 2022 (UTC)[reply]

That's too bad. I haven't tried this personally, but I can think of two potential approaches: (1) having the links be of the default text type, instead of buttons, and using CSS to make them look more like buttons; or (2) adding some JavaScript (in MediaWiki:Common.js) to change the text on the buttons, after they have already been rendered. Yaron Koren (talk) 03:06, 13 May 2022 (UTC)[reply]