6:02 am
I was able to install a sample plugin in Clay, but I have not finished the UI in the dashboard for managing and hooking plugins yet. I've been going back and forth a little on the base class for plugins to use. I hope to figure that out tonight or tomorrow.
8:32 pm
Hopefully Saturday I'll have a Plugins functional and a sample plugin finished so I can do some testing. I'll still have to do a lot of work in the Plugins application, but that is stuff I can take a little longer to iron out. The first official plugin will probably be part of a Comments application. I'm still trying to decide if I want to use a 3rd party service for comments or write my own. I'm leaning toward writing my own. I wrote one about 7 years ago, if I do, I at least have an idea of how to do it. Once Plugins are working, I have a few directions I can go from there. The form plugin will be part of the objects app, which is a 1.0 goal. I also have the editors and dashboard to migrate from services. There are several base apps I want to make, such as articles, a photo gallery, a forum, categories, and a solid menu application. I'll more than likely jump around a little and work on cleaning the code base up while I do all of that. Plugins are going to be a little simpler than I originally planned, as far as complexity goes. It's going to take some testing to make sure there aren't any hidden bottlenecks though. Progress continues :)
I try to build toward speed first. It's not always the sexiest approach, but sometimes smaller is better. In this case size doesn't matter. One of the features of Clay's module system is the ability to plug in submodules that act like on-demand APIs. The best way to use them is to structure a module's base class toward use cases instead of direct need. For instance, the Plugins module has a Get() method that pulls in a submodule class object. Now an entire class of methods are only loaded when I need to use Get (). It also has methods for implementing a hook or installing a plugin from an application. Without submodules over a dozen methods would all be in a single class, most of which only get used a fraction of the time. Why load all of those methods when they likely wont be used? SubModules make this happen on-demand, with very little base module code. Today I expanded SubModules capability by adding a new class that supports object classes as SubModules as well. Previously only static classes could be used. See the library/Clay/Module folder to view the code. The API class supports static classes (to stay inline with other Clay functionality) and the SubModule class supports objects. The Setup module employs similiar functionality, but without using SubModules (currently). Clay may have a few bottlenecks here or there, but the base is by far the fastest framework I've seen or used and that's sexy.
4:01 pm
By the I posted my 200th blog entry here. That has to be a record for consecutive posts on a single CMS :)
3:59 pm
The Clay Framework repo on github is about to get some action. I'll soon be merging all of the core libraries from Clay tothe Clay Framework. It will get a default base app and a base configuration that will work out of the box. I still havent decided if I want to merge the installer into it yet or just make it all a manual set up. The goal is to have a Clay Frame 1.0 release sometimw before the planned Clay 1.0 release.
3:51 pm
I've been working on the Plugins module for Clay. Once I have all of the APIs in place and the file structure figured out I'll move on to the Plugins app and begin adding some plugins to the repo. I've tabbed a few services to be migrated to the Plugins system as well. Eventually I plan to make Services a backend task-like system.
I recently bought a new laptop that shipped with Windows 8.  After some difficulty setting it up for PHP development, I decided to do a manual setup.  Keep in mind this was with binaries, I didn't compile from source.
Here's how I did it:

Apache 2.4 -
  • recommends downloading from
  • The version I downloaded was Apache 2.4.9 Win64
    • Get the latest version available.
The download is a zip file, once it's completed extract the files.  I tend to upgrade kind of often, so I decided to use my home folder for the install.  I simply created a Servers folder in my user home folder.  You can put t where ever you like. My Apache folder is: C:\Users\david\Servers\Apache24, which I named because if i test Apache 2.5, I will likely leave 2.4 just in case.

Now navigate to [apache]\conf and open httpd.conf. Scroll down to ServerRoot and set it to the path you have placed your Apache files.  Mine is: ServerRoot "C:/Users/david/Servers/Apache24".  This is the folder your Apache server is currently residing, not where you want to serve files from. 

Now scroll down until you see a lot of LoadModule lines. You'll notice a lot of these are commented (#).  Remove the comment in front of the ones you want to activate.  LoadModule rewrite_module modules/ was the only one I needed at the time, so I enabled that one.

Scroll down to DocumentRoot.  This is where you will serve file from, in my case it's a network hard drive.  If you want to serve from a local disk, you wrap the path in quotes, if not, then you don't.  Mine is set to a network drive: DocumentRoot //mybooklive/www/htdocs.  Generally your DocumentRoot would be something like: DocumentRoot "C:/Users/david/Servers/Apache24/htdocs".  

The line below that one should begin with <Directory, simply replace/append your new path to it: <Directory "C:/Users/david/Servers/Apache24/htdocs">.  Below you will see AllowOverride, if you want to use .htaccess files, set it to AllowOverride All, if not then leave it alone.

Further down the file you will find a <Directory line that has cgi-bin, modify it to show your DocumentRoot, with ci-bin at the end (even if you aren't planning to use it -- just in case).

That's all for Apache setup (for now).  Later we will add a few lines for PHP support, but we're not there yet.  Add an index.html file (if you aren't using the default) to your document root and add some text that says It Works! or something like that (mine said: NASSSSSSSSSS, yeah!). Now open the httpd.exe file from your [apache]\bin folder, then navigate to localhost in your browser.  Hopefully it works... 

to be continued....
After quite a bit of testing, I have decided to scale back my plans for Data Objects. There has been some performance cost in the current implementation that I am not willing to spend. Instead I will finish implementing the plugins system and supplement the DO functionality as a hook, spreading it out over multiple plugin types. DO's complexity simply doesn't fit the model for Clay. DO actually fits the bill for a different type of CMS that Clay could potentially evolve into. I'm not all that thrilled to cut back on the idea of DO, but it still gives me a goal to some day work toward. The good news is a simpler approach should enable me to crank out better features and apps, instead of spending the next couple of months finishing DO.
I haven't named the project yet, but I am working on a new way to encode data in relational databases. The premise is there is only a certain amount of data that can feasibly be encypted/decrypted and processes. That means if someone gains access to a database they will inevitably be able to see how relational data across tables is related and therefore exploit that data. A solution I am working on to solve this problem is to have a PHP class that encodes/decodes item ids, thereby making data appear to not be related or random. The class would generate a new encoded id for a particular decoded id and use it for an instance of related data, never referencing the legitimate item id in the database. Why? Because even large corporations (Ebay, Target, etc) have a hard time protecting data. You can't only depend on connection security to protect it. Direct encryption can only be used to the extent that it can be processed, you cant encrypt everything. It was announced today that Ebay was hacked and someone potentially has user data for 150 million Ebay users: their names, birthdays, user names, email, addresses, passwords, etc. Someone has the data (potentially) and could easily build a script to navigate that data. If item ids were different in every table, it would be likely impossible to ever discern how all of that data is related. This new project isnt intended to encode every id, that would likely become tedious for even the server to discern. The idea is to apply it to sensitive information, but it could be used on a broader scale to an extent. I'll keep you posted on the progress.
Unless you've been following my blog a while, you may not realize there are 2 hierarchies of Clay: the underlying libraries and modules that make up Clay Framework and then the feature level, formerly known as Clay CMS, simply called Clay. Early on in devleopment I would maintain them separately and pull updates into Clay. Over time I stopped maintaining both and began using just the Clay codebase. Once Clay reaches 1.0 status I will trim it down and release the framework as well. This is important because I will then begin moving the framework toward 2.0 and the process will start all over with 2 codebases. As I get closer to 1.0 I can't help but think of what needs to be added or changed. The plans for development of Passage will bring in a whole new dimension to both. It will require a new REST api and several template engine changes, plus some other major core changes. I also hope to build in composer support and a built in code management system. The code management functionality will be split between the framework and the Installer package of Clay. The goal there is to provide a scaffolding system for creating sites and applications, while also providing a built in IDE. Only time will tell if all of that makes it into 2.0 though.
5:03 pm
One of the side projects I'm working on is a github integration tool. Along with showing an activity stream I also hope to build in a change log generator for releases and a hook to create digest blog entries. Just a nice feature to have, but it's also a way to test Data Objects while I build that as well.
By the way, I hate doing this, because I never seem to make my deadlines, but I'm doing it anyway.

Clay 0.9.50 to be released on 1 August, 2014.  

Followed by some minor releases and bug fixes.

Clay 1.0 to be released on 1 January, 2015.

There, I set a goal.  Clay 0.9.50 is the milestone release for Data Objects, followed by integration releases and whatever fixes are needed.  I hope to do a release a month from August until the 1.0 release in January.