Hmmm. For the most part I think you’re safe. What if some slow to update user has an old version of WP and an old version of your plugin prior to when the split shared term hook was implemented? Then they deactivate your plugin and upgrade WP. I don’t know why, people do weird things. Then they activate your latest and greatest after the WP upgrade did whatever it does to the user’s old data.
What happens to the user’s old data? Something to think about even if very unlikely. It’s at least conceivable it could happen. Yes?
Good point! There are up to 20 installs that possibly use a version without the split shared term hook. (Can’t really tell, I introduced it in a patch release, so the stats don’t help me there)
So I came up with this:
There will be an update function, that converts the termmeta from the custom implementation to the official implementation. This is something every active install will execute before doing anything else (update mechanism based on plugin-specific version number in the db, as you do). For every conversion wp_get_split_term() is called to check if the term has been split in the past without the plugin noticing. Depending on the return value, the term id from my custom termmeta entry is used or the newly assigned term id that the plugin wasn’t aware of yet (for whatever reason).
Since the new version of the plugin requires WP 4.4, the terms got split before my update function runs, no matter what. The update function then takes care of all the terms, whether they were previously processed by the split shared term hook or not.
Perfect! No holes in that plan 🙂
Great, thanks a lot for the support 🙂
