Increase textfields maxlength

[stefan-korn]

User Story

Due to core's kind of strange implementation of Textfield any textfield receives maxlength of 128 chars by default.

There is some discussion about clearing/changing this: https://www.drupal.org/project/drupal/issues/3331028

For DKAN any standard schema property of type string will also receive this maxlength of 128 chars. This seems kind of limiting and for no real value. I came across this, while harvesting datasets with strings longer than 128 chars and this is fine, but then when editing the dataset the maxlength will kick in.

As far as I can see there is no option to change this via schema(.ui) properties because the default string field will not go through Widget Router. The place where an increase of maxlength could be integrated would be handleStringElement.

What do you think about this?

• nothing to care in DKAN, either wait for core to change this or change it yourself on a general base?
• change it to something fixed like "256" in DKAN
• make it configurable in DKAN via some schema(.ui) attribute

Acceptance Criteria

(be able to) increase maxlength on default string textfields

[dafeder]

@stefan-korn yeah this is a good point. Hmm. Since this field is used for URLs 128 does seem very stingy. What do we think of

1. Setting the maxlength by default to be 512, which seems likely to accommodate most URLs someone would be using here. Alternatively, is there a way to explicitly set no maxlength, like set it to zero or null? I can't find any reference to this in the docs.
2. Having handleStringElement look for a maxlength property in the schema and apply that instead if present.

I don't know that I think we should make this settable in the UI schema. UI schema is supposed to extend what can be inferred from the schema itself, not prevent input that would otherwise be allowed by the schema, or override limits that are present in the schema. We generally try to follow the model of react-jsonschema-form and they do not allow setting maxlength via ui schema.

[dafeder]

cc @paul-m who I think has been active in the Drupal core issues about this

[stefan-korn]

@dafeder : You surely know, but if you set schema property "format" to "uri" for a string field, the maxlength will increase to 255. That is because the JSON Form widget uses a drupal "url" form element then (same for pattern property which translates to email form element).

So urls are not direcly related to this issue, only plain text fields. But if you want to extend it even to 512 then "uri" has to be tackled too.

[dafeder]

Actually missed that, thanks for the clarification. 256 is probably still plenty for 99% of use cases, maybe let's just start with that as the default for all textfields?

[stefan-korn]

How about PR #4168. This would increase the limit just for "textfield" elements provided by JSON Form widget.

[stefan-korn]

maybe leave a hint or ToDo pointing to https://www.drupal.org/project/drupal/issues/3331028 in the code comments?

[stefan-korn]

@dafeder : While fixing the tests in #4168 I came across ArrayHelper. There is buildSimpleArrayElement which builds a texfield without maxlength too. Not sure if maxlength should be set there too?

[stefan-korn]

@dafeder : I changed the place of injecting maxlength from StringHelper to WidgetRouter. Injecting in StringHelper is problematic, because the WidgetRouter might change the type "textfield" to something else, i. e. Date Time widget and there the maxlength is causing trouble. Therefore injecting maxlength only after the WidgetRouter has done its changes and the type is still textfield.

[stefan-korn]

Hm, this is way more complex than I have thought. ArrayHelper and ObjectHelper together with the "add one" button do their own thing in some way.

I'm now tending to solve it for our project on a general base with hook_element_info_alter for all textfields regardless whether they are from JSON Form Widget or anywhere else.

[dafeder]

Hmm that is unfortunate... I will have to take a closer look at what's happening. I'd be open to bringing this in if it addresses the problem in most places and has test coverage and documents remaining open issues. But maybe needs a higher-level refactor to properly fix?

[stefan-korn]

Yes, maybe some refactoring would help to solve it in the JSON Form Widget. Probably it will have to happen in the StringHelper, but then in the WidgetRouter one would need to remove the maxlength for those widgets that are changing the type again. I tried to avoid this, because this is kind of a trap when implementing new widgets for example. But since the fields without a widget do not touch the WidgetRouter, it cannot be solved directly in the WidgetRouter.

And above mentioned buildSimpleArrayElement should probably also go to StringHelper and not directly provide the textfield type.

But surely it is questionable if it is worth the effort, when core maybe changes this later on.

But from JSON Form Widget point of view, there would be no maxlength necessary at all, since everything is stored in the JSON field. So maybe the other way round, just kicking maxlength out (as you have mentioned above and I have not noticed until now) might be a better approach. Still this is also not straightforward I am afraid.

[stefan-korn]

@dafeder : There is another issue that arises in this context, but not related to textfields maxlength directy.

The base field filePath of ResourceMapping entity is defined as a string field, resulting in database length of 255 chars for this field. DKAN D7 allowed for such a URL to have length of up to 2048 chars. So if you do a harvest from a DKAN D7 instance you may end up in an error during the harvest if the source URL is longer than 255 chars.

I suppose changing the base field definition to "uri" instead of "string" would solve this on the harvesting side without having any side effects hopefully. It would allow to harvest a long URL and it would also not get lost during saving the dataset.

Though it would still not be possible to enter a URL longer than 255 chars via the UI because maxlength of the textfield is still 255 chars.

What do you think? Should I create a separate issue for the change in the ResourceMapping entity?

[dafeder]

@stefan-korn sorry just caught this last comment. Yes that makes sense. Feel free to make a new issue for it/submit a PR.

I'm revisiting your PR here, I think it would be worth doing a fix like this even if there are still remaining issues.

[dafeder]

See PR comments, I am going to make my own attempt at a solution to this elsewhere in the module.

[dafeder]

@stefan-korn ok tried again implementing via stringhelper and then adding an unset when needed to overwrite with other widget types, that seems reasonable. Let me know what you think. It seems to trickle down into objects and arrays as well but haven't tested that quite as extensively yet.