This weekend there will likely be some downtime or at least some display issues on the site for a short period. I'll be upgrading to Clay 1.1, which involves some administrative changes to the site following the upgrade.
I finished the Blocks to Plugins migration in Clay. I haven't noticed very much difference performance wise other than query counts in the database. Plugins are less database intensive, because they use a module for the backend, instead of application APIs.
As of today, nothing in Clay uses the services module, it has all been migrated to Plugins. This week I will remove all of the deprecated pieces and work on the upgrade from 1.0 to 1.1. If all goes well, I'll be working on 1.2 next week, which is the beginning of the frontend changes for the 2.0 milestone. I'm about 2 weeks ahead of schedule for 1.1, so I'll probably save that time to work on some extra stuff at the end of 1.2.
The fun stuff starts with 1.2 😎
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...