Hello! Welcome to my humble web presence. I'm Mark Hamstra, 29 years young, wearer of many hats at modmore, resident of Leeuwarden, the Netherlands. Most of my time is spent building and maintaining awesome extras and tools at modmore, but I also love gaming, cooking, and my dogs. More about me.

This site is where I share thoughts, cool projects and other oddities related to MODX, xPDO and ExtJS. I also write about MODX regularly over at MODX.today. Sometimes I post three blogs in a week, sometimes there's nothing new here in a year. Read a random article.

Sometimes you need to define multiple criteria in xPDO schemas to make sure your relations are properly defined. I came across this while working on a project that needed some existing databases integrated. This specific case had one "fl_translations" table that contained the translations for thousands of objects. To get the translations for a specific object, you would need to filter that table on the "originaltable" field. For example, one row might have originaltable=fl_colors and contains the translation for the color in a specific language.

In order to properly define this relation, I went browsing the MODX core schema for some ideas, and I stumbled across a pretty much undocumented feature of xPDO Schemas: relation criteria!

Here's a snippet of the final schema:

Basically, while with a normal relation you would immediately close the <composite> (or <aggregate>) element, but if you want additional filters (criteria) on the relation, you can define that. A simple <criteria> object with a target (I presume but haven't tested that you can add an additional <criteria> object with a target of local), and inside it a JSON object with the fieldname (of the foreign object) and the value it should have (in this case, fl_colors, as that's how it was set up).

This way of defining relations is very powerful and I imagine some really complicated relations could be defined once (in the schema) and reused without knowing all the details by simply calling getMany('RelationAlias').

The core uses this type of relationship for defining the PropertySets relations on elements and also in the modAccess definition. For example, here is a snippet from the core schema for modChunk:

xPDO is quite nifty eh?

Ever find yourself having so many tabs open in your browser, that you can't see what is what anymore? I just had that and ended up going into the wrong MODX manager tab to make changes. Argh!

Luckily there's a simple way to give the MODX Manager a distinct favicon if you want to, and if you find yourself in some sort of tab-ception and can't find the right tab, I encourage you to do the same.

Simply open your (Revolution 2.1 or up) manager, and head over to System > System Settings.

In the search field in the grid toolbar, type "favicon" and hit enter. You should find the manager_favicon_url setting.

Double click in the value column to open the editor, and then add either the full URL to your favicon, or an URL relative to the manager directory. In the screenshot below you'll see I referenced an icon for the modmore site - this shows me that I'm in the live site and not my local install I was working on..

Other urls that may be a nice fit for your manager (all of these ship with Revolution):

  • templates/default/images/modx-theme/grid/group-by.gif
  • templates/default/images/modx-theme/grid/hmenu-lock.gif
  • templates/default/images/restyle/icons/context.png
  • templates/default/images/restyle/icons/computer.png
  • templates/default/images/restyle/icons/database.png
  • templates/default/images/restyle/icons/disk.png
  • templates/default/images/restyle/icons/layout_edit.png
  • templates/default/images/restyle/icons/plugin.png
  • templates/default/images/restyle/icons/resources.png
  • templates/default/images/restyle/icons/template.png
  • templates/default/images/restyle/icons/user.png

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.

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.


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!

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: