Contrib.social

Notice: Undefined index: [suffix|prefix] in FractionDecimalWidget

Open on Drupal.org →
Created on 24 October 2023, over 1 year ago

Problem/Motivation

Continuing on from needing to ✨ Use batching for post update functions Closed: won't fix , sites with old Fraction fields will encounter the following php notices as the field did not previously have the min, max, prefix or suffix keys set in settings. The code in core and in Fraction assumes that these keys exist without any checks.

Viewing or editing an entity with an old and now updated Fraction field results in an error message like this:

Notice: Undefined index: prefix in Drupal\fraction\Plugin\Field\FieldWidget\FractionDecimalWidget->formElement() (line 99 of /[path]/web/modules/contrib/fraction/src/Plugin/Field/FieldWidget/FractionDecimalWidget.php)
Notice: Undefined index: suffix in Drupal\fraction\Plugin\Field\FieldWidget\FractionDecimalWidget->formElement() (line 103 of /[path]/web/modules/contrib/fraction/src/Plugin/Field/FieldWidget/FractionDecimalWidget.php)

Viewing the field settings will give an error message such as:

Notice: Undefined index: min in Drupal\Core\Field\Plugin\Field\FieldType\NumericItemBase->fieldSettingsForm() (line 35 of /[path]/web/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/NumericItemBase.php)
Notice: Undefined index: max in Drupal\Core\Field\Plugin\Field\FieldType\NumericItemBase->fieldSettingsForm() (line 41 of /[path]/web/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/NumericItemBase.php)

Saving the field settings clears up the issue, but an automated method helps.

Again, probably relegated to the "maybe later" pile, but maybe it'll help someone else out too.

Steps to reproduce

Update the Field Instance Configs for each of the Fraction fields.

Proposed resolution

Add a post-update function to re-save the Field Instance Configs, which automatically fixes the problem by merging in default settings during the pre_save method.

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

🐛 Bug report
Status

Active

Version

2.0

Component

Code

Created by

🇦🇺Australia elc

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @elc
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 8.1 & pgsql-13.5
    last update over 1 year ago
    21 pass, 2 fail
  • @elc opened merge request.
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 8.1 & pgsql-13.5
    last update over 1 year ago
    23 pass
  • Status changed to Needs review over 1 year ago
  • Comment over 1 year ago →
    🇦🇺Australia elc

    For anyone else upgrading an old D8 site, update to Fraction 2.1.0 to run the post-updates from 2.x:HEAD modified by 3393104, with this MR appended to the end. This means you can get the schema fully upgraded and site ready for upgrade to D9.

    @m.stenta If you keep anything, the change to the batching of the update function during testing would be a wonderful addition.

  • Status changed to Closed: won't fix 3 months ago
  • Comment 3 months ago →
    🇺🇸United States m.stenta

    @elc thanks for this contribution! Sorry that I didn't get to it sooner. However, I think I am going to close it as "won't fix" for the same reason as ✨ Use batching for post update functions Closed: won't fix :

    However, because this is a significant change, and it changes an update hook (which only affects a very limited set of users), and the original issue is "fixed" for (hopefully) most users, and the number of users on 8.x-1.x is limited and dropping (according to usage statistics), and I do not have the time to review and test it thoroughly myself, from a maintainer's perspective I'm inclined to just leave this MR as an option for others who need it, but close this issue as "won't fix".

    That said, if someone else runs into the same problem (hopefully not!), and they dig in and discover this issue, and they contribute some time to review and test it (to get another perspective and context as a form of due-diligence), then we can reopen and merge it. Does that seem fair?

    Credit where credit is due! Simply opening this issue and contributing the MR is a huge contribution! Thank you again!

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024