Using bricks_is_builder_main() hook throws PHP error about being 'undefined'

Trying to follow the steps from BricksLabs here: WordPress Toolbar (Admin Bar) in Bricks editor - BricksLabs

// Show WP admin bar in Bricks editor.
add_action( 'init', function () {
	// if this is not the outer frame, abort
	if ( ! bricks_is_builder_main() ) {
		return;
	}

	add_filter( 'show_admin_bar', '__return_true' );
} );

The snippet above I run in WPCodeBox and it works but routinely logs PHP errors. I’m trying to understand if there’s a different way for this to run where I can avoid the PHP errors in my logs.

It isn’t a WPCodeBox thing to my knowledge as I can reproduce this very same behaviour if I use the code in a custom plugin instead.

Should I be running this at a different hook or location? For what it’s worth, if I use that snippet in the theme’s functions.php it works without PHP errors, so I suspect this is more of a position/hook issue when run as a plugin for example.

Here are the PHP errors I see in my logs which seem to display every 60 seconds:

Mar 13 00:16:53 PHP Fatal error: Uncaught Error: Call to undefined function bricks_is_builder_main() in /app/data/public/wp-content/plugins/wpcodebox/src/Runner/QueryRunner.php(119) : eval()'d code:10
Mar 13 00:16:53 Stack trace:
Mar 13 00:16:53 #0 /app/data/public/wp-includes/class-wp-hook.php(308): Wpcb\Runner\QueryRunner->{closure}()
Mar 13 00:16:53 #1 /app/data/public/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
Mar 13 00:16:53 #2 /app/data/public/wp-includes/plugin.php(517): WP_Hook->do_action()
Mar 13 00:16:53 #3 /app/data/public/wp-settings.php(617): do_action()
Mar 13 00:16:53 #4 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1336): require('...')
Mar 13 00:16:53 #5 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1254): WP_CLI\Runner->load_wordpress()
Mar 13 00:16:53 #6 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(28): WP_CLI\Runner->start()
Mar 13 00:16:53 #7 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(78): WP_CLI\Bootstrap\LaunchRunner->process()
Mar 13 00:16:53 #8 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(32): WP_CLI\bootstrap()
Mar 13 00:16:53 #9 phar:///app/pkg/wp/php/boot-phar.php(11): include('...')
Mar 13 00:16:53 #10 /app/pkg/wp(4): include('...')
Mar 13 00:16:53 #11 {main}
Mar 13 00:16:53 thrown in /app/data/public/wp-content/plugins/wpcodebox/src/Runner/QueryRunner.php(119) : eval()'d code on line 10
Mar 13 00:16:53 Fatal error: Uncaught Error: Call to undefined function bricks_is_builder_main() in /app/data/public/wp-content/plugins/wpcodebox/src/Runner/QueryRunner.php(119) : eval()'d code:10
Mar 13 00:16:53 Stack trace:
Mar 13 00:16:53 #0 /app/data/public/wp-includes/class-wp-hook.php(308): Wpcb\Runner\QueryRunner->{closure}()
Mar 13 00:16:53 #1 /app/data/public/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
Mar 13 00:16:53 #2 /app/data/public/wp-includes/plugin.php(517): WP_Hook->do_action()
Mar 13 00:16:53 #3 /app/data/public/wp-settings.php(617): do_action()
Mar 13 00:16:53 #4 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1336): require('...')
Mar 13 00:16:53 #5 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1254): WP_CLI\Runner->load_wordpress()
Mar 13 00:16:53 #6 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(28): WP_CLI\Runner->start()
Mar 13 00:16:53 #7 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(78): WP_CLI\Bootstrap\LaunchRunner->process()
Mar 13 00:16:53 #8 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(32): WP_CLI\bootstrap()
Mar 13 00:16:53 #9 phar:///app/pkg/wp/php/boot-phar.php(11): include('...')
Mar 13 00:16:53 #10 /app/pkg/wp(4): include('...')
Mar 13 00:16:53 #11 {main}
Mar 13 00:16:53 thrown in /app/data/public/wp-content/plugins/wpcodebox/src/Runner/QueryRunner.php(119) : eval()'d code on line 10

Since you’re calling a function that is provided by a theme I’d say using the after_setup_theme hook would be the correct option.

Thank you for the suggestion. I should have added earlier as I had run that test before, but changing “init” to “after_setup_theme” doesn’t change the behaviour at all. Unless you meant something different than I understood?

Here’s what I had tried:

add_action("after_setup_theme", function () {
    // if this is not the outer frame, abort
    if (!bricks_is_builder_main()) {
        return;
    }
    add_filter("show_admin_bar", "__return_true");
});

Both init and after_setup_theme will be firing too early.

Here’s the list of hook and the order The WordPress Hooks Firing Sequence! • RachieVee: Rachel's Blog

It would need run somewhere after init, but before admin_bar_init. (most likely wp_loaded from reading it quickly, but haven’t tested it)

1 Like

Thanks David! I tried a few of those options but unfortunately none seemed to work. It’s very confusing to me why this works fine in the functions.php file without causing PHP errors in the logs. For now I’m setting it in the functions.php file of a child theme but I’m ultimately wanting to make a plugin that sets this (among many other snippets) which I’d be able to easily distribute to my client sites using MainWP for example. Will help me easily update various commonly used snippets for my clients WordPress instances, and it all works really well except for this one particular Bricks-specific snippet. :confused:

I just tried this on a test instance and I do not see any warnings in my debug.log using the brickslabs.com code. :face_with_raised_eyebrow:

So strange. I just set mine up the exact same (same snippet order and changed to “Root” hook. My logs still show the same errors.

Mar 14 22:02:16 => Run cron job
Mar 14 22:02:16 PHP Fatal error: Uncaught Error: Call to undefined function bricks_is_builder_main() in /app/data/public/wp-content/plugins/wpcodebox/src/Runner/PhpSnippetRunner.php(22) : eval()'d code:6
Mar 14 22:02:16 Stack trace:
Mar 14 22:02:16 #0 /app/data/public/wp-includes/class-wp-hook.php(308): Wpcb\Runner\PhpSnippetRunner->{closure}()
Mar 14 22:02:16 #1 /app/data/public/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
Mar 14 22:02:16 #2 /app/data/public/wp-includes/plugin.php(517): WP_Hook->do_action()
Mar 14 22:02:16 #3 /app/data/public/wp-settings.php(617): do_action()
Mar 14 22:02:16 #4 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1336): require('...')
Mar 14 22:02:16 #5 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1254): WP_CLI\Runner->load_wordpress()
Mar 14 22:02:16 #6 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(28): WP_CLI\Runner->start()
Mar 14 22:02:16 #7 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(78): WP_CLI\Bootstrap\LaunchRunner->process()
Mar 14 22:02:16 #8 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(32): WP_CLI\bootstrap()
Mar 14 22:02:16 #9 phar:///app/pkg/wp/php/boot-phar.php(11): include('...')
Mar 14 22:02:16 #10 /app/pkg/wp(4): include('...')
Mar 14 22:02:16 #11 {main}
Mar 14 22:02:16 thrown in /app/data/public/wp-content/plugins/wpcodebox/src/Runner/PhpSnippetRunner.php(22) : eval()'d code on line 6
Mar 14 22:02:16 Fatal error: Uncaught Error: Call to undefined function bricks_is_builder_main() in /app/data/public/wp-content/plugins/wpcodebox/src/Runner/PhpSnippetRunner.php(22) : eval()'d code:6
Mar 14 22:02:16 Stack trace:
Mar 14 22:02:16 #0 /app/data/public/wp-includes/class-wp-hook.php(308): Wpcb\Runner\PhpSnippetRunner->{closure}()
Mar 14 22:02:16 #1 /app/data/public/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
Mar 14 22:02:16 #2 /app/data/public/wp-includes/plugin.php(517): WP_Hook->do_action()
Mar 14 22:02:16 #3 /app/data/public/wp-settings.php(617): do_action()
Mar 14 22:02:16 #4 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1336): require('...')
Mar 14 22:02:16 #5 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1254): WP_CLI\Runner->load_wordpress()
Mar 14 22:02:16 #6 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(28): WP_CLI\Runner->start()
Mar 14 22:02:16 #7 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(78): WP_CLI\Bootstrap\LaunchRunner->process()
Mar 14 22:02:16 #8 phar:///app/pkg/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(32): WP_CLI\bootstrap()
Mar 14 22:02:16 #9 phar:///app/pkg/wp/php/boot-phar.php(11): include('...')
Mar 14 22:02:16 #10 /app/pkg/wp(4): include('...')
Mar 14 22:02:16 #11 {main}
Mar 14 22:02:16 thrown in /app/data/public/wp-content/plugins/wpcodebox/src/Runner/PhpSnippetRunner.php(22) : eval()'d code on line 6
Mar 14 22:02:16 Error: There has been a critical error on this website.Learn more about troubleshooting WordPress. There has been a critical error on this website.
Mar 14 22:02:20 - - - [15/Mar/2023:05:02:20 +0000] "GET /wp-includes/version.php HTTP/1.1" 200 - "-" "Mozilla (CloudronHealth)"

What is the cron job the log is talking about in the first line?

It’s not any particular job, it’s just the WordPress cron that runs every sixty seconds to action any scheduled tasks. That’s what’s weird about this… I’m not sure why WordPress is seeing this code as something it needs to act on in a cron-like fashion when it works fine in functions.php. Not sure what makes this unique when declaring it anywhere else.

Finally got around to testing this. When I run the same code inside WPCodebox on a blank Bricks site, no error appears in the logs. So something else is going on, somehow you have the code running where it shouldn’t be.

For that, I don’t have a solution. It seems specific to your install/setup.

But just to prevent any errors, why not just check the function exists before checking it to be true/false. Then regardless of the reason for the above, it won’t matter.

add_action("init", function () {
    
    if ( !function_exists('bricks_is_builder_main') ) {
		return;
	}

    if ( !bricks_is_builder_main() ) {
        return;
    }
    add_filter("show_admin_bar", "__return_true");
});
3 Likes

I appreciate the help! I tried a fresh instance with only Bricks Builder installed but it still occurred for me for some reason. FWIW, I run WordPress on Cloudron as the platform which has never presented any issues or limitations, but am now wondering if perhaps the way the app is packaged may have something unique about this particular scenario (though it seems very strange, but hard to ignore that it seems to work fine for everyone else here who’s been helping). With that said, the “function_exists” PHP snippet seems to work perfectly fine. Saves all the errors in the logs every minute. Thanks so much for that tip! :slight_smile:

It’s similar to something i’ve come across before, but with people using Plesk.

We had code that was using a Bricks’ class (PHP class, not CSS class) and even though we knew the order that the code was executing was correct, and that the class must exist at the time the code was executing, (it was impossible for the plugin to be active without Bricks being active, and the code always ran after Bricks) Plesk still had an issue with it and threw an error saying the class didn’t exist.

I don’t use these platforms, but it seems whatever they’re doing. they’re going through and checking the code for errors, but not taking into account the order in which the code would be fired on the actual site. So errors are shown that aren’t actually errors on the site. For example, the error in your log says “PHP Fatal error”. If there was actually a real fatal error you would have known about it as it would have crashed the page and just white screen, it wouldn’t just be in the log.

So always checking functions and classes exist before using seems vital if using these platforms, even if you know 100% know the order is correct.

1 Like

Hey @wplit, just out of interest: When you say you don’t use these platforms… may I ask what you use to host your websites?

I do pretty much everything through GridPane now.

1 Like

@wplit & @aslotta - Just to finalize this one… I worked with the Cloudron team and turns out it was due to the way the cron job was configured to run in the app package. Seems it was skipping the themes and thus when running theme-related functions it was causing it to throw the errors since it was a function defined in the theme, or at least that’s my understanding of it. It’s been resolved already by their team and works great now. :slight_smile:

1 Like

Thanks for the update!