TLDR; This is nothing new : WordPress is a great choice for a quick blog or web-site.

We were after an update to our web-site and we did not want to spent too many evenings and weekends.

The outsiders

Textpattern

We used Textpattern for a long time for our old site. It was OK, but I missed a mobile app and did not like textile markup and generally was not greatly impressed by the admin UI.

Joomla

About 5 years ago I used Joomla for a client, but to be honest Martina and I kind of forgot about it and did not check it out. I might have been the best, but we will never know.

Typo3

Typo3 came into consideration because it is popular in German speaking countries. I checked it out in a demo site and downloaded it and never did more with it.

The Finalists

In the end it came down to only Drupal and WordPress even though these two might be the best they become the favourites for these reasons:

  • I used both Drupal and WordPress for clients and in my current job. Martina recently used WordPress for one of her previous clients.
  • For previous clients WordPress seemed to be the easiest choice for the particular users.
  • Usually I like software that challenges me and give me the opportunity to learn more. This time we both wanted to go for quickest and not best implementation
  • Mobile Apps – I want to be able to quickly take a shot and post it. The WordPress app that I tried seemed more mature than the Drupal app that I tried for
  • Markdown – Markdown is another lightweight mark-up language I like it. Not much more or less than all the other ones that I know, but more than textile. And I like to be able to write free-text without a WYSIWYG editor or HTML tags. All these CMS were able to use it in some way.
  • PHP : We are thinking about moving hoster but we are not and PHP is what supported. All non-PHP web apps did not get considered.

I know Drupal from work, but not intimately. For this test I set-up a complete site and allowed multiple users to create their own blogs in both WordPress and Drupal and apart from Martina’s work in the mnm blog and her effort of importing the old entries into the WordPress our test sites in WordPress and Drupal had similar functionality.
I believe that things were done in Drupal were more elegant than the equivalent in WordPress.
Also Drupal is not as annoying about the domain name changes as a multi-site WordPress installation.
During the process of testing I set up a VM and used a local IP then moved to a faked domain (hosts entry) then I wanted to reach it externally and set up a reverse proxy of our test home domain.
Drupal was still happy but for WordPress I had to run something along the lines of this:

export grepFile=$(mktemp)

cat > ${grepFile} <<ENDL
test.domain1:2081
test.domain1
test.domain2
www.mnm.at:2081
www.mnm.at
10.10.10.10:2081
10.10.10.10
ENDL

export sedFile=$(mktemp)
sed -e 's@\(.*\)@s~\1~mnm.at~g@' ${grepFile} > ${sedFile}
for f in $(grep  -l -i -r --file ${grepFile} wordpress  wp.final.dump.sql); do 
    sed -i --file ${sedFile} $f   
done

rm ${grepFile} ${sedFile}

Or I could have searched and used that script. I believe I was quicker with my script.

I did a bit more CSS work in Drupal. I think that it takes a similar effort to set up a multi site WordPress installation as a Drupal installation that provides a similar set-up.

The points that moved the decision to WordPress in the end:

  • The Drupal mobile app for Android that I checked out was not as advanced as the WordPress app.
  • Martina already imported all the posts from our old site and manually fixed

encoding issues that have been a problem in the old site. But that also meant that she was faster in doing a single user blog in WordPress with imported posts than I was with the multi-user Drupal set up and a single themed blog. (Though I was also the one who had to spent the time on the multi-site WordPress set-up)

Sigh, for virtual box the update build wrecks the boot MBR. After the updates are installed and the script reboots the vm it hangs at “GRUB” I was pretty sure that installed SuSE with by path instead of id and yes, autoyast has:

    <device_map config:type="list">
      <device_map_entry>
        <firmware>hd0</firmware>
        <linux>/dev/sda</linux>
      </device_map_entry>
    </device_map>

some how the boot manager got installed to /dev/disk/by-id/ata-VBOX_HARDDISK_6VM23FX0 according to /boot/grub2/device.map. And of course after packer clones the original VirtualBox vm the uuid changes and not boot. So I had to add

    echo "(hd0)   /dev/sda" > /boot/grub2/device.map  

to the start of the update script

Another problem that came up with VirtualBox is that the interface was renamed to eth1 after the reboot but the configurations were still pointing to eth0. The workaround for that was adding

    # remove the old udev rule before the reboot
    rm /etc/udev/rules.d/70-persistent-net.rules

Which meant the old eth0 was removed before the reboot and was then automatically set up at the boot-up.

SuSE bug 821879 – udev update breaks network:

My work for the problem with udev breaking the network is this script :

    #!/bin/bash

    t=/tmp/update-script
    #$( mktemp )

    cat >${t} <<ENDL
    zypper --non-interactive modifyrepo --disable --no-refresh openSUSE-12.3-1.7
    zypper --non-interactive addrepo --check --refresh --name "Update Repository (Non-Oss)" http://download.opensuse.org/update/12.3-non-oss/ download.opensuse.org-12.3-non-oss
    zypper --non-interactive addrepo --check --refresh --name "Main Repository (NON-OSS)" http://download.opensuse.org/distribution/12.3/repo/non-oss/ download.opensuse.org-non-oss   
    zypper --non-interactive addrepo --check --refresh --name "Main Repository (OSS)" http://download.opensuse.org/distribution/12.3/repo/oss/ download.opensuse.org-oss     
    zypper --non-interactive addrepo --check --refresh --name "Main Update Repository" http://download.opensuse.org/update/12.3/ download.opensuse.org-update 
    zypper --non-interactive refresh
    zypper --non-interactive update
    sleep 10 
    reboot
    # to make sure we wait for the reboot 
    sleep 10 

    ENDL

    chmod u+x ${t}

    echo storing output under VM : ${t}.out
    nohup bash -vx ${t} > ${t}.out &

for packer I also added this:

    echo Initiating sshd shutdown and killing all ssh* processes.
    echo The install process will seems to hang for serveral minutes 
    echo while the updates are installed.
    echo the reboot at the end will start sshd and the process will continue

    # prevent reconnect for next script until after the time out
    systemctl  stop sshd
    ps -ef | grep ssh | grep -v grep  | awk &#39;{print $2}&#39; | xargs kill

The OpenSuSE 12.3 issue with the slow network start-up time seems to be some timing issue. It might be because two processes start the network at the same time. One being auto plug and the other the network start time. I was looking into it until it suddenly stopped happening, so I stopped looking into it.

The next problem was/is that packer does not always reconnect to the install after the reboot. that might be related to the network issue or not. But the odd thing is that it worked once with a two hour period of successful sshd polling and the next time it failed after one minute of failed polling. did change my script from being in the background with nohup (to work around the udev network issue) in between, but I am not sure if that is related. started to check in the changes in to the https://bitbucket.org/markus_ebenhoeh/packer-opensuse.12.3 repository to track what I am doing.