Yoast / wordpress-seo

Yoast SEO for WordPress
https://yoast.com/wordpress/plugins/seo/
Other
1.75k stars 885 forks source link

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

Open apermo opened 5 years ago

apermo commented 5 years ago

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

benvaassen commented 5 years ago

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 commented 4 years ago

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

Djennez commented 4 years ago

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 commented 4 years ago

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?

selection_154

Pcosta88 commented 4 years ago

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

rmarcano commented 4 years ago

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

Pcosta88 commented 4 years ago

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

rmarcano commented 3 years ago

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

4ort0 commented 3 years ago

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

josevarghese commented 3 years ago

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

rmarcano commented 2 years ago

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

suascat commented 2 years ago

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

ogodoabiola commented 2 years ago

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

maybellyne commented 1 year ago

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

ogodoabiola commented 1 year ago

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

ogodoabiola commented 10 months ago

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

detolah commented 6 months ago

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

maybellyne commented 4 months ago

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

tyrann0us commented 3 months ago

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 commented 1 month ago

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