biberkopf

I have just experienced the same: one of two jobs was set to execute at 1/1/1970 02:00 (WP-Cron) in the jobs lists.

When I clicked edit to checkt the settings in the schedule tab it was correctly set to next Friday. So I presume the script would have run correctly and that the wrong date in the list was merely a glitch.

I tried to change the time and also toggle back and forth between wp-cron and manual in the schedule tab, saving a couple of times in the process.

This seemed to solve the problem. Not sure if it was the time change or the mode change that did the trick.

(There were some ftp-deletion of a big subfolder going on in the background while all this was taking place. Perhaps this activity could also have confused the script, since I have asked BackWPup to “display folder sizes on Files tab if job is edited”.)

Sorry, I didn’t notice the wp_snippets table. I only have one record in there. It was just a php script for testing image load errors from the development fase. Now that I know, I can safely reinstall. And I did and now I can get to the manage interface.

Not sure if it has any bearings for you, but here’s a few other observation I did in the process.

I did see a Code Snippets Import menu. I could see that an xml-file was needed for import. However, I did not find any export menu, until after I reinstalled, which lead me to believe the export process was parallel to the tools->import-process. Perhaps the import button really belongs with the export button in the manage GUI – for consistency?

Thanx a lot for your fast response. Although I don’t use the plugin right now, I really think it’s a superb tool and I’ll use it as soon as I get a chance.

That’s the spirit, Justin!
Wish I had the skills. I’m not yet a WPeC-user, still on the fence, but I’m really thankful somebody like you is putting time and energy into open source projects like this. Thanks a lot!

@oblax No, I’m affraid I can’t fix that. But for somebody who knows his or her php or javascript I believe it shouldn’t be to hard. If you name your files 1.mp3, 2.mp3, 3.mp3 […], n.mp3 all you have to do is to make a random logic that that pics a number between 1 and n, and insert it as the filename. But it’s not really a wpaudio question. So perhaps you can find som shortcode that will do it for you.

@euaugustine Good point. I haven’t had the problem myself. I wonder why???

I’m not sure I fully understand your problem. But are you aware that Gmail’s smtp-server is forcefully changing the sender id to your gmail account. If for example, you try to send a mail from let’s say [email protected] through you personal smtp.gmail.com using your gmail account, e.g. [email protected], you might have expected that you mail got through to the receiver with [email protected] as the sender id.

But apparently Google rewrites the sender ID in the process so that it match the authenticated gmail account.

I’m not sure if this is related. But it’s just a thought.
Perhaps this might help you, too:

https://www.askdavetaylor.com/configure_google_gmail_to_have_a_different_sender.html

Further to my test report:

I tested a full backup with FTP. This worked great:

2011-03-21 14:49.50: Backup Archive File size is 69.42 MB
2011-03-21 14:49.50: Job done in 220 sec.

Perhaps you need to return some error message to the logging if the setup is wrong. Initially, my process stalled because I had added a “/” to the directory path in the FTP setup.

And now we are talking ‘Embesserungen’:

It would be helpful if the Dropbox setting box for each backup would show which Dropbox username/email is being used. (Especially useful, if you’re returning to the menu after some time.)

And what would be really cool would be a direct download link to the latest backup file. If the Dropbox API allows. Maybe then a very userfriendly restore function is just around the corner! ??

Hi Daniel:

Nice work so far. Thanx for the update. Just want to add my experience to the debugging:

Everything goes seems to go well until the zipped backupfiles is being to be moved to dropbox

My log looks like this:

2011-03-21 13:51.48: Run Database Dump to file…
2011-03-21 13:51.48: Dump Database table: wp_commentmeta
2011-03-21 13:51.48: Dump Database table: wp_comments
2011-03-21 13:51.48: Dump Database table: wp_easymail_sendings
2011-03-21 13:51.48: Dump Database table: wp_easymail_subscribers
2011-03-21 13:51.48: Dump Database table: wp_easymail_trackings
2011-03-21 13:51.48: Dump Database table: wp_links
2011-03-21 13:51.48: Dump Database table: wp_ngg_album
2011-03-21 13:51.48: Dump Database table: wp_ngg_gallery
2011-03-21 13:51.48: Dump Database table: wp_ngg_pictures
2011-03-21 13:51.48: Dump Database table: wp_options
2011-03-21 13:51.48: Dump Database table: wp_postmeta
2011-03-21 13:51.48: Dump Database table: wp_posts
2011-03-21 13:51.48: Dump Database table: wp_term_relationships
2011-03-21 13:51.48: Dump Database table: wp_term_taxonomy
2011-03-21 13:51.48: Dump Database table: wp_terms
2011-03-21 13:51.48: Dump Database table: wp_usermeta
2011-03-21 13:51.48: Dump Database table: wp_users
2011-03-21 13:51.48: Database Dump done!
2011-03-21 13:51.48: Add Database Dump to Backup: <username>_wrd5.sql 1.07 MB
2011-03-21 13:51.48: Make a list of files to Backup ….
2011-03-21 13:51.48: Files to Backup: 2594
2011-03-21 13:51.48: Size of all Files: 87.11 MB
2011-03-21 13:51.48: Create Backup Zip file…
2011-03-21 13:52.15: Backup Zip file create done!
2011-03-21 13:52.15: Authed to DropBox from jesper s?holm
2011-03-21 13:52.15: Free Space on DropBox: 1.91 GB

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 72786751 bytes) in /home/<user>/public_html/<domainfolder>/wp-content/plugins/backwpup/app/libs/dropbox.php on line 425

Line 425 is this:
$content .= file_get_contents($filePath);

The problem shouldn’t be the memory size as the allowed momory size seems to exceeds the memory need.

Afterwards I did another test. I only backup’ed my Atahualpa theme folder + the DBs. This resulted in a succesful backup of only 1.19 MB:

2011-03-21 14:14.12: Free Space on DropBox: 1.91 GB
2011-03-21 14:14.15: Backup File transferred to DropBox.
2011-03-21 14:14.15: Backup Archive File size is 1.19 MB
2011-03-21 14:14.15: Job done in 5 sec.

Could it be a php time out error that interrupts the file transfer to dropbox. At least I got the “fatal error” way before php would have been able to finish the file transfer to Dropbox I think. (Although a server to server file transfer might be much faster than what I expect for a 90 MB file transfer. :-] )

Anyway, hope this might help a little.

I have just discovered BackWPup a fortnight ago and it’s everything I have longed for! GREAT plug-in, Daniel! Thanks a lot so far.
It has been running smoothly ever since – until today when I installed it on another wp-installation with exactly the same default configuration (saving to my dropbox). Suddenly, I get the same error message as above on both WP-installations. (Both running WP3.1 and latest atahualpa theme).
Oddly enough, the first installation ran a succesful daily scheduled backup at 10.42.17 GMT+1. (≈ 4 hours ago).
The failed schedules were all forced from the panel by clicking the “Run now” button. Both are on the same IP-no, but different domains.
Hope this will help clarify.

Thank you, Andrea.
That’s very useful info from the real experience.
I’ll take that into account.

Thanx for all the feedback. This is what I suspected. I don’t have much experience as a superadmin, but I suspect that one might easily be spammed by students that have various wishes for specific themes and plugins in a Multisite installation. One idea for a solution for the future could be, that the admins could search, download, and install plugins/themes through in the normal manner, but the final installation would await the approval/disapproval of the superadmin. A bit like the approval of a comment. That would make the daily life easier for the superadmin, I guess.

PS: Sorry for all the sloppy typos in my initial posting.