entity cannot have a URI as it does not have an ID error

Hi collinm,

Thanks for creating an issue with some more information. I suspect the culprit is the following

After upgrading to 11.3.5 from 9.18.0

Unfortunately we don't support skipping major versions during an update since that would require keeping a very long and complex upgrade path working and prevent us from removing old code.

This was mentioned in the release notes for 11.0.0 → which recommends upgrading to 10.x before moving on to 11. I do see that we can improve our upgrade documentation where this was not mentioned.

I hope that helps and that performing the upgrade from 9.x to 10.x and only then moving to 11.x solves your issue.

Hi Kingdutch,

We did the intermediate step of upgrading to 10.x. We did spot that when trying to upgrade and we had several intermediate versions to achieve an upgrade path to 11.3.5. It's what I hinted at with the "We can provide the version steps if required." in the reproduce section. If it helps I can look up the exact versions we rolled out to get to 11.3.5.

Ah I didn't quite get that from the original issue :) If you could provide the list of versions you updated through that may help :)

And you're sure the install was working correctly before the update?

Yep, the install was working correctly before the upgrade. I've used the "/nl/admin/structure/message" page before to look up the template config.

These are the versions reported by our git repo. Version 9.18.0 is the version we started with and we then made the step to 10 and proceeded to 11. Detail is that there's an intermediate step as composer initially picked up 11.0.0-alpha1 but that didn't give us an upgrade path. So the step back to 10.3.8 was made (but no config sync changes were committed and as far as I can tell it didn't change anything in the database). With us then forcing stable to continue with the upgrade. With us ending on 11.3.15 (currently we are testing 11.6.6 on our staging server)

1. 9.18.0
2. 10.3.8
3. 11.0.0-alpha1
4. 10.3.8
5. 11.0.0@stable

I would not be surprised that the 11.0.0-alpha1 step is what is causing us the grief with the admin screen.

Hi Kingdutch,

Can you have a look at the feedback I provided? I can't apply requested changes as long as I don't know why this isn't correctly working.

It's possible that 11.0.0-alpha1 contained update hooks that were executed that were maybe skipped at a later point. Going from 9 to 10 and then 11 was the way to go, but I'm honestly not sure what Drupal does if we go back to 10 and then back to 11. So if that's the cause I'm not sure there's much we can do from our side to fix that.

But do you know which migration is responsible for configuring this? It might be just a matter of rerunning it and that's something I can test on my local machine.

We edited the template via the config sync files but this isn't a solution for the underlying problem of the admin screen not working. I've poured through install/update files but I can't find anything that would explain the issue we're having. Can you please give me something I can further investigate. This is extremely frustrating that I can't even get a list of migrations that could possibly explain this. I don't even have enough information from the error to track it down in the database en maybe fix it there manually.