woocommerce nightmare (again), this time: product searches
-
unfortunately, since every woocommerce update is a nightmare and a constant waste of time.
This time, it has occurred to them to hack WordPress itself.
/plugins/woocommerce/includes/admin/list-tables/class-wc-admin-list-table-products.php, on line 466
unset ($ query_vars [‘s’]);
¿? ¿¿¿¿? ¿¿?!?!?! ¿?!? ¿¿!?! ¿WTF?! ??!?
consequence: in a text search
$ wp_query-> query_vars [‘s’] = null;
the core function is_search () = false
any other plugin that wants to perform a textual search in the product administration, is automatically out of service.
in addition, its own function $ data_store-> search_products () does not support hooks or actions, bravo !!
thank you very much automatic
-
Hi there @fabrisancho
I appreciate your frustration if you are running into troubles with each update.
Can you let me know which version of the plugin this update was, please?
This time, it has occurred to them to hack WordPress itself.
/plugins/woocommerce/includes/admin/list-tables/class-wc-admin-list-table-products.php, on line 466
unset ($ query_vars [‘s’]);This change was in the
3.3
release which has been out for some time now.This forum is for product support for the WooCommerce plugin but for developer focused discussions, I’d recommend posting a new GitHub Issue around this.
We wouldn’t be able to offer the same technical level of discussion on the forum as they can on GitHub.
Thanks,
I created the issue, I bet you to beer that the answer to the issue is “no” and a lot of excuses
and unfortunately enter into a discussion with a developer to which you have given feedback for a thing that has been done wrong, it is a waste of time
I have never seen an answer of the type:
“Yes, we have made a mistake, instead of doing simple things and using the search system of the WordPress core and that the whole community can continue using the cms functionality … I have reinvented the wheel, I’m sorry”
//snippet, remove new woocommerce textual search by sku add_filter( 'request', function($query_vars) { global $wp_filter; foreach($wp_filter['request']->callbacks as $priority=>$callbacks) { foreach($callbacks as $unique_id=>$filter_array) { if ( is_array($filter_array['function']) && is_object( $filter_array['function'][0] ) && get_class( $filter_array['function'][0] ) && get_class( $filter_array['function'][0] ) == 'WC_Admin_List_Table_Products' && $filter_array['function'][1] == 'request_query' ) { unset( $wp_filter['request']->callbacks[ $priority ][ $unique_id ] ); } } } return $query_vars; },9,1);
They did it for a reason: https://woocommerce.com/2018/01/extending-crud-data-stores/
And why the negativity? Looking at GitHub they take issues very seriously and they answer polite. They might even accept your pull request if you have a better solution.
They did it for a reason ...
excuse, what reason there is to deny the possibility that a user can perform a search for a post-meta or a custom textual search?
What reason is there to empty the value of wp_query-> query_vars [‘s’]? and remove the functionality of the core function is_search ()?negativity? nope, I’m super happy with the lost time and redo programming every time they think of reinventing the wheel ….
Wow, count to 10…
They don’t deny the possibility to perform a custom textual search. Mike answered your GitHub issue with a workaround:
“During a product_search, filter the main WP query and add extra params there or pass in extra IDs to the post__in parameter.”
I understand it feels a bit hacky, but for your case at least it is a solution.
Software evolves. This transition to abstracted CRUD of WooCommerce classes unfortunately currently needs some adjustment from us, plugin developers, but I’m sure you understand why this needs to be done.
They don’t deny the possibility to perform a custom textual search.
Cough, cough , see see:
https://github.com/woocommerce/woocommerce/issues/20142#issuecomment-390610624
mikejolley response:
I don't see a reason to search any other core data.
my previous message:
I bet you to beer that the answer to the issue is “no” and a lot of excuses
-
This reply was modified 6 years, 8 months ago by
Fabri.
https://github.com/woocommerce/woocommerce/issues/20142#issuecomment-390610624
Just bare in mind any post meta search will be very expensive performance wise.
excuse
We search title, description, excerpt, and SKU. These are the most important fields. I don't see a reason to search any other core data.
excuse
leaves the function of the core is_search () = false........ A custom query var is added so you can detect when search is happening - product_search
reinventing the wheel
issue closed….
-
This reply was modified 6 years, 8 months ago by
Fabri.
You are very selective in your quotes. Did you see the solution offered by Mike? It is possible to perform a custom textual search. Léelo bien. ¡Si se puede!
The PR was denied because it breaks the data store when products are migrated to their own table.
obviously, it is super super super weird that someone wants to search for some other field
Maybe reply to the GitHub comment instead of moaning over here?
No other core meta data is freeform, so I stand by my reasoning. SKU is the most important field to search from meta. There have been no other requests from users I’ve seen for searching other fields. Each comes with a performance cost.
There *could* be a case to search non-core data e.g. a field added by a plugin, for which the work arounds I gave should be valid.
You’ve had several ‘excuses’ now to explain why this was done. Sounds like you’re not interested in the reasoning?
It’s very easy to sit back and claim everything is wrong–harder to understand why decisions are made, or how you can improve them. Adding a filter to disable everything is the lazy way out 🙂 As I said I GitHub, it will break in the future and you’ll be back here in 6 months with broken code.
ciao
Yes, I have seen the offered solutions
1>During a product_search, filter the main WP query and add extra params there or pass in extra IDs to the post__in parameter
really? they tell me to hack them wp_query? Bravo!!!
2>Suggest a filter for search_products (either the query, or the returned IDs). IDs would probably be better so we're not just supporting query manipulation.
and the core functionality “is_seach ()”? we forgot? totally sure that it is useless. As they are from Automatic, I suppose that in WordPress 5 they definitely remove it ……..
ok ok pull request done, now we’ll see the next batch of excuses xD
There *could* be a case to search non-core data e.g. a field added by a plugin, for which the work arounds I gave should be valid.
Another excuse, since when the post-meta are not part of the core?
since when the is_search () function is not part of the core?
why do you override $ query_vars [‘s’]?
ohhhhh wp_query-> query_vars now is no longer core?
-
This reply was modified 6 years, 8 months ago by
Fabri.
When I say core, I’m talking about WooCommerce core, not posts and WordPress core.
See my comment here https://github.com/woocommerce/woocommerce/pull/20160#issuecomment-390921027 -.-
¿?¿?¿?¿? woocommerce is a plugin not core.
your _sku is in post meta table (core) value , my custom field is a post meta (core) value, same as yours
when you avoid the possibility that I do a search for my own field (like yours), canceling the function of the core is_search () and emptying query_vars [‘s’]…… bravo!! funnny!!!
How easy was it to solve the problems by emptying query_vars …….. right?
-
This reply was modified 6 years, 8 months ago by
Fabri.
As I said earlier in future versions of WooCommerce, SKU won’t be in post meta. It will be in a custom table.
Maybe you’re too busy ranting instead of reading 🙂 bravo!!
-
This reply was modified 6 years, 8 months ago by
- The topic ‘woocommerce nightmare (again), this time: product searches’ is closed to new replies.