Support » Fixing WordPress » New Install, 1 theme, 0 plugins – Site health Issues

  • vinnbrock

    (@vinnbrock)


    I have an Ubuntu 18.04.3 VM on my desktop where I’ve done a fresh install of WordPress 5.2.4. This is my first time ever using WordPress, so I know I have a lot to learn. This is my stack. Ubuntu, Nginx 1.17.5, MySQL, PHP 7.3. I’m not sure what else you would need but I’m happy to provide anything else which may be of use.

    I can’t get the Site Health rating past 72%. One of the issues will just have to stand as it’s a local VM on a test domain. So yeah, no SSL there. But the others I can’t figure out. As my Topic title says… I have one (1) theme, and ZERO (0) plugins. I have deleted all of everything else.

    Lastly, I think, I can’t edit the theme files in the theme-editor (http: / / mysite . com/theme-editor.php). I don’t know if it’s related, but I have to imagine it’s indicative of a problem. When I make a change I get the following error:

    
    Unable to communicate back with site to check for fatal errors, so the PHP change was reverted. You will need to upload your PHP file change by some other means, such as by using SFTP.
    

    Site Health Issues:

    1 Critical Issue

      • Background updates are not working as expected
        Background updates ensure that WordPress can auto-update if a security update is released for the version you are currently using.

      • Error A plugin has prevented updates by disabling wp_version_check().
      • Passed No version control systems were detected.
      • Passed Your installation of WordPress doesn’t require FTP credentials to perform updates.
      • Passed All of your WordPress files are writable.

    3 Recommended Improvements

    • Your site does not use HTTPS – Yeah… and for now I’m not addressing this unless this is somehow causing all the other issues…
      • A scheduled event has failed

      • The scheduled event, recovery_mode_clean_expired_keys, failed to run. Your site still works, but this may indicate that scheduling posts or automated updates may not work as intended.
      • The REST API did not behave correctly

      • The REST API is one way WordPress, and other applications, communicate with the server. One example is the block editor screen, which relies on this to display, and save, your posts and pages.

        The REST API did not process the context query parameter correctly.

    • This topic was modified 1 month ago by vinnbrock.
    • This topic was modified 1 month ago by vinnbrock.
Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    a) Make sure that your VM can make outgoing http requests
    b) Make sure that your VM can properly process DNS lookups
    c) Make sure that your VM can make outgoing http requests back to itself. That is, if you’re on the thing in a shell, and you do a curl or wget to get the URL of the site itself, then it should work. If your network configuration is such that you can’t go to the site from the site, then you will get the problems you describe.

    @otto42 Thank you for your reply. I know for a fact that bullet point “C” is a problem. I have adjusted the host file of my host machine so when I hit my URL from my host machine I can get to my VM. Do you think that, for the sake of testing and T/S, I should adjust the host file of the VM to do the same?

    Again, thank you for your time and assistance.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    I honestly cannot tell you the right way to configure your server, however yes, loopback requests need to work.

    WordPress makes http(s) calls back to its own URL in order to spawn wp-cron processes to perform various tasks. These include background updates and scheduling of posts.

    This loopback type request also occurs when using the code editor. If you put invalid code into the theme, then instead of simply breaking the site, it first save the code, then does a loopback to check and see if it broke the site. If it does break the site, then it reverts the change. If it can’t make that loopback request, then it cannot check that the code change won’t break the site, so for safety, it won’t let you do the change.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.