How To Manually Set Up Clients in WHMCS

Reading Time: 3 minutes

WHMCS is an amazingly capable software allowing you to manage your clients from initial purchase, continued support, and billing management. However, if you already have clients and you’re looking to get started with WHMCS, you will need to get those clients into the new system. While this process does require some manual work, it is absolutely possible and once they are set up, the automation can take over from there! In this guide, I will show you how to manually set up your existing clients into WHMCS.

Adding A Client Profile and Product in WHMCS

  1. Log in to your WHMCS Admin dashboard
  2. Hover over Clients, then Select Add New Client.

add a client drop-down menu screenshot

  1. Fill in the form with the required information.

new client information form screenshot

    1. Client Profile Information
      1. First Name
      2. Last Name
      3. Company Name
      4. Email Address
      5. Password
      6. Address 1
      7. Address 2 (optional)
      8. City
      9. State/Region
      10. Postcode
      11. Country
      12. Phone Number
    2. Client Billing Information (where applicable)
      1. Payment Method
      2. Billing Contact
      3. Language
      4. Status
      5. Currency
      6. Client Group
      7. Credit Balance
    3. Account traits
      1. Late Fees
      2. Overdue Notices
      3. Tax Exempt
      4. Separate Invoices
      5. Disable CC Processing
      6. Marketing Emails Opt-out
      7. Status Update
      8. Allow Single Sign On
    4. Include any relevant Admin Notes
  1. Tick the box IF you would like to send New Account Information to the client upon creation
  2. Click Add Client. Once added it will take you to the “Client Profile”.

add client button highlightedViewing the Client Profile

The Client Profile screen contains all of the information for a given client, separated into tabs. We’ll review the tabs and the information you can find under each tab.

  • Summary: this shows the “at-a-glance” summary of the client

client summary tab screenshot

  • Profile: this tab contains the basic information you entered when you setup the client.

Client profile, profile tab highlighted

  • Contacts: Add and modify additional contact information for the client.

contact tab screenshot

  • Products/Services: New clients will have no products/services. Use the Click Here link to place a new order.

New product button highlighted

  • From the new order page, you can confirm client details, select a default payment method, enter Promotion codes, set the order status, select a matching cPanel package, and additional details about the new client package. If this is a new client, the cPanel account will be created and mapped automatically. For an existing client, enter the cPanel username and password for the account, then use the cPanel/WHM Import Tool to connect the client with their cPanel account.

cPanel/WHM Import Tool

  1. Navigate to “Utilities > cPanel/WHM Import”, then select the Server from the drop down.

cPanel import tool highlighted

  1. Sort through the Domains and check ONLY the domains you are looking to import. This can be done as many times as needed, so feel free to do them in short batches if that’s easier.
  2. Once imported, it will most likely create a new client profile. It could potentially match the new information based on matching cPanel email addresses and the client email addresses you create. If WHMCS matches the new information correctly, you’re done. If not, continue with the steps below.
  3. If the system creates a new client and ties in the product, navigate to that client profile.
  4. From the Import Generated Client Profile, navigate to Products/Services, then click on Move Product/Service.

move product button highlighted

  1. Enter Client ID (if you don’t know it, you can find those under Clients > View/Search Clients and finding the ID column). Click Transfer and the client will now be matched to the correct product information.

With this guide you can add all of your existing clients and get them set up on billing plans to fully automate your existing clients as well as all of your new sign ups. This guide was specifically regarding your cPanel clients. However, Liquid Web also offers a WHMCS Plugin that integrates with our Cloud platform allowing you to do this with any existing VPS or Cloud Dedicated clients you have as well! You can use these links to learn about our WHMCS offering and see the Liquid Web WHMCS Plugin.

 

How To Delete Post Revisions using WP-CLI

Reading Time: 2 minutes

There may be times when you need to clean up post revisions created on your site. This is possible, using the commands already available in WP-CLI.

WP-CLI has a wp post delete command which can be used to delete post revisions. Post revisions are changes made to content on your site, over time those post revisions on your site can mount up. The following directions assume you are using one of Liquid Web’s Managed WordPress or Managed WooCommerce products. You can also use these techniques with other WordPress installations, just be sure to run the commands from the primary WordPress installation folder.

Preparing to Run Commands

One of the first steps will be to generate sFTP/SSH credentials from your site manager. You can use Terminal on the Mac, or Putty on a PC to use WP-CLI. For more information about logging into your server using SSH, see Logging into Your Server via Secure Shell (SSH).

Log in, then go to the WordPress installation folder by entering:

cd html

It is always a good idea to create a database backup before making significant changes to your site, like bulk deleting post revisions. To create a manual backup run this command:

wp db export

You can now use gzip to compress the resulting sql file which will mean a smaller file being stored on your server:

gzip sitebackup.sql

Cleaning Up Your Post Revisions

To delete post all revisions (moving them temporarily into the trash), use this WP-CLI command:

wp post delete $(wp post list --post_type='revision' --format=ids)

To delete the post revisions which have been moved to the trash (this includes all post revisions which have a post status of trash), run this command:

wp post delete $(wp post list --post_type='revision' --format=ids --force)

You can skip the first step of moving the posts to the trash by just running the second command. This will remove all post revisions, both those in the trash and those that are in the active portion of the site.

More Control Over Post Revisions Removal

If you need more control of deleting post revisions, there is a package which can be installed from a third-party for WP-CLI. Please note: This package is not provide by Liquid Web nor is it endorsed by Liquid Web. Please use at your own discretion.

To install the package for WP-CLI, run the following command:

wp package install trepmal/wp-revisions-cli

After the package WP Revisions has been installed, to clean all post revisions, you can use the following command. Please note: this command can be slow, since it will query post revisions before deleting them.

wp revisions clean -1

If you wanted to delete all post revisions before a specific date, you can include that in the command. For example:

wp revisions clean --before-date=2019-06-10

If you needed to clean all post revisions other than those for a specific post type, include that post type at the end of the command. For example, revisions for the WooCommerce created product post type would not be deleted if you run this command:

wp revisions clean --post_type=product

For a faster method to delete all post revisions, you can run this command:

wp revisions dump --hard

To list all existing post revisions, you can run this command:

wp revisions list

Easily deleting post revisions from your site database will help keep the database cleaned up. Streamlining the database can result in performance improvements, especially as the size of the database grows.

How To Secure Your WordPress Site

Reading Time: 4 minutes

WordPress is one of the most popular Content Management Systems on the Internet. Due to it’s popularity, it is also the target of many hackers.  We’re here to show you our top 5 recommendations on how to secure your WordPress site based on issues we’ve come across.

1. Keep WordPress Up to Date!

Our number one and top recommendation is to keep WordPress up to date! WordPress is a very active platform and updates come out regularly for it. The updates include many new features and changes in the backend, but also patch many bugs and exploits that the WordPress team finds. Just take a look at the releases and patch notes on https://wordpress.org/news/ sometime to get an idea of how much work gets put into finding and fixing these problems!

Being even just one or two versions behind can leave your site open to hackers that analyze the updates, create exploits, and go looking for outdated sites across the Internet. The longer a site isn’t updated, the more exploits and vulnerabilities are out there, and the increased likelihood that your site could be compromised.

The same rule applies to your Plugins and Themes, make sure those are all properly updated for the same reasons! Which brings us to item two on our list!

2. Review your Plugins and Themes!

WordPress is great because the plugins can quickly and easily give new features and customize your site very quickly, and themes can give your site a very professional appearance in a matter of seconds, but if they are not properly maintained, it could lead to problems down the road.

First, just remove any plugins and themes you don’t need. You could leave them disabled, but outright removing them is a safer option as the files wouldn’t be sitting on your server. Even if it’s disabled, it could still potentially be reached if an exploit can gain access to the files.

A side effect of removing the plugins is that it could actually speed up our site as well!

After removing any plugins and themes you don’t need, make sure to keep the ones you have left updated. WordPress can generally check for updates right in the admin area, but if you bought a plugin from a third party source, make sure to check with them for any updates. It would also be recommended to visit the website of each plugin and theme or even check reviews on other sites to make sure development is still active on it and that there are no known vulnerabilities.

3. Protect your logins!

Having your site publicly accessible out on the internet means customers and potential clients can access your site, but so can bots and people with malicious intentions! By default WordPress allows you to go to yourdomain.com/wp-login.php or yourdomain.com/wp-admin and should bring up a login page. If you try that on any of your sites and you get the login page, it’s highly recommended you use a plugin to hide where you go to log in.

WordPress does have some general security that blocks attempts after a few failed attempts, but if thousands of bots are all trying to log in and guess passwords, why even give them the chance to try? Make sure you use strong passwords, don’t use the same username and passwords in multiple locations, and go through your WordPress users to make sure they are all still valid. For example, if you gave a developer access years ago, maybe you don’t need that user sitting around there still.

4. Install protection plugins

I know I said to reduce your plugins earlier, but I would recommend having some plugins to block malicious connections, monitor suspicious activity, and scan site files for malware. We recommend iThemes Security, as it offers a lot of different features in just a single plugin, but you can look up what’s popular and read other reviews to help you decide on what would be the best fit with your site. For example, if you have a site where users can upload data, it would be a good idea to scan those files as they are being uploaded and block or at least report any that trigger warnings in a plugin that scans for viruses and malware.

Depending on how much protection you need, paid options would be recommended over free options to help increase the chances that newer exploits are blocked as well with more features and newer virus definitions.

5. Make sure you have good backups

Having good backups isn’t exactly a proactive step on how to protect your site, but it sure is a reactive step that can greatly help if the need arises. It’s a good idea for any business that relies on the data on their site. Think about all the orders, profiles, records, logs, and any other important information stored on your site, then imagine if something causes a problem and the whole site gets deleted, maybe a hard drive crash or malicious code is injected into it somewhere and causes the data to be lost. If you have no backups at all to restore from, then depending on the nature of your business this may be hundreds of work hours for a team to rebuild the site, lost revenue, lost customers, and would definitely be a major hit to your site’s reputation.

If you did have backups, depending on the frequency of the backups and how quickly the problem was noticed and rolled back, there may be little to no data loss, customers may not notice, and the site can quickly bounce back.

We highly recommend having multiple backups taken over a period of time. The more backups you have the more options you would have to restore from. Having only one daily backup could cause problems if an issue isn’t noticed until three days after it happens. Active sites may need continuous backups compared to a static site that maybe hasn’t changed in months.

Also storing your backups in different locations would help spread out the number of available backup copies. Like if a dedicated backup hard drive failed then you could still have remote backups saved on a different service that wouldn’t be affected. Think of it like not putting all your eggs in one basket! For more information on good backup practices, see Best Practices: Developing a BackUp Plan.

Hopefully, you gained something useful from this article! If you or a friend are in the market for a web host, feel free to talk to a Liquid Web tech by phone or in a chat 24 hours a day! Thanks for reading!

How to Check for Installed Packages on CentOS

Reading Time: 3 minutes

While managing your server, you’ll sometimes need to check on which software (or packages) you have installed on your system. You’ll need to know package names, version numbers, dates of installation, etc. In this Liquid Web tutorial, we’re going to be discussing how to inspect packages installed on your CentOS system. There are several ways to accomplish this, and we’ll discuss a few of them. Let’s dig in! To use these commands, you’ll need to log in to your server via SSH. For more information, see Logging into Your Server via Secure Shell (SSH).

Using RPM Package Manager

This first command uses the rpm package manager to poll for installed packages. This command allows you to see every installed package on your system, along with the version that is currently installed:

rpm -qa
Note the -q means “query” and -a means “all”. We’re asking rpm to query all installed packages.

Let’s examine a small portion of the results in detail. Note that you might not have these specific packages installed on your CentOS server. The important thing here is to understand how to read the output. Take a look at a small excerpt of entries from the list.kpartx-0.4.9-123.el7.x86_64
dracut-033-554.el7.x86_64
elfutils-libs-0.172-2.el7.x86_64

Each entry can be broken up into three parts. From left to right, these are:
Package name: (kpartx)
Version: (0.4.9-123.el7)
Architecture: (x86_64)

Instead of displaying all installed packages, rpm can also be used to search for a single package. Let’s use rpm to query kpartx:
rpm -q kpartx
You’ll see the output displays the same package name and version we saw from rpm -qa.
kpartx-0.4.9-123.el7.x86_64

Using Yum to Check Installed Packages

Using rpm is not the only way to check for installed packages on your system. Now we will discuss how to use “yum” to accomplish the same task. Try the following command:
yum list installed
You will see that the list yum provides is formatted slightly differently. Let’s look at an entry in depth.
whois.x86_64 5.1.1-2.el7 @base
The first column shows the package name and architecture: (whois.x86_64).
The second column shows the version installed: (5.1.1-2.el7).
Finally the third column shows the repository the software was installed from: (@base).

Using Yum to View Historical Installation Data

We can also use yum to view historical installation data on your system. Run the following command to see a list of anytime yum was used to install, remove, or upgrade a package:
yum history
Here is an example of the output you might see. Your system will show different results here, and that is OK. We’re just interested in learning how to read the output.
ID | Command line | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
10 | upgrade | 2019-06-01 04:13 | I, U | 12 EE
9 | install whois | 2019-05-04 17:40 | Install | 1
8 | install python36 | 2019-05-03 21:23 | Install | 2
7 | install epel-release | 2019-05-03 21:02 | Install | 1
6 | install bind-utils | 2019-05-03 19:33 | Install | 2
5 | install docker-ce docker | 2019-05-03 17:37 | Install | 4
4 | install yum-utils yum-co | 2019-05-03 17:26 | Install | 6
3 | install git | 2019-05-03 17:19 | Install | 4
2 | install vim | 2019-05-03 17:18 | Install | 31
1 | update | 2019-05-03 17:09 | I, U | 57
history list

Notice the column headings: “ID number, Data and time, Action(s), and Altered.” This is a good summary of when yum was used, but it is lacking detailed information. Let’s examine one of these history entries in detail. Try the following command, replacing “ID_NUMBER” with the actual ID you want to inspect.
yum history info ID_NUMBER

Here is some example output:
Loaded plugins: fastestmirror
Transaction ID : 9
Begin time : Sat May 4 17:40:24 2019
Begin rpmdb : 356:8ab21eca9f4a219812e33c41a73fbd4eb7de1ed8
End time : (0 seconds)
End rpmdb : 357:cf2bf4588ba4d3263d1c9af051c3bcc525596a68
User : Cloud User <centos>
Return-Code : Success
Command Line : install whois
Transaction performed with:
Installed rpm-4.11.3-35.el7.x86_64 installed
Installed yum-3.4.3-161.el7.centos.noarch installed
Installed yum-plugin-fastestmirror-1.1.31-50.el7.noarch installed
Packages Altered:
Install whois-5.1.1-2.el7.x86_64 @base
history info

In this tutorial, we discussed how to use rpm and yum to search your CentOS server for installed packages. These utilities are both critical tools for Linux sysadmins on CentOS systems. Of course if you have any questions about how to use these utilities on your own Liquid Web server, let us know! The Most Helpful Humans in Hosting are standing by 24×7 and we’ll be happy to answer your questions.

How to Convert .htaccess Rules to NGINX Directives

Reading Time: 6 minutes

NGINX is a webserver that is becoming an increasingly popular option for webhosting, as sixteen percent of all sites on the internet are utilizing NGINX. This percentage is constantly increasing as clients are in need of a web server that can serve content faster. It can also be used for proxies, reverse proxies, load balancing, and more depending on what modules you load onto NGINX. One of the significant differences between Apache (a popular webserver) and NGINX is the way each system handles access rules. If you are familiar with using .htaccess rules in Apache, then the method that NGINX uses of including directives in the server’s vhost block will be substantial change.

We will be showing how to convert .htaccess rewrite rules to NGINX rewrite directives. The NGINX rewrite directives will also need to be placed within the server block. Many server configurations include this server block information in the vhosts file, while some use a separate NGINX configuration file (for more information about the NGINX configuration file, see Redirecting URLs Using NGINX). To complete this task, you will need to understand some of the basic NGINX directives I will be discussing in the next session.

Introduction to NGINX Rewrite and Return Directives

The most commonly used directives with NGINX are the return and rewrite directives. When using an NGINX directive, a client visiting a page can be directed to a different directory or a different landing page. Requests can also be redirected to an application depending on the directives you specify. For example, clients visiting the page from a smartphone can be forwarded to a script that is coded specifically for phone browsers. Another example would be to forward a client based on IP or geographical location, making your site region specific and tailored to the visitor based on location.

NGINX Return Directive

The return directive is a bit less complicated than the rewrite directive. Best practice is to use this directive over the rewrite directive whenever possible. You will typically include the return in a server context that specifies the domains to be rewritten. I have included a common example below. Clients visiting the site will be redirected to the domain specified after the 301 status code. Using this directive will forward the client that visits www.liquidwebtest.com to www.liquidweb.com.

server {
listen 80;
server_name www.liquidwebtest.com;
return 301 $scheme://www.liquidweb.com$request_uri;
}

  • Server { } is defining the block
  • Listen “what port to listen to”
  • Server_name “defining the incoming requested URL”
  • Return “what the server returns from this request”

NGINX Rewrite Directive

The rewrite directive is somewhat different that the rewrite rules in .htaccess. It needs to be placed in a specific location or server block in order to rewrite the URL. The rewrite directive is usually used to perform smaller tedious tasks. For example, it is used in some cases to capture elements in the original URL or change elements in the path. The NGINX rewrite directive can get very complicated but once you understand the basic syntax it can be a lot less intimidating. I have included the basic syntax for a NGINX rewrite directive below.

rewrite regex URL [flag];
It is important to know a rewrite directive will almost always return a HTTP 301 or 302 status code. If you need your web server to return a different status code, the return directive is needed after the rewrite. I have included an example below from NGINX’s rewrite module documentation.

server{
...
rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;
rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra last;
return 403;
...
}

In this example the URLs that start with /download followed by /media or /audio are matched. Afterwards directories /media and /audio elements that contain /mp3 will have the extension .mp3 or .ra file extension added to the URL. This return directive will return a 403 to the client if the URL does not match the rewrite rule.

Converting .htaccess rules to NGINX directives

Hopefully by this point we have a basic understanding of the two most commonly used NGINX directives. However, learning these rules will take some time as the can be very complex. Learning regular expression is very helpful in this process. We’ll work through examples of commonly used htaccess rules that we will be converting to NGINX directives.

Example: Redirecting from example.com to www.example.com

Adding the www to a URL when a client requests content from your server can help certain sites (like those hosted on WordPress) to function more efficiently. A common .htaccess rule to accomplish this rewrite is:

RewriteCond %{HTTP_HOST} example.com
RewriteRule (.*)https://www.example.com$1

As I mentioned earlier it is best practice to use the return directive whenever possible. Below we will be creating a server block within the nginx.conf to accomplish the same task as the .htaccess rewrite rule above.

server {
listen 80;
server_name example.com;
return 301 http://www.example.com
$request_uri;
}
server {
listen 80'
server_name www.example.com;
#...
}

In this example there will be two server blocks defined with brackets” {}”. We are telling NGINX to listen on port 80 for requests to example.com. Then to return a 301 ”redirection” to www.example.com. We usually split these rules in two server blocks to make these directives as efficient as possible. The 2nd is not always needed but will serve content from the working directory if www.example.com is requested. If no exact match is found, NGINX then checks to see if there is a server_name with a starting wildcard that fits. The longest match beginning with a wildcard will be selected to fulfill the request.

You can test your syntax by running the following command:

nginx -t

This allows you to test the syntax for errors before loading the changes in the configuration file and possibly causing issues on your live site. Once you have edited the NGINX configuration file be sure to restart NGINX using a daemon or simply running the command below.

nginx -s reload

Example: WordPress Permalinks

In this example, I have included one of the most common set of .htaccess rules used today. The rules I have included below allow wordpress to utilize permalinks. This is installed by default with wordpress on an Apache server. A permalink is a URL that is intended to remain unchanged. For example, domainexample.com/blogexample.php can be loaded as domainexample.com/blog within your browsers address bar.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L] RewriteCond ${REQUEST_FILENAME} ~ - f
RewriteCond ${REQUEST_FILENAME} ~ - d
RewriteRule . /index.php [L] <IfModule>

Belowis the NGINX equivalent. No return or rewrite directive is needed here as we are only allowing the content management system to hide the paths using permalinks. For more information on this task please see NGINX’s documentation on permalinks.

location / {
try_files $uri $uri/ /index.php?$args;
}

You can test your syntax by running the following command:

nginx -t

This allows you to test the syntax for errors before loading the changes in the configuration file and possibly causing issues on your live site. Once you have edited the NGINX configuration file be sure to restart NGINX using a daemon or simply running the command below.

nginx -s reload

Example: Forcing http to https

Another popular use for the htaccess file is to force the browser to load the site using https over http. This allows the browser to verify the site is not a security risk by confirming the site exists on the server it claims to be on (see What Is an SSL Certificate?). It can also be used to verify a business location, business ID number, and location. This helps prevent visiting malicious sites that may cause harm to your personal computer or private information.

The following .htaccess rule will force https, so that requests using port 80 for example.com will be redirected to https://www.example.com.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC] RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

To accomplish this with NGINX, we will use the NGINX return directive.

server {
listen 80;
server_name example.com;
return 301 https://www.example.com$request_uri;
}

You can test your syntax by running the following command:

nginx -t

This allows you to test the syntax for errors before loading the changes in the configuration file and possibly causing issues on your live site. Once you have edited the NGINX configuration file be sure to restart NGINX using a daemon or simply running the command below.

nginx -s reload

Conclusion
We could go on and on with examples but hopefully at this point we now have a basic understanding on converting htaccess for Apache to NGINX directives. If you require further information on accomplishing these tasks you can always reach out to our support for assistance. However, we do not fully support NGINX and it is considered Beyond Scope support. This means we will assist you as much as possible but we may not be able to resolve your issue and may instead refer you to a developer for additional assistance. If you want to use NGINX web server to host your content, we have multiple options including our VPS lineup to meet your business requirements. NGINX is currently being developed for use on cPanel servers as well, although it is not currently supported or recommended in production situations. See cPanel’s blog for more information.

What is an EPP Code?

Reading Time: 4 minutes

When you have control over a domain name it grants you several extremely powerful options such as renewing it, cancelling it, and pointing inbound traffic to a location of your choosing. Because of the long-term impact all of these changes could have, Registrars (such as eNom and GoDaddy) take security very seriously. What does this mean for you? If you are wanting to transfer a domain to a new Registrar, you are going to need the authorization code from the current Registrar and that takes the form of the EPP Code.

The EPP Code (or EPP Key) is a complex system-generated password that a Registrar will create upon request and provide to the domain owner via the contact email address for the domain according to its WHOIS record. This allows the domain owner to contact their new Registrar, who will use the code to confirm ownership. These codes customarily expire within a day or two though which means if the owner does not submit the transfer request quickly, they may have to get a replacement EPP Code and try again. It should also be noted that a domain cannot be transferred within the first 60 days, nor within 60 days of a previous transfer.

How Can I Get an EPP Code?

Requesting an EPP Code is a fairly simple process, usually just requiring you to login to the Registrar that currently controls the domain name you want to transfer and pressing a “Request EPP Code” button. If you used a web host to register the domain for you, you may have to open a support ticket with your host to get the code generated for you.
For reference, here are the processes with several different Registrars and web hosts. If you are not sure who the current Registrar is for your domain name, you can do a WHOIS lookup.

At Liquid Web?

To transfer a domain name away from Liquid Web, first log into your manage portal and click on the Domains tab on the left-hand side:domains link in manage.liquidweb.com highlighted
Then click on the domain you want to transfer, which will bring up the details page featuring a “Transfer this Domain” button on the right:

transfer domain button highlighted

Clicking that will show you a confirmation prompt:

transfer confirmation dialog box

Confirm the domain and registrant email address are correct, and then press “Start Ongoing Domain Transfer” to begin. If this has been successful, you’ll see the following confirmation:

domain transfer request started information box

Once you receive the email with the code, you’re all set and ready to proceed. If you do not get an email, you’ll want to contact Liquid Web support.

At 1&1 IONOS?

To transfer a domain away from 1&1 IONOS, you’ll want to check the Domains section in your My IONOS panel. Clicking on “Rewal & Transfer” will allow you to select your domain. You’ll want to make sure the “Domain Transfer Lock” option is disabled and once it is, click “Show Activation Code.” If this does not work, you will need to contact IONOS support for more information.

At Dreamhost?

To transfer a domain from DreamHost, you’ll need to access your Panel, and unlock your domain. Check the Registrations section, and if the status for “Locked?” shows “Yes,” then simply click the word to unlock it. If it shows “no,” you’re all set. If you click “Or Transfer Away from Dreamhost,” the EPP Code generation prompt will be displayed. Click the “Reveal Auth Code” button to display the code, though depending on the TLD (Top Level Domain, such as .com or .gov), the code may be required to be emailed instead. If you do not receive a code or an email, you’ll want to contact support.

At GoDaddy?

If your domain name is currently with GoDaddy, you’ll need to log into the Domain Control Center specifically. Click on the button to “Manage” the domain in question and scroll down to “Additional Settings,” where you’ll see the option to “Get authorization code.” Once that link is pressed, the code will automatically be emailed to you. If the option shows disabled, your domain may be within 60 days of being registered or has previously been transferred or currently under a 60 day lock. Contact GoDaddy support for more information.

At HostGator?

If HostGator is your current Registrar, you’ll want to access the Domains section of your Dashboard and click on the domain in question. If you click on the ‘lock’ icon, the “Domain Locking” options are presented. Make sure the “Domain Locking” slider is in the OFF position, and press the “Request Your EPP Key” button to make the code visible. If you do not have a billing account with HostGator or your domain does not show up, you’ll want to contact HostGator’s support for assistance.

At NameCheap?

To transfer a domain name from NameCheap, you first have to log into your manage portal and click on the “Domain List” section. Select the domain you would like to transfer using the “Manage” button and using the “Sharing & Transfer” tab, set “Domain Lock” to OFF and press “Auth Code.” You will be prompted to respond with the reason for transferring, but the code will then be emailed to the registered email. If the prompt does not complete or you do not get an email, contact NameCheap support.

At Network Solutions?

If your domain is currently registered with Network Solutions, you will need to call their support line that is specifically for domain names at 1-888-642-0209 and request the EPP Code on the phone. This will be emailed to the registered contact.

What Do I Do With My EPP Code?

If you have not already started the domain transfer process with your new Registrar or web host, you’ll want to do that now. This is routinely handled in a support ticket and when the request is started, support will ask for the authorization. Simply give them the EPP Code, and the Registrars will communicate and confirm the transfer. You may be required to renew the domain name in question which will push back the expiration date, but the task is otherwise complete and your domain name should now be in the hands of your new Registrar!

How To Verify WordPress Checksums Using WP-CLI

Reading Time: 2 minutes

If you do not keep site plugins updated along with WordPress core updated, then you run into the chance of your site being hacked or infected by Malware. If your site does get infected by malware, a way to easily find any of the non-standard WordPress core and plugin files is by using the verify checksums commands in WP-CLI (the WordPress Command Line Interface).

Preparing to Run Commands

First, you will need to login to your portal via SSH. For directions on generating credentials for sFTP/SSH creds from your site manager, see Finding Your SFTP/SSH Credentials in Managed WordPress Portal. For help using SSH, see Logging into Your Server via Secure Shell (SSH).

Getting Started

Security plugins have definite uses, but when you need to verify WordPress core as well as all installed plugins on the WordPress.org checksums, plugins are just not the appropriate tool. WP-CLI already has checksum commands for both WordPress core and all plugins.

Checksums Commands

  • To verify that all WordPress core files checksum match, the WP-CLI command to run is:

wp core verify-checksums

  • To verify checksum against specific versions of WordPress, you can include the version number in the command. To verify for version 5.2.1 of WordPress core, for example, the command would be:

wp core verify-checksums --version=5.2.1

  • If you were using an older version of WordPress, for example version 4.9.10, the command would be:

wp core verify-checksums --version=4.9.10

  • To verify the checksum of all plugins which are installed on your site server (this would only include plugins available from WordPress), then the command to run would be:

wp plugin verify-checksums --all

  • To verify the checksums of a specific plugin (e.g., WooCommerce), you will need to know the plugin “slug” (or short name). You can find the slug by looking in the plugins links on the WordPress website.

The plugin slug for WooCommerce is woocommerce, so to verify the checksums of the WooCommerce plugin, the command would be;

wp plugin verify-checksum woocommerce

Summing Up

The files that the core verify checksum or the plugin verify checksum commands in WP-CLI will display will be any of the non-standard PHP or other files that should not exist in WordPress folders. The files should be deleted (it’s always a good idea to take backups before deleting data from your server). and then you can rerun the same verify checksums commands to check that there are no other files which should not exist on your site server.

Knowing how to verify the checksums of WordPress core files, all plugins installed from WordPress.org, and specific plugins installed from WordPress.org using simple-to-use WP-CLI commands will give you peace of mind in knowing that there are no non-standard files that exist in those folder directories.

How to Use the Mail Queue Manager in WHM

Reading Time: 3 minutes

The Mail Queue Manager feature in WHM allows you to view, delete, and attempt to deliver queued emails that have not yet left the server. It can be a handy tool for diagnosing a variety of issues with mail deliverability, such as spotting signs of a compromised account sending spam from the server.

Accessing Mail Queue Manager in WHM

If you are unfamiliar with how to access WebHost Manager (WHM), you can take a look at our article Getting Started with WHM.

Once logged into WHM, you can navigate to the Mail Queue Manager page by inputting the text “mail queue” into the search box above the left menu, then click the Mail Queue Manager option:

mail queue manager link in WHM

Searching for Queued Emails

From the Mail Queue Manager main page you will see a section for searching through these queued emails. You can input either a Sender, Recipient, or Message ID (a unique identifier the mail server gives each email sent and received) to filter through the queued messages.

Once you input a search for one of these options, select the corresponding option from the Select Query dropdown menu next to the text box: Search Sender, Search Recipient, or Search Message ID.

You can also select No Filter if you do not want to restrict the search to one of these specific options.

The search filter also includes a section to select a particular time frame by entering a Start Date and End Date. This will filter the search results down to emails that fall within this time frame. Please note: WHM only retains this data for 10 days, so email outside of that time frame will not be included in the search results.

Once you’ve input the text to search, and selected the filter options, click the Run Report button.

Below is an example of a search for all messages in which the sender of the email matches “user@domain.com”:

mail queue search screenshot

Viewing Queued Emails

To view an email currently in the queue, under the Actions column, click the magnifying glass icon:

example of email in the mail queue

This will display the email’s simple headers, text content, and provide you with options to delete the email, attempt delivery, download the email in .eml format (which you can open in mail client applications such as Microsoft Outlook), or view the email’s extended headers and control data:

example of email header detail in the mail queue

Delivering Queued Emails

As shown above, you can view a specific email and click Deliver Message Now to attempt delivery of the message. You can also select messages from the main page of the Mail Queue Manager and click Deliver Selected:

detailed view of the mail queue

The option Deliver All will attempt to send out all emails currently in the queue.

Deleting Queued Emails

To delete an email currently in the queue, you can view a specific email using the instructions above and then click Delete Message.
Multiple emails can be deleted from the queue using the main page of the Mail Queue Manager. You can either select each email you’d like to remove and then click Delete Selected, or you can remove all queued emails by clicking Delete All.

Unfreezing Frozen Queued Emails

You may see emails listed as Frozen under the Status column. These are emails that failed to deliver after multiple attempts, so in order to help the queue continue to run efficiently, the system will ‘freeze’ these emails. To unfreeze an email, you can click the second icon under actions:

frozen email in the mail queue

Once unfrozen, the email will attempt to send during the next queue run. Forcing a delivery attempt of a frozen email will also unfreeze the selected email.

Multiple frozen emails in the queue may indicate an issue that requires further investigation, such as a remote mail server blocking the mail transaction.

For more information on diagnosing email deliverability issues, you can take a look at our article entitled Troubleshooting: RBLs and Email Delivery Problems (Rejected Email Messages).

How To List Users in CentOS 7

Reading Time: 2 minutes

Adding a user in CentOS is a common task for most Linux admins. User’s have unique username’s and occassionally you may wonder if a username is in use or need other details about the user (like their group ID). We’ll show you how to see a list of users by logging into your Liquid Web CentOS 7 server. Once you’ve logged in via SSH, you’ll be able to run the commands below and get the information you need. Let’s get started!

To get a simple list of user names, enter the command below and press Enter.

getent passwd | cut -d: -f1

This command gives us a list of users assigned to this CentOS server. If you’d like a more detailed list of user you can use the command below. Using the command will provide you with the username, UID, GID, User Details, their home directory path, and the Default Shell for the user.

getent passwd

Example Output:

In our example you’ll see each field is separated by colons. Let’s breakdown the sections to provide more information on the user.

  • Username-the user example is root. Other users include bin, daemon, systemd-network, among many others. These are for when these entities need to access the system.
  • Password-indicated by the letter x, you can also find this encrypted password in the /etc/shadow file.
  • UID-this is the user’s ID, indicated by number starting at 1000. The root user is special as its UID is 0.
  • GID-like the user ID, the group ID shows us the the group that a user belongs to. The GID also starts at 1000 and for root user the group number is 0.
  • User Details – usually you’ll find the user’s first name. Sometimes this field can also be left blank.
  • Home Directory- this is the path that a user is in when logging into the server. You can alter this path by chrooting a user’s path.
  • Default Shell- A shell allows for an environment where users interact with the server and the type of shell assigned allows for different usage. The /bin/bash shell allows for text files to run commands.

How to Migrate from Shopify to WooCommerce

Reading Time: 3 minutes

Shopify is a hosted e-commerce platform which can make setting up a store easy for most customers. Unfortunately, Shopify can get expensive when you need to scale up, plus there is a cost per transaction for each order. WooCommerce is an open plugin which can be installed on your existing WordPress site which, along with other plugins, will turn your store into a fully fledged eCommerce store. You can also get a fully-managed WordPress/WooCommerce store with Liquid Web’s Managed WooCommerce Product.

If you did start your store on Shopify, but you now want to migrate to using WooCommerce, you’ll need to export your existing store data, customers, orders and products out from Shopify and then import all of that data into your new WooCommerce store.

Step #1 – Export your Data from Shopify

Shopify does have help posts which cover customers, orders, and products and how you can export those each out to CSV files.

Step #2 – Import Your Data into WooCommerce

Now that you have the store data, how do you get that data imported into your WooCommerce store? WooCommerce does have a native CSV importer for products which can be of use, but it has certain limits. If you have to import a number of CSV files, you’ll need to map each of the fields in the CSV for each part of the product import (like the product title and product SKU, for instance). To import a CSV file, go to WooCommerce > Products and select Import. Choose the CSV file, confirm all of the field mapping, then run the importer.

woocommerce import/export screenshot

Alternative – Use WP All Import

If you’d rather not manually map all of the fields for each import, there is an excellent paid plugin for WordPress which will allow you to import in customers, orders, and products. It’s WP All Import and has add-on plugins for users and WooCommerce. The WooCommerce add-on will allow you to import products, and orders and the user’s add-on will allow you to import in customers. You’ll need to purchase and install the WP All Import plugin to proceed with these directions.

To make the process easier WP All Import allows you to create templates. Since we are importing products in this article, we’ve created a template to map all of the product fields for a product import. To import products using this template, save this template as a TXT file.

Open the plug in and go to All Import > Settings. In the Import/Export Templates section, select the text template file and import it. After the template file has been imported correctly, you will see there is now a template file.

import template screenshot

To import your product CSV export from Shopify in WP All Import go to All Import > New Import.  Select the CSV file and then select New Items and select the  WooCommerce Products type.

continue to step 2

Confirm the number of rows to imported and then continue to Step 3.

number of rows to be imported screenshot

Scroll to the bottom of the page, and select Load Template. Next, select the Shopify product template. This indicates that all fields in the CSV have been mapped correctly to import products into WooCommerce.

Now you can continue and all products which were exported from the Shopify store will be imported into WooCommerce. The images used on the store on Shopify will be imported into the store’s media library during the import, and then mapped into the product. The products will contain the correct data, as well as the featured image.

Customers and orders can also be exported from Shopify as CSV files. Customers can be imported using WP All Import Pro, with the user’s add-on, and orders can be imported using the WP All Import Pro Woocommerce add-on. This only covers retrieving the data from Shopify, then importing into WooCommerce. The theme used on the Shopify store can not be used, but you can replicate the look of the store by using a solid combo of Astra as the theme, then add any specific landing page elements using Beaver Builder page builder.