`install()` method may be called before wc_version is set, this may cause unknown errors in 3PD gateways.
So its safer to only load PayPal gateway directly.
- Turn get_settings into a parameterless method, but accept one
parameter via func_get_arg; and mark the method as deprecated.
- Rename the existing get_settings to get_settings_for_section;
and mark the method as final.
- Rename the existing get_settings_for_section to get_settings_for_section_core.
See the comment added to get_settings for the rationale for the change.
In PHP 8 overriding a method having an optional parameter with a
method having no parameters throws an error, thus we can't use
the strategy of changing "get_settings()" to "get_settings($section='')"
without breaking existing extensions. So we do the following instead:
- Rename the existing "get_settings" to "get_settings_for_section"
- Rename the existing "get_settings_for_section" to "get_settings_for_section_core"
- Add a "get_settings" that just does "get_settings_for_section('')"
for compatibility, but mark it as deprecated.
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.