Stormykeith

Hi Damian,

Have retried the plugin today and am pleased that it worked fine for me now so changed rating to 5 star rating

Regards
Keith

Hi Damian,

Thanks for the prompt response.

Hi Stormykeith, you should open a support topic instead of leaving a bad review to get support. It’s a bit unethical

Apologies if I caused any unintended offence. I’m not sure I agree with your comments. I certainly wasn’t looking to use it to prompt a support response. Thought the whole purpose of the rating system was to evaluate the product and rate it accordingly. Don’t really see how I could have rated it any differently. I explained clearly what my issue was. In all honesty, it was such a fundamental issue. As a developer, I personally would do at least a sanity check to spot this type of error prior to any new WP release.

Anyway, glad to hear it’s fixed. Will change rating once I’ve had chance to use it.

Regards
Keith

Hi David,

Apologies for the long gap in response.

Just wanted to let you know that this is now working fine.

Many thanks for all your help. It is much appreciated.

Regards
Keith

Hi David,

Have added line to wp-config but still get same result as above. Hopefully the PHP error in line 0017.902 will tell you where the issue is.

Can happily restore manually so I know it’s not a major issue.

Thanks for your help though. It’s much appreciated.

Regards
Keith

Hi David,

Get same error with development version. Log file below.

0000.075 () Opened log file at time: Sat, 14 Dec 2013 22:34:03 +0000
0000.076 () UpdraftPlus WordPress backup plugin (https://updraftplus.com): 1.8.2 WP: 3.8 PHP: 5.4.22 (Windows NT AFLAPTOP 6.1 build 7601 (Windows 7 Business Edition Service Pack 1) i586) MySQL: 5.5.32 Server: Apache safe_mode: 0 max_execution_time: 900 memory_limit: 256M (used: 11.7M | 12M) multisite: N mcrypt: Y ZipArchive::addFile: Y
0000.077 () Free space on disk containing Updraft's temporary directory: 152968.8 Mb
0000.077 () Restore job started. Entities to restore:
0000.148 () Entity: db
0000.148 () Unpacking backup...
0000.154 () Restoring the database (on a large site this can take a long time - if it times out (which can happen if your web hosting company has configured your hosting to limit resources) then you should use a different method, such as phpMyAdmin)...
0000.173 () Tried to raise max_allowed_packet from 16 Mb to 32 Mb, but failed (Access denied; you need (at least one of) the SUPER privilege(s) for this operation, b:0;)
0000.173 () Max packet size: 16 Mb
0000.174 () <strong>Backup of:</strong> https://localhost/wordpresstest
0000.175 () Content URL: https://localhost/wordpresstest/wp-content
0000.175 () Old table prefix: wp_
0000.175 () Site information: multisite=0
0000.178 () New table prefix: wp_
0000.232 () Restoring table (InnoDB): wp_options
0000.526 () Restoring table (InnoDB): wp_users
0000.680 () Restoring table (InnoDB): wp_usermeta
0000.830 () Restoring table (InnoDB): wp_commentmeta
0000.951 () Restoring table (InnoDB): wp_comments
0001.099 () Restoring table (InnoDB): wp_links
0001.286 () Restoring table (InnoDB): wp_postmeta
0001.635 () Restoring table (InnoDB): wp_posts
0002.290 () Restoring table (InnoDB): wp_term_relationships
0002.704 () Restoring table (InnoDB): wp_term_taxonomy
0002.903 () Restoring table (InnoDB): wp_terms
0003.081 () Finished: lines processed: 39 in 2.91 seconds
0003.083 () Cleaning up rubbish...
0003.094 () Entity: others
0003.094 () Unpacking backup...
0003.490 () Cleaning up rubbish...
0003.491 () Entity: plugins
0003.492 () Unpacking backup...
0013.536 () Moving old data: filesystem method / updraft_dir is potentially possible
0013.537 () Moving old data: can potentially use wp_filesystem method / -old
0013.537 () Moving old data out of the way...
0016.363 () Moving unpacked backup into place...
0017.902 () PHP event: code E_WARNING: copy(): The first argument to copy() function cannot be a directory (line 217, C:\Program Files\BitNami WAMP Stack\apps\wordpresstest\htdocs\wp-admin\includes\class-wp-filesystem-direct.php)
0017.908 () Error message: Could not move the files into place. Check your file permissions.
0017.908 () Error data: C:/Program Files/BitNami WAMP Stack/apps/wordpresstest/htdocs/wp-content/upgrade/f8afeeb4/plugins/jetpack -> C:/Program Files/BitNami WAMP Stack/apps/wordpresstest/htdocs/wp-content/plugins/jetpack
0017.908 () Restore failed...
0017.908 () Error message: Could not move the files into place. Check your file permissions.
0017.908 () Error data: C:/Program Files/BitNami WAMP Stack/apps/wordpresstest/htdocs/wp-content/upgrade/f8afeeb4/plugins/jetpack -> C:/Program Files/BitNami WAMP Stack/apps/wordpresstest/htdocs/wp-content/plugins/jetpack
0017.908 () Restore failed

Will try adding line to wp-config.php and get back to you.

Regards
Keith

Hi David,

Thanks very much for your assistance. It is much appreciated.

However I’ve deleted and reinstalled the plugin buta am now getting a different error. I get this even when the blog name is only 4 characters long.

Plugins

Unpacking backup...
Moving old data out of the way...
Moving unpacked backup into place...
Error message: Could not move the files into place. Check your file permissions.
Restore failed...

There was also nothing in the plugins-old directory so my plugins have also disappeared (no problem – just restored them manually)

Any ideas?

Regard
Keith

I’ve just being doing some further testing:

I reduced the length of the Blog Title size gradually and at 5 characters long, UD actually deleted several plugins which I easily solved by re-downloading (plugin settings still remained from previous install).

Seems ok when Title is <5 chars
In summary, when Blog Title is
>5 characters – backs up but won’t restore
5 characters – kills plugins and have to re upload plugins
<4 – backs up and restores OK

Not a lot of room for movement on Blog Title though :).

A few other things:
1) Can’t find a log of the restore activity (ie like the one it prints to the screen). Does one exist and if so where is it located?
2) Prior to backup, on a one-time backup, what does ‘Don’t send this backup to cloud storage’ do if you are backing up via FTP? (Presumably not applicable to me)

Regards
Keith

Hi David,

Once again thanks for the prompt reply.

You were right!!! It seems to pick up part of the file name from the Blog Title. Originally, my blog title was

Keith's WP Lucid Theme Test Blog

which created a backup file name of

backup_2013-12-12-1743_Keith039s_WP_Lucid_Theme_Test_871a9f7b27f2-others.zip

I renamed the blog to just “Test” creating a backup file of

backup_2013-12-14-1123_Test_97ded036cca6-others.zip

When I did this, the restore worked fine.

So we now know what is the cause, but not sure how to overcome it.

The first bit of the backup filename is the date/time, 2nd bit is my Blog name, I assume the 3rd bit is the UD backupid and the 4th bit is the entity type. Can’t see how I can effect anything but the blog name and I can’t keep calling them “Test”!!!

There are a few things that come to mind:
1) Do I actually need this long directory name? ie I’m not backing up to the cloud. However I suspect that UD is utilising some form of cloud based storage during the process and I suspect using the directory as a form of tracking?

2) What would overcome it is if you were able to define the backupset name via the control panel. You could then put a limit on the length of this (so directory name can’t be over x characters). It would also be a more user friendly way of identifying backup sets on the server and may even be a way of utilising the ‘backupset name’ to identify different types of backup

3) Would it be easier to change the code to just save it to a directory nearer the root or simply change the file/directory names to take up less characters?

Obviously you will know better than I what is easiest/best solution.

Anyway, as (in this particular case) it’s only a test environment I can work round it for the time being (on the assumption that it won’t be an issue in a live, Linux hosted environment)

Thanks very much for your help.

Let me know if you have any suggestions in the meanwhile or how you intend to resolve the issue.

Regards
Keith

Hi David,

Thanks for your prompt response. I did what you said:

1) I downloaded a random plugin (Social Exchange)
2) I created a directory structure similar to the length of the path that Updraft appears to want to write to. Based on the error message in the logs the directory it’s trying to create is:

C:\Program Files\BitNami WAMP Stack\apps\wordpressfoxy\htdocs\wp-content\plugins\updraftplus\opencloud\rackspace\php-opencloud\lib\OpenCloud\CloudMonitoring\Exception

3) I extracted the Social Exchange plugin to

C:\Program Files\BitNami WAMP Stack\apps\wordpressfoxy\htdocs\wp-content\plugins\updraftplus\opencloud\rackspace\php-opencloud\lib\OpenCloud\CloudMonitoring\Exception\SocialExchange

which actually created 2 directories below that (…social-exchange-plugin\css

4) I then zipped it up from this new directory structure

5) I installed plugin from the newly created zip and it worked fine

This seems to indicate that it isn’t a limit on number of characters in my system (never, ever had an issue with this). My research shows that maximum path length is 260 on windows but this path is only 170+ so nowhere near it.

I also tried manually creating the above path (so updraft perhaps didn’t need to then create it) but this did’t work (ie I created it fine but still got same error on restore).

Any other ideas?

Regards
Keith