Clckwrks is a modular platform for building web sites and web applications. It provides a simple core which can be extended using a variety of plugins and themes. Ultimately, it will be possible to install plugins and themes via the web interface with zero programming knowledge.
The set of currently available plugins make clckwrks suitable for creating a blogging or CMS system. New functionality can be added by creating additional plugins.
Clckwrks has the hooks in place to support dynamic loading of plugins and themes. But, the higher-level functionality for interfacing with cabal is not yet implemented.
At present, Clckwrks still requires some degree of Haskell knowledge.
More information can be found at:
We have made several large changes in this release. We temporarily lost a little functionality, but overall things are a lot better.
The blogging and CMS functionality has now been split out into a new package
clckwrks-plugin-page. One important reason for doing this is that it just felt like the obvious thing to do. The blogging/CMS code was already largely independent of the other core code. So, creating the extra modularity was just good design.
This also means that
clckwrks can now be used even if you don't need blogging/CMS. This makes
clckwrks more suitable for implementing something like a wiki. The wiki functionality could be added in a new plugin
clckwrks-plugin-wiki but would still use existing plugins like
With this release we are beginning to base clckwrks on bootstrap. At the most basic level, this means that the setting menu and forms are a bit nicer looking. A larger problem we face is that plugins and themes are designed and implemented independently. But, the two sides need some sort of standardization to agree upon. Rather than invent our own new standard, we are going to leverage bootstraps.
As a plugin designer, you can hope that if your plugin looks good using the standard bootstrap theme, it will look good in other themes as well.
As a theme designer, you are not required to use bootstrap. But, you will be able to expect that the HTML your are trying to theme will try to follow the bootstrap conventions.
new NavBar editor
clckwrks < 0.15 we ended up with two things called 'menu'. One is the sidebar menu that appears in the settings pages. The other is the menu that is at the top of normal pages. The menu at the top of the page is now called a 'NavBar' and the types have been renamed accordingly. This matches better with bootstrap terminology.
There have also been substantial improvements to the navbar editor. It is now possible for each plugin to add new links to the navbar editor. And it is also possible to rename the nav bar entries.
We do not, unfortunately, provide any automatic migration of the old menu entries to the new system. Given the small number of users and the fact that it is relatively easy to recreate the navbar entries, we opted to simply ignore the old menu entries. The old menu is preserved in the "menu" state directory as the new navbar use the "navbar" state directory. But, users will need to recreate the navigation menu by hand.
The new navbar editor is still missing features -- but they will come over time :)
Previously, after a user was logged in, they would be presented with the default 'admin settings' menu. But, of course, they do not have authorization to most of the admin console features, so clicking on the links would result in an authorization error.
In the new system, the settings menu entries include a set of Roles for which they should be shown. So, non-admin users should only see links that are relevant to them.
What's Been Lost
As mentioned before, we can not migration old navbar data -- which is a minor inconvenience.
Previously, themes included the ability to customize the HTML used to generate individuals pages and the blog. Because all those types now live in a
clckwrks-plugin-page, the theme packages would need to depend on that plugin in order to continue providing that functionality.
However, that method does not really scale up. It seems likely that theme designers might want to heavily customize other plugins as well, such as the media plugin. So, it seems like the way to go is to have something like:
clckwrks-theme-foo- foo theme for core system
clckwrks-theme-foo-page- foo theme for page plugin
clckwrks-theme-foo-media- foo theme for media plugin
This allows theme designer to theme the core, and have addons for other plugins they want to customize, with out forcing users of the theme to install plugins they don't actually use.
This has not been implemented yet.