Page MenuHomePhabricator

input fields ignore default setting on page edit
Closed, DuplicatePublic

Description

Hi

I am reluctant to bring it up, but I still have a problem with default values getting ignored, this time on a normal template (and not a multi-instance as in T126770).

The problem seems only to occur when I edit a page. The form ignores all default settings for fields, that are part of a "show on select" and where hidden before.
On page creation all works fine. Also, when I edit a page and the field was shown before, all values are ok, too.

I try to give an example with an excerpt from my form:

{{{field|Cargo_activate|restricted=wf-operations|values=Ja,Nein|input type=radiobutton|mandatory|show on select=Ja=>row_Cargo_configuration;|default=Nein}}}				[0]
<div id = "row_Cargo_configuration">
Overwrite?	{{{field|wgCargo24HourTime_overwrite|show on select=Ja=>row_wgCargo24HourTime_value;|mandatory|values=Ja,Nein|input type=radiobutton|default=Nein}}}			[1]
	<div id="row_wgCargo24HourTime_value">
	new value	{{{field|wgCargo24HourTime_value|default=true|mandatory|values=true,false|input type=radiobutton}}}								[2]
	</div>
Overwrite?	{{{field|wgCargoDefaultQueryLimit_overwrite|show on select=Ja=>row_wgCargoDefaultQueryLimit_value|mandatory|values=Ja,Nein|input type=radiobutton|default=Nein}}}	[3]
	<div id="row_wgCargoDefaultQueryLimit_value">
	new value	{{{field|wgCargoDefaultQueryLimit_value|default=500|input type=regexp|regexp=/^[0-9]+$/|mandatory|base type=text|size=40}}}					[4]
	</div>
</div>

On create
Everything as expected:
[0] shows options "Ja" and "Nein" with "Nein" being selected
On selecting "Ja" the first div (row_Cargo_configuration) appears, giving

  • [1] showing options "Ja" and "Nein" with "Nein" being selected
    • selecting "Ja" here, gives us [2] with options "true" and "false", "true" being selected
  • [3] showing options "Ja" and "Nein" with "Nein" being selected
    • selecting "Ja" here, gives us [4] with "500" in the input field

Now, lets assume we keep [0] at "Nein" and save the page

On edit
Now I edit the page again. Unfortunately, my form looks slightly different:
[0] shows options "Ja" and "Nein" with "Nein" being selected (as before)
On selecting "Ja" the first div (row_Cargo_configuration) appears, giving

  • [1] showing options "Keine Angabe", "Ja" and "Nein" with "keine Angabe" being selected. ("Keine Angabe" is the german translation for message sf_formedit_none meaning "none"). Since [1] is a mandatory field, this should not be and also throws an error, when I try to save w/o selecting one viable option
    • selecting "Ja" here, gives us [2] with options "Keine Angabe", "Ja" and "Nein" with "keine Angabe" being selected
  • [3] showing options "Keine Angabe", "Ja" and "Nein" with "keine Angabe" being selected.
    • selecting "Ja" here, gives us [4] with an empty input field

When I set [0] to "Ja", [1] to "Ja" and [2] to "false" and save, I would get an error, since "keine Angabe" is not a viable option for [3]. So I set this to "Nein" and save. On my next edit [1], [2] and [3] are only showing the option that are defined in their respective value-attributes. (no "Keine Angabe" in any of them as third option). They also show the correct values I had set before. When now selecting "Ja" on [3], [4] however would still be empty not giving me the expected "500".

My setup

  • MW 1.25.5
  • SF 3.5 (tried both 9c48959 and 913c117)
  • PHP 5.6.17

I hope, I made myself clear enough. If you need more information, any source code or help, please let me know.

Best wishes

Event Timeline

If I understand what you're talking about, this is done on purpose - default values are ignored after a page has been created, with the exception of new instances of a multiple-instance template. You could make the case that a newly-unhidden form element should be another exception, which I think is what you're saying. Is that correct?

Hmm. I remember that there was an issue where purposefully blanked input fields would be (wrongfully) populated with the default values on a later edit.
My problem is that I often make heavy use of the "show on select" mechanics and sometimes I have defaults w/o whom users would have to enter quite some text. Also, adding unviable options like "none" to radiobuttons would in some cases have the user set all of them manually to a value accepted by the form (if not, the form refuses to save). I really hope it's not too much of a challange but:

[TL;DR] Yes, please. make newly unhidden form elements an exception.

As I see it, hidden fields do not show in the template at all after the page was saved, whereas blanked fields show up but have an empty value. Maybe SF could use that to decide whether to apply defaults or not.

That's a fair point - it's essentially the same issue covered in this bug report:

https://phabricator.wikimedia.org/T38505

...though that one covers newly-added template/form fields.

Actually, I have the problems mentioned in https://phabricator.wikimedia.org/T38505 as well. :) But compared to the ones I issued here, they are negligible for me.

Hmm. I just found out, I have to correct myself.

But compared to the ones I issued here, they are negligible for me.

Sadly I was wrong in that regard.

My case: I have a dynamic form that builds its fields from the contents of a cargo table. That table doesn't change often, but it sometimes does. The original point of the dynamic form was that changes in the cargo table do take effect. With this issue here, they indeed don't in some of the cases: Sometimes a change in the underlying cargo tabe triggers a new hidden field with a default value. Which, regarding to T38505 will be ignored.

To summarize:

  • if a field has a default value but is blanked by the user, I would expect sf to ignore the default on consecutive edits
  • if a formerly hidden field (meaning, a field being target of a "show on select") is presented to the user, I would expect sf to use the default value
  • if the form definition has changed and a field was added that has a default value, I would expect sf to use the default value, as well

Is that do-able at all?

On a sidenote: looking at the post data from a form save, it looks like at least firefox does not submit hidden form fields. I don't know if this is default behaviour for browsers, though. But maybe that could be something to work on...