Hello! Welcome to my humble web presence. I'm Mark Hamstra, 28 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.


There are times you will want to accept donations or payments on your MODX-powered sites. In my case I wanted to offer the possibility for users to donate towards one of my open source projects. So I whipped up a snippet to help me do that.

My requirements were simple.

  1. Customizable form to match layout
  2. Simple 2 (3) step procedure: type in amount, make donation, thank you.
  3. Ability to display a configurable "thank you" message
  4. Some kind of "posthooks" allowing you to (programmatically) do other stuff based on a donation. For example when people donate for HandyMan, I want to be able of creating a user account for them so they can access the HandyMan member only area (in the somewhat near future, that is). I don't need that for others, so it needs to configurable :)

After spending some time figuring out the PayPal API calls to use for these requirements it was finished pretty quickly, and the open source landing pages on this site now have one of those forms each.

How it's done (slightly technical)

The package (which I called mhPayPal as I needed a name to get started and didn't try to come up with something more fancy, open to suggestions in the comments!) consists of 2 snippets. One snippet, makeDonate, is used to display the form. It basically wraps a chunk which contains a FormIt call and the html for the form.

The second snippet, makeDonateHook, is registered as a posthook on FormIt which is triggered when the form is submitted. It takes some properties (via the FormIt call) and of course the amount and currency. It then uses a slightly modified version of this PHP PayPal class by Drew Johnston (which is the same one I used for SubscribeMe) to send a SetExpressCheckout API call (which prepares the token for the checkout) with the filled in and calculated data.

After redirecting to PayPal, and returning to the same page you were on when filling in the form, the makeDonate snippet will intercept the request and once again use the phpPayPal class to confirm the payment (DoExpressCheckoutPayment API), and to show the success message. Under the hood, there is data stored in the MODX cache to be able of matching data against the right token.

Does it work? Can I use it too?

Yes, and not yet!

You can see it in action on one of my open source pages (be aware that the forms are live though - I appreciate your donation :P). As I'm not entirely done with the package (need to implement requirement 4 still) I haven't yet wrapped it up for the general public, however it will probably pop up on my Github in the near future is available from Github and possibly in the MODX Extras Repository in the near future.

It's insanely easy to use (simply call the [[!makeDonate]] snippet in your template or content and, if you configured your PayPal credentials, you're done) and I think will be an extra value to those people and institutions that rely on donations and need a real easy solution for both visitors and developer.

Let me know in the comments if you have a project coming up this could be useful for. Perhaps you can also come up with a better name for the package while you're at it? :)

We're closing up 2011, of course cramming all the leftover work into one or two weeks, and with that I wish you Merry Christmas and a Happy HandyMan! Yes, you read that right and I (think) I spelled that right. Today - Christmas 2011, December 25th, 2011 - sees the release of HandyMan, the Mobile Manager for MODX all of you have been waiting for.

(At least - if I can drag myself away from all the Christmas celebrations for just a few minutes to upload the package to the Repository. This post was written a few days ago and I just told it to publish itself on December 25th cause, well, MODX can.)

Merry Christmas & Happy Holidays

Let's get this out of the way. 2011 was a great year for me personally, in which I dropped out of school and landed into this MODX world full of fascinating development projects, and the prospect of doing something I actually seem to like for a living! With over 25 clients in the first year of business I don't think I did too bad either!

I hope your year has been equally exciting, and that there's many interesting things on the shelve, waiting to be dusted off and executed. In memory of the one and only Steve Jobs, I hope we can make 2012 the best year yet

Merry Christmas & Happy Holidays!

Back to.. HandyMan!

Right - HandyMan. That rock-solid jQuery Mobile foundation, with some MODX love sprinkled on top. Or based on the time it took to get this ready for a public release - nearly nine months - a helluva lot MODX! HandyMan allows you to manage your MODX content using virtually any mobile device, including tablets, using a stripped down, mobile optimized UI.

For those who are unfamiliar with it, and don't understand what I'm so excited about - you should check out the following Promo video made by Jared Loman:

That probably told you very little new information.. but c'mon - it had to make you grin right? It's Christmas! :D If you really want more in depth information of what HandyMan is, head over to this eight minute screencast, also by the one and only Jared Loman

But hey.. why not just download the package, and get it up on your own site to start managing your content from a mobile device?

More information on HandyMan can be found on its dedicated site: MODX Mobile.

 

Somewhere in the Spring or Summer of this year I decided I wanted a new website. The old one, while functional, didn't quite speak to me anymore and the blog was simply tucked away too far to ever become a prominent part of the site.

A few different mockups followed, and eventually I found some people (Romain Tripault and YJ Tso most notably) willing to help me out with the whole process of getting a new proper design and get something launched. Now, December 2011, it's finally there.

What I wanted

  • Responsive website - Mobile is the future and I don't want to scare my visitors away by providing a bad user experience on other devices.
  • Automatically displaying related articles. Coincidentally I had a custom development client who wanted the same, which resulted in getRelated which is now powering the "related" widgets on the site.
  • Clean design. Fast, accessible. Syntax Highlighting to make code readable.
  • Much more focus on MODX related articles on the blog. Regularly posting fresh and interesting MODX content with visitor interactions through comments (perhaps a guest post someday?) will really thrive this site forward into the "MODX Vibe". (Read my take on the all new Articles plugin)
  • Better representation of the work I do and did for prior clients.
  • A demo site for some of the addons I developed.

Well, you're looking at the result!

I'll be finishing up the migration of the site over the next few days, including the comments that were left there on migrated posts and adjusting links to my site where-ever I can. Oh, and you may want to watch this space on December 25th 2011... to stay updated you could use my MODX 2.2 Dashboard Widget! :)

This website (and domain in general) will start housing many different sections in the next coming months, and the blog is only going to grow and grow - so come back some time! ;)

What do you think of the new design and in general - this website? Any requests on articles? Feel free to leave a comment (here, or on any article of course!) or to get in touch.

VersionX 1.0 was first developed in December 2010 - it was one of the first open source project I started actually. It also was the first tim that I actively developed a custom manager page, and, well, the code is terrible.

Luckily VersionX 2.0 is coming to town!

VersionX 2.0 is a complete rewrite - all that is reused is the name and the initial thoughts behind the plugin: providing a simple versioning component that allows viewing, comparing and restoring of past versions.

The rewrite is in progress, and as with any open source project - not quite as fast as I had wanted - but it's starting to get shape. Here's a quick list of what is currently in place:

  • Saving a resource causes VersionX 2 to check if any changes were made, and if so it will save a new copy to the database. If on MODX 2.1 or higher this includes Template Variable values.
  • Saving any element (templates, template variables, snippets, chunks or plugins) creates a new copy in the database.
  • Resource Versions can be seen and compared to any other version of the same resource through the VersionX Component.

Yes - it versions Elements and Resource TV values - that's new to VersionX! However, having built the versioning functionality for elements, there's not yet a grid to interact with it. The element data will be in the database if you need it, but there's no way to view or compare it from the manager.

As of writing, VersionX 2.0 is at release dev7 and I am expecting to be able of releasing it publicly at around dev15 or so. Here's the things I'm looking to implement by then:

  • Proper upgrade from VersionX 1.0. The database is set up way differently (to allow a more scalable and future-proof strategy), and there's not yet a simple upgrade procedure to re-use the data already stored. This needs to be different before a first public release.
  • Restoration of Resource versions - after all, that's what this whole thing is about.

When those two have been finished I will be releasing VersionX 2.0 as a free package available from the MODX Repository.

After that, hopefully some donations will pop up and I will be able to develop VersionX further. Adding the interface for elements, bringing new tabs to resource update screens to view the versions without leaving that page and more.. all of that and much more is on the roadmap for VersionX 2.0.

I'll admit: deep down inside I'm hurt. I've spent hours and hours trying to get this blog just right with all the right features. You may have noticed that I set up some automated archiving, tags use friendly URLS and you can even leave comments (with notifications). And guess what? You can have all that and more in literally five minutes with the all new "Articles" component for MODX 2.2. Thanks Shaun!

No - but in all seriousness, the release of this all new "Articles" plugin (formerly called "modBlog") is great news. The timing could have been better (like, not right after I deemed the blog section of my new site completed), but this is a great step leap forward for MODX, and I would really say it welcomes MODX 2.2 to the stage with a bang. 

Now, for those that have been hiding under some rocks lately - Articles is a Custom Resource Type developed by Shaun "splittingred" McCormick, MODX Senior Developer. "Custom Resource Type" is real nerdy talk for saying it's something that shows up in the side hierarchical resource tree, but doesn't neccesarily act similar to your regular Documents. If you want the nerdy description - it means you can extend the modResource class, and change its behavior (methods), customizing the user experience (controllers) and more. 

So what does it do?

Well, here's a list of some of its features:

  • Provide an overview UI when clicking the Articles resource in the resource tree, where a grid of posts are shown, as well as a huge amount of settings to configure its behavior.
  • Lists the individual articles on the front-end (powered by getPage and getResourcesTag, meaning you got it paginated and filterable on tags)
  • Creates automated archives (using friendly URLs). 
  • Generates RSS feeds.
  • Allows imports from Wordpress and resources. 
  • Has built in commenting (configurable through the Settings tab) powered by Quip. Real nifty thing here is that the Quip comments view in the manager is integrated with the individual article update screens.

Well, that pretty much sums up blogging right? I probably forgot a thing or two there, and luckily there's still some things planned for future releases for the total feature-nuts out there. 

All in all Articles really is a game changer, and the fact that it is for MODX 2.2 and up (I really should write a blog post on that, too!), I have the feeling we're about to see a big spike (a new download record, perhaps?) when 2.2-pl hits the shelves.

(And yes - this blog is still powered by my own craftmansship and hours of hard labor. And 2.1 for that matter. I'll upgrade it all someday - let's launch this baby first!)

Update 29/4: Thank you Bert Oost of OostDesign for the tip on supporting different getPage configurations!

If you've ever created custom components, chances are that you have had to create accompanying snippets to actually show the data on the front-end. That can be a lot of work, and once data starts piling up you may want to add some pagination to it. This brief article will explain the requirements that getPage puts on your coding to properly paginate custom objects.

Getting the number of Results

First of all, we will need to tell getPage what the total number of results matching any filters set in place by our snippet is. In our snippet, we can easily set up the xPDOQuery object the way we normally would and take that object to get the total amount of results. No - we don't use getCollection and count() the array - that would be an insane waste of processing time. Instead we use the little jewel called modX::getCount, which is actually extended from xPDO::getCount. This will, without retrieving all the data from the database, get the total number of results for your query. Let's show an example of how we could use this - in this example we look up the amount of resources that have a class of modWeblink or modSymLink and are published:

So that will give us a number in the $total var - but that doesn't tell getPage anything - yet! Having looked at the getPage documentation trying to figure out this part, I've overlooked the answer many times and it is surprisingly simple. The documentation tells us there's a totalVar property:

And that's our answer. We need to set a placeholder, of which the key matches the value of the totalVar property: by default that's "total", though users have the ability to change this in their getPage call, so we'll need to get the totalVar property and set a placeholder with that name. Let's update our example accordingly to set the placeholder and that's all there is to it.

Starting at the right offset

Secondly we will need to make sure our snippet understand which results to display - and that it passes this on to our xPDOQuery object. In this case all we need to do is lookout for two properties: limit and offset. Limit will be set by getPage to the &limit property, which indicates how many items to show at once. The offset will be calculated based on the "page" request and the limit per page.

If we would update our example, we could end up having this - which works perfect with getPage for pagination.

You may notice a few important things:

  • We get the total amount of results, and set the total placeholder *before* we limit the query. While the docs say it may ignore the limit property, I like to be sure.
  • We use modX::getOption() (extended from xPDO::getOption) to get the "limit" and "offset" properties from our scriptProperties array available in snippets. If it does not exist we assign default values of 10 and 0 respectively.
  • We use xPDOQuery::limit() to set the limit and offset to the query. We then pass that on to our getCollection call and be on our way to process it further and give the site visitor what they want.

Hopefully this brief article will help more developers making their snippets getPage-proof, which will make it easier for front-end developers to use one tool (getPage) for all their pagination needs. Please feel free to share your thoughts and suggestions below!