Austin Matzko

Could you describe what happens when you attempt to back up? Is there an error message?

Thanks for catching that! I’ve added a patch, and it will go out in the next release: (GitHub commit).

Sorry–I realized after I’d already updated that I’d forgotten the change log.

Basically, the changes were just a couple of minor bug-fixes and some changes to avoid using deprecated functionality. And to get rid of the “this plugin hasn’t been updated in years” warning, since it still works fine!

It’s the same 2 entries in different backup files? That is strange.

Any chance you could send me a copy of the backup to

austin -at- pressedcode -dot- com?

Which plugin did you decide to go with, and in what ways is it better?

No, spam is in the comments table and revisions are in the posts table, so there is no situation in which both WHERE clauses would apply to the same table.

Has this happened in more than one backup file? I could imagine something like this might happen if an auto-draft were created while the backup file was being generated, but that would be rare.

The problem is in how wp-follow prints its markup: it relies on the theme’s calling get_footer(), which Thesis doesn’t do.

Change line 146 of wp-followme/followme.php from

add_action( 'get_footer', 'show_followme' );

to

add_action( 'wp_footer', 'show_followme' );

I tried the same query, with custom post type and custom taxonomy, and it worked fine.

What happened is that back a couple of years ago it was more common for plugins to be installed right in the plugins directory, like

plugins/wp-db-backup.php

instead of what people do now:

plugins/wp-db-backup/wp-db-backup.php

The result is that when you upgrade from the former to the latter, the former doesn’t get deleted because it’s not in the expected wp-db-backup directory.

You can safely delete it though.

It was compressing in chunks before, but then the gzipped file would report an incorrect uncompressed file size, which would cause the unzipping to fail on a couple of common zip clients.

So the trick is not compressing in chunks, but doing so in a way that reports the correct uncompressed file size.

My number one support question used to be from people who would use one of these gzip clients, have the extraction fail, and then think that their backup was lost a crucial moment.

mardi, if you say “unlimited memory” I think you must mean disk space, not server memory. PHP memory must be limited to something; your host should know what that number is.

Karl,

The theme switch plugin isn’t meant to switch the theme for everyone; rather, it just sets the theme for whoever chooses it at that point. And the way it works is by setting a cookie in the user’s browser to identify which theme that user wants to see.

So that means that if you set the theme you want to see in one browser, you won’t see it in another. Bottom line, this is the intended behavior of the plugin. If you want to change the theme’s appearance for everyone, you’ll have to do that in the admin.

Looking around, I guess a number of people recommend 64MB for WP, but I would go higher if your system has the resources. 64MB might be sufficient for solving this issue, though. Basically the problem is that the server is trying to read that file into memory so it can make a gzipped version, and 19MB takes up the majority of the allotted 32MB, which is being used elsewhere.

Your PHP memory size of ~33MB is really low for WordPress. I’m surprised you haven’t run into other problems. I would set that no lower than 128MB. Normally, you would do this by setting the line memory_limit = 128MB in php.ini, but I don’t know if there’s a control panel way of doing that for your virtual server.