1

I've built a class which creates admin pages with the Settings API. I'm trying to optimize it to run only where I need it.

Most of the examples and tutorials I've seen say to instantiate it from the main plugin file. E.g., new MyPluginNameClass(); from my-plugin-name.php. That's how OptionTree and WPPB do it.

But doing it this way creates the class on every page load. The plugin I'm working on is strictly backend.

Now, I can wrap my new MyPluginNameClass() call in an is_admin() conditional to keep it from running on the frontend. But my conditional would still run on every page view, it just exits very quickly on frontend pages.

It just feels wrong to run code on every page when I don't need to. Is there an admin-only hook that I should tie my class instantiation to? Or am I just overthinking this by trying to optimize to save nanoseconds?

0

The example in Settings API documentation uses admin_init and admin_menu for registering custom settings and admin pages. https://developer.wordpress.org/plugins/settings/custom-settings-page/

There's also an old Codex entry on actions typically run on front and back end requests, which can help pick a suitable action hook. https://codex.wordpress.org/Plugin_API/Action_Reference

I also highly recommend the excellent old Q&A about instantiating classes in WP. Best way to initiate a class in a WP plugin?

  • Well now I feel silly. I'm modifying a plugin I had written functionally to be OOP instead. My functional version used admin_init and admin_menu, but it just didn't occur to me to tie my class instantiation to those hooks as well. That third link you provided has a lot of information in it that answers some other questions I had, so thanks for that as well! – Robert Gillmer Jan 19 at 14:49
0

It really depends on what you're doing, but I agree in most cases using the settings API and running the code/instantiate the classes only when needed inside the callback is usually the best route to take opposed to instantiate everything upfront.

Aside from the suggestions above - One approach I've taken a few times is hooking into some of the dynamic hooks offered in WP such as load-{$page_hook} to run code for dynamically created pages and triggering any necessary css/js respectively with admin_print_scripts-{$hook_suffix}/admin_print_styles-{$hook_suffix}(footer actions available as well if needed). admin_head-{$hook_suffix} is also useful when using this approach.

Where $hook_suffix is, is the hook suffix of the current page, so if you created a settings page named 'my-plugin-page' you could run your instantiation stuff in load-settings_page_my-plugin-page hook, which would only run on the settings page "my-plugin-page". The same can be done for other page types like load-toplevel_page_my-plugin-page if they aren't settings pages/using settings api.

The codex under 'Page Hook Suffix' has an example of this approach, but I didn't see anything on developer.wordpress.org that is more up to date.

  • 1
    The load-{$page_hook} is a great suggestion. I had considered something like that, but I had figured it was like trying to open a box using the crowbar inside the box. Your comment made me realize I can call a method that runs add_subpage from the main part of the class, then write a separate method that handles the other parts and hook that method onto load-{$page_hook}. Thanks! – Robert Gillmer Jan 19 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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