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?

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?

• plugins
• php
• settings-api
• oop

2 Answers 2

The example in Settings API documentation uses admin_init and admin_menu for registering custom settings and admin pages. https://developer.wordpress/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/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?

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 that is more up to date.