0

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 1

0

WordPress 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...

11
  • well sorry for the title; true that it's not real OOP, so I changed that. Anyway, thanks for your answer but it doesn't really answer my point. I wonder if there's any benefit of privatizing all of the plugins' public callbacks or not.. (while I'll keep in mind that using classes this way to develop plugins may not be the best approach..)
    – DevelJoe
    Commented Dec 30, 2020 at 21:17
  • The benefit of visibility of class methods is that you can have "functions" which are not part of the global scope of your application - that has multiple benefits, but only when working with objects and properties - as private global functions are not possible. WordPress only works directly with public functions - that's not to say you can't use OOP, but you need to find a pattern that works, based on your application requirements.
    – Q Studio
    Commented Dec 30, 2020 at 21:28
  • This is a good topic on function and variable visibility: stackoverflow.com/a/4361582/591486
    – Q Studio
    Commented Dec 30, 2020 at 21:28
  • Also - wordpress.stackexchange.com/a/151830/7968
    – Q Studio
    Commented Dec 30, 2020 at 21:37
  • 1
    Yupyup, alrighty, cheers mate, and a happy 21! :D
    – DevelJoe
    Commented Dec 30, 2020 at 21:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.