The problem
I was building websites with tight timeframes, no budget, no design specs, frantically copy and pasting then re-inventing code to enable similar functionality.
In the early days, at NZ Police, downloading a CMS from the web was not an option, so I had to come up with the solutions myself.
Later at Chromtoaster we were using CMSs from the web. Joomla!, Drupal, WordPress were all fine for doing what they were designed for. But what I was building almost never fitted the intended use of the product.
0 So I had to hack into the core code of the system to make it do what the client wanted.
This was a scary place to be. I still had tight deadlines, and now I needed to get my head around a whole new way of doing things.
I had to fix bugs, security holes you could drive a truck through, and conflicting logic before I even had the chance to build the requested features.
Inevitably this took much longer than if I had built the system myself from scratch.
What I needed was a CMS that did the core things well, securely, that was flexible enough to adapt to the different coding problems we were given. Since I was not the only developer there, it should also be able to be used by other developers in a way that suited their coding styles.
DevCore development began in earnest half way through 2008 after particularly bad experiences with Drupal, and then Joomla!
The solution
I spent my weekends and free time after work designing, building, refining my idea of a core framework that would suit my needs.
I was about two thirds of the way through when we had a project come up that was just right for a test of the concept.
I was given the go-ahead to use DevCore for the website, and started building the site.
It was one of those rare builds where I had all the information I need up front. I knew exactly what I had to build and what functionality was required.
Less than ten days later the site was up and finished (from a developer perspective). Everything worked as it should, all that was needed was for the design to be applied.
Our front end wizard was able to apply the template to the site running live data and videos, which made his job much easier.
This was easily the fastest, most enjoyable site I have ever built. And the client loved it!
Shortly after, the client wanted another version of the site. This one would run a bit differently, but still operate in a similar fashion. This build was even faster. It took an afternoon to set up a new instance and make the necessary changes.
My colleague wanted to have a try with the CMS on a new site he was building, so I gave him a copy of the code and watched as he installed it.
Shock Horror!!
He changed the folders where my code was based. He changed file names to suit what he wanted. In the space of five minutes my lovely structured code was all over the place.
He pulled up the home page of the CMS and naturally he had errors, files not found etc.
It took ten to twenty minutes to change some system constants and test the site structure fully, but in the end he had the site working again.
But now it was in his paradigm, with his folder structure, his filenames, his was of doing things.
That's what this is all about!
We were both quite excited about where this would lead for us as developers. Our lives were about to become a whole lot easier.
Then the recession hit.
With redundancy came new opportunities, for me and for DevCore.
I began a contract at NZTA working with the web team to build their new website.
This was a huge build, as it had to pull together the content and tools from two government departments in a way that satisfied all parts of the business and still served their clients, the public.
There were other challenges too. I was working alongside another developer who did things very different from me. And I must say I learned a lot from him. Some of the simplicity in this evolution of DevCore comes directly from the way he did his coding.
We were using SQL Server instead of MySQL and since he had already written a fully functioning database interface layer, we decided that it would be best to use that and just lay the DevCore code alongside it.
We agreed on an interface between my code and his and then went for it, developing independently, in our own styles, on separate parts of the system.
This worked quite well.
One of the big problems I faced at NZTA was with PHP's var_dump function. It works fine in Apache, but under IIS it frustratingly only gives you a partial dump.
And the error reporting was just a pain.
So I began working on the idea of self reporting objects that give meaningful messages. Now all DevCore object have the ability to dump their contents elegantly.
There were parts of the system that needed authentication, so the authentication module for DevCore was implemented in his code to take care of that.
This showed the true flexibility of the DevCore concept. We could take the parts that we needed, change them to suit the specific situation, and implement them in next to no time.
We finished the website on time and when it launched everything worked fine.
There has been ongoing development since then, with the team being able to follow the pattern with minimal training. This is also another feature I'm proud of - simplicity.
With a structured approach it is very easy to pick up the concepts and follow the flow of the code.
My next contract was for Marselme, a high end merino wool clothing site that specialises in clothes for babies and children.
For the first few months of 2010 I worked on the site on a part time basis, as they were going through changes at the company, dealing with designers, and generally have a very frustrating time.
I began incorporating some solutions into the build to problems I had faced at NZTA. DevCore was getting easier to work with every time I tried something new.
The site went live and the clients were very happy with it.
Now I had some free time, I started from scratch, building a codebase with the idea that instead of being a fully featured CMS, it would be a collection of modules that can be used by themselves or combined to make the CMS.
I also wanted a configurable var_dump function and smart caching, and I wanted it built into everything from the start.
So that's what I did.
The base component class that is the parent class for everything in the system has the var_dump functionality built in. You can also cache just about anything, from database calls, objects, pages, whatever you like.
The other feature that I just love, is the debugging panel. This is a panel for showing all the debugging information you have requested. Because its location is set using CSS you can put it wherever you like.
I put it on the right hand side so I can see it alongside my page. Set the page width to 50% and the left position of the debug panel to 50% and you have the debug panel alongside your page. Set them both to 100% and the debug panel sits off to the side of the page, out of the way until you need it.
So useful!!
So here we are now. It's the middle of 2010 and the code is now available to you to use, modify and have fun with.
So grab a copy and see what it can do for you.