11 Oct 17
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 😎
04 Oct 17
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.
22 Sep 17
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.
18 Sep 17
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.
15 Sep 17
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.
14 Sep 17
11 Sep 17
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.
08 Sep 17
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.