Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
Wordpress Mysql Connection to new Droplet with Ubuntu 16 Question Question
Unable to create user in SQL Question Question

Question

Transferring a wordpress installation, "Can't reach this page" on all pages possibly mysql related?

Posted May 25, 2017 7.5k views
MySQLWordPressUbuntu 16.04

Hello, I am in the process of transferring a wordpress that was previously hosted on wamp on my home server, on to digital ocean. I am reciving an error on every page that simply says “can’t reach this page” on microsoft edge and chrome says ERRCONNECTIONTIMEOUT

I followed the procedure here https://codex.wordpress.org/Moving_WordPress
I imported the old database, and I have made sure that the username and password match in the wp config file. I am stumped as to what else might be causing the problem, any suggestions would be appreciated and I can certainly provide a lot more information, I just don’t really know what is needed.

Add a comment
tommyconner96
By:
tommyconner96

Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
Wordpress Mysql Connection to new Droplet with Ubuntu 16 Question Question
Unable to create user in SQL Question Question

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
3 answers
jtittle1 May 25, 2017

@tommyconner96

The error itself doesn’t say much about what’s going on, so we’d need to check the error logs to see if there anything showing up there first and foremost.

If you’re using Apache, we can get the last 20 lines using:

tail -20 /var/log/apache2/error.log

If you’re using NGINX, we can get the last 20 lines using:

tail -20 /var/log/nginx/error.log

If you can paste the output of either command (whichever server you’re running), we can see if the logs are able to tell us anything.

Reply Report
  • tommyconner96 May 26, 2017

    I am running apache. I ran the command and got this:

    [Thu May 25 18:27:33.227834 2017] [mpm_event:notice] [pid 3417:tid 140423092254592] AH00489: Apache/2.4.18 (Ubuntu) configured -- resuming normal operations
[Thu May 25 18:27:33.227947 2017] [core:notice] [pid 3417:tid 140423092254592] AH00094: Command line: '/usr/sbin/apache2'
[Thu May 25 18:27:40.538485 2017] [mpm_event:notice] [pid 3417:tid 140423092254592] AH00491: caught SIGTERM, shutting down
[Thu May 25 18:27:41.622154 2017] [mpm_event:notice] [pid 3587:tid 140005385033600] AH00489: Apache/2.4.18 (Ubuntu) configured -- resuming normal operations
[Thu May 25 18:27:41.622262 2017] [core:notice] [pid 3587:tid 140005385033600] AH00094: Command line: '/usr/sbin/apache2'
[Thu May 25 18:28:57.470827 2017] [mpm_event:notice] [pid 3587:tid 140005385033600] AH00491: caught SIGTERM, shutting down
[Thu May 25 18:28:58.555143 2017] [mpm_event:notice] [pid 3717:tid 140086702786432] AH00489: Apache/2.4.18 (Ubuntu) configured -- resuming normal operations
[Thu May 25 18:28:58.555262 2017] [core:notice] [pid 3717:tid 140086702786432] AH00094: Command line: '/usr/sbin/apache2'
[Thu May 25 18:29:51.752401 2017] [mpm_event:notice] [pid 3717:tid 140086702786432] AH00491: caught SIGTERM, shutting down
[Thu May 25 18:29:52.841673 2017] [mpm_event:notice] [pid 3826:tid 140572765853568] AH00489: Apache/2.4.18 (Ubuntu) configured -- resuming normal operations
[Thu May 25 18:29:52.841786 2017] [core:notice] [pid 3826:tid 140572765853568] AH00094: Command line: '/usr/sbin/apache2'
[Fri May 26 04:54:22.018964 2017] [mpm_event:notice] [pid 3826:tid 140572765853568] AH00491: caught SIGTERM, shutting down
[Fri May 26 04:54:23.103990 2017] [mpm_event:notice] [pid 7815:tid 140084567263104] AH00489: Apache/2.4.18 (Ubuntu) configured -- resuming normal operations
[Fri May 26 04:54:23.104125 2017] [core:notice] [pid 7815:tid 140084567263104] AH00094: Command line: '/usr/sbin/apache2'

    I can definitely provide any more details, I just wasn ’t sure where to begin. Thank you. And sorry for the delay, I have been at work all day.

    Reply Report
jtittle1 May 26, 2017

@tommyconner96

The error log definitely doesn’t help in this case as all that’s showing is that Apache was restarted.

Is this the only site on the Droplet? If so, and there’s only one Apache VirtualHost setup, can you try to change the URL on the WordPress site to the IP of your Droplet and see if you’re able to access it?

Inside of wp-config.php, add the following:

define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');

Replace http://example.com with your Droplet IP. For example, if you’re Droplet IP is:

111.22.33.44

You’d use:

define('WP_HOME','111.22.33.44');
define('WP_SITEURL','111.22.33.44');

That’ll make it so that WordPress responds by IP instead of by domain. If that works, then the issue is either related to your VirtualHost configuration or it’s a DNS issue.

We’d then need to take a look at your VirtualHost file, your DNS, or both. You’d generally get an error relating to DNS in Chrome when DNS is not correctly setup, so the issue may very well be with the VirtualHost.

If you can paste that in to a response using a code block (to ensure proper formatting), I’ll be more than happy to take a look at it for you.

Reply Report
  • tommyconner96 May 26, 2017

    This is the only site on the droplet. Something I forgot to mention at the beginning, is that I have not touched the domain name, I wanted to get the site online using just the IP address, as this website will be replacing another site that needs to be online for the time being.
    I added those two lines to my wp config.
    virtualhost file:

    <VirtualHost *:80>
     ServerAdmin tommyconner96@gmail.com
     ServerName 174.138.58.51
     DocumentRoot /var/www/html
     ErrorLog ${APACHE_LOG_DIR}/error.log
     CustomLog ${APACHE_LOG_DIR}/access.log combined
     Redirect permanent / http://174.138.58.51
</VirtualHost>

    Is this missing anything?
    I also read this somewhere else on the forums, and tried curl localhost
    and got this

    
tommy@renew1:/etc/apache2/sites-enabled$ curl localhost
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://174.138.58.51">here</a>.</p>
<hr>
<address>Apache/2.4.18 (Ubuntu) Server at localhost Port 80</address>
</body></html>
    Reply Report
    • jtittle1 May 26, 2017

      @tommyconner96

      Seeing the too many redirects error is a set in the right direction, so we’re getting there!

      To start, remove this line:

      Redirect permanent / http://174.138.58.51

      Unless you’re using your domain, you don’t need this line. It’s essentially telling Apache to accept a request and redirect it back to the IP, which ends up in a loop. This would work as expected if you were using a domain and trying to redirect from www to your domain w/o the www, but for IP based access, it’s going to be problematic.

      Once that line is removed, backup and delete your .htaccess file in the web root (where index.php is). We can regenerate a new one once we get WordPress working by going to:

      ./wp-admin => Settings => Permalinks => Click Save

      Once you’ve done both, refresh the page and see if everything is working as it should be.

      Reply Report
      • tommyconner96 May 26, 2017

        Alright, I did both of those things. The page still doesn’t load in Chrome or Edge, but when I run curl localhostI get something that looks more promising

        <?php
/**
 * Front to the WordPress application. This file doesn't do anything, but loads
 * wp-blog-header.php which does and tells WordPress to load the theme.
 *
 * @package WordPress
 */

/**
 * Tells WordPress to load the WordPress theme and output it.
 *
 * @var bool
 */
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/wp-blog-header.php' );
        Reply Report
        • jtittle1 May 26, 2017

          @tommyconner96

          You’re seeing that because the correct module for PHP isn’t installed. When you go to install PHP, you’ll normally see packages such as:

          php7.0-cli
php7.0-fpm
php7.0-gd
etc

          Those packages are just the core PHP packages and while they do work, they do not setup mod_php for use with Apache.

          So what you’d need to do is install:

          libapache2-mod-php7.0

          …using:

          apt-get -y install libapache2-mod-php7.0

          You may need to install other packages as well depending on what you’ve already installed. To get a list of the packages you can install, you can run:

          apt-cache search php7.0 --names-only

          You’ll definitely need to make sure that php7.0-mysql is installed if it’s not already.

          Reply Report
davidfavor May 29, 2017

In general, it’s a very bad idea to hack up your wp-config.php + way better to fix your runtime environment so your install simply works.

First get everything working with pure Apache (remove NGINX).

Steps…

1) Use netstat -pluten to ensure apache is really listening on port 80 + 443.

2) If Apache is truly listening + setup correctly, you should see the Apache default page for non-SSL (port 80) access. Fix this before proceeding.

3) Setup your Apache config + run apachectl -t + ensure you get an OK before proceeding.

4) At this point you should have your WordPress root directory serving.

5) Deploy your WordPress installation via backup restore or wp-cli or however you do it.

All should be well.

6) The muck about with NGINX (shudder), which will only slow down well tuned LAMP Stacks, so if your site will be receiving significant traffic, better to tune your LAMP Stack, rather than attempt fixing poor LAMP Stack tuning via NGINX or Varnish or CDN or any other cruft between Apache + your money (visitors).

Reply Report

Related

Looking for something else?

Ask a new question Search for more help