WordPress is undergoing a steady change of its underlying database schema as part of its roadmap to taxonomy meta and post relationships. This was announced in 2013, and since then ground has been made in that direction. WordPress 4.2 will be another step along that roadmap.
Currently if you have two or more terms (in any taxonomy / for any post type) which share a term slug they point to the same term in the database. Part of this roadmap involves ensuring that no terms are shared between taxonomies. If you are running WordPress 4.0+ then any new terms will not be shared, but any terms created prior to that may well be. (You can check if you have any shared terms with this plug-in).
In WordPress 4.2, however, whenever you update a shared term it will be split out so that it has its own entry in the
How does this affect Event Organiser?
Any plug-in which internally stores term IDs will be affected because those term IDs may change. Event Organiser uses term IDs internally in two places:
- The venue metadata table (venues are taxonomy terms).
- To store the colour of a category
If a venue/category term is split then potentially you will ‘loose’ this data (it will still be in the database, but Event Organiser will be looking in the wrong place)1.
Who does this affect?
Users with shared terms across taxonomies. That is, venues or event categories with slugs which also appear in other taxonomies. This plug-in will tell you if you have shared terms.
How can I fix this?
Event Organiser has been updated in 2.12.0 to pre-empt these changes. If you update to 2.12.0 (released today) before you update to WordPress 4.2 (which at the time of writing is due April 2015) then you won’t experience any problems.
If you don’t, Event Organiser will attempt to recover any lost data when you do update to 2.12.0 (or later).
Actually, in testing it was found that editing a venue/category (but not quick editing) causes the data to be duplicated across to the new ID. This just means they’ll be some stale/obsolete data in the database, which won’t do any harm, and the plug-in will otherwise be unaffected. ↩