WIP: Fatal Error when Admin Menu Editor plugin is enabled

Browser: Chrome 110
OS: macOS / Windows / Linux / etc.
URL: Link to a page that illustrates this issue
Video: Short screen recording that illustrates this issue (free tool: jam.dev)

We use Admin Menu Editor on all our sites and the couple of test sites we’ve upgraded to 2.0 RC have critical errored. If we disable Admin Menu Editor then reenable it we can run RC but when we try and create a new user with editor permissions (WordPress permissions, not Bricks permissions) we critical error.

There’s obviously some interaction between the new permissions functionality in Bricks and other tools working with permissions.

Previous versions of Bricks have no issues. I don’t know if this is an issue with Bricks or the Admin Editor plugin but it could impact other tools doing permissions things in WordPress and Admin menu editor hasn’t had issue with other plugins that set user permissions such as User role editor or members in the past.

Here’s the PHP error we see

2025-06-30 12:39:40.890971 [NOTICE] [3690279] [203.118.137.168:51614:HTTP2-3#swapone.takahe.avoca.work] [STDERR] PHP Fatal error: Uncaught TypeError: Illegal offset type in isset or empty in /var/www/swapone.takahe.avoca.work/htdocs/wp-content/plugins/admin-menu-editor/modules/content-permissions/content-permissions.php:324
Stack trace:
#0 /var/www/swapone.takahe.avoca.work/htdocs/wp-includes/class-wp-hook.php(324): YahnisElsts\AdminMenuEditor\ContentPermissions\ContentPermissionsEnforcer->YahnisElsts\AdminMenuEditor\ContentPermissions{closure}()
#1 /var/www/swapone.takahe.avoca.work/htdocs/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#2 /var/www/swapone.takahe.avoca.work/htdocs/wp-includes/plugin.php(517): WP_Hook->do_action()
#3 /var/www/swapone.takahe.avoca.work/htdocs/wp-includes/post.php(1828): do_action()
#4 /var/www/swapone.takahe.avoca.work/htdocs/wp-content/themes/bricks/includes/custom-fonts.php(546): register_post_type()
#5 /var/www/swapone.takahe.avoca.work/htdocs/wp-includes/class-wp-hook.php(324): Bricks\Custom_Fonts->register_post_type()
#6 /var/www/swapone.takahe.avoca.work/htdocs/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#7 /var/www/swapone.takahe.avoca.work/htdocs/wp-includes/plugin.php(517): WP_Hook->do_action()
#8 /var/www/swapone.takahe.avoca.work/htdocs/wp-settings.php(727): do_action()
#9 /var/www/swapone.takahe.avoca.work/wp-config.php(151): require_once(‘…’)
#10 /var/www/swapone.takahe.avoca.work/htdocs/wp-load.php(55): require_once(‘…’)
#11 /var/www/swapone.takahe.avoca.work/htdocs/wp-blog-header.php(13): require_once(‘…’)
#12 /var/www/swapone.takahe.avoca.work/htdocs/index.php(17): require(‘…’)
#13 {main}
thrown in /var/www/swapone.takahe.avoca.work/htdocs/wp-content/plugins/admin-menu-editor/modules/content-permissions/content-permissions.php on line 324

2 Likes

Hi @brendyn,

Based on the error trace, this issue originates directly from the admin-menu-editor plugin. That line in the plugin is attempting to run isset() or empty() on an invalid offset type, which suggests a missing sanity check or assumption about the input data.

Since the error occurs within the plugin codebase, the best course of action is to report this to the plugin developer so they can either adjust their handling of custom capabilities or provide more context in case there’s something wrong on our end.

If you’re able to replicate the same issue without Admin Menu Editor active, let us know.

I’ve submitted a ticket with them.

2 Likes

The same error occurs in Publish Press Capabilities which we use in quite some of our projects. I agree it is always safe to check the data types but on the other hand: The convention is that the cap property of a post type should be a simple associative array of strings because a capability should be a string and not an array. I fear there will be some more crashes because of your unconventional storing of capabilities.

Hi @brendyn,

Looks like this is something we should handle on our end:

That sounds good - Admin Menu Editor released an update that sorts the specific issue but maintaining compatibility with other plugins sounds like an excellent idea. :slight_smile:

1 Like