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];
    unset(\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!

So, after I fixed the two screen problem I was having with my Ubuntu setup, I started getting an odd flickering.

This flickering didn’t affect the whole screen, rather it seemed to be something to do with window repainting, and it became even worse after I updated to 14.04.

I run a slightly non-traditional configuration, in that I run Gnome2 fallback rather than Gnome3 or Unity, therefore this probably won’t effect a lot of people, and is probably why it persists.

After a bit of digging, I discovered that this is actually a compiz issue. Here’s a summary of the fix:

Fixing the flicker

  • Install the compiz settings manager: apt-get install compizconfig-settings-manager
  • Scroll down to “Workarounds” in the “Utility” section:

compiz-1

  • Select “Force full screen redraws (buffer swap) on repaint”:

compiz-2

Once this is done, your windows should repaint as normal.

HTML Sanitisation is pretty important where user input is concerned, not doing so can easily let your users do some pretty funky things to your site.

The latest versions of the Known engine support a hook to call a sanitisation plugin when outputting bodies of text. The hook is called automatically whenever autop is called, but you can call it yourself if you want to.

Anyway, it would be remiss of me if I didn’t implement something that listened to this hook, so here’s a Known html sanitiser powered by HTML Purifier.

Check out the plugin, install and activate it in the usual way. Enjoy!

» Visit the project on Github...