If you live in Europe, you have probably heard about the crazy EU directive that is forcing EU Countries to adapt and enforce new laws which ban the use of cookies, unless you kindly ask for permission.

My opinion is that politicians shouldn't mess with things they don't know anything about, like this internet thing.

You see, the intent is right (protecting the end user from privacy issues relating to third party cookies and beacons tracking their every online move), but right now they are only making our job harder for zero gain to the people supposed to benefit. Actually, we're now starting to throw popups, scary tech lingo and (commonly) ugly banners at users. How does that help anyone? 

Anyway. This site uses one cookie to help the server know who you are to prevent authorizations and personal data from getting mixed up between users. I also track your every move on my website using Google Analytics and Gauges, which each set a few cookies of their own to see if you are new or have been here before. The collected data is aggregated before made visible on the respective sites: I cannot see what pages you specifically looked at, just what pages are being looked at and (again: aggregated) entrance/exit paths within the site. This data helps me figure out what people want to read and over time will increase your experience on my site. 

If you do not approve of these cookies, please use your browser to disable cookies all together or browse in private mode. Or don't visit again, though I would hate to see you leave.

Still here? Awesome! Now I can tell you a bit about Cookies in MODX.

Cookies in MODX Revolution

Out of the box, MODX sets one (1) cookie, by default called "PHPSESSID", which, as the name might indicate, has to do with sessions. Specifically, it sets a session ID/hash which relates to a row in the sessions table. By doing this, the system knows in a simple way who you are, allowing you to stay logged in among other things. 

In other words, it's an essential cookie that the infrastructure depends on. To my knowledge, that is a cookie which is allowed without asking for consent, at least in the Netherlands and the UK! If you absolutely don't want this cookie, you can change the MODX Session Handler to use the server default. In that case it could be the server that sets a session cookie, though. 

If you want to follow this crazy law anyway, I would advise using Silktide's Cookie Consent plugin. It's free, looks good and they offer a sweet wizard to get the code set up.

Disclaimer: I am not a lawyer and while I hope this page is helpful to you, consult your favorite lawyers office if you want to comply to the law. I'm not responsible for your (lack of) action(s) following this post. 

What's your favorite cookie flavor? Share it with the world in the comments section below.

As promised in a recent announcement, I was going to provide some tips on serving MODX sites over SSL based on my move to a complete SSL-based website. Here they are!

SSL Tip 1: Using protocol insensitive URLs for assets from the get go

You can apply this tip, even if you are not going to be serving anything over SSL soon! If you, like me, point to assets complete with the domain, you will risk serving non-secure content when making the switch. This is easy to prevent by not specifying the protocol, which is the "http" or "https" part.

An example before:

and after:

So basically you take a full URL, and instead of specifying "http://" or "https://", you simply specify "//" which will make it relative to the protocol in use.

SSL Tip 2: Generating HTTPS urls with MODX by default

When using the url syntax (like [[~1]]), this is usually relative to the site_url, the default. However it's easy to change this to use any other scheme both on a per case basis, and across the entire site through a system setting.

To change one link, pass &scheme=`https` to the link tag. Wait, you can add properties to link tags too? Yeah! For example, this is completely valid: [[~1? &scheme=`full`]].

To change all links to use https, find the link_tag_scheme system setting and change its value to "https". When not using https, I like to change this setting to "http" so all urls are absolute. All possible values for the &scheme property or link_tag_scheme setting can be found in the makeUrl documentation

Now, there are some Extras that don't neccessarily follow suit here and use their own defaults. Wayfinder, for example, has its own &scheme property you will want to change. And when Wayfinder points to the homepage of a context, it points directly to the contexts' site_url, so make sure that has https as well.

SSL Tip 3: Telling Quip to use secure Gravatar URLs

If you're using Quip for comments (like me!), you will usually use Gravatar for comments which usually serves over http. Luckily, Gravatar does offer a secure link to avatar images but Quip isn't aware of that by default. But it does give you the opportunity to change the link to the gravatar images. This allows you to use a proxy on your own server, or to point to the secure Gravatar url instead! :) This is the &gravatarUrl property. As the secure url for Gravatar is https://secure.gravatar.com/avatar/_MD5_of_email_h..., that's what we set the property to.

Before

After

That concludes this list for now. Do you have any good other ideas? Let me and other readers know in the comments below.

I've been really busy at my new job in between moving, throwing anniversary parties for the folks and trying to manage a couple of projects I'm still involved in personally. I've got some article ideas (and drafts) nearing a publish-ready state, but it really has been too quiet. In this post I want to provide you with a few quick updates with a promise for more quality posts "coming soon"!

Slight updates to my Design

You may have noticed while browsing the MODX Blog, Category or Archive pages, but I have been spicing things up a tiny bit! Blog items now show up with images in the listings, and the homepage has been updated to funnel people to the blog more easily as well. I am also using more images in article contents where applicable using my MIGX Gallery set-up and I have subtly improved the way my sidebar widgets appear on tablets. If anything my site is a constant work in progress and I hope you can appreciate these updates. If you have any feedback be sure to get in touch, or to leave a comment!

Doing my bit to make the web more Secure

Obviously by simply using MODX I'm doing my bit to make the web a more secure place to hang out at, but over the past week or so I've been working with my awesome hoster on serving my site over SSL.

Why?

Well, why not?

I'm already paying for a VPS (I need the processing power and storage for one of my personal projects) and as SSL certificates start at like €15 a year, I couldn't come up with a good reason not to. My visitors will be able of browsing my site securely (even if there's no log-in or personal data going 'round) and it's a nice experiment in general. 

There were a few challenges to getting to this point, but all in all it went mostly smoothly.

  1. The site needed to move to its own dedicated IP. Normally this is quite smooth, but it resulted in a few hours of down time due to the odd way I originally set up this site, which meant that for this to work smoothly, the site needed to be migrated to a new user on the server manually (which is harder than it may sound with all the loosely connected legacy cruft this site has already built up!). 
  2. As I've been using an assets sub-domain (among others) to split requests and speed up site loading, the sub-domain also needed to be served over SSL. Patrick did a great job helping to get that up and running. 
  3. This is probably the most annoying challenge, which is making sure you do not point to any non-ssl scripts or images - anywhere. There's stylesheets in the header, scripts in the footer, and most importantly: images in the content. There is also comments which uses Gravatar over non-SSL by default.

I will be publishing a new article probably next week with some specific and easy to action tips on preparing your MODX site for running over SSL.. stay tuned for that! Over the next few days I will start enforcing HTTPS as well (you can still visit over HTTP for now by changing the url), so if you do spot any issues - be sure to let me know!

VersionX 2.0.0-rc2 and 2.0.0-rc3!

I have to admit: VersionX is my favorite Extra right now. It sits in the background doing its thing, and when you screw something up you can go back and restore an older version. RC2, released on May 28th and RC3 released on July 8th, both fix a number of bugs that people have reported on the Github page, and it now has an interface for all data it collects! The next version will likely get rid of the "release candidate" moniker and introduce some more restore options that are not yet available. 

Read more about VersionX, just download the package, or make a donation

getRelated 1.2.0

If you don't know what this is, getRelated can be used to automatically show related items on a Resource. It's used in this site and I have seen many examples of it in use all over the place. By taking a getResources-like approach and offering easy ways to customize the sorta complex algorithm it uses, the result can be fine tuned to the bone and templated all the way you want it. 

In the June 7th release of getRelated 1.2.0 this is even further improved, as it now features a &stopwords property to assign a custom comma separated list of words to ignore for that instance, it properly supports multiple (different) snippet calls per page now, adds Russian support and the default output is now a bit more sensible too.

Read more about getRelateddownload the package or read the documentation.

ContextRouter

While released in March already, I never really publicized it much, but with the MODX Cloud Beta rolling out (which was the inspiration for writing it!) I'm plugging it here. ContextRouter is a plugin that eases setting up different (sub)domain contexts by taking your http_host context settings into a custom cache file, and routing requests to the proper context based on that. It's available via the package manager as well. 

You probably noticed MODX was represented at the CMS Expo in Chicago, already a week and a half ago. I was there too! For me personally, this was a week of "firsts". First time on an 8hr flight, first time outside Europe and in the United States, first time visiting Chicago and first time meeting my employers (fun story).

The week was awesome.

Arriving on Saturday at 2pm (after leaving Amsterdam at 2.40pm, aint that amazing?), I was completely broken and barely managed to stay awake until 9pm which is when I hit the very comfy king-size bed at Hotel Orrington. Sunday morning I bought myself a week-pass for the public transit to head downtown... Holy cow, 45 minutes per train to get into downtown Chicago?! This city is huge! After strolling around a bit and heading for Millennium Park, it started to rain and I found my way to Panama Bread for some lunch. Back to the hotel in Evanston to check in on the folks at home, email and the social networks. By the time all that was done I headed to Austin Tacos... Let's just say America has funny tacos. :P

    no stuff

The next day, which was Monday, was when the rest of the MODX team was going to arrive as well as the first attendees of the conference. After grabbing a cup of coffee to-go and intending to wait for them to arrive in the lobby, the door was opened and some faces that I just knew from avatars on Skype and Twitter walked in.

How do you greet people you have never met in person before, but have been in touch with for ages and now work with every day? I think I got as far as "you guys have to be from MODX!", or something silly along those lines. Kinda weird moment, but definitely one of the highlights of the week. The day went on with a mix of hanging out, building a booth, meeting more people formerly known as twitter or skype nicknames and getting to see some American excess first-hand at a local pizza place. I also had the pleasure of meeting Aaron Ladage (/la-dag-gie/, not /la-daaj/ as I imagined) and JP De Vries as well as others  - familiar names, but new faces.

Tuesday, Wednesday and Thursday were conference days which meant lots of talking, talking and spying on..er..getting inspired by the work of other platforms represented there. I personally got to see some Wondercode (odd business model, but a real WYSIWYG editor) and MuraCMS (awesome import/export functionality and some other interesting features) flyovers as well as the majority of the keynotes in the ballroom on content management strategy and history (instead of just the tools which highlighted the rest of the conference).

There was also plenty of MODX, of course. From the showcase session to the impromptu code share meeting in a room we sort of claimed, and the MODX (and friends) meetup at a local restaurant on Wednesday where everyone was too busy chatting and drinking "Revolution" beer (I kid you not!), to think about silly stuff like food. The team also brought along "the helmet", and many attendees were spotted wearing it (on picture, too).

    no stuff

After more talking, demo-ing and having a great time at the expo, the Thursday ended with an open showcase where site builders could show off their sites (MODX heavily represented with some truly stunning sites), and finally the famous "gotta have it gadget giveaway". I won a laptop cooler (one of those things you put on your lap that cools your laptop and prevents burning your delicate parts at the same time), but if he had not had an early flight back north our one and only Jay Gilmore would have won an iPad3 ...!! I hope that is a lesson for one and all to not leave before the final session..you never know what happens! ;)

After all that and saying our "see you later"-s to the people rushing back home I finally got to try the legendary pizza place in Evanston with JP De Vries and Jason Sonderman, also a MODXer from Kansas, things finally slowed down.

Friday I went downtown Chicago again, this time to visit Intelligentsia Coffee for coffee geek brother Kevin, the Chicago Cultural Center for the obligatory cultural sniffing and the Sears/Willis tower - 103 floors up in the tallest building of North America.

    no stuff

Saturday I had to get to the airport for my 4pm-7am (local) flight back home, after which I went back to bed and woke up just on time for dinner.... The joys of a jetlag. I did manage to get some nice shots on the flight home.

    no stuff

Now, all this was two weeks ago. Last week I also (finally) moved, and I now have my own place (with plenty of room for receiving people) in Leeuwarden, the Netherlands. I also released VersionX 2.0.0-rc2 last night.

In December 2010 I started developing VersionX 1.0 as a pet project. Now, 16 months later, I'm very glad to announce the immediate release of VersionX 2.0 - more stable, powerful, better organised, and available for MODX 2.0-2.2. 

While you can view the entire 2.0 changelog on Github, here's the gist of what you really want to know right now:

  1. Keeps track of changes to Resources (including TV values), Templates, Template Variables, Chunks, Snippets and Plugins. If you don't want to version a specific type of element, you can also disable that per element type.
  2. Offers a central component to view the details of versions and compare them for Resources, Templates and Template Variables.
  3. Offers the ability to revert Resources to a prior state.
  4. Has the (optional) ability to display tabs with a versions grid on Resource and Template update forms. 
  5. It's free (though donations are appreciated)

VersionX is now available as a release candidate from the MODX Extras Repository, and the source as well as issues list is available on Github

    no stuff

You can help!

We're currently in a release candidate phase. That means I have been using it for months on my own and client sites, but that it could probably do with more real world testing and people breaking it in ways I wouldn't have been able of thinking off.

Here's some ways to help shape up VersionX:

  • First of all: install it, use it, think of ways to make it better and post it on Github.
  • Developers: find bugs or requested features, and use Github to send over a pull request with your addition.
  • International folks: translate the lexicon file (just one for now) to your native tongue for inclusion in the next version.
  • Make a donation.
  • Spread the word! Blog about it, point people to the package when they need Versioning, share it on facebook or tweet it out!

Some time ago @tlyczko suggested I write a how-to on using MIGX with image Galleries or Sliders. As I'm using MIGX all over the place, I guess it can't hurt to spread the love with this How-To! We'll go over the basics of MIGX and work towards the new slider I recently set up for use in my blog.

Try MoreGallery!

While you can still use MIGX for image galleries, I have recently released MoreGallery, a custom Gallery resource for MODX, as part of my new business modmore. The user experience is significantly better compared to using MIGX, so check it out.

The end-result of what we're doing will be the following slider which you may have seen in my MODX Meetup post recently:

    no stuff

Requirements

  1. A MODX Revolution site. This one is on 2.1.5, but MODX Revolution 2.2 will work fine..
  2. The MIGX custom TV input type installed (available via package management or from here).
  3. A slider or gallery script we'll want to integrate. I went for FlexSlider by WooThemes as it adjusts itself to its containers' width (which is quite important with a responsive design!). It's also quite configurable, supports swiping on smart phones and it looks pretty good out of the box.
  4. The phpthumbof snippet installed via the Package Manager for autocropping images.
  5. Some images!

Getting Started

There's a few parts involved. There's the back-end MIGX TV we'll need to set up, and we need to take that data to our front-end to put our slider to work. As this tutorial assumes WooThemes' FlexSlider, we will make sure the markup is exactly what that needs - but it should be easy enough to adapt for other sliders as well.

Step 1: Setting up the MIGX TV to manage Images

Let's start with setting up the TV. The beauty of MIGX is that you can define the fields you want. You should basically see it as a table, and you get to define the headers. In this case, I will want three different fields:

  1. An image input field to select an image from the file system (or in 2.2, from your media source).
  2. A simple text input to give a caption / tag-line / description. FlexSlider handles captions quite nicely, so we'll be using that.
  3. I'm also adding a text input for "Set". As we'll see later, I'm using this to manage an infinite amount of individual sliders which could be added at any point in the resource.
You can use different fields if you want, though the rest of the tutorial will assume the fields above.

Now let's start creating the TV. Here's a quick slider with an overview of the things you should be seeing (in 2.1-UI style), in case the blurb of text catches you off-guard.

    no stuff

Create a new Template Variable via the left-hand Elements tab, and give it a proper name. I called it mh.images, so if you gave it a different name make sure to replace [[*mh.images]] with the right one further on in the tutorial. On the Input Options tab, choose the "migx" input type drop down. If you're not seeing it there, make sure you have installed the MIGX Package through Package Manager. You will notice that a couple of options have been added to the bottom of the screen, including Form Tabs and Grid Columns. If you're not seeing this and running MODX 2.0, sorry - it's slightly different there and you really should consider updating soon.

Note: Both the Form Tabs and Grid Columns field expect to be fed a valid JSON string. JSON is basically a way of showing objects, arrays or just key -> value combinations in a way that is supported in pretty much any programming language available. There's a technical specification and some examples available on the official JSON website.

Setting the Form Tabs

As the name implies, the form allows different tabs to be used. Every tab has a caption and a number of fields. There are some advanced things you can do with this, though most usages will only use a single tab so we'll keep it at that for now. Here's the Form Tabs JSON I am using:

Let's just briefly go through that per line:

  1. Line one shows us opening the array of tabs with a square bracket ( [ ), and opening the tab object with the curly bracket ( { ). After that we define our caption option with a value of Image. Note that it is important to use double quotes ( " " ) for both the properties and its values, as single quotes are not according to the spec and can have unexpected results. If you have any double quotes inside any properties or values, escape it with a slash ( \ ). After we defined our caption, we go ahead and start defining the "fields" array by opening it with the square bracket ( [ ).
  2. We define our first field, the set in this case. The "field" property defines we want to be able of accessing it in the code as "set" - this would be the name part of a regular text input as well. Next we give it a caption of "Set", which will be shown in the form as field label.
  3. Next we define the description field in the same way.
  4. Line 4 defines the image. What's special here is that it uses another TV (with the name "image") as input type. This is a very powerful feature of MIGX that allows you to use other TVs to build up your form. In this case, the "image" template variable is really simple. Input type is an image, and in 2.2 you would assign it to the right media source as well. You don't need to link it to a template to make this work. Another way you could use this (which I use in another MIGX powered TV) is to build radio boxes or select boxes.
  5. Line five closes the fields array. Also note that the last field definition line (image) does not end with a comma - this is important! If you leave a trailing comma in an array it will not be able to process your JSON, and your form would not work.
  6. Line six closes the tab object as well as the tabs array.
Having put that in place (and having created the "image" TV!) you should have a working form, though there's no grid to show its values yet..

Setting the Grid Columns

The Grid Columns are what builds up the actual table (grid) in the resource's TV panel. You get to define the headers for that grid with the Grid Columns input option.

Here's the (again, JSON) definition I'm use:

Per line:

  1. Open the array of headers with the square bracket ( [ ), and the first column header object with the curly bracket ( { ).
  2. We give the header a title of "Set", say it can be sorted (optional), and tell it the dataIndex is "set", which corresponds with the Set Form Tabs definition which had "field":"set".
  3. End Set / start Description
  4. Give the header a title of "Description", sortable, and match it with the Descriptions' field with dataIndex.
  5. End Description / start Image
  6. Give the header a title of "Image", not sortable, and match it with the Images' field with dataIndex. We also define a renderer which is an ExtJS thing that allows you to change how the value is displayed. In this case, the "this.renderImage" renderer will automatically take the selected image URL, and show a thumbnail for it instead of the url itself.
  7. End Image object, end headers array.
Now that's done, you can assign it to your template and check out the result. No grid or form showing up? Go back to your tab fields and make sure you have all properties and their values enclosed in double quotes, not single ones, and if there are any trailing or missing commas. Can't find anything wrong? It's probably something easy to miss. Use JSONLint to validate the JSON.

Step 1a: Fill in some data!

Find some kitty or dog pictures and put them in through the new magical MIGX TV.

Step 2: Take the data to the Front End

Now you could do something funny to your visitors, and just throw your [[*mh.images]] TV somewhere in the template and telling them to imagine it's all images.If I would have done that to you, the example slider would have looked something like this (without the nice indentation I threw in for readability) instead:

Correct, that's a JSON array with our fields and values!

Now, luckily, MIGX comes with a snippet called getImageList which can help you make sense of that JSON. As I'm a developer and it's easier for me to write an 8 line piece of PHP to parse it, I tend to write that 8 line php myself and not use getImageList at all. If you do want to use getImageList, you can find the documation for it here.

Here's the snippet (which I called mh.parseMIGXToGallery) I'm using to generate the markup (from a &tpl chunk) based on the TV data:

That looks easy enough don't you think? Let's just go through it line by line again.

  1. We take the $input variable (which is populated by the data passed in by &input on the snippet call, more on that later), and parse the JSON into a php array.
  2. We set up an empty array to hold our output.
  3. We make sure the $input variable isn't NULL or false, which would mean there was either no JSON passed or it was not valid, as well as we check the $tpl variable (passed from &tpl in the snippet call) isn't empty. If either condition is true we'll return an error "no stuff' which is a hint for you, as content manager, that something's not set up right.
  4. Next we loop over each item in the $input array as $row.
  5. We check if the $set variable (which is set by calling &set on the snippet) is set, and if it's not empty we match it against what the value of "set" in the current row is. If it's not the same as what we want, we continue to the next item in the array.
  6. We get the chunk by the name of $tpl, and inject the values of the current row into it as placeholders.
  7. We close the foreach loop.
  8. Finally we glue together the $output array, separating every entry with a simple line break, and return it to the page.
So to sum that up, we take our input, loop over the individual rows and if they belong to the set we defined it gets the chunk we defined and adds that to the output.

Putting the Snippet to work

Now all we need is a snippet call where we want our images to appear and a chunk that matches the markup required for FlexSlider. Here's how we'd call the snippet:

and the mh.images.gallery.tpl chunk to match what FlexSlider is looking for is as follows:

and we will also need to wrap the entire snippet output in a div with an unordered list, according to the FlexSlider documentation. To make that easier (and a helluva lot more client friendly), is to put all that in a chunk. My chunk is called mh.slider and has the following contents:

With this chunk in place, I can simply reference the following in the content which is much easier to remember or to put on a cheat sheet.

We could also use a TV to have it type in the name of the set (gallery or collection) in a TV which, when filled in, puts that chunk in a predefined place in the template.

Now we've got our raw markup as FlexSlider wants.. but it's not doing much yet. Off to hook up FlexSlider!

Step 3: Hooking up FlexSlider

FlexSlider is relatively easy to use (download its files here), and there's a number of examples on its site to look at if you need help. You will need to include jQuery on the page, as well as its CSS file (found in the zip) and the FlexSlider plugin (also found in the zip). After having done that you will need to initiate it on the right element, using a code like the following:

The website advises to put all of it in the head of the file, though I personally put it in the bottom. If your slider will appear near the top of the page (above the fold), it can be better to put it in the <head> so it loads before the page shows, though that's just a preference.

And that sums it up for this very long article! I hope this how-to can help people getting started with MIGX and galleries like FlexSlider!