The recent move to Composer for Known (and eventually Known plugins) has given me the opportunity to improve the experience for plugin developers.

Previously, generating a .pot file for languages would require a script in Known’s central language directory. This meant all sorts of “relative path” hijinks in your Gruntfile.js, and was generally bad.

So, I’ve taken this opportunity to package up the script into its own project that can be installed via composer as a development dependency into your plugin project.

How to use

  1. Create your CoolProject, and add your translation string hooks, and load them as described here.
  2. In your project, add known-language-tools as a dependency using composer require mapkyca/known-language-tools --dev
  3. In the project directory you’ll find a Sample.package.json file. Copy this to your project root as package.json and edit accordingly. Note your project name should be the name of your project.
  4. In the project directory, you’ll find a Sample.Gruntfile.js. Again, copy this into your project root.
  5. Create a languages directory
  6. Run the grunt task, grunt build-lang (if grunt isn’t found, npm install --only=dev first.

Hope this is useful to you!

» Visit the project on Github...

Some important changes to Known were merged in over the weekend.

Most notably, (most) external dependencies are now managed and installed via Composer, and not included natively in the repository itself.

This makes updates easier to manage, but it does mean that if you are installing from (or more importantly, upgrading from) the git repository directly, you will need to perform an extra step.

cd /path/to/known; composer install

This is particularly important if you’re upgrading, and your site is a checkout of the git repo.

Some other important changes

Composer was the big one, but there have been a number of other important changes you should probably be aware of, especially if you write code for Known:

Support for IdnoPlugins.local

You can now put your custom plugins in a separate IdnoPlugins.local directory. This works exactly like IdnoPlugins, but gives us a way of nicely separating custom code from package code.

FileSystem interface change

File systems now support storeContent() for storing content to a file from a variable in memory.

This must be implemented by any class that implements this interface, therefore if you maintain a FileSystem plugin, you’ll need to update your code.

SQLite is deprecated

SQLite is not widely used, and supporting it introduces a fair amount of technical debt.

Support is now deprecated, and will be removed in a future release.