elaborate
Forum Replies Created
-
I just encountered the issue again. It looks like the culprit is not whether the plugin has been running for a while, but instead an incompatibility with LiteSpeed Cache, which isn’t correctly busting its cache. Disabling LiteSpeed fixes the issue. I’ve updated LiteSpeed Cache to version 7.5.0.1, but the issue still occurs.
I’ll file a bug report with LiteSpeed Cache as well, but I would appreciate if you could share your thoughts on what might be source of the incompatibility. I’ve tried toggling the “block menu cache” option before and after disabling and updating Litespeed Chace, but it doesn’t have any effect.
Thanks again.Hello Usman,
That is excellent news! Thank you for the update.
Sincerely,
MagnusHi @woobewoo,
Has your development department been able to confirm the two different compatibility issues above?Excellent! Thank you for the response.
Forum: Reviews
In reply to: [Classic Menu in Navigation Block] Lets you spare your clients from GutenbergThank you for the response.
I’m not surprised to hear the placement decision came down to a Gutenberg limitation. I didn’t realize the menus continue to work after you deactivate the plugin, though. It sounds like you’re importing the classic menus into the Navigation blocks when tbe menus are updated? Anyway, that’s a neat feature. I’ll definitely keep it in mind.
Thanks for making your plugin available. It’s made my life easier 🤙Thanks for the update!
Thanks Mia, that fixed the issue! I appreciate the help and the quick turnaround. You guys rock 🤙
@alina98 Thanks for the update 🙏
Thank you for the quick update, I appreciate that you’re looking into it.
I can confirm that the issue is solved in the patch you’ve included.
Thanks for the help!Thanks, but it looks like this issue only involves the Order Items element.
Perfect, thank you for pointing that out!
Forum: Plugins
In reply to: [WooCommerce] Unable to Save “From” Email Address in WooCommerce SettingsI’m encountering the same issue on WooCommerce 9.7.0 and WordPress 6.7.2. I’ve also disabled all other plugins. It doesn’t matter which address I try to use, the field is always blank after I reload.
This is the output in the developer console after opening the page (same after submitting the address), but I’m not sure it’s relevant:[Log] JQMIGRATE: Migrate is installed, version 3.4.1 (load-scripts.php, line 5)
[Error] Store "core/interface" is already registered.
c (data.min.js:2:20195)
register (data.min.js:2:21706)
95590 (index.js:2:16588)
webpack_require (index.js:2:181921)
(anonymous function) (index.js:2:218326)
(anonymous function) (index.js:2:646304)
Global Code (index.js:2:646368)
[Warning] select control in @wordpress/data-controls is deprecated since version 5.7. Please use built-in resolveSelect control in @wordpress/data instead. (deprecated.min.js, line 2)I also have a screen recording of the issue. Let me know if you need a copy.
@woobewoo Thank you.
It looks like there’s another incompatibility with AWS.
If you apply the WBWwpf_fbv=1query parameter to an AWS query that returns paginated results, the search results page breaks, showing zero results with the pagination buttons still visible. Thewpf_fbv=1parameter controls the “filtering by variations attributes” option, which is enabled for all new filters by default.
For instance, sorting paginated AWS search results with a default WBW “sort by” filter always returns 0 results whenwpf_fbv=1is applied, which it is by default.
Here’s an example of page 2 of a regular WooCommerce search query:example.com/page/2/?s=test&post_type=product
Here’s the same query with AWS applied:example.com/page/2/?s=test&post_type=product&type_aws=trueHere’s the query with both AWS and WBW sorting applied, with “filtering by variations attributes” disabled:
example.com/?s=test&post_type=product&type_aws=true&orderby=price-descHere’s the query with “filtering by variations attributes” enabled:
example.com/?s=test&post_type=product&type_aws=true&orderby=price-desc&wpf_fbv=1
The last query breaks the results page.
As you can see in the examples above, WBW alters the URL structure for paginated search results by dropping the/page/2/part of the URL, which is used to indicate which page is currently being shown. The behavior is controlled by the “enable AJAX” option in the admin pages, but disabling AJAX doesn’t fix the issue.
I’ve confirmed the issue is only present when both AWS and WBW are active. Filtering regular WooCommerce results withwbf_fbv=1works just fine, and paginated AWS search results also work normally when they’re not filtered by WBW.On second look, it turns out the Javascript isn’t the culprit after all.
Instead, it’s the “multiblock taxonomy logic” option that’s the cause. It was set to “or”. If I remove the query parameterwpf_filter_tax_block_logic, there’s no issue. Setting it to eitheror
orandresults in an empty search results page.
It looks like there’s an incompatibility issue when using it in conjunction with Advanced Woo Search. I’ve recreated the issue on a staging site. To recreate it, you need a filter menu with at least two blocks, e.g., a price slider and a product attribute, and the “multiblock taxonomy logic” set to “or”. Applying just one of the filters, e.g., selecting a price ceiling, should trigger the issue.
Maybe you could take a look yourselves?