Fixing WordPress Errors

Posted on by Joel Parks
Category: Common Fixes | Tags: , , , , ,

Let’s face it. At some point, while running your WordPress site, you will run into issues and errors and may ultimately have to ask yourself…

A backup & restore may not resolve your issue, and a plugin may not display itself as the source of your problem, at least, not immediately. It’s hard to tell exactly what is causing your site issues just by looking at it. This can get pretty serious in some cases and can range from a large variety of issues. In this tutorial we will cover the basics on troubleshooting problems with your WordPress installation to try and correct common issues seen with WordPress. The first place you need to look for the source of your problem is within the error log.

 

The most common or likely seen error log used within WordPress investigations does not actually stem from WordPress but rather from your PHP installation on the server. The php.ini file used to control PHP settings for your site will determine if and where the error log is reporting. If this is enabled you can usually find the error log in the directory (or folder) of your WordPress installation. In most cases, this file is titled error_log but is dependent on the setting in the php.ini file. You can also find the WordPress PHP error log (if enabled) within the wp-content folder in a file called php.error_log. If you see neither of these and your site is not loading properly, you need to enable debugging mode or enable PHP logging in your php.ini.

 

You can enable debugging for WordPress within the wp-config.php file. This is essential when trying to determine why a site is no longer loading or is erroring. You may never understand why a site does not load without seeing the errors generated. To better see what is occurring simply edit the following line within your wp-config.php file:

define('WP_DEBUG', false);

And change the false to true:

define('WP_DEBUG', true);

Changing the value to true enables debug mode and will display any errors site code directly on the page. This can be useful when trying to track down site issues or to see if upgrades have created any new issues. If you change PHP versions and the site no longer loads this method  will tell you why. Wp-config.php is also the location where you can enable the WordPress PHP error log and log directly to a file rather than printing to the screen. You can do this by adding the following code to the wp-config file:

define('WP_DEBUG_LOG', true);This code creates the WordPress PHP error log (php.error_log) if errors are present and are being generated. You can find this file within the wp-content folder of your WordPress installation. You may not see this error file if errors are not being generated so the lack of presence, after enabling this setting, may mean no errors are being reported. For instance, if your .htaccess file has a syntax error the php.error_log will not show the error because it is not a PHP related error.

If you would rather enable PHP error logging you can add values to the php.ini for the domain or via .htaccess if your configuration supports them:

Open your site’s php.ini file. If you are unsure where this is located, you can use a phpinfo page to show the location or you can also run the following in command line:

cpUser=`pwd | cut -d/ -f3`; for i in `pwd`; do touch $i/phpinfo.php; chown $cpUser. $i/phpinfo.php ; echo "<?php phpinfo(); ?>" > $i/phpinfo.php; done

Manually create a phpinfo.php file within your sites public_html folder with the following code.

<?php
// Show all information
phpinfo();
?>Afterwards, access this file via a browser at the location you created it. You will find the php.ini path under Loaded Configuration File:

With a PHP info file, you will find the php.ini path under Loaded Configuration File

Once you find this location, edit the file and add the following code if it does not exist:

;;; log php errors
display_startup_errors = false
display_errors = false
html_errors = false
log_errors = true
track_errors = true
error_log = /home/USER/logs/error_log
error_reporting = E_ALL | E_STRICT

You can change the path for error_log to wherever you want this to be stored within your users home directory. The WordPress install is bound to the same access rights as the user installing it so it will not have the permissions to write outside their home directory.

On older setups you can change the logging information via .htaccess if your configuration supports php_flags (using DSO aka as Data Source Object)

# log php errors
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_flag  log_errors on
php_value error_log /home/path/logs/error_logMost likely newer and up-to-date configurations are not using DSO and you will need to modify this via the php.ini file.

 

To understand how to read the output of these logs look at the following entry:

[09-Sep-2018 22:57:20 UTC] PHP Fatal error:  Allowed memory size of 41943040 bytes exhausted (tried to allocate 32768 bytes) in home/USERNAME/public_html/wp-content/plugins/wordpress-seo/inc/class-wpseo-meta.php on line 477

You can see the date and timestamp followed by the general message and path this stems from. This tells you most of the details you will need to determine where the problem lies. You can see from the timestamp of this error when the error is occurring and if that relates to the current issue or if it was a different error. The path will usually show if this stems from a plugin or theme and the location of the software generating the error. This will even display the line in the document or file that triggered the error which can be further reviewed by your sites developer.

 

The “fatal error” is the most common type of error seen and the cause can vary from coding, like “undefined function”, indicate the function and problematic line of code to memory errors (like the one used in the above example). This usually occurs when the server has run out of memory or the PHP memory limit is not set high enough to run the code’s requirements. To fix these errors you may need to update software (themes and plugins usually) as it may be using deprecated code and or functions. You may also need to increase the PHP memory limit or locate any heavy resource usage on the server that may be consuming memory.

This generally means there is an issue with the database in use or the configuration of your WordPress setup. This could mean your database is corrupt or the configuration settings used in your wp-config are not correct or have been modified. Check your wp-config file has the correct credentials and syntax to ensure your database can communicate with your WordPress files. You may also see this error when the server has heavy load or the MySQL service is down. You’ll need to investigate resource usage on the server to determine why.

A standard 404 error means your server could not locate the file being called by the software in use on the domain. This usually occurs when ownership or permissions are incorrect, the file path is called incorrectly or the file is completely missing.

 

WordPress can sometimes run for a while without issue but some common errors can be solved with a little bit of background. As always our helpful support experts are here to assist with any WordPress related errors. Should you need assistance with troubleshooting your WordPress installation and we even offer a Managed WordPress hosting platform with WordPress error experts to investigate many issues.

 

WordPress Exploit – AMP Plugin

Posted on by Echo Diaz
Category: Security Bulletins | Tags: , ,

AMP for WP -Accelerated Mobile Pages allows your site to be faster for mobile visitors. Along with last week’s report, the AMP plugin has also been added to the list exploited. The AMP for WP plugin was reported on October 20, 2018, by its developers. Luckily, the newest version, 0.9.97.20, of this plugin has patched for their known security flaws. This exploit has the means of putting 100,000+ users at potential risk, so its best to check if you are utilizing this plugin. In this tutorial, we will be checking if you use this plugin. Along with updating, we will also show you how to check if your site for compromises.

In the vein of the WP GDPR plugin exploit, the AMP hack allows code vulnerability to make site-wide changes. Bots scan for sites using the AMP plugin and use an XSS security bug to create a new user that has admin-like privileges. The vulnerable versions’ (below 0.9.97.20) code didn’t cross check to see if registered users had the permissions to perform some actions. With administrative like privileges a hacker can hide their code within your WordPress files to use to take over your website. Additionally, they can upload files, update plugins, read files, and inject posts.

Identify If You Use AMP for WP

By logging into your WordPress backend you can easily see if you are subject to this exploit.

Step 1: Enter the WordPress backend by going to yourdomain.com/wp-login.php in your browser.
Step 2: Login with your WordPress username and password and navigate to Plugins and click on Installed Plugins on the left-hand side of your screen.
Step 3: Scroll down through any installed plugins to see if you have Accelerated Mobile Pages within your list, followed by its version. Any version below 0.9.97.20 is still vulnerable and you’ll have to perform a few actions to protect yourself.
The Plugins section in WordPress will allow you to see if you are utilizing AMP.

Upgrade AMP – Accelerated Mobile Pages

Note: It’s recommended to backup your website before pushing any updates.

Step 1: Follow the steps above in the section “Identify If You Use AMP for WP” to login and locate your Plugins menu.

Step 2: Locate Accelerated Mobile Pages. If you are running an outdated version you’ll see a message providing you a link to update. Click “update now” to automatically update to the latest version.

 

In the WordPress backend click the "update now" link to protect yourself from the AMP hack.

Have You Been Hacked?

A site hack is possible even without noticing any visual differences to your site. For a closer inspection below are some of the characteristics of the AMP exploit.

  • Characteristics of the AMP hack:
  • External Calls to sslapis.com
  • New creation of WordPress admin user “supportuuser”
  • Post injections
  • Registered user can manipulate code
  • Code vulnerability in ajax hooks
    • ampforwp_save_steps_data
    • wp_ajax_ampforwp_get_licence_activate_update
    • wp_ajax_ampforwp_deactivate_license
    • wp_ajax_ampforwp_save_installer
    • wp_ajax_amppb_export_layout_data
    • wp_ajax_amppb_save_layout_data
    • wp_ajax_ampforwp_get_image

If have identified your site is compromised from above characteristics, you’ll want to remedy it immediately since other sites on the same server can potentially be affected.

  • Liquid Web customer can purchase a Malware Clean Up package
  • Manually remove the code from the infected files
  • Restore from a backup dated before October 20, 2018 (keep in mind this will still have the old version and your site will still be in danger).

As time goes by, more plugins will give way to more vulnerabilities but there are some proactive steps to ensure your site’s security. For insight into ways of protecting your WordPress site look into our article on the subject, The Best Ways to Protect Your WordPress Site.

 

WordPress GDPR Plugin Exploit – All You Need To Know

Posted on by Echo Diaz | Updated:
Category: Featured Articles, Tutorials | Tags: , , ,

As of November 9, 2018, the WP GDPR Compliance plugin has been exploited by hackers. This plugin aids e-commerce site owners in compliance with European privacy standards. Since the very nature of GDPR is to protect the personal data and privacy of EU citizens, it should be tended to as soon as possible to avoid a costly cleanup. WP GDPR Compliance is also known for working in conjunction with many forms including Contact Form 7, Gravity Forms, and WordPress Comments.

The main characteristic of this hack is the addition of new users, users with admin privileges. These administrative users have full access to your WordPress site. With Admin users a hacker can alter your site without your knowledge, including making rouge pages or selling your visitor’s information.

This article shows WP GDPR users how to:

 

If you are familiar with how to log in to your WordPress backend you can easily see if you are using this plugin.

Step 1: Enter the WordPress backend by going to yourdomain.com/wp-login.php in your browser.

Step 2: Login with your WordPress username and password and navigate to Plugins and click on Installed Plugins on the left-hand side of your screen.

Step 3: Scroll down through any installed plugins to see if WP GDPR Compliance is within your list.  On this screen, you’ll be able to see the version of the plugin to the right of the plugin name. Any version less than 1.4.3 is vulnerable and should be updated.

Indentify if you are vulnerable to WP GDPR by locating the plugins menu in WordPress.

Note:
Documented evidence shows an inactive GDPR plugin is not vulnerable to the exploit.

 

Although this is a severe exploit, it is easy to patch and protect yourself by performing a simple update.

Step 1: Follow the steps above in the section “How to Identify if you use the WP GDPR plugin” to login and locate your Plugins menu.

Step 2: Afterwards, find WP GDPR Compliance, if you are running an outdated version you’ll see a message letting you know you can update. Selecting the “update now” link will automatically upgrade to the newest version.

Update the WP GDPR plugin to avoid a hacked WordPress site.

 

There is a couple of routes for identifying this hack, listed below, but you can also use the Wordfence Security Scanner or our read our blog article on the subject of exploitation.

Indicators of Compromise include the following characteristics:

  • Creation of new users with Admin privileges
  • A database user in the wp-users table named t2trollherten and t3trollherten
  • URL’s inserted into the code have seen as pornmam.com
  • Installation of the 2MB Autocode plugin, executed by WP-Cron via WooCommerce’s woocommerce_plugin_background_installer
  • The wp_options table within your database has an entry starting with 2mb_autocode or default_role  is set to anything other than “subscriber”
  • Recent edits to the wp-super-cache/wp-cache.php file
  • Creation of a backdoor file, /wp-content/uploads/…/wp-upd.php
  • Incoming IPs from:
    • 109.234.39.250
    • 109.234.37.214
    • 195.123.213.91
    • 46.39.65.176

 

If you deduced your site is compromised from previously mentioned characteristics, then you’ll want to remedy it immediately since other sites on the same server can be affected.

  • Liquid Web customer can purchase a Malware Clean Up package
  • Manually remove the code from the infected files
  • Restore from a backup dated before November 8, 2018 (keep in mind this will still have the old version, and your site will still be in danger)

 

Setup a Development Environment for CentOS using cPanel

Posted on by Cameron Paxton
Category: Tutorials | Tags: , , , , , , , ,

Editing a website’s code is often needed to update a site, but doing this to the live website could create downtime and other unwanted effects. Instead, its ideal to create an environment especially for developing new ideas.  In this tutorial, we will explore creating a development site specifically for CentOS servers.

As a warning, this is advanced technical work. It’s possible to make mistakes and cause downtime on your live domain. If you are not 100% confident, it may be a good idea to hire a system admin or developer to copy the domain for you.

Pre-flight

Step 1: Continue on to back up the cPanel account, just in case you have any issues while creating your development environment:

/scripts/pkgacct [username] --backup /home/temp/

Step 2: After creating a backup, you will create a copy the database of the main domain, otherwise known as the primary domain.

mysqldump [database_name] > /home/temp/backup.[database_name].sql

Step 3: Create the new dev domain in WHM. This domain name will be a subdomain of the primary domain. Creating a subdomain is one of the first steps in designing your development environment. We prefer to use, dev.[domain].com, the same domain name but with “dev” in front of it for clarity. Do be sure to note all the information, like the username and password. If you are not familiar with how to create a new account, see the following tutorial.

Step 4: Once you’ve created the subdomain within your cPanel you’ll copy the files from the main document root to the newly created dev document root. The document root is the location where your website’s files.

Use the following command to find the document root for either domain. Replace “exampledomain.com” with the primary and development domains for determining the location of document root for each.

whmapi1 domainuserdata domain=[exampledomain.com] | grep -i documentroot

Step 5: After locating the document roots we will copy the files from the primary domain over to the development environment. Insert the document roots into this next command.

rsync -avh /document/root/of/the/primary/domain/ /document/root/of/the/new/dev/domain

Step 6: Next you will need to state the correct ownership of the dev domain’s files and directories, as the previous username will be in place. The ‘dev_username’ will be the given/chosen when you created the new account. The following command will change the ownership for you.

chown -R [dev_username]: /home/[dev_username]

Step 7: After changing file ownership, create a new database and database user for the dev domain. Be sure to notate this information including the password set. Our documentation on the creating a new database will walk you through this necessary process.

Step 8: Once you’ve created the new database its user, you can start copying the original database into the newly created database.

mysql [new_database_name] < /home/temp/backup.[database_name].sql

Step 9: Copying over the database is the bulk of the work, but you’ll still need to edit the configuration files for your domain. Typically, some files need to access the database and will accomplish this via the database user and password. The file that contains these credentials needs to be updated to have the database, database user, and password you created in step 8 of this tutorial. If unsure of the location of these files talking with a developer may be helpful. If you are working with a WordPress site, you can continue onto the next section. Otherwise, if you have updated your dev configuration files with your new database info continue onto step 10.

Editing WordPress Configurations
Fortunately, WordPress is one of the most commonly used content management systems. WordPress is easy to configure we’ll provide a short tutorial on how to change the database and database user in the wp-config.php. First, move to the new document root. cd /document/root/to/the/dev/domain

There you will edit the wp-config.php with your favorite text editor such as vim or nano. nano wp-config.php

In the wp-config.php file, you will see a section that looks like the below. From there you will edit the highlighted characters with the information you used to create the database in the tutorial. // ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'new_database_name');
/** MySQL database username */
define('DB_USER', ‘new_database_user');
/** MySQL database password */
define('DB_PASSWORD', 'password');

In the database, clear all mentions of the original domain and replace them with the dev domain. For example with WordPress, in the _options table you need to change two entries of ‘home’ and ‘siteurl’. These can be quickly changed using WP-ClI, which is a is a command line tool for interacting with and managing WordPress sites. To install WP-CLI follow these instructions and continue onto the next step. If you do have a WordPress website, once you have installed WP-CLI you will want to run the following commands: su - [dev_username] cp public_html
wp option update siteurl https://dev.domain.com
wp option update home https://dev.domain.com
exit

Sometimes plugins or themes mention the original domain in the database. If some parts of the dev domain are not working, particularly plugins or themes, you may need to contact a developer to see if the original domain name is still active in the database. After replacing the names using WP-CLI, you’ll have officially created a dev domain.

Step 10: To complete this tutorial you have two choices: add an A record to your DNS view your dev site online or edit your local hosts file to view solely on your computer. For our Liquid Web customers feel free to contact The Most Helpful Humans™ with questions you may have in setting up a development environment.

 

 

Setup a Development Environment in Ubuntu

Posted on by Cameron Paxton | Updated:
Category: Tutorials | Tags: , , , , , , , , ,

Often we want to edit our domain’s code, but on a production website, this can be dangerous. Making changes to the production site would not only allow all of the Internet to see unfinished changes but could also cause errors to display. As a workaround, we’ll create a testing domain or “dev” domain to work out any bugs and changes to the site.

As a warning, this is advanced technical work. It’s possible to make mistakes and cause downtime on your live domain. If you are not 100% confident, it may be a good idea to hire a system admin or developer to copy the domain for you.

Pre-flight

Step 1: After logging in as root, back up the domain using the command below to save a compressed version. It’s essential to have a copy of your site just in case you run into any issues. Replace the brackets and the “domainname” with your site’s name.

tar cfv backup.[domainname].tar /document/root/of/the/domain/

 

Step 2: We will be moving our backup file, .tar, somewhere off that document root, This way we can still access the data while keeping it safe.

mv backup.[domainname].tar /another/location/on/the/server

 

Step 3: The tar command created a file that comprises only half of the site, which holds the files. Next, you will want to copy the database for the primary site.

mysqldump [database_name] > /another/location/on/the/server/backup.[database_name].sql

 

Step 4: Create the new dev account, just like you were adding a new domain to your server. However, you will be creating a subdomain which you can name as dev.[domain].com.

 

Step 5: Once you’ve created the dev subdomain, copy the files from the main document root to the newly created dev document root. The document root is the location of the files housing your domain, also known as the “path”.

To find the document root location, for either domain, run the following command. Find the document root by replacing “exampledomain.com” for each both the live and dev domain.

conf=$(apache2ctl -S | grep exampledomain.com | perl -n -e '/\((\/.*)\:/ && print "$1\n"'); grep -i documentroot $conf

 

Step 6: After you have found the document roots for both the domain and dev domain, you will need to copy the files. With the output of the last command, you’ll insert the path for the document roots.

rsync -avh /document/root/of/the/domain/ /document/root/of/the/new/dev/domain

 

Step 7: Give the correct ownership to the dev domain, as the previous username remains in place. The ‘dev_username’ is a default user, one generated by creating the new account. The following command will change the ownership for you.

chown -R [dev_username]: /document/root/of/the/new/domain

 

Step 8: After you have done this you will need to create a new database and database user for the dev domain, be sure to keep all this information including the password you set. First, enter the mysql command prompt by running the command:

mysql

Next, create the database itself.

CREATE DATABASE [new_database_name];

In our next command, we create the user and their password. Be sure this is a unique username, unused up till now.

CREATE USER '[select_new_username]'@'localhost' IDENTIFIED BY '[password]';

 

Step 9: Grant privileges for the user on the database.

GRANT ALL PRIVILEGES ON [new_database_name] TO '[new_username]'@'localhost' WITH GRANT OPTION;

Then exit out of mysql by typing “quit” and hitting enter:

quit

 

Step 10: Once back at the root command prompt, you can start copying the original database into the new database.

mysqldump [new_database_name] < /home/temp/backup.[database_name].sql

With the database dumped you will still need to edit the configuration files for your domain. Typically, there are files which need to access the database and will reference the database, database user, and password. These credentials need updating to the ones created earlier in step 8 of this tutorial. If you are unsure of where these files contact a developer. If you are working with a WordPress site continue on to the next section.  Otherwise, if you have updated your dev configuration files with your new database info continue onto step 11.

Editing WordPress Configurations

Fortunately, WordPress is one of the most commonly used content management systems. WordPress is easy to configure we’ll provide a short tutorial on how to change the database and database user in the wp-config.php. First, move to the new document root.

cd /document/root/to/the/dev/domain

There you will edit the wp-config.php with your favorite text editor such as vim or nano.

nano wp-config.php

In the wp-config.php file, you will see a section that looks like the below. From there you will edit the highlighted characters with the information you used to create the database in the tutorial.

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'new_database_name');
/** MySQL database username */
define('DB_USER', ‘new_database_user');
/** MySQL database password */
define('DB_PASSWORD', 'password');

In the database, clear all mentions of the original domain and replace them with the dev domain. For example with WordPress, in the _options table you need to change two entries of ‘home’ and ‘siteurl’. These can be quickly changed using WP-ClI, which is a is a command line tool for interacting with and managing WordPress sites.  To install WP-CLI follow these instructions and continue onto the next step.

If you do have a WordPress website, once you have installed WP-CLI you will want to run the following commands:

su - [dev_username] cp public_html
wp option update siteurl https://dev.domain.com
wp option update home https://dev.domain.com
exit

Sometimes plugins or themes mention the original domain in the database. If some parts of the dev domain are not working, particularly plugins or themes, you may need to contact a developer to see if the original domain name is still active in the database.

After replacing the names using WP-CLI, you’ll have officially created a dev domain.

Step 11: To complete this tutorial you have two choices: add an A record to your DNS to view your dev site online or edit your local hosts file to view solely on your computer. For our Liquid Web customers feel free to contact The Most Helpful Humans™ with questions you may have in setting up a development environment.

Migration to Managed WooCommerce

Posted on by Echo Diaz
Category: Getting Started, Managed WooCommerce Hosting | Tags: , , , , , , ,

Liquid Web is here to support your migration needs into our Managed WooCommerce Hosting platform. Whether you are migrating from an external or internal source, our in-house team of migration experts transforms the data migration process into a simple task. To ensure the smoothest and best possible data transfer, we have a quick overview and a few points for your consideration.

 

Our first step includes taking a copy of your live site (known as the origin site) and migrating it over to our Managed WooCommerce Hosting platform. Rest assured, when performing the migration, the only changes made to the site will be to assist in the movement. Within this timeframe, it is advised to avoid making changes or updates to the site as it will extend the migration timeline and could result in data loss. Changes and updates are included but not limited to themes, designs, contents, products, blog posts or WordPress versions. The initial sync process should result in no downtime for your live site.

Once the initial sync is complete, our Migration Specialists perform a series of basic tests to the site. During this time, our team will send information on ways to test out your new site to ensure that all aspects have carried over correctly and are in working order. Before going live, it is essential to take the time to thoroughly review your site and if at any point you do find a discrepancy our specialist is there to assist.

The third and most exciting step is the push to go live. We will coordinate the best date and time for the final sync of your site. This last sync will ensure the latest data on orders, products, and customers transfers to your new server. Upon completion of the final sync, you will be asked to update the staging domain’s name and DNS record. With a little DNS propagation time, you will begin to see the new site populate!

With the updating of DNS and the site name, you are now entirely done with the migration process. In subsequent steps, we will create a ticket with our Product Team to connect your store to our partnered applications, Glew and Jilt. Credentials to these valued applications will be sent out in an email, after which, our product team can suggest performance optimization methods to get the most out of your eCommerce store.

 

Knowing the details behind the migration process aligns us with our next step in creating a migration request from your Liquid Web control panel! Once completed, our Migration Specialists will be in touch to schedule the migration and answer any questions you may have.

 

Create a Robots.txt File

Posted on by Echo Diaz
Category: Common Fixes | Tags: , , , , ,

A web robot’s primary job is to scan websites and pages for information; they work tirelessly to collect data on behalf of search engines and other applications. For some, there is good reason to keep pages away from search engines.  Whether you want to fine-tune access to your site or want to work on a development site without showing up Google results, once implemented the robots.txt file lets web crawlers know which parts they can collect information.

Create a Robots.txt File

As being one of the first aspects analyzed by crawlers, the robots.txt file can be implemented on a page(s) or an entire site to discourage search engines from showing details about your site. Through this article, we will be providing insight into how to use the robots.txt file as well as syntax needed to keep these bots at bay.

User-agent: *
Disallow: /

 

Let’s break down the code below “user-agent” pertains to the web crawlers and the * sign means all web crawlers. Consequently, the first line grabs attention by saying “Listen up all web crawlers!” We move onto our second line which lets the web crawler know its direction. The forward slash (/) stops the bots from searching all the pages on your site. You can also discourage information collected for one specific page, in this case, it is a map of our building layout. Since the design of our building does not need to searchable, with the command below, I can tell all bots to leave out the index of the buildinglayout.png photo, while keeping it viewable to any guest that want to view.

User-agent: *
Disallow: /buildinglayout.png

 

Contrary, if you would like for all search engines to collect information on all the pages in your site you can leave the Disallow section blank.

User-agent: *
Disallow:

 

There are many types of web crawlers (aka user-agents) that can be specified. Below is a chart of the most popular web crawlers followed by as their associations. Furthermore, you can also instruct these bots to index a certain page by using Allow, as shown in the example below. You can implement these web crawlers within your robots.txt file like so:

User-agent:Googlebot
Allow: /parkinglotmap.png
Disallow: /buildinglayout.png

User-agent and their Association
Mostly, sites don’t automatically come with a robots.txt file (and isn’t required) so you can create one using a text editor and upload the file to your root directory or any other directory.  Luckily, if you use the popular CMS, WordPress and its helpful SEO plugin Yoast, you’ll see a section within the admin window to create a robots.txt file.

Robots.txt File In WordPress

Yoeast SEO Tool Section

 

After logging into your WordPress backend (yourdomain.com/wp-login.php) locate the SEO section and select Tools. After clicking on the file editor link, you see a page that looks similar to the code used in the first of our article.

Wordpress Robots.txt File

 

Our example keeps web bots from WordPress login page, including wp-includes directory while still allowing users and bots to see other pages of our site. Take note of the necessary ending slashes after the directory (but not needed when disallowing pages). After editing select the “save changes to robots.txt” button to activate the robots.txt file.

 

 

The Best Ways to Secure WordPress

Posted on by Jennifer Walsh | Updated:
Category: Managed WordPress | Tags: , , , , ,

On our Managed WordPress hosting platform, we strive to ensure security with regularly scheduled patches and updates. By utilizing our intrusion prevention software, we mitigate malicious activity and block repeated failed logins for your WordPress admin portal. Furthermore, our web-application firewall, restricts unneeded ports along with custom rules to help protect you on the application level. We take care of the administration work so you can spend more time securing your site. Below our Managed WordPress admins share tested (and trusted) implementations to keep your site locked up tight.

WordPress Security Plugins

iThemes Security

The iThemes Security plugin is a fantastic addition to enhance your security, and it is easy to install.  By adding an extra layer of protection, below is a list of security features that iThemes Security Pro provides.

Click To See iThemes Security Features
    • Banned Users – Allows you to completely ban hosts and user agents from your site
    • Network Brute Force Protection – Banning users who have tried to break into other sites from breaking into yours. The network protection will automatically report the IP addresses of failed login attempts to iThemes
    • SSL – This feature redirects all http traffic to https
    • Strong Password Enforcement – Force users to use strong passwords as rated by the WordPress password meter
    • System Tweaks:
      • Disable Directory Browsing
      • Filter Suspicious Query Strings in the URL
      • Remove File Writing Permissions – Prevents scripts and users from being able to write to the wp-config.php file and .htaccess file
      • Disable PHP in Uploads – Disable PHP execution in the uploads directory. This blocks requests to maliciously uploaded PHP files in the uploads directory.
      • Disable PHP in Plugins – Disable PHP execution in the plugins directory. This blocks requests to PHP files inside plugin directories that can be exploited directly.
    • Change WordPress Salts – Use WordPress Salts to encrypt any passwords saved within WordPress, this adds an extra layer in password protection. Check this box and then save settings to change your WordPress Salts.

Salt Encryption Settings

  • WordPress Tweaks:
    • Comment Spam– Reduce Comment Spam
    • XML– RPC feature allows external services to access and modify content on the site. Common example of services that make use of XML-RPC are the Jetpack plugin, the WordPress mobile app, and pingbacks. If the site does not use a service that requires XML-RPC, select the “Disable XML-RPC” setting as “disabling XML-RPC” which prevents attackers from using the feature to attack the site. Disable Pingbacks – This feature only disables pingbacks. Other XML-RPC features will work as normal. Select this setting if you require features such as Jetpack or the WordPress Mobile app.
    • Block XML– RPC requests that contain multiple login attempts.
    • Restricted Access– Restrict access to most REST API data. This means that most requests will require a logged in user or a user with specific privileges, blocking public requests for potentially private data.
    • Force Unique Nickname– This forces users to choose a unique nickname when updating their profile or creating a new account which prevents bots and attackers from easily harvesting user’s login usernames from the code on author pages. Note this does not automatically update existing users; it will affect author feed urls if used.
    • Protect Against Tabnapping– Alter target=”_blank” links to protect against tabnapping. Enabling this feature helps protect visitors to this site (including logged in users) from phishing attacks launched by a linked site.
    • Login with Email Address or Username– By default, WordPress allows users to log in using either an email address or username. This setting allows you to restrict logins to only accept email addresses or usernames.

To install, login to your WordPress dashboard, click on “Plugins” on the left. Click on “Add New” and use the search box to find “iThemes Security (formerly Better WP Security)”. Click on “Install Now”, and then activate the plugin.  On the left bar, click on “Security” and iThemes will start a security check on your site.  Additionally, you can click on Security > Settings on the left to enable any security features that fit your website.

WordFence

Wordfence Security – Firewall & Malware Scan plugin – Wordfence includes an endpoint firewall and malware scanner.  One of the key features is their threat defense feed arms that are supplied with the newest firewall rules, malware signatures and malicious IP addresses to keep your website safe.  Click on the Wordfence subtitle to jump to installation and setup instructions.

CloudFlare

You can create an account with CloudFlare to help protect your websites from various attacks including DDoS mitigation, customer Cloudflare helps mitigate DDoS attacks, prevent customer data breaches, and block malicious bot abuse. Cloudflare DNS is DDoS protection for domain resolution. It sits behind the same 15 Tbps network that protects over 7 million Internet properties from denial-of-service attacks.  Cloudflare DNS also comes with built-in load-balancing, automatic failover, rate-limiting, and filtering. Cloudflare also offers DNSSEC to add a layer of trust on top of DNS by providing authentication.

Web Application Firewall (WAF)

Web application firewall (WAF) rulesets – Available on all of Cloudflare’s paid plans, the WAF has built-in rulesets, including rules that mitigate WordPress specific threats and vulnerabilities. Additional features: automatic cache purge, and header rewrite to prevent a redirect loop when Cloudflare’s Universal SSL is enabled.  You can change Cloudflare’s settings from within the plugin itself without needing to navigate to the cloudflare.com dashboard. The available settings to change are: cache purge, security level, Always Online, and image optimization.

Sucuri

As an auditing, malware scanner, and security hardening plugin, it’s a security suite that works well with your existing website’s  security. This plugin offers a great set of security features such as Security Activity Auditing, File Integrity Monitoring, Remote Malware Scanning, Blacklist Monitoring, Effective Security Hardening, Post-Hack Security Actions, Security Notifications, and Website Firewall (premium).

General Security Recommendations

We are living in an age where security needs to be updated at all times. Passwords is one of those crucial security mechanisms that needs to be updated at least every 30 to 60 days. The recommendation for each password complexity is to be at least 15 characters containing a combination of uppercase letters, lowercase letters, numbers, and symbols. The passwords should not contain dictionary words, usernames, personal information, or letter sequences. The passwords should not be reused in a given year.

Along with having secured passwords, your computer should also be protected.  Attackers can exploit computers that have outdated operating systems using worms, malware, Trojans, and viruses. You will need to make sure your computer has the latest security patches and fixes.  All browsers should be the latest versions. Do not install any software or browser plugins from any untrusted parties.  Install reputable anti-virus software and conduct regularly malware scans on your computer.

The most common source for malicious injections are vulnerabilities in CMS software, plugins, themes and other commonly used third party code. We recommend taking measures to update all CMS software, plugins and themes used to the latest versions available from their respective vendors. This would help limit the chance of future infections occurring.

Registering your website with Google Webmaster Tools will tell you the health of your website. Change the Default “admin” username.  Since usernames make up half of login credentials, having the username “admin” made it easier for hackers to do brute-force attacks.

Final Thoughts

Being at the top of your game on security is worthwhile to avoid paying expensive fees to clean up a hacked site, especially since there are many free security options at your disposal. Take a stroll through our Managed WordPress product page and discover how we can take the guesswork out of security. Along with a 24/7 support team at your fingertips, our Managed WordPress platform automatically updates plugins to reduce your site’s vulnerability to malware.

Redirect to HTTPS

Posted on by Jerry Vasquez | Updated:
Category: Common Fixes | Tags: , , , , , ,

Google just announced that starting July 2018 Chrome, their very popular web browser, will start alerting for all websites which are not using Secure Sockets Layer, or SSL encryption. This is huge. The ramifications of such an alert could be quite impactful to traffic, to websites, and especially for the average user. So, what does that mean for you? More importantly, what can you do about it? No worries! Liquid Web has you covered.

In today’s post, we’ll be detailing some of the finer points of SSL encryption including what it is, what it means, and how to employ it. Let’s get started!

What is Secure Sockets Layer (SSL)?

Secure Sockets Layer, or SSL, is a means to encrypt traffic. That’s it! They’re no mystery, and there’s no reason to feel daunted by the technical term. The best part is that you’ve probably been making use of SSL encrypted traffic forever and haven’t even noticed it. If you’ve ever browsed to a website and noticed the prefix https:// or a little padlock in the browser bar, you’re using Secure Sockets Layer encryption.

Unencrypted: non-SSL

Insecure Site
Encrypted: Secure SSL
Secure Site

At a very high level, it’s referred to as a key-cert pair, and it’s super easy. The key file and certificate files are installed on your web server. Once installed your visitors browse to the https:// prefix and that’s it! Their traffic is encrypted end to end. If you’re unsure whether or not you’re currently using an SSL, there are some handy tools like  Why No Padock that can help identify your usage.

How does SSL work?

The more technical portions revolve around an encryption algorithm and are a little specific for the average user. At its base, an encryption key and certificate are installed on your web server, as we mentioned earlier. This key is comprised of details about the website. Nothing scary, though! It’s just enough to ensure the site is who it claims to be. Details such as the domain name, the company’s name, the company’s business address; that kind of thing. You know, aspects you’d like to know about a legitimate company with whom you’re choosing to do business and, as a business owner, are proud to announce to the public.

Finally, that information is submitted to a known certificate authority who’ll encrypt the data into the key-cert pair we talked about already. You’ll install the key-cert pair on your server. Then, whenever someone tries to access https on your site, their browser will receive that public cert and compare it to public records for your domain. The browser will verify that your business is legitimate, –because it is!– and will use that certificate to encrypt all the data that’s passed between them and your web server.

This means, whenever there is data moving between them and you, if any bad guys try to inspect or steal it, all they’ll get is a bunch of garbled junk. Your data and your clients’ data are both safe and secure!

Liquid Web has a detailed step by step instruction on server setup at our Knowledge Base. Once you have an SSL installed on your site, your clients still have two means by which to connect to your site. The HTTP method, which is unencrypted, and the HTTPS method, which is encrypted by your new SSL. The choice is usually denoted by how your clients or your referral traffic structures their link.

Redirecting to HTTPS

Note
This process assumes you’ve already installed an SSL on your site.

The process is referred to as “Forcing SSL Redirection.” Ultimately, you’ll use code to make sure, whenever someone goes to HTTP, their traffic is directed over to HTTPS. Click on the tabs below to learn how the different ways to implement SSL onto your site.

cPanelWordpress.htaccessPlesk
If you’re using cPanel, you’ll need to access your cPanel account and navigate to the “Redirects” menu from the “Domains” group.

You’ll notice the Wild Card Redirect check box. This is a unique function that forces all links to HTTPS, not just the primary domain. I’m very much a fan of this option as it ensures all links will be directed to the SSL secured version which has you covered if someone links to a specific page of your site and not the home page.

Click “ADD” and you’re done!

No need to use cPanel, Plesk or the command line with the very popular Content Management Software, WordPress! Editing can be done straight from the WordPress Admin interface. Log into your WordPress Admin interface navigate to the Settings menu. From there you can simply set your WordPress and Site Address to use the https:// prefix, like so:

Wordpress Admin Section in Settings

Easy Peasy! One last test to make sure you’re using your SSL will show that you are! You could use an SSL checker like SSLShopper, or clear your cache on your browser and reload! See our article on how to clear your browser cache if you are having trouble.

You should be able to see the little green padlock in the browser bar that gives your clients that warm, fuzzy feeling. Even better, the upcoming alert from Google Chrome about unencrypted traffic is no longer a worry.

More advanced users who aren’t using a control panel can use some simple rules in their .htaccess file.

From the command line, navigate to the document root of your domain and use your favorite editor to open or create your .htaccess file. Then add the following lines:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Here’s an output of mine:

Example of Redirection Code

The method is very similar for Plesk: Log into your Plesk interface and navigate to the “Hosting Settings” for your domain:

Locating Hosting Settings in Plesk

From the Security subheading of the Hosting Settings, check the SSL/TLS support and Permanent 301 redirect checkboxes. Also, make sure you select the correct certificate. Lastly, click the “Apply” button and you’re done!

Redirection Settings Within Plesk

Mixed Content (Insecure Content)

There is one last part. SSLs are installed on your server. So they can only encrypt and protect objects that are on your server. This means, if you happen to be linking to off-server content, like Facebook posts, YouTube links, or images or other content from some else’s sites, you have to make sure they’re using an SSL too. If they’re not, you’re technically hosting insecure content on that page and Chrome will alert your clients as such (characterized by having https but not the green lock). If you’re unsure about the content on your site, you can use a site like Why No Padlock to check. It’ll give you a nice readout and will list any issues with unencrypted content under the “Mixed Content” heading in the report.

Luckily, big names like YouTube and Facebook are already on board and use SSLs. But there are still a lot of sites on the internet who do not. It’s up to you to help the internet’s security and be diligent in our pursuit to be good net-citizens together.

You’re now familiar with SSLs, Forced SSL Redirection and the upcoming Google Chrome alert. As always, if ever you need help or have issues, our Knowledge Base is here for you to peruse and our Helpful Support Humans are happy to help.

 

Configuring NGINX for Managed WordPress

Posted on by Libby White | Updated:
Category: Featured Articles, Managed WordPress | Tags: ,

Running a WordPress site can be incredibly simple and used right out of the box, but you may need to customize or add specific files in order to get the most out of your site. Our Managed WordPress customers can include custom NGINX configurations for individual sites because we know that adding simple redirects or adjusting browser cache settings are actions that many of our Managed WordPress users do on a regular basis. Read on to learn how you can use this functionality for your own site.

On the Managed WordPress platform, custom configuration files are read from the NGINX folder within the site’s home directory. Any file ending with .conf will be read into NGINX on reload or restart, so a file called ~/nginx/user.conf.sample is provided as a placeholder.

While you can create and edit these files, it is necessary that you reach out to our Managed WordPress Support team to reload the NGINX configuration. This will allow us to test the file configuration and confirm that there are no errors or warnings. Because your site performance and uptime is important, the Managed WordPress support team will manually review files to check for potentially irregular and harmful configurations.

Although the primary use of this feature is for configuring redirects at the NGINX level. you may also set custom browser cache expiration times for static files. Any configurations beyond those described below are considered beyond scope support.

An example of simple redirects:

# Simple redirect to an individual page
location /example-redirect-123 {
add_header X-Redirect-By "Yoast SEO Premium";
return 301 /example-redirect;
}

# Rewrite all urls under an old path to a new path
location /category/old-category {
rewrite ^/category/old-category/(.*)$ /category/new-category/$1 permanent;
}

An example of adjusting browser cache settings:

# Reduces js and css cache times to a single day instead of the MWP default of 1 year.
location ~* \.(?:css|js)$ {
expires 24h;
access_log off;
add_header Cache-Control "public";
}

If you are looking to block access to a specific directory, you can complete this request by using the following command:

rewrite ^/wp-content/private_directory/(.*) /last;

Where “private_directory” is the directory you wish to block access to.

Configuring NGINX

  1. Log into the site via SSH.:ssh/sftp credential section in Managed WordPress portal highlighted
  2. Navigate to the NGINX directory located in the home directory.
    s150@default:~$ pwd
    /home/s150
    s150@default:~$ cd nginx
    s150@default:~ngingx$ ls
    user.conf.sample
    s150@default:~/nginx$
  3. Next, create a file ending in .conf:
    s150@default:~/nginx$ touch redirects.conf
    s150@default:~ngingx$ ls
    redirects.conf user.conf.sample
    s150@default:~/nginx$

    In this example, we are using redirects.conf, but you can name it anything you’d like, just make sure you remember the file name.
  4. Then modify the file with the configuration changes:
    s150@default:~/nginx$ vi redirects.conf
    s150@default:~ngingx$ cat redirects.conf
    # Limited to directives valid in the server block context
    # All files ending in '.conf' in this directory will be loaded
    # Please contact support to have them reload the nginx config files
    # for changes to go into effect.# Configure redirects
    #
    loacation /example-redirect-123 {
    add_header X-Redirect-By "Yoast SEO Premium";
    return 301 /example-redirect;
    }
    s150@default:~/nginx$
  5. Lastly, contact support to request review and reload of the config. You can easily reach our Managed WordPress support team by opening a chat or ticket through your Managed WordPress portal, or by calling our team at 1(833)845-4527 or 1(517)322-0434.