Extension talk:Page Forms/Archive October to December 2018

Include SMW inline query in info tag "page name" parameter?

Hi there. I would like to design a form that generates the value of the pagename parameter from a combination of

1. a template field value (<GuidelineArticle[FieldnameXy]>) AND
2. the result of an SMW inline query {{#show:{{{Fieldname|}}}|?PropertnameXy}}

Is this doable? How would the syntax look like? -- 11-G3n (talk) 09:06, 5 December 2018 (UTC)

I think the only way to do this is programmatically, using the "PageForms::SetTargetName" hook. Yaron Koren (talk) 19:55, 5 December 2018 (UTC)

Thanks! 11-G3n (talk) 18:47, 6 December 2018 (UTC)

input type "datetime" loses time zone info on editing

If I have a PageForm defined with a datetime input with "include timezone" set, I can enter the date, time, and timezone and save correctly. However, when I go to edit the page with the form again the timezone gets changed to UTC and the date/time get converted to UTC (I think it may actually change to the server's time zone). I think the issue is related to PF_DateTimeInput.php line 81, as the call to date just takes in the integer timestamp. I wonder if maybe line 69 should be tweaked to use date_create_from_format or some other code to parse out the timezone string from the template value. --PCChris23 (talk) 07:38, 5 October 2018 (UTC)

s/date_create_from_format/DateTime::__construct()/ @Yaron Koren: should I create an issue in Phabricator? I am not very familiar with PHP or with the codebase of MediaWiki or this extension, but I could try to fix it if this general approach seems reasonable. Or is there some other workaround you can suggest? Thanks, PCChris23 (talk) 06:26, 13 October 2018 (UTC)

Sorry about the problem, and that was a good idea on the solution. I just checked in what I think is a fix, using the PHP DateTime class as you suggested. Yaron Koren (talk) 03:09, 15 October 2018 (UTC)

Thanks, @Yaron Koren: , that did the trick! --PCChris23 (talk) 23:54, 28 October 2018 (UTC)

Combobox/Text with autocomplete: Possibility for indented items or separators for separating content?

Heya,

is there a possibility to format the content of a combobox or text with autocomplete in a way that it shows indented items (like "*", "**" etc. for "tree" input type)?

If not, is there a way to insert a horizontal rule or a blank line in order to group the list items?

Thank you!

--Sochin67 (talk) 20:06, 5 October 2018 (UTC)

Unfortunately, no. Yaron Koren (talk) 20:20, 5 October 2018 (UTC)

Okay - thank you, Yaron! --Sochin67 (talk) 20:31, 5 October 2018 (UTC)

Set custom attr or ID on a field

I'm writing some pre-save errorchecking for a form in JS, and it would be really convenient if I could define an attribute like data-stat="Strength" for each field, particularly for dropdowns but also in general. Could something like |attr=stat,att2,att3|attr_values=Strength,val2,val3 be added as an available option for any input field if it's straightforward enough to do? Similar for setting a custom ID. --RheingoldRiver (talk) 09:34, 10 October 2018 (UTC)

What about just putting a "div" or "span" tag around the input, and setting one or more classes for it - would that be good enough? Yaron Koren (talk) 15:51, 10 October 2018 (UTC)

I have 7 sets of data that correspond to different stats, and some of the fields are dropdowns so I have to monitor their values with .change. So what I'm able to do is pretty awkward if I want to do any kind of for loop. If I could set an attr I could look up its value and then define what changed with that as the key, and it would be a lot cleaner. But yeah this request is probably only needed for dropdowns, for any other input type I think just a parent class is fine (and has been so far). --RheingoldRiver (talk) 21:47, 10 October 2018 (UTC)

Bug with "show on select" radiobutton labels when using Multiple instances

Hi Yaron, hi Friends,

I am using Page Form [REL1_31 (June 24)] (Maybe this bug has already been fixed, if yes, sorry for that..)

When I use "show on select" with radiobuttons when using Multiple instances, the label of the radiobuttons are not clickable on every instance.

I have noticed that:

• When I formedit a page, for each new multiple instance added, the radiobutton's labels have a "For" target empty (in that case the label is NOT clickable because the For is empty)
• When I save the page and go back to formedit, the radiobutton's labels of the pre-existing instances doesn't have a "For" target at all (in that case the label is clickable)

I assume the best way to fix this is to add a target to each "For". Am I doing something wrong? Have you seen that bug before?

Thanks a lot --ClemFlip (talk) 10:15, 11 October 2018 (UTC)

Okay, I just checked in a fix for this (with your help :) ). Yaron Koren (talk) 19:09, 26 October 2018 (UTC)

Bug in fields textarea with editor = wikieditor: the field can not be empty.

Hi there,
With PageForms 4.3.1, a textarea field with editor=wikieditor generates a bug when the field isn't filled : "« | » is not allowed except inside {{...}} or [[...]]."
--Megajoule (talk) 09:01, 12 October 2018 (UTC)

Is the problem still there in PF 4.4? Yaron Koren (talk) 04:45, 14 October 2018 (UTC)

Yes, it is... Megajoule (talk) 13:15, 8 January 2019 (UTC)

Textarea on multiple-instance templates while using IE turns placeholder text in to actual text

Hello!

When using the multiple-instance template and setting a field to use the "textarea" input type, the placeholder text (in the "textarea") populates as actual text. This only seems to happen on Internet Explorer, is there a way to fix this?

I'm experiencing this on:

• MW: 1.31.1 (a4c8065)
• SMW: 2.5.8
• PF: 4.4-rc1 (b4c29bd)

Thanks in advance,

V brooks (talk) 18:12, 18 October 2018 (UTC)

Yes, that's a known problem, already listed here. Is there any way you can upgrade to MS Edge? Yaron Koren (talk) 19:03, 18 October 2018 (UTC)

Sounds good, majority of my users use Chrome so I'll suggest the IE users to use Chrome for now. Thanks! --V brooks (talk) 15:46, 19 October 2018 (UTC)

mapping cargo table ampersand encoding

If I have a cargo table "sweets" with a field "sweetName" and if I have a form that allows you to pick a sweet from this list like this...

{{{for template|Prize}}}
{| class="formtable"
|-
! Pick you sweet prize!
|{{{field|sweetPrize|values from category=Sweets|mapping cargo table=sweets|mapping cargo field=sweetName}}}
|}
{{{end template}}}</nowiki>

M&Ms would be displayed as M&amp;Ms in the option list. i.e

<option value="M&amp;amp;Ms">M&amp;amp;Ms</option>

Have I missed a trick or is there a bug? JamesDriscoll (talk) 17:29, 1 November 2018 (UTC)

Further to this problem, I think I've tracked the issue down to double encoding in PF_DropdownInput::getHTML

		foreach ( $possible_values as $possible_value ) {
			$optionAttrs = array( 'value' => $possible_value );
			if ( $possible_value == $cur_value ) {
				$optionAttrs['selected'] = "selected";
			}
			if (
				array_key_exists( 'value_labels', $other_args ) &&
				is_array( $other_args['value_labels'] ) &&
				array_key_exists( $possible_value, $other_args['value_labels'] )
			) {
				$label = $other_args['value_labels'][$possible_value];
			} else {
				$label = $possible_value;
			}
			$innerDropdown .= Html::element( 'option', $optionAttrs, $label );
		}

Here is a fix for my own use case but I dont' know enough about the code to know if $label will also need decoding on line 91 and there may be similar issues in other forminputs.

		foreach ( $possible_values as $possible_value ) {
// prevent double-encoding, value has already been HTML-encoded 
// and it will get encoded again by Html::element() - 
$possible_value = html_entity_decode( $possible_value );
			$optionAttrs = array( 'value' => $possible_value );
			if ( $possible_value == $cur_value ) {
				$optionAttrs['selected'] = "selected";
			}
			if (
				array_key_exists( 'value_labels', $other_args ) &&
				is_array( $other_args['value_labels'] ) &&
				array_key_exists( $possible_value, $other_args['value_labels'] )
			) {
				$label = $other_args['value_labels'][$possible_value];
			} else {
				$label = $possible_value;
			}
			$innerDropdown .= Html::element( 'option', $optionAttrs, $label );
		}

If $label also needs decoding on line 91 maybe changing

$innerDropdown .= Html::element( 'option', $optionAttrs, $label );

to

$innerDropdown .= Html::rawElement( 'option', $optionAttrs, $label );

will have the desired outcome without having to call html_entity_decode()?

I hope this helps JamesDriscoll (talk) 10:46, 10 November 2018 (UTC)

Create Property link missing

Hi

I have several installations of MediaWiki with Page Forms installed on all of these installations.

But one of the installations I am not seeing the create property link. I have run the update script, but still not seeing anything.

Not sure what I have done wrong.

Any help is appreciated.

Gary

--Squeak24 (talk) 13:04, 2 November 2018 (UTC)

It only shows up if Semantic MediaWiki is installed on that wiki. Yaron Koren (talk) 13:49, 2 November 2018 (UTC)

Thanks Yaron, I have Semantic MediaWiki installed, but it still isn't showing. The only SMW related extension I don't have installed at the moment is Semantic Compound Queries. Do I need that installed as well?

This is what I have so far:

Semantic extensions
Extension	Version	Licence	Description	Authors
Semantic Drilldown	2.0.2 (2252e92)06:10, 14 April 2018	GPL-2.0-or-later	A drilldown interface for navigating through semantic data	Yaron Koren and others
Semantic Forms Select	2.2.0-alpha	GPL-2.0-or-later	Allows to generate a select field in a form whose values are retrieved from a query	Jason Zhang, James Hong Kong, Toni Hermoso Pulido, Thomas Mulhall and others
Semantic Internal Objects	0.8.2 (2b195cf)04:25, 10 March 2018	GPL-2.0-or-later	Setting of internal objects in Semantic MediaWiki	Yaron Koren

--Squeak24 (talk) 10:22, 7 November 2018 (UTC)

What version of Page Forms are you running? Yaron Koren (talk) 17:13, 7 November 2018 (UTC)

Hi Yaron, apologies for the delay. I am using version 4.3. But now you mention that, this is the only Wiki I have that I am running SMW 3.0. I will try 2.5x --Squeak24 (talk) 10:55, 15 November 2018 (UTC)

WikiEditor strange timing bug

I'm trying to track down a bug where the wikieditor doesn't always display the file upload and other icons on a form edit. instead of

it's opening like this

I discovered an error that I'm hoping is related(though I'm not entirely convinced) the console is reporting

Uncaught TypeError: initFunction is not a function
    at HTMLDocument.<anonymous> (PageForms.js?18121:330)
    at mightThrow (load.php?debug=true&lang=en-gb&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=0ri47ih:3583)
    at process (load.php?debug=true&lang=en-gb&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=0ri47ih:3651)

the offending line in PageForms.js is

    $(function() {initFunction ( input.attr("id"), param );});

called from (in PageForms.js)

    	$( '#' + inputID ).PageForms_registerInputInit( getFunctionFromName( initFunctionData[ inputID ][ i ][ 'name' ] ), initFunctionData[ inputID ][ i ][ 'param' ] );

with a param of null in this...

including &purge=true&debug=true in formedit url is very likely to repeat the bug. I've never got the icons to fail to load on a action=edit ,it's only happening on pageforms action=formedit. I hope this is usful info

JamesDriscoll (talk) 11:59, 3 November 2018 (UTC)

Sorry for the very long delay. This might have been fixed a while ago; I'm not sure. Yaron Koren (talk) 15:36, 12 February 2019 (UTC)

the initFunction error has gone but the fileupload doesn't always appear in a random way for users (often, but not always, a page refresh will fix it). loading a page with &action=formedit&debug=true is still a pretty good way of reproducing the error (sadly on a company intranet so I can't point you at the problem) JamesDriscoll (talk) 14:51, 15 February 2019 (UTC)

$wgPageFormsAutocompleteOnAllChars = true; not working?

I have not tried earlier versions but since 4.3 minimum and every later version on php 5.6 setting this configuration parameter has no effect. I can only autocomplete on the first chars of a word and not on chars within a word. --91.64.58.124 16:13, 7 November 2018 (UTC)

I just tried it - it looks like it works with the "tokens" and "combobox" input types, but not with "text with autocomplete". What input type(s) are you trying it with? Yaron Koren (talk) 17:20, 7 November 2018 (UTC)

Yes, I am using it with "text with autocomplete". --91.64.58.124 19:43, 7 November 2018 (UTC)

Alright - well, this is a bug that should be fixed. I should note that I've been thinking for a long time of getting rid of "text with autocomplete" (and "textarea with autocomplete"), keeping just "tokens" and "combobox". I would recommend switching one of those two, since I think their interface is better anyway. Yaron Koren (talk) 20:29, 7 November 2018 (UTC)

At least "tokens" does not work as a way out. No acceptance for it from the editors and it is not working on skin Foreground. I will have to look at "combobox" but in the end I do not like to loose "text with autocomplete" and "textarea with autocomplete" at all. These are the best to use. --91.64.58.124 21:33, 7 November 2018 (UTC)

Input type "datepicker" only shows after reloading the form a second time

Setup

• PHP 7.0
• MediaWiki 1.27.5
• PageForms 4.4.2
• Header Tabs 1.2

Issue

The datepicker only shows after reloading the form for a second time. The error shown in browser console for Firefox is:

TypeError: initFunction is not a function TypeError: "initFunction is not a function"
	PageForms_registerInputInit https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=ext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csubmit%2Cwikieditor%7Cext.pageforms.fancybox.jquery1%7Cjquery.checkboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Cuser%7Cmediawiki.api.user%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Csite%7Cuser.defaults&skin=monobook&version=737e8768c86e:72:20
	fire https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:104
	add https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:656
	ready https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:49:63
	<anonymous> https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=ext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csubmit%2Cwikieditor%7Cext.pageforms.fancybox.jquery1%7Cjquery.checkboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Cuser%7Cmediawiki.api.user%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Csite%7Cuser.defaults&skin=monobook&version=737e8768c86e:97:529
	<anonymous> https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=ext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csubmit%2Cwikieditor%7Cext.pageforms.fancybox.jquery1%7Cjquery.checkboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Cuser%7Cmediawiki.api.user%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Csite%7Cuser.defaults&skin=monobook&version=737e8768c86e:67:104
	runScript https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:163:74
	fire https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:104
	add https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:656
	always https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:46:865
	runScript https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:162:944
	checkCssHandles https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:163:774
	cssHandle https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:163:904
	fire https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:45:104
	fireWith https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:46:431
	fire https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:46:474
	fireCallbacks https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:157:607
	addEmbeddedCSS https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:158:681
	cssBufferTimer https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=ZwtlXwEX:157:832
load.php:178:449
log
https://www.example.com/w/load.php:178:449
handler
https://www.example.com/w/load.php:155:380
fire
https://www.example.com/w/load.php:45:104
fireWith
https://www.example.com/w/load.php:46:431
fire
https://www.example.com/w/load.php:46:474
track
https://www.example.com/w/load.php:155:162
runScript
https://www.example.com/w/load.php:163:400
checkCssHandles
https://www.example.com/w/load.php:163:774
cssHandle/<
https://www.example.com/w/load.php:163:904
fire
https://www.example.com/w/load.php:45:104
fireWith
https://www.example.com/w/load.php:46:431
fire
https://www.example.com/w/load.php:46:474
fireCallbacks
https://www.example.com/w/load.php:157:607
addEmbeddedCSS
https://www.example.com/w/load.php:158:681
addEmbeddedCSS/cssBufferTimer<
https://www.example.com/w/load.php:157:832

Perhaps this is also related to HeaderTabs. This is why I incuded the info, too. Cheers --[[kgh]] (talk) 11:37, 16 November 2018 (UTC)

I think you already reported that issue before, but it's still a problem, unfortunately. Yaron Koren (talk) 16:24, 16 November 2018 (UTC)

Well, it indeed somehow appeared familiar to me. Keeping fingers crossed for a fix. --[[kgh]] (talk) 18:58, 16 November 2018 (UTC)

This may be fixed now; I'm not sure. Yaron Koren (talk) 15:47, 23 January 2019 (UTC)

pfautoedit - 2 suggestions/requests

Hi,

1) Could you add a summary field for this action so I can let people know what's going on in RC?

And 2) Not sure how doable this is, but I often run this action on a set of 4k+ pages (all our player pages). Based on how long it takes to run, I assume it's blank editing every page if there are no changes. Would it be possible to have an option to say "skip if no changes" ? This would save me a ton of time since usually at most 300-500 of the pages need to be changed.

Thanks --RheingoldRiver (talk) 04:26, 24 November 2018 (UTC)

Auto complete on all pages

Auto completion can be enabled only on specific properties: name space, categories etc, but cannot be set for all pages in all namespaces (unless declared by Cargo which is not always possible or relevant), or not even to multiple name spaces. When working with wikis that use multiple content namespaces, there's a need to have autocompletion for all pages just like the autocompletion of the VE template-data feature (i.e. with a property "values from=allpages" which will use the "allpages" API query). Completion from content namespaces will be even better, but is not crucial.Wess (talk) 16:54, 26 November 2018 (UTC)

I should note that there's currently no way to autocomplete on either all namespaces, or all content namespaces, within Page Forms, even if Cargo or SMW are being used. Autocompleting on all content namespaces seems like a much more useful feature than autocompleting on every single page in the wiki. Another option would be to allow multiple values for "values from namespace", so that you could have something like "values from namespace=Main,Project,Help". Yaron Koren (talk) 22:27, 27 November 2018 (UTC)

You are right. Both options will solve this need. Wess (talk) 09:49, 3 December 2018 (UTC)

I added in this feature a few days ago - if you use the latest code, you can now specify multiple values for "values from namespace=", separated by commas. Yaron Koren (talk) 16:23, 30 December 2018 (UTC)

Width of tokens input type [PROPOSED SOLUTION]

The tokens input type doesn’t work well within a “formtable” class form on the iPhone any more. It expands beyond the intended width of the td element and makes the whole table too wide. I know tables aren’t great on mobile anyway but I’m sure it used to work ok. I’ve not looked into it but see that min-width is set by javascript as 6*size, ie default 600, and wonder if this is relevant. The input element flashes up the right width then changes as the page loads. I worked round the problem for now by using a wikitable with th and td on alternate rows (so that the width of the tokens input type doesn’t cause any problem). Best wishes. Jonathan3 (talk) 09:55, 26 November 2018 (UTC)

Yes, I've run into this problem too. What do you suggest doing? Yaron Koren (talk) 04:22, 27 November 2018 (UTC)

I'd need to look into it. Giving it its own row seems to work for now, though. Maybe use a responsive grid format for the forms, so that on a computer it's two-column but on a phone it's one? Or add a "width" parameter which the Javascript will respect when setting "min-width"? Jonathan3 (talk) 14:39, 27 November 2018 (UTC)

I did the following to set widths on fields for a birthday input with comboboxes (I didn't want to use date input type since we allow year only or month-day only entry):

.select2-choices, .select2-choice{
  min-width: 0;
}
#content .form-ip-year .select2-container{
  width: 100px;
}

#content .form-ip-month .select2-container{
  width: 120px;
}

#content .form-ip-day .select2-container{
  width: 70px;
}

.form-ip-day, .form-ip-month, .form-ip-year {
  display:inline-block;
}

--RheingoldRiver (talk) 01:42, 29 November 2018 (UTC)

Thanks, both of you. For the tokens type, here is a solution in MediaWiki:Common.css: .pf-select2-container {min-width:0px !important}. It should be possible just to stop setting min-width in Page Forms by removing line 122 of ext.pf.select2.tokens.js which sets min-width: opts.containerCss = { 'min-width': size * 6 };. Jonathan3 (talk) 13:52, 23 February 2019 (UTC)

Issue with PHP 7.2

With PHP 7.2 Page Forms throws the following Warning in Special:FormEdit in a form with Field Typ Date

Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/extensions/PageForms/includes/forminputs/PF_ComboBoxInput.php on line 146

Version is current as of today in master branch (07cfd57).

Sorry about that - I just checked in what I think is a fix for this problem. Yaron Koren (talk) 04:54, 29 November 2018 (UTC)

editor=wikieditor does not work anymore with a Semantic Property

Hello. It seems that editor=wikieditor in a form does not work anymore. We are upgrading our wiki to MW 1.31 and found this problem.

I made an example on the SMW sandbox where the same thing happens.

see: https://sandbox.semantic-mediawiki.org/wiki/TestForm

Thanks and regards. --Felipe (talk) 13:44, 18 December 2018 (UTC)

I found the problem. In the past we wrote:

{{{field|test|rows=20|editor=wikieditor}}}

It should now be:

{{{field|test|input type=textarea|rows=20|editor=wikieditor}}}

--Felipe (talk) 14:48, 18 December 2018 (UTC)

Composer Install of Semantic Forms 3.4.2 fails

https://github.com/BITPlan/docker-semanticmediawiki has a docker image to install an older Mediawiki/SMW and Semantic Forms version. now the issue https://github.com/BITPlan/docker-semanticmediawiki/issues/13 has come up. I seems that renaming the extension has led to this situation. How can this be fixed? --WolfgangFahl (talk) 04:49, 30 December 2018 (UTC)

I don't know - I know very little about Composer, or Docker. Yaron Koren (talk) 16:16, 30 December 2018 (UTC)

Field Defined with "values from property=" Limited to What's Been Used

I have a generic property called "Has payment method". This property is used by several forms.

The property has many allowed values, including: ACH Bitcoin Cash Check Credit Card

If any one of the pages that use the form is updated with a payment method, then that payment method is the only one available to any of the other forms (including the one just used).

E.g., if I select "Check" when updating one page, then any page using a form that calls this property is limited to just "Check". None of the other options appear any more.

Is this an expected behavior of properties? Would I be better off creating a "Payment Method" category, with individual pages or sub-pages for each payment method? I can see some benefit of that, as it could provide a place to keep additional information about each payment method, but my first thought was that using properties would be somehow cleaner. Now I'm not so sure.

dvicci (talk) 19:28, 31 December 2018 (UTC)

That's very odd. When you go to the page for that property ("Property:Has payment method"), do you see all the values there? If so - what versions of MediaWiki, SMW and Page Forms are you running? Yaron Koren (talk) 20:14, 31 December 2018 (UTC)

I know, right? All the values remain in the property - the form isn't altering the property at all. All that's changing is what is being displayed. I'm running the following:

MediaWiki 1.31.1

PHP 7.0.33-0+deb9u1 (apache2handler)

MariaDB 10.1.37-MariaDB-0+deb9u1

Semantic Forms Select 3.0.0

Semantic MediaWiki 3.0.0

Semantic Result Formats 3.0.0

Page Forms 4.4.2

Page Schemas 0.4.8

dvicci (talk) 20:34, 31 December 2018 (UTC)

This isn't a public wiki, is it? Unfortunately, I don't have development access to a wiki running SMW 3.0, and I actually rarely use any version of SMW these days. When you say the property has many allowed values, do you mean it literally defines allowed values using the "Allows value" special property? If so, it's even stranger that this would fail. Yaron Koren (talk) 21:28, 31 December 2018 (UTC)

Correct, this isn't a public wiki. And also correct, I'm literally defining the allowed values in the Property, e.g. Allows value::Cash. Under the circumstances, I think using categories may be a better option anyway, though I may struggle a bit with page name collisions. Using subpages will get around that, but then I have the issue of potentially very long page names. 1st world problems...

It sounds like this is a pretty major bug with SMW 3.0, but unfortunately I don't know if I can debug it unless I get access to a wiki where this problem is occurring. Yaron Koren (talk) 18:20, 2 January 2019 (UTC)