8000 Maintenance hook · Issue #43 · lukasjuhas/lj-maintenance-mode · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Maintenance hook #43

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
lukasjuhas opened this issue Nov 21, 2017 · 1 comment · May be fixed by #50
Open

Maintenance hook #43

lukasjuhas opened this issue Nov 21, 2017 · 1 comment · May be fixed by #50
Labels
enhancement help wanted

Comments

@lukasjuhas
Copy link
Owner

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 john-lang-86 linked a pull request Jan 8, 2022 that will close this issue
Open
@john-lang-86
Copy link
john-lang-86 commented Jan 8, 2022 •
edited
Loading

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.

@john-lang-86 john-lang-86 mentioned this issue Jan 9, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement help wanted
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Maintenance Mode 2.5.2 - Enhancements & Fixes 37, 43, 44 and 47 john-lang-86/lj-maintenance-mode
2 participants
@lukasjuhas @john-lang-86
0