admintiger

Are the 404 errors due to link URLs being wrong or due to linked pages not being available? In other words, do the pages being linked to display without errors if you type their URLs in a web browser address bar instead of taking a link from another page?

WP Super Cache 1.1 works fine here with WP 3.4 under both Windows and Linux using Apache web servers configured for dedicated or name-based virtual hosting. Are you using Apache?

Your site displays fine here.

That doesn’t happen here at multiple sites where WP Super Cache is being used. This screen image is an example from a new site that is still being developed Cache Contents.

Sorry, I must be going blind! I saw get_option(‘siteurl’) and thought I was seeing get_bloginfo(‘siteurl’).

Sorry, I must be going blind! I saw get_option(‘siteurl’) and thought it was get_bloginfo(‘siteurl’).

I am using wp-super-cache. My concern is not the time required to query. It is that if a query finds that a library file has become available at Google every cached page that uses that file will be automatically invalidated and rebuilt whether or not it happens to be a good time for that to occur.

Yes, the same combination of plugins work fine with 3.3/1.2. I can easily modify 1.2 for compatibility with 3.4 if you decide to continue with the new method.

Autoptimize doesn’t use WordPress concatenation to merge sections of JS code together. That is done in its autoptimizeScripts.php file where individual JS code components can be selectively flagged to be moved, to not be moved, or to be moved last.

It is true that querying Google won’t cause constant change. Most UGL users won’t notice the difference, but on a site with more than 25,000 complex pages, like one of mine, cache rebuilding takes more than 30 minutes on a dedicated server. The site remains usable, but page load times increase from less than a second to many seconds during periods of high activity with many HTTP requests per second. It is best to do that as rarely as possible and to do it at times of low activity.

(I am referring above to the live site. I have been testing at an offline test site that except for having the beta version of UGL and WP 3.4RC1 is identical to the online site.)

There are two compatibility issues using 1.5b1 with JavaScript compression (also called minification or minimization) plugins.

1) Autoptimize and various similar plugins not only compress JavaScript code, but also concatenate multiple JS files into single files to reduce the number of HTTP requests. The new method in 1.5b1 of querying Google’s servers and automatically obtaining files from Google as they become available invalidates those pre-compressed and concatenated JS files, which cascades to invalidating compressed HTML files (because JS file names change), and further cascades to invalidating files cached by caching plugins such as WP Super Cache. The server workload to re-create the invalidated files is enormous where a website has a large number of posts or pages.

2) 1.5b1 causes individual JavaScript files to be concatenated in an incorrect sequence, so JS dependencies are broken and web pages do not display correctly even after all those files have been re-created.

I haven’t had any problem using 1.5b1 with WP3.4RC1 without JS compression, but I think its use at sites employing JS compression and caching will cause problems. Of course, cached files also had to be re-created in the past whenever users updated to a new plugin version, but that could be timed to occur during periods of low activity. Furthermore, the previous design didn’t break dependencies in concatenated JS files.

Yes, it does seem that should not happen, because the function does, in fact, exist, at least in a disk file, but not necessarily in memory when needed. The first thing I did after reading the error message was to verify that the function exists.

However, although I haven’t worked through the logic of everything going on, on Line 2406 of wp-cache.php there is an if ‘function_exists’ conditional test to avoid a race-condition. There were operational indications of a race condition after PHP complained that ‘wp_cache_phase2_clean_expired()’ was undefined. Therefore, it seems that even though the function should have been loaded by the phase2 file, it must not have been defined in memory at the time of the error for some reason.

I just installed 1.5b1 at a WordPress 3.4RC1 test site that has 25,000 complex test pages and a wide assortment of other plugins installed. It seemed to function correctly until I optimized JavaScript code with YUI Compression using a customized version of the Autoptimize plugin, which caused web pages to no longer load. Of course, that doesn’t necessarily indicate anything is wrong with 1.5b1, but merely that there is an incompatibility with that combination.

I haven’t done any debugging yet to learn why that happens. I will do some troubleshooting and let you know what I find.

The wp-cache-config.php file at the test site that sends emails contains:

$cache_gc_email_me = 0; //Added by WP-Cache Manager

I checked to be sure the option isn’t set a second place in the file with a different setting and found that it isn’t.

The difference is that I use Apache, instead of IIS, on my Windows servers. I gave up on IIS years ago because of endless problems. WP Super Cache 1.1 runs fine under Windows with Apache. Apache is free, easy to install, more configurable, more reliable, faster, and runs most website code developed under Linux without problems.

If there is some compelling need for IIS, both web servers will run compatibly under the same Windows installation if they are configured to use different IP Addresses or Port Numbers and a router is used to route incoming traffic.

I had to modify 1.0 to make it Windows backslash compatible, but 1.1 runs fine here without modification on several Windows servers. Maybe our servers are configured differently in some way that causes that operational difference.

I have WP Super Cache 1.1 installed at multiple sites. Two are test/development sites with public access blocked. The others are live. WP Super Cache sends an email each time its cache is preloaded even though “Send me status emails when files are refreshed” is not checked on its preload settings page. Emails are not sent from any of the other sites with identical settings.

Deactivating WP Super Cache, deleting its directory, and re-installing doesn’t correct the problem. That suggests that something was left set in the database by a previous version. Many incremental trunk versions of WP Super Cache, other plugins, and nightly WP builds have been installed at that test site over recent years, so database corruption is likely.

I am not explaining this because the email issue is a problem for me. I could easily re-install everything in a fresh database. I just thought it is curious that only that one test site sends the emails and thought that fact might suggest to you another reason for the email issue described by Hazman Aziz.