Extension talk:Page Forms

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

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)

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)

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)

editor=wikieditor in a field crashes the form

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)

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)

Embedding query forms broken

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)

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)

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)

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

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)

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)

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)

Table Error in textarea field

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

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)

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)

The combobox fields are not user-friendly

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

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)

Mandatory parameter does not work in combobox

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)

This was fixed here. Yaron Koren (talk) 17:15, 21 April 2022 (UTC)

Thanks! It works. Manu.wikidebats (talk) 21:54, 21 April 2022 (UTC)

Any suggestion to troubleshoot 'autocomplete on URL'?

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)

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)

Property parameter does not work for combobox

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

_run table display bug

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)

Combobox - A non-numeric value encountered

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)

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)

"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)

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)

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)

Datetimepicker (and combobox), highly criticized by users

I get very negative feedback from my users about the datetimepicker fields. They say that these fields are not at all ergonomic compared to the old version, especially :

• it is impossible to enter a whole date with the keyboard (e.g. 21/02/2022 17:04)
• the current date and time is filled in by default when you start filling in the field (including minutes and seconds!), which means that you have to update everything (including minutes and seconds, which the user often has to reset to 00).
• the delete button on the right of the field is not explicit. Moreover, on the Linux version of Firefox, its width is reduced to a few pixels (you have to aim right).

If we also consider combobox, it is difficult to find advantages to the change to OOUI.

Will a white knight fight this dragon? Megajoule (talk) 13:59, 22 May 2022 (UTC)

I admit that the datetimepicker input has some problems (I didn't know about Firefox on Linux). I should note that there's also a "datetime" input type - which is not JavaScript-based, but it might appeal more to your users. What are the problems with "combobox"? Yaron Koren (talk) 14:16, 22 May 2022 (UTC)

Hello Yoren,

Thank you for your answer. The datetime type is even less ergonomic (no navigation in a calendar + a field for day, month, year, hour, minutes, seconds, PM/AM... phew!).

In a form, a user should be able to move from field to field with the TAB key and type an entry with the keyboard if he wants. And for the date/time fields, he must be able to fill it in at once.

For combobox, I noted:

• Feeds to map does not work with combobox fields
• When a value has been previously entered in a combobox field, the list of other possible values is not displayed
• No image preview in an "uploadable" field

Megajoule (talk) 16:02, 22 May 2022 (UTC)

Okay, thanks for putting all of these in one place. Were any/all of these working when combobox was defined with jQuery UI instead of OOUI, do you know? Yaron Koren (talk) 17:48, 22 May 2022 (UTC)

I just tested on a jquery version :

• The geocoding with leaflet was not working so impossible to know if feeds to map worked with combobox fields
• The other possible values are displayed when a value has been previously filled in.
• As for OOUI, image preview does not work: at the creation of the page, no preview at all. On modification, the image previously filled in is displayed but the display is not updated if you change the file in the combobox. Megajoule (talk) 18:09, 22 May 2022 (UTC)

visualeditor in fields not working

Hi,
MW 1.35.6 | SMW 4.0.1 | Foreground 2.4.0 | PageForms 5.1 | VEForAll 0.4 | VisualEditor 0.1.2
I have in my form fields that I want to be used with VEForAll to have a VisualEditor bundled in it. I used |editor=visualeditor before, but since the upgrade from 1.35.2 to 1.35.6 it broke and now the field is simply greyed out and disabled. Thus, I've to put it back to a normal text field to make it usable. Could you please help me make the form working again? Here's the configuration I have for PageForms:

$wgPageFormsLinkAllRedLinksToForms = true;
$wgPageFormsHeightForMinimizingInstances = -1;

Raphoraph (talk) 18:50, 11 June 2022 (UTC)

Okay, so tested with the Vector skin, and suddenly it worked… not only with Vector but with Foreground too. I'm a little confused. Perhaps without noticing, I cleared some cache or data, and it worked. Raphoraph (talk) 19:13, 11 June 2022 (UTC)

pf_autoedit_fail error

Switching from PF 5.21 to 5.3x, the message "Modifying <a href="pagetitle..."> failed." appears in case of an anonymous edit. It's impossible to edit a page with PF when non-logged. An autoedit error appears. Yet the #autoedit function is not used in the form.

An example here. (Note the captcha: "Wikipedia" or "debats".) Manu.wikidebats (talk) 16:03, 21 June 2022 (UTC)

How to display form uploaded image in completed page?

I was able to create a form that requires multiple inputs and allow a file upload.

Once done/saved, the new page does not display or reference the uploaded file. I have also tried adjusting the field to the file reference [[File:xxxx.png|frameless|1000px]] as is the formatting I am planning to use but no images display. Coreyjohnson75 (talk) 17:06, 24 June 2022 (UTC)

Was the file uploaded, and is its name stored in the template call on the page? If so, the problem is somewhere in the template. Yaron Koren (talk) 17:48, 24 June 2022 (UTC)

It uploads the file but the upload pop-up window goes white/blank after the upload. I can see the file under file list. If I close the pop-up the file name is not visible on the form. Coreyjohnson75 (talk) 18:58, 24 June 2022 (UTC)

I'm guessing there's some kind of JavaScript error. Can you try it again, this time looking in the browser console (if you know how to do that) to see if an error occurs? Yaron Koren (talk) 14:00, 1 July 2022 (UTC)

I tried again and had the same results. Found this in the console from Dev Tools:

ReferenceError

Coreyjohnson75 (talk) 15:14, 1 July 2022 (UTC)

Remote Autocompletion values arriving differently than Local when using values from property=xx when xx Has type::Keyword

Hi. I wanted to list a weird thing that has started happening to me recently (since January 2022) with Keyword properties. When Page Forms pulls the list of items from a keyword property for local autocomplete, they show up as they were entered.. capitalization and everything (even though internally there isn't case sensitivity to them I know)... but when it switches to remote autocompletion, suddenly everything is all lowercase. I have figured the best way to solve this is just never touch the keyword type for now, but if it were possible to keep capitalization for looks purposes and have the smw search be case insensitive (which I think was my original thought of using keyword and how it seemed to work a while ago), it'd be even better.

RinaCY (talk) 20:09, 30 June 2022 (UTC)

I had never heard of the "Keyword" type before, but I just looked up its documentation page, and it does say that Keyword values are "normalized (lowercased, removed diacritics)". So it sounds like it's local autocompletion that's doing it "wrong". Though really, maybe you should always be entering these values as all-lowercase? Yaron Koren (talk) 14:05, 1 July 2022 (UTC)

You're likely right, I guess I just noticed how it worked at one point then once things got too large it completely changed, and now things have to be rewritten. RinaCY (talk) 17:42, 6 July 2022 (UTC)

_run doesn't populate default values when using #queryformlink

I have a form with a field called "Author" with "default=current user". If I access this form with #queryformlink, my username is automatically filled in the Author field, as expected. However, I still have to click "Run query" to see the results. When I add "query string=_run", the query is executed without populating the Author field. Is this a bug or is there something else I should be doing? Wulfda02 (talk) 21:08, 19 July 2022 (UTC)

That does sound like a bug, yes. Yaron Koren (talk) 13:51, 22 July 2022 (UTC)

Form properties after upgrading from Semantic Forms to Page Forms.

MediaWiki - 1.35.6

PHP - 7.4.25 (cgi-fcgi)

Postgresql - 10+

PageForms 5.4

Upgrading from Mediawiki 1.27;

I have a Special Page query which looks for page properties, most importantly, the Geometry: property; My forms (PF_NS_FORM) are each built off a template. Each page has a relative Template page (NS_TEMPLATE) which contains the Has default form:: which I go through every page with that using a script and adding {{#default_form:}} as outlined in Page Forms (https://www.mediawiki.org/wiki/Extension:Page_Forms/The_%22edit_with_form%22_tab);

However, after doing this, my Form no longer displays the CategoryLinks to some of the properties, most noteably Geometry and DTG (which is a date time thing). All forms before updating the template (and running runJobs.php) query properly and show Geometry but after the template update, it no longer works. Is there another way I should be doing this? Rijvirajib (talk) 04:06, 22 July 2022 (UTC)

Sorry, what do you mean by "no longer displays the CategoryLinks"? Yaron Koren (talk) 13:50, 22 July 2022 (UTC)

Thanks for getting back to me so quickly! In my form using [\[Page has default form]\], I have a property at the bottom [\[Geometry:POINT(some numbers)]\]. I want to query Page Forms form for all properties for that form, including Geometry. This works fine BEFORE I update my Page Form Template and append {{#default_form}} to the bottom so that the form itself will show "Edit with form" when viewing it. However, when I update the Form Template, the properties that I once queried to get Geometry and others like [\[Has DTG:]\] no longer display.

The query to grab all properties for a form/template:

SELECT DISTINCT T1.smw_sortkey AS pname

FROM mediawiki.smw_object_ids T1,

mediawiki.smw_object_ids T2,

mediawiki.smw_di_wikipage page

WHERE page.s_id IN (SELECT smw_id

FROM mediawiki.smw_object_ids

WHERE smw_title IN (SELECT page_title

FROM mediawiki.page,

mediawiki.categorylinks

WHERE cl_from = page_id'

AND cl_to = 'Bridge_Assessment'

))

AND T1.smw_id = page.p_id

AND T2.smw_id = page.o_id

ORDER BY pname;

Rijvirajib (talk) 15:55, 22 July 2022 (UTC)

Sorry, I still don't understand. Are you putting properties like "Geometry" in the form, or the template? I'm guessing in the template, but if so - does this issue actually have to do with Page Forms? Yaron Koren (talk) 21:57, 22 July 2022 (UTC)

Correct, they are stored in the template. We are trying to discover all the properties used in a particular template. For example, if you create a page form based on a template there are properties generated on the newly created form for the user to populate. We need to get these properties.

We have been using the above database query but since moving to MW 1.35.5 (SMW 3.2.3) we have noticed the query no longer returns back the correct properties. Some are missing (Geometry, DTG, etc.).

Do you know of a way to get these list of page form template properties using an endpoint API (https://www.semantic-mediawiki.org/wiki/Help:API, https://www.mediawiki.org/w/api.php), direct DB query or a using the any of the classes (https://doc.wikimedia.org/mediawiki-core/master/php/annotated.html) ? 2601:191:8400:9E0:30F4:BCF9:8D80:85B4 15:20, 23 July 2022 (UTC)

I don't know, but this does sound like a Semantic MediaWiki, not a Page Forms, question - it seems like this issue would exist even if you were editing pages manually, not with forms. Yaron Koren (talk) 17:35, 24 July 2022 (UTC)

How does PageForms know what properties to use for a category/template(s)? Ckapop (talk) 22:00, 27 July 2022 (UTC)

Do you mean, for example, how it knows where to get the autocompletion values for some field? It parses the template page to see what SMW property (if any) is attached to each template field. Yaron Koren (talk) 22:47, 27 July 2022 (UTC)

Just a small update:

We've identified where Semantic Mediawiki stores form categories. They exist in smw_qi_* tables. Doing a complex query to grab them all worked based off the Category name. Thank you 70.109.152.21 14:28, 30 July 2022 (UTC)

Remote autocompletion when using mapping property

SMW : 4.0.1 // MW : 1.38.1 // PF : 5.4

Hello,

It seems that remote autocompletion doesn't work when using mapping property. Is ther a way to active it ?

Thanks !

Paul LEMPERIERE (talk) 19:33, 23 July 2022 (UTC)

Wrong value displayed using token input type and magic word

SMW : 4.0.1 // MW : 1.38.1 // PF : 5.4

I use the magicword {{DISPLAYTITLE}} for a page category.

When i feed the list of a token input type with this category, here is what happen :

- The list displayed is the original name of the page

- If i search a word that must be in the alias of the page title, the results filtered are good, like if the alias thas hidden. So the alias is searchable

- When i click on a result to display it, the alias appear in the box !

See here the use case : https://gifyu.com/image/SNlJ7

Is it possible to show the display title in the list of the token input ? Paul LEMPERIERE (talk) 20:04, 23 July 2022 (UTC)

Prevent resorting of input-type tokens (textarea with autocomplete)

Hej-hej,

is it possible for extension Page Forms 5.1 (SMW 3.2.2) to prevent the resorting or rearrangemet of input-types tokens (former textarea with autocomplete)? My goal is to input words in a (semicolon separated) list but keep the order of input values as it was entered by the user. I found no possibility yet to prevent that reordering when the form is loaded—is it possible and how can it be achieved? Thank you for any help on this. -- Andreas P. 11:48, 24 July 2022 (UTC)

You should definitely upgrade to the latest Page Forms version - I'm not sure this bug has been fixed, but I think it has. Yaron Koren (talk) 17:35, 24 July 2022 (UTC)

How do you create a category (or select an existing one) from a field value on a Page Form in MediaWiki?

I created a form to allow users to input data about scientific topics, references and categories in an organized manner. Problem is, I am unable to automatically categorize the page (by either creating a new category or using an existing one) when a user fills the form with the appropriate category information.

Here is the template page from my Mediawiki site:

<noinclude>
{{#template_params:Summary (label=Topic Summary (In point form, as a numbered list. Include references between <ref></ref> tags.))|User_Category}}
</noinclude><includeonly>
{{#template_display:_format=sections}}
[[Category:Summary Article]]
[[Category:{{#arraymap:|,|@@||}}]]
</includeonly>

Here's my form code:

<noinclude>
This is the "Summary Article" form.
To create a page with this form, enter the page name below;
if a page with that name already exists, you will be sent to a form to edit that page.

{{#forminput:form=Summary Article}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
=Summary=
{{{section|Summary|level=1}}}

==Category==
{{{field|User_Category|level=2}}}

</includeonly>

I attempted to assign the field value to the category variable `User_Category` in order to create a category in the template page, but was unsuccessful. Any assistance would be greatly appreciated. 114.73.149.245 13:28, 25 July 2022 (UTC)

You should change this line in your template:

[[Category:{{#arraymap:|,|@@||}}]]

...to something more like:

[[Category:{{{User Category|}}}]]

(Assuming the user is only supposed to enter one category, not a list of them.) Yaron Koren (talk) 14:30, 25 July 2022 (UTC)

Yeah, I made the changes, but it still doesn't work as the category information doesn't turn up on the page that is created (I only entered one category). 114.73.149.245 23:21, 25 July 2022 (UTC)

See Topic:Wzwhzgwbn1bv73fw. Jonathan3 (talk) 13:28, 26 July 2022 (UTC)

How do you transclude user input from a form into a page without the section heading?

I have a form that takes user input and creates a page. Unfortunately, the page that is created includes the section heading, which I wish to avoid. I only wish to keep the name of the page, user input and nothing else.

Here is the template page from my Mediawiki site:

<noinclude>
{{#template_params:Summary (label=Topic Summary (In point form, as a numbered list. Include references between <ref></ref> tags.))|User_Category}}
</noinclude><includeonly>
{{#template_display:_format=sections}}
[[Category:Summary Article]]
</includeonly>

Here's my form code:

<noinclude>
This is the "Summary Article" form.
To create a page with this form, enter the page name below;
if a page with that name already exists, you will be sent to a form to edit that page.

{{#forminput:form=Summary Article}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
=Summary=
{{{section|Summary|level=1}}}

==Category==
{{{field|User_Category|level=2}}}

</includeonly>

The page that is created has it's name on top, then the label 'Summary' as the next heading, followed by the user input. I wish to remove the 'Summary' heading altogether. How do I accomplish that? 114.73.149.245 10:32, 26 July 2022 (UTC)

I think you'd have to replace the {{#template_display:_format=sections}} line and find another way to display the {{{Summary|}}} field. Maybe have it as a field rather than a section? Jonathan3 (talk) 13:33, 26 July 2022 (UTC)

That doesn't work 114.73.149.245 14:02, 26 July 2022 (UTC)

The error I get is "EditPage does not have a context title set" 114.73.149.245 14:03, 26 July 2022 (UTC)

Edit the page (by this I mean any content page you have created using the form) to remove the section heading =Summary= and the text below. Then change the form to have a field instead of a section. Then edit the template to show the summary field. (By the way it's confusing to have a PF field called Summary when wiki pages have a Summary field already.) Note that in the following I've made changes from your original code, so you might have other changes to make.

Form:

<noinclude>
This is the "Summary Article" form.
To create a page with this form, enter the page name below;
if a page with that name already exists, you will be sent to a form to edit that page.

{{#forminput:form=Summary Article}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Summary Article}}}
==Summary==
{{{field|Summary|input type=textarea}}}

==Category==
{{{field|User Category|input type=tokens|list}}}

</includeonly>

Template:

<noinclude>
{{#template_params:Summary|User Category}}
</noinclude><includeonly>
{{{Summary|}}}
[[Category:Summary Article]]
{{#arraymap:{{{User Category|}}}|,|@@|[[Category:@@]]|}}
</includeonly>

Jonathan3 (talk) 22:29, 28 July 2022 (UTC)

Uploading a duplicate file

It seems since MW v1.33 we are having issues uploading a duplicate file. We used to be able to ignore warning and choose to upload anyway.

Now there is some code in LocalFile.php that prevents this from working anymore.

LocalFile.php:

if ( $row && $row->img_sha1 === $this->sha1 ) {

  $dbw->endAtomic( __METHOD__ );
  wfDebug( __METHOD__ . ": File " . $this->getRel() . " already exists!" );
  $title = Title::newFromText( $this->getName(), NS_FILE );
  return Status::newFatal( 'fileexists-no-change', $title->getPrefixedText() );

}

This returns an error and we never get the option to ignore the warning and upload anyway like before. Is this a known issue or change? Any workarounds? We tried commenting out the code above and it all seems to work like it used to. Just not sure this is the best decision. Ckapop (talk) 14:15, 2 August 2022 (UTC)

[SOLVED] How to make content of embedded template show as parsed wikitext

When I use the approach in Extension:Page_Forms/Defining_forms#Embedded_templates the embedded template is displayed as unparsed wikitext (e.g. [[Pagename]] instead of Pagename). When I call the same template from a normal content page the wikitext is parsed. It also works when I use the normal method (i.e. not the "embedded templates" method). What am I doing wrong? Thanks. Jonathan3 (talk) 21:59, 2 August 2022 (UTC)

I think I have the answer. It was a new template so I was using the new standard {{#template_display:_format=infobox}}. When I changed to the old way of doing things (writing code to display each parameter separately) the wikitext parsing worked fine. Jonathan3 (talk) 22:12, 2 August 2022 (UTC)

[SOLVED] Get "values from category" to work with category with about 5000 pages

I vaguely remember that there are some extension settings, and something about in-browser vs remote autocompletion, but thought it better to ask here instead of experiment. What would be the best settings for this? Thanks. Jonathan3 (talk) 22:16, 4 August 2022 (UTC)

The standard settings should work fine, with $wgPageFormsMaxLocalAutocompleteValues equal to 100, ensuring that you have remote autocompletion for this input. Yaron Koren (talk) 23:27, 4 August 2022 (UTC)

I have that setting. Not sure about "ensuring that you have remote autocompletion for this input". I have two problems when using {{{field|fieldname|input type=tokens|values from category=categoryname}}}: (1) when it finds something, it highlights it in the long list (e.g. Cheese) but I have to scroll all the way down to select it; (2) some things aren't in the list that I think should be. Jonathan3 (talk) 21:39, 8 August 2022 (UTC)

I should add that it highlights several words (e.g. Cheese, Cheeky, Cheers) but because it still displays the unhighlighted words it's not as easy to find them. I'd expect the unhighlighted words to disappear from the dropdown, leaving only the matching words. Jonathan3 (talk) 23:00, 8 August 2022 (UTC)

It's odd that it's showing non-matching values. Is this viewable on a public wiki? Yaron Koren (talk) 23:21, 8 August 2022 (UTC)

I'll email you. Jonathan3 (talk) 15:42, 9 August 2022 (UTC)

I updated PF to the latest version, at your suggestion, and it all works now :-) Thanks Jonathan3 (talk) 09:54, 10 August 2022 (UTC)

Can't enter just year for date field using Date input type

I used to be able to add, for instance, "2007" in a date field, and leave the day and month fields blank.

I upgraded PF to the most recent version a day or so ago, and now I get the " There were errors with your form input; see below." and "cannot be blank" error messages.

What can I do? Or is this a bug? Jonathan3 (talk) 21:58, 12 August 2022 (UTC)

I assume this is a mandatory date field. I just looked it up, though, and it looks like the code that handles mandatory date fields hasn't changed since 2016 or so. You could certainly argue that mandatory date fields should be allowed to just hold a year, although I think no one has complained yet about the current behavior (before now, that is), for whatever reason. My guess is that there was some JS bug in the handling of this form before, which prevented validation from taking effect, and now, with this upgrade, you're finally seeing the validation happening. The easiest solution for now is to just get rid of the "mandatory" part (although, if the field is always meant to hold just a year value, the best solution is to switch to the "year" input). But for the future, maybe it indeed makes sense to allow just the year - or just year + month, for that matter. Yaron Koren (talk) 15:45, 15 August 2022 (UTC)

Thanks. I definitely think that month/year or just year should suffice for a mandatory date field. Especially as Cargo is set up specially to handle that sort of thing, with the extra "precision" field. Jonathan3 (talk) 17:16, 15 August 2022 (UTC)

Edit summary disappears on page preview

Usually the edit summary remains after a page preview, but with PF if you type an edit summary, then view page preview, the edit summary box is blank. Jonathan3 (talk) 20:19, 18 August 2022 (UTC)

Thanks for letting me know about that - I checked in what I think is a fix for that, earlier today. Yaron Koren (talk) 01:07, 23 August 2022 (UTC)

Query Form | having field that depends on other field text

Hi!

I want to have a Query Form with two fields, one of them will allow to choose "main category" and the other will allow to choose "sub category" (but the sub category should depend on the user choose and don't show everything).

Let's assume I have a Cargo table with subcategories and the Main category choose will be 'select main_category from table' and the sub_category should be 'select sub_category' from table where 'main_category'={user_choose}', this is possible somehow?:)

Koshob (talk) 21:06, 31 August 2022 (UTC)

Yes, I think so - for the first field, you should have something like "input type=combobox|cargo table=table|cargo field=main_category", while for the second field, you should have something like "input type=combobox|cargo table=table|cargo field=sub_category|values dependent on=TemplateName[Field Name]", where TemplateName is the name of this template, and FieldName is the name of the first field. Yaron Koren (talk) 21:56, 31 August 2022 (UTC)

Thanks! Koshob (talk) 18:22, 1 September 2022 (UTC)