Summary:
Cornerstone throws an uncaught TypeError on wp-admin/nav-menus.php for any user role that lacks the delete_users WordPress capability. The error occurs even when the role has full access to the Menus screen itself (i.e., edit_theme_options is granted and nothing is restricting the page via a third-party access-control plugin). Administrator (which has every capability) is unaffected; a custom role without delete_users reproduces it 100% of the time.
Environment:
- Relevant plugins: Advanced Access Manager (used for role/capability management), ACF Pro
- Confirmed the issue persists after updating Pro/Cornerstone to the latest available version as of July 15, 2026 — updating did not resolve it.
Steps to reproduce:
- Create or use a custom WordPress role that has
edit_theme_options(so Appearance/Menus is accessible) but does not havedelete_users. - Log in as a user with that role.
- Navigate to Appearance → Menus (
wp-admin/nav-menus.php). - Page fails to load — “There has been a critical error on this website.”
Expected behavior: The Menus page should load normally for any role that has the capability to access it, regardless of unrelated capabilities like delete_users .
Actual behavior: Fatal error.
Error log:
PHP Warning: Undefined array key "deps" in /wp-content/themes/pro/cornerstone/includes/classes/Services/Admin.php on line 165
PHP Fatal error: Uncaught TypeError: array_unique(): Argument #1 ($array) must be of type array, null given in /wp-content/themes/pro/cornerstone/includes/classes/Services/Admin.php:165
Stack trace:
#0 /wp-content/themes/pro/cornerstone/includes/classes/Services/Admin.php(165): array_unique()
#1 /wp-includes/class-wp-hook.php(341): Themeco\Cornerstone\Services\Admin->enqueue()
#2 /wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters()
#3 /wp-includes/plugin.php(522): WP_Hook->do_action()
#4 /wp-admin/admin-header.php(123): do_action()
#5 /wp-admin/nav-menus.php(780): require_once('...')
#6 {main}
thrown in /wp-content/themes/pro/cornerstone/includes/classes/Services/Admin.php on line 165
Root cause (as far as I’ve isolated it): Services\Admin->enqueue() appears to build a dependency array keyed in a way that depends on current_user_can('delete_users') (or an equivalent internal check tied to that capability) somewhere upstream of line 165. When that capability is absent, the resulting 'deps' key is missing entirely rather than defaulting to an empty array, and the subsequent array_unique() call on the undefined value throws a fatal TypeError . I did not trace the exact line(s) building that array upstream of 165 — only isolated the triggering capability via role/capability bisection.
Suggested fix: Line 165 should defensively coalesce to an empty array before calling array_unique() , e.g. array_unique( $var['deps'] ?? [] ) , and/or whatever capability check feeds that array shouldn’t gate on delete_users for what is fundamentally an asset-enqueue operation unrelated to user management.
Workaround currently in place (client-side): A must-use plugin that grants delete_users contextually only while $pagenow === 'nav-menus.php' , scoped to the affected role. This avoids permanently over-privileging the role but is a workaround, not a fix, and should be removable once patched upstream.