... you're more worried about your cache than what your significant other is doing with the joint credit card. And 12 more signs you've worked too much with MODX.
Hello! Welcome to my humble web presence. I'm Mark Hamstra, 30 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.
Throughout the history of our awesome CMS, figuring out how the word is capitalised hasn't always been easy. I answered this life long question on MODX.today.
It's been a while since I published anything on my personal website. Work at modmore and for my freelance clients simply take a lot of time, and blogging has never been something I did on a regular schedule.
That doesn't mean I don't have ideas on what to write - quite on the contrary. There's probably two dozen unfinished posts I've been meaning to complete and finish, but I never had the time.. or rather, the feeling it was urgent enough to make time. Do people even visit my blog anyway?
Now we've built something really cool with modmore that is going to change that - and already has.
The all-new shiny MODX.today website is a project from modmore that aims to be a daily-ish news source for all things MODX. It complements official sources, like the MODX blog, with editorials, reviews, tutorials and links to other interesting articles around the web. And with a weekly reading list, anyone can stay up to date with minimal effort too.
But best of all though, it's a project for the community. Anyone can submit an article and I hope that people who didn't feel like they have a platform to publish their thoughts and knowledge, will find their way to MODX.today now. Together, we can build and maintain an awesome news platform that keeps people updated and excited about the many initiatives and great tools around MODX.
Christian Seel did the design and front-end, while I worked on making it work and writing a bunch of content so we have a buffer to get through the first few weeks while we continue producing content. There are some great articles lined up, including a preview of the new Premium Extras from Extras.io, answers to age old questions about the MODX brand, a couple of tutorials going into more detail on how we built MODX.today and lots more.
As for this site? It's still a place for me to publish some of my thoughts, so maybe we'll see some more posts here now that I've been getting into the habit of writing more. Maybe not. Time will tell!
Add-ons will be called Apps in 2.3, but the name doesn't matter - it's the extensibility that makes MODX great.
Blue and orange is what MODX used to look like.
Designers and Developers love MODX for different reasons.
Evolution is the MODX Legacy that oldies wont forget, and is still being used by some.
Forums are the heart of the community.
Global would describe the MODX Community best, aided by many available translations.
Huge numbers of MODX sites are out there, but nobody knows exactly how many because it's impossible to track.
Integrating custom markup into MODX is as easy as copy, paste, replace content with tags.
Join the MODX Weekend 2014 for 15+ sessions of MODX & Web goodness, on September 19-22 2014.
Large or small, MODX handles them all.
Nothing is impossible.
Open Source, of course.
Quantum Physics will be possible in MODX3, or it will not.
RTFM supposedly means Read The Free Manual, but we all know it doesn't, right?
SiteCheck is a great addon by community hero and author Bob Ray, available here.
Templates and Tags are what makes up the bulk of MODX sites. They're simple yet super powerful.
Users can easily and intuitively manage the entire site with the sitemap-like resource tree.
VersionX can save your content and elements when editors make mistakes, so install it when you work on a site.
Web Content Platform is my preferred term for describing what MODX is, over the more prevalent CMS or CMF
XPDO is at the core of MODX and provides a secure, object-oriented way of dealing with any data.
You can help make MODX better by reporting and confirming bugs, developing patches or contributing documentation and tutorials.
Zero letters are now left in the MODX Alphabet. Now post your own..
17:51 And that's all. This means (almost) the end of the conference. Thanks for tuning in!
17:51 Suggested to use Vapor instead.... yep, that's going to happen soon.
17:50 The download is not a transport package, just a dump of an actual MODX installer.
17:49 Bert is plugging his command line installer that lets you choose (by responding yes or no) what you want to install (editors etc). This is different from a Distro as you only install what you need. Somewhat sounds like the configurator mentioned before. Find his installers here.
17:49 [Q] Do you also update packages? [A] Packages are not bundled with the distribution, they are downloaded directly from the MODX package provider using the APIs.
17:47 [Q] How do you stay up to date with the official release? [A] Patch versions (2.2.9 -> 2.2.10) are manually upgraded locally. This is then tested. SiteCheck from Bob Ray helps with this.
17:46 A configurator (like Foundation) would be great, but the distro is not there.
17:44 Everything we saw today is in the download link for people to try.
17:44 [Q] Have you seen SiteCheck? [A] Yes. It's a great tool, find it here.
17:43 [Q] What about performance? [A] Haven't noticed much but if you would profile carefully it would likely be a bit slower than a clean install.
17:42 End of presentations, time for Q&A.
17:42 Get the package: bit.ly/1ajv2nP If you have any feedback, email email@example.com.
17:42 In the next version there might be some work for purging unused elements. Bob Ray's Orphans can help.
17:41 You either love MIGX, or you hate it. Steve loves it, and Susan will have its children.
17:40 More commerce is on the work too.
17:39 A lot of elements are in the database, but putting stuff on the filesystem through static elements is what will likely happen next.
17:38 Beanstalk acts as a holding server. Deployments are made via a number of bash commands over SSH. This is manual, but explorations into automating are being made.
17:37 Everyone works on a local machine. Every change is made locally and comitted. They're using Beanstalk and Subversion (no Git yet, but it sounds like that wont take long).
17:37 Next subject: Workflow.
17:35 On to Elements. There are 10 templates, 32 template variables, 56 chunks, 30 snippets and 5 plugins. That's before any Extras are installed.
17:34 There are no less than 52
resources pages in the default install. This includes home, contact, sitemap, robots, pages for login management etc. Most of these are hidden from the client.
17:33 When clicking the MODX Support button, it goes to a form on the Blaze Concepts website. The Help Videos provide a MODX modal with general instructional videos for working with MODX.
17:31 This dashboard was for the admin. Now we're looking at the client dashboard, which is very stripped down. The Elements and Files tabs are gone. In the dashboard there still is the Manager Quickstart and a resource list, as well as some additional Help & Support sections.
17:30 There's pre-flight checks too showing reports of resources to see if all the required information is there, such as aliases and titles. The update buttons opens the quick update.
17:28 But there's more! There's an email check to make sure the system email is properly adjusted to go to the client.
17:27 Some developer tools include export database, a link checker and a link to Pingdom to check the speed. The Manager Quickstart checks if certain extras such as Articles are installed, and provides links to commonly used stuff.17:27 Here comes the custom dashboard. Using Christian Seel's custom dashboard buttons and a list of media sources.
17:24 Custom Dashboard screenshots are coming up in a bit. As the team uses Foundation, that is also pre-loaded, under version control and available immediately.
17:23 My ClientConfig is installed with 5 tabs of settings in this distro too. :D It also installs cart configurations for ecommerce.
17:22 Awesome slide to explain why lexicons are changed...
17:22 Additionally, media sources and form customisations are also pre-configured and set up, along with some lexicon changes. This is one big distribution!
17:21 ACLs and Resource Groups are also pre-configured to skip the complexity.
17:20 A package installer will download 25 extras with one click and install them all as well. Lot of extras, but they're all often used.
17:19 By using a custom installer with a checkbox to install a default database, the setup process is super simple. Unchecking the checkbox is enough to get a clean, normal MODX install. Some other small changes (file paths, thumbnails and ExtJS) have been made as well.
17:18 The general distro that will be available after the session is no less than 50mb and 7.1k files in size. The normal MODX setup is a mere 5.7K files and about 8mb, so definitely a lot bigger.
17:17 The main benefits for distros include Team Consistency, no repetitiveness (only creating snippets or chunks once), a higher development speed and a more efficient support for clients.
17:17 Steve emphasises it's just their way of doing things and that it can be done differently as well, of course.
17:15 Custom distrobutions are cost effective, and it helps being as prepared as possible. It's easy to make certain features available for clients, just by publishing what they developed before and charging big bucks for it.
17:14 Definition of a Distro: An industry specific, pre-loaded installation of MODX that can be rapidly deployed and developed upon. Not a complete solution, but more a bedrock for development.
17:13 Steve was doing a lot of similar work in the education sector, and as they were all asking for the same thing they wanted to build stuff smarter. Constantly using the base install of would be silly.
17:12 The 6Ps is a mantra for Prior Planning and Preparation Prevents (Piss) Poor Performance (and Pain).
17:11 Talking about what we'll hear about today. Distros for teams, manager customisations, workflows and case studies are coming shortly.
17:10 Greame is also live blogging.. would be interesting to see the differences in reporting! Check it out here. I didn't grab a pic of the monkey unfortunately :D
17:08 Technical problems sorted, we're starting!
17:05 We're still waiting to start, shouldn't take much longer. Thanks for tuning in!
17:50 In about 10 minutes we'll start live blogging the presentation by Steve King: Distros for Success, the 6Ps.
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 :)