Problem/Motivation

This error happens because when adding the field in the entity the field "Range" has the type as textfield and it means that the user can put any value there and not only "numbers" so the editors can put letters, special chars, etc.
If the content editors put any value there different than numbers it's definitely a content issue but I think we can use the field type "number" instead of "textfield" and this error will be avoided

Steps to reproduce

  1. Access: "Structure" » "Content types" » Basic Page » "Manage fields" » "Add field" ( /admin/structure/types/manage/page/fields/add-field )
  2. Select "General" » "Weight"
  3. On "Range" field put letters only, example: "asdfg"
  4. Save
  5. Access: /node/add/page
  6. Result:
  7. TypeError: Unsupported operand types: string * int in Drupal\weight\Plugin\Field\FieldWidget\WeightSelectorWidget::rangeOptions() (line 44 of /app/web/modules/contrib/weight/src/Plugin/Field/FieldWidget/WeightSelectorWidget.php).

Proposed resolution

Update the #FormAPI on "Range" field to use fieldtype as "number". It'll fix the root cause because the editor will be forced to select a number

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork weight-3343538

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

RenatoG created an issue. See original summary.

RenatoG opened merge request !9

renatog’s picture

renatog commented
Status: Active » Needs review

MR open with the fix: https://git.drupalcode.org/project/weight/-/merge_requests/9

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented

Could we get a test showing the failure and a fix? This is a new module to me, and I'm not aware of all the edge cases where text field input might actually be desired.

renatog’s picture

renatog commented

@heddn Just to confirm as a double-check, do you mean, automated tests with PHPUnit that's right?

If yes, I think really makes sense

I was thinking to open this in a separated issue, with that we can fix this issue and work in the PHPUnit separated, what do you think?

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Status: Needs review » Needs work

Adding the test w/ the fix is the better approach as it shows what is at issue and proves we fix things. I'm mainly proposing this since as a new maintainer, I want to be overly cautious about breaking existing sites. And adding test coverage helps here.

renatog’s picture

renatog commented
Issue tags: +Needs tests

Makes sense

So adding the tag