A Tale About The Jaeger PHP Framework
Last year, when I first started development on rewriting Backup Pro to be CMS agnostic, I knew I'd have to write a ton of code to do what I needed.
Not all of it though; as thanks to Composer and Packagist I'd be able stand on the shoulders of quite a few giants, but the CMS agnostic stuff didn't exist. So creating that was a huge part of the job. But I did it, and I was able to release Backup Pro 3 for Craft and EE 2&3 last July (a year ago exactly it turns out).
And then my world exploded.
It quickly became apparent I was onto something interesting with the CMS agnostic library. Nearly every programmer I knew was curious about it and had questions. So I thought I'd put a post together and lay it all out; the flow, the logic, a few examples, and then get back to work on the WordPress version. But then I did something really stupid; I started thinking about the possibilities, and, even worse, I started thinking about responsibility.
The Possibilities
I'd spent the last 5 years working with ExpressionEngine almost exclusively. I was still doing some custom, framework based, projects but for the most part nearly everything I did was ExpressionEngine based. Oh. And the odd Craft site. And a few WordPress projects actually. And then there were those Magento and Zencart ones… Oh. Shit. And a Drupal site came up once I couldn't get out of too, now that I think about it. So I use quite a few CMSs professionally.
And that's actually not uncommon, at least for a specific subset of programmers (agency and freelancer programmers to be precise). For me though, I was working on all these systems for years, learning all their libraries and peccadilloes, and constantly reinventing the wheel(s) I invented last week. For example, ExpressionEngine 2 is CodeIgniter based, Craft is built on Yii, Magento is coded with evil in its heart, and WordPress is a time warp to a scarier, but oddly more comforting, time, so nothing's organically portable between them. Developers can't take most EE/Wp/Mag/etc code and use it in another CMS without a LOT of pain and overhead. And that's true across the entire CMS spectrum.
But, what if you could? What if there was a way to create CMS agnostic add-ons?
Agnostic development isn't exactly an unheard of idea; the video game industry does it, to mixed results in the past admittedly (but they've gotten better), so it is doable. It's also a job though, certainly, but with a bit of elbow grease, theoretically possible.
Not exactly a universal paradigm though, is it? For tools like Backup Pro, it makes sense, but abstract concepts like data models and front end architecture pretty much preclude even attempting most content based add-ons. As an example, Export It, my data export module for ExpressionEngine, would be painful to make CMS agnostic since it relies on the individual CMS data model(s).
So I went to Reddit and asked r/PHP what the PHP developers there thought of the idea. And… got a resounding meh… Some liked the idea, others didn't, but I didn't leave thinking it'd be stupid to do, so chalked that up to a win. In the “ask your mother” sort of way, but still, a win nonetheless.
Our Responsibility As Programmers (Time to Get Preachy For a Minute)
Now, up to this point, all the above was a nagging itch on my brain. I had an idea others would find a CMS PHP framework useful, but being so busy with Backup Pro, the product, my time's finite. Do I even have time for something like this? And, seriously now, what benefit is there, to me, for doing it? Taking all the time to not only build a PHP framework, but also release it, document it, maintain it, nurture it, and promote it? And, worse, I have a long standing policy that I get paid for my time spent working. All my time spent working. Dammit.
So, what benefit would there be for me to put this together? Some people may say it's marketing. “You'll sell more copies of Backup Pro through simple association”, is a common refrain. And that's probably true, but only up to a point. I don't have numbers, obviously, but it's tough to imagine HelpSpot flew off the shelf because of Laravel, or ExpressionEngine's success was due to CodeIgniter (in fact, did you even know HelpSpot was the benefactor of Laravel?). The people who care about such things aren't traditionally known as the same ones who have purchasing authority is my point. So I don't really buy that.
But then I recall, once again, that my career is built on open source. I write code in PHP, to deploy on Apache web servers, that use the MySQL database, rendered using HTML, CSS, & JavaScript, abstracted with jQuery and Less/Sass, and viewed primarily on Webkit, Blink, and Gecko based web browsers (we're still pretending IE doesn't exist, right?).
Put another way, my career is built on open source (and the developers who put their lives into it) so it's selfish as fuck for me NOT to give back.
Dipping a Toe (Again)
So… I did it… Jaeger, officially, exists.
I'm not sure how successful I was, but a bare bones 0.1.X version exists up on GitHub now as jaeger-app. It's also on Packagist (and Travis and Scrutinizer…) as well, so it's ready for Composer use. And, to make matters worse, and throw a little more skin in the game, starting from Backup Pro 3.4 (which is in developer preview right now), Backup Pro will be Jaeger based. So I'm going all in at least insofar as Backup Pro is concerned.
I'll put together some detailed examples later, but for now, I just wanted to put it out there that Jaeger exists and is ready to start poking at. You can get Jaeger from GitHub and Packagist.
This post is sponsored by Backup Pro. Find out more on their website.