sephage
Forum Replies Created
-
Forum: Plugins
In reply to: [WordPress Backup to Dropbox] Two issues with latest updateSorry 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.
Forum: Plugins
In reply to: [WordPress Backup to Dropbox] Two issues with latest updateAn update, the plugins SQL dump is not only half the size it should be, but now I’m getting errors that it failed to copy, as if it might still be open?
Error uploading ‘/htdocs/wp-content/backups/XXXXXXXXX-backup-plugins.sql’ to Dropbox: Submitted input out of alignment: got [29360128] expected [26512199] (Status Code: 400)
Forum: Plugins
In reply to: [WordPress Backup to Dropbox] Two issues with latest updateOk, confirmed it’s no longer overwriting everything every time, thanks!
As for the odd issue with the names, that is still happening, and it is happening for the SQL dumps every time now (they get put into the /wp-content dir on Dropbox instead of in the /wp-content/backups dir). Additionally, the SQL dump for the plugins seems quite small to me, about 1/2 the normal size (usually around 73 MB now about 35 mb).
Forum: Plugins
In reply to: [WordPress Backup to Dropbox] Two issues with latest updateNo diff between the file sizes that I can discern, and they’ve not been changed I’m some cases for over a year. In fact, one of the files this is happening with are the SQL dumps created by this plugin, which are in the backups dir on the server but one level up in wp-content on drop box, with “backups” appended to the beginning of the filename.
For #2, thanks, I’ll have to give that a go tomorrow when I’m back in front of a proper PC.
Forum: Plugins
In reply to: [WordPress Backup to Dropbox] Two issues with latest update1) yeah, I know. Some of then files are in a subdir off the top level directory titled audio, and they got put into the root / home directory with “audio” appended to the beginning of the filename instead of being copied to the audio directory on the drop box side. If I had to guess, I’d say that might have something to do with how a dir list got parsed and what characters are used to recognize or write those (e.g., “/”, etc.) But I’ve not taken a gander at the code so that’s only a guess.
2) thanks!
Confirmed FIXED for me. Thanks!
Yes, whatever the most recent update was.
I downloaded downloads.wordpress.org/plugin/wordfence.3.3.7.zip, unzipped and replaced all the files in the wordfence directory with the previous version via FTP (good idea to backup the current wordfence folder, and your database, of course, before making those kinds of changes just in case).
For me, that worked like a charm – back to previous version and running normally.
BTW, rolling back to the previous version, and everything works like a charm from what I can tell, so it’s definitely related to the latest update for me.
I’d be very interested in seeing if the Dev version helps correct this, so anyone trying it please post!
@cldswm – If reverting to 1.0 (I did the same), I’d make sure that you also replace the .htaccess rewrite rules (if using the advanced caching mode) just in case.
All – I can confirm that reverting back to 1.0 resolved this for me at 1WineDude.com (including reverting the .htaccess mod rewrite rules just in case they were different).
Not sure what is going on but I don’t have time to debug it right now so reverting and ignoring updates on WPSC until there’s more time for Donncha to review/test/sort it out.
I’m having exactly the same issue. Seems to have started when I updated WP SUpercache to 1.1. I’ve since reverted to version 1.0 of WP SC, but am still seeing this problem with scheduled posts. This is ONLY on automated builds, the manual rebuilds work just fine. It’s quite odd.
I’m having a similar issue after installing 1.1. I’ve reverted back to 1.0 and will see if that helps.
What happens is that the scheduled post gets created, but the homepage cache isn’t cleared so the new pos isn’t visible on the homepage. For some reason this also causes the rss feed not to update & kills the automation of the site’s XML for google as well.
@cuppyz – try this link:
http://downloads.wordpress.org/plugin/wp-super-cache.1.0.zip
It seems to be working for me after reverting to 1.0, but will need to wait until tomorrow to test it with scheduled posts, due to my schedule. Be aware that you might need to revert the .htaccess code if you’re using mod rewrites (I did that just to be safe). Good luck!
I should note that this affects the feed as well – the RSS feed is not updated either until the cache is cleared, and XML Sitemap Generator for WordPress 3.2.7 will throw errors about rebuilding the sitemap (but rebuilding the sitemap manually after I delete the cache works just fine).
I am reverting back to 1.0 for now, preload mode off, extra homepage checks on. I can confirm the the homepage of the site is being cached as a supercache file, not sure if preload wasn’t working correctly for that somehow in 1.1 for me?
Same issue here. Home page does not update whatsoever under the new version when new posts are published :(.