Category Archives: Software

Posted on
by

In the latest builds of Known, I’ve added support for Gettext translations. This can operate in tandem with the string array mechanism used previously, but it is my hope that using gettext will make translations easier, as there is a more complete tool chain available.

Creating .POT file

The first step, after you’ve used \Idno\Core\Idno::site()->language()->_() to write your strings, is to generate a POT template translation file. To do this, in /languages/ there’s a helpful script, go into this directory and run the script

./makepot.sh /path/to/your/plugin > /path/to/your/plugin/languages/

This will parse all your plugin’s PHP files and extract translatable strings.

Creating your translation

Open up your .POT file with a suitable tool, e.g. poedit, and save your .mo and .po files as /path/to/your/plugin/languages/LOCALE/LC_MESSAGES/DOMAIN.mo|po, where:

  • LOCALE is the locale you’re writing for, e.g. pt_BR
  • DOMAIN is the domain, e.g. your plugin name ‘myplugin’

Registering your translation

In your plugin, register your language by registering a new GetTextTranslation class, passing the path of your languages directory, and the domain you used.

So, for the above example this might look like:

function registerTranslations()
{
    \Idno\Core\Idno::site()->language()->register(
        new \Idno\Core\GetTextTranslation(
            'myplugin',
            dirname(__FILE__) . '/languages/'
        )
    );
}

Posted on
by

I’ve been doing a bit of spring cleaning to the Known repo, removing unnecessary files, tidying up various bits and bobs. One thing I did, because it actually made some client work testing easier, was to move the Known vagrant wrapper into its own repo.

This makes the wrapper much easier to maintain and deploy (for me at least). I also took the liberty of tidying up a number of issues with the ansible configuration which was preventing the provisioning script from working properly.

Usage

You need to download and install a number of tools first, namely: VirtualBox, Vagrant, and Ansible.

Next, you need to check out a copy of the Known repo (or your Known based product environment) into a sub directory called Known. Symlinks should also work.

Run vagrant, and your new Known install will be provisioned as withknown on 192.168.33.33, I recommend modifying your /etc/hosts file to alias this.

Hope you find this useful!

» Visit the project on Github...



Vagrant logo by Fco.plj – Own work, CC BY-SA 3.0, Link

Posted on
by

I hit a number of gotchas when upgrading my home and business web server from jessie to stretch, here they are in no particular order. Hopefully will save you some hair pulling…

Broken MariaDB install

Debian now ships with MariaDB by default, but when I upgraded mariadb-server would not install, meaning their were loads of broken dependencies. Dpkg exited with an error status, but with no indication as to what the actual error actually was.

Fixes suggested elsewhere (purging and reinstalling, moving /var/lib/mysql away and reinstalling, etc) did not help.

Eventually, I was able to manually execute mysql_install_db, which actually gave me some output. For me, the problem seemed to have been caused by the slow query logging entries, which are either unsupported in MariaDB or are named something else (I’ve not had a chance to check).

I commented out the following lines as follows:

# log_slow_queries  = /var/log/mysql/mysql-slow.log
# long_query_time = 2
# log-queries-not-using-indexes

… and apt-get was able to install the package.

Isolated /tmp

The version of systemd shipping with Debian 9 includes some security enhancements, including PrivateTmp, which isolates the temporary directory from users.

So, if you use your tmp directory to store e.g. cache data when developing websites, you’re going to need to store this somewhere else, otherwise file_exists and other file functions will not be able to read or write to them.

PHP 7

Ooooooo… boy.

Biggest hitter by far for me was that Debian 9 now ships with PHP7. Usefully, 5.6 is still available, so you have to switch to 7 manually (which means installing all the appropriate module again). Gotcha here is the mysql extension has been entirely removed, good thing too… however, if you’ve been running your server for a while like I have, you’re going to have a metric shittonne of things that need to be upgraded in order to work. Biggest pain in the bum was my ownCloud 8 server (made harder by the fact you can’t cross major versions in an upgrade, and the releases for those versions were no longer available until I nudged someone on IRC, also, pro tip, do the upgrade on PHP 5).

For scripts that either don’t have newer versions, or legacy stuff you don’t have time right now to allocate significant dev resources to, there is a mysql->mysqli shim available. This seems to work quite well in most cases, although of course it should be fairly high priority for you to migrate to PDO or similar!

Elgg and PHP 7

If you’re building sites on the 1.x.x branch of Elgg, you’re either going to have to upgrade to Elgg 2.x to run on PHP7, or use the shim.

I only have development sites running on PHP 7 at the moment, all of my clients that use < Elgg 2 are running on older PHP releases for now, but the shim works well in development and until I can manage those upgrades. If you use the shim you may need to comment out the following lines in executeQuery() in engine/classes/Elgg/Database.php:

if (!is_resource($dblink)) {
    throw new \DatabaseException("Connection to database was lost.");
}

…since the resource returned by the shim is a different type than expected.

That’s all so far, hope this will save you some stress!