• Resolved Fabri

    (@fabrisancho)


    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

Viewing 15 replies - 1 through 15 (of 20 total)
  • dougaitken

    (@dougaitken)

    Automattic Happiness Engineer

    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,

    Thread Starter Fabri

    (@fabrisancho)

    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”

    Thread Starter Fabri

    (@fabrisancho)

    //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.

    Thread Starter Fabri

    (@fabrisancho)

    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.

    Thread Starter Fabri

    (@fabrisancho)

    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.
    Thread Starter Fabri

    (@fabrisancho)

    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.

    Plugin Contributor Mike Jolley

    (@mikejolley)

    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

    Thread Starter Fabri

    (@fabrisancho)

    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

    Thread Starter Fabri

    (@fabrisancho)

    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.
    Plugin Contributor Mike Jolley

    (@mikejolley)

    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 -.-

    Thread Starter Fabri

    (@fabrisancho)

    ¿?¿?¿?¿? 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.
    Plugin Contributor Mike Jolley

    (@mikejolley)

    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!!

Viewing 15 replies - 1 through 15 (of 20 total)
  • The topic ‘woocommerce nightmare (again), this time: product searches’ is closed to new replies.