This blog has just been migrated to a newer and (much) faster host node running Proxmox 5 with ZFS.
Therefore, I was looking for the best method to migrate a WordPress blog to another server (and/or database and/or directory and/or URL).
Do you remember the times when migrating a WordPress blog was rather tedious, involving many manual steps, despite (other) handy tools like WP-CLI? Apparently, this is no longer needed, as all you need is the following plugin:
All-in-One WP Migration
This plugin’s export and import functionality takes care of all the required configuration and path adjustments, allowing you to easily migrate a blog with up to 512 MB data. The steps are thus:
- Install the All-in-One WP Migration plugin on your current WordPress site
- Use the plugin to export all your data, plugins, themes, configuration etc., e.g. as a downloadable file.
Note: In particularly tricky cases you can also manually replace certain strings in the db or exclude specific data and files.
- Setup a new vanilla WordPress installation at another location (server, directory). You’ll need a database and the WP installation files for this.
- Install the All-in-One WP Migration plugin on your new WordPress site
- Use the plugin on your new site to import the previously exported data from your old site
It’s hard to believe, but that’s really it!
Here’s a quick overview how to migrate a ZCS mail server (based on Ubuntu) to a new IP address:
0) Not covered here: Adjusting DNS entries. Make sure you lower the TTLs of the relevant DNS entries a couple of days in advance in order to minimize downtime for clients (e.g. set a TTL of 300 for a 5 minute downtime).
1) Set the new IP address in:
* The relevant DNS entries
* If ZCS runs in a container/VM, don’t forget to adjust its IP address too.
2) If the new IP address is part of a new subnet, make sure to add this new subnet to ZCS’s trusted_networks, otherwise, sending (relaying) messages through ZCS from Zimbra Desktop (or any other mail client) won’t work. This can be set using ZCS’s web admin interface (i.e. https://mail.myserver.com:7071/zimbraAdmin/):
Navigate to “Server settings”, then open the “MTA” tab and set something analogous to the following in “MTA Trusted Networks”:
3) Restart networking and the ZCS services (it’s important, as this adjusts the trusted_network setting in ZCS’s amavisd too):
# /etc/init.d/zimbra stop
# /etc/init.d/networking restart
# /etc/init.d/zimbra start
Alternatively, just reboot the server, particularly if it runs in a VM.
Note: The need for the adjustments in step 2) might come as a surprise. Authenticated messages to be relayed through ZCS apparently seem to originate from the external IP address, not localhost/127.0.0.1.
 A typical postfix error message might look like:
Delivery Failure Notification: Invalid address: somebody . com.zimbra.cs.mailbox.MailSender$SafeSendFailedException: MESSAGE_NOT_DELIVERED; chained exception is: com.zimbra.cs.mailclient.smtp.InvalidRecipientException: RCPT failed: Invalid recipient firstname.lastname@example.org: 554 5.7.1 : Relay access denied
I decided to disable the “share” button plugin (“tweet”, “like”, “+1” etc.) on this changelog for the following reasons:
I) I have to use (and know about) these social sharing technologies as an IT professional. As a private person however, I disapprove of proprietary technologies that may unknowingly inflict people’s privacy online (for even more scary stuff, learn about browser fingerprinting and read this recent Wired story about undeletable cookies). I also recommend and support using plugins and tools like
II) The way how social sharing (and “social” per se) is done today is just plain wrong:
- It’s proprietary instead of based on open standards.
- Data usually gets pulled into proprietary, closed, data silos instead of giving users full and exclusive control over their very own data.
- All the big existing social sharing architectures follow a vulnerable (in so many ways), centralized approach instead of a robust, distributed (or at least federated) one.
- Erroneously, people try to solve “social sharing” on the web application level instead of on a lower level and as part of an open protocol and specification (an open social backbone) rather than as various incompatible and proprietary implementations.
- Giving users guarantees and full control about their online privacy and data is impossible with the current approaches. Users are required to care about their settings for every single social sharing tool out there instead of being able to specify a global policy (e.g. in the browser).
- So far, social sharing is de facto opt-out instead of opt-in, which is the wrong approach if you want to put the user in control and avoid being evil.
III) “tweet”, “like”, “+1” buttons clutter up and “slow down” web pages and make for an unenjoyable user experience, also in regard to accessibility. It doesn’t scale (a separate button for each social network, for each shareable entity on a page , though it’s basically all just about “sharing something”? Oh no!). It’s not even necessary, pure lazyness (feel free to share by copy-pasting URLs manually until there’s a true social backbone). It simply s*cks on so many levels. The “share” button-itis as common today will largely disappear and be replaced by a browser built-in, extensible, standardized social sharing facility in a matter of 5 years.
IV) Do you know the code that hides behind a share button (or a fake thereof)? If so, do you know what exactly is going to happen when you click on it while surfing the web? Neither do I. Security, transparency, reliability, usability and accessibility could be improved a lot by moving “social sharing” from web pages to the browser.
Further (of less importance for the general discussion):
- As a private person I don’t care much about popularity contests and popularity in general, neither that of my pages nor of myself (or my virtual alter ego).
- On this changelog, the “share” buttons were rarely used anyway. I’m confident people won’t miss them now that they’re gone.
Important note: This post reflects nothing but my own opinion as a private person (like everything else posted on this private blog). I can clearly distinguish between my own opinion as a private person and opinions and needs of other individuals, businesses (even my own business), organizations and customers and fully respect them.
This is just a quick note to let you know that the migration is currently work in progress. Now the whole blog content is available again and the features that were available on the old server, will be migrated as time allows.
Sorry for any inconveniences and thanks for your understanding.
Just a quick update to let you know that this blog/changelog will soon be migrated to a new (faster) server.
I’ll keep (
unavoidable, due to DNS changes ) downtimes at the minimum and will inform you in advance about expected outages.
Thanks for your understanding.
I’ve just installed WPtouch 18.104.22.168 (ZIP) which was released on Feb 9 and I really like it:
More than just a plugin, WPtouchTM is a mobile theme for your WordPress website. Modelled after Apple’s app store design specs, WPtouch loads lightning fast and shows your content beautifully, without interfering with your regular site theme.
WPtouch automatically transforms your WordPress blog into a web-application experience when viewed from an iPhoneTM, iPod touchTM, AndroidTM, or BlackBerry StormTM touch mobile device.
via WPtouch: Mobile Plugin + Theme for WordPress » BraveNewCode Inc..
As spam levels increased quite a bit lately, I made a Gentoo Ebuild for the iXhash SpamAssassin plugin by Bert Ungerer / Heise iX, Germany.
So far, it’s available on bugs.gentoo.org only. In order to install it, download
and put it in your local Portage Overlay.
YMMV, but it performs really well on my server (particularly for German spam which is difficult to catch without). Don’t forget to adjust the according penalty scores to your liking, though!
Finally, I’ve had to enable greylisting for this domain due to ever increasing levels of spam. Fortunately, setting it up is very easy. For Gentoo and Postfix, here’s a nice walkthrough:
postfix greylisting on gentoo (postgrey) | andreas d.’s.
Let’s hope that this, in conjunction with other anti-spam measures, will do it for a while.
Non-spammers shouldn’t experience any problems due to this change, but if you do, please contact me using Skype (mettlerd), phone or SMS.
When I’m on the road, I can check my private and business e-mail using my very handy Nokia e61i smartphone (which I like a lot, apart from its rather unstable web browser). However, as I’ve never been far away from a computer for a long time so far, I’ve only used to check mail that was delivered to my inbox, and not to any of its about 200 subfolders (I once tried to subscribe to all folders – the mail client of the e61i simply crashed ;). Now, I figured I’d need to do something about this in order to not miss any of the mails that are automatically moved to a subfolder by the server-side procmail mail filter.
The solution: Simply create a new procmail rule that copies (that’s what the c stands for) any incoming message to a special folder (I named it “mobile”; note that my postfix uses the maildir format to store messages):
Preferably, this rule should be placed after the spam filtering rules (you don’t want to pay for spam on your mobile, do you? ;) and before the normal procmail mail filter rules (which move every incoming mail to the appropriate subfolder). You can also use a dedicated rules file for every group of similar rules. For example, I include the files spam.rc, mobile.rc, lists.rc (with their according rules) in the main .procmailrc config file.
Now every mail that wasn’t filtered by the spam filter gets copied to the “mobile” subfolder of your inbox prior to getting moved to the appropriate subfolder (by the rules in lists.rc).
On my e61i, I hence only need to subscribe to the “mobile” subfolder in order to catch all incoming messages. As you can’t unsubscribe from the inbox subfolder itself, you should set the maximum number of caught new inbox mails to 1 (which is the minimum) in order to avoid fetching things twice. You can further configure that only headers are fetched to minimize the amount of data that is automatically downloaded with every mail check (also: switch off polling if you don’t need it).
Note that another advantage of this solution is that you won’t tamper with any of the original messages (that are either in your inbox or in any of its subfolders). Some might call this a disadvantage though.
That’s it, have fun! :)
 I pay 0.10 CHF per 20 KB, i.e. 5 CHF (5 USD) per MB (which is incredibly expensive as I currently don’t have any flat rate data plan -> please don’t send me a mail bomb just for fun, else I’ll have to write a more sophisticated procmail rule that only copies messages < 100 KB to the mobile folder)
I’ve finally joined the flock of birds: Twitter / mettlerd. Let’s see whether it will be just a waste of time or an unexpected blessing. In general, most reviews of other (much earlier) birds are cautiously positive..