I do a lot of my day to day work on Github, as you may have noticed. So, to be a good #indieweb citizen, I figured it’d be nice to be able to at least comment on tickets from my own site.

Thankfully, Github has a pretty comprehensive API, so it turns out that doing this was pretty easy. So, I wrote a quick plugin for Known…

Github ticket and comment syndication

Install and activate the plugin in the usual way, and once enabled, you will have the ability to reply to comments and create tickets on Github. This is particularly useful when using the Known browser extensions (like my Chrome plugin).

To create a new ticket, make a reply to a plugin’s issues page, and to create a new comment, simply reply to the comment thread.

Let me know how you get on!

» Visit the project on Github...

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!

As with the code I’ve released previously, I have found myself cutting and pasting this code about the place again and again, so I’ve packaged up my simple PHP template framework and stuck it on github.

This library comes complete with a basic HTML5, JSON, and JSONP templates, that you can extend and override, making the development of web applications (hopefully) slightly easier. It does for me at any rate, because I really hate repeating myself!

Usage

The default template engine provided by this library – the Basic template – should be fairly familiar to anyone who’s used Elgg or similar systems.

You initialise it with a set of template base paths (“base” provides a basic HTML5 hierachy). If you pass an array to the constructor, each array overrides the one preceding it, and so you can replace some functionality (for example providing a bootstrap layout) without having to replace everything.

Views are in a file hierarchy off of [basepath]/[template_type]/path/to/view.php, and are named simply as the path without the base gumph (in the example I give in the docs, this view would be ‘path/to/view’).

HTML5 versions of pages are in the /default/ template type branch, but the basic template comes with json and jsonp encoding of the pages, you can specify which template to use at runtime by passing the _vt=[branch] variable on the GET line, or from within your program code.

The basic template also makes a call to the simple event dispatcher before and after a given view is generated, passing “view:[viewname with colons instead of slashes]” as the namespace and either “prepend” or “extend” as the event, together with an array of all the variables passed to the view.

So, to listen to my documented example, you’d listen for events on “view:path:to:view” and either “prepend” or “extend”, echoing any extra stuff you want.

Anyway, hopefully this’ll be useful to someone!

» Visit the project on Github...