- The `Container` class now implements `Psr\Container\ContainerInterface`
(and registers itself as such), holding a private instance of the
real container. This way it's a read-only container from the point
of view of plugins (which should use their own containers, but
can still use this to get WooCommerce classes).
- All registrations are now done in the `Container` constructor via
service providers.
- The container instance is now held in a global variable, set in
`woocommerce.php`
- Added the `wc_get_container` function for old code.
- Added the `AbstractServiceProvider` class, which inherits with the
corresponding League's class and adds some utility methods,
most notably `add/shareWithAutoArguments`.
- Added the `ActionsProxy` and `LegacyProxy` classes, they are
registered via a dedicated service provider.
- `WC_Queue_Interface` is no longer resolvable via the container
(which is for classes inside `src` only).
- All the method names in the new classes have the format `fooBarFizz`
to be PSR4 compliant, so the MethodNameInvalid error has been
disabled in phpcs.xml for the `src` directory.
- Introduced the `@public` annotation for public API classes
(classes that plugins can use and whose backwards compatibility
we guarantee), applied to `ActionsProxy` and to `LegacyProxy` for now.
- Removed the hack for the autoloader as now it doesn't work anyway.
For the changes in this branch to work, now WP_DEBUG must be false.
- Renamed from `ObjectContainer` to `Container`.
- It now inherits from PHP League's `Container`.
- It has now a `defineAsSharedAutowired` method.
- Initialization moved to the `WooCommerce::init_container` method.
- The static method for object resolution is now `WooCommerce::get_instance_of`.
- Add PHP League's Container package via Composer.
- Add an ObjectContainer class that encapsulates all the configuration
and insulates the codebase from the concrete DI engine used.
- Add an improved ReflectionContainer class that will allow to
register individual classes as singletons while autowiring.
- Use ObjectContainer to resolve the WooCommerce class, everything
instantiated with "new" inside it, and all singletons that are
usually obtained via WC() function.
- Introduce the CustomerProvider class.
- Introduce a service provider to resolve WC_Queue_Interface,
this replaces the WC_Queue class.
- Mark as obsolete all the replaced "instance()" methods,
and the entire WC_Queue class.
While variations only uses "published" and "private" statuses when
exporting we should display the variations as "draft" in case the parent
product it's also a draft.
At some point the 'change_stock' key is assumed to be present
in the request data, but it might not. Fixed to test for existence
before using the value.
Create a new `request_data` method in WC_Admin_Post_Types that
just returns $_REQUEST. This is intended to ease unit testing,
as this method can be easily mocked to return test data.
For bulk edit: even if stock status was left as "No change", the
status of all variations was being changed to whatever the status
of the product was before it was converted to variable. Now
no change is performed when "No change" is selected, and all
variations change to whatever is selected otherwise.
For quick edit: a new "No change" option is added that will be
preselected when the product is variable. Previously, whatever
status the product had before being converted to variable was being
shown, and that's the status that would be set when saving.
Also, a "This will change the stock status of all variations"
message is displayed before the selector.
Two methods have been created:
- update_stock_status, replaces code that was duplicated in the
quick_edit_save and bulk_edit_save methods.
- set_new_price, replaces code that was duplicated-ish in the
bulk_edit_save for setting the new regular and sales prices
(code was not identical but very similar).
Also, `round` is now used on sale price calculations that involve
multiplying by a percent, the same was as it was done already
to calculate the regular price.
Some of our endpoints don't have an "<id>" parameter but we're expecting one in the CLI. Since the `id` is already part of the supported IDs we don't actually need this since it will pull it from the route.
Methods `wc_maybe_increase_stock_levels` and `wc_maybe_reduce_stock_levels` already reduce/increase stock levels when statuses are changed, so no need to do this here.
When a product is saved its validate_props method is invoked,
and this recalculates the stock_status property based on whether
the product manages stock or not, the stock quantity, and the
value of the woocommerce_notify_no_stock_amount option.
In the case of variable products, and when stock is managed, the stock
was set to "instock" when the current stock was enough, but only
if the "stock_quantity" property was in the list of changed properties
for the object (the method in the base product class doen't check
for changed properties). This is a problem because the
wc_update_product_stock function updates stock_quantity but via direct
database modification, and thus stock_quantity isn't considered
modified. Therefore stock modifications via wc_update_product_stock
don't update stock_status on the product (e.g. when going from 0 to 1
after a refund the stock status will remain as "outofstock").
The fix consists of removing the check for changed properties since
it's not done anyway in the other cases (when stock is below the
woocommerce_notify_no_stock_amount threshold) nor in the base class.
Also, validate_props is refactored for readabiliyy, and an useless
set_stock_status() call placed right before save()
in wc_update_product_stock is removed.
One of the problems with synchronous webhooks is that they are executed as soon as the related action is. Since we may call an action multiple times in the process of updating something, this causes only the first action to trigger the hook. This differs from asynchronous execution because in that case, the web hook will be executed after the entire request has completed.
When a logged-out user tries to check out with an email address associated with an existing account, they are prompted to log in. This PR updates that prompt with a link to the login form. Though other opportunities to log in should already exist elsewhere on the checkout page (such as `form-login.php`'s "Returning customer?" prompt), this change makes it more explicit and intuitive.
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.
With the increased cadence of releases it becomes necessary that we address the `WC tested up to` header's usefulness. It isn't practical to require everyone to update their extensions every month, especially given that we are only doing backwards compatible minor releases. The only case I can think of where we might want to check the minor version is if the Stable tag on Core is downgraded, but due to the naming of the header, this doesn't make any sense.
I considered making this a wildcard of some kind but I think most would bind to a full major version anyway and so this isn't worth the time to add it. As an aside, the tests in `plugin-updates.php` seem to indicate that a header of `WC tested up to: 4` would apply to the entire major version cycle, so wildcards already exist!
Nestor Soriano
budzanowski
vedanshujain
Claudio Sanches
Christopher Allford
Damir Ha
Ron Rennick
Peter Fabian
Szabolcs Légrádi
Claudio Sanches
Alamgir
Dan Bitzer
Ken Gagne
Daniel Morell
Paul Sealock
jonathansadowski
Jonathan Sadowski
Peter Viszt
Julia Amosova
Dor Elidan
Viszt Péter