Extension talk:Page Forms/Archive September to December 2019

Display field values on Form Page?

Is it possible to display the value of a field on a Form Input Page without it being an input? For example, I have a Base Page (My Page) that contains a FormLink:

{{#formlink:form=Form_Name|query string=Form_Name[Base Page Name]={{PAGENAME}} }}

The Form:Form_Name page contains the following to create a unique page:

{{{info|page name=Form_Name-<unique number;start=1001>}}}

The Form:Form_Name page also contains:

{{{field|Base Page Name|}}}

When the FormLink is clicked, the field above (if not hidden) shows the correct value for "Base Page Name" as the PAGENAME from the original page (My Page). However, if I try to display this value like the following, it always shows up exactly like below ({{{Base Page Name|}}}) without being interpreted as the value (My Page).

{{{Base Page Name|}}}

Ultimately, the original page has a warning stored by Cargo I'd like to display on the Form Input page and I think I need the original page name to query for it. I can display the warning as a field input:

{{{field|Base Page Name|restricted}}} (restricted so it doesn't act like a form)

This seems like a hack. Is there a correct way to do this? --Bryandamon (talk) 08:17, 2 September 2019 (UTC)

I didn't follow everything, but what about adding a Cargo query to the form to display whatever it is you need? Jonathan3 (talk) 22:22, 4 September 2019 (UTC)

Adding "editor=visualeditor" prevents "restricted" from working

It seems that adding "editor=visualeditor" prevents "restricted" from working. If the field had "restricted", only admins/sysops are able to edit, however if "editor=visualeditor" is also added, the field is editable by anyone. --Bryandamon (talk) 01:38, 3 September 2019 (UTC)

PHP 7.2: Warning: count(): Parameter must be...

Datepicker triggers the following warnings

Warning: count(): Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 391

Warning: count(): Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 410

Warning: count(): Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 415

Warning: count(): Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 391

Warning: count(): Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 410

Warning: count(): Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 415

TiltedCerebellum (talk) 17:39, 22 September 2019 (UTC)

What version of Page Forms are you running? Yaron Koren (talk) 17:53, 22 September 2019 (UTC)

Page forms 4.5 (fe9dcc2) 09:23, 23 March 2019 on MW 1.33.0 (62dc614)TiltedCerebellum (talk) 18:10, 22 September 2019 (UTC)

Could you upgrade to the latest Page Forms? It could be that this problem has been fixed already. Yaron Koren (talk) 20:29, 22 September 2019 (UTC)

When I checked earlier today for a new download it provided the link to 4.5 as the latest version. Ah, nevermind it was from the download link in the right bar under Download that went to extension distributor link. Will look manually for a zip, install from there, turn error reporting back on and re-check. TiltedCerebellum (talk) 23:11, 22 September 2019 (UTC)

Yes, thank you that issue is resolved after the update. My apologies, I didn't know we couldn't rely on the right infobox links. I will be sure to check that in future. :) The other (separate) issues unfortunately still remain (as noted in the next topic). TiltedCerebellum (talk) 23:44, 22 September 2019 (UTC)

Similar Problem

Hi! I am experiencing a similar problem every time i save a page schema or read the category page containg the schema

Warning: count(): Parameter must be an array or an object that implements Countable in ../Extensions/PageSchemas/includes/PageSchemas.classes.php on line 148

Also on line 189 and occasionally 235 The code in question is:

$returnVals = call_user_func( array( $psHandlerClass, 'getSchemaDisplayValues' ), $schemaXML );
if ( count( $returnVals ) != 2 )

Installed versions are: MW 1.33.1 , PHP 7.3.10 (cgi-fcgi) , SMW 3.1.1 , Page Forms 4.6 , Page Schemas 0.4.9 , ParserFunctions 1.6.0

Switching to PHP 7.1.30 gets rid of the warnings.

Thanx a lot for your great work and looking forward to any suggestions, Andi 3ö (talk) 16:05, 6 December 2019 (UTC)

I believe this was already fixed in Page Schemas about five months ago, but I haven't released a new version yet with the fix - I need to do that. If you get the latest Page Schemas code, though, the problem should go away. Yaron Koren (talk) 21:15, 6 December 2019 (UTC)

Thanx a lot! Yes, you fixed it. Downloaded the fixed versions of PageSchemas.classes.php and includes/PS_ExtensionHandler.php from here and now the warnings are gone :) Andi 3ö (talk) 15:43, 7 December 2019 (UTC)

Great! And I'll try to release a new version of Page Schemas (0.5) soon. Yaron Koren (talk) 02:10, 8 December 2019 (UTC)

Multiple issues in 4.6

This is an awesome extension, it will be even more awesome if the following issues are addressed: (Pageforms 4.6 on MW 1.33 issues, PHP 7.2)

1. Template lines are not imported into the Create a Form page in the correct order
2. The Values from Category option only works in the default namespace, otherwise it includes the namespace in the page name, even though the page name is displayed without namespace on the page itself.
3. the following fields don't display their help/description/instruction text below the fields as they should, instead showing the following (looks like) template call text:

   ⧼pageforms-timepicker-mintime⧽, ⧼pageforms-timepicker-maxtime⧽, ⧼pageforms-timepicker-interval⧽

4. DISPLAYTITLE property does not work when Values from Category is selected, instead the name shows up as "0"
5. When pageforms is saved with the items out of order, the inputs are all assigned to the wrong fields (as if the mapping order of what input was entered for what field is modeled after the template order, but the form order itself is different. This renders the Create a Form function unusable. As an example, if my template contains:

{{Template
|a=
|b=
|c=
}}

When I go to create the form and attach a template it appears as:

Form field order:
b
c
a

I ignore the incorrect order and assign form types: a: text b: dropdown c: combobox

And instead upon saving the form it appears like this:

a=dropdown b=combobox c=text

With forms with many parameters, it makes it impossible to use the Create a Form feature.

Also, is there any way to get Pageforms to stop displaying namespaces in page titles? I'm using page names in a category to populate drop-down lists and other inputs and the values are all showing with the namespace (undesired). The think documentation says it the page name can be overriden by setting a different page name however I've already tried overriding this with and rather than showing "desiredname" it shows a 0 instead. I love this extension but my values are not usable if they can't be displayed without the namespace being included. The default namespace is not an option in this particular setup. Pulling values from a category is exceptionally useful when multiple forms populate data off the same categories as adding a page in that category will update the fields in all forms. Currently I can't share templates, forms and category page name values across namespaces and this is a real drag. :'( Even if the DISPLAYTITLE issue was fixed to display only the page title and not namespace:title, that would make this usable. Please consider fixing!

I also don't want to have to go to the trouble of mapping a bunch of values for something that already exists. The idea of populating the form data from categories was for the form to be auto-updated every time a page was added to that category but I can't do that if the namespaces are included in page names and title override does nothing. Or in other words, currently it looks like this can only be used in the default namespace or both your forms and the values for it from categories are not unusable :c

The goal of "(page name) Values from category" is to get just the page names, or perhaps it is best to add a note in the documentation that this does not work as expected outside the default namespace. Some help getting around the DISPLAYTITLE issue would be extremely helpful (pretty please). I can't imaging that page forms category values are only useful in the default namespace?

TiltedCerebellum (talk) 05:22, 22 September 2019 (UTC)

I'm messing around with the different templates and input types to try to determine which is causing the issue. No idea yet on the first, seems to be something to do with parameters whose names appear inside of other parameters (for example one of them is just "s" while another is "s1" and "s2" and the "s" suddenly is out of place on import and causing an issue with jumbling perhaps. The second issue with mismatch in controls may also be caused by changing the input type... it would look like that you have to blank every field when changing your mind on input type or once an input type is picked it is appended rather than cleared out and switched? Not sure, will have to test again to see. When inspecting the final result code, some inputs had multiple input type settings, which would lead me to believe the second is correct. It seems it is more detrimental than helpful to use the Create a Form feature currently.

Some parts of the edit form did not reach the server; double-check that your edits are intact and try again.

When attempting to preview pages, I see the following error: "Some parts of the edit form did not reach the server; double-check that your edits are intact and try again."

There appears to be a patch in-progress at https://gerrit.wikimedia.org/r/522605 however it doesn't work when applied unfortunately. PF 4.6 on MW 1.33, php 7.2 TiltedCerebellum (talk) 06:02, 5 October 2019 (UTC)

Does it happen with every form? And every time? Yaron Koren (talk) 17:15, 6 October 2019 (UTC)

Linking to form via navigation tab

Hello, I'm using PF to create a form that allows users to add structured notes to pages. To do that I decided to use a very simple way, linking to the form via 'formlink', which saves each note as a subpage of the page 'User:Username/Notepad'; each note/subpage has the name of the page which the note is referring to. So the form call is something like this:
{{#formlink:form=Add note|new window|link text=Add note|link type=button|target=User:{{#USERNAME:}}/Notepad/{{PAGENAME}}}}
Everything works fine with this, but now I want to add the call to this form on almost all the pages of my wiki. To do that I would like to add a new tab named 'Add note', next to the Discussion and History tabs. I've seen several guides to create a new tab (like this and this) via hooks, but seen that I am pretty a dummy in php ,I am not able to properly deal with it. So I wrote this code:

<?php
if( !defined( 'MEDIAWIKI' ) ){
        die( "This is not a valid access point.\n" );
}

$wgHooks['SkinTemplateNavigation'][] = function ( SkinTemplate &$skin, &$links) {  
        $addNote = Title::newFromText( 'Special:FormEdit/Add note/User:{{#USERNAME:}}/Notepad/' . $skin->getTitle()->getText() );
// Add an additional link
        $links['views']['main'] = array(
                'class' => false, // false or 'selected', defines whether the tab should be highlighted
                'text' => "Add note", // what the tab says
                'href' => $addNote->getInternalURL(),  // where it links to
                'context' => 'main',
        );
        return true;
};

But obviously it's not working since I can't use variables like {{#USERNAME:}} in php. So, do you think it's possible to do what I need in a simpler way using PF linking functions? Or I have to find a solution to do that via hooks?
Thanks for your collaboration, any help is really appreciated.
--Loman87 (talk) 13:56, 15 October 2019 (UTC)

This isn't a Page Forms question per se, but I think you can get that "$addNote =" line working by replacing it with these two lines:

        global $wgUser;
        $addNote = Title::newFromText( 'Special:FormEdit/Add note/User:' . $wgUser->getName() . '/Notepad/' . $skin->getTitle()->getText() );

Yaron Koren (talk) 16:45, 15 October 2019 (UTC)

You can get the user via the skin too, and avoid the global, e.g.:

$addNote = Title::newFromText( 'Special:FormEdit/Add note/User:' . $skin->getUser()->getName() . '/Notepad/' . $skin->getTitle()->getText() );

Sam Wilson 00:22, 16 October 2019 (UTC)

Even better. Yaron Koren (talk) 15:43, 16 October 2019 (UTC)

Thanks for your help guys and sorry if this was a bit out of topic here. Your code works perfectly, anyway it seems like it would be better for my purpose to use the {{#formlink}} parser function (e.g. to open the form in a popup window and to pre-fill some fields). Would it be somehow possible to link it from a tab, like the 'Discussion' tab as I described in my first post? Thanks again for your help! Loman87 (talk) 07:28, 23 October 2019 (UTC)

That's basically what you're doing now, no? Yaron Koren (talk) 14:16, 23 October 2019 (UTC)

Well not exactly. Thanks to your help I can link to my form via Special:FormEdit/... from a tab present on every page of my wiki. But I finally found out that a {{#formlink}} call would be more useful for my needs (e.g. I want the form opened in a popup and some fields prefilled). So I was wondering how include the {{#formlink}} call on every page of my wiki as it has been done with the Special:FormEdit/... link. I don't know if I explained myself... Loman87 (talk) 09:41, 24 October 2019 (UTC)

It's strange to have a tab that, when clicked, brings up a popup window - that's not really a tab at all. What about instead having a link somewhere on the page itself? Then you could have the relevant template(s) add it, without the need for any custom coding. Yaron Koren (talk) 16:11, 24 October 2019 (UTC)

Update a template in another page from form

Is it possible to update another pages template without adding the #autoedit button? When submitting a form I would like to also update a dependent property in another Page.

If I have a Page of Category Collection with a multiple instance template member, and a Page of Category Concept (which has a form Concept) which has a property memberOf I would like to also populate the Collection[member] with the pagename of the current submitted item.

I've looked at partial forms, but was unsure if I could start two info tags (One partial, followed by regular) and have one submit button for both.

Thank you very much! Øyvind

Before we get to the mechanics of what's possible with forms - it sounds like you're storing the same information (a relationship between two pages) twice, once in each page. Is that true? If so, that's a bad idea. You should only store the relationship once, in one page or the other. Yaron Koren (talk) 20:26, 17 October 2019 (UTC)

According to the model I'm implementing from the relationship should be present in Collection (Begrepsamling nb) only. However I placed the property on Concept (Begrep nb) to create a working prototype. I use the following forminput on "Collection" view to add or edit a "Concept" and to go to its form:

{{#vardefine:ns_from_identifier|{{#ask: [[{{FULLPAGENAME}}]]|?Dct:identifier= |mainlabel=-}} }} {{#forminput:button text=Legg til nytt Begrep|form=Begrep|link type=button|query string=Begrep[medlem]={{PAGENAMEE}}|namespace={{#var:ns_from_identifier}}|autocomplete on namespace={{#var:ns_from_identifier}}|reload|new window|no autofocus }}

"Collection" has it's own form, which defines which tabs (HeaderTabs) and namespace (for user rights) should be present and used on the "Concept" form, and I needed a relationship to query, so I'll have to do some rewriting if I manage to move the relationship :)

I enjoyed reading your Working with Mediawiki as an introduction to MW.

Øyvind

Additional Query Button creating Invalid Request

Hi,

I have upgraded from Mediawiki 1.27.5 to 1.31.5 and am using Page Forms version 4.5.

When I run the Additional Query button at the bottom of my #queryformlink I do not get a valid page and it sends me back to my site home page.

I have a simple form that has one parameter.

The browser URL text that is produced is as follows:

..../index.php?pfRunQueryFormName='Field'='Value'&wpRunQuery='Label'&pf_free_text=

Is there a need for different syntax in MW 1.31.5?

Thank you,

Gregg

I run into the same problem. Comparing the URL to the original URL, it seems the pagename is missing

so instead of ..../index.php?pfRunQueryFormName=...

it hould probably look like ..../index.php/pagename?pfRunQueryFormName=...

~cmdrKEEN

Everything about that URL looks wrong... is this query form contained in Special:RunQuery, or on some other page (which transcludes Special:RunQuery)? Yaron Koren (talk) 20:45, 25 October 2019 (UTC)

Hi Yaron.

The URL is what I see after I click on the additional query button that is available on the page that is produced from a #querylinkform. In other words:

Step 1: From Homepage run #querylinkform -> Works fine, New Page is produced with query results

Step 2: Attempt to run Additional Query at bottom of page in Step 1 with new or existing value

User is returned to Home page and the URL in the Home page browser address bar as a result of Step 2 is what I have shown above.

I can provide more data as needed.

Thanks, Gregg

What does the URL of the query form look like? Yaron Koren (talk) 21:32, 25 October 2019 (UTC)

Happy to provide:

Step 0 #queryformlink code for completeness:

{{#queryformlink:form=Convention Card|link text= Display Convention Card|link type=button| query string=Convention Card[SystemID]=1&_run}}

Step 1 URL - Query Resulting Page

http://../mediawiki/1.31.5/index.php/Special:RunQuery/Convention_Card?Convention_Card%5BSystemID%5D=1&_run=

Step 2 URL - Return to Homepage - Query not completed

http://.../mediawiki/1.31.5/index.php?pfRunQueryFormName=Convention+Card&Convention+Card%5BSystemID%5D=1&wpRunQuery=Display+Convention+Card&pf_free_text=

Let me know if you would like anything else. Gregg

Yaron, I am having other problems with my installation, I think related to the fact that my MW installation is operating is behind a reverse proxy. Would this setup cause the erroneous behaviour I've shown? If so, do you know a work around? Gregg

I don't know. The value you listed now for pfRunQueryFormName looks a lot more normal than what you listed before ('Field'='Value'). Did something change? Or was it just described in an unclear way before? Yaron Koren (talk) 17:07, 27 October 2019 (UTC)

Hi Yaron. Before I was removing my specific values and replacing with 'generic' ones. In the last I cut and paste verbatim what I observed. Are there any experiments I can try?

Okay, I just wanted to make sure. I think upgrading to the latest version of Page Forms will fix this problem. Yaron Koren (talk) 23:18, 27 October 2019 (UTC)

Hi Yaron, I had some problems with my setup and so could not tryout PageForms 4.6 until today. You are correct in that Version 4.6 works as expected (works correctly now) and I have since only tested on MW 1.33.1 since I moved up a version as an experiment but will stay there for now. I am back to business as I had it in MW 1.27.5. Thanks for your patience.

Multiple choice in listbox doesn't work when reediting while using mapping template

Hi Yaron,

I'm using PageForms 4.5. Currently I have the following problem:

• the form contains a listbox which is mapped with a mapping template => works fine
• while creating a page with the form I can choose multiple values from the listbox
• the values are stored well with #arraymap
• reopening the page with the form there are no values selected in the listbox
• this way only works when ONE item from the listbox is selected
• when I use the form without the mapping template all former chosen values are shown correctly.

What is to be done?

Hi Yaron, any idea?

Sorry for not responding before. Is this still a problem with the latest version of Page Forms? Yaron Koren (talk) 14:14, 30 October 2019 (UTC)

Hi Yaron, yes with 4.6 it is the same. What is to be done?

Any idea? --DDSnowl (talk)

Could you pastebin the source text of the relevant form and template - or, if this is a public wiki, link to them? Yaron Koren (talk) 14:31, 16 December 2019 (UTC)

$wgRawHtml = true not working in Forms namespace

Hi, it seems it is impossible to allow $wgRawHtml in the Form namespace ? --Varlin (talk) 13:17, 1 November 2019 (UTC)

I don't know why that's happening, but it seems good... allowing raw HTML in the form sounds dangerous. Why would you want that? Yaron Koren (talk) 14:14, 1 November 2019 (UTC)

I needed to insert <label> tags, cause the default automatic insertion of labels is not flexible. Dangerous? If the form definition is only editable by sysop I think it's not. (Ew, of course I hope the html is not allowed inside the fields) --Varlin (talk) 14:40, 1 November 2019 (UTC)

That's true - if only admins can edit form definitions, and you know what you're doing, it should be fine. However, this would probably require a change to Page Forms' parsing. I do want to better support labels in the future. If it's just the label tag, by the way, one option is to use the Widgets extension and create a "label" widget - that should work, I think. Yaron Koren (talk) 15:37, 1 November 2019 (UTC)

Thanks for the advice. I'll try it. In fact I could have stick to default labels with display=table (it has the advantage of a cleaner wikitext code), but it seems it does not work with embedded fields, so I had to construct manually the table, and so the fields have no labels. --Varlin (talk) 11:43, 2 November 2019 (UTC)

What do you mean by embedded fields? Yaron Koren (talk) 15:59, 3 November 2019 (UTC)

I mean using embed in field= like defined here. --Varlin (talk) 16:36, 3 November 2019 (UTC)

Oh, okay... that's too bad; it sounds like a bug. Yaron Koren (talk) 18:31, 3 November 2019 (UTC)

Fields with 'values from category' display html markups

Upgraded from PageForms 4.2.1 to 4.6 and experienced strange behavior with fields which are using 'values from category='. (on MediaWiki: 1.30 and SemanticMediaWiki: 2.5.6)

Eg. {{{field|businessArea|input type=textarea with autocomplete|values from category=Business Areas|remote autocompletion}}}

All such input fields in the form display expected value but wrapped with html markups: <span style="display:none">VALUE</span>. Also autocomplete works when you start typing '<span' ...

How to fix this behavior? --Mourawi (talk) 4 November 2019 (UTC)

After some more debugging I realized that in order to remove displaying titles on these pages I used {{DISPLAYTITLE:<span style="display:none">{{FULLPAGENAME}}</span>}} on all of them ... which apparently influenced how selection of these pages works now.

I guess in order to fix this new not desired behavior I have to find another way to hide a title on the pages (this applies to only some categories, so I can't use css approach). Any other hints ? --Mourawi (talk) 4 November 2019 (UTC)

Try adding "$wgPageFormsUseDisplayTitle = false;" to LocalSettings.php. Yaron Koren (talk) 02:59, 5 November 2019 (UTC)

That is what I did and it's working fine. Thanks

Bug in multiple instances with fields using "textarea with autocomplete", "list"/"delimiter=;" and "values from category/concept"

PF 4.5 + 4.6. Saving new instances with the above field appears to be working fine. However, the trouble starts when I reload the form and notice that these textarea fields are empty if they contain more than one value and so naturally, their content gets removed after I save the page. I'm afraid that in this way I've unwittingly thrown away some work over the course of several months. Curiously enough, but probably unrelated, if these fields contain one value only, the value itself is preserved fine (in the form) but the delimiter at the end has disappeared. Cavila 15:59, 7 November 2019 (UTC)

What about using the "tokens" input instead? I think that's generally the better choice anyway. Although maybe it has the same bug. Yaron Koren (talk) 16:47, 7 November 2019 (UTC)

Thanks for the quick reply. The issue does not happen with "text" or "tokens" as input types I think. I'm definitely using "tokens" in many, perhaps even most other situations where value arrays are concerned, but they are not a one-size-fits-all solution. In this case, textareas proved to be the user-friendlier (lightweight?) option, as it became easier for users to copy/paste and edit lots of data. Also, Select2 tokens are more unwieldy if you need to fit them in a tight space while I have workable solution using expandable textareas, and editing tokens can be a little buggy sometimes. Hope that makes sense. Cavila 17:29, 7 November 2019 (UTC)

That all makes sense except for the buggy editing part - I didn't know about that. Anyway, I guess the "values from ..." bug will have to be fixed, although it's good to know that it's restricted to just this one input type (well, maybe "text with autocomplete" too). Yaron Koren (talk) 04:57, 8 November 2019 (UTC)

I just tried reproducing this bug, by the way, and couldn't. What is the exact tag for that input in the form definition? And do you see any JS errors in the console? Yaron Koren (talk) 05:42, 8 November 2019 (UTC)

$wgPageFormsSimpleUpload uploads image before page save

After some testing, I figured out the following:

If you set

$wgPageFormsSimpleUpload = true;

then the image gets already uploaded to the wiki before the user saves the form. I guess this is somewhat intended/needed behaviour since an impage preview is displayed in the form. However, I think this has to be clearly identified since it breaks the default behaviour of a wiki/page forms.

A user has to be sure that nothing gets entered in the wiki unless he/she hits "save".

BTW: it does not matter of you set

|image preview

in the form field definition or not, the preview is there always when $wgPageFormsSimpleUpload ist set to true and the image always gets uploaded to the wiki at the time the user selects it from the PC.

--Krabina (talk) 14:48, 11 November 2019 (UTC)

Jquery error in autocompletion

Hello, I'm getting this error on pages with forms with the input type "text with autocomplete":

JQMIGRATE: jQuery.fn.bind() is deprecated VM2220:167 Error setting autocompletion: TypeError: Cannot read property 'element' of undefined

When I start typing in the field with autocompletion the browser debugger gives also the following uncaught error:

VM2684:155 Uncaught TypeError: Cannot read property 'element' of undefined
    at $.<computed>.<computed>._suggest (<anonymous>:155:178)
    at $.<computed>.<computed>._suggest (<anonymous>:7:579)
    at $.<computed>.<computed>.__response (<anonymous>:154:469)
    at $.<computed>.<computed>.__response (<anonymous>:7:579)
    at $.<computed>.<computed>._superApply (<anonymous>:7:410)
    at $.<computed>.<computed>.__response (<anonymous>:156:988)
    at $.<computed>.<computed>.__response (<anonymous>:7:579)
    at <anonymous>:154:157
    at Object.success (<anonymous>:166:363)
    at fire (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1pn19ua:46)

My configuration is the following :

MediaWiki 1.31.1

PHP 7.0.33-0ubuntu0.16.04.7 (apache2handler)

MySQL 5.7.27-0ubuntu0.16.04.1

ICU 55.1

Elasticsearch 5.6.1

Lua 5.1.5

Pageforms 4.5

I updated from PF 4.1 when the error was generated only in some fields.

Any ideas about the reason?

Thanks for the help,

Lorenzo

I don't know, but can you try upgrading to either version 4.6 or (even better) 4.7-alpha of Page Forms, to see if the problem is still there? Yaron Koren (talk) 15:23, 13 November 2019 (UTC)

Thanks for the answer Yaron. 4.6 seems to solve the problem actually, I wasn't sure it was compatible with my MW version. Bye!

File upload form - Special:FormEdit should recognise wpDestFile

When you want to use page forms for uploading files in your wiki (which btw. works great, you specify a form that enters pages in the File: namespace), you could redirect the "Upload file" link with $wgUploadNavigationUrl to your form, e. g. Form:Fileupload

However, if you want to use $wgUploadMissingFileUrl to point red links to files to the form, you could set $wgUploadMissingFileUrl = '/Special:Edit form/Fileupload/'; but the problem is, that the form does not regognise the (?|&)wpDestFile=<filename> paramater that will be added to the URL according to Manual:$wgUploadMissingFileUrl. So the resulting link is

Special:FormEdit/Fileupload/?wpDestFile=Filename.jpg

when it should be

Special:FormEdit/Fileupload/Filename.jpg

for page forms.

Show on select only works for the first instance of multiple instance templates

Hi everybody,

I am using pageforms 4.5.1 and MW 1.32.1 and I am facing the following problem:

In my form I have a radiobutton field which should trigger another field within multiple instance templates (MIT) to appear/ or to be hidden. For the first instance this works well, but beginning from the second instance this field is always been shown although the user has choosen the field values outside the MIT, that normally should hide this field.

This is my code in a simplfied way:

{{{for template|test}}}

{{{field|select|input type=radiobutton|values=add,hide|default=hide|show on select=add=>add|mandatory}}}

{{{field|MIT|holds template}}}

{{{end template}}}


{{{for template|test mit |multiple|add button text=Add row<!--|minimum instances=1-->|embed in field=test[MIT]|mandatory}}} 

Name: {{{field|name|input type=text }}}
<div id="add">Country: {{{field|country|input type=dropdown|values=DE,US,TZ,FR}}}</div>

{{{end template}}}

Anybody an idea? Is this a bug or some failure in the code from my side?

I have also already tested it with Page forms 4.6 without success. Had then to revert to 4.5.1 because using a "uploadable" field within MITs is not working anymore after the upgrade to 4.6.

--Shuitavsshente (talk) 13:06, 25 November 2019 (UTC)

VE4All and PopUp Forms

finally got VEforAll integrated into my site and discovered that while it does work for "normal" forms, it doesn't work for popup forms.. can anyone confirm this?

• MW - 1.31.2 (5951e3e)
• PF - 4.5.1 (bb1beb0)
• VE4All - 0.1 (0ed0f27)

/R.Evans

Error using UML extension with Page Forms

I'm unable to use PlantUML notation to create a diagram with the extension notation using a form. Other PlantUML diagrams work via the form, but the <|-- results in the following error: "|" is not allowed, except within {{...}}, [[...]], or special tags

It seems that the issue is with the Page Forms processing of the content in the <uml> tags.

I'm using Mediawiki 1.33.1, along with [4.6] and [0.7]. As an example, I'm trying to allow for PlantUML input in a form (e.g. text area input). This works for some diagrams, but will produce an error with others, such as:

 
<uml>
Class01 <|-- Class02
</uml>

The {{!}} template does not work in this case as it is read as syntax error by PlantUML. --MeganKatsumi (talk) 16:07, 25 November 2019 (UTC)

Dependent Autocompletion Help

Ok, We've a perfect application for this feature, but I'm having trouble interpreting the documentation. Somewhere the relationship for say, the Countries and Cities needs to have been stored. Where are they stored? I was thinking it was something like the mapping template option, but I can't seem to make it work (slightly confounded perhaps the sandbox errors associated with 1.34 rc at time of this post). I found related topics here and here but I'm still not seeing how/where the relationship is already stored such that the form can 'know' which list of values to get. Thanks! - Lbillett (talk) 14:37, 5 December 2019 (UTC)

It gets that information from other pages of the same type as the one being created - for the case of the example, other restaurant pages. Yaron Koren (talk) 19:11, 5 December 2019 (UTC)

Page Forms Preview not working

I am working on setting up a new installation of MW 1.33 and have the latest version of Page Forms installed. When trying to preview changes to a form I get the following error:

"Sorry! We could not process your edit due to a loss of session data. Because {wiki} has raw HTML enabled, the preview is hidden as a precaution against JavaScript attacks. If this is a legitimate edit attempt, please try again. If it still does not work, try logging out and logging back in, and check that your browser allows cookies from this site."

I started digging through the code and found that this error is being generated by EditPage->getPreviewText() if mTokenOk is set to false. However, it doesn't look like mTokenOk is ever set to anything other than its default false value in this api call. Perhaps this has something to do with it?

If anyone has any ideas, It'd be greatly appreciated!

UPDATE

Did some digging into the code and found that in the core EditPage.php the TokenOk method never gets run when trying to preivew a page form. This is because of this line: $this->incompleteForm = !$request->getVal( 'wpUltimateParam' ). wpUltimateParam is null when you try to preview the form so this always results in true. Since $this->incompleteForm is true, EditPage->tokenOk() method never gets called in subsequent if statement. This ultimately leads to PF_AutoeditAPI.php calling EditPage->getPreviewText() without ever setting the EditPage->mTokenOk attribute. Because of this EditPage->getPreviewText() displays the 'session_fail_preview_html' message (Sorry! We could not process your edit due to a loss of session data ...)

This looks like it might have been introduced sometime between 1.29 and 1.33. I have an instance of 1.29 installed and the if statement that starts the whole chain reaction above looks like this $this->incompleteForm = ( !$request->getVal( 'wpUltimateParam' )&& is_null( $this->edittime ) ). This correctly results in false because $this->edittime is set when trying to preview a PageForm.

is a minor autoedit possible?

I'm using {{#autoedit:...}} to allow users to perform really basic state changes to a template. It works great, thank you. However, page watchers are getting notified every time the autoedit function is clicked. This is causing users to "unwatch" the pages due to the spam.

Is it possible to allow a page developer to program the autoedit function to specify that the autoedit is a "minor edit" and thus not generate the notifications?

Thanks,
/ R.Evans

I don't think so, but it's a good idea - adding a parameter called "minor" or "minor edit" to #autoedit makes sense. Yaron Koren (talk) 16:40, 10 December 2019 (UTC)

Alright, I just added the parameter "minor" to #autoedit in the Page Forms code. It's still an undocumented feature, though. Yaron Koren (talk) 19:53, 17 December 2019 (UTC)

Guessing field values from page name

I'm trying to preset fields in a form, based on the page name that is created when using my contact form. The corresponding contact template is used as:

{{Contact
|First name=
|Last name=
|Company=
}}

More specifically, if the user presses the "create or edit" button for a page named Jean-René Bouvier, I'd like the form to contain placeholders for the first name and last name. I've tried to set placeholder={{#explode:{{ PAGENAME }}| |-1}}, mandatory for the Last name field, but the form does not honor wiki expansions.

Question 1: is there a proper way to achieve this?

Then, once the user possibly modifies the values of First name and Last name in the form and presses the "save" button, I'd like the page to be renamed {{{First name}}} {{{Lastname}}}.

Question 2: is there a way to do so?

JRB (talk) 08:44, 11 December 2019 (UTC)

You should be using the "one-step process", where the user doesn't type in a page name at all, but the name is instead generated automatically. See here. Yaron Koren (talk) 14:46, 11 December 2019 (UTC)

0 is not a valid form when using Edit with form

I'm receiving error: "0 is not a valid form" when attempting to use the default Edit with form action created by Page Forms (4.6) in MW 1.33.

I created created a form: Add or Edit Boss Dragon Then added {{#default_form:Add or Edit Boss Dragon}} to the following category: Category:Boss Dragons (deleted for now as it triggers the error mentioned).

Strangely, using the form itself and typing in the page name (e.g., Mini) will edit just fine. If I explicitly specify the form with which to edit it also edits fine, e.g., https://dragon-mania-legends-wiki.mobga.me/Special:FormEdit/Add_or_Edit_Boss_Dragon/Mini

But the trigger to Edit with form is broken. Any idea what could be causing this? As mentioned above, I have removed the {{#default_form:Add or Edit Boss Dragon}} from mycategory page to prevent users from triggering the error from the default Edit with form link created by Pageforms in our skin's Actions menu. Would really love to know of a workaround or fix for this as we love the extension :(

For now I'm going to be cloning the site to a test space and disabling extensions one by one to try to determine if it is a compatibility issue with another extensions and will post if I find anything. TiltedCerebellum (talk) 02:08, 15 December 2019 (UTC)

Update - site cloned and example of the error can be seen at: https://www.dragon-mania-legends.wiki/index.php?title=Mini&action=formedit

That's very strange! I don't know if I've seen that error before. Are you using a custom ID for the PF_NS_FORM namespace? Have you made any changes to the local Page Forms code? If neither of those - if you have access to the SQL database for your wiki, it would be great if you could run the query "SELECT * FROM page_props WHERE pp_propname = 'PFDefaultForm'" on that database, and let me know what it outputs. Yaron Koren (talk) 04:35, 16 December 2019 (UTC)

I was experiencing the same problem with one of my forms. I ran that SQL query and got this:

pp_page	pp_propname	pp_value	pp_sortkey
1383	PFDefaultForm	Law School	NULL
1430	PFDefaultForm	Case Brief	NULL
1479	PFDefaultForm	Case Brief	NULL
1484	PFDefaultForm	Case Brief	NULL
1674	PFDefaultForm	Class-Specific Outline	NULL
1885	PFDefaultForm	Case Brief	NULL
1886	PFDefaultForm	Case Brief	NULL
1887	PFDefaultForm	Case Brief	NULL
1891	PFDefaultForm	Case Brief	NULL
2010	PFDefaultForm	Case Brief	NULL
2030	PFDefaultForm	Case Brief	NULL
5906	PFDefaultForm	Professor	NULL
19499	PFDefaultForm	Case Brief	NULL
19581	PFDefaultForm	Law Firm	NULL
19850	PFDefaultForm	Text-Specific_Outline	NULL
19878	PFDefaultForm	Case Brief	NULL
19886	PFDefaultForm	Case Brief	NULL

FYI, the one and only form that is having this issue is the "Case Brief" form. I have no idea why it shows up so many times on the list, but I'm guessing it's related to why that's the only form with this problem.

My install info:

Product	Version
MediaWiki	1.33.0
PHP	7.1.33-3+0~20191218.29+debian8~1.gbp18b07c (fpm-fcgi)
MySQL	5.6.46-86.2-log
ICU	64.1

The extension version:

4.6 (71f42d6) 09:08, September 4, 2019

Any help is much appreciated! -Lost Student (talk) 05:55, 20 January 2020 (UTC)

Update

I just realized that the error ...is not a valid form was just the result of a stupid user error on my part. Within the form I had the parser {{#forminput:form=Infobox Case Brief}} but the name of the form is really just "Case Brief." I fixed it and is appears to be working.

I don't know why it shows up so many times in the database, but it's functional. -Lost Student (talk) 06:11, 20 January 2020 (UTC)

Update to the Update

I just figured out that the query was looking for category pages that name a form as the default form (duh), and I have that particular form called on a bunch of sub-categories. So that answers that. -Lost Student (talk) 06:17, 20 January 2020 (UTC)

values from namespace=<multiple namespaces>?

I have the need to get get certain values from more than one namespace, see example. How could this be achieved? --Wikinaut (talk) 00:10, 16 December 2019 (UTC)

{{{field|Has project tag|input type=tokens|values from namespace=Assembly|values from namespace=Session}}}

Just separate the namespaces with commas, like "values from namespace=Assembly,Session". I see now that this feature has remained undocumented, even though it was added about a year ago. Sorry about that - I just updated the documentation. Yaron Koren (talk) 04:45, 16 December 2019 (UTC)

Cool! Thanks!! --Wikinaut (talk) 12:05, 16 December 2019 (UTC)

`for template` can lead to not-unique GUIDs

Using the syntax described below, sometimes leads to not-unique GUIDs. The behaviour I noticed is that the first two entrys are unique, but all following share the GUID from the second entry. When creating them step-by-step (e.g. creating two, saving, creating two new e.t.c.) this does not occur. Is there any way to 'convince' the wiki to render the template, every time an entry get's addeds?

{{{for template|Event|multiple|minimum instances=1|add button text=Add another timeslot (aka event) to this session}}}
{| {{Form/Event}}
> Here were things, i left out. For more details, see https://events.ccc.de/congress/2019/wiki/index.php?title=Form:Session&action=edit
|-
|}
{{{field|GUID|hidden|unique|default={{UUID}} }}}
{{{end template}}}

--SimeonKeske (talk) 12:46, 18 December 2019 (UTC)

Right, what you're trying will not work. Why do you need a unique ID for each event, anyway? Yaron Koren (talk) 14:47, 18 December 2019 (UTC)

Hmm, ok. The unique IDs are needed, because the specific events get imported into a schedule (data.c3voc.de/36C3/everything.schedule.xml) which then can be imported into an app (e.g. github.com/EventFahrplan/EventFahrplan) where the user can for example select favourite events and subscribe to changes. --SimeonKeske (talk) 15:26, 18 December 2019 (UTC)

I am backing him up, we are working on the same 36C3-Congress-Wiki. Just added here and try to use

$wgPageFormsCacheFormDefinitions = false;
$wgPageFormsFormCacheType = null;

acccording to https://www.mediawiki.org/wiki/Extension:Page_Forms/Defining_forms#Caching_form_definition .

We will report back here if this fixed the issue. --Wikinaut (talk) 15:40, 18 December 2019 (UTC)

Ok, it seems like it was not successsfull. --SimeonKeske (talk) 15:55, 18 December 2019 (UTC)

Okay, I see how a unique ID could be useful. I don't think it can be done in multiple-instance templates, unless explicit support for this is added to Page Forms. I would guess that the best approach for this would be to change to have a separate page for each event. The event information can then still be displayed within session pages, so to users it might not look any different. Yaron Koren (talk) 16:06, 18 December 2019 (UTC)

Concatenate fields prior to storing in Cargo

I have a situation where I have a number of forms / tables. For example:

Form 1: House Type >> cargo table: House Types
Form 2: Roof >> cargo table: Roof types
Form 3: Material Type >> cargo table: Material
Form 4: Source >> cargo table: Material source

I then have a form for creating a joined up version. The form has the fields

- House Type with a list of values using the house types cargo table
- Roof type with a list of values using the roof type cargo table
- Material type with a list of values using the material cargo table
- Source with a list of values using the material source cargo table

When I store to the cargo table I consolidate the 4 fields in the template. The table has the 4 fields and an additional field that looks like this:

Condolidated = House Type.Roof.Material.Source The records would look something like this:-

Georgian.90degree.Slate.Wales
Victorian.90degree.Slate.Belgium
etc etc

The separate fields don't need to be unique. But the resulting consolidated field does. I can test in the cargo field using Unique & Mandatory, but this is not ideal as though the duplicate record will not be posted to cargo, it will sit in the queue and the page will exist.

What I'd like to do is catch it in the form. Problem is the component parts that are consolidated in the template will not be unique in the form. It is that I need to consolidate in the form and then test for uniqueness.

Any tricks?

Michaeldakin (talk)

There's no way in the form to check for uniqueness of a computed field, I don't think. If this were done, it would have to be done through the use of hooks - either JavaScript or PHP, I'm not sure which makes more sense - which some outside code then used to stop the saving of a page that contained a duplicate value for that computed field. I don't think a usable such hook exists in Page Forms, so it would need to be added... Yaron Koren (talk) 16:17, 25 December 2019 (UTC)

Ok thanks. I'll stick it on the backburner for now and decide which approach to use later down the line. I'll think about procedural solutions. As it tends to be a one off job at configuration stage, it may be just a case for some kind of housekeeping procedue (no pun intended). I'll mull it over. Michaeldakin (talk) 20:41, 25 December 2019 (UTC)

Saved values are not displayed as selected in edit-with-form view for listbox field in multiple-instance template

I'm working on a form that will use a multiple instance template. Within each instance, the first field is a simple dropdown. The second field is a listbox, which lists all possible values from a category of pages. I would like to use the mapping property option to display alternate text than the pagenames. But it seems there's an issue. Even though I selected multiple values and saved the page, and I confirmed the values are set in the page's template call by viewing the source, the form does not display these values as selected upon the next "edit with form" load. Below is a snippet from the form:

{{{for template|Test event activity module|multiple|add button text=Add activity module|label=Activity modules}}}
{{{field|ACTIVITY_MODULE|input type=dropdown|values from category=Activity module analog|mapping property=Ops Nom}}}

'''Completed objectives:'''

{{{field|COMPLETED_APPLICABLE_OBJECTIVES|input type=listbox|values from category=Test objective|size=40|mapping property=Has text title}}}
{{{end template}}}

Note that I have a similar form that does not use the multiple instance thing and it seems to work with the mapping property. So I wonder if it's an issue with the multiple instance aspect. I'm not sure where I could try to replicate this in a public wiki. If you have a place, I can try to set up an example.

--Darenwelsh (talk) 23:39, 27 December 2019 (UTC)

It would be great to replicate this, yes. Given that this uses SMW, probably the best place to try to reproduce it is at https://sandbox.semantic-mediawiki.org. Yaron Koren (talk) 16:36, 29 December 2019 (UTC)

I tried here, but it seems they've got bigger issues based on the banner there that says, "The update to the MediaWiki 1.34.0-rc.0 release candidate resulted into an armada of issues with multiple extensions." If you've got another place, I can try again. --Darenwelsh (talk) 14:29, 30 December 2019 (UTC)

That's too bad. I don't know... but just to clarify: does this problem happen for both the dropdown and the listbox? Yaron Koren (talk) 18:25, 30 December 2019 (UTC)

Just the listbox. I think it's related to the mapping property, since it seems to display the saved values if I don't use the mapping feature. And it seems to only be for multiple instance templates using mapping. Darenwelsh (talk) 20:03, 30 December 2019 (UTC)

Moving the conversation to T241745.

Query based on a previous query results

It could be me, but I can see no way to carry out a query based on the results of a previous query. I suppose for me this would be the biggest step forward. Whether this is being able to write to a Cargo table based on the result of a query or a way of holding a result and then running another query based on that result. I could describe why this would be massively beneficial, but maybe you don't need me to? But in short if I'm querying based on the user and this gives me a set of results, I then want to further query based on those results on another table. I no longer want to query the other table based on the user, but now on a field in the results.

It could be my lack of expertise but holding a query in a temporary table to then carry out a further query would be very powerful for me. Am I asking for the impossible?

Michaeldakin (talk) 14:56, 29 December 2019 (UTC)

Yes, you can run a query based on a previous query, by using the "template" format and having the display template itself contain a query. (You probably would need to have "no html" specified for the outer query.) Another potential option is to do everything in a Lua module, using the Scribunto extension. Are you sure, though, that what you're trying to do can't be done in a single query? Yaron Koren (talk) 16:41, 29 December 2019 (UTC)

Yes I'm pretty certain it cannot be done in a single query, because the selection criteria on the query tells it to get info based on the user. I then need to go to the same table and get records where the other users have a field set based on a field set on the originally selected user. I gave it many hours of thought on how to organise my data differently to make it work and came up with a solution to sort of cheat, where I hard code the users into the original user record. That works to an extent, but then I still find myself having issues later down the flow. So I think you have given me a solution with the template format. I'll have to play and get my head around how the template format feeds the outer query. I could go down the LUA route, but I'd avoided because I never seem to get quite what I want out of LUA. A reflection on the fact I'm not a programmer - not a reflection on the capability of LUA. Best regards and happy new year Michaeldakin (talk) 15:30, 30 December 2019 (UTC)