In response to customer demand, we’ve expanded the offerings around paid W3 Total Cache support. Use the form below to order service and improve your site’s performance today.
The fastest and most complete WordPress performance optimization plugin. Trusted by many popular blogs like: mashable.com, pearsonified.com, noupe.com, webdesignerdepot.com, freelanceswitch.com, briansolis.com, tutsplus.com, yoast.com, css3.info and others — W3 Total Cache improves the user experience of your blog by improving your server performance, caching every aspect of your site, reducing the download time of your theme and providing transparent content delivery network (CDN) integration.
Benefits:
- At least 10x improvement in site performance (when fully configured: Grade A in YSlow or great Google Page Speed Improvements)
- “Instant” second page views (browser caching after first page view)
- Reduced page load time: increased visitor time on site (visitors view more pages)
- Optimized progressive render (pages appear to load instantly)
- Improved web server performance (easily sustain high traffic spikes)
- Up to 80% Bandwidth savings via Minify and HTTP compression of HTML, CSS, JavaScript and RSS feeds
Features:
- Compatible with shared hosting, virtual private servers and dedicated servers / clusters
- Transparent content delivery network (CDN) integration with Media Library, theme files and WordPress itself
- Caching of (minified and compressed) pages and posts in memory or on disk
- Caching of (minified and compressed) CSS and JavaScript in memory, on disk or on CDN
- Caching of RSS (comments, page and site) feeds in memory or on disk
- Caching of search results pages (i.e. URIs with query string variables) in memory or on disk
- Caching of database objects in memory
- Minification of posts and pages and RSS feeds
- Minification (combine and remove comments / white space) of inline, embedded or 3rd party JavaScript (with automated updates)
- Minification (combine and remove comments / white space) of inline, embedded or 3rd party CSS (with automated updates)
- Browser caching of CSS, JavaScript and HTML using future expire headers and entity tags (ETag)
- JavaScript grouping by template (home page, post page etc) with embed location management
- Non-blocking JavaScript embedding
- Import post attachments directly into the Media Library (and CDN)
Easily improve the user experience for your readers without having to change WordPress, your theme, your plugins or how you produce your content.
Download it now or get support here.
- 389 Comments
- 20 Mentions
-
Some great tips there – some are completely new to me, so thanks!
-
When my site was hosted with Dreamhost, W3 Total Cache suddenly stopped working last February 2012, and I had to use W3 Super Cache. I decided to move to Hostgator last April and W3 Total Cache now works again with no problems and it really makes load times faster (about 5 to 10 seconds faster!!!). Now I just started using a cdn and it was so easy to configure and everything just works! Thanks for the excellent plugin!
-
Thanks for the great plugin. Download speed has declined. Good luck!
-
I would also like to thank you for this excellent plugin. I’ve just deployed it for 3 of my sites so far. The increase in page load is AWESOME!
-
i have tried this plugin.. it's really work.. thank you so much
-
Wow awesome plugin! I've been looking for something like this for years!!! I found you through Vladimir Prelovac's site and I use it for http://e-cigarette-review.net
Went from 12 seconds load time to 4.5 seconds! thanks a lot! -
Very good tool, but not so easy to use
i prefer if it was all preselected! -
Most excellent wp plugin. Thanks.
-
Great plugin, i have tried it to my friends sites and works fine. The speed of website is important and google panda just loves it!
-
Total Cache is totally amazing! Thank you Willie and Frederick. I decided to order the basic config. for a client's site and the speed score jumped 32%. I am so pleased with the result and look forward to improving things more via Willie's other recommendations. If you're thinking of getting these guys to give your site a little tune up, don't delay. Instant results. Page load is lightning fast and I can see already in analytics our bounce rate is decreasing and page views are increasing. Cheers to the Total Cache team. Five stars from me:)
-
Probably the best and powerfull plugin for caching ! W3 Total Cache may give your blog 50% faster as usual.
-
by Frederick Townes
on November 5, 2009 at 4:24 pmThat bug will be fixed in the next release.
-
on December 1, 2009 at 8:12 pmDid you check out the link on the installation tab in the plugin?
-
on December 2, 2009 at 1:12 amDid you check out the link on the installation tab in the plugin?
-
on December 2, 2009 at 1:13 amThis question was addressed here: http://wordpress.org/support/topic/337122?replies…
-
on December 3, 2009 at 4:54 pmPlease backup your settings file in wp-content/w3-total-cache-settings.php, deactivate, delete and re-download the plugin, re-enable and restore your settings file to get rid of this issue. Sorry for the inconvenience.
-
on December 3, 2009 at 4:56 pmW3TC is not compatible with other caching plugins. They cannot be combined. Using W3TC you need no other caching plugins.
-
on December 4, 2009 at 1:54 amWhat version of MySQL do you have?
-
on December 4, 2009 at 1:55 amHave a link to multi-database? Haven't heard of it unfortunately.
-
on December 4, 2009 at 9:22 amPlease try to deactivate, delete and then – re-download and re-activate the plugin. Sorry for the inconvenience.t
-
on December 4, 2009 at 5:27 pmThanks for the tip!
-
on December 4, 2009 at 10:48 pmI think it's interesting what this plugin is trying to do. But there are no real performance wins doing this. MySQL isn't scaled by using multiple databases, typically it's scaled with clusters and caching. Using a single database for all your blogs often feels annoying I suppose, but the only performance issues I can see would be addressed with a switch to InnoDB. Other than that, keeping tables optimized and using database caching is the way to go. Having said that, there's no way to make W3TC and Multi DB get along unless multi DB functionality is implemented into WordPress itself, too much logic would have to be added with no real performance gain.
So in the end I think you need to decide, do you want a real performance gain, by adding caching, or do you want separate databases?
-
on December 7, 2009 at 5:31 amThanks @groovyPost
-
on December 9, 2009 at 4:08 pmThe plugin supports path and vhost implementation and has been tested for both cases. Can you explain in more details? Perhaps the domain is in a reserved keyword list?
-
on December 10, 2009 at 10:00 amI have no idea what you're asking about now. As for IntenseDebate, it's not hosted by us, it's hosted by them, so I cannot resolve any issue there. It seems to work in Firefox for the moment.
-
on December 10, 2009 at 10:18 amNot all JS scripts can be minified. You can try to combine them only and if that still produces an error then the script that causes error must be omitted.
-
on December 10, 2009 at 1:56 pmMany blogs have too many pages and comments for this case to be productive. I've never seen any caching software or plugin that forcibly generates a cache for pages that may or may not be viewed. So that feature will not be added. As for minification, you can choose combine only for header or footer to achieve what you describe.
-
on December 13, 2009 at 3:18 pmThere's something else going on with your server config if you are having that issue. There's no combine only option for CSS. It might be best to submit a bug issue from the support tab of the plugin as this is not a known issue. For building your cache, yes a recursive wget or curl to your site map page for example could work. But unless your server is very underpowered, such schemes are pointless.
-
on December 13, 2009 at 3:20 pmYes, on the page cache tab add "/.+" (without the quotes) in the "Never cache the following pages" box.
-
on December 13, 2009 at 3:21 pmThis is not a known issue. If you could install again, disable all options on the general settings tab and submit a bug report from the support tab, that would be best. If you could provide access to your server as well that is preferred.
-
on December 13, 2009 at 4:04 pmI'm unsure what the purpose of your comments are any more. Let's stick to the topic please.
-
on December 14, 2009 at 12:12 pmThere are too many things to check in order find measure all of the benefits you're getting from the plugin. The most simple test for page cache, minification and CDN performance is http://tools.pingdom.com. But there are numerous other tests depending on the optimization.
-
on December 15, 2009 at 1:47 pmHave you uploaded your files to CloudFront? As for the plugin, if you've minified any CSS/JS it uses and not uploaded minify files to CloudFroont (the first time), your site won't behave properly.
-
on December 22, 2009 at 6:09 pmIn the past WordPress did support gzip compression. From a performance standpoint the majority of frameworks have numerous options the least of which is typically gzip compression, however very few natively employ all of the best practices that high performance or problematic sites need. I don't see this changing for the foreseeable future as there are many solutions to common problems and the vast majority of cases really do not need those implementations. Minification for example is extremely problematic in practice because many scripts and CSS files have bugs. If CMS vendors would support this functionality I suppose it would raise the bar on the coding quality that developers deliver, but it would for the short term raise the bar for working with the frameworks, which is the contrary to the goal of growing market share (adoption). So the issue is quite complex and probably deserves it's own blog post.
-
on December 23, 2009 at 2:31 amI don't agree that plugins are just patches. Many would argue that WordPress should offer more SEO friendly functionality by default as well. This isn't true necessarily. WordPress' obligation is to make the core product extensible and robust and the rollout of Canonical plugins shows that WordPress is focused on the publish tool and not the countless directions that users want to use it (which would have diminishing returns). Even if the techniques in W3 Total Cache were implement in WordPress it would not reduce the complexity of the various solutions. Due to how WordPress works they can only be sorted in a specific way and require a tremendous amount of knowledge to implement in a one-size-fits-all way.
-
on December 23, 2009 at 2:34 amGreat testimonial. The plugin was designed precisely for this kind of scenario. Once your site is stable, you can continue using the various options to further improve user experience.
-
on December 23, 2009 at 9:57 amAPC will not work on (gs) hosting accounts. For (gs) use:
Page Cache: Disk enhanced
Minify: Disk
Database: DiskAnd definitely use a CDN if possible, even "Self-hosted" option is better than nothing.
-
on December 23, 2009 at 9:58 amI was referring to canonical plugins: http://wordpress.org/development/2009/12/canonica… And about SEO, well this is a relative thing unfortunately, the friendliness of a site from SEO perspective is one thing, the actual optimization is completely circumstantial.
-
on December 23, 2009 at 2:17 pmCheck the FAQ: /wp-admin/options-general.php?page=w3-total-cache/w3-total-cache.php&tab=faq#q73
-
by Andrew
on December 23, 2009 at 3:38 pmWe are going to install APC tonight and get that tightened up. The CDN is probably the next step. Do people like Amazon the best?
Andrew
-
on December 23, 2009 at 10:09 pm"Origin pull" providers are usually best and just as affordable.
-
on December 24, 2009 at 11:34 amUse the rejected user agents field to resolve this case. You can put all of the mobile user agents that your site needs to handle with your mobile themes, in this field and the users will always see a page that is not cached. The same needs to be be done on the minify tab.
-
on December 25, 2009 at 9:02 amFor now if you make sure that your page cache expires at some interval less than 1 hour, you'll find that nearly all of your pages will always been up to date with regard to your top posts widget.
-
on December 25, 2009 at 9:02 amYes it does, the instructions are simple.
-
on December 25, 2009 at 9:04 amFor now, you'll need to make sure that page cache, minify and CDN (if not using origin pull) all have any mobile user agents you need to handle in the rejected user agents field of the respective settings pages.
-
on December 27, 2009 at 2:16 pmMobile user agents are devices like iPhones and BlackBerries etc.
-
on December 28, 2009 at 12:44 amMobile user agents are devices like iPhones and Blackberries.
-
on December 28, 2009 at 12:50 amBest to only specify the user agents you want to support. Using a long list carries a performance penalty.
-
on December 31, 2009 at 8:25 pmMy popular posts is custom made. Anyway, please check out: http://wordpress.org/support/topic/346439?replies…
-
on January 2, 2010 at 9:37 pmUnfortunately shared hosting providers can do some pretty interesting things, however your uploads directory should be in wp-content, which means this error is unlikely. It's probably best to submit a bug submission via the plugin's support tab so I can have a look at your configuration.
-
on January 6, 2010 at 1:34 amYes, it should. I would appreciate your feedback on this as well.
-
on January 6, 2010 at 1:35 amI'm not familiar with hive (at least by that name). You'll need to remove w3-total-cache-config.php, db.php and advanced-cache.php from wp-content/ after disabling the plugin.
-
on January 6, 2010 at 1:36 amThis may be a bug in WP MU. Can you try other page cache methods and confirm that they work, I believe the issue is only with disk enhanced mode for page caching.
-
on January 11, 2010 at 10:51 pmYes, the plugin currently supports redirection of mobile user agent to another domain (if you use a service) and it supports Origin Pull CDN method for Mobile as well as Database Caching. To use Mobile themes etc, you must add the mobile user agents you do not wish to cache to the rejected user agents list on the page cache settings and minify settings tabs so that your theme will function properly.
-
on January 15, 2010 at 2:51 amIf you're using an origin pull provider you have to do nothing differently. If you're using an origin push provider and the media library the plugin will upload the attachments for you and update your post's cache when the file transfer is successful.
-
on January 15, 2010 at 2:52 amIt's best to submit a bug submission via the support tab of the plugin so I can investigate the matter properly. I've seen 1 case where another plugin's namespace interfered with W3TC and still another where missing PHP libraries prevented proper function of the feature also.
-
on January 15, 2010 at 2:53 amI've seen this issue before in my own testing, but have not see it anywhere else. Could you submit your original file via a bug submission report in the support tab of the plugin so I can see what is unique to your case?
-
on January 15, 2010 at 10:29 amThis is not a known bug, normally if wp-content/ has the write permission the entire directory structure can be created. Just for this case, try to manually create that directory with the proper ownership (user:group) and see if you can make the errors go away. Otherwise you may need to completely remove the plugin and try again. Unfortunately this is really not a common case and is almost impossible to test for.
-
on January 15, 2010 at 10:30 amWhat is your site? This is not enough information to guess what the issue is.
-
on January 17, 2010 at 12:19 pmThis is not a known issue. Please submit a bug submission support using the support tab of the plugin settings area.
-
on January 17, 2010 at 12:21 pmAs a rule of thumb, larger sites do not benefit from having a huge file cache. If your site isn't too large (a relative thing depending on your server etc etc) and is not frequently updated it may be ok to do what you ask. Using settings beyond the defaults is experimental and completely circumstantial.
-
on January 18, 2010 at 8:52 pmAlso remove: w3tc/ directory, advanced-cache.php, db.php and w3-total-cache-config.php from wp-content/
-
on January 18, 2010 at 8:53 pmThe point there is that the cache file will exist, but be unusable and will remain on the server (unused) until garbage collection runs.
-
on January 20, 2010 at 11:05 amI tried to reply to your email and it bounced. Please check your server.
-
on January 20, 2010 at 11:05 amThis and mobile theme management are quite complex use case scenarios. Do you have some recommendations?
-
on January 22, 2010 at 1:37 amYes in wp-config.php. The plugin will tell you what is missing when you try to activate.
-
on January 22, 2010 at 1:38 amDid you change any scripts/css or are you minifying a 3rd party script/css? You may have to submit a bug submission using the support tab of the plugin for better support.
-
by 1lear
on January 22, 2010 at 1:25 amThanks Fred for the response,
I need to clarify. I know it is to be placed in the config file but I don't know exactly where? Top-Bottom after or before something?
<?php
/**
* The base configurations of the WordPress.
*
* This file has the following configurations: MySQL settings, Table Prefix,
* Secret Keys, WordPress Language, and ABSPATH. You can find more information by
* visiting {@link http://codex.wordpress.org/Editing_wp-config.php Editing
* wp-config.php} Codex page. You can get the MySQL settings from your web host.
*
* This file is used by the wp-config.php creation script during the
* installation. You don't have to use the web site, you can just copy this file
* to "wp-config.php" and fill in the values.
*
* @package WordPress
*/// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'putyourdbnamehere');/** MySQL database username */
define('DB_USER', 'usernamehere');/** MySQL database password */
define('DB_PASSWORD', 'yourpasswordhere');/** MySQL hostname */
define('DB_HOST', 'localhost');/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');/**#@+
* Authentication Unique Keys.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
/**#@-*//**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each a unique
* prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'wp_';/**
* WordPress Localized Language, defaults to English.
*
* Change this to localize WordPress. A corresponding MO file for the chosen
* language must be installed to wp-content/languages. For example, install
* de.mo to wp-content/languages and set WPLANG to 'de' to enable German
* language support.
*/
define ('WPLANG', '');/* That's all, stop editing! Happy blogging. */
/** WordPress absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php'); -
on January 22, 2010 at 7:14 amThe top of the file after the line with <?php is fine. Again if you activate the plugin it will tell you precisely what to do.
-
on January 22, 2010 at 9:43 amSorry?
-
on January 22, 2010 at 10:14 amAre you using fancy permalinks? It's impossible for the plugin to slow down your site.
-
on January 22, 2010 at 11:53 amActivation issues are not common. Make sure that wp-content/uploads/ is also 777 permissions as well as wp-content/ (no other directories matter). If permissions aren't working you can change ownership and group to match those that apache is using for wp-content/ and wp-content/uploads/
-
on January 24, 2010 at 8:16 pmYes it works on Windows, the hardest part is getting the underlying software properly configured (IIS or Apache, PHP and MySQL), not using the plugin itself.
-
on January 25, 2010 at 10:48 amThe link is a 404 somehow…
-
on January 26, 2010 at 6:17 amAs of this moment, any files outside the media library would need to be uploaded using the respective tool periodically.
-
on January 26, 2010 at 11:14 amSo if you're not using origin pull minified files will be pushed to your CDN. If you're using Origin Pull, then obviously nothing is ever uploaded by definition (there is no effect).
-
on January 29, 2010 at 8:07 amI don't see anything wrong with your configuration. You'll have to submit a bug submission using the support tab of the plugin. And i also recommend using the support forum (http://wordpress.org/tags/w3-total-cache) instead of the blog because the forum was designed for support, but some people like to ask for support here anyway.
-
on January 29, 2010 at 8:10 amObviously what you say is a fact, but it's a requirement for many caching plugins even if it's not clearly stated.
Furthermore once the plugin creates the files necessary there's a warning message reminding you to reset the permissions back to the defaults.
If you're able and more comfortable changing ownerships and groups, then the plugin will create the necessary files automatically and permissions changes are not necessary.
-
on January 29, 2010 at 5:33 pmYes you can store images, css, js etc on a domain of your choosing using the CDN settings and self-hosted or origin push method. You can specify any web accessible space as the basis for files. For minify, you need to check your site and manually add (and test) which files can be minified. Only those you configure on the minify settings tab will be gzipped et al. If you use origin pull CDN method, then (if your CDN provider supports) even unminified files will be gzipped etc. Everything depends on your options and there are many.
-
on January 30, 2010 at 9:14 amThe default group is for objects that appear on all pages. And the other groups are for objects that are unique to those templates. So if you have jquery on every template add it to default. But if only your post pages have some jquery slider, then add that slider to the 'single' group only. Unused templates can be ignored.
-
on February 2, 2010 at 6:11 amThat warning is more a heads up, that's why it's deliberately annoying. Click hide this message if you've already taken action once as appropriate for your situation.
-
on February 2, 2010 at 10:15 pmDisk enhanced caching for page, disk for minify and APC (if possible) for database and if not disk are best for most users. Obviously setting up an origin pull CDN is going to to be the biggest performance win to speed up your site and get more performance out of your existing hosting plan. Still everyone's situation is different, only the principles remain unchanged. As me privately if you have more specific questions.
-
on February 3, 2010 at 5:21 amIf you have the plugin running you can use the support tab there to submit a bug (ask for help).
-
on February 4, 2010 at 12:09 amNone of those plugins are nearly as complex. Are you also saying that you have other cache other cache plugins installed at the same time?
-
on February 4, 2010 at 4:30 amCurrently there are no known bugs with HTTP compression. This issue is being discussed here: http://wordpress.org/support/topic/360032
-
on February 4, 2010 at 9:30 amCurrently there are no known bugs with HTTP compression. This issue is being discussed here: http://wordpress.org/support/topic/360032
-
on February 4, 2010 at 4:30 amCurrently there are no known bugs with HTTP compression. This issue is being discussed here: http://wordpress.org/support/topic/360032
-
on February 4, 2010 at 9:30 amOlder versions of apache have this issue, it's already fixed in the next release.
-
on February 4, 2010 at 9:32 amThe minify library has numerous bugs that no one seemed to identify or patch, so yes there have been custom patches. Additional minifcation engines will be added in later releases, but for the moment, you cannot remove comments from jQuery 1.32 with minify, the combine only option (with no other options), is the only setting that does not falsely match some vital jQuery code and break the library. There is no workaround except to deeply patch the minify library and I'm not going to continue doing that as it slowing down the project as a whole (instead other minfy engines will be added).
-
on February 4, 2010 at 3:54 pmYes, it's the same minify library. I've submitted patches to the core team before as well. The other minify plugin I've seen uses and older version of the library and supports less options, provides less savings. As previously explained I'm aware of the jQuery issue and why it happens and the point I made was NOT using the comment removal option in the release I use was the solution.
-
on February 5, 2010 at 10:01 amYes
-
on February 11, 2010 at 10:47 amEvery site is different. Compared to a default WordPress install this is quite extreme. It means you either have a site with many queries per page, lots of traffic and/or high garbage collection time with very low cache time for objects.
-
on February 12, 2010 at 10:52 pmSeems like some slow hard disk I/O. Try to dactivate the plugin and reactivate to see if there are any underlying errors. It will check to make sure all is ok on activation.
-
on February 13, 2010 at 10:50 amThis is not a known (or common) issue, so unfortunately all I can suggest is having a look at your server. W3TC has a lot of functionality so activation is a "a lot of work" for some servers. Please contact me through my contact form.
-
on February 16, 2010 at 12:26 amYou don't need to worry about links as W3TC is dynamically replacing the URLs to your images in the cached file. It does not modify your database. In other words, when W3TC is disabled, your images will load from your server as they used to, not the CDN.
-
on February 18, 2010 at 12:41 pmI really don't think it takes so long to understand how to set up the plugin. If you want to use all of the options, then yes it will take some time depending on your experience level or the problems with your site/server.
-
on February 19, 2010 at 10:54 amI recommend installing the PECL memcached extension to make memcached more reliable for you. You also may want to test telneting to the port memcached is listening on to be sure that it is in fact responding.
-
on February 19, 2010 at 10:55 amUnfortunately there are too many settings to give you more than a "no, I've configured this with W3TC fine before" response. If you fill out the bug submission form in the support tab of the plugin I can then see what settings you have hopefully what is going wrong.
-
on February 19, 2010 at 10:57 amThis topic will be continued here: http://wordpress.org/support/topic/366310?replies…
-
on February 19, 2010 at 3:48 pmThese problems are not normal. You have not compiled it properly or are not running it as a daemon with flag '-d' as per the instructions on the install tab. If you do not have a multiple server configuration, do not use it at all. If you do have a multiple server configuration, make sure to use PECL memcache PHP extension and test the connection from within W3TC.
-
on February 23, 2010 at 2:14 amIt's hard to guess what's causing that error. Can you fill out the bug submission form in the plugin so I can get a report of your settings?
-
on February 23, 2010 at 2:15 amW3TC does not send (or modify the) content-length header. Modifying the headers may cause compatibility issues. Did you try not caching a single page without using * ?
-
on February 23, 2010 at 2:15 amNo.
-
on February 23, 2010 at 2:16 amSpiders get a compressed version of the page, if they support it.
-
on February 23, 2010 at 11:03 amAs the message says, if you change the status of plugins, it may affect your minify settings. So if you're sure that it hasn't then hide the message.
-
on February 24, 2010 at 11:13 pmIf you're using default settings then the warning the plugin shows is irrelevant. The point of the warning is to remind you to check/update your settings in case JS or CSS has been added/removed from your theme or file names modified.
-
on February 25, 2010 at 9:56 amIf you've checked to make sure that that query is longer cached, then the page caching itself is preventing the updates from being visible. So until fragment caching is added to the plugin it's best to lower the 'Maximum lifetime of cache objects' value so that the page cache is regenerated more frequently.
-
on February 28, 2010 at 12:36 amNo, only the comments in the plugin near the respective options.
-
on March 9, 2010 at 11:20 pmThis bug is fixed in the next release which is due out soon.
-
on March 9, 2010 at 11:22 pmAdd the relative path to the page in the "Never cache the following pages" field, e.g. /contact/
-
on March 9, 2010 at 11:24 pmThe point here is that pages that bots visit should not be cached since there is no need to fill up the cache with pages that normal users are not using. I'm debating whether or not to remove these default options, but in any case it won't matter as if a search engine is visiting old pages it's not possible to cache them before hand unless you prime the cache for all pages in your site in advance which wastes resources.
-
on March 9, 2010 at 11:26 pmYes it will work, but more testing will still need to be done as not many users are using it for BuddyPress yet.
-
on March 9, 2010 at 11:26 pmIn general, because Page Speed is a factor, it will improve your Google ranking especially if you send cached pages to search engines.
-
on March 9, 2010 at 11:27 pmYes, but it's best to minify them. If they cannot be minfied and they're not statistics or ad code, then yes.
-
on March 9, 2010 at 11:28 pmThe enqueue functionality is not reliable, so this is already changed in the next release. You don't need to worry about key collisions. There has not been a lot of demand for lighttpd support, so it's currently not scheduled.
-
on March 9, 2010 at 11:25 pmASAP.
-
on March 15, 2010 at 5:59 pmTry adding wp_rg_ (if your blog uses the default table prefix) to the ignored query stems field on the database caching tab. Whether or not database is helping your site is a relative thing that would require me to review it to answer. In general database caching is going to reduce the time required to build a new page, so it's important.
-
on March 23, 2010 at 10:21 pmThe plugin doesn't cause these kinds of issues, there's a conflict with another plugin and a bug submission is the best way to get any useful support.
-
on March 23, 2010 at 10:22 pmToo many users were selecting memcached without knowing what it was or following the installation instructions correctly. So now PECL memcache PHP extension is *required* for memcached support. If memcache is not detected, memcached support is not available.
-
on March 23, 2010 at 10:23 pmYou can do it by adding the directories path to the never cache the following pages field on the page cache settings tab.
-
on March 23, 2010 at 10:23 pmI don't think I will support either of those, the # of users on windows is too small compared to linux and coralcdn has extremely poor performance.
-
on March 23, 2010 at 10:24 pmThank you.
-
on March 23, 2010 at 10:25 pmI have no experience with that particular stack permutation. If you wish you can submit a bug submission via the support tab of the plugin if possible. If you cannot, it's unlikely I can help.
-
on March 23, 2010 at 10:25 pmPlease download and install the development version: http://wordpress.org/extend/plugins/w3-total-cach… and submit a bug submission via the support tab if problems persist.
-
on March 23, 2010 at 10:26 pmIt appears there's either a conflict with your .htaccess file or the directives were not properly implemented. Try switching to disk basic and then back to disk enhanced and see if there are any notifications.
-
on March 23, 2010 at 10:28 pmTry turning in database caching debug mode on the general settings tab of the plugin. Debug data will appear in an HTML comment at the bottom of the source code.
-
on March 23, 2010 at 10:28 pmFragment caching will be supported in an upcoming release.
-
on March 23, 2010 at 10:29 pmPlease check the FAQ for instructions on how to update YSlow to recognize your CDN.
-
on March 23, 2010 at 10:40 pmI can't recommend a mobile plugin as I haven't tested them all. Unless you have a mobile only domain you will have to add the mobile user agents to the rejected user agents field on all of the caches except CDN if you use origin pull. As for the counters, you need to either disable database caching or use debug mode (the output of it will appear as HTML comments in the source code) to find the tables that are used and add them to the ignored query stems field on the database caching tab.
-
on March 23, 2010 at 10:43 pmPlease upgrade to the development version: http://wordpress.org/extend/plugins/w3-total-cach… and make sure to click the "Verify URI" button next to each of your file entries before saving your settings.
-
on March 23, 2010 at 10:43 pmDisable HTML minification. Your settings are too aggressive.
-
on March 23, 2010 at 10:45 pmThe plugin doesn't currently check for changed files and re-upload them. It handles new files only. More functionality will be added surrounding this in the future.
-
on March 26, 2010 at 10:46 pmNo ideas without logging in to see (since there are no errors displayed). Submitting a bug submission from the support tab would be helpful.
-
on March 26, 2010 at 10:47 pmIt's not possible to cache the home page an ignore updates. The home page is automatically re-cached (as long as people keep loading it) according to the expiry time in your settings.
-
on March 30, 2010 at 6:07 pmCan you try the development version: http://wordpress.org/extend/plugins/w3-total-cach… ?
-
on March 30, 2010 at 6:11 pmThis path is modified using the define statements according to: http://codex.wordpress.org/Editing_wp-config.php
-
on March 31, 2010 at 6:44 pmIn a future release.
-
on April 12, 2010 at 1:57 amTry about test like the one at port80software.com to be sure.
-
on April 12, 2010 at 1:58 amTry making sure that wp-content is chmod 777 as is wp-content/uploads/ at the time of activation (revert afterwards).
-
on May 7, 2010 at 12:45 pmPlease email me directly for help troubleshooting.
-
on April 12, 2010 at 1:58 amUnfortunately this is not possible, but there will be logic to re-purpose setting files in the future.
-
on May 7, 2010 at 12:45 pmThis is not possible. There are too many settings and limitations. I will perhaps work on some solutions in the future.
-
on April 12, 2010 at 6:45 amIt means your PHP.ini (configuration file) is set to do HTTP compression already and that setting is interferring with W3TC. Ask your web hosting administrator to disable it.
-
on May 7, 2010 at 12:44 pmIt means that you have gzip compression by default in your PHP configuration and that setting is incompatible with W3TC. Ask you host for help changing that value.
-
on April 12, 2010 at 7:01 amNo you didn’t, please try the development version for now: http://wordpress.org/extend/plugins/w3-total-cache/download/
-
on May 7, 2010 at 12:40 pmPlease try the development version of the plugin:http://wordpress.org/extend/plugins/w3-total-cach…
-
on May 7, 2010 at 7:40 amPlease try the development version of the plugin:http://wordpress.org/extend/plugins/w3-total-cach…
-
on April 14, 2010 at 7:31 amIt’s important to move the W3TC .htaccess directives directly above your WordPress directives (which should be last in the file), so that any of your own custom directives are above W3TC directives; i.e. from the top of the file down: [your directives], [W3TC directives], [WordPress directives]
-
on May 7, 2010 at 12:51 pmThere's an issue with the order of directives in your .htaccess file. Move all except WP and W3TC directives to the top of the file. This is better handled in the next release.
-
on April 16, 2010 at 4:30 amDid disabling caching of feeds or page caching entirely resolve the issue?
-
on May 7, 2010 at 12:51 pmBest to submit a bug submission on the support tab of the plugin.
-
on April 16, 2010 at 4:31 amCan you submit a bug submission report from the support tab of the plugin? There's an issue with the order of directives in your .htaccess file.
-
on May 7, 2010 at 12:51 pmThere's an issue with the order of directives in your .htaccess file. Move all except WP and W3TC directives to the top of the file. This is better handled in the next release.
-
on April 16, 2010 at 9:21 amSimilar features are already scheduled. I’m not at v1.0 yet.
-
on May 7, 2010 at 12:52 pmA similar feature is scheduled.
-
on April 16, 2010 at 9:26 amSpecify a path like /somesection/* in the “Never cache the following pages” field on the page cache settings tab.
-
on May 7, 2010 at 12:52 pmAdd the path of the page to the never cache the following pages field of the page cache settings tab.
-
on April 23, 2010 at 4:55 amPlease fill out bug submission report from the support tab of the plugin.
-
on May 7, 2010 at 12:39 pmYou can fill out a bug submission form from the support tab of the plugin if the problem is persisting.
-
on April 23, 2010 at 4:56 amI don't think you have read the description of the plugin, please take a closer look.
-
on May 7, 2010 at 1:06 pmYou need follow the usage instructions in the plugins FAQ to properly configure minify.
-
on April 23, 2010 at 4:57 amThis question was answered in the forums.
-
on May 7, 2010 at 7:19 amTo be honest, I would have to have a look at the server to see what the cause of this was.
-
on May 7, 2010 at 12:23 pmBy version 1.0.
-
on May 7, 2010 at 12:39 pmHere are some great instructions for this use case:http://nimopress.com/pressed/blog-building-how-to…
-
on May 7, 2010 at 1:18 pmCan you submit a bug submission report from the support tab of the plugin please?
-
on May 7, 2010 at 12:28 pmThis is done by default in the next release.
-
on May 7, 2010 at 12:28 pmIt's a bug with opera, but fixed in the next W3TC release.
-
on May 7, 2010 at 12:34 pmThat is not a reliable implementation. Not all plugins / theme authors use this convention. The current implementation is the only way to handle any possible case. Later a wizard will be available to save time. But since not all scripts can be minified, your suggestion still is not viable. There's no one-size fits all approach even if there's a quick set up wizard. Configuration data is stored in the config file in wp-content/.
-
on May 8, 2010 at 2:54 pmHave you added any files to the CSS and JS minify sections? Also read the comments of and use the file found in wp-content/plugins/w3-total-cache/ini/_htaccess
-
on May 10, 2010 at 4:28 pmUnfortunately, the plugin is not properly configured. Please review the usage section of the plugin's FAQ.
-
on May 10, 2010 at 6:26 amThat functionality is determined when creating your bucket. If you create it using tools other than W3TC you will be able to control it's location. Regardless, Cloudfront provides optimal performance and should be used instead of S3 alone.
-
on May 13, 2010 at 4:08 amThe general settings tab shows the recommendations for many cases. Beyond that there are too many possibilities to make blind suggestions.
-
on May 18, 2010 at 2:08 pmEvery blog is different, the comments in the options group will help you get started. Beyond that either expert advice or experimentation is required. Also read the FAQ. Many blogs have no need to change the defaults for most settings.
-
on May 13, 2010 at 4:12 amIt's hard to guess without seeing your site. Try submitting a bug submission report from the support tab of the plugin.
-
on May 18, 2010 at 2:07 pmSubmitted a bug report from the support tab of the plugin will make it easier to troubleshoot.
-
on May 18, 2010 at 2:06 pmSorry this cannot be removed right now. You can search through the code to disable in manually if you must.
-
by Josh
on May 19, 2010 at 11:02 amI have the exact same problem when I turn off the CDN. The main problem I have though is that the CDN doesn't work. The image files are all renamed with either 1 or the image sizes added to the end. This breaks all of the links to the files.
-
by Joshua Abel
on June 17, 2010 at 4:56 pmWe're running W3TC on a CentOS 5.4 cloud node with NGINX+PHP-FPM+MEMCACHED with great performance!
Great Plugin man, my loading speed increased from 89 to 94 after using this plugin. Thanks a ton