This commit fixes some inconsistencies in the settings pages, and
makes all the existing pages extensible by adding new sections
(that was possible in some pages, but not in others). Main changes:
1. Modify the 'get_sections' method so that it invokes a new protected
'get_own_sections' method and then triggers the
'woocommerce_get_sections_' . id filter.
This way the filter is triggered only in the base class
and not in each of the derived classes too.
2. Change the get_settings() method so that it has its signature
changed to get_settings( $current_section = '' )
in the base class and in all the derived class.
Some derived classes were already using this signature, but others
(those not having multiple sections natively) weren't, making then
effectively impossible to define multiple sections for these pages
via filters.
With this change all the section pages act consistently and allow
both adding new settings to the default "General" section
and creating new sections via filters.
3. Change the implementation of 'get_settings' in the base class
so that it searches for a 'get_settings_for_{section_id}_section'
method in the class and executes it, otherwise it executes the new
protected method get_settings_for_section( $current_section ); then
it triggers the 'woocommerce_get_settings_' . id filter.
This makes it easier to separate the code that returns the list
of filters in multiple methods, one per section, instead of using
one big if-else-else... block.
So now instead of overriding get_settings($current_section='') derived
classes need to implement get_settings_for_{$current_section}_section
for each section, or override get_settings_for_section($current_section)
or both. 'get_settings_for_section' returns an empty array by default.
Also, 'woocommerce_get_settings_' . id is triggered in one single
place too.
Other improvements:
* Remove duplicated code from 'output' in 'WC_Settings_Page' children.
Some classes inherited from 'WC_Settings_Page' override the 'output'
method with custom code, which in all cases ended up repeating the code
of the original method as a fallback. These repetitions have been
replaced with 'parent::output()'.
* Fix inconsistencies for 'save' and 'output' in WC_Settings_Tax/Emails
The 'WC_Settings_Tax' and 'WC_Settings_Emails' classes had some
inconsistencies in their 'save' and 'output' methods that prevented the
proper creation new sections and the addition of new settings via the
'woocommerce_get_sections_' and 'woocommerce_get_settings_' filters.
Now they work as expected.
* Deduplicate parts of 'save' in 'WC_Settings_Page' and children.
Two methods have been added to 'WC_Settings_Page' class:
'save_settings_for_current_section' and 'do_update_options_action'.
These are intended to be invoked by derived classes in their 'save'
methods, in order to remove code repetition.
* Add some helper methods to WC_Unit_Test_Case.
Methods added:
- assertOutputsHTML
- assertEqualsHTML
- normalize_html
- capture_output_from
PR #28849 introduced a verification of the posted country code
on checkout, so an invalid code will throw an error. However there
are cases when an empty code is legitimately received, for example
when using Paypal checkout directly from the product page and
the customer doesn't have an address in his Paypal profile.
* Removed extra double quotation from the image tag
* Fixed typo in the init() method
* Moved init() method body into the constructor -- a separate method is not necessary
The WC_REST_Terms_Controller and WC_REST_Product_Attributes_V1_Controller
classes have a get_taxonomy method that gets the name of the taxonomy
to process from a taxonomy id passed in the request, but once the
taxonomy name has been obtained it's cached and sbsequently reused.
The problem is that these controller instances are reused if more than
one request is processed programmatically, and thus the taxonomy that
was cached once is always used even if the new request specifies a
different taxonomy id.
The fix consists of using a dictionary of taxonomy id - taxonomy name
instead of one single taxonomy for caching.
In the case of WC_REST_Terms_Controller there's a protected $taxonomy
property that needs to be kept for compatibility, it's now set to
the last taxonomy name that has been introduced in the dictionary.
- Allow the list of line items to be a non-associative array
where each item is identified by an "id" field
- Same for taxes inside line items, specify amount to refund in
a "refund_total" key as in the case of line items
- Allow "quantity" keys as synonyms of "qty"
Also calculate "amount" automatically if missing and when all the
line items and taxes have a valid "refund_total" key.
The price filtering query wasn't working properly when there are
variations with different prices: if at least one variation was
outside of the price range but other were inside, the product wasn't
being listed.
The DownloadPermissionsAdjuster class hooks to adjust_download_permissions
from within its init method. However this method is executed only
if the class is resolved, otherwise the hooks doesn't get attached
and then the scheduled action is not serviced.
To solve this, the class is resolved from WooCommerce::init_hooks.
This requires a change in DownloadPermissionsAdjuster::init
to use wc_get_container()->get( LegacyProxy::class )->get_instance_of
instead of WC()->get_instance_of, since WC() can't be used from
WooCommerce::construct (which invokes init_hooks).
We are using func_get_arg method to receive argument in a backward compatible way since we cannot modify function signature to add more params even with default params. Earlier I was hoping to use DI to create another child class with modified signature and load it depending upon where we are executing from, however since we had to revert DI, we add this workaround to unblock #27735.
- Added the `ThemeSupport class`, with methods to add and get
theme support options.
- It also has a new `add_default_options` method that adds the
options under a `_defaults` key.
- The `WC_Twenty_*` classes now use `ThemeSupport` instead of
the `add_theme_support` function to define image and thumbnail sizes.
- The values are defined as default options.
- The `WC_Shop_Customizer` class now uses `ThemeSupport` instead of
`wc_get_theme_support` to check if image and thumbnail sizes UI
should be rendered.
- The check is made excluding default values.
With these changes the UI to change the image and thumbnail sizes
is hidden only if the options are added as non-defaults elsewhere.
Additional changes:
- The code of the `wc_get_theme_support` function is replaced with
a simple call to `get_option` in `ThemeSupport`.
- Added the utility class `ArrayUtil`.
- One dummy class used for tests had a 'final private' method, this
is not allowed in PHP 8 and so the method is now just 'private'.
- The AbstractServiceProvider class was using
ReflectionParameter::getClass. This is deprecated in PHP8 and thus
that usage has been replaced with an utility method that uses
the recommended replacement.
- Passing a string that represents a number but has spaces (e.g. ' 1 ')
now works as expected (the number is properly interpreted)
- Passing the boolean true now returns 1, not 0
- Passing an object throws an error, instead of returning 0
After the League's Container package has been reintroduced, all the
code that implements the dependency injection mechanism in woocommerce
can be brought back as well.
There's a number of places in the WooCommerce codebase where the
built-in function 'round' is executed passing a non-numeric value
(not a number and not a string that can be parsed as a number),
for example round(''). In PHP 7 this yields a value of 0, but in
PHP 8 this throws an error.
This commit adds a 'NumberUtil' class with a static 'round' method,
this method checks if the passed value is numeric and if so it just
executes the built-in function, otherwise it returns 0. And all the
calls to 'round' in the codebase are replaced with 'NumberUtil::round'.
Since reverting the PR at this point would be a mess I've gone ahead and removed the internals of the container. We should aim to keep the class since it's now part of our public API but it won't work as expected anymore. This is fine for now since we don't actually have anything in it!
1. Since our code style dictates that these be `final` methods, we shouldn't be concerned about overlap.
2. There is precedent for `init` methods as requirements before using class instances.
Claudio Sanches
Nestor Soriano
Nestor Soriano
𝓑𝓪𝓻𝓻𝔂 𝓗𝓾𝓰𝓱𝓮𝓼
Roy Ho
Peter Fabian
Saggre
Moon
Timmy Crawford
Vedanshu Jain
Steve Grunwell
jonathansadowski
Rodrigo Primo
Christopher Allford