Entity IDs inconsistent across exports and imports

The (uu)id for taxonomies are also synced (see: https://cgit.drupalcode.org/structure_sync/tree/src/Controller/Taxonomie...) so I'm not sure what you mean by this. Could you perhaps provide more detailed information as to what you would like to see changed and if possible also provide a patch that would change that?

@ñull is right.

When you force import taxonomies, taxonomy term id's are reset and thus, any view filtering by taxonomy term id will stop working.

Only uuid is guaranteed unique and doesn't change between different environments.

However, Views doesn't allow filtering by taxonmy term uuid at the moment:

https://www.drupal.org/project/drupal/issues/2761157

I guess, what @ñull is proposing is a mechanism that will guarantee same TID for each term when synching between environemtns.

This of course, is no easy task. How do you handle conflicting term ids when importing a taxonomy?

Perhaps we can discuss ideas on wheter this is doable and what the best approach to go about it would be.

Thanks @bmunslow for clarifying this.

Syncing non-UU id's between environments is definitely something you shouldn't be doing. The linked issue seems like the best approach to get the functionality you want. Best way forward would be to contribute on that issue if you would like to see this functionality.

Thanks for this info, because I faced off this issue after importing views using TID and these settings (using TID as dynamic class for list items) aren't work anymore. More worrying, is recreating the field doesn't better work too...weird.

Just to confirm TID are NOT imported in? We have a taxonomy list that was used as an entity reference but now all the TID's have changed so the references fail.

TID are updated when vocabularies are already in the system (from migration).

I understand that we should be using the UUID instead of the TID, unfortunately not all contributed modules and core are utilizing that when making references. One thought I had is that we could have a checkbox in the UI when importing taxonomy terms that would preserve the taxonomy IDs, and rely on the site admin that's importing the terms to resolve/prevent conflicts if they occur.

Attached is a simple / quick patch that will preserve the taxonomy ID when importing using the force method.

Better title, and I noted this issue as a Contrib project blocker at #2761157: Have Views' taxonomy term filters use UUIDs instead of entity IDs.

I agree with #5. Let's ensure this is properly documented.

I just posted a patch in the other issue. Please review that if you can, and let's see if there's anything else to do here after that gets in.

#9: Thanks for the patch; it's a reasonable temporary workaround, but as per #4, let's not commit it. I'd rather have folks direct their efforts toward the core issue.

Another scenario where tids have to be sync is when a team build a new web site :
tid "last number" will be different on each dev computer, so everytime a dev will export terms modifications to config file, all tids will be updated, it could be real mess for managing merge conflict or simply reviewing Merge Requests

An dev option should be available to force synchronise tids between environments.

Does #9 simply remove the tid from the config? I'm starting to think that's a good idea because:

• It doesn't work anyway,
• It confuses folks because it looks like it should, and
• it leads to unnecessary merge conflicts that require resolution.

Thoughts?

Edit: Never mind. This is #3213758: Stop setting term IDs when exporting taxonomy terms.

Using the "Force" method import does indeed now preserve the taxonomy ID when importing.

As preserving TIDs is something that one would expect anyway when doing an operation called "Force", IMHO having a checkbox as suggested in #9 is unnecessary. Also because that should be covered when using Drush as well (using 'drush it').

If there is no reason to have two ways of the "Force" method, this can be RTBC. I have tested it with multiple vocabularies that were already filled with terms that had the wrong TIDs from a previous import, using the unpatched version of the module. It turned out perfect as the import led to only the correct term TIDs existing, without the need to remove the faulty ones first.

Just a one-line patch, but thanks in any case. It solved my issue, adding to the composer patches section:

            "drupal/structure_sync": {
                "Entity IDs inconsistent across exports and imports": "https://www.drupal.org/files/issues/2019-11-20/structure-sync-taxonomy-id-not-preserved-3032480-9.patch"
            },

Here's a ticket for what was bothering me in #13, which is really a separate issue.

Can confirm patch #9 is working. It keeps the tids consistent when using the Force method. Makes it quite simple and easy to sync taxonomy vocabularies.

It looks like #3213758: Stop setting term IDs when exporting taxonomy terms intends to do the opposite.

Let's discuss a bit more then. :)

I vote for keeping the tid consistant.
If you get often conflicts on tids between your environments, you likely have a workflow issue.

As we can export only a specific vocabulary, i don't think we can realisticly keep the tids as we can for example want to export terms for vocabulary "Product category" that could be consistant between environment and have "News tag" vocabulary that has terms generated by contributors through tag style autocomplete field. This implies that some tid might be overlapping themselves between environments.

I am also running into this issue in fact the TID changes. We have Views and custom modules that all depend on the TID being consistent. These are pieces of the site moved from D7.

I think if #9 gives us the ability to actually force this to be followed then it should be a checkbox and added, as mentioned if folks run into problems between environments that is likely more of a workflow problem and can be mitigated. As #14 implies, the fact that this is called "Force" makes sense, it forces in all the pieces included in the export, so it works as I would expect with #9's patch. Having the TID's not imported or changed causes bigger problems throughout the site than having some missing ones due to workflow conflicts, which could be sorted out via Git.

While this is just my opinion, I know this is causing us big headaches currently and it seems like the simpler solution to allow the dev the ability to force these to be followed. With a lot of sites coming off of D7, I'm sure there is plenty of modules that still look for the TID as was more common in D7.

Thank you! Patch #9 does the job for me

Changing status, based on the last comments above. It seems that the majority of commenters "vote" for committing this.

I would be happy to merge this issue, I totally agree we need to be able to retrieve tid that are currently wrong and broking relations

But what does happen if there is a term already existing with a tid that is going to be imported ?

We need a clarification of what is happenning in any case

But what does happen if there is a term already existing with a tid that is going to be imported ?

It gets overwritten with the new data. That is exactly what you would expect when doing an operation called "Force".

I agree, we still need to make it more obvious about the differences between safe, full and force mode for taxonomies before we can merge this patch

Thanks

Not sure if a comment on Drupal 10.1 is relevant here, but I confirm that in Drupal 10.1 you can still experience an issue with inconsistency between source and destination TIDs when you expect the TIDs to be preserved from the source (what is in structure_sync.data.yml file).

It is not entirely clear to me how to achieve that goal.

To make this easier to review, I've created a merge request.

This is an issue for an unsupported branch (8.x-1.x).

Is this still an issue in the 2.x branch?

There hasn't been a response as to whether this is still an issue on a supported branch, so I'm going to close this issue as outdated; but please feel free to re-open if this is actually a problem in the 2.x branch.

Thanks in advance for your patience and understanding as I try to clean up this project's issue queue!