Title: _ck_'s Replies | WordPress.org --- # _ck_ [ ](https://wordpress.org/support/users/_ck_/) * [Profile](https://wordpress.org/support/users/_ck_/) * [Topics Started](https://wordpress.org/support/users/_ck_/topics/) * [Replies Created](https://wordpress.org/support/users/_ck_/replies/) * [Reviews Written](https://wordpress.org/support/users/_ck_/reviews/) * [Topics Replied To](https://wordpress.org/support/users/_ck_/replied-to/) * [Engagements](https://wordpress.org/support/users/_ck_/engagements/) * [Favorites](https://wordpress.org/support/users/_ck_/favorites/) Search replies: ## Forum Replies Created Viewing 15 replies - 1 through 15 (of 79 total) 1 [2](https://wordpress.org/support/users/_ck_/replies/page/2/?output_format=md) [3](https://wordpress.org/support/users/_ck_/replies/page/3/?output_format=md) [4](https://wordpress.org/support/users/_ck_/replies/page/4/?output_format=md) [5](https://wordpress.org/support/users/_ck_/replies/page/5/?output_format=md) [6](https://wordpress.org/support/users/_ck_/replies/page/6/?output_format=md) [→](https://wordpress.org/support/users/_ck_/replies/page/2/?output_format=md) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Contact Form 7] beforeSubmit: ajax-loader visibility: visible ?](https://wordpress.org/support/topic/beforesubmit-ajax-loader-visibility-visible/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [10 years, 10 months ago](https://wordpress.org/support/topic/beforesubmit-ajax-loader-visibility-visible/#post-6474914) * It is not the theme, the STYLE=”” is direct applied on the element * apparently beforesubmit is being fired on document ready * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] difficult problem with double "Content-Encoding: gzip" "Content-Encoding: gzip"](https://wordpress.org/support/topic/difficult-problem-with-double-content-encoding-gzip-content-encoding-gzip/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [11 years, 5 months ago](https://wordpress.org/support/topic/difficult-problem-with-double-content-encoding-gzip-content-encoding-gzip/#post-5665844) * 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. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] strange behavior under 3.6.1 multisite](https://wordpress.org/support/topic/strange-behavior-under-36-multisite/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [12 years, 9 months ago](https://wordpress.org/support/topic/strange-behavior-under-36-multisite/#post-4123798) * Short was between operator’s headset 😀 * Local copy was trunk, server copy was older copy before transition function was created. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WordPress MU Domain Mapping] security issue with allowing users to map their own domains](https://wordpress.org/support/topic/security-issue-with-allowing-users-to-map-their-own-domains/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [12 years, 9 months ago](https://wordpress.org/support/topic/security-issue-with-allowing-users-to-map-their-own-domains/#post-4079448) * 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 * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] suggestion for better https support](https://wordpress.org/support/topic/suggestion-for-better-https-support/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [13 years, 3 months ago](https://wordpress.org/support/topic/suggestion-for-better-https-support/#post-3567527) * 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. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] suggestion for better https support](https://wordpress.org/support/topic/suggestion-for-better-https-support/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [13 years, 3 months ago](https://wordpress.org/support/topic/suggestion-for-better-https-support/#post-3567488) * 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. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] suggestion for better https support](https://wordpress.org/support/topic/suggestion-for-better-https-support/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [13 years, 3 months ago](https://wordpress.org/support/topic/suggestion-for-better-https-support/#post-3567290) * 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. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] RSS feed not getting GC'd](https://wordpress.org/support/topic/rss-feed-not-getting-gcd/) * [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [13 years, 7 months ago](https://wordpress.org/support/topic/rss-feed-not-getting-gcd/#post-3173826) * “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 * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] RSS feed not getting GC'd](https://wordpress.org/support/topic/rss-feed-not-getting-gcd/) * [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [13 years, 7 months ago](https://wordpress.org/support/topic/rss-feed-not-getting-gcd/#post-3173812) * 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. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] [WP Super Cache] Here's how to REFRESH PAGES when a new post is added/deleted](https://wordpress.org/support/topic/wp-super-cache-heres-how-to-refresh-pages-when-a-new-post-is-addeddeleted/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [14 years, 4 months ago](https://wordpress.org/support/topic/wp-super-cache-heres-how-to-refresh-pages-when-a-new-post-is-addeddeleted/#post-2557575) * 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… * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] bug with use of $_SERVER["HTTP_HOST"] instead of SERVER_NAME](https://wordpress.org/support/topic/plugin-wp-super-cache-minor-bug-with-use-of-_serverhttp_host-instead-of-_serverserver_name/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [14 years, 4 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-minor-bug-with-use-of-_serverhttp_host-instead-of-_serverserver_name/#post-2556958) * 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. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] [Plugin: WP Super Cache] found possible bug with starting new post](https://wordpress.org/support/topic/plugin-wp-super-cache-found-possible-bug-with-starting-new-post/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [14 years, 5 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-found-possible-bug-with-starting-new-post/#post-2468482) * I have now tested this with changing `=='draft'` to `!='publish'` and it works perfectly. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] [Plugin: WP Super Cache] Improving prune_super_cache to work in background with real cron](https://wordpress.org/support/topic/plugin-wp-super-cache-improving-prune_super_cache-to-work-in-background-with-real-cron/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [14 years, 6 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-improving-prune_super_cache-to-work-in-background-with-real-cron/#post-2452643) * 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. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] [Plugin: WP Super Cache] Improving prune_super_cache to work in background with real cron](https://wordpress.org/support/topic/plugin-wp-super-cache-improving-prune_super_cache-to-work-in-background-with-real-cron/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [14 years, 6 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-improving-prune_super_cache-to-work-in-background-with-real-cron/#post-2452627) * 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 * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] [Plugin: WP Super Cache] Improving prune_super_cache to work in background with real cron](https://wordpress.org/support/topic/plugin-wp-super-cache-improving-prune_super_cache-to-work-in-background-with-real-cron/) * Thread Starter [_ck_](https://wordpress.org/support/users/_ck_/) * (@_ck_) * [14 years, 6 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-improving-prune_super_cache-to-work-in-background-with-real-cron/#post-2452605) * 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. * [http://ckon.wordpress.com/2008/09/16/filemtime-the-performance-killer/](http://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. Viewing 15 replies - 1 through 15 (of 79 total) 1 [2](https://wordpress.org/support/users/_ck_/replies/page/2/?output_format=md) [3](https://wordpress.org/support/users/_ck_/replies/page/3/?output_format=md) [4](https://wordpress.org/support/users/_ck_/replies/page/4/?output_format=md) [5](https://wordpress.org/support/users/_ck_/replies/page/5/?output_format=md) [6](https://wordpress.org/support/users/_ck_/replies/page/6/?output_format=md) [→](https://wordpress.org/support/users/_ck_/replies/page/2/?output_format=md)