We have special method to round taxes which may round up or round down depending upon settings. This method should be used instead of default rounding in formatting funtions.
We round up or round down depending upon if prices are entered inclusive or exclusive taxes, however since shipping and fees are always entered exclusive of taxes, they should always be rounded down.
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.
This commit will fix the batch export issues related to distributed file systems and memory limitations.
Basically, instead of pretending the headers at the last step of the export and loading the full CSV content into memory each time data needs to be added, we basically will append the data to the created file on each batch request; and at the last step, we will also create a temporary file to store the CSV headers, so when preparing the download to the user, this will simply read the CSV headers from the created temporary file.
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/).
roykho
Jonathan Sadowski
Nestor Soriano
Christopher Allford
Claudio Sanches
Vedanshu Jain
Paul Sealock
jonathansadowski
Dan Wyman
And Finally
Néstor Soriano
Menaka S
Tim Howe
Yehuda Hassine
Khoi Nguyen
barryhughes
Kapil Paul
Marcos
gilesholder
Bero
Albert Juhé Lluveras
Ovidiu Liuta
Gracie Ofslager
kkmuffme
Caleb Burks
raicem
Barry Hughes
Brian
Jacob Arriola
James Allan
Mike Jolley
Mehrshad Darzi
Timo Boyer
Quy
Luiz "Bills
Kudratullah
Ewout Fernhout
Mauricio Urrego
Peter Fabian