Extension talk:Page Forms

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:

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

The Form:Form_Name page also contains:

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 without being interpreted as the value (My Page).

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:
 * (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:

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: 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: But obviously it's not working since I can't use variables like  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:


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


 * You can get the user via the skin too, and avoid the global, e.g.:
 * Sam Wilson 00:22, 16 October 2019 (UTC)
 * Even better. Yaron Koren (talk) 15:43, 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  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  from a tab present on every page of my wiki. But I finally found out that a   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   call on every page of my wiki as it has been done with the   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:

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

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

it hould probably look like


 * ~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:


 * Step 1 URL - Query Resulting Page


 * Step 2 URL - Return to Homepage - Query not completed


 * 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 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  (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  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.

All such input fields in the form display expected value but wrapped with html markups: VALUE. 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 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":

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

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  to your form, e. g. Form:Fileupload

However, if you want to use  to point red links to files to the form, you could set but the problem is, that the form does not regognise the (?|&)wpDestFile= 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:

Name: Country:

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 tags.

I'm using Mediawiki 1.33.1, along with [|PageForms 4.6] and [|UML 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:

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:. wpUltimateParam is null when you try to preview the form so this always results in true. Since  is true,   method never gets called in subsequent if statement. This ultimately leads to PF_AutoeditAPI.php calling  without ever setting the   attribute. Because of this  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 correctly results in false because  is set when trying to preview a PageForm.

is a minor autoedit possible?
I'm using  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  form. The corresponding  template is used as:

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  for the   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  and   in the form and presses the "save" button, I'd like the page to be renamed.

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

values from namespace= ?
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)


 * 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?

--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:

Completed objectives:

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)

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)