Thank you for using W3 Total Cache! 

With this minor release we addressed an issue with the WordPress 5.3 release:

Warning: Declaration of W3TCDbCache_Wpdb::prepare($query, $args) should be compatible with wpdb::prepare($query, …$args) in /home/xxxxxxx/public_html/wp-content/plugins/w3-total-cache/DbCache_Wpdb.php on line 8

Please note that you need to Purge all caches and to clear your CDN cache if the warning is still showing on your website after updating to v0.10.2

We want to thank all of you who brought this issue to our attention, and hope you continue to support our product!

In our public repository on GitHub, you can review our source code, post issues, and even submit pull requests. You are welcome to join us there, and we really appreciate all users that have contributed, both past and present. In the very near future, we will be adding attribution for all contributors that assist us in making W3 Total Cache the best WordPress Performance Boosting product on the market. 

We are always looking for ways to improve W3 Total Cache with new features, UX and UI improvements, and fixing any outlying problems that may exist. If you like what we are doing, please be sure to take some time and rate our plugin on the WordPress Plugin Repository.

We appreciate all of our partners, supporters and the entire WordPress community, and would like to give special thanks to those who are active in the forums helping end-users.

Sometimes modifications to existing .js and .css files are not reflected for users visiting your website. This occurs because those files have been cached in the user’s browser from a previous visit and the cached version is served instead of the most recent version. The expiration of this cache is called time to live, or TTL and it is associated with this local cache in your browser, which is why it will show the old version until this length of time has passed. To see the correct version of the files, the user has to either clear the browser’s local cache & reload the page or do a hard refresh of the page by pressing Ctrl+F5 to ensure their browser is using the latest file versions.

When a user tries to access the URL, and the browser starts fetching the page data, it sees that it already has the page’s stylesheet E.G. style.css, and  says “Wait!, I already have this file cached, so I don’t need to fetch it again and can just present that to the visitor”. And the Browser has a point!

What is Cache Busting?

Asking each and every user to clear their browser cookies or do a hard refresh is not reasonable and leads to frustrating user experience. To remedy this, we can use a technique known as Cache Busting. Cache Busting works by appending a unique query string to the path of the .js or .css file that tells the browser there is a new file to add to the cache memory.  When the browser loads a page using these query strings it downloads any unrecognized files and displays them for the visitor.

How can I fix this?

You can use any unique query string you want to bust the browser cache, but the easiest way to guarantee a unique string is to use version numbers.

For example:

Let’s say you make some changes within your theme’s main JS file:

/mywebsite/wp-content/themes/mytheme/mytheme.js

After updating the file simply add a version number query string ?v=1.0

/mywebsite/wp-content/themes/mytheme/mytheme.js?v=1.0

This way when the browser will see the updated JS as a new .js file which is not cached. So it will generally force the browser to update the JavaScript/stylesheet. So, each time you update your JS/CSS on the server, you can incrementally update your version number so it busts the previously saved browser cache.

You can accomplish this when you enqueue your script by adding an argument for the version, for example:

WordPress 5.3, scheduled to be released on November 12, and contains numerous improvements for site performance and user experience.

Server-Side Block API

PHP enthusiasts (and JavaScript haters) will be glad to know that there is now a server-side API for creating blocks in the WordPress Block Editor (Gutenberg). When asked about the performance impact of registering new blocks this way, Core Contributor Jorge Costa suspects that the impact should be negligible unless compared to a JavaScript file that is registering a large number of new blocks, which could be cached by the browser:

For most cases, the performance should be equivalent. The PHP code dynamically generates an inline script with the equivalent JavaScript code to register a block style and generates an inline style with the classes. If many block styles are being registered having a single JavaScript file that registers all the styles and a single stylesheet that includes the styles may be more performant than registering the styles with PHP. In that case, the JavaScript and CSS files will probably be cached by the browsers while for inline scripts/styles it is not possible to take advantage of caching.

Better Large Image Uploads

An update to the WordPress REST API will solve a major pain-point for many users— better handling of large image uploads. Previously, if the server returned a 500 error at any point during the upload process, the upload would fail. Now, the request will automatically reconnect and attempt the upload again, as well as generate the attachment sizes at the very end of the request.

In another improvement to the REST API, you can now use Objects and Arrays to create Post Meta-based Gutenberg blocks.

Twenty Twenty Theme

The Twenty Twenty theme has excellent performance according to our tests. The developers have included the Inter typeface, which includes all of its weights and variations in just two files—  which are served directly from the website rather than using cross-domain requests.

Modernizing the Date/Time API

The WordPress Date/Time component has historically relied on the sum of the Unix timestamp and a time zone offset, which caused a great deal of confusion since the inline documentation referred to it as simply a Unix timestamp. Developers would need to account for this difference when comparing two timestamps against each other.

The new API allows developers to fetch a timestamp as a true Unix time or a DateTimeImmutable object, with methods to set timezone offsets in a reliable manner.

Thank you for using W3 Total Cache!

With this minor release, we fixed slowdown in Memcached engine, Purge Cache menu links so they flush current blog in WPMU, and fixed am an error during upgrade, “Call to undefined method W3TC Util_Content::is_database_error”.  We’ve also updated Redis cache engine to avoid “Function Redis::delete() is deprecated” warning

In our public repository on GitHub, you can review our source code, post issues, and even submit Pull requests. You are welcome to join us there, and we really appreciate all users that have contributed, both past and present.

We are always looking for ways to improve W3 Total Cache with new features, UI improvements, and of course, improvements to the user experience. If you like what we have done, please be sure to take some time and rate our plugin on the WordPress Plugin Repository.

Once again, we are sending a big thanks to all of our supporters, including those who are active in the forums helping end-users. 

Thank you for using W3 Total Cache!

The newest update for W3 Total Cache is here and we will continue to deliver more speed for your WordPress websites while we continually improve the user experience.

In this release, we’ve added a new statistics component for pro users, redirects by using safer wp_safe redirect, .htaccess usage when page cache does not require it, protection of unexpected values in global variables, and improved support for CloudFront distributions with multiple origins. We’ve also added support for the Memcached binary protocol when available, more Amazon S3 regions, and caching for webp MIME type. 

Additionally, we have fixed some bugs with the usage of base URL with minify, S3 + CloudFront URLs when CNAMEs not used, and mixing the content of sync & async scripts with minify.

In our public repository on GitHub, you can review our source code, post issues, and even submit Pull requests. You are welcome to join us there, and we really appreciate all users that have contributed, both past and present.

We are always looking for ways to improve W3 Total Cache with new features, UI improvements, and of course, improvements to the user experience. If you like what we have done, please be sure to take some time and rate our plugin on the WordPress Plugin Repository.

Once again, we are sending a big thanks to all of our supporters, including those who are active in the forums helping end-users. 

Thank you for using W3 Total Cache!

We are continuing to improve W3 Total Cache by delivering more speed for your websites and better user experience. With this release, we’ve Updated AWS library due to the deprecation of older API versions scheduled on June 6, 2019, and added support of set_sql_mode by dbcluster. We’ve fixed the PHP warning when remote service cannot be loaded, PHP warnings on the support page and improved support for a web server running on non-default port with disk-enhanced and menu icons.

In our public repository on GitHub, you can review our code, post issues, and Pull requests, and you are welcome to join us there.

We are always looking to improve W3 Total Cache with new features and UI improvements and of course, fixes and improvements for improved user experience so make sure to take some time and rate our plugin here.

Again, big thanks to all of our supporters, including those who are active in the forums helping end users.

Thanks for using W3 Total Cache!

First, we want to thank all of you for bringing bugs and issues to our attention. This is helping us to fix and improve the W3 Total Cache to user satisfaction. In this release we improved security on calls to Opcache flush, cache delivery of /feed URLs, purging of the current page by using post_id instead of URL and minification of files in environments running on non-default ports.

We’ve also added fixes for database cluster in WordPress 5.1, minification in multisite when URLs were set to root-blog based URL, undefined w3tc_ga issue, warning caused by user agent theme change used, 404 in multisite caused by subdirectory issue and PHP warning when Redis integration not configured correctly

Make sure to visit our public repository on GitHub where you can review our code, post issues, and Pull requests.

In future releases, you can expect a lot of new features and UI improvements and of course, fixes and improvements for improved user experience

A big thanks to all of our supporters, including those who are active in the forums helping end users. Please take some time and rate our plugin here. Every feedback and every issue reported is helping us continue offering a top-notch product.