Joel Bernerman

This fixes it but I’m not sure if it is the best approach.
Would it hurt the performace?
Its pretty edge case so it would probably not be done that often.

public function get_fly_dir( $path = '' ) {
  if ( empty($this->_fly_dir) || ( function_exists('ms_is_switched') && ms_is_switched() ) ) {
    $wp_upload_dir = wp_upload_dir();
    return $wp_upload_dir['basedir'] . DIRECTORY_SEPARATOR . 'fly-images' . ( '' !== $path ? DIRECTORY_SEPARATOR . $path : '' );
  } else {
    return $this->_fly_dir . ( '' !== $path ? DIRECTORY_SEPARATOR . $path : '' );
  }
}

I have done some debugging.

The problem is appearing when updating and creating a custom post with “‘rewrite’ => false,”

WP Super cache function “prune_super_cache” will get a call with the parameter $directory pointing att the cache root dir.
This will start a recursive delete off all cache present and this is really time consuming.

Below is the result of a “trigger_error($directory);” in wp-cache-phase2.php on line 703 when updating a custom post registered as my previous post declares.

PHP Notice:  C:\vagrant\se-dev-environment\webroot/wp-content/cache/supercache/wp.local/ in C:\vagrant\se-dev-environment\webroot\wp-content\plugins\wp-super-cache\wp-cache-phase2.php on line 703
PHP Stack trace:
PHP   1. {main}() C:\vagrant\se-dev-environment\webroot\wp-admin\post.php:0
PHP   2. edit_post() C:\vagrant\se-dev-environment\webroot\wp-admin\post.php:229
PHP   3. wp_update_post() C:\vagrant\se-dev-environment\webroot\wp-admin\includes\post.php:321
PHP   4. wp_insert_post() C:\vagrant\se-dev-environment\webroot\wp-includes\post.php:3572
PHP   5. clean_post_cache() C:\vagrant\se-dev-environment\webroot\wp-includes\post.php:3408
PHP   6. do_action() C:\vagrant\se-dev-environment\webroot\wp-includes\post.php:5470
PHP   7. call_user_func_array:{C:\vagrant\se-dev-environment\webroot\wp-includes\plugin.php:496}() C:\vagrant\se-dev-environment\webroot\wp-includes\plugin.php:496
PHP   8. wp_cache_post_edit() C:\vagrant\se-dev-environment\webroot\wp-includes\plugin.php:496
PHP   9. wp_cache_post_change() C:\vagrant\se-dev-environment\webroot\wp-content\plugins\wp-super-cache\wp-cache-phase2.php:1065
PHP  10. wp_cache_post_id_gc() C:\vagrant\se-dev-environment\webroot\wp-content\plugins\wp-super-cache\wp-cache-phase2.php:1139
PHP  11. prune_super_cache() C:\vagrant\se-dev-environment\webroot\wp-content\plugins\wp-super-cache\wp-cache-phase2.php:1083
PHP  12. trigger_error() C:\vagrant\se-dev-environment\webroot\wp-content\plugins\wp-super-cache\wp-cache-phase2.php:703

The “problem” is located in the function “get_current_url_supercache_dir” in wp-cache-phase1.php

The permalink that the post will get when using “rewrite => false” is for ex.
“http://wp.local/?post_type=magazine&p=2991”

This will get the uri “/?post_type=magazine&p=2991” on line 585 in wp-cache-phase1.php

It will not survive the regexes that follows on line 585-587 and the uri will end up as “/”.

Hence it will try to empty all cache recusively from the root in the function “prune_super_cache” later on.

My suggestion would be to totally exclude posts from caching and purging when rewrite is specifically set to false using “get_post_types(array(‘rewrite’ => false, ‘_builtin’ => false))” to find what to exclude.
Also their permalink structure would probably totally fail when using the “rewrite”-metod of serving cache.

I cant se any use of these kind of custom post types other than private and therefore they are probably conseptually and practically not suitable for caching.

But this is an issue you devs have to decide what to do about 🙂

Regards

Cool, I am trying to rule out some problems in connectivity I have had with a customer.
I think I can safely say BruteProtect is not a problem if th ip in the db only for one hour.

Who reads instructions 😉
I missed that one and I do recall add/update_option does remove backslashes in some kind of input cleaning aptempt(Think i solved it by adding an extra backslash when I fetch the options before i present it to the user… but anyhow.).

Well yes it got encoded but the plugin didnt quite understand it and delivered an error and the file didnt end up inside the media library.
I did however see the encoded video inside the upload directory.

I think the code does not take into account that Windows adds an extra char(carriage return and line feed) at line breaks and because of this the $lastline varible is always empty and this renders an error as it doesnt find the strings “libx264 ” or “video:”

I had to change the “$lines = 2;” to “$lines = 4;” in the below part of the code in video-embed-thumbnail-generator.php line 2941 – 2955.
(In the latest stable, didnt try any trunk or dev versions.)

$fp = fopen($logfile, 'r');
$c = '';
$read = '';
$offset = -1;
$lines = 2;
while ( $lines && fseek($fp, $offset, SEEK_END) >= 0 ) {
  $c = fgetc($fp);
  if( $c == "\n" || $c == "\r" ) {
    $lines--;
  }
  $read .= $c;
  $offset--;
}
fclose($fp);
$lastline = strrev(rtrim($read,"\n\r"));

This is not a good cross-platform solution as it will skip some extra lines in Unix systems but I just tried to se if anything else bugged.

After this “fix” I got no error and the encoded file(mp4) inside the media library but I could still not insert that file using “Insert into Post”.

Maybee this is not an issue with this plugin but just some kind of error with my .htaccess settigns to allow it.

We use ubuntu servers on our external sites but this plugin was going into our intranet and it is sadly using a windows server.

I cant spend any more time bugsearching this for now but at least this might help you do some kind of fix for windows servers.