erwinbr

I updated your plugin and so far, no more problems. Thanks.

Fine, that you are looking into this.

I forgot to mention that while looking into the problem, I also ran your code through the static checker of my IDE and found that the class Module in wp-content/plugins/press-permit-core/vendor/publishpress/wordpress-version-notices/src/Module/Footer/Module.php does not seem to implement the interface AdInterface as it should. This will give a fatal error as well when loaded.

I updated your plugin and the notices are gone. Thanks a lot!

Thanks for your response,

I did some further digging and found that it only occurs if I use a persistent object cache (or more specifically, I am using Docket Cache as I am working on a site whose hoster does not offer memcached, apcu or Redis). Apparently, the values of the options as stored in the cache get unserialized while still being linked/referenced to the cache or are stored before being serialized or something like that.

However, it also looks like your plugin doubly serializes its options (in the plugin itself and in add/update_option()) which seems unnecessary as well. So I think that changing unserialize() to maybe_unserialize() solves the problem. (You could then even remove the calls to serialize() in your own code and not have to write an db update function.)

I hope this helps,

Oh, I now see that unserialize() returns false if the passed string cannot be unserialized (instead of just returning the value). This means that this is now a real error and no longer a warning: all option values are changed into false and thus settings being ignored with lots of

Trying to access array offset on value of type bool

notices.

Thanks for correcting it. Marking as resolved.

This problem has now been solved in https://github.com/splitbrain/php-archive and is part of the new release 1.2.1. I hope you can update your project soon to include that version.

Thanks for this plugin.

Error is probably due to fopen() not working onfolders on Windows, I got the same error on adding wp-admin (folder) to the archive: I logged an issue on https:/ /github.com/splitbrain/php-archive.

I also reported this error at https://github.com/splitbrain/php-archive where it should be solved. If they don’t, you could solve it at a higher level in your own code, but that’s not what we should do.

I’m joining in on this issue as I do think there’s also a change you can make in your code. As the original post states there are 2 redirects:

1. 301: from ..media?size=t to …media/?size=t
2. 302: from …media/?size=t to https://scontent-….cdninstagram.com/…

The latter, the 302, cannot be prevented, but the former, the 301 (permanently moved), can be prevented by changing the code to render URLs like …media/?size=t instead of …media?size=t. So I hope you will change this for the next version.

Forget the above change, That didn’t do the whole trick. It turns out that folders do not have to be added to a tar archive anyway, you just add files with a relative path and on viewing it in a GUI or extracting it, those sub folders will be shown/created automatically.

Thus just add:

if ($file['type'] !== 'dir) {
  ...
}

around calls to addFile(), both in includes/class-xcloner-archive.php, method add_file_to_archive(); and in includes/class-xcloner-api.php, method download_restore_script() (the call within the foreach).

I did a quick test by replacing the call to addfile() in wp-content/plugins/xcloner-backup-and-restore/includes/class-xcloner-archive.php, method add_file_to_archive() with this code:

if ($bytes_wrote !== 0) {
  $this->backup_archive->addFile(
    $start_adapter->applyPathPrefix( $file_info['path'] ),
    $file_info['target_path']
  );
} else {
  $this->backup_archive->addData(
    $file_info['target_path'],
    ''
  );
}

And this works for me, and looks like a way to prevent some (unnecessary?) file IO for all folders and empty files in the backup.

Thanks for your quick response.

– I tested fopen() with several folders around my drive and all fail with the same message.
– If I adjust the backup to only include wp-content, it fails on that, or, it fails on the first folder it tries to add.
– If I adjust the PHP version to 5.6.40, it also fails.

So, it almost seems like this plugin (and the tar archive library) will not work with Windows, but given its widespread use and lack of reports about that, this is also hard to believe. So perhaps the php builds I use are giving the problems??? I use WampServer 3.2.2.2 X64 on Windows 10 X64 (build 18362)

Thanks!