Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter orlov0562

    (@orlov0562)

    Забыл сразу написать: СПАСИБО!!! 🙂 Все заработало!

    orlov0562

    (@orlov0562)

    Hello @optimizingmatters,

    Thank you for your reply. I have tested solution with removing LOCK_EX from file_put_contents on line 59 in file
    /wp-content/plugins/autoptimize/classes/autoptimizeCache.php
    and yes, it fixed the problem – the errors doesn’t appears anymore in httpd log and looks like it doesn’t affect to the site stability.

    The only one thing that bothers me, that I understand that this solution removes the logs errors, but two processes can write into file at the same time and that can lead to errors in data.

    The another problem is that I have a few WP sites, so will be very cool if you append some solution from the box to avoid this error. This will help to avoid manual edits in plugin files after plugin updates come. It can be setting “Don’t use cache file exclusive lock” into admin panel or something like this.

    JFYI, first time I faced with this error on slow VPS, so I thought that the problem is coming from there, but a week ago I have made new installation on empty dedicated server with a lot of free CPU and RAM and I have got same error right after google bot come to index three pages of the site.

    Thank you for great plugin and have a nice day!

    Hi there,

    At the beginning want to say thank you to author for great plugin!

    At the second want to sorry that write in this topic, but I think no need to make new one cuz I have the same problem.

    I have also faced with same problem (warning on line 59) on vps and fixed it with next code, that suppress warnings and attempt 10 tries to write to the file with random sleep from 50 to 250 ms if first try failed. Looks like errors have gone.

    this ( autoptimizeCache.php on line 59 ):

    file_put_contents($this->cachedir.$this->filename, $code, LOCK_EX);

    replace with this

    
    $errorlevel = error_reporting();
    error_reporting($errorlevel & ~E_WARNING);
    for ($try=0; $try<10; $try++) {
        if (file_put_contents($this->cachedir.$this->filename, $code, LOCK_EX)) {
            break;
        } else {
            usleep(rand(50, 250));
        }
    }
    error_reporting($errorlevel);
    

    You can also just ignore this warning in next way (without any sleep)

    
    $errorlevel = error_reporting();
    error_reporting($errorlevel & ~E_WARNING);
    file_put_contents($this->cachedir.$this->filename, $code, LOCK_EX);
    error_reporting($errorlevel);
    

    in this case the code just ignore warning that generated by the file_put_contents and keep logs clean

    the another, but not recomended way is to put “@” at the beginning of this function:
    @file_put_contents($this->cachedir.$this->filename, $code, LOCK_EX);

    And the best way, is to replace file_put_contents with class method that will use flock to make sure that code can set lock before made any operations. Something like this:

    
    protected static function write_file($filepath, $content) {
    
        if (!is_writable($filepath)) thrown new Exception('File '.$filepath.' is not writable');
    
        $fp = @fopen($filepath, 'w');
        if (!is_resource($fp)) thrown new Exception('Can\'t open file '.$filepath);
    
        $lock = flock($fp, LOCK_EX)
        if (!$lock) {
            fclose($fp);
            thrown new Exception('Can\'t lock file '.$filepath);
        }
    
        if (fwrite($fp, $content) === FALSE) {
            thrown new Exception('Can\'t write to file '.$filepath);
        }
    
        flock($fp, LOCK_UN);
        fclose($fp);
    
        return true;
    
    }
    

    and then in code

    
    try {
         self::write_file($filepath, $content);
    } catch(Exception $ex) {
        \\ oops something going wrong
        \\ make decision what to do
    }
    

    P.S. This is information for the plugin author. If you user then think twice if you decide to apply this changes manually to the plugin code. At least it is bad idea, cuz all changes will be automatically overwritten after plugin updated.

    JFYI: the discussion of this bug is here: https://core.trac.ww.wp.xz.cn/ticket/29750

    Hi there,

    It’s old error, that happens because this method has not additional check for input variables.

    It’s wp core devs fault.

    You can fix it in next way:
    file: /wp-includes/class-wp-xmlrpc-server.php
    line: ~ 596
    Append type check of $args variable

    
    	public function wp_getUsersBlogs( $args ) {
                    
                    if (!is_array($args)) {
                        return $this->error;
                    }
    
Viewing 5 replies - 1 through 5 (of 5 total)