Information stored in wpseo_taxonomy_meta in the wp_options won't be cleaned up

[apermo]

• [x] I've read and understood the contribution guidelines.
• [x] I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened.

When deleting a category, post_tag, custom_taxonomy, the information, stored inside the option 'wpseo_taxonomy_meta' won't be deleted, though these information are lost forever, since they are bound to an id, which will never be given again.

Please describe what you expected to happen and why.

Obviously, delete the information alongside with deleting a term within a taxonomy.

How can we reproduce this behavior?

1. Create a term(category)
2. open and edit it, give it something to store in the wpseo_taxonomy_meta
3. delete the freshly created term
4. check the database

Technical info

• WordPress version: 4.9.8
• Yoast SEO version: 8.4
• If relevant, which editor is affected (or editors):
• [ ] Classic Editor
• [ ] Gutenberg
• [ ] Classic Editor plugin

• Which browser is affected (or browsers):

• [ ] IE11

• [ ] Edge

• [ ] Chrome

• [ ] Firefox

• [ ] Safari

• Relevant plugins in case of a bug:

• Tested with theme:

[benvaassen]

Thanks for reporting this bug! I've been able to confirm this. I’ve marked it correctly so it appears on the to-do list for our developers.

[amboutwe]

Please inform the customer of conversation # 587163 when this conversation has been closed.

[Djennez]

So, just providing some context on this for people running into this and for if this needs to get fixed. When a taxonomy gets deleted, we don't delete the associated WPSEO data from the wpseo_taxonomy_meta option. I think this will be solved in a future project. However, for manually cleaning up, the best way is to see if the IDs of the different options still exists in the wp_terms table.

Looking at a small example of wpseo_taxonomy_meta:

a:2:{s:8:"category";a:1:{i:2;a:2:{s:13:"wpseo_linkdex";s:2:"28";s:19:"wpseo_content_score";s:1:"0";}}s:8:"post_tag";a:2:{i:95;a:3:{s:10:"wpseo_desc";s:30:"srtjstyj tsyjstyj dt dtyj dtyj";s:13:"wpseo_linkdex";s:2:"31";s:19:"wpseo_content_score";s:2:"60";}i:93;a:4:{s:10:"wpseo_desc";s:8:"sfdhsfgh";s:13:"wpseo_focuskw";s:11:"tdkxdtk dfg";s:13:"wpseo_linkdex";s:2:"24";s:19:"wpseo_content_score";s:2:"30";}}}

This contains data for the category and post_tag taxonomies. In the post_tag taxonomy there is an array of 2 items:

i:95;a:3:{s:10:"wpseo_desc";s:30:"srtjstyj tsyjstyj dt dtyj dtyj";s:13:"wpseo_linkdex";s:2:"31";s:19:"wpseo_content_score";s:2:"60";}
i:93;a:4:{s:10:"wpseo_desc";s:8:"sfdhsfgh";s:13:"wpseo_focuskw";s:11:"tdkxdtk dfg";s:13:"wpseo_linkdex";s:2:"24";s:19:"wpseo_content_score";s:2:"30";}

These are for the tags with IDs 95 and 93. I have already deleted the tag with ID 95 so this data is outdated and could be removed.

However, to the question why would you delete this data? I don't believe this option has a large impact on normal sites. If you have thousands upon thousands of taxonomies with different SEO metadata, it might cause some impact, but I am unable to test or verify this claim.

[amboutwe]

Conv # 587163 said

Because this value is in the wp_options table and has autoload = yes That means this value is parsed on every page load. So 2.4 Mb is loaded every time making my site slow.

Note: Customer provided us with the data stored in the field. I noticed quite a few empty data strings. (Screenshot below.) Do we need to store empty strings?

[Pcosta88]

Please inform the customer of conversation # 628267 when this conversation has been closed.

[rmarcano]

Please inform the customer of conversation # 634424 when this conversation has been closed.

[Pcosta88]

Please inform the customer of conversation # 647116 when this conversation has been closed.

[rmarcano]

Please inform the customer of conversation # 679177 when this conversation has been closed.

[4ort0]

Please inform the customer of conversation # 750636 when this conversation has been closed.

[josevarghese]

Please inform the customer of conversation # 805049 when this conversation has been closed.

[rmarcano]

Please inform the customer of conversation # 835226 when this conversation has been closed.

[suascat]

Please inform the customer of conversation # 863970 when this conversation has been closed.

[ogodoabiola]

Please inform the customer of conversation #889444 when this conversation has been closed.

[maybellyne]

Please inform the customer of conversation # 1003486 when this conversation has been closed.

[ogodoabiola]

Please inform the customer of conversation # 1021202 when this conversation has been closed.

[ogodoabiola]

Please inform the customer of conversation # 1071308 when this conversation has been closed.

[detolah]

Please inform the customer of conversation # 1110008 when this conversation has been closed.

[maybellyne]

Please inform the customer of conversation # 1134424 when this conversation has been closed.

[tyrann0us]

Hi @Djennez, given that this issue apparently keeps popping up in support requests again and again over the years, do you plan to add logic that cleans up the wpseo_taxonomy_meta option on term deletion at some point?

However, to the question why would you delete this data? I don't believe this option has a large impact on normal sites. If you have thousands upon thousands of taxonomies with different SEO metadata, it might cause some impact, but I am unable to test or verify this claim.

Well, the simplest answer is data minimization and preventing "data garbage" on your customer's systems as much as possible. But more importantly, there are real-life cases where this ever-growing option causes issues, e.g., here: https://wordpress.org/support/topic/wpseo_taxonomy_meta-causing-and-autoloaded-data/.

TBH, I'm surprised cleaning up hasn't been introduced after all those years, given that this is a really simple fix: Hook to the delete_term action, check the wpseo_taxonomy_meta option for the term ID, and delete it if present. Additionally, a one-time migration script should run over all term IDs stored in the option to check if the terms still exist. If not, delete the key.

I'd really appreciate it if you could consider adding this! Thanks!

[detolah]

Please inform the customer of conversation # 1163634 when this conversation has been closed.

[rumejan]

Please inform the customer of conversation # 1192211 when this conversation has been closed.