Firing WP action hook function from a different class - php

Question

In a custom plugin, I am creating a custom menu page in WP with an admin_menu hook in the main Asset loader class. In a separate file, I have another class called Leads_UI that houses the public static function leads_html() to output the markup to show on this custom admin page.
If you see in the code below, in the register_leads_dashboard function, if I am calling the
leads_html function via the same class rather than the Leads_UI class, it works as intended and outputs the html only when you are on that Leads page.
But if I try to use the public static function leads_html() from the separate Leads_UI class, Leads_UI::leads_html(), it is causing 2 errors:
The html is outputted on every page in the dashboard and shows at the top left corner behind the main content,
When I click on the 'Leads' page in dashboard, it throws the 404 page not found error.
What might be the issue? I am new to OOP.
namespace MWS_PLUGIN\Inc;
use MWS_PLUGIN\Inc\Traits\Singleton;
class Assets {
use Singleton;
protected function __construct() {
// Load all critical functions
$this->setup_hooks();
}
protected function setup_hooks() {
//Add a new screen for 'Leads' CPT
add_action( 'admin_menu', [$this, 'register_leads_dashboard'] );
}
public function register_leads_dashboard() {
// This causes unexpected behaviour
add_menu_page( __( 'Leads', 'my-plugin' ), __( 'Leads', 'my-plugin' ), 'manage_options', 'leads-list', Leads_UI::leads_html(), 'dashicons-admin-users', 50 );
// This works perfectly!
//add_menu_page( __( 'Leads', 'my-plugin' ), __( 'Leads', 'my-plugin' ), 'manage_options', 'leads-list', [ $this, 'leads_html' ], 'dashicons-admin-users', 50 );
}
public function leads_html() {
esc_html_e( 'Leads page test', 'my-plugin' );
}
}
Lead_UI class that's in a separate file:
namespace MWS_PLUGIN\Inc;
class Leads_UI {
private function __construct(){
}
public static function leads_html() {
esc_html_e( 'Leads page test', 'my-plugin' );
}
}

Answer 1

The add_menu_page() function's fifth parameter has the callable type.
But, your code doesn't pass the callable. Rather, it calls your void Leads_UI::leads_html() function, then passes the missing return value of that function to add_menu_page(). So the function is getting invoked at the time you call add_menu_page() which is not what you want.
add_menu_page( __( 'Leads', 'my-plugin' ), __( 'Leads', 'my-plugin' ),
'manage_options', 'leads-list',
Leads_UI::leads_html(), /* NOT a callable! */
'dashicons-admin-users', 50 );
You want to specify that static function as a callable like this:
[ Leads_UI::class, 'leads_html' ]
giving code like this.
add_menu_page( __( 'Leads', 'my-plugin' ), __( 'Leads', 'my-plugin' ),
'manage_options', 'leads-list',
[ Leads_UI::class, 'leads_html' ], /* Callable! */
'dashicons-admin-users', 50 );
Edit: More explanation:
Here's the sequence of operations.
Somewhere in your code you say something like new Assets().
That calls the __construct member function you showed us.
In turn that calls your setup_hooks() member function.
That registers an admin_menu action that will call your register_leads_dashboard() member function later on.
When you return from __construct(), WordPress does a whole lot of other stuff. If it's rendering any dashboard page, eventually it invokes your admin_menu action. If it's rendering a front-end page it never invokes it.
Everything that appears in the big dashboard menu on the left side of the dashboard, everything, is the result of some admin_menu action handler. There are many admin_menu handlers in WordPress. Yours is one of them.
WordPress calls your admin_menu handler which invokes your register_leads_dashboard() method.
You call add_menu_page() to put your Leads page on the menu.
That in turn registers another callback (the callable we've been talking about here) to be called when your user clicks on your menu item. In your case you want it to call that static member function Leads_UI::leads_html().
When the user clicks on your menu item, WordPress calls that static member function.
WordPress lives, and sometimes dies (:-) by all these callbacks. And it happens that php has peculiar ways of declaring callables, the functions to be called when invoking callbacks.
For a global function, a callable is simply a text string containing its name.
For a non-static member function, the callable is
array( $instance, 'function_name' )
For a static member function like yours, the callable is
array( ClassName::class, 'function_name' )
Why not forget about all those class definitions and just make all callback functions global? Doing that would make it easier to add WordPress action and filter handlers. These reasons.
Global name space pollution. If you and I both define the same global function namespace\name combination, the php program (WordPress) will crash. Using a static member function (what you did) is a way to take those functions out of the global namespace.
Context. While an ordinary member function is running, it has access via $this to all the class instance's properties and functions. So one callback can save information in properties, and another callback can use that information.
Don't overthink this OOP stuff.