Issue #2650994: Javascript states not working for boolean fields updated formatters to fix an issue with states http://cgit.drupalcode.org/drupal/commit/core/lib/Drupal/Core/Field/Plug... and the result input for timestamps ended up with a double name="name="

     $elements['custom_date_format']['#states']['visible'][] = array(
-      ':input[name="options[settings][date_format]"]' => array('value' => 'custom'),
+      ':input[name="name="fields[' . $this->fieldDefinition->getName() . '][settings_edit_form][settings][date_format]"]' => array('value' => 'custom'),
     );

Solution remove the extra name=".

CommentFileSizeAuthor
#11 2662592-fix-timestamp-formatter-states.patch893 bytesDave Reid
#4 issue-2662592-4.patch893 bytesmarcingy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

marcingy created an issue. See original summary.

marcingy’s picture

marcingy CreditAttribution: marcingy at Examiner.com commented
marcingy’s picture

marcingy CreditAttribution: marcingy at Examiner.com commented
Related issues: +#2650994: Javascript states not working for boolean fields
marcingy’s picture

marcingy CreditAttribution: marcingy at Examiner.com commented
Status: Active » Needs review
FileSize
issue-2662592-4.patch893 bytes
swentel’s picture

swentel CreditAttribution: swentel commented
Status: Needs review » Reviewed & tested by the community

Ah crap :)

slashrsm’s picture

slashrsm CreditAttribution: slashrsm at Examiner.com commented

Yes, looks good.

  • catch committed 0473722 on 
    Issue #2662592 by marcingy: TimestampFormatter.php has invalid input...
catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.1.x, thanks!

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid as a volunteer and at Lullabot commented
Version: 8.1.x-dev » 8.0.x-dev
Status: Fixed » Reviewed & tested by the community

This also applies to 8.0.x. Isn't there a standard procedure to at least check if it needs to be committed there too?

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 4: issue-2662592-4.patch, failed testing.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid as a volunteer and at Lullabot commented
Status: Needs work » Needs review
FileSize
2662592-fix-timestamp-formatter-states.patch893 bytes

Backported to 8.0.x.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid as a volunteer and at Lullabot commented

Wow, there's literally no difference in my patch vs the earlier one. Is the new testbot quite picky?

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid as a volunteer and at Lullabot commented

Oh, it tried to apply it to 8.1.x (which already has the patch) instead of 8.0.x.

swentel’s picture

swentel CreditAttribution: swentel commented
Status: Needs review » Reviewed & tested by the community
catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented

This also applies to 8.0.x. Isn't there a standard procedure to at least check if it needs to be committed there too?

Yes, that's done by setting the issue to 8.0.x - then whoever's committing the patch will check it against the bc policy and either commit it there, or explain why they haven't. This issue was against 8.1.x so I didn't bother.

If an issue doesn't get committed to 8.0.x, then it just means people have to wait until April 20th to get it. Given the number of issues in the RTBC queue, (132 8.x commits in the past four weeks) I'm more concerned about getting them committed to at least once branch (or CNW so they're not in the RTBC queue sitting around) so that everyone gets them eventually, than spending lots of time figuring out which issues can and cannot be committed to 8.0.x individually. When people really care about an issue being in 8.0.x, they can re-open the issue like you've done.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid as a volunteer and at Lullabot commented

Hrm, that's a bit concerning. I know it the past it's been customary of the committer to at least ask if it applies to a lower version but I guess the onus can be on the OP as well. It's just especially troubling that to me, it feels like we're not even bothering to try and fix 8.0.x bugs, because it doesn't matter (that's the impression I got, sorry if I'm totally misreading).

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented

Hrm, that's a bit concerning. I know it the past it's been customary of the committer to at least ask if it applies to a lower version but I guess the onus can be on the OP as well.

7.x EOL is in 2-5 years, 8.0.x EOL is in two months. So the applicability to 7.x or not is far more important than the applicability to 8.0.x.

Given there are ~5,000 bugs, ~500 major bugs and ~7 critical bugs (or at least reports) all unfixed in any 8.x branch at all, one or two bugs taking an extra couple of months to get into a tagged stable release doesn't seem like the worst trade-off. Especially since several issues over the past few months have been delayed or held up by discussions about whether they can get into 8.0.x due to our (albeit strict) bc policy for patch releases. Better to commit to 8.1.x and move on than have things potentially lost in the queue for months as those discussions often fizzle out at CNR. Also at least two recent patches caused regressions in 8.0.x despite being 'no API change' bug fixes so we do need to properly check every patch that goes into 8.0.x, given the monthly release cycle and the expectation of more stability than either 8.x minor releases or 7.x bug fix releases.

And regardless of that, plenty of commits are happening against 8.0.x:

8.x catch$ git log 8.1.x --pretty=oneline --since="3 months ago" | wc -l
     498
8.x catch$ git log 8.0.x --pretty=oneline --since="3 months ago" | wc -l
     377

8.x catch$ git log 8.1.x --pretty=oneline --since="1 month ago" | wc -l
     237

8.x catch$ git log 8.0.x --pretty=oneline --since="1 month ago" | wc -l
     152
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Status: Reviewed & tested by the community » Fixed

I can't see any reason not to fix this in 8.0.x as well. I just did a cherry pick. Committed b352a6c and pushed to 8.0.x. Thanks!

It is tricky for a committer to think of everything and when an issue is filed against 8.1.x. It is okay to commit only to that branch and for the community to then ask for it to be committed to another branch.

  • alexpott committed b352a6c on 8.0.x authored by catch 
    Issue #2662592 by marcingy: TimestampFormatter.php has invalid input...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.