Howdy! Welcome to my humble web presence. I'm Mark Hamstra, the CEA at my latest venture modmore, where I spend most of my time developing and providing support for awesome tools and extras for MODX Revolution.

This website is where I share my thoughts, cool projects and other oddities related to MODX, xPDO and ExtJS. Sometimes I post three blogs in a day, sometimes there's no update in a year. Read a random article.

MODXpo 2013 Live: Continuous Integration & Deployment

16:47 And we're done. Time for a 15 minute break. After the break, we'll be back for a live blog from Steve King's presentation about Distributions. Find the live blog for that talk here.

16:47 Another tool; Deploy HQ that could deal with the whole deployment process (git pull etc). It can be used to automatically upload all changes to git directly to the server, or you need to hit a big Deploy Now button to deploy manually.

16:45 Version control is mandatory when working in a team.

16:45 [Q] Is there a video somewhere to explain the process? [A] Great idea. Chris will talk to other people at the office (I'm guessing Mark Willis) to see if it's possible to get a screencast for the process.

16:42 Before committing, someone uses PHP codesniffer to check docblocks and other code. It even checks if there is an actual ticket for the commit, which is assigned to you, before it lets you commit.

16:41 Oops. Passwords are the same for environments. That's something that could use some work..

16:41 The automatic project set up uses a zip file of an earlier install MODX site.

16:39 For an iPhone application a community member (Ramon Getman) set up Jenkins to check out from repository, run some commands, create a build using Xcode on Mac, upload it back to Jenkins and then to an app testing service. The key point is that it saves you a lot of time. There is time needed up front, but the time is saved down the line.

16:38 [Q] Have you solved the problem of chunks etc? [A] Yes, Static Elements. [Q] Any impact on performance? [A] Not if the media source is set to none (from the community).

16:36 And that's a wrap, time for questions now.

16:35 Another great tool, Toolbelt, is used to set up projects. Enter the domain, it clones the MODX repo to the local machine, the repository is set up, the origin remote (in git) is updated, the hook (connector we talked about before) is added to bitbucked and stuff gets pushed to git.

16:34 When everything is successful to that point, the site is deployed with RunDeck. Jenkins could be used, but by abstracting the deploy to RunDeck, it offers you the features of that. RunDeck just uses git pull.

16:33 BitBucket is used to create pull requests. Each feature is reviewed, and the branch is merged with master and then closed. That merger will automatically trigger Jenkins which runs all the tests.

16:31 Database differences (in both schema and data) are not automated, as it's very subjective and needs the developer to decide what needs to be merged and how. MySQL workbench is used (among others). This is done on a case-by-case basis.

16:29 Databases are still an unsolved problem. One thing is that there are no hardcoded IPs; instead the database server is configured (and committed to the source) as db.server, and the DNS on each of the servers (local, jenkins and live on rackspace) resolves that to the right IP/domain. Clever!

16:28 Seeing the Jenkins jobs for specific projects now. Jenkins is not just for testing. Previously they would use rsync to publish demo sites for clients. They wanted multiple demo sites, and they use Jenkins to do so through wildcards. Every branch for every project is available via

16:25 Here's how changing the context would be implemented. More blog posts or information will be published about this later.

16:23 For testing, phplint, phpunit and behat was used. Behat is really cool, and this an example (of an odd test, apparently). The cool thing is you can define your own scripts (in this example below) to change to a certain context.

16:21 A bitbucket connector is used to tell Jenkins about when something new was pushed to bitbucket. This is the connector they use, that each project is pointed to: link

16:19 So this is the final process, that doesn't let people skip any steps:

16:18 Every feature is branched, tests will be written for each feature, that is then committed and pushed and then Jenkins is used as CI Server.

16:17 The CI Server handles the testing. It's run every time code is pushed, or periodically. It's possible to deploying automatically, but the adido team doesn't use that. Results of the tests are reported via email and hipchat.

16:15 Now we're starting to talk about continuous integration. The goal is to prevent integration problems (merging is scary) and to have automatic testing.

16:14 Apparently bitbucket might be more reliable than Github because Github went down a few days ago. Bitbucket also gives free private repositories, which is a big pro. I'm still a Github user. :D

16:13 Using Git (bitbucket) for deployments, it's possible to force people through certain processes for deployments. There are no more wild west coding opportunities any more.

16:12 We're now looking at another diagram that shows a way of using nginx configurations with wildcards, which lets developers look at projects on other developers' computers.

16:10 Great diagram that shows where the developer is (inside the green circle) and how that works together with the rest.

16:08 We're now looking at a Vagrantfile (see photo below). There's some information taken out if (RSA keys etc), but this shows how it's configured.

16:06 To get the virtual machine, simply type vagrant up in the command line to get everything set up according to the specification (which uses Puppet one way or another that I didn't quite understand, sorry).

16:05 Vagrant keeps files synced between the host and guest operating system. In the finder/explorer it will look like all files are on your system, but Vagrant makes sure the virtual machine has access to the exact same files.

16:03 With vagrant you configure a process that sets up a preconfigured operating system. Everyone uses the exact same environment. It's a wrapper around VirtualBox to set up virtual machines.

16:02 Vagrant: "create and configure lightweight, reproducible and portable development environments".

16:01 Big shoutout to Mark Willis for introducing the Adido team to MODX.

16:00 Working with these processes would mean everyone needed to know all about these small problems.

15:59 Chris describes Remote Desktop as the "devil on your shoulder" where developers could log in to the server and fix problems in place... which would get overwritten next time a rsync deploy would be ran. Lot of small problems can pile up over time.

15:57 To figure out who didn't commit their code, sync logs could be checked to see who introduced uncommitted code.

15:55 .bat files were used for the rssync deploy, merges etc. For this process it wasn't necessary to commit to SVN before deploying with this process, so it was possible to deploy things not yet in the source, which could get overwritten by someone else.

15:53 After checking out the source, it was ran on a Visual Studio Server or local IIS. They don't work exactly the same, which makes collaborating more difficult. Also used was rsync, which according to the audience is awesome! It was used as alternative for FTP to deploy to live or demo sites.

15:52 In the .NET days, SVN was used for version control (hosted internally).

15:51 Changing CMSs gave Adido a chance to review things. How to build and how to deploy websites. Especially important when you're collaborating with other people.

15:49 When looking for a CMS, there were a couple of priorities for evaluating a CMS. There needed to be a good community they could participate in. It needs to be customisable so they can easily adjust to clients changing their mind. The third is that it needed to be easier for clients. Apparently orange and blue is bad... WHAT?! Luckily, they did end up going with MODX because it was easy to use for clients.

15:46 A community like the MODX one is a lot better at managing a CMS product than an in-house team.

15:46 The Adido team used to be a .NET agency, with their own CMS. It's called dub3, and was built in-house and has been their primary platform for about 10 years. Over 300 websites built with it!

15:45 Adido doesn't do any work at all, they just play video games.

15:44 Chris explains why quick and easy access is important for the developers working at Adido (a 30 man show).

15:41 Chris Cherrett from Adido will talk about Continuous Integration and Deployment, starting right now. Chris is not a sysadmin, but a developer building and breaking features :)

Read 0 comments and share your own thoughts!

MODXpo 2013 Live: Extending modUser

14:50 And we're done. I'm up now, so can't continue blogging :) Leave a comment if you want to see more like this.

14:50 Susan Ottwell highlighting how awesome Revolution is because it lets you override basically anything, without meddling what's already there.

14:48 Breaking: Bert doesn't like MIGXdb.

14:48 Google is useful.

14:47 Most of the examples can be found in the Extending modUser document in the RTFM.

14:46 Why choose MODX? Interesting question at a MODXpo... ;)

14:46 Changing the table later is possible with modManager using addField/alterField methods. You don't lose data when the model changes but you do need to update the table.

14:44 Great question from Susan; why not extend modUserProfile? Could do that, but in this case just extending modUser seems to be fine.

14:43 Using the User extended fields doesn't work when you need to search through the data, as it's stored as JSON.

14:41 Bert claims he can't access the ExtJS files from here, but I think he just doesn't want to show it :P

14:40 To add the tabs to the user edit screen, a plugin is used that triggers on the OnUserFormPrerender event. It also triggers on the OnUserFormSave event which seems to do stuff for licenses. People want to see all code now!

14:39 Several people are mocking the usage of ExtJS. Can't blame 'm. :D

14:38 There's also another component that lists all the users and their licenses.

14:37 Now we're seeing the manager page for the extended modUser that Bert uses for SimpleCart. It has a new tab that Bert added using ExtJS, which shows the API Keys (licenses) for users.

14:35 With extending modUser we're not calling $modx->addPackage; instead we are only adding the extension package (using $modx->addExtensionPackage()) as that will make sure the package is loaded on every request.

14:34 Someone in the crowd recommends checking out MIGXdb to easily build from the schema.

14:33 The build script is run once to generate the models from the schema. The same as regular component development. The build script can be found in the RTFM. See here.

14:32 And that's a wrap! Time for questions.

14:32 We're indeed seeing that the fullname method works. We can still use the xPDO getOne method to get related objects, in this case the dateProfile object is huge!

14:31 Login not working! Okay, it did work the second time :)

14:30 Some clarification based on a question, the first and lastname are stored in the dateProfile object related to the dateUser. So this is stored separately (in the dateProfile table) from the core modUser (modx_users) table.

14:29 Unsurprisingly, the getFullname method gets the dateProfile object, and adds the first and last name together.

14:28 Back to the model to show the getFullname method. Bug spotted! The getFullname method uses the core xPDO methods such as xPDOObject->getOne to load related models.

14:27 We're now looking at an example snippet that checks if the user is logged in (using the hasSessionContext setting) and if so, it returns the fullname from the getFullname method, that was added to the custom user model.

14:26 Question from the audience, is it possible to set a default class key? Answer: not in the manager, but in the frontend using the Register snippet you can set a property to make sure new users are created with that class.

14:25 Of course all normal functionality and methods are available too.

14:24 MODX loaded. We're now seeing the class key is different, but everything else is the same as regular users. Awesome! When the user logs in it will use the custom model (dateUser), so you can access everything as normal (core) user methods.

14:24 Using the normal Login snippet you can login in the frontend of the site with an extended user. We're now waiting for MODX to load...

14:23 Bert explained how using custom methods on the extended modUser object can help keep things organised.

14:22 It's important to add the extended user as an Extension Package using the addExtensionPackage method on the modX object. This is also discussed in the Extending modUser documentation.

14:20 As with normal component development, you'll need to build the model out of the schema. A script for that is available from the RTFM, this one to be exact.

14:19 The manager pages for editing users does not change by using a custom modUser object. You can of course add custom manager pages for editing that.

14:19 Because the relation is composite, there is no need to manually remove the dateProfile objects after removing the dateUser. Aint xPDO awesome? :D

14:18 We're now looking at the schema file which shows a relation between the dateUser (an extended modUser) and a dateProfile which contains the extra data.

14:16 For component developers, the model and schema files are exactly the same as what they're used to.

14:14 Bert is talking about a dating site he built that had specific requirements to the user, such as encryption.

14:12 Bert is explaining the general modUser setup as it is in the core. This contains the modUserProfile (name, address etc), modUserGroup (permissions) and a number of useful methods such as isMember, hasSessionContext and isAUthenticated, generatePassword, sendEmail. Other useful data includes user settings, messages and profile data.

14:11 Bert Oost will be talking about extending modUser today.

Read 8 comments and share your own thoughts!

Get ready for MODXpo 2013 in Cologne!

It's that time of the year again. Working on projects and, oh look at the time fly by! I recall telling myself I wouldn't host MODXpo 2013 so I could just attend a conference instead of stressing myself out... yet here I am again. Along with a bunch of German MODX ambassadors and of course the MODX team, I'm on the organising committee for MODXpo Europe 2013.

Here's the facts you need right now:

  • November 1st (Friday) and November 2nd (Saturday) 2013.
  • 2 days, 1 track, 15 or so sessions, breakout rooms available for work/workshops/hackathons.
  • Lunch and drinks are included on both days.
  • KOMED Meeting-Centre at the Köln (Cologne) Media Park
  • Tickets are on sale now, with advance tickets available until August 15th at € 99. Tickets are bumped up to €149 after the 15th, and will be bumped to €199 in October. The earlier you get your tickets, the better!
  • NH Hotel Cologne Media Park is located pretty much next door. I stayed there a few months ago while visiting a Cologne MODX Meetup and am planning to for MODXpo too.
  • We're looking for speakers!

This year, MODXpo will be slightly different. It will be better. With more people involved in the organisation, a larger budget and a really, really cool conference venue it will be awesome.

Cologne is pretty too. There are talks of a Sunday touristy thing for people who are in town the day after as well, and of course there'll be plenty of opportunity to meet and greet MODXers.

Oh, and I'm bringing modmore swag and discounts, so you really have no excuse to miss this event.

Get your tickets | More information | Speak at MODXpo

Read 0 comments and share your own thoughts!