Dekadinious

I filed a bug report in trac for this ??

Thanks!

It’s the ampersand. It is inserted into the database as “X & Y”. But term_exists does not escape it before checking for existence. It checks for “X & Y”, and that does not exist of course. So this is a problem that will happen with any term that has an ampersand in it, I would think. My tests at least show so.

This is surely not consistent behavior? One would think that any conversion of characters done in wp_insert_term should also be done when checking for the existence of that term?

Are they all main menu pages and not sub menu pages? I did a quick search from my phone on the code base of Members (is it from MemberPress?) on GitHub. Try create_roles instead?

Only if it’s the same plugin of course.

Try changing the priority on the hook to something like 99999 to see if that makes any difference? In admin_menu. I don’t know if it should. Are you sure you are using the correct slugs?

I guess it is because term_exists only checks for slugs, and if you pass it a name, it uses sanitize_title to convert to slug. wp_insert_term seems to also check for names. That’s kind of inconsistent behavior maybe?

Try the “admin_menu” hook instead of “admin_init”? From “remove_menu_page” code reference:

“This function should be called on the admin_menu action hook. Calling it elsewhere might cause issues: either the function is not defined or the global $menu variable used but this function is not yet declared.”

Ok, thanks! ??

Removing the time limit and triggering using a file checked for by Cron is one way to go. But it’s better to go via CLI IMHO. Then I can also trigger this manually from the terminal when needed and have better control over all ??

The testing on XAMPP is just because of my lack of knowledge in the matter. I thought everything on XAMPP ran in a sort of Unix based VM, and that exec would work just like I was expecting. I have since learned that this is not the case, and that testing such operations in an environment matching production is prudent ??

By the way, > /dev/null 2>&1 & was what was needed to get it to work in the end in production ?? It now works as a charm!

The problem is that XAMPP on Windows won’t run these things in the background the way Unix-based systems will. I thought XAMPP running Apache etc. would be enough, but it’s not.

        if (substr(php_uname(), 0, 7) == "Windows") {
            pclose(popen("start /B " . $cmd, "r"));
        } else {
            exec($cmd . " > /dev/null &");
        }

The above code will work. You need to use pclose and popen in your local environment if that is on Windows. Then you can use the normal > /dev/null & in your production environment if that is running on Linux.

• This reply was modified 2 years, 11 months ago by Dekadinious.

Wouldn’t that still run into timeout issues?

Yeah, it only alters the “timeout” and not the “connect_timeout” that I was looking for!

But thanks! ??

Sorry, I might be a bit OCD about this, but I need to understand how it works. Why do the products sync when product sync is disabled? Even if we want the products to sync, I need to understand why they sync when they supposedly should not?

Because if we later want them to not sync, that setting should do it, right? But it doesn’t?

Hello and thanks for your answer!

This was actually discovered after a misunderstanding at work. I had disabled the syncing of products because our Facebook manager person did not want the shop page to appear on our page. At the same time, I guess they figured out how to disable it. I thought that the disabling of product sync did the trick, but those managing Facebook actually want the products to sync because of ads!

So we have gone for half a year where I have thought no products have been synced and they have had all new products synced to use in ads. We have specific products we absolutely don’t want to sync, and those are disabled on a per product basis. That seems to work.

wc_facebook_enable_product_sync is set to “no”, and has been that way for at least 6 months. Products that did not exist in our store until last week are in our Facebook catalouge.

So I guess I just wanted to know what is supposed to happen with the different options. The way it is now is fine, but if a new update can suddenly disable product sync because it is set to “no”, then I will need to activate it again!

Done, will resolve this ticket ??

Is this implemented? Can you give any feedback here at all?