Support

October 27, 2023 at 12:20 pm

Hi there,

The above error isn’t from Event Espresso, it’s likely from the wp heartbeat request sent within the WP admin and that’s running whist viewing registrations.

From looking at the code where that error is from it looks like something is calling to remove menu items but none at set on the request but that could be from pretty much any plugin.

Is that the full error shown?

October 27, 2023 at 12:35 pm

Hmmm, do you get that error when viewing any other pages or is the referrer always showing the above address?

(Note the error is from an ajax request, so the referrer is just the page that triggered the ajax request, but EE doesn’t trigger ajax requests on the registration page which is why I suspect the Heartbeat requests)

October 30, 2023 at 6:04 am

Is there a current list of known plugins that conflict with Event Espresso?

Yes, but I’m not aware of the the issue you’ve posted.

Known conflicts here:
https://eventespresso.com/wiki/known-third-party-plugin-theme-conflicts/

Is there a way exclude the Heartbeat requests for Event Espresso?

That’s not the solution to this it just masks the problem.

Do you have a staging/dev copy of the site?

I can tell you what I would do to debug this and see what is calling the above function, you’ll need to add some code within /wp-admin/includes/plugin.php (temporarily), wp-config.php (to enable WP_DEBUG_LOG) and add a custom function to create debug logs easier (not strictly needed, but helps!).

Are you comfortable with FTP/File Manager and PHP?

October 30, 2023 at 7:40 am

Ok, so within wp-config.php I use this:

https://eventespresso.com/wiki/troubleshooting-checklist/#wpdebug

To set the log to use /wp-content/debug.log

Then I use this little function:

if ( ! function_exists('ee_write_log')) {
   function ee_write_log ( $log )  {
      if ( is_array( $log ) || is_object( $log ) ) {
         error_log( print_r( $log, true ) );
      } else {
         error_log( $log );
      }
   }
}

You can add that anywhere that always loads, I use a custom functions plugin:

https://eventespresso.com/wiki/create-site-specific-plugin-wordpress-site/

—

Now, you’ll need to temporarily hack up WordPress core (remember to remove this code when finished).

/wp-admin/includes/plugin.php

Lines 1781 – 1792:

function remove_menu_page( $menu_slug ) {
	global $menu;

	foreach ( $menu as $i => $item ) {
		if ( $menu_slug === $item[2] ) {
			unset( $menu[ $i ] );
			return $item;
		}
	}

	return false;
}

The warning is from $menu being null and being used in the foreach loop, so, check for that and then do something to track down from there, you have a couple of options and personally I use an exception and grab the stack trace from that… like this:

if( is_null($menu)) {
	$e = new \Exception;
	ee_write_log(
		[
			'menu_slug' 	=> $menu_slug,
			'menu' 		=> $menu,
			'stacktrace' 	=> $e->getTraceAsString(),
		]
	);
}

Add that just below global $menu;

Now do whatever you do to trigger the above again and see if anything juicy is saved within /wp-content/debug.log

Post it up here if needed and help troubleshoot if I can.

October 31, 2023 at 8:02 am

When is remove_menu_pages_for_all_except_admin() called? On a hook, if so which one?

Why does that function declare the global $user_ID but then not use it?

current_user_can(‘administrator’) using the role slug itself within that check is considered doing_it_wrong(), see HERE. A role is a collection of capabilities so you check the capability.

current_user_can('manage_options') is generally the better choice there.

As it’s only happening on the Ajax requests, and you don’t need to remove those menus on ajax requests, at the top of that function you could just use something like:

if( wp_doing_ajax() ) {
    return;
}