After chevron clicking on attribute section complete edit product data section toggled insted cliackig area.
Key point issue is missing 'postbox' class of wordpress postbox.js library for a attribute block that we try to toggle.
- Jest/Puppeteer sometimes will not find an element on page load when that element is outside the initial viewport
- There were duplicate .variation_tab classes which confused Jest/Puppeteer
- Add function for opening and verifying new product page
- Update test sequence for changes in flow in markup and Jest/Puppeteer
This commit fixes a bug that made it impossible to assign to a product a tax class that contained non-ASCII characters that are URL encoded by sanitize_title().
WooCommerce uses sanitize_title() to generate a slug when creating a tax class (d48f1d4e2e/includes/class-wc-tax.php (L808)). sanitize_title() converts some non-ASCII to ASCII equivalents (those handled by remove_accents()) and URL encodes others (like some Greek characters, for example).
The code was using wc_clean() to sanitize the tax class when the user edited a product. The problem is that wc_clean() removes URL encoded characters, changing the slug of some tax class, causing WooCommerce to use the standard tax class instead without any errors. To fix this issue, this commit replaces wc_clean() with sanitize_title(). This should be enough for security purposes and should not cause any issues with non-ASCII characters.
Previously 'dirname( __FILE__ )' was used to import files, however, the directory separator was missing.
This commit replaces 'dirname( __FILE__ )' that was introduced in 5370d02484 with __DIR__ and added DIRECTORY_SEPARATOR
Relative include paths in PHP can break whenever the server is running opcache. As such, WordPress.com deploy system refuses to include WooCommerce because of that issue.
This commit changes the relative include paths to absolute include paths.
Relates to #27269
This commit changes the condition in the if the statement that decides
whether or not to display the "Paid by customer" section in the order admin
page. Before it, this section was displayed for all orders that
contained one of the following statuses: 'processing', 'completed' or 'refunded'.
The problem with this approach is that offline payment gateways, like
'Cash on Delivery', set the order status to processing when the order is
placed but before the customer pays for it. So the "Paid by customer"
section was being displayed in some cases where the order was not
actually paid yet creating a confusing experience to store managers.
To fix this, this commit also checks for the presence of the
`_date_paid` order meta. If this order meta is present and the order
status corresponds to one of the three statuses listed above, it means that
the order has been paid and we can display the "Paid by customer"
section. If this order meta is not present, we don't display the "Paid
by customer" section.
Peter Fabian
Claudio Sanches
roykho
Ron Rennick
OlegApanovich
Rodrigo Primo
Romario
Hayden Whiteman
Néstor Soriano
vedanshujain
Jonathan Sadowski