Extension talk:Page Forms/Archive April to July 2017

Form input autofocus attribute

Is there a way to disable the 'autofocus' attribute from the text form inputs without manually hacking it out of the source code? I have issues on long forms where the autofocus shifts the page to the bottom of the form as soon as it is loaded because of that attribute (on pages using the #forminput parser functions). Removing it after the fact with jQuery doesn't work because by the time the jQuery call kicks in, the page has already been shifted down from the autofocus. --Lalquier (talk) 14:35, 4 April 2017 (UTC)

Nevermind - Answering my own question. I reviewed the list of parameters for #forminput and found I missed the 'noautofocus' parameter. --Lalquier (talk) 14:42, 4 April 2017 (UTC)

Pipes are not working with wikitable format

I get the following error when using a simple wikitable in a textarea box. Actual error message is "|" is not allowed, except within {{...}} or [[...]]

I see this was reported previously here: https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_January_to_March_2016#Pipes_are_not_allowed

But it seems to be not working for us now. Version used: PageForms 4.0.2 (f0816ba) 22:12, 6 January 2017

MediaWiki 1.28.0 PHP 5.5.9-1ubuntu4.20 (apache2handler) MySQL 5.5.53-0ubuntu0.14.04.1

--Nischayn22 (talk) 07:29, 7 April 2017 (UTC)

A naked pipe will be interpreted as the end of the parameter you are trying to set with your field. Did you try transcluding the pipes with {{!}} ? - Lbillett (talk) 09:30, 7 April 2017 (UTC)

I am trying to use the WikiEditor to insert a table. The basic format of the table has pipes. I don't think I can transclude them, maybe tables just don't work with page forms?--Nischayn22 (talk) 13:27, 5 June 2017 (UTC)

Nested Forms with Multiple Instances

I'd like to have a form that allows multiple instances and has an optional sub-form that can go with each instance. For example, you may have a main form (form "Item"), which can have an "Item Detail" sub-form. And you can have multiple "Item" instances, each with its own sub-form. Is this possible? I think this is what the partial forms are for, but I cannot figure out how to use it. Thanks in advance. Gstupp (talk) 20:12, 9 April 2017 (UTC)

Are you asking about having a form that only edits one instance of a multiple-instance template? If so, unfortunately that's not possible. Yaron Koren (talk) 22:41, 9 April 2017 (UTC)

Autocomplete not working

Can you think why autocomplete isn't working with the following?

{{#forminput:form=Contact|size=30|autocomplete on namespace=Contact|query string=namespace=Contact}}

I am sure it used to work, but I can't think what's changed. Thanks. Jonathan3 (talk) 14:15, 28 April 2017 (UTC)

Someone else said this was a problem too, but I can't reproduce it. Do you see any JavaScript error message in the browser console? Yaron Koren (talk) 17:35, 28 April 2017 (UTC)

Yes. This is from Firefox:

TypeError: this.source is not a function[Learn More]  load.php:6:984
	._search http://www.mydomain.com/load.php:6:984
	$.widget/</prototype[prop]</< http://www.mydomain.com/load.php:78:450
	.search http://www.mydomain.com/load.php:6:853
	$.widget/</prototype[prop]</< http://www.mydomain.com/load.php:78:450
	._searchTimeout/this.searching< http://www.mydomain.com/load.php:6:590
	handlerProxy http://www.mydomain.com/load.php:84:579

Jonathan3 (talk) 20:48, 28 April 2017 (UTC)

Could you add "?debug=true" (or "&debug=true") to the URL, to see if a more helpful error message can be seen? Yaron Koren (talk) 14:37, 30 April 2017 (UTC)

That didn't make any difference. It may be because I'm still using PF 4.1 (7f1cec5). I can't easily upgrade, as I haven't written that map/coordinates code for you yet, so have to add it each time... I'll get back to you when I do get the latest version. Jonathan3 (talk) 22:27, 1 May 2017 (UTC)

Ah - I'm pretty sure that upgrading will fix the problem, but until then, implementing these two changes directly in your code should hopefully fix the problem as well. Yaron Koren (talk) 01:58, 2 May 2017 (UTC)

I have reproduced the problem here, can you see it ? Nicolas NALLET Wiki-Valley.com, Semantiki.fr (talk) 09:40, 2 May 2017 (UTC)

This might be a different issue - in the JS console for that page, there's a Chameleon skin error that might be blocking the rest of the JS. Yaron Koren (talk) 13:36, 2 May 2017 (UTC)

Ok it's working now with Page forms version 4.1 (bb3327e) avril 27 2017 both here and vector skin based wikis. Thanks Yaron Nicolas NALLET Wiki-Valley.com, Semantiki.fr (talk) 07:04, 7 May 2017 (UTC)

The two changes mentioned above did the trick, thanks. Jonathan3 (talk) 01:27, 8 May 2017 (UTC)

Different list behaviour between dropdown and combobox

I have a property that has a set of allowed values defined using [[Allows value::xyz]]. If I put a field on a form related to this property, and I set the input type to dropdown, the dropdown list displays all the allowed values. In older Semantic Forms versions, the combobox input type also displayed the same list. Now, though, the combobox input type only lists the values that are actually assigned to the property on other pages. Is there any way to get the combo box to list all the allowed values? L Andy (talk) 15:57, 2 May 2017 (UTC)

Empty hidden field

Hello,

I'm trying to use an empty hidden field like this:

{{{field|foo|default= |hidden}}}

I want the form to automatically add foo= to the template on the new page. But it does not seem to work, this parameter is not added to the new page.

Is there any way to do that?

--Rudloff (talk) 17:17, 5 May 2017 (UTC)

I don't know of any. Yaron Koren (talk) 01:44, 8 May 2017 (UTC)

I don't know why you would want to have an empty parameter, but off the cuff, have you tried wrapping nowiki tags around an empty value or space? Cavila 17:04, 8 May 2017 (UTC)

Issue with two datetimepickers in the same form

Hi, I have an issue when two datetimepickers are used in the same form. The datepicker-part is missing, but the time-part is shown. The problem disappears when I reduce to only one datetimepicker in the form.

Tested with both PF 4.1 and PF 4.1.1, MW 1.28.1 and SMW 2.5.1.

--BMfly (talk) 06:42, 11 May 2017 (UTC)

I can't reproduce this problem. What browser(s) are you using? And if you can get to see the JavaScript console, do you see any errors there? Yaron Koren (talk) 17:46, 11 May 2017 (UTC)

Tested with Chromium 58, Firefox 53 and Chrome 52, problem exists in all three browsers. Output from JS console:

This page is using the deprecated ResourceLoader module "jquery.effects.core".
This page is using the deprecated ResourceLoader module "jquery.ui.position".
This page is using the deprecated ResourceLoader module "jquery.ui.widget".
This page is using the deprecated ResourceLoader module "jquery.ui.core".
Please use "mediawiki.ui.button" or "oojs-ui" instead.

--BMfly (talk) 06:06, 12 May 2017 (UTC)

Those are all warnings that should be fixed (most of them come from Page Forms, I think), but I don't think any of them are preventing the JavaScript from running. This isn't on a public wiki by any chance, is it? Yaron Koren (talk) 14:13, 12 May 2017 (UTC)

I made a test on the sandbox SMW, which generates the same result: [1]. The form consists of two datetimepicker fields, but only the time picker part is visible. BMfly (talk) 18:07, 12 May 2017 (UTC)

I can confirm that this still is an issue. The problem is, that PageForms loads the modules with OutputPage::addModuleScripts which does not resolve the declared dependency of ext.pageforms.datetimepicker to ext.pageforms.datepicker. A solution would be to useOutputPage::addModules, but that would also mean that CSS that is needed on pageload needs to be placed in dedicated modules. --Osnard (talk) 11:06, 2 August 2017 (UTC)

What if you replace the calls to the $output->addModuleStyles() and $output->addModuleScripts() with $output->addModules() - does it work better? And what CSS are you talking about? Yaron Koren (talk) 16:03, 2 August 2017 (UTC)

Yes, replacing with addModuleScripts with addModules will work. You can also leave the addModuleStyles call even if that means that the CSS will be loaded twice (directly on page load and via javascript before the actual module code is being executed) --Osnard (talk) 12:35, 17 August 2017 (UTC)

I have the same issue, two datetime pickers and I can only see the clock icon (I just checked and I have same problem with single datetimepicker instance...). Also, if I have default dates set in proper format, upon Preview or Save, if time is set, dates become undefined. MW 1.29, SW 2.5.4, PF 4.1. Blaz Malnersic (talk) 17:53, 10 August 2017 (UTC)

editor=wikieditor does no longer work on 4.1.1 for "free text"

I just realized that after upgrading from Page Forms 4.1 to 4.1.1 the WikiEditor no longer shows up for the "free text", e.g. {{{standard input|free text|rows=25|autogrow|editor=wikieditor}}}. It continues to work for {{{field|description|input type=textarea|editor=wikieditor|rows=3|autogrow}}} but still I had to pull the new version. Cheers --[[kgh]] (talk) 19:47, 14 May 2017 (UTC)

There is a live example and the respective form definition is in this spot Cheers --[[kgh]] (talk) 07:29, 23 May 2017 (UTC)

Thanks for following up on this. I just checked in what I think is a fix. Yaron Koren (talk) 16:26, 23 May 2017 (UTC)

Is there a limit on number of values in a dropdown when populated from cargo fields?

I am trying to populate a dropdown (or combobox) using tokenized data stored as a single "List (,) of String" in a Cargo table.

The dropdown works - in that it populates, and I can select individual list items - but it looks like it's stopping at around 100 entries. Is this a limitation of values dependent on using Cargo, or is this a limitation with using a tokenized single list?

Here is the field declaration in the muti-instance template:

{{{field|ThirdParty|input type=combobox|cargo table=SOE_Versions_Store|cargo field=ThirdPartyCollect|}}}

The data is stored as {{#cargo_declare:_table=SOE_Versions_Store|ThirdPartyCollect=List (,) of String}} in a separate template.

Before I look to structuring the data differently (ie, store ThirdPartyCollect as separate rows instead of a delimited single entry), I'd like to know if this would solve the issue. FYI, the real goal is actually to combine several Cargo fields into a single, alphabetized dropdown in the spreadsheet-style view. I've almost got this in place, but it's konking out at 100 entries in the dropdown.

--Bgrenon (talk) 02:17, 16 May 2017 (UTC)

Is this happening in the spreadsheet display, or in a standard display? Or both? Yaron Koren (talk) 15:17, 16 May 2017 (UTC)

It looks like both. --Bgrenon (talk) 15:48, 16 May 2017 (UTC)

The fact that it's happening in the spreadsheet is not that surprising, but with the standard display it's quite surprising. What versions are you using of Page Forms and Cargo? Yaron Koren (talk) 17:49, 16 May 2017 (UTC)

Cargo 1.1.1 and Semantic Forms 3.7 --Bgrenon (talk) 18:19, 16 May 2017 (UTC)

Oh... those are both old, as I'm guessing you know. Maybe upgrading to the latest versions would fix the problem? Yaron Koren (talk) 18:31, 16 May 2017 (UTC)

Same settings, different resulting fields

I am not sure if it is a PF issue, but here we are: I have these two form fields:

{{{field|Has parent page|input type=tokens|values from concept=Institution|mapping property=Display title of}}}
{{{field|Has hierarchical superior|input type=tokens|values from concept=Instituton|mapping property=Display title of}}}

the only difference between the two is the name field. But when the form loads, it looks like different. See. We can see from the URL that both of the fields are sending the same information: Institution[Has hierarchical superior]=Configuração:Institution 003 & Institution[Has parent page]=Configuração:Institution 003

It seems like a bug. I am using PF 4.0.2 (fbecc9f). Jaider ^msg 20:28, 18 January 2017 (UTC)

That does look like a bug, yes. Yaron Koren (talk) 20:41, 18 January 2017 (UTC)

Cindy.cicalese maybe you have an interest in this bug. Jaider ^msg 13:53, 26 May 2017 (UTC)

That is indeed strange. Try removing the "|mapping property=Display title of", which is no longer necessary. You may need to update to a more recent version of Page Forms. Cindy.cicalese (talk) 14:16, 26 May 2017 (UTC)

Cindy.cicalese, done + errors:

• Warning: asort() expects parameter 1 to be array, object given in /mw-REL1_28/extensions/PageForms/includes/PF_ValuesUtils.php on line 588
• Warning: array_unique() expects parameter 1 to be array, object given in /mw-REL1_28/extensions/PageForms/includes/PF_ValuesUtils.php on line 589
  Jaider ^msg 14:30, 26 May 2017 (UTC)

(Just a brief note, to anyone reading this and confused - the first few lines, from January, were copied over from the archives.) Yaron Koren (talk) 16:21, 26 May 2017 (UTC)

Autocompetion on Category

Hi, I am using PageForms to create pages with sequential names, e.g. 'PageName 0001', 'PageName 0002' etc. To avoid duplications I used the argument 'Autocomplete on category', so users can check if a page name already exists. This is very useful until there are few pages, but when they become hundreds, users are obliged to guess which will be the next 'free' page name. I didn't find anything in Page Forms user guide to solve this problem. While I was searching for a solution I have a simple idea about how to solve it: it would be enough to set 'Autocomplete on category' to show page names in a reverse alphabetical order (Z to A), so users would immediately see the last page name used. Does anyone know if this could be a possible solution?

Update: I have found something here.

Thanks,
--Loman87 (talk) 08:11, 5 June 2017 (UTC)

You may be in for a treat - see The one-step process; it may make your life a lot easier. Yaron Koren (talk) 14:29, 5 June 2017 (UTC)

Wow! This is really helpful Yaron, thanks a lot! --Loman87 (talk) 09:29, 6 June 2017 (UTC)

Value delimiter

Hi, there is an issue that I am not able to fix by myself.
I have a very simple form to create bibliographical pages; in the template I set the field 'Name' as follows:

| {{#arraymap:{{{Name(s)|}}}|;|x|[[Has creator::x]]|}}

The same field in the form is set as follows:

| {{{field|Name(s)|input type=text with autocomplete|list}}}

When I start typing the field, autocompletion appears as expected; but if I select one of suggested values, a comma is automatically added after the value. If I add a new value, the same happens; after saving, the whole field contains a unique value composed by all the values that I have added, separated by a comma. Now, I understand why this happens, since in the template the delimiter is semicolon. If I come back to the field and I manually change comma with semicolon, the values are actually processed as two different values, but, after saving, I see them separated by comma not semicolon. This is one issue.
Secondly, when I am filling the form and I use semicolon to separate the values, autocompletion doesn't work; otherwise, it works if a I use a semicolon.
Am I missing something very basic? Please help!
Thanks,
--Loman87 (talk) 12:11, 6 June 2017 (UTC)

I didn't really understand the second issue, but I'm guessing that both would be fixed if you added "|delimiter=;" to the field tag in the form definition. Normally the form would be able to figure that out from the template, but somehow it's failing here - maybe because of the parentheses in the field name. It seems like a Page Forms bug, in any case. Yaron Koren (talk) 13:37, 6 June 2017 (UTC)

I meant 'otherwise, it works if a I use a comma', sorry. However I added "|delimiter=;" to the field tag in the form definition and everything works fine, both visualization and autocompletion. Thanks for the help. --Loman87 (talk) 14:06, 6 June 2017 (UTC)

Dollar symbol issue

I have a form with a price input, but for some reason whenever I enter say "$100" it becomes "0" or "$9.55" becomes ".55". am I doing something wrong? or is something else affecting this? --CyberXRef^☎ 06:39, 8 June 2017 (UTC)

That was a problem a while ago, but I thought it was fixed already. What version of Page Forms are you using? Yaron Koren (talk) 14:10, 8 June 2017 (UTC)

Page Forms 4.1.1, Semantic MediaWiki 2.5.0 --CyberXRef^☎ 16:52, 8 June 2017 (UTC)

Well, there's a slightly newer version of PF, but I doubt that's the issue. What version of MediaWiki are you running? What is the input type of that field? And what is the type of the corresponding SMW property? Yaron Koren (talk) 18:34, 8 June 2017 (UTC)

We're using MediaWiki 1.28.1 and the input is just "text". The problem occurs in any field I enter a number starting with a dollar symbol actually.

If I enter "$123.456" in pretty much any field. When I click the "Show changes" the value shows up as: |something=3.456.

This is true even if I disable JavaScript, Just to make sure I don't have some conflicting library. --CyberXRef^☎ 20:36, 8 June 2017 (UTC)

I just tested it some more and discovered this only happens when I work on pages with existing template. If I try to create a new page with the form, it saves the value correctly (e.g., "$123.456"). Maybe this can help pinpoint the exact issue. --CyberXRef^☎ 22:21, 8 June 2017 (UTC)

I can't reproduce this issue, with either new pages or existing pages. Is this a public wiki, by any chance? Also, I would try upgrading to the latest version of PF - who knows, maybe that will fix it. Yaron Koren (talk) 15:42, 9 June 2017 (UTC)

Problem persists in Page Forms 4.1.2 (b8d88a7) 16:45, 7 June 2017. And naa, the wiki is internal only. I'll try to see if I can find something on wikiapiary. --CyberXRef^☎ 18:37, 9 June 2017 (UTC)

Hey Yaron, I found the issue (or at least one). Line 1363 of PF_FormPrinter.php. preg_replace is eating that "$12". Here is a minimal reproducer on codepad. --CyberXRef^☎ 05:50, 10 June 2017 (UTC)

Thanks for finding that, that's very helpful. Is this a "partial" form, by any chance? Yaron Koren (talk) 15:27, 14 June 2017 (UTC)

Yes this is a partial form. --CyberXRef^☎ 21:26, 14 June 2017 (UTC)

Okay, that explains it - this only happens for partial forms, which is why I couldn't reproduce it. I just checked in what I think is a fix. Yaron Koren (talk) 17:11, 15 June 2017 (UTC)

Looks like it's fixed! --CyberXRef^☎ 13:18, 17 June 2017 (UTC)

Two forms in one Page

Is there a way to edit two forms in the same time on the same page ? --Paul LEMPERIERE (talk) 19:29, 9 June 2017 (UTC)

Sorry, I don't know what you mean exactly. Yaron Koren (talk) 15:43, 9 June 2017 (UTC)

For exemple, I want to create a page "Project 0001" and a page "Event 0001", using a form called "Project" and a form called "Event". But I don't want to call successively this two forms. I want to create the two pages in the same time. Is it possible ? --Paul LEMPERIERE (talk) 19:29, 9 June 2017 (UTC)

Alternatively, I'd say you want to use a single form - not two - to create as well as edit two separate pages, right? What you could do is use the AutoCreatePage extension to create your second page (Event 0001) automatically as soon as the first page (Project 0001) is created. Secondly, ensure that the first page contains the source data for both pages but only show the information relevant for each page. This requires that your second page contains calls to your master page - clever transclusion or use of queries through the Semantic MediaWiki extension or Cargo could help you with that. Cavila 06:45, 11 June 2017 (UTC)

Thanks a lot, it seems that this is the good way to solve my problem ! But I have another question : in a standard form, you can use the "page name=" parameter combined with the <unique number> tag to generate incremental and unique page name. That's what I use to define the name of my "Project" pages (Project 0001, Project 0002,Project 0003,...). Unfortunately, when I use the parser {{#createpageifnotex:}} provided by the AutoCreatePage extension to create my event pages, I can't use this way to name the pages, and so I can't name incrementally my events (Event 0001, Event 0002,...). Do you know a way to solve this problem ? Thanks ! --Paul LEMPERIERE (talk) 09:25, 5 July 2017 (UTC)

I don't know. Talk to the author of that extension (Markus), I guess? Yaron Koren (talk) 14:44, 5 July 2017 (UTC)

Image in a combobox

I'd like to know if it is possible, in a form, to use images as list of values for a combobox ? Something like this : {{{field|1|input type=tokens|values=[[Fichier:1.png]],[[Fichier:2.png]]}}} ? When I try to do this, images appear in the list, but when I select one of them, it's a <a href> tag who is displayed... --Paul LEMPERIERE (talk) 21:58, 10 June 2017 (UTC)

I think you can do this only in a roundabout way, via the External Data extension - see here. It's somewhat confusing, especially if the image data comes from MediaWiki itself - let me know if any of it doesn't make sense. Yaron Koren (talk) 03:05, 12 June 2017 (UTC)

Hi Yaron - I am also interested in this feature - especially in the combination with values from namespace=File - what would be necessary to enable selecting images?

--Seppl2013 (talk) 10:01, 25 August 2017 (UTC)

Did you read the section I linked to? Yaron Koren (talk) 12:50, 25 August 2017 (UTC)

formlink variable doesn't get parsed through (SOLVED)

Hi, I following direction from: https://www.mediawiki.org/wiki/Extension:Page_Forms/Linking_to_forms#Using_.23formlink to parse through a value to a variable using formlink. In the example ( {{#formlink:form=Quote|link text=Add a quote for this author|link type=button|query string=Quote[Author]=Page Forms/Archive April to July 2017 }} ) the 'pagename' gets assigned to 'Author' in the cargo table Quote. I'm trying something similar for example: http://csdms.colorado.edu/wiki/Model:HydroTrend#References. The 2 buttons ( "Automatically enter Reference by DOI" and "Manually enter Reference" ) are defined at: http://csdms.colorado.edu/wiki/Template:AddReferenceUploadButtons. The formlink contains the table name, variable and value (pagename) as indicated, but the value doesn't get passed. Is this because the template in the form is set up to hold multiple values ({{{for template| RefsInt2|multiple|label=Add Model name(s) discussed in reference}}} ) ? This is how the URL looks when trying to parse through the variable: http://csdms.colorado.edu/wiki/Special:FormEdit/Reference-auto1?RefsInt2%5BPublicationMultipleModelsCargo%5D=HydroTrend so seems like almost working to me. Tested this in Chrome.

Thanks, --Albert Ke (talk) 16:16, 14 June 2017 (UTC)

Yes, the query string for multiple-instance templates needs to be different - if you replace "RefsInt2[PublicationMultipleModelsCargo]" with "RefsInt2[1][PublicationMultipleModelsCargo]", it should work. By the way, if you only have one field in the template, it doesn't seem worth it to have that template... you can just replace it with a field that holds a list of values, like a "tokens" input. Yaron Koren (talk) 17:45, 15 June 2017 (UTC)

Works!! That was a simple fix, thank you! I'll look into the "tokens" input, thanks, --17:53, 15 June 2017 (UTC)

Is it possible to hide empty sections?

Hi, is it possible to not add to the page the heading for sections left empty? I see the extension does this for empty template parameters, and I'm looking to have the same happen with empty sections. Is it possible? If not, could you point me in the right direction to accomplish this in code? Thanks, FFS ^Talk 12:48, 21 June 2017 (UTC)

It's not possible, but it sounds like an interesting idea. You would have to modify lines 171-178 of includes/wikipage/PF_WikiPage.php - and possibly more if you wanted to make it a true form option. Yaron Koren (talk) 18:55, 21 June 2017 (UTC)

Thanks for pointing the way! Since I definitely do not want to keep a fork of my own, I ended up doing it as an option (editing PFPageSection, PFWikiPageSection, PFFormPrinter and PFWikiPage). It was really easy to dive into your code! I'll try to clean it up and submit as a patch soon, so you can behold in horror the result of my horrendous naming skills. And maybe even merge it, eventually :-) FFS ^Talk 23:54, 21 June 2017 (UTC)

Actually, I have a question - I currently have it implemented as a section-by-section option ("hidewhenempty"). I'm not sure if that makes any sense; do you think it makes more sense to have it as a global configuration option, or maybe a form-level one? For my use case it doesn't matter at all (I will always hide empty sections on my wiki). FFS ^Talk 11:02, 22 June 2017 (UTC)

That's an interesting question. I agree that this would be a useful feature, but I think you're the first person who has asked about it, which means that I don't know what all the potential use cases for it would be. But it seems to me that a section-based option, like you have it, is the safest approach. Though maybe calling it "hide when empty" (with spaces) is better... Yaron Koren (talk) 15:00, 22 June 2017 (UTC)

OK, so I submitted gerrit:361238 and added you as a reviewer. I'd love your feedback and to know what mistakes I made along the way :-) FFS ^Talk 20:25, 24 June 2017 (UTC)

datepicker not usable

Hi Yaron,

i'm using PageForms 4.1.2. Fields with a a datepicker-type and a datetimepicker-type appear like usual fields. Here's the code from the form:

|-
| valign="top" | '''Wunschdatum:'''
| {{{field|Wunschdatum|input type=datepicker}}}

There's no error on js-console. This is the html-code generated by the system:

<tr>
<td valign="top"> <b>Wunschdatum:</b>
</td>
<td> <span class="inputSpan"><input name="SNOWL:Idee[Wunschdatum]" class="" value="" type="text" id="input_6" tabindex="6" /></span>
</td></tr>

What's wrong? --217.234.159.235 09:11, 26 June 2017 (UTC)

Sorry, sometimes the ideas came while writing. There was a mediawiki:common.js. Seems to be the problem. I've deleted this and datepicker works :-)

"Show on select" not working properly

I maintain the website where, among others, one can find information about locomotives. A locomotive can have status "scrapped", "in running order", "exhibit" and so on. Depending on the status the form displays some fields, and some fields not. In some cases the fields are the same - only instructions shown to the editor differ. When an editor uses the form to create a new record everything is fine. But when he wants to update information a problem appears. The form shows values in fields only when the fragment of the code responsible for displaying them is in the first block of conditional code. Example:

{{{field|Stan|input type=dropdown|values=Sprawna, Odstawiona, Złom, Eksponat, Pomnik, W trakcie remontu, Nieznany, Wrak|mandatory|property=Lw stan|show on select=Sprawna=>sprawna;Odstawiona=>odstawiona;Złom=>zlom}}} <div id="sprawna"> .
.
.
</div> <div id="odstawiona"> .
.
.
</div> <div id="zlom"> .
.
.
</div>

So when the status of the locomotive is "Złom" (which means scrapped) or "Ostawiona" (out of order) and the user wants to edit an existing page fields in the form are empty (values are not shown though they exist in the code of the page). When the status of a locomotive is "Sprawna" (in running order) values in the fields of the form are shown properly. Shortly said: data are shown in fields of the form only if the div responsible for displaying them is first in the code. When it is second, third and so on - fields of the form are empty. Is it a bug or it is me doing something wrong?

I use MediaWiki 28.2, SMW 2.5.2 and PageForms 4.1.1. But the problem also existed when I used slghtly older versions of MW, SMW and PF. Regards Pawel Niemczuk (talk) 17:02, 1 July 2017 (UTC)

Could you link to (if it's on a public wiki) or pastebin the entire form definition? Yaron Koren (talk) 02:35, 3 July 2017 (UTC)

Yaron, thank you for your prompt reply. In the meantime I've analyzed the code and rethought it. And I've come to the conclusion that it is my mistake and wrong way of thinking. So apparantly the code, though it is not displayed, is still parsed. And this produces unforseen or unwanted behaviour. Shortly said: if there are several divs which are displayed (or not) depending on selected value they should not use the same names of fields. So in order to avoid unwanted behaviour one should either carefully design the code of the form or, what is way more complicated, cumbersome, not elegant and obfuscates the code, redesign it changing names of the fields which are repeated in different divs (and, consequently, redesign templates, queries etc.).

To make a long story short: I think I've found the solution and once the form is ready I'll post links to both old and not working version and the new working one. Pawel Niemczuk (talk) 23:36, 3 July 2017 (UTC)

I just read this again, and I realized I missed the part before where you mentioned using the same field names in different divs. Yes, that doesn't work, and it's a frequent complaint of people using "show on select". The "values dependent on" option is a way to try to achieve something similar - where the value selected for field A affects the allowed values for field B - but it doesn't work exactly the same, so it may or may not be helpful for your case. Yaron Koren (talk) 14:13, 21 July 2017 (UTC)

openlayers input over https

When using openlayers input on a server running https, I get the following JS error:

Mixed Content: The page at 'https://myserver/index.php?title=Building:9cd73c9a-f238-4757-b4d2-5e91554daa59&action=formedit' was loaded over HTTPS, but requested an insecure script 'http://openlayers.org/api/OpenLayers.js'. This request has been blocked; the content must be served over HTTPS.

The funny thing: changing PF_OpenLayersInput.php ~Line 59 to https://www.openlayers.org/api/OpenLayers.js and flushing all caches still returns the above error...

...ah, it seems, that the openlayers.org is always redirecting to http

... using the recent version of Extension:OpenLayers fails with the following JS error: Uncaught ReferenceError: OpenLayers is not defined

Mmm, I remember seeing the same error in another situation (using a widget with OpenLayers v2.x). It worked for a moment by replacing it with a call to https://cdnjs.cloudflare.com/ajax/libs/openlayers/2.13.1/OpenLayers.js but after a day or so, this, too, failed. Cavila 07:19, 17 July 2017 (UTC)

Special:CreateClass over rides property pages with no warning

It appears that when I use [[Special:CreateClass]] and input properties that already exist, I edit the property pages with no warning. A user kept changing my properties page type from [[Has type::Page]] to [[Has type::Text]] and they didn't realize it because they were using [[Special:CreateClass]]. --Mav-Tek (talk) 17:09, 5 July 2017 (UTC)

Default filename when using "uploadable" parameter

Is it possible to base the default filename on the current contents of one of the form's own fields? Thanks. Jonathan3 (talk) 00:41, 16 July 2017 (UTC)

No, unfortunately. Yaron Koren (talk) 22:52, 16 July 2017 (UTC)

Autocomplete in forminput only works once

I use this to create or edit a page with autocompletion on a category (PageForms 4.1.2):

{{#forminput:form=Create Device|autocomplete on category=Devices}}

Strangely, autocompletion in this input field only works one single time after I change something in the LocalSettings.php (regardless of what I change, can be just a new line). When I reload the page, it's not working anymore (until I change again the LocalSettings). Any idea, what's going on there? The autocompletion in the search bar works. Marccreal

When it's not working, do you see any errors in the JavaScript console? Yaron Koren (talk) 17:39, 19 July 2017 (UTC)

No, there are no errors (in Chrome the console under "More Tools/Developer tools" is the correct place to look, right?). The only thing, that shows up there are these warnings, but they always show up (and already when loading the page):

VM13225:70 This page is using the deprecated ResourceLoader module "jquery.ui.position"

VM13225:81 This page is using the deprecated ResourceLoader module "jquery.ui.widget".

This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use "mediawiki.ui.button" or "oojs-ui" instead. Marccreal (talk) 22:15, 19 July 2017 (UTC)

More puzzling findings: The behaviour is "page-wise". Even when there are two different forminput with autocomplete to different categories, autocompletion works for both of them but only until I reload the page. But if I then go to another page with a forminput, it works there again (but again only until reload). Marccreal (talk) 22:37, 19 July 2017 (UTC)

Alright. I know about those JS warnings - I need to fix those, but they're unrelated to this issue. I'm pretty sure the problem is the MediaWiki cache - you don't need to edit LocalSettings.php to get the autocompletion temporarily working, you just need to add "?action=purge" to the URL, I think. I don't know why this is happening for you, though. Do you have some unusual MW caching setup? And what version of MediaWiki are you using? Yaron Koren (talk) 03:54, 20 July 2017 (UTC)

You are right, adding "?action=purge" makes the autocompletion work. I also suspected some problem with caching. The setting after installation was $wgMainCacheType = CACHE_NONE; I tried CACHE_DB, but this did not change anything (or do I have to do additional steps besides setting the variable?). During installation, the following warning was displayed: "Warning: Could not find APCu, XCache or WinCache. Object caching is not enabled." Marccreal (talk) 08:14, 20 July 2017 (UTC)

What version of MediaWiki are you using? Yaron Koren (talk) 11:50, 20 July 2017 (UTC)

Sorry, forgot to answer that: 1.29.0. I now changed to $wgMainCacheType = CACHE_ANYTHING; With that, autocompletion seems to work!

Oh - very interesting. It's great that you found a solution. I'll have to look into that; ideally this can work with any caching type. Yaron Koren (talk) 12:17, 20 July 2017 (UTC)

Bad news, it still does not work reliably. The functionality is not gone by a simple reload but for example after modifying the page. As before, ?action=purge brings back the autocomplete. Also when I load other pages and load then again the page with the forminput, autocompletion might stop working (not every time, but when it once stops working, it does not come back until a purge) Marccreal (talk) 13:29, 20 July 2017 (UTC)

Ok with this setting: $wgParserCacheType = CACHE_NONE; it seems to work. Which is very puzzling, because was set to $wgMainCacheType = CACHE_NONE; from the start, and the documentation says, that this setting is inherited by $wgParserCacheType, nevertheless autocompletion didn't work with this setting. By the way, I am not sure, if this page is suitable for communication about this problem so if you feel this should move to somewhere else, please let me know. Marccreal (talk) 12:30, 21 July 2017 (UTC)

No, here is fine. It's not surprising that turning off caching will fix this problem for you, given that caching was causing the problem. I'll have to look into it - it may be a new issue due to changes in MW 1.29. Yaron Koren (talk) 14:08, 21 July 2017 (UTC)

I have a 1.28.2 installation on the same server, it's the same issue there. Manual:$wgParserCacheType is unclear or wrong imho because it states: "If you set Manual:$wgMainCacheType then the values for $wgParserCacheType and Manual:$wgMessageCacheType will inherit it." Marccreal (talk) 14:42, 21 July 2017 (UTC)

What happens if you remove (or comment out) all caching-related settings from LocalSettings.php? Yaron Koren (talk) 04:13, 25 July 2017 (UTC)

Then it shows the "working once" behaviour again. Marccreal (talk) 10:53, 25 July 2017 (UTC)

Edit with Form Tab

Hello, what is the correct way to disable the edit with form-tab on a single page within a category with default_form. Example: i Have a category "countries" with {#default_form:country} in category-page. The pages are "Germany, Italian, etc.". Also there exist one page "merged country's" with some explanations, but this page can't use the form "country". In Previous versions of Page forms i use [[Has default Page::None]] on this special page to disable the edit with form tab. But this doesn't work anymore. --TomyLee (talk) 11:19, 31 July 2017 (UTC)

I don't remember if that previous behavior was intentional, or just an accident (by the way, it didn't have to be "None" - you could just put in any string that was not a form name), but it does make sense to have behavior like that - so that if someone adds "{{#default_form:}}" to a page, it won't get an "edit with form" tab. I'll have to look into that. Yaron Koren (talk) 02:55, 1 August 2017 (UTC)

I just added that feature, so now "{{#default_form:}}" works for this, if you get the latest code. Yaron Koren (talk) 20:02, 1 August 2017 (UTC)