elaborate

Yeah, I can see that deregistering the jQuery script breaks the whole filtering feature. I’ll have to go with another solution, but thank you for the response. I’ll keep an eye out for updates.

That sounds great. Thank you for taking the time to respond.

Thanks for clarifying. There’s data there now, but it’s a little unexpected.

Thank you for the update. I’ve taken another look, and I can confirm the new Search Form block can be inserted into Navigation blocks.

I’ve also taken another look at the search form and results page. Your plugin reuses the existing search results page entirely, so the only step short of making the plugin a drop-in replacement is to switch the default search bar’s form handler to your plugin’s search feature. That comes down to just adding the hidden input <input type="hidden" name="type_aws" value="true">:

// Configure WooCommerce Product Search blocks to use the Advanced Woo Search plugin's search feature.
add_filter( 'render_block_core/search', 'redirectProductSearch', 10, 3 );
function redirectProductSearch( $block_content, $block, $instance ) {
  
  // Insert hidden input responsible for enabling the Advanced Woo Search plugin's search feature.
  $hidden_input = '<input type="hidden" name="type_aws" value="true">';
  $block_content = preg_replace('/<\/form>/', $hidden_input . '</form>', $block_content);
  return $block_content;
}

That solution won’t include the instant AJAX search results, but it enables all the other features seamlessly.

Maybe you could implement that to take a step closer to seamless integration, at least for users who have the AJAX feature disabled anyway?

Thanks for the repsonse.

What I’m describing regarding the Block editor is dragging the plugin’s Search Form block into a Navigation block, not just into the Header template block. WooCommerce has its own block called Product Search, which can be included in the Navigation block. I assume the Search Form is meant to replace Product Search, which is why I’m pointing it out.

Thank you, that fixed the issue. I can now add slides. I’ve updated the score and the review.

I’m not using an experimental plugin version of Gutenberg. I’m just on a default installation of WordPress with the Block Editor, version 6.6.2 specifically.

Thank you, that’s exciting to hear. I can picture some of the technical challenges involved, but I’ll be interested to hear about it if you do manage to find a good solution.

Thanks for taking the time to respond to my request. I appreciate it.

@rhyswynne I just saw this review after reading the description, and I don’t remember reading anything about a limit. What exactly is the limit and are any features disabled when it’s reached?

@moderator This post is a plugin review, not a support question. I’m aware of the distinction. Please move the thread back to the reviews section.

This is my second message asking to have the thread moved back to the reviews section. I don’t know why my first message appears to have been removed from the thread.

You’re asking if I’m referring to terms or taxonomies, right? I’m talking about taxonomies.

The plugin already dynamically includes all product attribute terms for a taxonomy that has been manually added to a filter group ahead of time, so that’s not what I’m asking about.

I’m asking about the ability to dynamically include all product attribute taxonomies in a filter group, optionally with a list of exceptions.

@alexcozmoslabs As mentioned above, this is a review and not a support topic, so you won’t find a support ticket from me.

The review evauates the decision to (1) advertise support for WooCommerce when support is in fact limited; and (2) the decision to leave data on the system after removal.

Those aren’t misunderstandings or support questions.

The free version of the plugin does not allow you to use Local Attributes in filters, and does not display Local Attributes when creating a filter.

That’s odd. I was able to select local attributes on the free version when initially setting up filters, and I did not notice any asterisks when doing so.

I only realized I was dealing with local attribtues because the filter did not display those attributes on the rendererd page, as I described above.

I’ve since removed those specific local attributes, and I can’t replicate the issue when adding new ones. I’ll keep an eye on it and report back if I figure out how to replicate it.

Thanks for looking into the issue.

Please describe this in more detail, preferably with a screenshot.

Sure. Here’s a color-coded illustration that hopefully makes it more clear:

In orange are groups of filters; in green are individual filters; and in purple are product attribtues.

What I’m asking is whether it’s possible—within a single, existing filter group (orange)—to automatically add a single, new individual filter (green) when a single new product attribute is created (purple)?

The scenario is that I’m setting up a webshop for a client. I would like the solution to be as low-maintainance as possible. The client would like to make all product attributes across the webshop filterable by the end user. The client knows how to manage products, including how to add product attributes, but I don’t want to ask the client to also manage the product filters if that task can be automated.

Thanks for responding, and thanks for using the correct term. I wasn’t aware they’re called local attributes.

I think you might have misunderstood me. It sounds like you assume I’m asking for some sort of integrating between your plugin and the WooCommerce product creation process. That’s not the case.

Your plugin already displays local attributes within your plugin’s admin panel. Local attributes are available when selecting which attributes to tie to a produt filter. I’m suggesting you either (1) stop listing local attributes as options when creating a product filter; or (2) display a warning if for some reason you can’t exclude them.