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
Related Issues
- #1852896: Throw an exception if a schema defines a key that would be over 1000 bytes in MySQL
- #2100203: Make config entities use dots in machine names consistently
- To be filed? The config entity prefix should only consist of the current domain-specific second half (e.g. "instance") and the owner module (e.g. "field") should be enforced in validation as the first part of the object name.
Comments
Comment #0.0
xjmUpdated issue summary.
Comment #0.1
xjmUpdated issue summary.
Comment #1
xjmComment #1.0
xjmUpdated issue summary.
Comment #1.1
xjmUpdated issue summary.
Comment #1.2
xjmUpdated issue summary.
Comment #2
yched CreditAttribution: yched commentedTricky - 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 ?
Comment #2.0
yched CreditAttribution: yched commentedUpdated issue summary.
Comment #3
andypostAdded a bit more child issues, also this actually major target for beta!
Comment #4
xjmDiscussed with @alexpott; this needs to block beta.
Comment #5
jhodgdonComing 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?
Comment #6
xjmComment #7
jessebeach CreditAttribution: jessebeach commentedComment #8
jessebeach CreditAttribution: jessebeach commentedComment #9
jessebeach CreditAttribution: jessebeach commentedComment #10
alexpottComment #11
jessebeach CreditAttribution: jessebeach commentedComment #12
jessebeach CreditAttribution: jessebeach commentedComment #13
jessebeach CreditAttribution: jessebeach commentedComment #14
jessebeach CreditAttribution: jessebeach commentedComment #15
jessebeach CreditAttribution: jessebeach commentedComment #16
jessebeach CreditAttribution: jessebeach commentedComment #17
jessebeach CreditAttribution: jessebeach commentedComment #18
alexpottFound a longer name!
131 characters
And created #2220739: Custom block types can be 64 characters long but the custom_block only supports 32
Comment #19
BerdirSee #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...
Comment #20
xjmAwesome info in the summary!
Comment #21
jessebeach CreditAttribution: jessebeach commentedComment #22
jessebeach CreditAttribution: jessebeach commentedComment #23
jessebeach CreditAttribution: jessebeach commentedComment #24
xjm50 + 32 + 128 = 210; what happened to the other 40 characters? :)
Comment #25
BerdirAs 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 :)
Comment #26
xjmI 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).
Comment #27
xjmAnd couldn't we also just hash the cache keys or something?
Comment #28
BerdirPossible (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 ;)
Comment #29
jessebeach CreditAttribution: jessebeach commentedComment #30
xjmWe still have three here I think:
#2220749: Limit $extension.$(config_prefix/entity_id) combo value to 83 characters (82 plus a '.') as part of a 250 character limit on config entity file names
#2220757: Limit length of Config::$id to something <= 166 characters
#1709960: declare a maximum length for entity and bundle machine names
Comment #31
zserno CreditAttribution: zserno commentedWe're down to 2 since #2220749: Limit $extension.$(config_prefix/entity_id) combo value to 83 characters (82 plus a '.') as part of a 250 character limit on config entity file names got committed yesterday:
Comment #32
jhodgdonSo.. 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?
Comment #33
Berdir@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.
Comment #34
zserno CreditAttribution: zserno commented#2220757: Limit length of Config::$id to something <= 166 characters just got committed, so only one left:
#1709960: declare a maximum length for entity and bundle machine names
Comment #35
catchMemcache 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.
Comment #36
jhodgdonI 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?
Comment #37
BerdirAs 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.
Comment #38
effulgentsia CreditAttribution: effulgentsia commentedLooks 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?
Comment #39
BerdirOne 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.
Comment #40
effulgentsia CreditAttribution: effulgentsia commentedOk then. Removing the beta blocker tag, since that's already on the one and only beta blocking child issue.
Comment #41
xjm@berdir, I think you filed an issue last week for the cache keys? Can you add it here?
Comment #42
BerdirYou mean #2224847: Automatically shorten cid's in Cache\DatabaseBackend and PhpBackend? Could use a review :)
Comment #43
xjmYes, that one!
Comment #44
catchIsn't this done? All the open issues look like general follow-up to me.
Comment #45
BerdirYeah, I think so too, all remaining issues are just related but not sub-issues of this meta.
Comment #46
Berdir