Top Nav

Archive | Web

Content Updates With W3 Total Cache & RackSpace Cloud Files

We get frequent questions from WordPress clients with W3 Total Cache (W3TC) and RackSpace Cloud Files (RCF) content distribution network (CDN) about how to make changes to the website visible.

First some general notes:

  1. Content changes or updates to pages or posts do not involve the CDN so no special actions are required. W3TC will automatically flush old pages and post revisions from it’s caches.
  2. Media files uploaded through WordPress admin will be automatically uploaded to the CDN and can be immediately used in post or pages with no additional action.
  3. Files that are changed via FTP will required additional action. This included media files, CSS and Javascript as discussed below.

As an example, let’s assume that you’ve modified you themes primary stylesheet at:

wp-content/themes/mytheme/style.css

You made the modification by downloading the file, editing on your workstation and then uploading via SFTP back to the server. In this case W3TC has no way of knowing that you’ve made a change to the file so it does not know that the file needs to be uploaded to the CDN.

First you’ll need to sync or upload the file to the CDN:

  1. Login to WordPress admin.
  2. Go to Performance -> CDN
  3. Click the appropriate upload button in the General section. The button will depend on what type of file you’ve changed. In this example we need to click the “Upload theme files” button. W3TC_CDN_General
  4. A popup window will open when you click the button similar to this: W3TC_CDN_UploadIn the popup window, click the “Start” button. The sync process will start and you’ll be able to see as each file is examined. If the file has not changed since the last sync the it will be marked “Object up-to-date”. If the file is now or has changed then it will be marked with “Ok”. W3TC_CDN_Upload2
  5. After the sync process completes you can close the popup window. If you have many files it may take several minutes to several hours to fully sync.

Now the new or changed file has been uploaded to the CDN. If it’s a new file then it will be immediately available for use in your site.  If instead you are changing a file then we have to take an additional step and “purge” the file from the CDN.

CDN’s function by distribution content to access points close to the user. For large CDN’s there might be dozens or even hundreds of access points. When a user requests a file, the request is routed to the closest access point. The CDN infrequently check back with your web server for changed or updated files. The frequency of these checks is call the “Time to Live” or TTL. By default RCF sets a 24 hour TTL on all files. So after uploading a change, it may take up to 24 hours before the change if visible on on access points. This can be a problem for our CSS change as users on different access point might get different versions of the file.

W3TC includes a “purge” feature which you can use as follows:

  1. Login to WordPress admin
  2. Go to Performance -> CDN
  3. Look for the Purge button above the General section. Click the Purge button to open the CDN Purge Tool popup window. W3TC_CDN_Purge1
  4. Enter the relative paths of each file that you want to purge into the “Files to purge” field.
  5. Click the Purge button and wait for the process to complete.W3TC_CDN_Purge2
  6. Close the CDN Purge Tool window.

Purging on the CDN is not an instantaneous process. I may take up to about a half hour for all access point to receive and honor the purge request but this is still much faster then the 24 hour TTL.

We have had mixed success with the W3TC CDN Purge Tool. If I need a change purged as fast as possible then I prefer to run the purge from the RackSpace Cloud Files control panel as follows:

  1. Login to https://mycloud.rackspace.com
  2. Go to Storage -> Files
  3. Drill down on your container and then to the file that you want to purge.
  4. Click on the Gear icon next to the file to open the drop down menu. RSCF_Purge1
  5. Select “Refresh File (Purge)” from the menu. A small confirmation dialog will open. RSCF_Purge2
  6. Click “Purge File” button in the dialog to complete the process.

Again purging on the CDN is not an instantaneous process. I may take up to about a half hour for all access point to receive and honor the purge request.

Is there anyway to make updates to the CDN faster?

Short answer is “no”. The TTL and propagation delay is the nature of the CDN. Generally the benefits of distributing content win out over the update delays.

But two notes:

  1. New files do not experience any propagation delay. If you want to change a file and have it propagate instantly then change the name of the file so it is seen as a new file by the CDN.
  2. You can lower the TTL of the CDN container. If you have a big setup of updates planned, then it might be a good idea to lower the TTL a few days in advance so that you minimize propagation delay.

 

 

0

Upgrade CURL

The Yoast SEO plugin in WordPress has started advising users to upgrade curl to the latest version. On CentoOS this can be done easily using the city-fan.org repo here:

http://www.city-fan.org/ftp/contrib/yum-repo/

For a CentOS 6 server, here are the steps:

 

 

0

404 On sitemap_index.xml With Yoast SEO After Site Migration

After moving and renaming a site, we were getting 404 errors for the sitemap generated by Yoast SEO at:

http://acme.com/sitemap_index.xml

After digging around it turned out the solution was to reset permalinks by going to:

Settings -> Permalinks

and clicking the Save button without making any changes.

0

Changing Magento Path

Suppose you have a Magento Commerce store at:

http://acme.com/store

but you want to change the URL to:

http://acme.com/catalog

There are plenty of articles that give the basics like:

https://docs.nexcess.net/article/how-to-change-magento-base-urls.html

Basically the steps are:

1. Login to admin, go to Configuration -> Web and change the secure and insecure urls.

2. Move the store/ folder to catalog/

3. Clear cache and sessions folders with

4. Add a rewrite rule in your .htaccess to send traffic from the old path to the new path:

So far so good but we found several additional steps that might be needed. If compilation is turned on then you may need to do:

Next if you have APC installed in PHP then you may need to restart the web server to clear the APC cache with something like:

If you have memcached configured as the cache backend then you’ll also need to restart memcached:

Let us know if the comments if you find any other steps that are needed to successfully move magento to a new path.

 

 

0

How-to Mitigate Bittorrent DDOS Attacks

You’ll know that you’re getting hit with a Bittorrent attack when the server slows down and you see log entries referencing:

Here’s a good article about one sysadmin’s struggle with this type of attack:

http://blog.carlesmateo.com/2015/01/23/stopping-a-bittorrent-ddos-attack/

There are a number of possible strategies to mitigate this attack:

1. CloudFlare will block but it can take time to move DNS to CloudFlare and activate.

2. Create an announce.php file that returns an error like this:

This will use fewer resources then letting WordPress or other CMS return a 404.

3. Block in iptables with a rule like this:

Not sure how efficient this is on a high traffic web server.

4. Block in Apache config:

5. Block with fail2ban as described here:

http://shazbert.com/blog/2015/01/24/fail2ban-china-ddos-announce-bittorent/

Note that Plesk 12 has fail2ban built-in so this fix is easy to implement.

6. If traffic is limited to a range of IP addresses then block that range in any available firewall. For example we’ve defeated this attack in one case by blocking a class B range from China.

Other suggestions on blocking this type of attack are welcomed. Comment below and let us know if you’ve seen this attack and how you handled it.

0