Plugin update failed

Beaver Builder
21

[Content Hidden]

22

Hey David,

I just got caught up on this thread and am jumping in to lend a hand. Looking at the error (I got the same one when trying on your site) it does appear to be some sort of permissions or disk space issue.

I had a look at your site via FTP and all of your files and folders have permissions set to 777 which is not only really insecure but can cause issues of its own. Is it ok if I change everything to the standard 755?

Also, where are you hosting?

Let me know.

Justin

23

[Content Hidden]

24

Hey David,

Ah, I didn’t realize that it was a Windows server. Is 777 still “safe” on a Windows server?

Unfortunately, it does look like there is an issue with the server somewhere. WordPress is successfully receiving the zip file from us at which point the update fails when WordPress tries to unzip it.

I tried a number of times and it appears to be failing on different files, so that tells me that something is happening during the unzipping process. We’re using a standard UNIX command to build the zip files during our export process so I don’t think we’re doing anything wrong there.

I hate to say it, but at that this point I’m a bit stumped. If anything else comes up that you think might be useful in solving this, let me know and I’ll have a look. Sorry I don’t have an answer at this time.

Justin

25

Hi Justin,

777 has no meaning on Windows and it is not possible to adjust file permissions via FTP on a Windows server.

I will keep looking into this to see if I can work it out, but in the meantime I can update via FTP.

Would you be able to send me a copy of version 1.6.4.7 so that I can continue testing?

Thanks!

26

Hi Justin,

I have just got round to looking into this again and am doing some testing. I have a few questions:

  • Are the existing plugin files deleted from wp-content/plugins before the new plugin files are moved there?
  • When the ZIP file is fetched from your server what directory is it saved into?
  • Also when WordPress tries to unzip it where is it trying to unzip it into?

In order to test WordPress’s unpacking process on the Beaver Builder ZIP file I have run the following code which is based upon WordPress’s WP_Upgrader::unpack_package method:

require_once(untrailingslashit(ABSPATH) .'\wp-admin\includes\file.php'); //the cheat

WP_Filesystem();
	
function mike_unpack_package( $package, $delete_package = true ) {
    global $wp_filesystem;
 
    //$this->skin->feedback('unpack_package');
 
    $upgrade_folder = $wp_filesystem->wp_content_dir() . 'upgrade/';
 
    //Clean up contents of upgrade directory beforehand.
    $upgrade_files = $wp_filesystem->dirlist($upgrade_folder);
    if ( !empty($upgrade_files) ) {
        foreach ( $upgrade_files as $file )
            $wp_filesystem->delete($upgrade_folder . $file['name'], true);
    }
 
    // We need a working directory - Strip off any .tmp or .zip suffixes
    $working_dir = $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' );
 
    // Clean up working directory
    if ( $wp_filesystem->is_dir($working_dir) )
        $wp_filesystem->delete($working_dir, true);
 
    // Unzip package to working directory
    $result = unzip_file( $package, $working_dir );
	
    var_dump($result);
 
    // Once extracted, delete the package if required.
    if ( $delete_package )
        unlink($package);
 
    if ( is_wp_error($result) ) {
        $wp_filesystem->delete($working_dir, true);
        if ( 'incompatible_archive' == $result->get_error_code() ) {
            return new WP_Error( 'incompatible_archive', $this->strings['incompatible_archive'], $result->get_error_data() );
        }
        return $result;
    }
 
    return $working_dir;
}

mike_unpack_package( untrailingslashit(ABSPATH) . '\wp-content\miketemp\bb-plugin-standard.zip', false);

This extraction is successful with no errors and the var_dump($result) returns true. This test extraction is taking place in the same wp-content directory where the automatic update fails.

Thanks,
Michael.

27

Hi David,

Thanks for the follow up.

Are the existing plugin files deleted from wp-content/plugins before the new plugin files are moved there?
When the ZIP file is fetched from your server what directory is it saved into?
Also when WordPress tries to unzip it where is it trying to unzip it into?

Unfortunately, I don’t know the answer to these questions as WordPress core handles all of that. We’re not doing anything special in the upgrade process, we’re just passing WordPress the download link in the pre_set_site_transient_update_plugins filter. Sorry I can’t be of much help there.

Justin

28

Hi,

As per my message before last to which I didn’t get a reply can you please provide me with the ZIP of the previous version of Beaver Builder before the current one so I can try and work out the problem?

Thanks,
Michael.

29

[Content Hidden]

30

Thanks Justin

31

I have finally got to the bottom of this issue. It is caused during the unzipping process when an absolute file path exceeds the ~255 characters allowed on Windows.

Most of the the characters in the file path are being taken up by the name of the temporary directory created during the unzip process as the name of the directory is taken from the URL from which the ZIP file was retrieved.

See my post here https://core.trac.wordpress.org/ticket/33053#comment:6 for more details.

32

Hey David,

Thanks for the heads up on what the issue was! Hopefully they can get that fixed soon.

Justin