Troubleshooting mode in Pantheon hosting do not work

  • Resolved Carl Alberto

    (@carl-alberto)


    5 years, 10 months ago

    This is related to Birgit Pauli-Haack’s report that the troubleshooting mode of this plugin is not working in Pantheon hosting.

    When Enable Troubleshooting Mode is clicked for the first time, nothing happens, it just goes to the default dashboard page. Then when you go back to the click to enable troubleshooting mode, it will say Sorry, you are not allowed to access this page. One thing that I observed is that the default file in the mu-plugins folder has been written without any issues.

    Tried it on a newly installed 5.0.3 site without any plugin and default twentynineteen theme, here are more details about the setup:

    WP version: 5.0.3
Server architecture | Linux 4.14.15-201.fc22.x86_64 x86_64
-- | --
Web Server Software | nginx/1.8.1
PHP Version | 7.2.14 (Supports 64bit values)
PHP SAPI | fpm-fcgi
PHP max input variables | 10000
PHP time limit | 120
PHP memory limit | 256M
Max input time | 900
Upload max filesize | 100M
PHP post max size | 100M
cURL Version | 7.40.0 NSS/3.21 Basic ECC
SUHOSIN installed | No
Is the Imagick library available | Yes

    Console logs shows under the Site Status tab:

    VM148:1 POST https://example.com/wp-admin/admin-ajax.php 400
(anonymous) @ VM148:1
send @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=5.0.3:4
ajax @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=5.0.3:4
n.(anonymous function) @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=5.0.3:4
(anonymous) @ health-check.js?ver=1.2.5:196
each @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=5.0.3:2
each @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=5.0.3:2
(anonymous) @ health-check.js?ver=1.2.5:188
i @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=5.0.3:2
fireWith @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=5.0.3:2
ready @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=5.0.3:2
K @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=5.0.3:2

    php slow log error shows:

    script_filename = /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code//wp-admin/admin-ajax.php
[0x00007f7a5081df90] unlink() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:285
[0x00007f7a5081deb0] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081ddd0] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081dcf0] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081dc10] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081db30] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081da50] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081d970] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081d890] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081d7b0] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081d6d0] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/class-wp-filesystem-direct.php:296
[0x00007f7a5081d5f0] delete() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/plugin.php:859
[0x00007f7a5081d430] delete_plugins() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/includes/ajax-actions.php:3901
[0x00007f7a5081d330] wp_ajax_delete_plugin() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-includes/class-wp-hook.php:286
[0x00007f7a5081d250] apply_filters() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-includes/class-wp-hook.php:310
[0x00007f7a5081d1e0] do_action() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-includes/plugin.php:453
[0x00007f7a5081d0e0] do_action() /srv/bindings/a94484ccf3e64353a32c620ff37ac9d7/code/wp-admin/admin-ajax.php:99

    Things that I have tried to troubleshoot
    – removed all Pantheon mu-plugins
    – added this in the wp-config.php which usually solved file writing issues in the platform

    define('FS_METHOD', 'direct');
define('FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define('FS_CHMOD_FILE', ( 0755 & ~ umask() ) );
define( 'DISALLOW_FILE_MODS', false );

    By the way, awesome plugin you have here and we would love to see it working on more hosting to help out a broader range of WP users out there!

    I can share some more details in wp.org Slack via DM for a site access so we can try to collaborate on what is going on with this plugin in that specific hosting.

    Also submitted an issue here https://github.com/WordPress/health-check/issues/246

    • This topic was modified 5 years, 10 months ago by Carl Alberto.
    • This topic was modified 5 years, 10 months ago by Carl Alberto.
Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author Marius L. J.

    (@clorith)

    Hmm,

    So this is a little bit interesting, it sounds like troubleshooting did in fact start up, as indicated by you getting that message when trying to go back after enabling it (this makes sense, as the page does not exist at that point, and the error is just a bit vague).

    Are there any other indicators that it’s working/not working, for example does visiting the plugins list show options to enable/disable while troubleshooting instead of the normal activate/deactivate/delete options?

    Thanks, Marius.
    Taking it from the beginning: I activated the Health Check plugin.
    Scrolling all the way to the bottom of the Site Status tab, I see the last three items:

    • Communication with www.ads-software.com
    • Background updates
    • Loopback request

    rotating but never finishing.
    The browser console shows the following error:
    Failed to load resource: /wp-admin/admin-ajax.php:1 Failed to the server responded with a status of 400 (Bad Request)

    Going to the Troubleshooting tab, I click on “Enable Troubleshooting Mode” and immediately I get the message “Sorry, you are not allowed to access this page.”

    Looking at the file directories I find the “health-check-troubleshooting-mode.php” in /wp-content/mu-plugins

    Then I delete the file, assuming that’s a left over from earlier attempts.

    Then I click on the Troubleshooting Mode again, and I am redirected to the Dashboard view, but only see the “Welcome to WordPress” prompt, not the usual “Health Check – Troubleshooting Mode” screen, announcing that my site is in Troubleshooting Mode. When I visit the site, it shows me live site, in the activated theme, not a default theme.

    Thread Starter Carl Alberto

    (@carl-alberto)

    For this 2nd test that I made:

    1) I tried turning on 2 plugins Akismet and ACF.
    2) Went to Health Check and enabled troubleshooting mode.
    3) Went back to the plugins list and it seems they are still activated https://screencast.com/t/jJPuPSjf

    Clicking the troubleshooting button from there does nothing, it just goes back to the same page, no error in console log.

    It looks like this plugin is utilizing session_start() or PHP’s $_SESSION superglobal? This might be turning off Pantheon’s required plugin for sessions to work properly in the platform: https://pantheon.io/docs/wordpress-sessions/ when the troubleshooting mode kicks in?

    • This reply was modified 5 years, 10 months ago by Carl Alberto.
    • This reply was modified 5 years, 10 months ago by Carl Alberto.
    Plugin Author Marius L. J.

    (@clorith)

    We don’t use sessions, no, it’s just a cookie. Do you filter out cookies by any chance? It sounds unlikely for that to happen on the backend, but you never know, it would be named health-check-disable-plugins.

    Thread Starter Carl Alberto

    (@carl-alberto)

    It seems the cookie is being stripped by the Pantheon’s Varnish cache layer not letting it pass as per naming specifications defined in the platform’s Varnish configuration: https://pantheon.io/docs/cookies/#cache-busting-cookies, any cookie that do not have a wp- prefix is being stripped. I tried it in my test environment and I was able to make the plugin work by searching all strings that matches 'health-check-disable-plugins' to 'wp-health-check-disable-plugins'.

    Is it possible that I can open a feature request or PR where we can put in a filter in place where we can manually override the cookie name from health-check-disable-plugins to something like wp-health-check-disable-plugins or STYXKEY_health-check-disable-plugins or would simply renaming a cookie won’t affect the plugins overall functionality on existing installs or if it is included in an update?

    • This reply was modified 5 years, 9 months ago by Carl Alberto.
    Plugin Author Marius L. J.

    (@clorith)

    I’m very open to PRs, and renaming the cookie won’t have any adverse effect on anything, so it is a perfectly valid approach. I’d go so far as to say ti’s the ideal solution here, as it’s a scenario that may be happening elsewhere as well that we’ve just not heard of.

    Thread Starter Carl Alberto

    (@carl-alberto)

    Thanks @clorith and for reporting this @bph. PR is on its way – https://github.com/WordPress/health-check/pull/253

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Troubleshooting mode in Pantheon hosting do not work’ is closed to new replies.