Ghost Taxonomies / Deleted Taxonomy not always deleting associations from entry

[jonathan-bird]

Bug description

We have been reporting issues whereby they delete a bunch of taxonomy terms from the admin panel UI, and they might temporarily be removed, and the actual taxonomy files within content/taxonomies/event_category/ are removed, but after a while (a day or two they claim), the taxonomies start showing in the admin panel UI again and the front-end. It doesn't seem to be removing the code from the entries themselves. I'll share some screenshots below.

Event Category taxonomy shows a bunch of taxonomies that were deleted:

You can see they don't exist in the folder:

They still exist in the entries:

I try removing them from taxonomy list again but it doesn't make any difference. I've even tried recreating the taxonomies in the admin panel and deleting but still stays referenced in the entries (and therefore still shows on the front-end and just shows back up in the admin panel after a while.

But as soon as I clear the stache (php please stache:clear) it just shows up again.

From reading Statamic issues in Github it seemed to be an old issue but was solved 2020-2022.

I've got this marked as true too just like out of the box: https://github.com/statamic/cms/blob/v3.3.30/config/system.php#L142-L153

It seems to be the same as this issue: #1349

I can't understand why this is occurring. Can you please help?

How to reproduce

Digging in further, it seems that usually there's a "UpdateTermReferences" job that runs when a taxonomy is deleted which is to update all of the entries. However for whatever reason this site was stuck in a state where the taxonomy was deleted, this didn't run/failed and therefore it never run this job again. As you know with queue jobs, failed will retry and then just get removed so it's not ideal for things of this importance imo.

Since stache:clear shows these deleted taxonomies because they're linked to entries, and clicking delete of a taxonomy that didn't exist did not run this job, Statamic was stuck in a state where it was impossible to delete it.

What I had to do as a workaround was rename the taxonomy that appeared (even though the file didn't exist), which created the taxonomy file, and then deleted it which re-triggered the job and deleted everything successfully since it removed it from the associated entries.

This required me as a developer to intervene which isn't a good experience for my client. I'd still consider this a bug (albeit difficult to replicate as it requires that job failing/not running) since and I'd like to see it possible for Statamic to fix states like this so it should re-create the taxonomy file when it realises there's still entries associated, so that when you click delete it will actually work again and the job will fire.

I believe there should be 1 of 2 things to sort this:

• Either have some sort of rollback where if it can't remove it from entries, it rolls back the deletion of the taxonomy. I generally do this in database laravel sites (eg DB Transaction wrapped around the entire logic if you can't have A happen without B too)
• Have a clean-up that if the taxonomy doesn't exist, it either re-creates the file so when you delete it, it works second time or have it automatically remove taxonomies from the entries if it notices them existing without a taxonomy file.

Logs

No response

Environment

Environment
Application Name: xxxxx
Laravel Version: 11.34.2
PHP Version: 8.2.25
Composer Version: 2.6.6
Environment: production
Debug Mode: OFF
URL: xxxx.org.au
Maintenance Mode: OFF
Timezone: Australia/Brisbane
Locale: en
 
Cache
Config: CACHED
Events: CACHED
Routes: CACHED
Views: CACHED
 
Drivers
Broadcasting: log
Cache: redis
Database: mysql
Logs: stack / daily
Mail: smtp
Queue: redis
Session: redis
 
Livewire
Livewire: v3.5.16
 
Statamic
Addons: 7
Sites: 1
Stache Watcher: Disabled
Static Caching: full
Version: 5.41.0 PRO
 
Statamic Addons
aerni/advanced-seo: 2.9.3
aerni/livewire-forms: 9.4.1
digital-bird/statamic-redirect: 3.8.1
digital-bird/statamic-toc: 1.0.2
jonassiewertsen/statamic-livewire: 3.8.1
mitydigital/sitemapamic: 3.2.0
mitydigital/statamic-two-factor: 2.4.1

### Installation

Fresh statamic/statamic site via CLI

### Additional details

_No response_

[duncanmcclean]

Queue: redis

The UpdateTermReferences job will run on the queue. Since you're using the redis queue driver, you'll need a queue worker for these jobs to actually be executed.

I know it might be a silly question but are you able to confirm you have a queue driver running in production?

[jonathan-bird]

Yes I am. It's an existing site and as I said in the ticket, once I changed the name, it recreated the taxonomy files and then I could delete them permanently because the queue jobs ran.

The fact the site was stuck in limbo that they couldn't be deleted is the issue and Statamic should be architected in a way that's not possible.

[duncanmcclean]

Yes I am.

Thanks - I just wanted to confirm. I've seen some people change their queue driver but forget to configure queue workers.

It's an existing site and as I said in the ticket, once I changed the name, it recreated the taxonomy files and then I could delete them permanently because the queue jobs ran.

We haven't reviewed it yet, but have you seen #11058? I believe it fixes an issue where changing a term's slug creates duplicates and causes the UpdateTermReferences job to not work as expected.

I don't know if it's exactly what you're seeing here, but maybe it'll help?

[daun]

@duncanmcclean Sounds like it might be related. We've been seeing the behavior mentioned by @jonathan-bird as well, where a deleted term would be reawakened from the dead by saving from the cp.

Any hints on what's blocking the review of #11058? The fix seems pretty straightforward, but as always, without knowing the internals, it's a cheap shot from the sidelines :) In any case, it fixes an issue where the term reference udpate job wouldn't be triggered due to the term class not picking up changes after initialization.

[duncanmcclean]

I don't think there's any reason other than the fact other PRs have been reviewed instead.