sephage

I should note that it’s the same provider with the same (as far as I am ware, anyway) caching that I have been using since I started using WP SlimStat a year ago, so there have not been any previous conflicts.

Hi – no, no caching plugins. HOwever, the host is ZippyKid, they might be doing some caching but if so I’ve no way of modifying that.

Yes, still several hours off. Events are firing okay, it’s just reporting the time incorrectly.

Thanks!

Same here, after update it published a future post (July 30) now causing me all kinds of headaches. Deactivated for now.

I’m reverting back to 2.8.7 for now, as the testing version that you sent to me only works with Java OFF, and even then it seems to be lagging Google Analytics (previously, it was the other way around, actually). Will try out 2.9.1 when I get a chance.

Camu – thanks, just sent it to you.

OK, lowering that threshold isn’t working now even for manual scans. It hangs at about 475 mob into the malware portion of the scan ??

Will do. It does hang at b the same place, when scanning for malware.

I know this is marked as resolved, but it’s actually not since the plugins SQL portion of this never finishes :).

In fact, I’ve seen another 400 error today on the plugins SQL file upload to dropbox, as the file was still being created at the time of upload. From what I can discern, the plugins SQL is actually still (9 hours later!) creating a temporary file of the SQL dump on my server… moving veeeeery slowly….!

It might make sense to add some kind of exclude tables feature, as I think that might help determine if there’s a single plugin or table causing the issue, and generally that would make your plugin even more useful if folks wanted to exclude the plugin table data, etc.

Thanks – confirmed that the uploaded SQL dumps are now going into the backups directory. ??

Also confirmed that the plugin is copying an unfinished version of the plugins SQL dump, which is only 1/3 to 1/2 complete at the time it gets sent to Dropbox. ??

Is there any constant/setting I should try to get the plugin to wait for a completed plugins sql dump? I’m running Slimstat and that seems to be the major issue, in that the stats table for that plugin is probably around 90mb. Would increasing the WAIT_TIMEOUT in class-wp-backup-database.php possibly help?

Thanks!

Thanks. Installed and tested. Neither the incorrect naming/dir issue or the incomplete SQL dump issue have been fixed, both ate exhibiting the same behavior as in your previous version.

1) The SQL dumps are still copied from backups dir on the server to wp-content dir on drop box, with “backups” appended to the beginning of the file name.

2) The plugins SQL dump is not complete when copied, so only a partial dump is sent to drop box and then the file is deleted from the server.

Is there any way to isolate the SQL dump code that you use, so I could run it separately as php to test how long the plugin db dump portion needs to execute a full dump? Mine is a bit large, probably over 80 mb, I suspect it’s taking a long time also due to the config at Zippykid which is not at all standard. It’s worth noting that most SQL dumps on ZK don’t work, so yours is already far ahead of the game!

Thanks!

Cool. It’s back to overwriting every file, by the way. That might be a server config thing, I’m on Zippykid and their config breaks all kinds of plugins I’ve found. But the 4 hours it took to copy all the content to drop box gave the sqlmdump plenty of time to complete ?? . In any case, thanks and I’ll be anxiously awaiting the next round of fixes.

Thanks! Were you talking about the naming issue, the copying of the plugins SQL dump, or both? Cheers!

Sorry for the flurry of updates but had a few mins to test it out today, and from what I can see, I’ve no idea why the incorrect naming issue is happening on the SQL dumps, but I can just about confirm that the issues with the plugin SQL dump is due to the fact that the dump gets copied over to drop box before the SQL dump is complete. So, sometimes out copies over an incomplete dump file, sometimes it creates an error instead, but I see based on changing file size via ftp that the dump file is still being written to when the copy to dropbox kicks off. Might need a check on completion of the SQL dump, or some kind of wait period before copying? I hadn’t noticed it before because when it was overwriting files on the drop box side there was plenty of time for the SQL dumps to complete, I think.