Fabri

I have seen the changes, someone has suggested to the programmer to add:

if ( ! function_exists( ‘is_user_logged_in’ ) ) {

require_once ABSPATH . ‘wp-includes/pluggable.php’;

}

this is a BIG BIG mistake!

You shouldn’t use WP internal libraries before you should.

And you do it as soon as you start the plugin WITHOUT ANY HOOK or wait for other plugins to load.

FOR THIS CAUSE IT IS CAUSING MULTIPLE PLUGINS FROM OTHER DEVELOPMENTS TO STOP WORKING

please correct it

suspicious calls from tribal-common library sending login and authentication token, to url =https://us-central1-promoter-auth-connector.cloudfunctions.net/promoterConnector/connect/auth

OK thanks!!!!

also think that there may be multisites with other memory needs or that the memory limit may be above 256mb.

possibly the best way would be for the operation to be similar to the core function wp_initial_constants () in wp-includes / default-constants.php

lines 35/59…. especially:

if (-1! == $ current_limit_int && (-1 === $ wp_limit_int || $ wp_limit_int> $ current_limit_int)) {

thank you very much again, great plugin

“but I really don’t understand your concern for this.”

Your bad practice has led to a production server to the loss of data

please watch as wordpress does and do not touch the server settings mindlessly

this is not true, WordPress uses WP_MEMORY_LIMIT constant, to be able to define what is the limit memory that can be used in the server.

you change it without any option or inform about the change you are going to make.

“Smush is not changing any server configuration”

@ini_set('memory_limit', '256M');

“The setting is reverted back after the process finishes”
excuse no1

“In any case, it’s not going to use more memory than allowed by the server.”
excuse no2

you have no idea how each server is configured and you do not know how the increase in available memory for each process can affect

• This reply was modified 5 years, 9 months ago by Fabri.

Ok Remy thanks
;D

ok Remy, thx

??

Maybe you’re too busy ranting instead of reading

Right. I have nothing else to do.

wait, yes, I have to fix hundreds of websites because his majesty had the happy idea to cancel a function of the wordpress core or cancel the query_vars [‘s’]

“in future versions of WooCommerce, SKU won’t be in post meta. It will be in a custom table.”

the same excuse.

and as in a future the sku will no longer be in post-meta,…. today I avoid that you can search for some other field…..

???????? 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, 6 months ago by Fabri.

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, 6 months ago by Fabri.

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

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, 6 months ago by Fabri.

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, 6 months ago by Fabri.