Extension talk:Page Forms

autoedit issue when page has subobjects
Product	Version MediaWiki	1.31.1 PHP	7.1.8 (apache2handler) MySQL	5.6.10 Semantic MediaWiki	2.5.8 Page Forms	4.3.1 (624f2a9) 18:20, 16 January 2018 I'm using auto edit to set a property to a new value on a page. When the page has subobjects and I select the button to change the property 1 of the subobjects disappears.


 * I upgraded page forms to 4.5.1 and that seems to have fixed the issue Legaulph (talk) 11:23, 2 July 2019 (UTC)

No default values for embedded multiple-instance templates
(MediaWiki 1.32.2, Page Forms 4.5.1) I made a query form with a main template and a secondary "embed in field" multiple instance template. It works fine but the fields default values are not set for the secondary template. Tested without "embed in field": defaults are ok.

By the way, "Select all" and "Select none" for checkboxes are not shown in multiple instance layout, I don't know if its made on purpose, still it would be nice to have it also in this context.

I switched skin and browser user-agent, don't know what happens but now defaults are correctly set.

Steph.

Select2 don't work.
When I create a form, I create 'field' tag, which have input type: 'text with autocomplete', 'textarea with autocomplete', 'tokens' or 'combobox', and have 'list' parameter for many values. This field are associated with template field which have SMW-property "Page" and have several allow values ( AllowValues:: . When I try to use this form, I type characters but nothing happens. I don't see autocomplete. At the same time, on my monitor screen, I see spinning boot icon (from the file extension\PageForms\skins\loading.gif). When I change input type on 'checkboxes' or 'listbox', I can select required values in the form without problem. But it is uncomfortable. I think, it is problem into Select2-library. What must I do? MediaWiki 	1.32.1 PHP 		7.3.5 (apache2handler) MariaDB 	10.1.40-MariaDB Windows 10 64 bit FireFox         68.0 Language        Russian

Extension: Semantic Drilldown	2.1 Semantic MediaWiki	2.3.1 Page Forms		4.5.1 DataValues		1.0 DataValues Common	0.2.3 DataValues Interfaces	0.1.5 DataValues Validators	0.1.2 ParserHooks		1.4.0 Validator		2.0.4

Settings in LocalSetting.php: $wgPageFormsAutocompleteOnAllChars = true; $smwgEnableUpdateJobs = false;


 * Could you look in the console on your browser, and see if there are any JavaScript errors? Yaron Koren (talk) 22:54, 18 July 2019 (UTC)


 * Browser console:

[ac0a9dbb1002909f24b58b84] /wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector BadMethodCallException from line 848 of C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php: Sessions are disabled for this entry point Backtrace: Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.main" sortDependencies http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:41 resolveStubbornly http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:42 load http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:53 http://localhost/wiki/mediawiki-1.32.1/index.php/Служебная:FormEdit/Создание_нового_документа/13:9 push http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:76 http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:76 http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:76 load.php:35:662
 * 0 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php(310): MediaWiki\Session\SessionManager->getSessionFromInfo(MediaWiki\Session\SessionInfo, WebRequest)
 * 1 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php(244): MediaWiki\Session\SessionManager->getEmptySessionInternal(WebRequest)
 * 2 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php(194): MediaWiki\Session\SessionManager->getEmptySession(WebRequest)
 * 3 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\WebRequest.php(750): MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest)
 * 4 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(1377): WebRequest->getSession
 * 5 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(447): User->loadFromSession
 * 6 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(5487): User->load
 * 7 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(3174): User->loadOptions
 * 8 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\context\RequestContext.php(336): User->getOption(string)
 * 9 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\Message.php(713): RequestContext->getLanguage
 * 1) 10 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\context\RequestContext.php(426): Message->setContext(RequestContext)
 * 2) 11 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\context\ContextSource.php(171): RequestContext->msg(string)
 * 3) 12 C:\xampp\htdocs\wiki\mediawiki-1.32.1\extensions\SemanticMediaWiki\includes\queryprinters\TableResultPrinter.php(35): ContextSource->msg(string)
 * 4) 13 C:\xampp\htdocs\wiki\mediawiki-1.32.1\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\ResourceLoaderGetConfigVars.php(62): SMW\TableResultPrinter->getName
 * 5) 14 C:\xampp\htdocs\wiki\mediawiki-1.32.1\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\HookRegistry.php(341): SMW\MediaWiki\Hooks\ResourceLoaderGetConfigVars->process
 * 6) 15 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\Hooks.php(174): SMW\MediaWiki\Hooks\HookRegistry->SMW\MediaWiki\Hooks\{closure}(array)
 * 7) 16 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\Hooks.php(202): Hooks::callHook(string, array, array, NULL)
 * 8) 17 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderStartUpModule.php(129): Hooks::run(string, array)
 * 9) 18 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderStartUpModule.php(432): ResourceLoaderStartUpModule->getConfigSettings(ResourceLoaderContext)
 * 10) 19 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderModule.php(708): ResourceLoaderStartUpModule->getScript(ResourceLoaderContext)
 * 11) 20 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderModule.php(675): ResourceLoaderModule->buildContent(ResourceLoaderContext)
 * 12) 21 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderModule.php(812): ResourceLoaderModule->getModuleContent(ResourceLoaderContext)
 * 13) 22 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoader.php(660): ResourceLoaderModule->getVersionHash(ResourceLoaderContext)
 * 14) 23 [internal function]: ResourceLoader->{closure}(string)
 * 15) 24 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoader.php(672): array_map(Closure, array)
 * 16) 25 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoader.php(753): ResourceLoader->getCombinedVersion(ResourceLoaderContext, array)
 * 17) 26 C:\xampp\htdocs\wiki\mediawiki-1.32.1\load.php(51): ResourceLoader->respond(ResourceLoaderContext)
 * 18) 27 {main} load.php:33:47


 * And other analogical errors:

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.submit" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.fancytree" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.imagepreview" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.autogrow" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.checkboxes" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.select2" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.rating" load.php:35:662

Exception in resolve: load.php:35:625 Error: "Unknown dependency: ext.pageforms.fancybox.jquery3" load.php:35:662


 * I have solved this problem by change the skin in my Wiki from 'Vektor' to 'Monobook'. But it isn't good, because 'Vektor' more beautiful then 'Monobook'. I hope this bug will be eliminate in future. Thank you for support. Thiazole


 * Interesting. Is "Vektor" the same as "Vector"? (I assume so.) And do these JS errors show up in every one of your forms, if you have more than one? Yaron Koren (talk) 13:24, 19 July 2019 (UTC)


 * Yes, "Vektor" = "Vector", it is a misprint. I'm sorry. I have several forms, and all of this forms have errors. Thiazole


 * It sounds like there are one or more JavaScript bugs there, which may be unrelated to Select2. Possibly they're coming from Semantic MediaWiki, judging by that console printout. Could you try temporarily disabling SMW and seeing if the JS errors are still there in the forms? Yaron Koren (talk) 01:57, 25 July 2019 (UTC)

Input type "checkboxes": Missing CSS class in span tag?
I am going to use Page Forms in this wiki here in order to create file descriptions for uploaded files by using a page form. I fiddled around with radio buttons and I am now finally able to format and position them with the help of a CSS grid. Therefore I created a CSS class for a special group of radio buttons in Common.css. This works fine. Then I tried the same on checkboxes. Of course with a different CSS class for a special group of checkboxes. That failed at first. I took a look at the HTML source code of such a page form. Every group of radio buttons and every group of chackboxes with their label and input tags is wrapped in a span tag. The span tag of the radio button group includes the CSS class, witch I added to the field tag in the form. The span tag of the group of checkboxes shows no sign of the CSS class as provided by the field tag in the form. Only the label tags of every item in that span tag are carrying this class.

This here is line 107 to 113 from the original PF_RadioButtonInput.php file:

This is line 94 to 97 from the original PF_CheckboxesInput.php

I changed that part in "my" PF_CheckboxesInput.php to: Now the span tag of the group of checkboxes includes the CSS class, witch I added to the field tag in the form. And the CSS grid gets effectiv.

Is this a bug? --Wgkderdicke (talk) 14:13, 20 July 2019 (UTC)

Questions about the input types "radiobutton" and "checkboxes"
While fiddeling around with the above-named input types, I discovered this:

For every value from the values parameter one input element is created. If there is no mapping, the order of the input elements is determined by the order of the values as specified at the values parameter. If the label of the input elements is changed by a mapping template, the order changes. Now the input elements are sorted in ascending alphabetic order on the basis of the values given by the mapping template. And if the mapping template creates dynamic labels, the input elements are going to appear here and there. I think, it is better, if the order is fix and determined by the order of the values as specified at the values parameter. Or there is an extra parameter which provides sorting options.

The default parameter has to be set with one specific value out of the comma separated list from the values parameter. The show on select parameter needs the values given by the mapping template. To retrieve the values from different sources seems odd to me.

It seems that the semicolon separated values of the show on select parameter, the allocation from IDs to values, can not be generated by a template (or maybe all my attempts went wrong because of faulty syntax). Lets presume that the input field holds 90 radio buttons. And every single radio button wants to get an ID to show further information on select of this button. And the pretty long show on select part in the field tag clutters everything in the wiki code of this form... --Wgkderdicke (talk) 21:13, 24 July 2019 (UTC)


 * For the first issue, I didn't understand this part: "if the mapping template creates dynamic labels, the input elements are going to appear here and there". What are dynamic labels? For the second one, I'm guessing that the "show on select" value isn't parsed - not all values are parsed. That seems like a problem in this case, though it doesn't sound like a major one. Yaron Koren (talk) 02:43, 25 July 2019 (UTC)


 * Wrong word. Here in Germany one says: . This means:  . I "translated" this to  . Seems to be a false friend thing. Actually, I mean: if the mapping template creates variable labels, the input elements are going to appear here and there.--Wgkderdicke (talk) 08:01, 25 July 2019 (UTC)


 * I still don't understand what this means. Does the mapping template sometimes create "variable labels" and sometimes not? Yaron Koren (talk) 20:12, 25 July 2019 (UTC)

OK, let's presume one wants to categorize crimes. To choose one of them the form provides this field tag: You get three radiobuttons in this order:. Furthermore, let's presume that the page created by this form needs exactly the A,B,C values at the Crime parameter. So it is unfeasible to change the  parameter.

Now the mapping template named  comes into play with this code: The field tag gets the  option and now the order of the radiobuttons changes to: . Now another mapping template called  is used. This template calls yet another template named, which retrieves the percentage of a specific crime from the last month. The code of the new mapping template: The field tag contains ths:. At the moment the radiobuttons will show us this, for example, and again in a different order: . The percentages of the crimes have changed to 22% for Murder, 33% for Assault and battery and 45% for Robbery. Time passes, it is the next month now, the last month is the former current month, the form now shows this and yet again in a different order: . Depending on a variable value a specific radiobuttion will appear sometimes as first radio button, some other time as second radiobutton and another time as third radiobutton. The button apears here and there.

But perhaps one wants to keep a static order or respectively stick to that order, which is given by the comma separated list at the  parameter. And wants to use the mapping feature. --Wgkderdicke (talk) 21:44, 25 July 2019 (UTC)


 * Aha! Now I understand; thanks for that full explanation. This does seem like a bug - if "values=" is specified, the values should be kept in that order, even if they are mapped. Yaron Koren (talk) 18:27, 26 July 2019 (UTC)


 * Living example, check this: Form, Page, Mappig template. --Wgkderdicke (talk) 21:10, 26 July 2019 (UTC)


 * Same with checkboxes. I just added them to the above-posted example. --Wgkderdicke (talk) 11:58, 27 July 2019 (UTC)


 * Since "my" wiki runs with German language, you may view the source code of the page and the mapping template by klicking the tab named "Quelltext anzeigen" and on the page you may view the form by klicking the tab named "Formular anzeigen". --Wgkderdicke (talk) 10:01, 29 July 2019 (UTC)

And this here is an example of a so called cluttered field tag. There are 161 Buttons generated by the field tag. They are positioned in a specific order using a CSS grid. And every button triggers a select on case ID. This works! Actually it works fine. And I am going to use this. But look for yourself, if you will edit the form, what you get in the wiki editor because of the not parsed show on select value. For this following example I only added some line feed here, so that it looks a little bit like the wiki text one gets to see in the edit window. The syntaxhighlight tag here would give me only two lines and one has to scroll at least five miles to the right to watch the end of the line. I would gladly appreciate a parsed show on select value. --Wgkderdicke (talk) 19:54, 4 August 2019 (UTC)


 * I think that I found the line where the order of the radiobuttons is changed. It's the disambiguateLabels function in the PF_ValuesUtils.php file. The first line changes the order. To test it, I commented this line out. And the radiobuttons are displayed in the order like specified by the values parameter but shows the label text and not the value. --Wgkderdicke (talk) 23:42, 13 August 2019 (UTC)

PF namespaces 106 & 107
To begin with, in principle the PF extension seems to run without any problems here in this wiki. In the LocalSettings.php file of this wiki near the top there are four custom namespaces defined (100-103). In the middle of that file the installation of PF happens. After that, near the end of that file, the access to several namespaces is restricted via $wgNamespaceProtection and the Lockdown extension. Now I additionally want to restrict the access to the form namespace PF_NS_FORM. Therefore I added this line beneath the other restriction:

I immediately got this warning:.

Then I added near the top and beneath the other definitions for "my" custom namespaces but before the PF installation line this here:

Now the warning has disappeared. And the restriction seams to get effectiv.

Is this a bug? --Wgkderdicke (talk) 20:42, 25 July 2019 (UTC)


 * How are you loading Page Forms - with PageForms.php, or with wfLoadExtension? Yaron Koren (talk) 18:28, 26 July 2019 (UTC)


 * It's the wfLoadExtension method. --Wgkderdicke (talk) 21:06, 26 July 2019 (UTC)

Section tag & VEForAll prevents placeholder from showing
Using a 'section' tag with VEForAll prevents the display of any placeholder text (although it flashes when the form is loaded, then disappears). If you switch to the wikitext editor, the placeholder text returns. --Bryandamon (talk) 08:09, 7 August 2019 (UTC)

Parsing multiple-instance templates
What is the best way to parse data stored in multiple-instance templates? I'm not sure I'm doing everything correctly to start with, but I have a Main Form that contains something like this:

Which calls (I think) this template called WorkerHours:

A page created by the form gives me the following after creating multiple instances of the WorkerHours template in the Time Form

I would like to list all the Worker/Hour values in a side infobox and format it. If possible, I'd like to total the hours from all the workers. The results are reliably placed on the page instances, however the values don't seem to exist in any Cargo tables I have (Time or WorkerHours) and I'm not sure how I can use them. --Bryandamon (talk) 10:21, 8 August 2019 (UTC)


 * If the template is "WorkerHours", why is the template being called in the page named "Hours"? Yaron Koren (talk) 16:19, 8 August 2019 (UTC)
 * Sorry, I changed the name of the templates to paste here, but didn't do a good job being consistent. I updated the code above to better capture a simplified version of what I'm doing (the Cargo changed from "Hours" to "WorkerHours" and similar with the instances in the created page).  I do have a new field (WorkerHours) in any instance created from my Time Form/Template (it's created in the order the Form calls).  The values are correct for the information saved, but I'm not sure how I can "use" them; i.e. place them where I chose in the template, format and arrange the values,  or sum the hours. --Bryandamon (talk) 20:58, 8 August 2019 (UTC)
 * I think I figured out the storage part. What worked was removing my version of an embedded multiple-instance template for a regular one.  Now to see if I can understand how to use/display this new data structure.  Thanks Yaron! --Bryandamon (talk) 22:54, 8 August 2019 (UTC)
 * Alright. You should be able to get this working with an embedded multiple-instance template as well - my guess is that what was missing was a call to the " " field from within the "Time" template, although maybe it was something else. Yaron Koren (talk) 23:16, 8 August 2019 (UTC)

Save and Continue doesn' work in forms with mandatory fields
Hi Yaron,

is there a way to solve this issue? Using MW 1.31 and PageForms 4.5

Thanks, Klaus


 * I don't think I knew about this problem before. Does it fail even when the mandatory field(s) are filled in? Yaron Koren (talk) 23:17, 8 August 2019 (UTC)
 * No, only when one or more are not filled. --DDSnowl (talk) 10:53, 13 August 2019 (UTC)

Radiobuttons: "Show on select" and default values
Hi Yaron

I created this field here:

There is a div tag with the id licence and is triggered by a show on select parameter ahead of this code. If a specific value is choosen ahead, this div tag is shown.

The field tag here gives me 10 radiobuttons. The default value is set to CC. Each values is provided with two or three IDs. Some div tags and the content inbetween are provided by the Form-File-Licence-Info template. The div tag with the id ccart is not wrapped in a template.

If the licence div tag pops up with its default value for the first time, the ccart div tag is not shown. If another radio button is choosen and then the CC radiobutton is choosen again, finally the ccart div tag pops up.

Is that a bug? By the way, did you noticed the span tag issue? --Wgkderdicke (talk) 20:26, 10 August 2019 (UTC)


 * In addition to the above, you can take a look at the full wikitext of the form here: Formular:DateiFlex.
 * And this is the odd part. The CC value is provided with three IDs: . If the licence div tag pops up with its default value for the first time, the ccart div tag is not shown, as said before. But the cclicence1 tag and the nextlicence2 is shown. A change of order for this three IDs at the show on select parameter doesn't pay.--Wgkderdicke (talk) 09:55, 11 August 2019 (UTC)


 * It comes better. I renamed the ccart tag to wgkart. And, of course, the corresponding part in the show on select value. This does the trick. The now called wgkart div tag is also shown, if the licence div tag pops up with its default value for the first time. Does one have to be careful that the first two letters of an ID are not identical? --Wgkderdicke (talk) 18:25, 11 August 2019 (UTC)

Radiobutton: First default value 'none'
Hi, Yaron.

The description regarding the radiobutton input type says:

By default, the first radiobutton value is "None", which lets the user choose a blank value. To prevent "None" from showing up, you must make the field "mandatory", as well as making one of the allowed values the field's "default=" value.

Let's presume this: If I create a page using this form and the radiobutton 1 stays on its default value A, I will get a page with the following template call: The parameter for the first field Radiobutton1 is available. The parameter for the second field Radiobutton2 does not show up.

If I edit this page using the form and change the value of radiobutton 1 to, for example, B, the second radiobutton input appears. And, so I presume, because of the missing Radiobutton2 parameter, and besides the defined three values, the second radiobutton input is provided also with an extra default value "none" notwithstanding the "mandatory" setting, which should suppress the default value "none".

Imho every mandatory field with a default value should get its parameter in the saved page's template call, no matter if this mandatory field is visible or not. Or every mandatory field which lacks a parameter in a saved page's template call should not be extended by a possibly unwanted extra "none" value (which leads to an extra radiobutton or checkbox, for example) but stick to the defined values and set to the default value. --Wgkderdicke (talk) 21:45, 11 August 2019 (UTC)


 * I did some research in the PF_RadioButtonInput.php file. This here is line 41 to 37 from this file:


 * I changed that part in "my" PF_RadioButtonInput.php file to:
 * Now no extra "None" value is added, if the field is mandatory and a default value is available.
 * But another "feature" crops up. In case of a missing parameter in the saved page's template call the  variable comes with an empty string. If the labels of the field's radiobuttons are not changed by a mapping template, the default value of this field gets effective. But if the labels of the field's radiobuttons are changed by a mapping template, the first value of the   array gets effective, not the declared default value. Furthermore, it seems that, if the labels of the field's radiobuttons are changed by a mapping template, the   array holds the mapped labels and not the declared values of the field. After that above-mentioned change I added this to "my" PF_RadioButtonInput.php file:
 * This doesn't pay, the field wasn't set to the default value.
 * One of the fields values is "-". This is the defaukt value, But this doesn't pay either, the field wasn't set to the default value.
 * The field value "-" is mapped to "Keine Angabe" (german for "not specified"), so that the label shows "Keine Angabe" but the "-" is used in the saved page's template call. Well, this pays! Now the field shows the default value!
 * --Wgkderdicke (talk) 20:54, 12 August 2019 (UTC)
 * The field value "-" is mapped to "Keine Angabe" (german for "not specified"), so that the label shows "Keine Angabe" but the "-" is used in the saved page's template call. Well, this pays! Now the field shows the default value!
 * --Wgkderdicke (talk) 20:54, 12 August 2019 (UTC)
 * --Wgkderdicke (talk) 20:54, 12 August 2019 (UTC)
 * --Wgkderdicke (talk) 20:54, 12 August 2019 (UTC)

Multiple }} in default value
In relation to the default value - "You can also include templates, parser functions, and magic words within the "default=" value." - I just noticed that if you have multiple }}'s, you need to put spaces between each, otherwise PF thinks the first }}} closes the initial {{{. Jonathan3 (talk) 00:31, 12 August 2019 (UTC)

Using Templates in Form Default values
Hi,

The various help pages seem to indicate that this should be possible but I must be missing something. I have a form field that allows user to select people based on there real name (or Foaf:name), which is a semantic property on their "user page":

This work fine, but I would like to set the default value for this field to the real name of the current user. I can get this value in a few different ways such as:

I have tried to place this inline query directly in the code and also tried to put it in a separate template but neither works:

Where correct outputs the text value of "Foaf:name". Both options correctly creates the dropdown field but have the following warming message as the default value:

 The page type input value "User:" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Should this actually work and if so can anyone say what I have missed? If this should not work can anyone suggest an alternative way to get this type of default value in a field?

Thanks

--Jpadfield (talk) 10:31, 12 August 2019 (UTC)

MediaWiki	1.33.0 Semantic MediaWiki	3.0.2 Page Forms	4.5.1


 * I wonder if subst: would help - it’s mentioned here: https://stackoverflow.com/questions/12926969/variable-in-mediawiki-for-the-current-user Jonathan3 (talk) 13:41, 12 August 2019 (UTC)


 * Or maybe REVISIONUSER has no value or a problematic value when displaying a form for a new page (and default= only works on new pages, I think). Just more guesswork as I’ve not used it. Have you tried displaying it within the form? Jonathan3 (talk) 13:51, 12 August 2019 (UTC)


 * The name is displayed correctly when the inline query or the template is used outside of the form. It was trying to display it in the form that gave me the big "span" error - all as un-parsed text in the combobox on the form. It seemed that the REVISIONUSER value, or template, etc . was being parsed or interpreted differently wen included in the form. I will have look at your other suggestion, thanks --Jpadfield (talk) 15:43, 12 August 2019 (UTC)


 * Ah it seems that the value for REVISIONUSER is not processed correctly, and in fact it is not really the one I needed. I have solved the problem by using Extension%3aMyVariables and the new variable and everything seems fine. Thanks --Jpadfield (talk) 16:13, 12 August 2019 (UTC)

Simple upload not working on MW 1.33.0 and PageForms 4.5.1
I'm noticing that simpleupload option is not working on the current builds of PageForms and MediaWiki. I looked through the archives and noticed this had been brought up before but it seemed that no one had reported using the master branch with the latest version of MediaWiki. So just wanted to report that it still doesn't seem to work. Thanks, really appreciate this extension and all the work you've put into it! Mwyman (talk) 15:09, 12 August 2019 (UTC)

Reuse template in page forms without the multiple instance buttons?
Versions: Mediawiki: 1.33.0, SMW: 3.0.2, Page forms: 4.5.1, Header tabs 1.2. Is it possible to call a template with page-forms multiple times without using the multiple parameter? If I add a form by the «Create Form» special page, and I add a template twice, then fill out the data and submit, only the first template adds the annotations, and the values saved are the last ones. The second template is written with no output.

For instance a dummy form with two sections using the same template: English section: (label=test,altLabel=trial,iso_lang=en) German section: (label=prüfung, iso_lang=de, altLabel=)

Results in

Best regards, Øyvind


 * I don't think so. Yaron Koren (talk) 13:32, 13 August 2019 (UTC)

Checkboxes vs. mapping templates and 'edit with form' mode
Hi.

It's about the checkboxes field. I discovered, that, if more than one value is chosen, the values are saved after the equal sign in the page's template call not only separated by the delimiter character. After every delimiter character there follows a white space character. Happens this by purpose? A tokens field generates no white space after the delimiter, if his value is composed of several individual values. Only the delimiter separates the individual values without any white space characters.

In addition to that, if the checkboxes' lables get their text by a mapping table and if an existing page is edited with the form, the checkboxes in the form are not set to the value which is saved in the page's template call.--Wgkderdicke (talk) 23:14, 14 August 2019 (UTC)


 * Yes, the spaces are there on purpose. If "tokens" does not add spaces after the commas, that sounds like a bug. And that second one definitely sounds like a bug. Yaron Koren (talk) 15:38, 15 August 2019 (UTC)

autocomplete list by cargo table contains decoded html entities in autocomplete
The reason is this line in includes/CargoSQLQuery.php

While it's necessary to filter user input, I'm not sure that's the best place to do this filtering. This preventing the use of the source data needed in some cases.


 * Do you have HTML in your autocomplete values? If so, that's not good - Cargo (and Page Forms) are doing the right thing by escaping it, because otherwise it's a security risk. Yaron Koren (talk) 15:40, 15 August 2019 (UTC)

Database error when using Edit with Form
I think I bungled a MW/SMW upgrade somewhere and now I'm getting 500 Internal errors when I click Edit with Form. SMW queries etc are behaving normally. This happens with a clean MW and extensions install and a default LocalSettings.php. I suspect I have a mismatch between the Postgres database schema and the SMW/PF version. So this may be an SMW rather than PF question.

MediaWiki 1.33.0, SemanticMediaWiki 3.0.2, Page Forms 4.5.1

Nginx 1.12.2, PHP 7.2.19, Postgresql 9.5.15

This happened a couple of upgrades ago and I've been living in denial and hoping Something Magic would happen when I upgraded and ran the maintenance scripts. So I can't describe exactly which actions have been taken.

Is there any way I can tell from the database schema or contents, which version of SMW/PF it conforms to? That is, could I install a previous version and run the upgrade scripts from there to bring my database up to date?

Thanks, Andrew

[70eda6171c99d8e2ac8b55fc] [no req] Wikimedia\Rdbms\DBTransactionStateError from line 1423 of /var/www/foo.com/mediawiki-1.33.0/includes/libs/rdbms/database/Database.php: Cannot execute query from LCStoreDB::get while transaction status is ERROR.

Backtrace:


 * 1) 0 /var/www/foo.com/mediawiki-1.33.0/includes/libs/rdbms/database/Database.php(1192): Wikimedia\Rdbms\Database->assertTransactionStatus(string, string)
 * 2) 1 /var/www/foo.com/mediawiki-1.33.0/includes/libs/rdbms/database/Database.php(1784): Wikimedia\Rdbms\Database->query(string, string)
 * 3) 2 /var/www/foo.com/mediawiki-1.33.0/includes/libs/rdbms/database/Database.php(1609): Wikimedia\Rdbms\Database->select(string, string, array, string, array, array)
 * 4) 3 /var/www/foo.com/mediawiki-1.33.0/includes/cache/localisation/LCStoreDB.php(61): Wikimedia\Rdbms\Database->selectField(string, string, array, string)
 * 5) 4 /var/www/foo.com/mediawiki-1.33.0/includes/cache/localisation/LocalisationCache.php(391): LCStoreDB->get(string, string)
 * 6) 5 /var/www/foo.com/mediawiki-1.33.0/includes/cache/localisation/LocalisationCache.php(294): LocalisationCache->loadSubitem(string, string, string)
 * 7) 6 /var/www/foo.com/mediawiki-1.33.0/languages/Language.php(2645): LocalisationCache->getSubitem(string, string, string)
 * 8) 7 /var/www/foo.com/mediawiki-1.33.0/includes/cache/MessageCache.php(990): Language->getMessage(string)
 * 9) 8 /var/www/foo.com/mediawiki-1.33.0/includes/cache/MessageCache.php(948): MessageCache->getMessageForLang(Language, string, boolean, array)
 * 10) 9 /var/www/foo.com/mediawiki-1.33.0/includes/cache/MessageCache.php(890): MessageCache->getMessageFromFallbackChain(Language, string, boolean)
 * 11) 10 /var/www/foo.com/mediawiki-1.33.0/includes/Message.php(1308): MessageCache->get(string, boolean, Language)
 * 12) 11 /var/www/foo.com/mediawiki-1.33.0/includes/Message.php(863): Message->fetchMessage
 * 13) 12 /var/www/foo.com/mediawiki-1.33.0/includes/Message.php(955): Message->toString(string)
 * 14) 13 /var/www/foo.com/mediawiki-1.33.0/extensions/PageForms/specials/PF_FormEdit.php(144): Message->text
 * 15) 14 /var/www/foo.com/mediawiki-1.33.0/extensions/PageForms/includes/PF_FormEditAction.php(299): PFFormEdit->printForm(string, string)
 * 16) 15 /var/www/foo.com/mediawiki-1.33.0/extensions/PageForms/includes/PF_FormEditAction.php(32): PFFormEditAction::displayForm(PFFormEditAction, Article)
 * 17) 16 /var/www/foo.com/mediawiki-1.33.0/includes/MediaWiki.php(499): PFFormEditAction->show
 * 18) 17 /var/www/foo.com/mediawiki-1.33.0/includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title)
 * 19) 18 /var/www/foo.com/mediawiki-1.33.0/includes/MediaWiki.php(865): MediaWiki->performRequest
 * 20) 19 /var/www/foo.com/mediawiki-1.33.0/includes/MediaWiki.php(515): MediaWiki->main
 * 21) 20 /var/www/foo.com/mediawiki-1.33.0/index.php(42): MediaWiki->run
 * 22) 21 {main}


 * Very strange... it looks like the problem comes when the code tries to get the value of the message 'pf_formedit_edittitle' from the "l10n_cache" table. Does that table look alright in your database? I would try truncating it - calling something like "DELETE * FROM l10n_cache". It shouldn't break anything - that table exists just to improve performance. But don't mess with any of the other tables. :) Yaron Koren (talk) 19:59, 15 August 2019 (UTC)


 * That table held exactly 15,228 entries. Deleting them resulted in an empty table, but after the next page load there were the exact same number of entries in the table.  And 'Edit with Form' gives the same error message as before.  --Acrabb (talk) 20:52, 15 August 2019 (UTC)


 * I don't know then - I've never heard of this kind of problem happening. I would try disabling every extension other than Page Forms, to see if the problem persists - if not, then it's a matter of isolating the extension causing the problems. Yaron Koren (talk) 21:01, 15 August 2019 (UTC)


 * OK, thanks! I had already tried reinstalling MW with just SMW and PageForms enabled.  Anything else I might try, even if it takes some work?  I have a fair investment in this database, 100-odd properties and a few thousand property values over the last five years or so.  I do recall it started when I did an upgrade, perhaps I skipped a version or didn't run the maintenance script.  Acrabb (talk) 21:19, 15 August 2019 (UTC)