• When staging configuration between sites, modules do not know whether a configuration object might have been renamed.
  • There is no guarantee that an identical config object name/machine name already exists on the target site into which configuration is imported.


  • Make configuration objects unique to ensure a rock solid support for staging configuration.


  • This only affects Configurable Thingies™; i.e., configuration objects that represent 0-N instances of certain configuration entity types, which are managed (created/edited/deleted/renamed) by site administrators.

    "Static/non-dynamic" config objects are not affected (e.g., settings).

  • Configuration objects need to be queried/looked up when they are imported on another site; e.g., when they are staged from dev to production. In this process, the import mechanism needs to be 100% sure that the imported configuration object is exactly the identical object that it is going to alter/update. Machine names are NOT unique. They are only singular within the scope of a single site.

  • We will definitely add (and enforce) UUIDs to configuration entities as a standard 'uuid' key within config objects. However, there is no "grep" mechanism in the configuration storage controller design (nor in any generalized/abstracted key/value store concepts), so baking UUIDs as keys/properties into config objects doesn't really help with the essential problem space of lookups.

    I.e., if there would only be UUID as properties within config objects, then the import mechanism would have to load all config objects of a certain entity type in order to figure out whether the UUID corresponding to the object it is importing is really the config object that it claims to be.

  • The idea of just naturally leveraging UUIDs inherently resolves a full stack of foreseeable config import/staging problems, which are neither covered in HEAD, nor filed in any issues, and not leveraging them will keep us busy (as in: busy) for several months. Given the current state of the system, it is quite predictable that we'll run into the major bugs and flaws being caused by not leveraging UUIDs only after releasing D8, so in turn, we'll very potentially fail to deliver the goal of a rock solid configuration system that supports to move configuration across systems.

  • The entire idea of asking humans to "enter a machine name" in administrative UIs is utter nonsense to begin with, and we're going to let a unique chance pass to eliminate that WTF.

    The architectural impact of this goes way beyond the configuration system. Machine names are only used for Configurable Thingies™. Eliminating them means to eliminate (most of) this entire queue of issues. — Getting rid of all of that at the "cost" of non-human-readable config file names would only make sense.

Proposed solution

  1. Replace machine names in config object [file] names with UUIDs; i.e.:




  • Yes, this "removes" human-readability of config object/file names.

Related issues

Original summary

From #1447686: Allow importing and synchronizing configuration when files are updated:

+++ b/core/modules/image/image.module
@@ function image_config_sync
  foreach ($config_changes['deleted'] as $file_name) {
    if (strpos($file_name, '') === 0) {
      // The style has been deleted, so read the previous configuration from the
      // old storage.
      $style = $target_storage->load($file_name)->get();

      // @todo image_style_delete() supports the notion of a "replacement style"
      //   to be used by other modules instead of the deleted style. Good idea.
      //   But squeezing that into a "delete" operation is the worst idea ever.
      //   Regardless of Image module insanity, add a 'replaced' stack to
      //   config_sync()? And how can that work? If an 'old_ID' key would be a
      //   standard, wouldn't this belong into 'changed' instead?
      $style['old_name'] = $style['name'];
      $style['name'] = '';
      module_invoke_all('image_style_delete', $style);


sun’s picture

Actually, the super most proper way to do this is to unconditionally add UUIDs to all config objects.

Jose Reyero’s picture

What about some old style function and hooks?

function config_rename($old_name, $new_name);

function hook_config_rename($old_name, $new_name);

function hook_config_image_style_rename(..);
sun’s picture

Title:Modules need to be able to react to renamed configuration object names (not data within)» Modules don't know whether a config object name (not data within) was renamed during imports
Priority:Major» Normal

This is about importing configuration, in which case there are only 1-2 config objects, and so modules don't have any idea that was before.

Sorry if that wasn't clear. Clarifying issue title. Will try to clarify the summary as well.

Lastly, as long as not more Configurables are converted and especially as long as fields are not converted, this shouldn't block other issues from getting in, so demoting priority. It will become major/critical as soon as that's the case though.

sun’s picture

Issue tags:+UUID
sun’s picture

Issue summary:View changes

Updated issue summary.

sun’s picture

Title:Modules don't know whether a config object name (not data within) was renamed during imports» Configuration objects are not unique
Category:task» bug

I've rewritten the issue summary, incorporating considerations from many related issues.

Also clarifying the issue title. This is a major bug IMHO.

heyrocker’s picture

It has already been well established at #1703168-27: [Meta] Ensure that configuration system functionality matches expected workflows for users and devs and the followups that UUID named config objects are not an appropriate solution, so while I agree that this is a problem that needs to be solved, that solution needs to be shelved and other options discussed.

sun’s picture

With due respect, the one and only counter-argument that came up was the human-readability of config file names.

Comparing that single argument against the full stack of problems that would be just simply solved without any further code and actions, that argument appears absurd and a bit ridiculous to me. Sorry, I know this sounds slightly offending, but it's really tough to not put it that way.

Especially given the remaining timeline for D8, and given that we're not even in a state in which we're actually confronted with the uniqueness problems I'm hinting at, I fail to see how and when we're going to "solve" this problem differently.

Fact is, by not leveraging UUIDs in the way proposed, we will have to invent and add a shitload of code that tries to handle and ensure uniqueness in import/staging scenarios.

Furthermore, it is already clear that a couple of problems scenarios just simply cannot be resolved by any amount of code and additional logic we might be thinking of.

Taking all of that into account, it appears just simply illogical to not use an industry standard that was designed for exactly this purpose, and which requires zero extra support code/logic to properly and reliably handle all possible scenarios.

Lastly, I think we're vastly over-estimating the amount/change/frequency and use-case of developers that will actually look into the configuration files. Additionally, there can happily be helper tools (either directly in core or via drush) to produce information for whatever (yet unknown) direct file lookup use-case that's being criticized.

yched’s picture

Even regardless of CMI filenames and the impossibility to review the scope of changes through "git st / svn st", which is a massive turn off to me as well, I don't see how we can get rid of machine names DX wise :

E.g in the case of field names - who wants to code business or template logic on fields that way :

$node->4bd1c937-f530-456f-a218-241d7bfd40b8 ?
render($content['4bd1c937-f530-456f-a218-241d7bfd40b8']) ?
field--4bd1c937-f530-456f-a218-241d7bfd40b8.tpl.php ?
$result = new EntityFieldQuery()->fieldCondition('4bd1c937-f530-456f-a218-241d7bfd40b8', 'value', 0)->execute ?

Similar for views, I have sites with a shitload of code that renders a given display in a given view. When looking over a piece of code, I need to tell which view it is, not possible with UUIDS.

Bottomline is : machine names are not there only for machines (which, if you will, could very well do with UUIDs), they are there also for code written/read by humans. And CMI file names are only one tiny aspect of it.

So, big -1 from me as well for removing 'human readable' machine names.
Which, in the case at hand, leaves us with, what ? A lookup registry between CMI filenames and UUIDs they enclose ?

yched’s picture

Also - about unicity :
Doesn't a pattern of image.styles.[style_machine_name].yml ensure the unicity of style_machine_name as an image style name within a given config set ? I mean, there cannot be two files with the same name.

AFAIK, the issue is, when importing a new version of, is it really the *same* image style being updated, or is it a delete / create new ? (ok, bad example, image styles don't really care I think, but fields will).
But this can be handled by looking up (by name) existing and imported image style, and see if the enclosed UUIDs match, right ? No need to have the UUID in the file name ?

Are we having other potential issues in mind ?

heyrocker’s picture

Remember too that in a lot of cases, UUIDs are reused as CSS class names. This means designers and themers will have to navigate that and have UUIDs in their CSS and the like.

Jose Reyero’s picture

I share @yched and @heyrocker's concerns and also as a programmer I wouldn't be confortable with needing to use an UUID in code at all. That names are also used for URLs btw.

I think however that UUIDs may have some place in configuration though they belong to a different level of the stack. We can have UUIDs on top of human readable machine names so they can be used by deployment systems. I mean we can have UUIDs stuck into config data, as one more property then they can be used by deployment systems to check whether it is the same object renamed or a different one but no one else needs to even see them. Or we can have UUIDs as an aditional colum in the config table so you can always do the mapping while not needing to read and write them all the time.

beejeebus’s picture

is there an issue for adding UUIDs to config objects? i'd be happy to hack on a patch for that if i new where i should do the work, and if i knew i wasn't duplicating (see what i did there) others work.

sun’s picture

Assigned:Unassigned» sun


#1668820: Concept, base class, and interface for Configurables (e.g., node types, image styles, vocabularies, views, etc) introduced the infrastructure for (automatically) adding UUIDs to all (dynamic) config objects that need them. "Static" config objects (like simple module settings) don't need UUIDs.

The general idea is that everything that is using Configurables automatically gets proper UUID support and thus proper import/export/staging support. (Further discussions at DrupalCon made pretty clear that 'uuid' will not be the only property we'll have to require, enforce, and ensure across dynamic config objects, so the plan definitely is to make pretty much all configurable stuff use Configurables.)

All of that, however, does not have any impact on the core of this issue. The UUIDs are stored within config objects and thus it is impossible to look up a config object by UUID. In turn, we'll have to invent a UUID validation mechanism for the config import mechanism that can easily get extremely memory intensive.

I'm planning to do that as part of this issue.

heyrocker’s picture

Seems like we should cache these for easier lookups - cid = uuid, value = object name. It wouldn't solve all our problems but it would help.

mojzis’s picture

cant we simply keep both the human readability and the UUID, so it would be :


boombatower’s picture

Probably want dashes so things like


work and even still yikes a DX on this stuff. Hard enough to read code with fields stuff with all the several levels of nested arrays, but this will make things even more interesting. Dunno, but if you go this route should probably use dashes so it works nicer in code.

andypost’s picture

Also this issue required to handle properly a machine name changes for Configurables

alexrayu’s picture

Is it possible to have config objects unique without actually having to use the UUIDs in code like above? That does look monstrous. There has to be another way to ensure uniquess - separate UUID and machine name?

adub’s picture

Could be missing something here but my understanding was that UUID is the only identifier that really makes sense in a non-local context, particularly when all entities are becoming addressable (e.g. drupal services as a views data source, ESI etc), but that indexing performance on standard UUID is pretty bad - and so we would maintain both ways of addressing entities, depending on context of the caller. (Unless the 'UUID' is made up of domain+locally_unique_id.)

xjm’s picture

xjm’s picture

Issue summary:View changes


alexpott’s picture

Status:Active» Closed (works as designed)

The config synchronisation system now compares uuids and configuration objects to work out if an operation is an update or a delete/create so this issue is solved (by #1740378: Implement renames in the import cycle).