I'm almost finished with the blocks to plugins migration in Clay. It has made the Plugins API a little heavier, but with submodules most of the API isn't loaded on a normal page load. Cutting out the blocks API, which depends on the services module will still lighten Clay. Plugins also require only a single DB query, whereas the services module uses the more DB intensive application settings API.
I'm also doing an overhaul of the privileges for plugins and making a new UI interface that gives you a clearer picture of what the privileges assigned to a role actually allow. The Privileges API already had the capability, it just wasn't built into the admin component to show it before.
Finally, I'm building a sandbox mode into the Roles administration that allows an admin to see what is available for a user to see, without seeing the actual content. The sandbox mode will provide the user a layer of privacy, while not hampering site administration.
This is my 300th blog post. I could have made it about something interesting, perhaps, but it's a milestone at least. Clay keeps chugging along.
I've been working to merge blocks into the plugins app and therefore instances and groups will be part of plugins. Blocks will no longer be called blocks, they just fall into the different plugin categories. Groups will become open to any plugin type, whether they require instances or not.
I bounced back and forth trying to decide what to do with the blocks app. I guess the Xaraya dev in me wanted to keep it as a namesake. I eventually decided everything that is hooked internally should be a plugin, so blocks are going away. The whole point of the changes is to allow external hooks and use the services module for those. Moving blocks and the dashboard to plugins also cuts down on how much code is required to run the backend, since services, blocks, and plugins basically do the same thing in different ways.
Groups will work the same way they do now, except they will reference hooks from plugins instead of the blocks tables. This reduces database queries as well. The only difference between calling hooks for a group and an app will be referencing a group instead of an app, therefore groups can be displayed anywhere like before. Like blocks now, plugin instances will be assignable to multiple groups simultaneously.
I'm hoping the merger makes it easier to build apps and plugins, while reducing how many APIs are required to work with. If nothing else, it will reduce the database load and increase efficiency within the code. It also simplifies the privileges table and allows privileges to be implemented more consistently, which is better for security. Finally, it gets rid of the choice of whether something should be a block or a plugin. A lot of work, but I'm already seeing the payoff just from an administrative standpoint.
I've been migrating Clay's services over to plugins. So far only the Dashboard is finished. I'm working on the blocks now. They work a little differently from other plugins, but it demonstrates how flexible the plugins module can be. During the updates I plan to add some blocks, such as metadata and make the navbar a block.
The advantage of plugins over services is you manage the content through the UI, where services are called in manually within the code. This will allow me to build more flexible apps that can be used in various forms, by combining generic features for specific purposes.
The goal with plugins is to be able to eventually build custom content by using and mixing various plugins, then enhance them through a theme instead of creating new apps. Once the migration is complete I'll remove the services module and probably bring it back in a different form later on.
If anyone is interested in using Clay, I'm offering 5 free hosting plans. Use the contact link and send me an email. This is to allow me to gauge performance, test server migrations, and build metrics for hosting packages. These 5 accounts will always be free under a very generous quota, so take advantage of it if you are interested.
Please only apply if you will be actively using the hosting and willing provide feedback.
Now that Clay 1.0 is here (get it in the releases section on Github or clone master), I will rebuild Clay Framework and do a 1.0 release of it as well.
In the future, I may turn the framework into a composer package and manage it that way, even within Clay CMS (I normally just call it Clay). I had tossed around the idea to drop the framework as being a separate entity, but it could be useful to someone so I'll keep it.
For those that don't know, the Clay Framework is the core Clay library, with ClayDB and a multi-package installer framework. It's the part everything in Clay CMS is built upon. It has gone through several rewrites and is probably on somewhere around 6.0, I just never ticked up the version numbers. 1.0 sounds just as good to me.
Clay has been updated to 1.0 on Github. I've also upgraded all of my sites, without any issues from 0.9.x. If you notice any issues post a comment or report any issue on Github.
After sleeping on it, I'm doing a last audit of Clay, fixing a bunch of minor consistency issues, and will do an upgrade test. If all goes well, I plan to release Clay 1.0 on Monday.
I'm considering releasing Clay almost as-is as 1.0 and just beginning on the 2.0 branch. The changes I want to make are piling up and most of them are keeping me from doing other things. Version numbers aren't really a big deal nowadays, but I've wanted to make it perfect for 1.0 and I can't if I keep thinking of ways to improve it.
It works as it is now, I may as well call it the first version and move on. I don't have all of the apps I wanted in a first release, but the changes I want to make will allow apps to be developed much faster and easier. So...I'm going to sleep on it. The main thing to me is to always have an upgrade path and if I tick up the version to 1 now, I can build on that.
What I'm looking at would deprecate some older features and consolidate into newer, some even current, features. It feels odd to have deprecated features in a 1.0 release. I'd rather start fresh and at least show how much time has gone into it. So, more than likely, I'm going to do the 1.0 release, do some major changes to prep for 2.0 in 1.x, and keep moving along.
But, like I said, I'm going to sleep on it...
I've been trying to make Clay a little more developer friendly, mainly to make up for a lack of documentation. Adding Composer support was a part of that. I'm hoping, over time, I can continue building in tools that assist in that department, but to also use them as a form of documentation.
Tonight I started on an example/starter app that will demonstration how applications work and all of the options available to use from Clay itself. Apps are their own entity within Clay, so it's impossible to demonstrate everything possible to build in an app, but I can show ways to do certain things.
I've always hated scaffolded apps, but I was still considering building a generator that gives you a simple, functioning app. I still may do that, as a temporary solution, but I have a better idea for the long term. I may tell you about it some day...or I may just wait and show you.
The one tool Clay needs the most is documentation and I plan to slowly document everything. I had a complete set of docs for Clay years ago, but it kept changing so much that was not maintainable by just me. Clay is stable now and if nothing else I'll have a complete document on for 2.0.
I'm currently adding Composer (the PHP package manager) support in Clay, with the hope that access to additional packages will speed up my development flow. I do not plan to make Composer a requirement to use Clay, it will only be for Clay developers.
Until now there has been very little 3rd party code within Clay, I've attempted to write as much of it as I can. Unfortunately, that isn't the timeliest way to do things, especially if there is a specialized package that can do the same things. There are still plenty of things I want to add to Clay that I'll have to write myself, but these packages (which are equivalent to Clay Libraries) will definitely makes development easier and faster.
Again, Composer won't be required to use Clay, it will just be a developer tool, in addition to NPM (Node.js Package Manager) and several other command line tools that are used for Clay development. All of the 3rd party packages will be included in Clay and managed through the release cycle process.