As of today, I've stepped down as full time Developer for MODX. It's been a helluva ride over the past year, and I don't regret taking the opportunity to work with this team at all. In the past months, a huge amount of attention has been shifting to MODX Cloud and while Cloud is a pretty cool platform, I'm more of an open source guy. The closed nature of Cloud has been quite frustrating at times.

To ensure support continuity, I'll continue to hang out with the MODX Cloud team for some time to provide support in European timezones, leaving plenty of time for cool initiatives and learning new stuff as part of my own business. I've got some exciting things planned for the future which I can't wait to share with all of you (no teasers yet tho, sorry!) and I'm looking forward to spending more of my time with the MODX community. I'm also launching a new iteration of this site with a cleaner design and more focus on the content soon!

I'm sure some of you will be disappointed hearing this, but I am not planning on going back to a lot of freelancing, like I did before I joined MODX. I feel that I've neglected or postponed a lot of personal projects for far too long, and this is a great opportunity to revive and maybe even finish some projects for a change! ;) I will consider super awesome projects of course (especially if they are directly related to personal projects), so feel free to shoot me a message if you have a great idea.

As I realize this is quite a short blog post, here's one of my all-time favorite videos for your watching pleasure.

(A sequel to my jQuery Manager post is coming really soon, I promise!)

After deciding that "learn about unit testing" was going to be my new years resolution, I just went on with business as usual and pretended nothing happened. Now, a year and a bit later, I finally did what I promised myself I'd do at the start of 2012.

It may have been the recent migraines messing with my common sense, or Chris Hartjes' relentless battle for unit tested code on Twitter, or having randomly picked up his building testable code ebook during sale a few weeks ago, or the voice whispering in my head that I would be in big problems if at some point in the undetermined future a very crucial "calculateTotal" method would end up borked.

I'm not sure what, but something triggered it.

Learning Unit Testing with PHPUnit

So last weekend, I set out to finally learn how to unit test my code. I was going to start with baby steps. Just this one calculateTotal method that I was worrying about. So I grabbed my ebook, read it, and opened up Terminal to follow the instructions.

By the end of the day I had ran out of unique cursewords, nearly wiped my entire MAMP-powered localhost and had given up on unit tests completely (about three times).

Oh, and I also added unit tests covering pretty much all methods in this (admittedly still small) project.

You know, unit testing has always been one thing that I never considered vital to a project. I am careful when I release stuff, and every fix gets tested properly. In the browser, clicking around. Reading code extra carefully. PHPStorm's excellent code sniffing. Nothing major could possibly slip past that.

PHPUnit forced me to reconsider.

Discovering Bugs that couldn't possibly exist

I initially thought I broke PhpUnit (again) when it was telling me that a certain sanitize function wasn't living up to the tests. I had previously tested it, and while stepping through the code, it all looked fine. It must have been PhpUnit. But no. It turned out the entire method was busted in a very subtle way, and it basically left my entire app wide open to XSS and CSRF attacks and possibly even worse. My first, and quite crucial, line of defence was broken from the start without me even knowing.

If I hadn't unit tested that method, I would have quite possibly never figured out it was this badly broken, until someone else did (accidentally or on purpose).

I also wouldn't have found two other major (and similarly hard to spot) bugs in other code that I considered solid. This code also passed my "clicking and reading" test before.

So, if you write code but don't unit test it yet because you are already testing your code, it's time to fix that.

Steps to Take

1. Get Chris Hartjes' book: The Grumpy Programmer's Guide To Building Testable PHP Applications. It's a great and easy to read ebook that covers basic and more advanced object oriented programming methodologies that make it so much easier to test code. It's loaded with examples too. If you don't know how to apply dependency injection yet, you have no excuse not to get this ebook. He's also working on a new ebook specifically about testing with PHP Unit.
2. Take/plan some time to read about and get phpunit running on your machine. This was by far the most troublesome thing I had to do and what caused the swearing and almost nuking my entire localhost to start from scratch.
3. Set some goals on what you want to test and just do it already. Start easy - take one vital method and test if every line works as expected. I wouldn't suggest going for 100% code coverage right away; give your new testing addiction time to grow and to get better at writing tests.
4. Do it. And tell others who don't test code yet, to start doing it too.

I've been in the camp of "I already test my code" for a long time, but I've finally experienced first hand the power of automated unit testing.

It's good to test and think your code is working, but it's awesome to know it actually is, too.

The MODX Manager interface is a very rich interface: there's right click options all over the place, modal windows are pretty much second nature and dynamic validation and AJAX submissions make it a very interactive experience. The design is easy for clients to understand, yet it offers the power users even more power to do the things they need to do. All of that is powered by a library called ExtJS, developed by Sencha. As a very powerful JavaScript framework it generates virtually everything you see in the MODX manager. A newer version is also used for the MODX Cloud Dashboard.

I've been learning ExtJS since 2010, every since I got interested in MODX Revolution development and extending, bending and plainly hacking the sh*t out of it. Tutorials, lots of code gazing and client projects, and over two years later I feel like I'm comfortable with what it can do and understanding the often cryptic errors. At some point, it starts becoming a source of frustration. And I can boil that frustration down to one sentence..

I love ExtJS for what it does, but I hate the way it does it.
~ Mark Hamstra

ExtJS is a dream

Don't leave yet! At least hear me out on this one. After having spent 2+ years learning ExtJS and its implementation within the Revolution manager, I am convinced it's a developers' dream. I totally understand why it was chosen to power Revolution back in the day.

1. Rapid prototyping and interface building. Just define (basically) a big array, and you have a fully functional interface, completely blended in with the rest of the manager.
2. Packs a large amount of widgets that are infinitely configurable and customizable.
3. Through its object oriented philosophy, you can easily reuse other definitions in an object oriented fashion and save the hard work. Define a widget once, use it everywhere.
4. ExtJS makes stuff work and look fancy across browsers.

In a nutshell, ExtJS is an insanely powerful framework that makes fancy stuff easy to achieve. It takes time to learn (and I bet a more senior developer would pick it up much faster than I did), but once you bridged the learning curve you have a lot of power at your fingertips.

ExtJS is a nightmare

1. It's obviously a JavaScript framework, and ExtJS builds the interface from JavaScript definitions. There are exceptions where you can take existing DOM elements as basis, but you still need to use (and load) all the JavaScript to use the interface as intended. If an error occurs somewhere, ExtJS tends to decide to show an empty page instead.
2. ExtJS builds elements with a shitload (yes, that's a technical term) of divs and tables. Here's an example an actual "Save" button. My guess is that it does that to make it look good cross-browser, but it clutters up the DOM and makes it more difficult to cleanly create a custom theme with crazy inheritance and royal class-soups. Truth be told, this seems improved in ExtJS 4.
3. Similar to the previous point, sizes are *very* often defined inline (style="width: 134px;"). This could be helpful, but it isn't one bit if you try to build a more fluid layout.
4. The ExtJS learning curve is quite steep. In the context of MODX Revolution, this harms community involvement as the amount of developers improving the core is small, and takes a long time to grow. In a proprietary environment (such as MODX Cloud) this isn't a huge concern as you can invest in training and hire the right people, but I'd argue it is a huge problem in the open source scene.
5. The ExtJS licensing has historically been vague, at least in our context.
6. ExtJS is slow. Not only does it have to load a few megs would worth of javascript before it can even start building your interface, but it's not particularly fast in doing that in many cases.

Despite being a big proponent of ExtJS for the reasons mentioned earlier, over time I have become more frustrated with the cons of the framework that I believe are doing serious harm to community involvement in Revolution. Learning ExtJS has been a great business decision (it made up probably a good 85% of my freelance work), but as I'm a big community fan I'd rather see something a bit more.. approachable.

The Ideal Framework

So, taken the above considerations, what would be The Ideal Framework for a MODX manager? Here's my personal list of requirements.

1. Easy to get started with, plenty of existing documentation and tutorials.
2. Easy to extend and capable of Object Oriented paradigms to cut on development time (rapid prototyping) and code duplication.
3. Large set of available widgets to build interfaces with, but with a lean core.
4. Fast.
5. Progressively enhanced so that users with old browsers can still get a proper experience. As it's a backend I'm fine with it requiring JavaScript, but regular HTML and CSS should provide a baselevel experience.

In my mind (and I can hear sighs coming), jQuery fits a large number of those requirements. Getting started with it is easy, documentation and tutorials are everywhere and the amount of widgets (plugins) available for jQuery is enormous. It easily lets you use progressive enhancements paradigms and considering JavaScript itself is an object oriented language, yes that applies to jQuery as well.

Does just sticking jQuery into the manager provide a maintainable product? No; it needs more thought. The manager is big and complex and just filling up a footer with $(document).ready() tags wont make things better than ExtJS. But I do think a properly implemented object oriented "wrapper" could definitely be what MODX needs.

And that's what I started mocking up.

Introducing a jQuery Based Manager

If you follow me on Github, you may have noticed some recent commits to a new alternative-manager branch in my Revolution fork. This contains a Proof of Concept of how I think a jQuery-object-oriented-wrapper-framework could provide a better experience for the MODX Manager.

So far only the manager login and dashboard has been (mostly) converted, but it's a lot of work. Everything that can be represented as plain HTML/CSS is being converted to that, while other bits of HTML are being used to load up widgets based on a "data-role" attribute.

My first impression of this proof of concept is that it would definitely be powerful, lean and extensible enough to replace a heavyweight like ExtJS, without getting stung by the downsides of the framework. So far (at an early state, obviously), my jQuery alternative sure feels smoother and faster than the ExtJS one too. It needs a lot of work, and tearing out ExtJS of the manager sure is more work than just removing the files, but my belief is that in the end it would be worth it.

So now what?

Now.. I want your feedback. What do you think about ExtJS; and my jQuery-based alternative? Would you support (and better yet; help out) an initiative like this, or am I being a pity fool? Do you want to see a demo?

Depending on your feedback, I want to publish a couple blog posts in the coming weeks on some of the decisions I've made so far and what I think the implications of them are.

Just to prevent any rumors: no I was not asked to work on this for my job at MODX, nor does this proof of concept mean that jQuery is what will power MODX in the future. It's me being curious if jQuery could be a practical alternative and at some point a few weeks ago deciding there's only one way to find out..

UPDATE T+45mins: Despite publishing this article at a time where people are either enjoying a nice drink or a comfortable bed, the response (in the comments, on twitter and on skype) has been awesome! Please do keep it going and let me know anything you'd like to know about the jQuery manager in the comments below. I'll try to answer as much questions about that in a follow up post in the next week or so. Of course, feel free to just go ahead and have a look at the JavaScript. I'll also look into making a public demo available.

Do you know those features some people have been requesting for a long time, and when you finally sit down to build them, it takes no more than 30 minutes to code the first version? This latest one definitely falls in that category.

Getting Groovy with the CLI

See, not everyone wants to use a nice GUI to manage their site. Some people are hardcore, and would rather use the commandline. Rawr. Truth be told, I'm not one of them, but here's a goodie for the people that do.

modCli is a command line php script enabling you to run any of the MODX processors from a (ssh) terminal, in just shy of 180 lines of code (including comments). After you dump the file in your MODX_BASE_URL, you can start running processors from the command line. It's kind of like Drush for Drupal, but then for MODX.

Examples

While you can find exact usage instructions and some other examples in the code, here's two quick examples as to what you can do with modCli.

php modcli.php resource/create pagetitle=Awesome! parent=6 content=Awesomer!

php modcli.php workspace/packages/getlist limit=1 start=2

Security Concerns

As to my knowledge you can't have sessions in a Terminal, this script basically bypasses the login process for MODX. Yes, you read that right, it just loads MODX in API mode, in the mgr context, which in my tests gives it full access to everything.

While it's a nifty tool which in some cases can be very convenient (I still prefer shiny buttons), do NOT EVER EVER EVER leave this available in the root of your site. Even better, don't put it there in the first place, but adjust line 44 of the script to point to your MODX install from, say, a non-web accessible SSH-only directory.

Disclaimer: use at your own risk and don't come whining if the script worked as intended for someone else, too.

Get the Code

I want to make sure you read the security concerns above before I even tell you where to get the code from, or how it exactly works. Only tick the box below if you did!

Yes, I read the security concerns above!

Happy New Year!

As the last post of 2012, it's my statutory duty to wish you a happy new year today. My hope for you is to make the next year at least twice as ambitious, successful and awesome as 2012!

Of course there's no way to say goodbye to 2012 as with an old fashioned list of what went on in 2012. So without further ado, here's the top 5 most visited blog posts in 2012:

• How to: Managing Galleries with MIGX (April, 2012)
• Caching Guidelines for MODX Revolution (October, 2011)
• How to: Listing Articles posts with getResources or Wayfinder (February, 2012)
• modExt versus ExtJS and their Documentation (January, 2012)
• Bringing Dropbox to your MODX Media Sources (January, 2012)

I challenged the community a while ago. If we would hit 200 documentation bugs in the tracker, I would spend two full days working on closing as many as I could. Even though it received some good response and the amount of bug reports went up quite a bit, we still didn't hit 200 yet. But that's okay, cause now we have even better initiative: Documentation Friday.

Meet Scott Borys.

Scott Borys is many things. He's a web developer, hitchhiker, blogger and (even though I never met him in person) I'm pretty sure he's a genuine nice guy, too. 

He just happens to build sites in MODX, and has recently single-handedly created a new recurring initiative causing all sorts of uproar in the MODX Community. The good kind of uproar, that is. The kind of uproar that impacts people's experience with the MODX system, most likely without them realizing it!

Introducing Documentation Friday

Take one avid tweeter, who goes in and fixes documentation issues, while live tweeting the progress and involving members of the community in doing so. That about summarizes what Documentation Friday is. It's a continuous effort to improve the documentation based on bug reports and new tutorials about specific subjects.

Like last week, it usually starts with something like this:

gooooood morning #documentationfriday. Who wants to help make #modx documentation amazing? Hit me up for something to do!

— Scott Borys (@scottborys) October 12, 2012

And ends up with some very important updates to the MODX RTFM.

One very interesting side effect that Scott mentioned to me on Skype some time ago (and which I can attest to myself as well), is how writing documentation is a great way to learn and to be sure the information you need is available for reference. Win-win-win!

It's been phenomenal for increasing my working knowledge of MODX. It also makes me happy whenever I need to check something that I *know* is in the documentation because I wrote it.

— Scott Borys, September 28th, 2012

Join the movement!

I've seen various people in the community hitchhiking along with Scott on this amazing initiative (see what I did there?), and I'm hoping that we can kick this into gear and make this a real weekly thing that we as a community help out with. It would be awesome if everyone would hop on board and start fixing things, but even if you just report issues with the documentation so the editors know what to do, that would be fantastic!

So yes, I am going to sunset my Community Challenge in favor of #documentationfriday, in trying to get at least an hour of documentation work in every Friday. Or at least a #catchupsunday. 

@scottborys I am up for round two! My Friday was insane but I am planning on a #catchupsunday!

— Anne Miles (@redtoadmedia) October 13, 2012

Scott; thank you so much for doing this and being such an amazing part of the MODX community. I hope this initiative stays around a long time! Oh, and if you ever end up hitchhiking and couchsurfing in The Netherlands, just give me a call: you're very welcome to stay here for a while. (I know you wouldn't mind me staying at your place either!)

As the first work for this event started ages ago (early 2012), this post is way overdue. And I've been neglecting this blog lately, too.. But if you've missed the announcements so far, please allow me introduce you to MODXpo Europe!

What?

MODXpo Europe is a one day (two if you count the friday night social) event on November 10th, 2012. Similar to the MODX event in Dallas two and a half years earlier, it's the premier event where MODX users, community and team get together to talk about MODX, MODX, MODX and a little more MODX. Less than a month left to get your tickets!!

Who?

We're seeing all sorts of people signing up for the event. All the way from hardcore back-end MODX Developers and front end integrators to entrepreneurs and project managers.

This mixed audience is also equally represented in our speaker line up. We've got several well known developers such as Menno Pietersen and Bert Oost speaking about front and back end subjects, while community rockstars Bob Ray (who also wrote a book) and Susan Ottwell also fly in from other continents to talk to you about a range of subjects: Evolution, Building sites in Revolution, Packaging Extras and the Revolution Security Model. We'll also hear about what clients need to know about MODX from Skytoaster PM Matt Fuller, and I will personally share my experience of Building Extras for MODX as well.

That's just a quick sample though, head over to the MODXpo.eu site to view the entire schedule.

When?

Saturday November 10th, 2012, from 8.30am until about 8pm. For those in town the night before, we will also be announcing a social event on the Friday night with sponsored beer and snacks real soon.

Where?

Cursus- en Vergadercentrum Domstad, Koningbergerstraat 9, 3531 AJ, Utrecht, The Netherlands, Europe. View on Google Maps or on the MODXpo Website.

If you need a place to stay, we've collected a couple of hotel deals in the area for you, so be sure to check them out!

What are you waiting for?!

Get your tickets today (only € 39,95!), and see you in November!