(No) issues with the WordPress DB Plugin

Since I moved my hosting location I had some problems to schedule backups with the WordPress DB Plugin.
Simple Task: I wanted to create backups of my DB and have it emailed to me once a week.
This used to work great with my old hosting environment.

Eventually I discovered that I did not receive any more backups.

Doing backups manually (and downloading them) worked fine. If I decided to not not download them, but to email them, I got an error stating:

Oh well, that did not sound good. The error wasn’t that helpful either.

Some sketched solutions I tried (and didn’t work) were:

  • Increase memory limit
  • Rewrite some plugin code

I don’t want to go into the embarassing details here, because the solution was … ehhhh … simple.

Solution

In the managing UI of my provider (hosteurope) you can define a standard email adress, which I did not know of. Set it and everything worked fine! The email adress configured within wordpress does not seem to suffice.

I am a little sad, that this wasn’t obvious from the logs or the UI. Or the provider could have simply predefine a standard adress, that would have reached my primary adress (catch all).

Funny thing is, that I did find this only because I was about to install some other DB backup tool, that pointed me to that potential problem.

 

 

Moving Servers: Status

As you might have noticed,  my site is more or less back again. Until now the relocation did not cause any major headaches, which is a good thing ;)

I did a fresh install of wordpress, as my new provider offered me a one-click-install option. It wasn’t actually „one-click“, downloading and unzipping WordPress would have been just as fast.

There were basically two things which bothered me:

  1. The installer forced me to use a custom prefix for my wordpress database tables. Usually a good thing, but the prefix could only consist of numbers and characters and especially no underscore. And it didn’t add any separator. So I ended up with tablenames like xxwp_content. Ugly, don’t you think. As I do not plan to add another wordpress installation, I could have easily stuck with wp_content but the installer did not leave that choice. This makes importing an old sql-dump harder than it should be. But I didn’t use that dump anyway ;)
  2. Updates of wordpress did not work out-of-the-box. The installer forgot creating a temporary folder, so that the update process stumbled on missing files. Or my provider did not set the property pointing to temporary storage properly. Just as bad.
    So what I did was:

    • Created a temporary folder [wordpress-install-dir]/tmp
      Keep an eye on the permissions.
    • Updated wp_config.php with

      putenv('TMPDIR='. ABSPATH .'tmp');
      define('WP_TEMP_DIR', ABSPATH . 'tmp');

    After I managed to solve those issues. I actually could install the WordPress xml importer plugin and everything went fine. I just had to upload some images and I was done.

    Now I am more or less through reinstalling my former set of plugins. That was quite straightforward, except the iG:Syntax Hiliter Plugin, which did not seem to be maintained any longer. As some post rely on it, I had to manually move it from my old site. Perhaps I should look for a replacement.

    Right now I am looking out for a new theme, though iBlog looks very nice. Perhaps I’ll keep it.  It’s just that it feels more like an addon than just a style-provider.

    Perhaps this will keep me busy for some time ;) Please feel free to suggest a nice theme.

Moving Servers

Hi all,

I am about to move my site to a new provider. I hope the downtime will only be a short one. Perhaps I will blog my experiences of moving WordPress from one place to another at a later time. Interesting topic. And suprisingly not that trivial.

Thanks go out to Marc for providing me with webspace for quite some time now! Cheers!

CU