There are now many plugins for Known, a lot of them I’ve written, are available on Github.

Many people, myself included, like to install these plugins via a git submodule checkout – this simplifies deployment and makes updating installed plugins easier, however it can be problematic.

The problem is that either the repository contains the actual plugin in a subdirectory (e.g. my Github plugin is in the repo ‘KnownGithub‘, and the plugin is in a subdirectory ‘Github’), or if they don’t, the actual clone of the repository will default to an incompatible name (e.g. Known’s Facebook plugin is in a repo ‘facebook’, but the code wants it in a directory ‘Facebook’).

Both have their own issues, but both mean you can’t directly use them in a submodule git checkout (unless you use my symlink trick). It would be nice if you could use these repos directly, so I put together a patch (which has been accepted) that allows you to build your plugin repos in such a way that they can be used directly from a git clone.

Introducing the autoloader

The patch I submitted introduces the ability to provide a loader for your plugin in the root directory of your plugin repository. So, if your plugin is Foo in a directory inside your repository KnownFoo, you could create a special autoloader.php file in the root that will allow Known to load your plugin in the normal way, direct from a git clone into your IdnoPlugins directory.

To do this, create a file autoloader.php with the following code:

 * Support loading of direct checkout.
spl_autoload_register(function($class) {
        $class = str_replace('\\', DIRECTORY_SEPARATOR, $class);

    $segments = explode(DIRECTORY_SEPARATOR, $class);
    $PLUGIN_NAME = $segments[1];

        $basedir = dirname(dirname(dirname(__FILE__))) . '/'; 
        $file = str_replace($PLUGIN_NAME, basename(dirname(__FILE__)) . "/$PLUGIN_NAME", $class);

    \Idno\Core\site()->plugins()->plugins[basename(dirname(__FILE__))] = \Idno\Core\site()->plugins()->plugins[$PLUGIN_NAME];

        if (file_exists($basedir . $file . '.php')) {
                include_once($basedir . $file . '.php');


This code will automatically load your plugin classes from its “real name” subdirectory, and make it available to your plugin loader.

Have a look at my Github plugin for an example, have fun!

oEmbed, as the wikipedia page puts it, is an open format for obtaining an embeddable representation of an object. As suggested in the comments in an earlier post, I’ve now extended my Idno Embedded post plugin to support oEmbed.

It works by providing an endpoint that other sites can query, passing the permalink of the thing they’re wanting to embed, a format parameter (currently only json is supported), and any other content specific parameters (e.g. maxwidth and maxheight).

You can pass a permalink of an idno post to this endpoint, and you’ll be returned a JSON data structure containing some details about it. Additionally, if you pass a callback parameter, you’ll get this data as JSONP, which may be more useful.

Here’s some example code, using jQuery for convenience:

This example makes use of the JSONP callback to update all div elements of class oembed, with the URL from the data-url parameter.

Because of this bug, at the moment you’ll need to use my branch of the bonita template library, which applies this fix, in order for the oEmbed functionality to work.

Currently, all posts will default to the 'rich' data type, however you can extend this by providing your own entity class templates and provide specific details for your own custom types.

» Visit the project on Github...

Further to my previous post on embedding Idno posts, I’ve written a WordPress plugin to make the process even easier!

Now, you can embed a post in your blog by placing the permalink of the blog inside the new [idno] shortcode, for example:


or, to override the default size of the embed code:

[idno width="somesize" height="somesize"][/idno]

» Visit the project on Github…