So, I’m delighted to say that what I consider to be an important landmark towards Known 1.0 has been reached, and that is that Composer Installers now supports Known plugins, themes and console plugins!

Currently support is only available in the development build, but support now should be included in the next release, which will hopefully come out soon!

This is a big deal for two important reasons; firstly it now becomes super easy to roll your own builds of Known, by simply supplying your own composer.json, and second, it solves the frustrating “checkout repository, move and rename” problem.

Making your plugin Composer ready

If you’re a plugin developer, there’s a few things you need to do in order to take advantage of this:

Create a composer.json file

Firstly you need to create a composer.json file. This file can contain a bunch of things, but at the very least you need to give your package a name, a version, and include the relevant composer installers instructions.

Here’s an example from my IPFS plugin, with the important parts in bold.

{
"name": "mapkyca/known-ipfs",
"type": "known-plugin",
"description": "Adds IPFS support to Known",
"version": "0.1.4",
"homepage": "https://www.marcus-povey.co.uk",
"keywords": [
"known",
"plugin",
"ipfs"
],
"license": "GPL-2.0",
"authors": [
{
"name": "Marcus Povey",
"email": "marcus@marcus-povey.co.uk"
}
],
"require": {
"php": ">=7.1",
"cloutier/php-ipfs-api": "^0.0.6",
"composer/installers": "~1.0"
},
"extra": {
"installer-name": "IPFS"
},
"require-dev": {
"mapkyca/known-language-tools": "^1.0",
"mapkyca/known-dev-scripts": "^1.0",
"mapkyca/known-phpcs": "^1.0"
}
}
  • name: the name of the repository (used for packagist)
  • type: should either be known-plugin known-console or known-theme
  • version: version of the plugin, again for packagist
  • “composer/installers”: “~1.0” in require composer your plugin needs to require the installers plugin. This is also included by Known core, so don’t worry too much if you forget!
  • “installer-name”: “IPFS” this tells installers that your plugin should be installed in the named directory. So in this case instead of installing the plugin as the repo name (known-ipfs), it’ll install as ‘IPFS’. This is of course the correct plugin name according to its class hierarchy… so no more renaming!

Create a tagged release

Write your code, and then create a tagged release matching the version value in your composer.json.

Submit to packagists.org

Finally, submit your plugin to packagists.org in order to make it available for other Known installations to use!

Enjoy!

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.