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.
- 359 Comments
- 20 Mentions
Did you check out the link on the installation tab in the plugin?
Did you check out the link on the installation tab in the plugin?
This question was addressed here: http://wordpress.org/support/topic/337122?replies...
Please 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.
W3TC is not compatible with other caching plugins. They cannot be combined. Using W3TC you need no other caching plugins.
What version of MySQL do you have?
Have a link to multi-database? Haven't heard of it unfortunately.
Please try to deactivate, delete and then – re-download and re-activate the plugin. Sorry for the inconvenience.t
Thanks for the tip!
I 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?
Thanks @groovyPost
The 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?
I 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.
Not 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.
Many 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.
There'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.
Yes, on the page cache tab add "/.+" (without the quotes) in the "Never cache the following pages" box.
This 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.
I'm unsure what the purpose of your comments are any more. Let's stick to the topic please.
There 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.
Have 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.
In 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.
I 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.
Great 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.
APC 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.
I 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.
Check the FAQ: /wp-admin/options-general.php?page=w3-total-cache/w3-total-cache.php&tab=faq#q73
We 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
"Origin pull" providers are usually best and just as affordable.
Use 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.
For 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.
Yes it does, the instructions are simple.
For 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.
Mobile user agents are devices like iPhones and BlackBerries etc.
Mobile user agents are devices like iPhones and Blackberries.
Best to only specify the user agents you want to support. Using a long list carries a performance penalty.
My popular posts is custom made. Anyway, please check out: http://wordpress.org/support/topic/346439?replies...
Unfortunately 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.
Yes, it should. I would appreciate your feedback on this as well.
I'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.
This 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.
Yes, 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.
If 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.
It'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.
I'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?
Are you using suhosin or suPHP?
This 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.
What is your site? This is not enough information to guess what the issue is.
This is not a known issue. Please submit a bug submission support using the support tab of the plugin settings area.
As 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.
Also remove: w3tc/ directory, advanced-cache.php, db.php and w3-total-cache-config.php from wp-content/
The point there is that the cache file will exist, but be unusable and will remain on the server (unused) until garbage collection runs.
I tried to reply to your email and it bounced. Please check your server.
This and mobile theme management are quite complex use case scenarios. Do you have some recommendations?
Yes in wp-config.php. The plugin will tell you what is missing when you try to activate.
Did 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.
Thanks 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');The 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.
Sorry?
Are you using fancy permalinks? It's impossible for the plugin to slow down your site.
Activation 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/
Yes 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.
The link is a 404 somehow…
As of this moment, any files outside the media library would need to be uploaded using the respective tool periodically.
So 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).
I 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.
Obviously 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.
Yes 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.
The 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.
That 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.
Disk 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.
If you have the plugin running you can use the support tab there to submit a bug (ask for help).
None of those plugins are nearly as complex. Are you also saying that you have other cache other cache plugins installed at the same time?
Currently there are no known bugs with HTTP compression. This issue is being discussed here: http://wordpress.org/support/topic/360032
Currently there are no known bugs with HTTP compression. This issue is being discussed here: http://wordpress.org/support/topic/360032
Currently there are no known bugs with HTTP compression. This issue is being discussed here: http://wordpress.org/support/topic/360032
Older versions of apache have this issue, it's already fixed in the next release.
The 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).
Yes, 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.
Yes
Every 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.
Seems 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.
Yes, and by default it's enabled (page's not cached for logged in users) on the page cache settings tab.
This 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.
You 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.
I 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.
I 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.
Unfortunately 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.
This topic will be continued here: http://wordpress.org/support/topic/366310?replies...
These 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.
It'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?
W3TC 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 * ?
No.
Spiders get a compressed version of the page, if they support it.
As 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.
If 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.
If 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.
No, only the comments in the plugin near the respective options.
This bug is fixed in the next release which is due out soon.
Add the relative path to the page in the "Never cache the following pages" field, e.g. /contact/
The 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.
Yes it will work, but more testing will still need to be done as not many users are using it for BuddyPress yet.
In general, because Page Speed is a factor, it will improve your Google ranking especially if you send cached pages to search engines.
Yes, but it's best to minify them. If they cannot be minfied and they're not statistics or ad code, then yes.
The 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.
ASAP.
Try 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.
The 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.
Too 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.
You can do it by adding the directories path to the never cache the following pages field on the page cache settings tab.
I 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.
Thank you.
I 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.
Please 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.
It 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.
Try 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.
Fragment caching will be supported in an upcoming release.
Please check the FAQ for instructions on how to update YSlow to recognize your CDN.
I 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.
Please 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.
Disable HTML minification. Your settings are too aggressive.
The 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.
No ideas without logging in to see (since there are no errors displayed). Submitting a bug submission from the support tab would be helpful.
It'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.
Can you try the development version: http://wordpress.org/extend/plugins/w3-total-cach... ?
This path is modified using the define statements according to: http://codex.wordpress.org/Editing_wp-config.php
In a future release.
It 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.
It 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.
Try about test like the one at port80software.com to be sure.
Try making sure that wp-content is chmod 777 as is wp-content/uploads/ at the time of activation (revert afterwards).
Please email me directly for help troubleshooting.
Unfortunately this is not possible, but there will be logic to re-purpose setting files in the future.
This is not possible. There are too many settings and limitations. I will perhaps work on some solutions in the future.
No you didn’t, please try the development version for now: http://wordpress.org/extend/plugins/w3-total-cache/download/
Please try the development version of the plugin:http://wordpress.org/extend/plugins/w3-total-cach...
Please try the development version of the plugin:http://wordpress.org/extend/plugins/w3-total-cach...
It’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]
There'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.
Similar features are already scheduled. I’m not at v1.0 yet.
A similar feature is scheduled.
Specify a path like /somesection/* in the “Never cache the following pages” field on the page cache settings tab.
Add the path of the page to the never cache the following pages field of the page cache settings tab.
Did disabling caching of feeds or page caching entirely resolve the issue?
Best to submit a bug submission on the support tab of the plugin.
Can 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.
There'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.
Please fill out bug submission report from the support tab of the plugin.
You can fill out a bug submission form from the support tab of the plugin if the problem is persisting.
I don’t think you have read the description of the plugin, please take a closer look.
by w3edge
on May 7, 2010 at 1:06 pmYou need follow the usage instructions in the plugins FAQ to properly configure minify.
This question was answered in the forums.
By version 1.0.
Here are some great instructions for this use case:http://nimopress.com/pressed/blog-building-how-to...
- by w3edge
on May 7, 2010 at 1:18 pmCan you submit a bug submission report from the support tab of the plugin please?
- by admin
on May 7, 2010 at 12:19 pmTo be honest, I would have to have a look at the server to see what the cause of this was.
This is done by default in the next release.
It's a bug with opera, but fixed in the next W3TC release.
That 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/.
- by admin
on May 8, 2010 at 7: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
Unfortunately, the plugin is not properly configured. Please review the usage section of the plugin's FAQ.
That 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.
- by admin
on May 13, 2010 at 9:08 amThe general settings tab shows the recommendations for many cases. Beyond that there are too many possibilities to make blind suggestions.
Every 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.
- by admin
on May 13, 2010 at 9:12 amIt’s hard to guess without seeing your site. Try submitting a bug submission report from the support tab of the plugin.
Submitted a bug report from the support tab of the plugin will make it easier to troubleshoot.
Sorry 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 4:02 pmI 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.
We're running W3TC on a CentOS 5.4 cloud node with NGINX+PHP-FPM+MEMCACHED with great performance!
That bug will be fixed in the next release.