The original summary is not relevant to the customers or visitors
but it was shown to them if the theme displays page summaries.
Changed to a public-friendly text.
Product attribute lists permalinks ("/attribute/term") were not working
for attribute names containing non-ascii characters. That's because
when the attribute taxonomy was registered the url rewrite rules were
created using the sanitized version of the attribute name, which
implies converting these characters into the urlencoded version.
The fix consists of applying "urldecode" to the sanitized attribute
name before using it to create the rewrite rule. The sanitization
needs to be kept for compatibility purposes, since it also replaces
latin characters with accents into the non-accent versions
(this conversion won't be affected by "urldecode")
WC was erroneously adding wc- prefix to the core WP auto-draft status.
#22380 registered it formally but we don't need it.
I've reverted #22380 and handled the prefix correctly.
This commit changes the value of the option 'woocommerce_queue_flush_rewrite_rules' to 'no' instead of deleting it when rewrite rules are flushed. This way this option is autoloaded and the `get_option()` call below doesn't trigger a select query to the database on every request.
61f037060b/includes/class-wc-post-types.php (L514)
WC seems to use 'yes' and 'no' instead of 'true' and 'false' as the values of boolean options, so this commit changes the value of the option woocommerce_queue_flush_rewrite_rules to follow this pattern. Also, the string 'false' can induce bugs as it is truthy.
Since WC 3.3.1, the following query is executed on every page load:
```
UPDATE `wp_options` SET `option_value` = '1' WHERE `option_name` = 'current_theme_supports_woocommerce'
```
This is happening because of the following call to `update_option()`:
```
update_option( 'current_theme_supports_woocommerce', current_theme_supports( 'woocommerce' ) ? 1 : 0 )
```
(02cac7d637/includes/class-wc-post-types.php (L268))
`update_option()` shouldn't update the option when the value hasn't changed, but in this case it is updating on every request because, when the current theme supports WC, `1` (integer) is passed to `update_option()` and this function internally compares it against the old value stored in the database which is `"1"` (string). A strict comparison (`===`) is used (f3eaddd2dc/wp-includes/option.php (L343)), so the function assumes that the value changed and proceeds with the update.
This PR fixes this problem by using the values `"yes"` and `"no"` instead of `1` and `0`.
To test, set shop page slug and name to `חנות` then set permalinks to
shop base.
Repeat that before and after patch.
Shop page 404 errors before patch.
Fixes#15111