In my mind, one of the important milestones in our long march towards Known 1.0, was to allow allow Known settings and admin pages to have their own template.

It was not uncommon for themes or plugins to get a little broken, and in some cases this caused Known’s admin page to break. A bad time all round.

So, a recent patch makes it so that these special pages can now have their own templates, which will make Known framework sites much more robust.

As a side effect of this, I’ve introduced a mechanism in the template system for code to specify a different page shell for a url hierarchy. So, for example, by using \Idno\Core\Idno::site()->template()->addUrlShellOverride('/foo/', 'foo-shell') you can specify that anything under ‘/foo/’ would use shell ‘foo-shell’, automatically.

More tweaks to come, I’m sure, but so far it looks like this…

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...

Previously, I wrote about an experimental plugin for the IPFS.

Now, I’ve extended this tool with experimental support for serving image proxied content (user icons, unfurled images, etc) via an IPFS CDN, rather than from your local server.

For this to work, your IPFS server needs to be publicly available.

It goes without saying that you need to be running the latest versions of Known for this to work!

Give it a try!

» Visit the project on Github...