Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
to your account
Currently, post metadata is stored through individual keys.
This means there are a lot of entries stored in the database, and key collision is prominent.
To resolve this, we must upgrade the metadata from single entries to an array with a common (namespaced) key.
In WordPress 4.4, new term metadata functionality was added. In TSF 2.7, the Term Metadata upgrade was handled and annotated.
This upgrade was done in one single request.
Lines 117 to 131
This can't be done for posts.
Now, all propositions can work alongside. In all cases, new data will be tested for existence, and will then fall back to old.
When done follow-up: #48
Related functionality: #84
The text was updated successfully, but these errors were encountered:
Candidate for 3.1.0. But, I don't want to rush this as it's a vital component and it needs to be done perfectly.
Sorry, something went wrong.
Maybe later, it's not pressing.
Almost completes #110. Reworked meta handler.
+ Lays foundation for #185
In TSF 4.0, we revised how post-metadata is handled, with this issue in mind.
See the post-data.class.php file.
When we move to this method of storing data, plugins like "Better Search and Replace", and possibly "WP-Optimize", will annihilate the metadata as they pass over it.
Here's one recent finding, where "Better Search and Replace" replaces Extension Manager's neatly-packed metadata with (string) "1".
No branches or pull requests