_ck_

It is not the theme, the STYLE=”” is direct applied on the element

apparently beforesubmit is being fired on document ready

Okay figured out a simple workaround if anyone runs into this in the future

in phase1 just return false when testing gzip_accepted

function gzip_accepted(){ return false;

This way supercache still makes the .gz files for direct serving via nginx but will use the non-gzip version of the file when it falls through to legacy mode when a url query is present. Then nginx will still gzip the output properly.

Short was between operator’s headset ??

Local copy was trunk, server copy was older copy before transition function was created.

It’s a security issue if users can control how your site behaves.

The entire sanitation check is highly dubious in this plugin and not robust enough.

$domain = $wpdb->escape( $_POST[ 'domain' ] );
                if ( $domain == '' ) {
                        wp_die( "You must enter a domain" );
                }

if( null == $wpdb->get_row( "SELECT blog_id FROM {$wpdb->blogs} WHERE domain = ...
&& null == $wpdb->get_row( "SELECT blog_id FROM {$wpdb->dmtable} WHERE domain = ...'

So a user can enter high ascii characters, unicode, leading dots, trailing dots, ip addresses, “localhost” and a whole bunch of other questionable entries that may cause undesired behavior.

It would probably be a good idea to test if the domain entered

1. is not an ip
2. is dotted (not dotless or localhost)
3. doesn’t contain the domain of the multisite home network
4. actually has an rdns A record or CNAME
5. that rdns resolves to the current network ip

A word of warning to those with proxies ahead of apache like nginx.

This will NOT work if you artificially set the HTTPS flag

RewriteCond %{HTTPS} on

Because apache hasn’t determined it on it’s own, the HTTPS flag is NOT equal to the environmental HTTPS variable, even though PHP after apache will see them as equal.

What you have to do instead is this

RewriteCond %{ENV:HTTPS} on

This is not the fault of wp-super-cache, just something to be aware of to save you time.
If you do it incorrectly, you will see Apache serving the index.html file to https connections instead of index-https.html

I do suggest that super-cache put the HTTPS rewrite rule first in it’s .htacess blocks though, kind of a waste to process all those other rules for each page load.

Okay I see where index-https was added in 1.2

Doesn’t really address the original problem of true https detection but I guess nginx users can work around the environment problem.

Is there a better solution than this for nginx

inside http {

map $scheme $index {
    default  index;
    https    index-https;
}

then later in your location {

try_files /wp-content/cache/supercache/$host/$uri/$index.html

Note the $ on index to make it a string set by the map early on

That’s be best I can come up with because you should not use if statements in nginx when possible to avoid it.

Actually now that I think about it, the whole approach is bad.

Because a cached page for https and a cached page for http will have completely different links on the page.

If you use the same http cached page for https, non-relative links will be broken and take the user out of https when they follow (and visa versa)

You need to store (https) cached pages with the protocol appended and adjust htaccess as well for that situation.

“legacy caching” means php loads to send the headers and then dumps the static file?

there has to be a way to avoid that – I’ll study it this weekend, not sure why feeds would need any kind of special headers for logged out users

Unless donncha has addressed it in newer versions, feeds aren’t cached (any longer?) as static files because of the header difference for feeds.

But I sure would like to fix that and make feeds static too.

Unfortunately the sites I have running supercache are too high volume to risk experimentation but I will maybe try it locally first and watch the behaviors…

WordPress itself seems conflicted on the issue, half the hacks in there use SERVER_NAME the other half HTTP_HOST

The problem is the .htaccess code has to stay consistent with the internal approach. Unfortunately the wordpress site_url is just not available there.

Probably IIS hosts with PHP respond differently than apache or even nginx.

You might just want to set a global variable or even a constant for the hostname and allow it to be adjusted as needed.

But browser provided headers should never be accepted as the default. SERVER_NAME is far preferred over HTTP_HOST, unless SERVER_NAME is just not available in the environment.

I have now tested this with changing =='draft' to !='publish' and it works perfectly.

After some additional thinking, it occurs to me a parent directory to a file might be (significantly) older than the file that is needing deletion – ie. 2011/08/09/index.htm but 2011/08/ might have other subdirectories even though it meets the age requirements.

So it still can be done, but has to be done in two passes, first just old files, then looking for empty directories to cleanup.

1st pass

nice -n +19 find /home/username/public_html/wp-content/cache/supercache/* -type f -mmin +60 -delete

2nd pass

nice -n +19 find /home/username/public_html/wp-content/cache/supercache/* -type d -empty -delete

I think that should work nicely.

Okay I have an easy idea for pure speed without php, at least for linux hosted wordpress:

nice +19 find /home/username/public_html/wp-content/cache/supercache/* -mmin +60 -delete

fast cache delete by age, directly from linux, it’s perfect for running in cron (hence me adding the nice +19 in the front so apache and php get higher priority)

You can test that line by first carefully removing the the -delete from the end to see which files it comes up with (obviously modify the directory too)

By skipping the file type, it will include directories as well as it’s children, which I believe is the behavior we want?

The +60 is obviously minutes which is adjustable

Simple is nice and that’s a good quick workaround but PHP is notoriously bad at file handling and reading filemtime, etc. compared to working closer to the OS.

https://ckon.wordpress.com/2008/09/16/filemtime-the-performance-killer/

Ironically you commented on my post there three years ago so I guess we’ve come full circle ??

So once I have your idea in place I will probably try to do something more native.

I guess I should set the WPSC scheduler to a very high number to disable it.

I am still not quite sure why I see WPSC trying to comb through all files and prune the cache the moment an editor goes into posts->add new regardless of the scheduler setting – I am missing something in the code somewhere but getting more familiar with it.