I haven't upgraded the site yet, so I missed my scheduled bi-weekly update. I was hoping to have the Blocks app finished in time, but my real life work schedule has cut into my playtime quite a bit.
I'll probably get around to doing the upgrade this week, with or without the Blocks. Most of the changes are on the admin side, so it's not like I have anything special to show off right now anyway.
My goal this week is to have CF 0.9.1 on GitHub, [hopefully] along with compatibility updates to Clay Installer. I would also like to push the ClayCMS core. ClayCMS may not make it, or I may just not push the files to the master repo yet (create an Unstable branch and put a note in the readme file about what is going on).
CF 0.9.1 includes some namespace changes, in both libraries and applications. It's some major changes, so I'm having to review and test the code to make sure everything is correct. I'm also commenting code as I do the review, which is something I've neglected quite a bit in the past.
Note: I've already pushed the namespace changes to the master repo. My goal is to have the code ready to tag as 0.9.1, which is Alpha 2 (see previous post about Clay release schedule).
I've finally figured out how to effectively use eGit in Eclipse with the different repos. It's kind of a pain, but it's better than anything else I've tried. I basically have a local repo I use for development. I have clones of the repos from Github. I use branches in my dev repo to make changes and pull in updates from the various repos. Once I've made a change in the dev repo, I pull it into the clones, verfiy all the changes made it into the clone, then push upstream back to GitHub.
Like I said, it's a pain, but I've had worse. This allows me to keep CF in its own repo, so I can continue development without effecting any of the projects using it. It also allows me to break everything up and tier the repos. I have clay-frame, clay-installer (which will soon include clay-framework), and I'll soon be pushing up claycms (which will include clay-installer, which includes clay-framework). It may seem odd, but it's the only way I can think of to ensure the project meets its goals of providing different component for different project needs.
If anyone knows me, they know I don't finish anything. Well, hopefully this time it at least works out better than normal. I believe I've finally hammered out a path to CF 1.0. The main reason I want to get there is so I can start over :) The good thing about having a new version to work on is I can build stuff for CF 1.0, while working on CF 2.0 to make it better. For a while CF 1 was too raw to build for, but now I can let the project mature around it and still look to the future. Fun time ahead :)
I've tagged the current version of Clay Framework, in the GitHub repo, as 0.9.0 (Alpha 1). I'm not publicizing it as a release, but it is the first 'complete' Alpha. Alpha 2 (0.9.1) will incorporate the new namespace changes. It will not be publicized either (other than here of course). Finally Alpha 3 (0.9.2) will have some changes to the way Application objects are created and will incorporate a few other improvements for applications. Alpha 3 will be the first public Alpha release. If all goes well, as in nothing catastrophic comes up, it will be the only Alpha release. Starting at 0.9.3 I hope to begin releasing Betas and to have clay-project.com launched by that point.
I've started changing the namespace/folder names in Clay Framework (CF) to match. Some of them are kind of strange, since the folder name should be plural, but the namespace is easier to read as singular. Such as \data\filter\html. You may think the html filter would be in a /filters folder. Clay is action-based, so the classes and functions are namespaced as actions, not sets. A lot of frameworks are using matching folders and namespaces, which I have planned to change to for a while.
Once I've finished some testing I will push the changes out to the repos. I've also started doing the changes in ClayCMS and Clay Installer. For instance Application Libaries will be in a /library folder to be uniform with the change in CF of /libraries to /library. The app library namespace is changing accordingly, from \application\*\api to \application\*\library. I am keeping the method of calling Library Static methods using static::api(), as those are API functions.
Once all of these changes are in affect, CF will be at version 0.9.1 (Alpha 2). I plan to do the first publicized Alpha release with 0.9.2 (Alpha 3).
I pushed some updates to GitHub for Clay Framework and Clay Installer. These mainly focused on PHP Strict Standards compliance. I also pushed the Autoboot package and the renamed feature for site configuration names.
I'm trying to decide on how to do the repos. I want to keep a repo of just Clay Framework. The rest are a little trickier. The plan has bee to keep them separated in their own repos. It's kind of a pain to keep track of what changes and doing the cross merges to the different repos. I'm thinking about tiering them instead. I had a long night at work, so I'm not deciding right now :)
I have Autoboot working, mostly. I still have to finish the method that creates/updates the configuration file to store domains -> configurations. I only spent about an hour on it, so considering I worked a night shift and then worked on Autoboot I think I did ok.
CF is amazing, and yes I am biased. To implement Autoboot's functionality took about 10 lines of code, 1 class extending the \clay class. I wouldn't have even had to extend \clay, if it wasn't for a static property I needed to access configuration data.
To use it you create an "installation" of the Autoboot package and name it 'default'. Then in the "installation" set up you match a domain name to an installation. That's it. The 10 lines of code does the rest. It's only accessible from the Clay Installer.
I also added a feature to rename "installations" to Clay Installer. I did that yesterday before going into work. It doesn't set up a restore point, which I may add later. The Site Restore feature isn't complete, so I didn't want to dive into that too much.
Once I put the finishing touches on Autoboot, I'll be back to working on ClayCMS. I'm hoping to have enough content apps soon to use Autoboot and launch clay-project.com.
Autoboot is a package I started on a while back, but could never think of a good way to implement it. It is a multisite boot utility, which works by taking the current domain name and determines which site configuration is being requested. This has become fairly easy to implement, now that \clay::bootstrap delegates initialization to the site configuration.
I started working on it again yesterday, but had to stop to get virtual domains working in Apache on my development server. I finally figured out what I was doing wrong and now I can make up my own domains and point them all to my Clay file system. Anyway, I'm finishing Autoboot so I can begin setting clay-project.com and other sites using the same Clay files as daviddyess.com (right now they all just show up as daviddyess.com).
I decided to work on it, because it had gone mostly forgotten so long. I didn't want to get ready to set up clay-project.com and then realize Autoboot isn't finished (making me rush it out). The idea right now is an Autoboot installation will be the 'default' site configuration and it will then hand off site initialization to the site being requested. Fairly typical for multisites, just adapted to the Clay style of doing things.
Downtime: It's a Clay Installer package that lets you take a site offline for maintenance. Doing it.
This one I've dreaded for a while. The problem with making applications loosely knitted, is when you need to make a menu. I'm still trying to decide how to do the Menu block. There are lots of potential ways, but those are based on other CMS' and none are perfect. Still trying to hammer this one out. I think I'll fall back to something like Xaraya's, which a few usability improvements (I hope). Anyway, don't be surprised if we end up with several menu blocks haha.