Using WordPress CMS on AWS Elastic Beanstalk – Trouble deploying (page doesn’t load)

I’m trying to get WordPress running on AWS Elastic Beanstalk. I’m starting with:

  • Set of WordPress 4.1 files (with some additional plugins, etc.)
  • An environment on AWS Elastic Beanstalk (let’s call it app-dev)
  • A MySQL database running on AWS RDS
  • Local server running using MAMP

I can successfully get the app going locally. I start the server, point it to the WP directory, and can then access it. I go through the WP setup screens, plug in my database info, install WP, and everything works fine in conjunction with the database. This also generates my wp-config.php file.

Read More

Now, when I use the Elastic Beanstalk command line tools to attempt to deploy the app to the app-dev environment (by way of making a git repo, using eb init, and eb deploy), the result I get on app-dev.elasticbeanstalk.com is just a “This webpage is unavailable” problem. Interestingly, if I go to app-dev.elasticbeanstalk.com/wp-admin, it automatically redirects me to the localhost:8888/wp-admin page. This makes me think I’m doing something wrong when I set the wp-config – it’s doing something to link it back to the localhost:8888 links.

I’ve tried to not go through WP setup locally, and just deployed to the server and set up there, but after I click through the setup, it oddly re-routes me to try setup again on localhost:8888. So I get the sense that’s the wrong approach.

I’ve tried getting insights from the following tutorials, especially in regards to their local versus production setup (i.e. everything having to do with the local-config.php file), but every variation of things I’ve tried hasn’t had better results.

I’m inclined to think I’m misunderstanding some basic concept about how WP setup works and what it does during setup. Could anyone point me in the right direction, or try to describe that for me?

Thanks!

Related posts

Leave a Reply

1 comment

  1. Figured it out. Turns out I just wasn’t accounting for a few variables that WP sets as you install WP – the URL’s associated with the installation. So in this case, WP was pointing to my localhost links, even when I deployed to the server.

    The straightforward fix is to go to WordPress, Settings > General, and change both the WordPress Address and Site Address URLs to reflect the server URL rather than your local URL. You should do this right before you deploy, because after you change it you’ll no longer be able to access it via localhost.

    The more complete fix is to set up your wp-config.php file to account for this. Those two fields correspond to WP_HOME and WP_SITEURL variables. For my setup (in which I used git branching to differentiate between development and production code), I used this:

    // Check for a local config file
    if ( file_exists( dirname( __FILE__ ) . '/local-config.php' ) ) {
       define( 'WP_LOCAL_DEV', true );
       include( dirname( __FILE__ ) . '/local-config.php' );
    } else {
      define( 'WP_LOCAL_DEV', false );
      define('WP_HOME','http://myserverurl.com');
      define('WP_SITEURL','http://myserverurl.com');
    }
    

    In local-config.php, I just had:

    <?php define('WP_HOME','http://localhost:8888'); 
    define('WP_SITEURL','http://localhost:8888'); ?>
    

    I listed local-config.php in .gitignore, which meant whenever I deployed, local-config.php was not included, and the right variables were used when trying to run on the server.