Going Live With Your Site in Managed WordPress Portal

Note: The instructions in this tutorial are for the Managed WordPress portal client, these instructions do not apply if you have a Liquid Web WordPress Server Optimized Template account.

Going live with your site is the last step in the process of migrating your WordPress sites into Liquid Web’s Managed WordPress portal. These instructions are for domains registered at Liquid Web, if your domain is registered with someone other than Liquid Web, see our DNS Tutorials for instructions to update the DNS for other domain registrars.

Step #1: Create DNS Record

  1. Log into your Liquid Web account.
  2. Click on Domains to open the domain page. 
  3. Select the DNS tab to open your DNS management screen. 
  4. Click on the [+] to expand the DNS records for that domain. 
  5. Once the DNS records are open, you will need to add an A Record to point your WordPress site to the correct domain.
  6. Click Add New Record to create a new A Record for your site. 
  7. Enter the domain name, TTL of 3600, select A for the record Type from the drop down menu. 
    Note:
    For this tutorial, I am leaving the domain name empty, as I want the A record to apply to the entire lwtrainingmwp.com domain name. For more information on what information goes into your A Record, see our article DNS Record Types.

     

  8. The IP address to add to the A Record can be found in your Managed WordPress portal on the home page. Click Copy to copy the IP address from your dashboard. 
  9. Paste the IP address into the A Record for your domain. 
  10. Click the green check mark to create the A Record.
  11. The A Record will appear in your DNS zone list. 

Step #2: Change Your Domain

  1. Once the A Record is created, go back to your Managed WordPress Dashboard site home page. 
  2. Change the Primary Domain to the domain you want to use for the site and click Update
  3. When you click on the site link under Domain at the top of the page, your site will open and is now live. 

Git & Continuous Deployment on Cloud Sites

If you’re used to using services such as GitHub or Bitbucket for continuous integration, chances are you’re wondering how you can setup continuous deployment for your website on Cloud Sites. Since Cloud Sites doesn’t have git or SSH access, you might think it’s impossible. Luckily, with a service like DeployBot and their SFTP deployment tools, it is actually very simple to deploy your code from your repository to Cloud Sites with a simple click. Here’s a quick tour on how to get up and running with DeployBot and Cloud Sites.

Creating a new site on Cloud Sites

If you haven’t done so already, you’ll first want to create your website on Cloud Sites. Once logged into your Cloud Sites dashboard, simply click on Create Website, input your domain name, choose your Framework, and then click on Create New Website. Continue reading “Git & Continuous Deployment on Cloud Sites”

Using W3 Total Cache on Cloud Sites

Cloud Sites has a unique infrastructure setup that requires specific settings for the page cache to provide the best experience for a given site. Please use these settings when you are configuring W3 Total Cache instead of any other settings. These directions will provide an optimized configuration for W3 Total Cache on the Cloud Sites platform. This article assumes you have already installed the W3 Total Cache plugin. Continue reading “Using W3 Total Cache on Cloud Sites”

How to Configure Cyberduck for Use with Storm Object Storage

Storm Object Storage delivers a durable, secure, highly available solution for storage needs of virtually any size. With object storage access occurs via API calls to the object storage cluster, which replaces the need to rely on additional servers for dedicated storage.

Here we use the client Cyberduck to interact with Storm Object Storage. Cyberduck is available for download from https://cyberduck.io/?l=en.

Pre-Flight Check
  • These instructions are intended specifically for configuring Cyberduck for use with Storm Object Storage.
  • I’ll be working from a Microsoft Windows 8 desktop with Cyberduck already installed.

Continue reading “How to Configure Cyberduck for Use with Storm Object Storage”

How to Install WP-CLI

WP-CLI is a command line tool for interacting with and managing WordPress sites. WP-CLI is very similar in functionality to what drush provides Drupal. If you are already familiar with using cli tools then this will be quick to pick up on. If not, then it may be a good time to start learning.

In this tutorial we’ll learn how to install wp-cli on a server and learn some basics. With WP-CLI you can speed up common maintenance, automate tasks, or even take backups.

Install wp-cli for All Users

Installing a tool like wp-cli on a server globally means that any user will be able to use the application. With WordPress being one of the most common CMS’ it’s helpful to have wp-cli installed for all users.

Pre-flight Check:

  • Root-level command line access via SSH is required to follow this tutorial.
  • PHP 5.3.29, or higher, will be required for wp-cli to function.
  • WordPress 3.7, or later, is required for wp-cli support.

To start you should do a quick test to see if wp-cli is already installed on the server:
wp
If you see the error below wp-cli is not installed, you can continue with the tutorial to install it on the server.

[root@host ~]# wp –info
-bash: wp: command not found
If you see actual command output, as shown below, then wp-cli is already installed.
  1. To begin the install we will use curl to download the wp-cli.phar file:
    curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
  2. Then do a quick test of of download with the following:
    php wp-cli.phar --info

    Error: YIKES! It looks like you’re running this as root. You probably meant to run this as the user that your WordPress install exists under.If you REALLY mean to run this as root, we won’t stop you, but just bear in mind that any code on this site will then have full control of your server, making it quite DANGEROUS.

    If you’d like to continue as root, please run this again, adding this flag: –allow-root

    If you’d like to run it as the user that this site is under, you can run the following to become the respective user:

    sudo -u USER -i — wp

    In this case seeing the error above is a good sign, we were just verifying that the file executes correctly.
  3. Next we will ensure that the file has the correct file permissions for execution:
    chmod +x wp-cli.phar
  4. Finally we will move the wp-cli.phar executable to global location to ensure all users have access.
    sudo mv wp-cli.phar /usr/local/bin/wp

    In this step we are also renaming the file to feel more like a traditional cli tool.

To ensure you’ve done the process correct you can do one final test. You’ll still see the same error from the test above since we’re running as the root user.
wp --info

Error: YIKES! It looks like you’re running this as root. You probably meant to run this as the user that your WordPress install exists under.If you REALLY mean to run this as root, we won’t stop you, but just bear in mind that any code on this site will then have full control of your server, making it quite DANGEROUS.

If you’d like to continue as root, please run this again, adding this flag: –allow-root

If you’d like to run it as the user that this site is under, you can run the following to become the respective user:

sudo -u USER -i — wp

Again, seeing the error above is a good sign, we were just verifying that the file executes correct.

Verify & Test wp-cli as a Site User

Now that wp-cli is installed globally you will want to test the tool from a user hosting a WordPress site. To do this you will login as root via SSH then:

  1. su - wordpress
    By executing this command you will then be logged in as the ‘wordpress’ user. Do take note that you’ll enter the actual username where it says ‘wordpress’.
  2. Then you can run the following to get basic info about wp-cli:
    wp --info

    [wordpress@web01 public_html]$ wp –info
    PHP binary: /opt/remi/php70/root/usr/bin/php
    PHP version: 7.0.11
    php.ini used: /etc/opt/remi/php70/php.ini
    WP-CLI root dir: phar://wp-cli.phar
    WP-CLI packages dir:
    WP-CLI global config:
    WP-CLI project config:
    WP-CLI version: 0.24.1

As you can see from the above output running the wp-cli tool as a regular user does not trigger an error. You can also see that we’re running on a server with PHP 7.0.11 and wp-cli is at version 0.24.1.