I had my plugin working (it generates some files based on post types, only in admin) and threw in an if statement to generate if the folder didn’t exist.
Even though it’s on the init hook, it says that add_settings_error is not defined. I put it on the wp_loaded hook instead, but get the same result.
I thought perhaps it was due to a different loading sequence for ajax or cron so I checked for 4 conditions before loading my plugin file. Same result of undefined function.
If I use
require_once ABSPATH . '/wp-admin/includes/template.php'
it works fine.
How can I be hitting a state in admin that doesn’t load the admin files?
Should you, perhaps, be using the admin_init hook?
No, admin_init is after admin_menu and wp_loaded and I need it sooner than that. I had tried wp which is after both of those, and it still didn’t have it loaded.
So let’s see what else is there which one could in theory use as a workaround action hook:
According to the admin core initialization process seen in wp-admin/admin.php, the following other functions are being called before do_action( 'admin_init'), but AFTER all the admin functions and classes have been loaded (using includes/admin.php):
- auth_redirect - auth_redirect() | Function | WordPress Developer Resources
- set_screen_options - set_screen_options() | Function | WordPress Developer Resources
auth_redirect contains one action hook, that only applies if the user is logged in (else there is a redirect to the login page): do_action( 'auth_redirect', $user_id );
While set_screen_options doesnt yield anything helpful.
Next, there are the admin menu include calls, so I dug into those as well - et voila: there might still be (a) more promising action hook(s): Right at the start of wp-admin/includes/menu.php, there are three potential hooks that fire BEFORE the admin_menu hooks do, ie.:
-
_admin_menu- if its a WP / CP single site install -
_user_admin_menu- if its a WP / CP multisite install and the user admin (= the admin interface for the current site) is active -
_network_admin_menu- if its a WP / CP multisite install and the global admin interface is active
So that gives you two more action hooks to try. To me, the _admin_menu hook looks the most promising.
cu, w0lf.
Thanks for the research, but it’s not that I need a different hook. It’s that even when using the wp hook, the file still isn’t loaded. Since the function is for settings errors, this seems really odd to me.
Apparently there are code paths in the admin that don’t include all the functions for settings.
If you’re using the ‘wp’ hook, then that doesnt mean its necessarly gonna load the rest, ie. that could fire in the frontend, too.
The only other thing I can think of is, that there is an early abort happening, or that some files are corrupted / modified. Or: It’s not running in admin at all, but the hooks get called within the admin-ajax.php.
Question: Which WP or CP version are you testing this with? I didnt look in 6.0 yet, but both admin init processes, ie, of CP 1.4.x and WP 5.9.x, look identical.
Also: Are you running any other scripts / plugins? Maybe some of those interfere in unknown ways? (eg. throw an error during an action hook when the Settings API gets loaded or other weird stuff …)
cu, w0lf.
Yes, a bunch of the hooks fire in both, but I didn’t have the front end open.
As I said, I put a guard if statement around it:
if ( ! defined('REST_REQUEST') && ! wp_doing_cron() && ! wp_doing_ajax() && ! defined('XMLRPC_REQUEST') ) {
if ( is_admin() ) {
require_once plugin_dir_path( __FILE__ ) . 'class-static-search-admin.php';
Static_Search_Admin::get_instance();
}
else {
require_once plugin_dir_path( __FILE__ ) . 'search-form.php';
}
The admin class is the only place where I had the hook that got the error.
It runs the same under CP 1.4.2 and WP 5.2.15.
Only a couple. When I searched for the file that should be loaded, I found that other plugins load it themselves. That’s how I fixed my problem. I think this is a bug in core, though.
No other errors are logged.
On what page does this happen? The “Actions Run During an Admin Page Request” overview in the Codex mentions that
Each admin page has a different list of actions depending upon the purpose of the page and the plugins installed.
Although while doing a quick scan through the regular files, I couldnt find any of them NOT including the base core admin.php (except for the very base files like setup-config or the ones being included by the admin core setup process itself). But what COULD happen is: If its not included by a regular file / part of the admin directory, as the comments actually mention, then several constants are not set.
TL;DR: On what screen of the admin area does this happen?
Or does it happen with all of them?
Which would be weird, because all the includes happen with a require_once, so it should throw a fatal error / compile error and instantly abort program execution, if it wasnt able to.
So maybe there is one or two regular screens that may not include wp-admin/includes/admin.php aka “Core Administration API”, neither directly nor indirectly via including ( wp-admin/admin.php).
And the other option might be suppressing all errors altogether, including disabling logging them; albeit, at least in theory, a Fatal Error or Compile Error should still lead to program execution abortion, so it might fail silently.
cu, w0lf.
I didn’t try them all, but the first three that I went to had the error. (dashboard, plugins, themes) None of those have actual settings, so I assume it is not loaded.
No, it’s not an option to suppress the errors when writing a plugin. I load the file in the plugin and the error is solved.
Either the settings errors functions should be loaded every time, or there should be some documentation about needing to load it.
I didn’t try them all, but the first three that I went to had the error. (dashboard, plugins, themes)
Which is indeed strange, because the dashboard gets loaded in the index.php, and that one clearly includes the admin.php and thus also the settings API.
No, it’s not an option to suppress the errors when writing a plugin. I load the file in the plugin and the error is solved.
Either the settings errors functions should be loaded every time, or there should be some documentation about needing to load it.
you’re either intentionally misinterpreting what I wrote, or misunderstood it (might be, because I’m not a native English speaker).
To clarify: I mentioned the error suppression, as being another potential CAUSE of the issue.
Eg. maybe another plugin does that, there is a server setting or something in the wp-config.
Other potential causes I can think of: A caching tool or server-side cache running amok / is misconfigured, or other server side-related issues, including the classic “disk is full” issue.
I might be testing this myself if I find some time to spare in the next few days, maybe on Su / Mo, so I can further investigate and come up with some insights.