-
Hi. I am trying to add a Condition and when I click “Save Conditions”, it kicks me back out to the “Add New / Manage Categories” screen without saving the Condition.
I have done this multiple times including while the performance plugins are deactivated. Does this sound familiar?
Thanks for your time.
-
Hi there,
We haven’t received any similar reports about this so far, so this appears to be a new issue. I also copied the same condition setup to my own test site and was able to save it without any problems.
It would be helpful to check the WordPress error log to see if anything is being recorded there that might give us a clue.
-
Hi Alvind. Thanks for the response.
I checked the Kinsta error log, but am not seeing anything. Also turned this on in wp-config.php.
if ( !defined( 'WP_DEBUG' ) ) { define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 ); }But there’s nothing related to GB wp-content/debug.log after I try to save the Condition. I added some example lines from the log in the private area to show what I am talking about.
In any case, I found another way to achieve what I was trying to do originally. So we can close this ticket. Although, it would be good to find the issue.
On a related note, I gather that I can use CSS selectors to look at the <body> tag classes to selectively use “display: none”.
-
Sure, no problem 🙂
We’ll continue monitoring for additional reports of similar behavior, as it’s difficult to properly diagnose the issue without being able to reproduce it.
If you have the chance to set up a staging site, it would be helpful to perform a plugin conflict test by temporarily deactivating all non-GeneratePress/GenerateBlocks plugins. That would help determine whether a third-party plugin is interfering with the functionality.
-
Hi Alvind. I did the following.
1. Created a staging site.
2. Deactivated all plugins except for Generate-related ones.
3. Deleted the contents of functions.php.
4. Cleared Kinsta cache.
5. I tried the JSON in the private area AND just a super-simple one-liner.The problem still persists. Login creds are in the private area. I am not in need of this fix right now, but I can keep this inquiry up if it helps you reproduce the issue. Regards.
-
Thanks for the detailed information. Unfortunately, we’re unable to reproduce the issue in our environment. There is probably something going on at the server level.
If you have a chance, could you try bringing this up with Kinsta Support to see if they can find anything? If they identify anything that needs fixing on our side, just let us know.
-
Hi Alvind. I went over to Kinsta and the rep there decided to activate opcache on the staging site. I went into GenerateBlocks >> Conditions and saw a Condition was already saved – “Logged In”. I do not remember making that – was that from you?
Anyway, I decided to try making my own – “Test”. Sure enough, that worked. Please confirm you are seeing the same thing.
Going back to the live site, saving still does not work.
So now we seem to have a live site with all plugins activated that does not save AND a staging site with all plugins deactivated that does save. Assuming you are seeing the same thing, this now sounds like a plugin issue?
-
Hello,
Thanks for the update — that’s a really useful finding.
The opcache detail is interesting. It’s possible that without opcache, PHP is recompiling files on every request, and something in that process is interfering with how the condition save is being handled. It could also point to a PHP version mismatch or memory constraint between the live and staging environments.
A few things worth checking on the live site:
- PHP version — confirm the live site is running the same PHP version as staging
- opcache — ask Kinsta to enable opcache on the live site as well, since that’s what resolved it on staging
- PHP memory limit — worth checking if the live site has a lower limit;
WP_MEMORY_LIMITandWP_MAX_MEMORY_LIMITin wp-config.php, or ask Kinsta directly
If enabling opcache on live resolves it, that would confirm this is a server configuration issue rather than a plugin conflict.
-
Hi George. Thanks for the follow-up. According to the rep, Kinsta live sites always have opcache on. It is turned off, by default, for staging sites. So, I do not think that the opcache is the issue.
As for your other questions, the PHP version is 8.1 and each thread has 512MB memory.
That memory number sounds high to me, so that probably is not the issue. Latest PHP is 8.5, but the site has 8.1, which sounds reasonable too. I can select PHP 8.5, if desired, though.
Thoughts?
-
Hello,
Just to make sure I’m understanding correctly: opcache is always on for live sites at Kinsta, but the live site still can’t save conditions. And on staging, enabling opcache fixed it. Is that right?
If so, the difference between the two environments is likely something else — the most obvious candidate being the plugins that are active on live but not staging. It might be worth doing a conflict test on the live site: deactivate all non-GP/GB plugins temporarily, attempt to save a condition, then reactivate them one by one until the issue reappears.
PHP 8.1 is fine and memory shouldn’t be the issue at 512MB, so I’d focus on the plugin conflict angle first.
-
Hi George. Correct with a caveat – When opcache was manually activated on the staging site, all the plugins were already deactivated. On the live site, all the plugins are still activated because I simply cannot deactivate the plugins since it is a business-producing site.
That tells me that it is the combination of deactivating all plugins AND having an opcache that makes the Condition saving operation work.
Agreed that I will be focusing on the plugins now.
EDIT
I just went into the staging site and I can no longer see any saved Conditions. Also found about 75% of the plugins are reactivated – suggesting someone is testing which plugin is causing the problem. I will sit tight for a bit.
-
Hi,
Thanks for clarifying — that makes sense. The combination of opcache + no plugins confirms the direction.
One thing that might help on the live site: the Health Check & Troubleshooting plugin (by the WordPress team) has a Troubleshooting Mode that lets you deactivate plugins for your session only, without affecting other visitors. That way you could run the conflict test on live without any disruption to the business.
-
Hi George – I tried running the Troubleshooting Mode from the Health Check plugin and the whole site crashed.
I did find a workaround to the Conditions earlier. I intend to go back to the staging site at some point to play with the plugins, but that may not for a bit.
That said, I do not want to hold you and the Generate team up on this ticket. If you would like me to close it, I can.
On a related note – does a Condition run BEFORE the HTML is output or does a Condition equate to some CSS on the backend?
-
Hello,
No rush on your end — happy to leave the ticket open if you plan to revisit it on staging.
To answer your question: Conditions are evaluated server-side before any HTML is output. If the conditions aren’t met, the element simply isn’t rendered at all — there’s no CSS hiding involved.
- You must be logged in to reply to this topic.