Increase or remove default textfield #maxlength=128

Implemented the 4 options a - d as example MR's. I'd tend to choose a or b and I think the limit of 128 characters never should have been introduced after Drupal 7 with configuration.

As next step it should be discussed which way to go with which risks, eventually BC's (= core target version) etc. The MR's are just examples to show possible ways. Would be nice to have core maintainers feedback here.

I'd agree with either solution a) or b), where setting the limit to 256 would be more explicit, as you wouldn't usually need a higher char count for labels etc. anyway. But removing the maxlength entirely could help with the remaining 1% needing a higher char count.

So if it wouldn't have any negative side effects, I'd vote for solution a), otherwise b).

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened → , as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Out of interest I looked through git history and found that we set maxlength to 128 for textfields in #35644: Change defaults on form elements to most common values → - previously it was an arbitrary value of 70 instead.

I am not sure what the best option is here. I don't really like any of them except the simplest one: remove the default maxlength entirely - but I also share the BC concerns. There is definitely a risk of introducing bugs if we just drop the length, because of things like database column lengths.

We could (in theory) deprecate it by detecting when it's not set, warning users that #maxlength default will change in the next major, etc, but is it worth it? I am not entirely sure of the benefit of changing it now given that form API elements can just override this value if they need to.

Adding framework manager review tag to get more visibility on this.

Thanks for the feedback @longwave. I shouldn't repeat myself, as I already wrote those points into the issue summary, but as short reply to your comment

1. I think this limitation is simply unexpected from a framework. When using an input field without providing a #maxlength you may not even think about (or try) there's such a limit. That's my a framework shouldn't do it in my oppinion.
2. Currently, I only see a potential risk for database schema, config schema doesn't seem to have (any) limits. If we can split these and apply a limit only to database forms or protect them in any other way, that would unblock this limitation
3. It leads to real issues in forms like the core-provided translation forms, where the input is shorter than the original field, see 🐛 Cookies Service Input fields limit text length too short Fixed
4. I think it mainly has historic reasons, and we should take the steps to remove it. If not possible, we should at least increase the limit further to 256 characters so it's even more unlikely that people run into it, but I think it still wouldn't be the right way. But better :)

I faced that issue in an views exposed filter on an entity reference field using the autocomplete widget.
One of my users tried to search for a referenced entity which title is 138 chars long (+ double quotes and ID between parenthesis). The autocomplete works well and the field is filled when selecting the right result but after submitting the form, they gets an error and no results.

Thinking about the deprecation, I'm not sure we can do that, unless we want to force everyone to set a maxlength, otherwise there's no way to remove the deprecation message for modules that don't want it set.

There is definitely a risk of introducing bugs if we just drop the length, because of things like database column sizes being overflowed where previously this was not possible.

This is true but I feel like for entities this would already be a problem due to JSON:API. The database will either truncate the value or throw an exception, the exception could be jarring, but it would only be for someone who previously would not have successfully submitted that form with the same values.

I think this is probably OK to do in a minor release, but with quite a loud change record/release note.

It's also the sort of thing we could make 'major version only', generally we've avoided that as much as possible, but this might be a case where that would work.

Ok we shouldn't try to change the MR to 11.x ;D
This should be just fine and patchable ...

I am doing triage on the core RTBC queue → .

I read the issue summary and the most importantly the proposed resolution is a set of options. I then read the comments to figure that out. The comment that set this to RTBC supported 2 of the options. Since that is not clear I am tagging for an IS update and setting to NW.

In #15 catch asked for a CR. I am adding that tag. Of course, that shouldn't be made until this has a definite resolution. He also considered that this might be done in a major release. Therefor, I am tagging for RM review as well.

I am setting to NR for discussing and selecting the option to implement.

For the issue summary update and change record.

Let's simply elevate the max length to 256. This should be enough. Removing it entirely might have further consequences.

So MR !4005 should be the final approach here. I can not close the other MR's, maybe @Anybody is able to do that.

According to the discussion here, we should proceed with MR !4006 as @catch confirmed the approach in #15.

I'll create the change record.

Marked the approaches we probably won't take as "Draft". Maybe useful for a follow-up or discussions. Feel free to close otherwise.

Ok, I created a Change Record → ! Back to "RTBC".

Issue summary updated. Waiting for Needs framework manager review, Needs release manager review now!

1 test fails.

OK, the last failing test is simply an unrelated racing condition problem. I don't think, this should be fixed in this issue, as it is completely unrelated.

Setting this back to "Needs work" as I don't think any core maintainer would commit an MR containing failed tests. Maybe someone can help with 🐛 testCreateViewWizard fails, when removing the "#maxlength" property of the textfield form element Needs work . I have no idea, what makes the test fail and can not reproduce it through manual testing.

Alright, back to needs review! Special thanks to @lendude, who provided the "_populate" fix on Slack! Thanks again! 👍
Please credit him manually!

Pipeline is green! https://git.drupalcode.org/issue/drupal-3331028/-/pipelines/39305

Back to RTBC! :)

Anybody → closed merge request !4007

Anybody → closed merge request !4006

Anybody → closed merge request !4005

Are there any existing forms in core (entity labels? Machine names?) where we might be relying on the default 128 #maxlength and need to add an explicit value in those forms?

@catch: Any ideas how we can be sure about that?

Looking at this: https://git.drupalcode.org/search?search=%23maxlength&nav_source=navbar&...
it seems there are at least many cases where peolple added the value, where it was needed!

An important example you made: Machine names:
https://git.drupalcode.org/issue/drupal-3331028/-/blob/3331028-increase-...

So I think we should ensure this is safe wherever possible, but on the other hand things won't get better, if we wait longer to "fix" this. Happy to help if anyone has further ideas how to be even more safe!

@Anybody can we look at core usages of #type 'textfield' where it doesn't have #maxlength?

Following up @Anybody if you had a chance to look at #37.

@smustgrave thanks for the ping, I didn't forget this, but currently can't take the time. Open for anyone, sorry.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I did a search in core (granted, it was 10.2), for '#type' => 'textfield',, and stopped counting at 10 when I found files that rely on the default value.

Also, it seems like relying on the default value is kind of OK, which is why it's there.

Config offers a schema constraint of Length.max, so it seems like a config form would use that value if it's present, only using the form element default if there was no such constraint. Ideally this would happen in some automatic or semi-automatic way to make it easy to build config forms. Maybe as a method on ConfigFormBase that does magic for you.

It seems like there would be some other issue where this is happening, but I don't see it, other than in initiatives to make sure all config has constraints: 🌱 [meta] Add constraints to all config entity types Active It also seems like it would slot right into this CR's purpose: https://www.drupal.org/node/3373502 →