Thanks for using W3 Total Cache! Our journey to enable great user experiences in WordPress continues with today’s release. As will any minor release, the focus has been on improved security and interoperability / compatibility. With this release we’ve added two security fixes to ensure that your hosting environment is more secure, improved reliability of the plugin itself, and increased the responses of the WordPress administration panel.
As always thanks to all of our supporters, including those who are active in the forums helping end users.
Thanks to everyone that provided bug reports and helped to troubleshoot issues in the forums for other users. As the changelog will show, many of the most glaring issues have been resolved, which hopefully will reveal the next set of high priority concerns users are facing. I hope everyone tests out this release in a staging environment or sandbox before moving to a production environment.
A word to those who’s support of the project takes the form of code:
Looking forward, we’ll be re-visiting our plans for making the github repository public, making our tests available and sharing the roadmap for those who are interested in helping us accelerate it.
Thanks for your support and for using W3 Total Cache!
As always, security is very important to us. A few folks from the community came forward and called those issues to our attention and helped us test those fixes. Specifically, SecuPress team for testing the various security fixes: Security Token ByPass, Arbitrary File Upload, Arbitrary File Download, Arbitrary PHP Eval and the XSS vector. Thanks to those that continue to be supportive in their efforts and kind words.
This release has some cosmetic bugs in the latest version of WordPress, but our test suite shows that core functionality is working as intended. Having said that, I’m sure there are other bugs and bumps in the upgrade process – we’d love to learn about those, so we can push a follow-up release. Thanks in advance for reporting any issues you find. Hopefully, you find them in a staging area and not in your production site.
There are a couple of highlights for this build aside from the security fixes including new functionality for Pro subscribers, new caching engines, new extensions, new integrations and increased interoperability. Please check out the changelog for specifics.
We recently noticed an increase in the number of customers experiencing activation issues with W3 Total Cache Pro. For those of you who don’t know, this is how it works:
Once you upgrade from the Community (free) version of W3 Total Cache to the Pro version ($99/yr subscription), you’re assigned a license key that in most cases is automatically applied. In the event that activation isn’t automatic, you simply need to paste the license key (which is sent via email and displayed in your browser at the time of purchase) in the License field on the General Settings page and save settings.
A number of customers were unsuccessful in getting the Pro version activated despite following the steps above, and our investigation has revealed that a patch is required in order to complete the activation process if you’re among those affected.
Two things before I reveal the patch:
We’re happy to implement this patch for you! Just email us at email@example.com and let us know that you need help. We’ll provide you with a secure link so you can send us WP Admin and filesystem (SSH or FTP) access. Note that both required to implement and verify the patch, so please be sure you have both ready.
This patch will be in the next release, so most people won’t have to worry about it. We don’t have an ETA we can give you for this release, but it will be available “soon” (smile).
Without further ado.
On line 117 of
/w3-total-cache/lib/W3/Licensing.php, the following line:
APC is an opcode cache used by many sites to improve application performance. PHP is an interpreted language, and the scripts (such as the ones that comprise your WordPress site) are loaded, parsed, compiled into an opcode, and executed when called. This process can use an inordinate amount of resources on a busy site, especially one without caching, so we need to do what we can to optimize this process.
While installing APC on a dedicated server or VPS is a straightforward process, this post (the first in a series of Web Performance Optimization (WPO) posts for GoDaddy) outlines how to enable it on your GoDaddy shared web hosting account:
Log into your GoDaddy account and navigate to your hosting dashboard
Go to Tools > FTP File Manager
php5.ini file and make a copy by clicking the checkbox, clicking on the “html” directory on the left, and entering
php5.ini.backup.txt as the file name
Look for a line mentioning apc.shm_size and if one doesn’t exist, add this:
Make sure lines beginning with
zend_extension are preceded by a semicolon
Save the file and then click the X in the top-right corner
And now we need to restart PHP:
Navigate to your hosting dashboard again
Click the “Launch” button that corresponds with the hosting account in question
Under “Stats & Monitors” click “System Processes”
Click “End Web” in the top
This will restart the PHP process on your account and you should now be able to cache against APC in W3 Total Cache
Note that the optimal configuration depends on available memory, your theme, active plugins, and other factors. If you’d like help unlocking your site’s performance potential, place your order here and we’ll implement these best practices for you.
And if you’d like to be updated when products are updated or announced, be sure to sign up here.
The integration of a Content Delivery Network (CDN) into your website remains one of the easiest and most cost-effective ways to improve web performance. W3 Total Cache supports several CDN types (self-hosted, origin pull, and origin push) and makes the integration into WordPress simple.
In this post, I’ll show you how to integrate MaxCDN’s origin pull CDN product into W3TC. MaxCDN’s product remains one of the most commonly used CDNs in W3TC because it’s both affordable, simple to set up, and requires virtually no maintenance once integrated.
MaxCDN configuration steps
First, create MaxCDN account if you haven’t already. When you log in, click “Manage Zones”
Then click “Create Pull Zone”
Configure your new Pull Zone and then click “Create”
Make a note of your CDN URL, which we’ll use in a moment
We could technically integrate our CDN now, but W3TC can communicate with the MaxCDN (allowing purge requests to be sent directly from WordPress) if we set up the API connection.
Click “my settings” in the top-right corner
Click “API” in the sub-menu that appears
You’ll notice that we don’t have any API Keys configured. Click “Add Key”
Add a description if you’d like and then click “Save”
Your API ID and Key will appear here, I’ve removed my Key from the screenshot
That’s all we need to do in MaxCDN right now. In the next section, we’ll configure W3 Total Cache using the pull zone we just created.
W3 Total Cache configuration steps:
Once logged into WordPress, navigate to the W3 Total Cache by clicking on the “Performance” tab towards the bottom of your Dashboard sidebar. From the General Setting page, ensure that CDN is disabled and select “NetDNA / MaxCDN” from dropdown menu
Navigate to the CDN Settings. Enter your API ID and Key, your CDN URL, and click “Test NetDNA”
You should see “Test passed” in green if you’ve done everything correctly. Save your settings and then navigate back to the General Settings page. Enable the CDN by clicking the check box and saving your settings.
Power user tip #1: Configure a subdomain like
cdn.yourdomain.com so we can get rid of long MaxCDN URL. W3 Total Cache lets you configure multiple CDN subdomains, so we’ll go ahead and configure a few.
Log back into MaxCDN and from the dashboard, click “Manage” next to the Pull Zone you created:
Then click “Settings” right above the Zone Configuration
You’re presented with an overview of your Pull Zone settings
The section we want is labeled Custom Domains. Click “Edit” and enter your desired subdomains
Click “Update” and then navigate to your DNS control panel. Create a CNAME entry for every subdomain that you entered in MaxCDN, and alias them to your MaxCDN URL
Once DNS propagates, you can update W3TC with the subdomains and replace the long CDN URL with the new, custom ones
Power user tip #2: We can further improve page loads speeds by using a completely different domain for the CDN, ensuring that the domain is cookie-free. So if your site is
www.domain.com, you could set
domain.<strong>net</strong> as the domain to use with your CDN. Note: this assumes that you own
domain.net and have access to its DNS control panel.
That’s it! If you have any issues getting it working, drop us a line. If you’d like us to set this up for you, we’re happy to help.