Updated: Comment #1

Problem/Motivation

#1701014: Validate config object names limits the maximum file name length of a configuration object name to 250 characters.

Now we need to prevent situations where the individual parts of the configuration object filename (plus the periods that separate them) do exceed 250 characters.

The name of a file that contains the details for a configuration entity is composed of 3 parts.

$extension.$identifier.$machine_name

The $machine_name may itself be comprised of components; this complexity is determined by the config entity class that produces the machine name.

Here is the fully-expanded set of possibilities.

                        |------> Machine name - defined by config entity type
{extension}.{identifier}.{target entity type}.{target entity bundle}.{instance name}

In Core, we find these combinations:

{extension}.{identifier}.{target entity type}.{instance name}
{extension}.{identifier}.{target entity type}.{target entity bundle}.{instance name}
{extension}.{identifier}.{target entity type}.{target entity bundle}
{extension}.{identifier}.{instance name}

In order to maintain file names that are less than 255 characters, we need to limit the length of the components of the file name, so given the template

$extension.$identifier.$machine_name

we need to establish the following char length limits on each part:

50.32.128

Listed below is a complete set of examples for each config entity entity in core.

EntityViewMode, EntityFormMode and FieldConfig File Name Components

Config Entity Type api provider entity type ID target entity type -- instance name
view_mode entity .view_mode .node -- .search_result
form_mode entity .form_mode .user -- .register
field_config field .field .node -- .body

EntityViewDisplay, EntityFormDisplay and FieldInstanceConfig File Name Components


Config Entity Type api provider entity type ID target entity type target entity bundle instance name
entity_view_display entity .view_display .node .article .teaser
entity_form_display entity .form_display .node .article .default
field_instance_config field .instance .node .article .body

RdfMapping File Name Components

Config Entity Type api provider config_prefix target entity type target entity bundle --
rdf_mapping rdf .mapping .comment .node__comment --

All other Configuration entities File Name Components

Config Entity Type api provider config_prefix -- -- machine_name
node_type node .type -- -- .article
custom_block_type custom_block .type -- -- .basic
search_page search .page -- -- .node_search
user_role user .role -- -- .anonymous
block block .block -- -- .bartik_content
filter_format filter .format -- -- .full_html
image_style image .style -- -- .large
contact_category contact .category -- -- .feedback
editor editor .editor -- -- .basic_html
breakpoint breakpoint .breakpoint -- -- .theme.bartik.mobile
breakpoint_group breakpoint .breakpoint_group -- -- .theme.bartik.bartik
language_entity language .entity -- -- .en
responsive_image_mapping responsive_image .mappings -- -- .someName
shortcut_set shortcut .set -- -- .default
action system .action -- -- .node_unpublish_action
date_format system .date_format -- -- .html_date
menu system .menu -- -- .main
taxonomy_vocabulary taxonomy .vocabulary -- -- .tags
tour tour .tour -- -- .views_ui
view views .view -- -- .frontpage

The combination of these parts cannot exceed 250 characters. If they did, a site could break during upgrade, when a module is enabled, when configuration is imported, and various other scenarios.

Note: original discussion related to this problem occurred in #1186034: Length of configuration object name can be too small

The longest configuration name (found so far) in core is:

entity.view_display.node.12345678901234567890123456789012.1234567890123456789012345678901234567890123456789012345678901234

It's 122 characters long. This consists of provider ("node"), entity type ID ("view_display"), target entity type ("node"), target entity type bundle ("12345678901234567890123456789012") and display mode machine name ("1234567890123456789012345678901234567890123456789012345678901234").

In addition, language-specific configuration prefixes information to the existing configuration object file name, potentially making it too long. That issue is tracked here #2201437: [META-1] Config overrides and language.

Remaining tasks

Each part of a configuration object file name will get its own issue. Some parts are already length-limited.

Part Issue
api provider #1852454: Restrict module and theme name lengths to 50 characters
entity type ID/config_prefix #1862600: Entity type names/IDs are not properly namespaced by owner (e.g., taxonomy.term vs. taxonomy_term)
entity type/entity bundle #1709960: declare a maximum length for entity and bundle machine names
config entity machine name #2220757: Limit length of Config::$id to something <= 166 characters
composed config file name #1701014: Validate config object names

Additionally, we must determine how to migrate Drupal 7 data that exceeds these limits.

User interface changes

Certain admin UIs should indicated a maximum character limit. (Needs issues.)

API changes

Potentially

Comments

xjm’s picture

Issue summary: View changes

Updated issue summary.

xjm’s picture

Issue summary: View changes

Updated issue summary.

xjm’s picture

Issue tags: +Entity Field API
xjm’s picture

Issue summary: View changes

Updated issue summary.

xjm’s picture

Issue summary: View changes

Updated issue summary.

xjm’s picture

Issue summary: View changes

Updated issue summary.

yched’s picture

Tricky - many config entities (including 3rd party / contrib config entities) put bundle names in their CMI files, and rename them on the fly if a bundle gets renamed.
So how would we validate the "change node type machine name" form and pre-check that the proposed rename won't cause any filename to go overboard ?

yched’s picture

Issue summary: View changes

Updated issue summary.

andypost’s picture

Priority: Normal » Major
Issue tags: +beta target

Added a bit more child issues, also this actually major target for beta!

xjm’s picture

Priority: Major » Critical
Issue tags: -beta target +beta blocker

Discussed with @alexpott; this needs to block beta.

jhodgdon’s picture

Coming here from #1425622: Increase length of 'type' field in search_dataset, search_index tables from 16 to 64, which was marked as a child issue recently...

What "sensible" limit are you proposing to use for the length of a plugin ID?

xjm’s picture

Issue tags: +Naming things is hard
jessebeach’s picture

Issue summary: View changes
jessebeach’s picture

Issue summary: View changes
jessebeach’s picture

alexpott’s picture

Issue summary: View changes
jessebeach’s picture

Issue summary: View changes
jessebeach’s picture

Issue summary: View changes
jessebeach’s picture

Issue summary: View changes
jessebeach’s picture

jessebeach’s picture

Issue summary: View changes
jessebeach’s picture

Issue summary: View changes
jessebeach’s picture

Title: [META] Create sensible limits for the maximum length of configuration object filename components » [META-4] Create sensible limits for the maximum length of configuration object filename components
alexpott’s picture

Issue summary: View changes

Found a longer name!

entity.view_display.comment.node__field_02345678901234567890123456.1234567890123456789012345678901234567890123456789012345678901234

131 characters

And created #2220739: Custom block types can be 64 characters long but the custom_block only supports 32

Berdir’s picture

See #2220757-1: Limit length of Config::$id to something <= 166 characters for a problem with the fixed length limitations per component approach. Not saying that I have a better idea...

xjm’s picture

Awesome info in the summary!

jessebeach’s picture

jessebeach’s picture

Issue summary: View changes
jessebeach’s picture

Title: [META-4] Create sensible limits for the maximum length of configuration object filename components » [META-3] Create sensible limits for the maximum length of configuration object filename components
xjm’s picture

50 + 32 + 128 = 210; what happened to the other 40 characters? :)

Berdir’s picture

As mentioned by @alexpott in IRC, we need some free room, for example for the language prefix, so that we can prepend language.config.LANGCODE to every config file. There are discussions for making that a subfolder, but we also need to cache the language overriden config files and the cache key is limited to 255 characters as well.

In short, the fewer characters we can safely limit it to, the better :)

xjm’s picture

I thought making language prefix a folder was a done deal? And where is the cache ID length issue? @alexpott has mentioned this several times but I don't see it listed here.

128 seems really tight (e.g. WRT to comment bundles, as you've mentioned in IRC).

xjm’s picture

And couldn't we also just hash the cache keys or something?

Berdir’s picture

Possible (re folder). Would the same then apply to domains, for example?

We could probably hash it, yes. We would have to use cache tags for mass deletion anyway, so doesn't matter if it's hashed or not.

Comment bundles could be a problem with the length if we let them violate the 32 char bundle length limit. I've been thinking a bit more about it and it would actually have to be a lot more than that to be a problem for this issue, the nice thing is that comment bundles obviously only exist for comment entities, so they only use 7 of the 32 characters they're "allowed to" for the entity type, which gives us 25 "overflow" characters for comment bundles. so for example for a field instance: 128 - 8 (comment.) - 34 (attached_entity_type__) - 33 (.field_name) still leaves us with 53 characters, which is more than enough for another 32 character field name.

So unless I'm missing something, we're good there..

However, we might have a slight problem with the fact that we have 50 character extension limit but only 32 for entity types and bundles. It's common to prefix entity_types and bundles with the module name. That would not be possible if you have an extension that is more than 32 characters, obviously. And I don't think #1862600: Entity type names/IDs are not properly namespaced by owner (e.g., taxonomy.term vs. taxonomy_term) would help, because we still need to reference the fully namespaced entity type in the field/entity config entities.

That said, we could also say that when you create 50 character extension names (for modules that provide entity types/bundles) then you deserve what you get ;)

jessebeach’s picture

Title: [META-3] Create sensible limits for the maximum length of configuration object filename components » [META-2] Create sensible limits for the maximum length of configuration object filename components
xjm’s picture

Title: [META-2] Create sensible limits for the maximum length of configuration object filename components » [META-3] Create sensible limits for the maximum length of configuration object filename components
zserno’s picture

Title: [META-3] Create sensible limits for the maximum length of configuration object filename components » [META-2] Create sensible limits for the maximum length of configuration object filename components
jhodgdon’s picture

So.. One of the child issues here is #1425622: Increase length of 'type' field in search_dataset, search_index tables from 16 to 64

I'm trying to figure out what the right limit is there... it's not directly related to config, but indirectly, and I can't figure out from this issue summary or the child issues (at least, not easily) what the limits should be.

In that issue, we need to fix the length for a database column that probably will store a plugin ID string (for the search plugin ID), or a unique identifier for a search page config entity.

What are the limits for each of these?

Berdir’s picture

@jhodgdon: That is up to you. This issue only mandates that the config entity ID's are never over 166 characters. We don't care about plugin id length apart from entity types, and as long as you ensure that all (possibly composite like entity_type.bundle.fieldname) IDs are below that, the config system doesn't care.

We only special case entity_type IDs and bundles because they are known components of the IDs of a set of config entity types (fields/displays), so we want to ensure upfront that it will be possible to add fields to them and so on.

That said, 16 seems pretty short, it might be a good idea to at least allow as much as entity_type's support (32) or even 64, to ensure that modules with (close to) 50 characters can define a plugin implementation within their namespace.

zserno’s picture

Title: [META-2] Create sensible limits for the maximum length of configuration object filename components » [META-1] Create sensible limits for the maximum length of configuration object filename components
catch’s picture

Memcache runs strlen on cache keys and hashes if they're longer. So that's definitely an option and we can consider implementing a similar thing in the core database backends.

jhodgdon’s picture

I just added comments on a couple of sub-issues here, but... Is all of this stuff really related to counts of characters or counts of bytes or both? Can you even use non-ascii characters in any of these machine names -- I'm not sure?

Berdir’s picture

As commented in the entity_type issue, it is always characters. What characters are allowed is a different question, but identifiers like those are usually "machine names", aka lower case alphanumeric + _-., depending on the use case.

effulgentsia’s picture

Looks like #1709960: declare a maximum length for entity and bundle machine names is the only child issue that's a beta blocker, but this issue has other child issues that aren't. Seems like we should either make all child issues beta blockers, or make this meta issue not one. Which is it?

Berdir’s picture

One child issue is about improving documentation of some constants, not a beta blocker, the search issue is not a blocker either, bor is the requirements one.

I think it's really just #1709960: declare a maximum length for entity and bundle machine names. Once that is in, we have the rules and basic validations in place to ensure the limits are kept. The views name issue might simply be a bug now that should be fixed but not a beta blocker IMHO, just like anything else that would then allow to create configuration objects that break the limits.

effulgentsia’s picture

Issue tags: -beta blocker

Ok then. Removing the beta blocker tag, since that's already on the one and only beta blocking child issue.

xjm’s picture

@berdir, I think you filed an issue last week for the cache keys? Can you add it here?

Berdir’s picture

xjm’s picture

catch’s picture

Isn't this done? All the open issues look like general follow-up to me.

Berdir’s picture

Status: Active » Fixed

Yeah, I think so too, all remaining issues are just related but not sub-issues of this meta.

Berdir’s picture

Title: [META-1] Create sensible limits for the maximum length of configuration object filename components » [META] Create sensible limits for the maximum length of configuration object filename components

Status: Fixed » Closed (fixed)

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