Strange Error – Missing settings on most tabs

OK. Thanks for reporting this.

It’s going to take a while to dissect that error message which is about 10-15 errors all wrapped into one.

It does seem to be tied to WP Engine and WP Rocket.

When you say “Almost all of the tabs on the settings page have no content” – is that just Style Pack or is it other parts of the WP admin panel too?

I think I see what’s happening and should have a modified version for you to test tomorrow.

The problems appears specific to the BBPress Styles plugin. You can see the issue here: https://imgur.com/a/fd5GMbN where I click on the display tab and no settings appear, click on a different tab and see the error I reported. A few tabs, like plugin information, dashboard admin, and translations do render properly (I didn’t do an exhaustive survey of the tabs, but I can if it will be helpful). Right now another plugin in masking the actual

Just to clarify, I am running/testing in a local development environment using the LocalWP development stack, which is owned and maintained by WPEngine (https://localwp.com/). Using WP Rocket for caching etc.

Thanks for jumping on this so quickly!

Update – this may not be limited to just your plugin. I noticed it happening when trying to save a new Avada Theme Layout.

What I suspect is that the plugin for WP Engine is not working properly in a local environment, but will work fine on their actual live production hosting. Working on a way to bypass WP Engine interactions for local environments.

Can you deactivate Style Pack and check the theme settings page again? I want to verify that it’s not the theme itself or some other plugin causing it.

• This reply was modified 1 year, 2 months ago by codejp3.

Ok, I disabled BB Style Pack (but not BBPress itself). Same problem when I try to edit an Avada Layout. Disabled BBPress as well, same issue. I am thinking this is unrelated to your plugin.

A few weeks ago I was editing the Avada Layouts without any problems. Not sure what may have changed.

Bizarre, deactivating WP Rocket didn’t help. But commenting out the the wp-config.php directive

define( 'WP_CACHE', true );

without deactivating the wp-rocket, or setting the value in the directive to false, again without deactivating wp-rocket, solves the problem.

Here’s what I have figured out.

ROOT CAUSE:

You have a WP Engine plugin running on your local site:

WP Engine Common

“The wpengine-common plugin provides most of the WP Engine platform functionality. Platform features provided by this plugin can be seen in your wp-admin dashboard under the WP Engine menu icon.” (towards the bottom of that link)

PROBLEM:

Some of the functionality that that plugin offers (maybe even most or ALL functionality ) will NOT work unless it’s running on active WP Engine web hosting. That means the classes and methods being called won’t work and will error out on your local site.

ERROR BREAKDOWN:

Cause of the error is within /wp-content/mu-plugins/wpengine-common/plugin.php

Fatal error:
Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /wp-content/mu-plugins/wpengine-common/plugin.php:1348
Stack trace:
#0 /wp-content/mu-plugins/wpengine-common/plugin.php(1638): WpeCommon::is_object_cache_enabled()

ERROR TRIGGERS:

Error is triggered by both WP Rocket and bbP Style Pack, because both plugins look for WP Engine and clear WP Engine caches if the WP Engine plugin is found (specifically classes and methods for WP Engine, and they’re typically only found on actual WP Engine web hosting servers).

WP Rocket triggering the error:
#1 /wp-content/plugins/wp-rocket/inc/ThirdParty/Hostings/WPEngine.php(88): WpeCommon::purge_memcached()
#2 /wp-includes/class-wp-hook.php(312): WP_Rocket\ThirdParty\Hostings\WPEngine->clean_wpengine(‘/Volumes/G-DRIV…’)
#3 /wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters(NULL, Array)
#4 /wp-includes/plugin.php(517): WP_Hook->do_action(Array) 5 /wp-content/plugins/wp-rocket/inc/functions/files.php(860): do_action(‘after_rocket_cl…’, ‘/Volumes/G-DRIV…’, ”, ‘https://kornfel…’)

bbP Style Pack triggering the error:
#6 /wp-content/plugins/bbp-style-pack/includes/functions.php(3449): rocket_clean_domain()
#7 /wp-content/plugins/bbp-style-pack/includes/settings_topic_preview.php(17): bsp_clear_cache()

PLAIN ENGLISH:

With all that said, based on the error stack trace you posted here, it seems pretty clear what’s happening.

WP Rocket and WP Engine are just 2 of the roughly 20+ caching plugins/hosting platforms that Style Pack integrates with.

With bbP Style Pack + WP Rocket active:
1.) Style Pack says “hey WP Rocket, empty your caches”
2.) WP Rocket says “hey WP Engine, empty your caches”
3.) WP Engine says “hey self, empty your caches….oh wait…. caches aren’t available since I’m not on the WP Engine hosting server so kick out a fatal error instead”

With just Style Pack active:
1.) Style Pack says “hey WP Engine, empty your caches”
2.) WP Engine says “hey self, empty your caches….oh wait…. caches aren’t available since I’m not on the WP Engine hosting server so kick out a fatal error instead”

With just WP Rocket active:
1.) WP Rocket says “hey WP Engine, empty your caches”
2.) WP Engine says “hey self, empty your caches….oh wait…. caches aren’t available since I’m not on the WP Engine hosting server so kick out a fatal error instead”

With just the WP_CACHE global value set to true and other plugins deactivated:
1.) WP Engine says “hey self, empty your caches….oh wait…. caches aren’t available since I’m not on the WP Engine hosting server so kick out a fatal error instead”

I hope that plain English break-down is clear enough.

POSSIBLE FIX:

I think the best way to “fix” this issue is to account for whether the site is running on your local dev environment or the WP Engine web hosing server.

If local: set WP_CACHE to false and move
/wp-content/mu-plugins/wpengine-common/
to
/wp-content/mu-plugins-disabled/wpengine-common/

If live on WP Engine hosting: set WP_CACHE to true and move
/wp-content/mu-plugins-disabled/wpengine-common/
to
/wp-content/mu-plugins/wpengine-common/

Some UNTESTED code for this would look something like:

// recursive move and remove functions
// https://stackoverflow.com/questions/9835492/move-all-files-and-folders-in-a-folder-to-another

// Function to remove folders and files 
function rrmdir( $dir ) {
    if ( is_dir( $dir ) ) {
        $files = scandir( $dir );
        foreach ( $files as $file ) {
            if ( $file != "." && $file != ".." ) rrmdir( $dir.DIRECTORY_SEPARATOR.$file );
        }
        rmdir( $dir );
    }
    else if ( file_exists( $dir ) ) unlink( $dir );
}

// Function to Copy folders and files       
function rcopy( $src, $dst ) {
    if ( file_exists ( $dst ) )
        rrmdir ( $dst );
    if ( is_dir ( $src ) ) {
        mkdir ( $dst );
        $files = scandir ( $src );
        foreach ( $files as $file )
            if ( $file != "." && $file != ".." ) {
                rcopy( $src.DIRECTORY_SEPARATOR.$file, $dst.DIRECTORY_SEPARATOR.$file );
            }
    } else if ( file_exists ( $src ) ) copy( $src, $dst );
}

function bsp_wpe_mu_path() {
    return WPMU_PLUGIN_DIR.DIRECTORY_SEPARATOR.'wpengine-common';
}
function bsp_wpe_mu_disabled_path() {
    return WP_CONTENT_DIR.DIRECTORY_SEPARATOR.'mu-plugins-disabled'.DIRECTORY_SEPARATOR.'wpengine-common';
}

// handle environment changes
if ( strpos( ABSPATH, 'LocalSites') !== false ) {
    
    // set WP_CACHE value to false
    if ( ! defined( 'WP_CACHE' ) ) define( 'WP_CACHE', false );
    else $GLOBALS['WP_CACHE'] = false;
    
    // move wpengine-common to disabled 
    rcopy( bsp_wpe_mu_path(), bsp_wpe_mu_disabled_path() );
    rrmdir( bsp_wpe_mu_path() );
    
}
else {
    
    // set WP_CACHE value to true
    if ( ! defined( 'WP_CACHE' ) ) define( 'WP_CACHE', true );
    else $GLOBALS['WP_CACHE'] = true;
    
    // move wpengine-common to mu-plugins
    rcopy( bsp_wpe_mu_disabled_path(), bsp_wpe_mu_path() );
    rrmdir( bsp_wpe_mu_disabled_path() );
    
}

There may be an easier way to accomplish this using a PHP constant or WP_ENVIRONMENT_TYPE, but as far as I can tell, it’s not 100% consistent between different environments and hosting, specifically with WP Engine.

Checking for something unique to your local environment (like specific root directory string) as I coded above may be the easiest method…at least for now.

You can add that code to your child theme (assuming you have one setup), or with the Code Snippets plugin (set to run everywhere) plugin. Keep in mind that it is untested and may need some tweaks o work 100% as expected.

IMPORTANT:

Please do us both a favor, and test out WP Rocket and Style Pack on your live WP Engine web hosting to verify that the errors disappear on actual WP Engine hosting servers. Do this before even messing with the code snippet above. You can set your site into maintenance mode (tons of plugins available for that) so that the general public doesn’t see your unfinished site. You just want to test for errors. If the errors are gone on actual WP Engine hosting, but come back when on your local dev environment, then something like the code snippet I posted above should “fix” the issue.

• This reply was modified 1 year, 2 months ago by codejp3. Reason: fix small typos

@mflc – just wanted to check back in with you and see if what I posted above makes sense, and if you’re able to verify that the error disappears on actual WP Engine hosting servers.

Also, looking at my code snippet, I can see that there should probably be an extra check for “if directory does not exist, create it” before the plugin directories are moved back and forth based on current running environment. If you do end up using the code snippet and need some help with modifying it to include that extra check, let me know!

Since this issue is not exclusively a Style Pack issue, but an overall issue with the WP Engine plugin being used on a local dev environment, I’m going to close the topic as resolved. Feel free to post back here if you have any additional questions.