Adding a new site fails to propagate categories [3.6]

[shoored]

When adding a new site to a multi-site Craft setup and deploying this to another Staging or Production environment, the queue tasks for Propagating categories fail.

The error message is "Category’s group (1) is not enabled for site 12".

I've had this with previous added sites on the same setup.

Sometimes it helps to do a project-config/apply --force but it's not always the case.
Restarting the task keeps failing.

I have deliberately not activated any sections yet so that it's only adding the basic site things.
To my understanding categories are always enabled for every (new) site by default.

Any idea how to tackle this?

Craft 3.5.19.1
PHP 7.4

[carlcs]

We were running into the same problem while deploying new sites to production today, so thanks for bringing this up @shoored. What’s strange is that it didn’t happen when I deployed the sites to staging last week. And nothing else changed config wise in the meantime… erm…

Now that I say this, it comes to mind that there was a difference. On staging it’s been two deployments. With the first update I’ve added 3 sites and then I had to remove one of these again.

[brandonkelly]

@shoored Can you please email the following things into [email protected]?

• A database backup taken from staging/production, from before the deployment
• Your composer.json and composer.lock files
• The incoming config/project/ folder that was being deployed

[shoored]

@brandonkelly Will do!

@carlcs Yeah I've also had weird Global set permission errors with other newly added sites as well. Hopefully Brandon's or someone else's eyes can shine a light since I'm probably too focused on the wrong thing.

[carlcs]

We’ve got things fixed on our side. It was an issue with the project config which I was able to resolve by going into settings for each category group and save it from the control panel. There was a UUID in the category YAML’s siteSettings that didn’t belong there.

[brandonkelly]

@carlcs Did you try running php craft project-config/rebuild? I believe that would have had a similar effect.

[carlcs]

@brandonkelly I did rebuild the config files first. But the UUIDs only got removed once I did it through the control panel.

[brandonkelly]

@carlcs Do you happen to have a DB backup from before you resaved the category groups? If so could you send it to [email protected] so we can investigate?

[carlcs]

@brandonkelly sorry, but I don’t have access to a backup. Locally I didn’t create one, and I currently don’t have full access to the other environments.

[LukasV3]

Is there an update on this issue? We're currently running into the exact same problem outlined above by @shoored.
We have tried the following to no avail;

• Running php craft project-config/rebuild
• Rebuilding via the control panel as mentioned by @carlcs
• Running php craft project-config/apply --force
• Running php craft resave/categories --group regions which has worked on a local environment but fails on staging.

Any more info would be greatly appreciated.

[TazzaRhae]

Hi all, is there an update on this issue, please?

I am also experiencing the same problem outlined above by @shoored and @LukasV3

Thanks

[nettum]

For the record, I also had the same error some time ago. Same fix as @carlcs, re-saving the category group(s) in settings fixed it. In my case craft was missing a site uuid in the category group project config.

[brandonkelly]

I’m not able to reproduce it on 3.7.41.

The only way I could sortof reproduce it was, if I viewed the Categories index page for the newly-created site, after applying the project config changes but before the “Propagating categories” queue job had run, the index query would get cached with zero results, and then subsequent requests would load the results from cache, even after the job had completed. I’ve fixed that for the next release (8642349), but guessing it’s not the original culprit for this issue as the issue predates 3.7.14 when element index caching was added (3d799ae).

[LukasV3]

To fix this issue I first updated Craft to 3.7.42. I then re-saved the category group that had its propagating categories job failing. I then retried the failed queued task for propagating categories which then ran successfully. As previously mentioned Craft was missing a site uuid in the category group project config.

Previously, re-saving the category group had no effect as the queued job would continue to fail. To get around this I tried adding a category URI to the category group, saving it, and then retrying the failed queued task and then removing the category URI I added earlier. This seemed to work also.

[bzin]

I am also having this from a Craft CMS installation that was running 3.7.34 and we updated to 3.7.43 and installed a new Site. Propagation and resaving of categories fails all the time. I tried to repair these 1 by 1 but can't seem to make this right on staging. Also repairing the categories via cli took a lot of time for specific groups.

[carlcs]

I’m running into this again while deploying a new site to multiple environments. This time I was able to fix the problem on all environments by running project-config/apply --force.

1. Added the new site in the control panel in my local env.
2. Checked that my project config files are correct. And yes, all sites’ UUIDs were listed in the category groups’ siteSettings.
3. Deployed the project config files and applied the changes.
4. Propagating categories job failed.
5. Manually cleared all caches.
6. Manually applied project config changes with force option.
7. Clicked retry on the failed job and it finished successfully.

So there seems to be 2 issues here:

• Site UUIDs are sometimes not added/removed in category groups siteSettings in the project config after adding or deleting a site. This is possibly related to bugfix ef244e3 though?
• A normal project-config/apply without the force option doesn’t apply project config changes of category groups correctly.

@brandonkelly Yeah, it doesn’t seem to have anything to do with visiting the Categories index page in the control panel. I didn’t visit the page at all after deployment. This time I’ve got a database backup and everything and will send an email to support.

[brandonkelly]

Site UUIDs are sometimes not added/removed in category groups siteSettings in the project config after adding or deleting a site.

They must have already been in there if project-config/apply --force worked.

A normal project-config/apply without the force option doesn’t apply project config changes of category groups correctly.

Tested again locally and it’s still working for me.

Wonder if maybe it’s due to a plugin or module that’s interfering somehow. Do you mind sharing your existing Composer files, project config files, and any custom module code? If so please send them into [email protected]. I could try adding a new site and deploying the changes from there.

[carlcs]

What I wanted to say is that I we are discussing two separate issues in this thread.

The issue where UUIDs in the project config YAML files are out of sync can‘t be fixed with project-config/apply --force. But I am hopeful that ef244e3 might have fixed this and other project config issues we did run into.

The other issue where the YAML files are correct and project-config/apply --force did actually help is reproducible with the files I sent to support. I just tested it again with a fresh 3.7 project, where I imported the database dump and then ran project-config/apply without the force option.

[brandonkelly]

Gotcha… this is the first I‘ve heard of site UUIDs not getting added to category groups’ siteSettings on site creation, and I’m not able to reproduce.

The ef244e3 fix was specific to Craft 4, and only to fix an edge case where someone was making project config changes from their templates, rather than from a controller like they normally happen.

[brandonkelly]

Got to the bottom of this! The issue only occurs when the same deployment included a deleted field, for a field that had been included in a field layout that hadn’t been resaved since before Craft 3.5.

The field deletion-handling logic was trying to be thorough and remove the field from any field layouts. However that logic hadn’t been updated for the new way that field layouts store field references starting in Craft 3.5, so it only actually made a difference for field layouts that hadn’t been resaved since before updating to 3.5. And when it did actually made a difference, there was a separate bug that led to this issue: the code was running even when existing YAML changes were being applied. New changes should never be made while applying YAML changes, as it causes the ProjectConfig service to ignore any conflicting incoming changes.

I’d already removed the logic in Craft 4.0.5 (#11054), and just went ahead and removed it for the next Craft 3 release as well (7de2fcf).

There was a similar issue with site deletion, so I’ve updated that as well.

[carlcs]

Awesome work @brandonkelly! Thanks for taking the time, I can only imagine how complicated it must have been to debug all of this.

[brandonkelly]

Thanks for bearing with me and providing the example case!

[brandonkelly]

Craft 3.7.51 is out with this fix! ✨