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 Update WP-CLI

WP-CLI is a command line tool for interacting with and managing WordPress sites. In our previous article on How to Install WP-CLI we covered the process of installing WP-CLI onto a server. We did this in a way that the tool would be accessible by any user on the server. This prevents the need for your users to install the tool locally.
Continue reading “How to Update WP-CLI”

How to enable EPEL repository?

What’s an ‘EPEL repository’?

The EPEL repository is an additional package repository that provides easy to install packages for commonly used software. The EPEL repository is managed by the EPEL group, which is a Special Interest Group within the Fedora Project. ‘EPEL’ stands for Extra Packages for Enterprise Linux.

The EPEL group creates, maintains and manages a high quality set of additional packages. These packages may be software not included in the core repository, or even updates which haven’t been provided yet.
Continue reading “How to enable EPEL repository?”

How To Set up Email in Outlook 2016

Pre-Flight Check

 

Step #1: Add or Edit the Email Account

Continue reading “How To Set up Email in Outlook 2016”

Backup Your WordPress Database with WP-CLI

In this article you will learn how to backup your WordPress database using the wp-cli tool. Knowing how to backup your database is a critical skill to have when running a WordPress site. All your posts, pages, and more live in your database; keeping backups is critical.

You should always take a backup before any major changes to your site, just in case. It’s much quicker to take a backup now and do a restore if you need to, than to find a useful backup when you need it.

Pre-flight Check:

  • These instructions were created with a cPanel-based server in mind.
  • Command line access via SSH will be necessary to follow along.
  • The server must have WP-CLI installed, for installation directions see this tutorial.

To follow along with this tutorial you will need to have WP-CLI installed. If you have not yet installed wp-cli on your server feel free to read our tutorial here on that subject.

  1. Login to the server via SSH as the cPanel user that owns the domain, or the root user.
    ssh wordpress@198.51.100.142

    In the example we are using ssh to connect to the server. You can follow the rest of the steps even if you connect via alternative means(TTY, a Windows SSH Gui, etc).

    If you login as root you will need to use `su` to take on the user which owns the WordPress site before you continue.

  2. Now logged in (as the cPanel user) change to the WordPress root folder:
    cd ~/public_html

    We’re using a cPanel server so we know WordPress should be installed in the `public_html` folder. If you are not on a cPanel server it will be in a different location.
  3. Once in the WordPress root folder (where you can find wp-config.php) you can use the wp-cli tool. To backup your database run one of the following commands:
    • Backup the database to the current folder:
      wp db exportThis will use all the defaults for exporting the database as a backup. This means it will be in the current folder and will have the same name as the database.
    • Backup the database to a specific file:
      wp db export ../my_wordpress_db.sqlUsing this command will backup the database to a file called “my_wordpress_db.sql” and will put it in the folder above the current one (or `../`). This is done as a security measure to ensure no one can download your database.

Once you’ve run the export command you’ll see confirmation output like the following:

Success: Exported to ‘../my_wordpress_db.sql’.

After you see that confirmation your WordPress database is officially backed up. Now you can continue making changes or updates and will have a way to restore if anything goes wrong.

Troubleshooting email in WHM

In this article we will go over the process used to investigate Email delivery issues on a WHM server. This can be helpful when a user is having issues receiving or sending Emails. The Mail Troubleshooter tool provided in WHM works by tracing the route an Email would take when sent to the provided Email address.

  1. With WHM opened in your browser, (a) type ‘Mail Troubleshooter’ into the search box. This will sort the menu options for you, (b) now find and click “Mail Troubleshooter”.
    troubleshoot-email-pt1
  2. Now on the Mail Troubleshooter page you should see a text box labeled as “Email to trace”. Enter the Email address you wish to trace here.
    troubleshoot-email-pt2
  3. Once you click Submit, you will be on the results page.
    troubleshoot-email-pt3

The example above shows a working configuration for a Gmail based email address. If the results show no errors the issue is likely related to improper Email client settings.
Below you will find an example of results showing errors, the issue here is that the domain has DNS problems and is not able to be resolved.

troubleshoot-email-pt4

EasyApache 4 & CLI based PHP utilities

With the release of EasyApache 4 in WHM 58 there are various changes to how PHP is managed. The most obvious being that EasyApache 4 brings support for installing multiple PHP versions alongside each other. However with multiple versions of PHP being installed on the server it’s easy to lose track of your command-line based PHP utilities and their PHP requirements.

Certain PHP packages like Composer, Drush, and WP-cli prefer to be run with the latest version of PHP. Unfortunately, having multiple PHP versions can mean not knowing which PHP will execute the utility when you call it directly. This article will detail a few methods to specify which PHP version should be used in instances like this.

Pre-flight Check:

  • These instructions are intended specifically for cPanel-based servers running WHM prior to version 58.
  • Command line access via SSH may be necessary to follow the examples.
  • The server will need to have EasyApache 4 active.
  • PHP 7 will be necessary to follow the provided examples.

Option #1: Directly Call the PHP Binary

The most basic option to workaround these issues is to directly call the PHP binary you need before executing the script. While this can be effective and will work as expected most of the time, certain utilities will not work when using this method.

You may want to attempt this method first and move on to Option #2 if this does not work as expected; generally though, this should work for executing basic PHP code.

/opt/cpanel/ea-php70/root/usr/bin/php someScript.php

The above command will specifically call the 7.0 version of PHP and will execute the someScript.php file within that version of PHP. If they are also installed on the server, the alternative PHP versions can be found at:

  • /opt/cpanel/ea-php55/root/usr/bin/php
  • /opt/cpanel/ea-php56/root/usr/bin/php
  • /opt/cpanel/ea-php70/root/usr/bin/php

Option #2: Use scl to Specify PHP Versions

As mentioned, certain PHP utilities are not provided as basic PHP files and are stored in the PHAR format. These utilities will not execute properly with the above method for specifying the PHP version. For these types of utilities you will need to specify the PHP version using a command called `scl`.

This command is a utility that allows running software in an environment packaged as a ‘Software Collection’. To be brief a ‘Software Collection’ is a way of defining an alternate location to a certain software. Fortunately, WHM provides predefined collections for the various versions of PHP supported by EasyApache 4.

The syntax of this command is as follows:

scl enable {SoftwareCollection} '{CommandToRun}'

Where you replace {SoftwareCollection} with the needed collection [ea-php55, ea-php56, or ea-php70], and you replace {CommandToRun} with the command, utility, or script you need to run.

A good way to highlight this is to review the difference in the following outputs:

root@noms [~]# php -v

PHP 5.6.25 (cli) (built: Aug 25 2016 17:00:38)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with the ionCube PHP Loader v4.7.5, Copyright (c) 2002-2014, by ionCube Ltd., and
with Zend Guard Loader v3.3, Copyright (c) 1998-2014, by Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies

root@noms [~]# scl enable ea-php70 'php -v'

PHP 7.0.10 (cli) (built: Aug 25 2016 18:04:55) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.10, Copyright (c) 1999-2016, by Zend Technologies

As you can see when calling PHP by itself we get the default version, but when using scl we explicitly called the PHP 7.0 collection and get results to match.

Example #1: Executing a utility [Composer]:

root@noms [~]# scl enable ea-php70 'composer --version'

Composer version 1.2.0 2016-07-19 01:28:52

Example #2: Running a PHP script:

root@noms [~]# scl enable ea-php70 './someScript.php'

With these key tips and tricks you should now be equipped with the necessary tools to run CLI utilities on a server using EasyApache 4. If you have any questions or are not comfortable making these changes yourself, please feel free to contact Heroic Support®.