We output the block if
- The user has permissions to install plugins.
- Their location is in one of the countries identified in a `geowhitelist`.
- WooCommerce Payments is not already active.
This class creates and fills the product attributes lookup table
from the existing products. It does so by in small chunks by using
Action Scheduler; it handles all the batches and the scheduling
by itself.
It also adds two entries to the debug tools menu:
- Initiate lookup table regeneration (deleting the existing table first)
- Enable or disable the actual usage of the lookup table
for product filtering
The first one is the only way to generate the lookup table for now
(there's no explicit data migration).
The actual filling of the table is delegated to a LookupDataStore class
that is not implemented yet, so for now the table isn't actually filled.
Also enabling/disabling the lookup table usage has no real effect yet.
Two new optional keys have been added to the tool definition array:
- 'disabled': when true the tool button will appear disabled.
- 'needs_refresh': when running a tool, by default the tool definitions
are retrieved first, then the selected tool is executed,
then the definitions previously retrieved are rendered.
When this key is true the tool definitions are retrieved again
after execution, useful for cases where the tool description
or button enable/disable state changes after the tool execution.
Also now if a tool execution throws an exception a notice will be
shown with the execption message, previously the exception
was unhandled.
Previously, if the product didn't have an explicit low stock value
amount the value of the woocommerce_notify_low_stock_amount option,
which is a string, was returned verbatim.
Also, update related unit tests to create the option value as a string,
and to check that the value returned by woocommerce_notify_low_stock_amount
is always an integer.
- 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.
This helps on conveying the notion that the method to be overriden
is get_settings_for_section_core instead (or get_settings_for_X_section
methods must be added).
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.
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.
The logic should be "if woo payments is installed and the country
is US then remove the payments task" but the check was mistakenly
being set to "or" so the task was removed whenever the country was US.
- Check input (no 'id', has 'code') and throw an error if needed
before removing the existing coupons, so an invalid input
won't cause the loss of these existing coupons.
- Also, check that the coupon is actually valid as part of the
input check.
- Cache the coupon objects that are created during the input check,
and apply them directly.
- Don't check if 'coupon_lines' is an array and contains arrays,
that's already done by the REST API engine by looking at the schema.
- Adjust unit tests.
Following a code snippet suggestion the wp_redirect in
WC_Checkout::process_order_payment was replaced with wp_safe_redirect,
but this had unitended side effects. From issue #29387:
You've changed wp_redirect to wp_safe_redirect in
WC_Checkout::process_order_payment. If a 3rd-party-plugin executes a
"non-AJAX-processing-order", wp_safe_redirect will be executed.
But your default PayPal interface will redirect to an URL that is
not allowed in wp_validate_redirect because your default PayPal Gateway
does not add the required PayPal URLs with the hook
"allowed_redirect_hosts". As a result, it could happen that a customer
is not redirected to PayPal but to wp-admin
(https://developer.wordpress.org/reference/functions/wp_safe_redirect/).
And Finally
barryhughes
Nestor Soriano
Kapil Paul
roykho
Jonathan Sadowski
Marcos
gilesholder
Bero
Albert Juhé Lluveras
vedanshujain
Gracie Ofslager
kkmuffme
Claudio Sanches
Caleb Burks
Nestor Soriano
raicem
Barry Hughes
Brian
Jacob Arriola
James Allan
Mike Jolley
Mehrshad Darzi
Timo Boyer
jonathansadowski
Luiz "Bills
Kudratullah
Ewout Fernhout
Mauricio Urrego
Peter Fabian