Alright, so I'm developing a plugin where my plugin file is a class which holds all the functions related to the initiation of the plugin, such that I can simply provide all of the plugins functionalities by initiating the class. According to a variety of docs, I developed stuff in a way where I hook all of the plugin's functionalities as callbacks onto the according hooks. Callbacks are defined as public functions in the class, and the callbacks are hooked via the class constructor; like so:
if ( ! class_exists( 'MyPluginClass' ) ) {
class MyPluginClass {
public function __construct() {
add_action( 'admin_menu', array( $this, 'my_admin_menus' );
}
public function my_admin_menus() {
add_menu_page( ... );
}
}
}
okay, all of that worked. Now, when going over the plugin again; I felt weird looking at the final plugin and seeing about 50 public callbacks. That's why I attempted to privatize all of the plugin's main file callbacks, by changing for example the code above to:
if ( ! class_exists( 'MyPluginClass' ) ) {
class MyPluginClass {
public function __construct() {
add_action( 'admin_menu', function() { $this->my_admin_menus(); };
}
private function my_admin_menus() {
add_menu_page( ... );
}
}
}
Okay, now don't get me wrong, my question's not about this transition, as there are many posts replying to this question; but rather how far this transition actually makes sense. I moreover faced several challenges, where one remained unexplained to me: when I change the callback which creates a custom post type with register_post_typefrom being public to being private (exactly as described above, so I won't paste the entire huge code here); the support columns disappear from the custom post type admin page (i.e. no more author, title, etc. columns, just a table having a row per created post, without column descriptions). Problems like these, and the several conundrums and workarounds I needed to code to make most of the callbacks private gave me the strong feeling that wordpress plugin development is not designed to use private callbacks. Am I wrong, or am I doing something wrong and it's indeed better (in terms of security) to privatize the main plugin callbacks?
Alright, so I'm developing a plugin where my plugin file is a class which holds all the functions related to the initiation of the plugin, such that I can simply provide all of the plugins functionalities by initiating the class. According to a variety of docs, I developed stuff in a way where I hook all of the plugin's functionalities as callbacks onto the according hooks. Callbacks are defined as public functions in the class, and the callbacks are hooked via the class constructor; like so:
if ( ! class_exists( 'MyPluginClass' ) ) {
class MyPluginClass {
public function __construct() {
add_action( 'admin_menu', array( $this, 'my_admin_menus' );
}
public function my_admin_menus() {
add_menu_page( ... );
}
}
}
okay, all of that worked. Now, when going over the plugin again; I felt weird looking at the final plugin and seeing about 50 public callbacks. That's why I attempted to privatize all of the plugin's main file callbacks, by changing for example the code above to:
if ( ! class_exists( 'MyPluginClass' ) ) {
class MyPluginClass {
public function __construct() {
add_action( 'admin_menu', function() { $this->my_admin_menus(); };
}
private function my_admin_menus() {
add_menu_page( ... );
}
}
}
Okay, now don't get me wrong, my question's not about this transition, as there are many posts replying to this question; but rather how far this transition actually makes sense. I moreover faced several challenges, where one remained unexplained to me: when I change the callback which creates a custom post type with register_post_typefrom being public to being private (exactly as described above, so I won't paste the entire huge code here); the support columns disappear from the custom post type admin page (i.e. no more author, title, etc. columns, just a table having a row per created post, without column descriptions). Problems like these, and the several conundrums and workarounds I needed to code to make most of the callbacks private gave me the strong feeling that wordpress plugin development is not designed to use private callbacks. Am I wrong, or am I doing something wrong and it's indeed better (in terms of security) to privatize the main plugin callbacks?
1 Answer
Reset to default 0WordPress hooks only work with global functions ( or public function inside a class ) - private or protected methods are not available due to their visibility level, so not available to the way WP calls actions or filters.
What you are trying to do is tidy up your code using a class to contain all the functions ( called methods inside a class ), this seems like a good idea, until you review it - and then you notice the bad code smell - you're writing proxy OOP - not real OOP - and this offers little justifiable benefit.
WordPress is partly responsible, but your plugin design is also responsible - you need to understand the patterns and refactor your plan - OR NOT.. because maybe it works better as procedural code than OOP...