After the code that creates term relationships for variations has been
removed, a data migration is required to remove all the no longer needed
term relationships.
Also, the original migration that backfilled those relationships has
been removed (the migration function is kept but with an empty body).
In an environment with persistent object caching, concurrent calls
to delete_option() + add_option() can result in the option value
leaking out of the alloptions cache key, and into its own cache
item under the options group, while deleting the value from the
database.
This causes future function calls to add_option() to fail, since
the value already exists in cache (under the wrong key). It also
causes calls to delete_option() to fail, since the value is not
in the database.
This commit forces update_option() instead of the delete + add
combination, as well as removes multiple unnecessary calls to
update the woocommerce_db_version from admin notes and notices.
Product attributes are currently recorded as terms in
wp_term_relationships (product attributes are actually taxonomies).
In the case of variable products this is true for the main product,
but not for the variations. The attributes used to define variations
are stored as post meta, but nothing is recorded in the term
relationships table.
This is a problem when using the layered nav filtering plugin,
since the attribute counters displayed are calculated based solely
on the contents of the term relationships table. Adding meta queries
would be really messy (especially when the widget is configured
with AND operator) and would probably also hurt performance.
This commit adds a change to store the attributes for variations
as term relationships, additionally to storing them as post meta.
Terms are stored on variation creation, and updated/deleted together
with the variation as appropriate. "Any" variations (stored in meta
as empty values) are not stored as terms.
Additionally, a database upgrade is included in order to backfill
terms for already existing products.
Using WooCommerce on a multisite network using the hyperdb drop-in, the foreign key check fails although there is a foreign key.
32037e37dd/includes/class-wc-install.php (L745-L763)
The first problem is that hyperdb wasn't designed to route `information_schema` queries. After patching hyperdb, the query is routed to the correct database.
The second problem is that the query still finds zero foreign keys because `$wpdb->dbname` is blank when the query is generated. Hyperdb only has a dbname in the context of a query being executed; hyperdb extracts the table name, then maps that to the correct database.
Although we could find a way to support such `information_schema` queries, they are also not preferred because they are notoriously slow. On WordPress.com they take 300ms, versus 3ms for a `SHOW CREATE TABLE` which similarly reveals the existence of the foreign key.
The proposed changes simplify the check, make it faster, and make it work with hyperdb.
1. Use '0000-00-00 00:00:00' instead of CURRENT_TIMESTAMP as default value to support MySQL 5.6
2. Return early if DB version is less than 430 because then it would mean that required wc_reserved_stock table might not be present.
Roy Ho
geektzu
Claudio Sanches
Cale9
Marcos
jonathansadowski
mfs-mindsize
vedanshujain
Gary Cao
Néstor Soriano
Jonathan Sadowski
Joshua Flowers
Rodrigo Primo
Ron Rennick
Konstantin Kovshenin
And Finally
Andy Skelton
Jory Hogeveen
Peter Fabian
Paul Sealock