Maintenance hook

[lukasjuhas]

Hi! Some WordPress starter themes (like sage) uses theme wrappers (more detail). Therefore, for the proper operation of your plugin, I propose to replace this: add_action('get_header', array( $this, 'maintenance' )); with this: add_action('template_redirect', array( $this, 'maintenance' ));

• Possibly replace add_action get_header with template_redirect
• Or find a better, alternative workaround?

[john-lang-86]

Hi Lukas,

The get_header() function confirms that it will fire the 'get_header' actions. However, there is no guarantee that a theme hasn't high-jacked the header actions and removed the fundamental hook that the maintenance mode plug is relying on. I believe this is the fundamental point of the above enhancement request (?).

Reading through this awesome StackExchange answer confirms the vanilla WordPress 5.7.2 order of execution for hooks/actions for one of the older themes 'Twenty Twelve'. We just need to be careful about which hooks are fired as part of core WordPress vs which ones are fired due to their use in the theme. ... [init] => 1 ... [wp_register_sidebar_widget] => 45 ... --->[wp_loaded] => 1 ... [parse_request] => 1 [send_headers] => 1 ... [wp] => 1 [template_redirect] => 1 [get_header] => 1 ...

The WP::main() class confirms that even the WP::wp hook happens after a whole bunch of other hooks/actions have had a chance to do their thing. So, at what point in the hook/action sequence would it be considered too early or too late ... I'm not sure. $this->init(); $this->parse_request( $query_args ); $this->send_headers(); $this->query_posts(); $this->handle_404(); $this->register_globals();

I'm liking the wp_loaded hook/actions, buried in the init hook.

This hook is fired once WP, all plugins, and the theme are fully loaded and instantiated.

Advantage 1: The wp_loaded hook/actions will always be triggered, no matter what theme is active. Advantage 2: The wp_loaded hook/actions is triggered after the wp_register_sidebar_widget hook/actions; which maintenance mode has some registered widgets. Advantage 3: The wp_loaded hook/actions stops send_headers and handle_404 from interfering with the maintenance mode functionality; while not wasting precious CPU processing query_args and query_posts. Advantage 4: The wp_loaded hook/actions happen after plugins & themes are loaded (other custom code) that can cause fatal errors that WordPress Recovery Mode. was built to capture. This implies that recovery mode will function as expected, and not be hidden by the maintenance mode plugin for major fundamental errors. Obviously, any custom code errors that occur in a themes page will not be apparent unless you are logged in and are navigating around the site. I believe this balance (plugin/theme -> maintenance mode -> site content) is ok.

Situation 1: Looks like the wp_loaded hook/actions is quite early in the sequence; now wp-login.php page is permanently locked out. Opps. Solution 1: Added wp-login.php into maintenance mode plugin as 'always available'; which also ensures the default /wp-login.php?action=lostpassword capability is 'always available' for administrators.

Observation 1: Any plugin & theme that leverages other WordPress capabilities (login, password, register, etc) via custom URLs, or needs additional access to other services (cron, mail, xmlrpc) can be handled by the six new maintenance mode settings. Each site can add their specific 'allowed exceptions' to a list to ensure maintenance mode does not trigger under these specific scenarios/conditions.

1. An "Allowed IP List" check that uses $_SERVER[REMOTE_ADDR].
2. An "Allowed URI List (Strict Match)" check that uses $_SERVER[REQUEST_URI].
3. An "Allowed URI List" check that uses $_SERVER[REQUEST_URI].
4. An "Allowed Query String List" check that uses $_SERVER[QUERY_STRING].
5. An "Allowed Referer List" check that uses $_SERVER[HTTP_REFERER].
6. An "Allowed User Agent List" check that uses $_SERVER[HTTP_USER_AGENT].

Working solution available in forked Milestone. All feedback is welcomed.