For those who haven’t been following the Midgard-land, there have been some interesting developments recently. The long-term supported Ragnaroek branch of Midgard1 is slowly fading away, and much of the recent activity has focused on making Midgard2 available via the PHPCR standard, and on the new Create.js inline editing tool.

At the same time the installation story of Midgard2 has greatly improved, with for instance Ubuntu 12.04 LTS providing it straight from the distribution’s package repositories. And Andreas Flack from Content Control has kept on working on MidCOM in his own fork, slowly bringing it towards the state of modern PHP frameworks.

This post focuses on the new improved state of MidCOM, and how that will bring the Midgard CMS story forward. So if you’ve been using Midgard and MidCOM, or if you’ve been curious about them but have never figured out how to exactly try, keep reading.

Why MidCOM?

In 2012 the obvious question might be: why bother with MidCOM at all? Haven’t modern PHP frameworks like Zend and Symfony already made it obsolete?

Well, yes and no. MidCOM is a web framework that has been going on for quite a long time. And as such, it has organizations like Nokia and Lufthansa that have big and important websites and applications running on it. And it has a lot of functionality needed for building content-oriented web services.

An old saying in the industry is that it takes ten years to build great software, and with MidCOM this very much holds true. While new technologies have emerged, few of them can match MidCOM when you get to details.

But at the same time, the long development and maintenance time of course imposes its own constraints. Programming practices, and especially the PHP ecosystem have evolved. And so it is imperative that MidCOM joins this new collaborative space where projects like Symfony CMF allow us to share code and ideas.

A better, cleaner MidCOM

Having been launched in 2003, the original MidCOM was starting to show age. There has been a consensus in the Midgard world that several improvements would be needed, but so far the requirement for LTS stability has kept our hands tied.

Midgard MVC was created as the testbed for how a simpler framework would work with MidCOM’s concepts. It proved a great framework for building web applications, as seen with the Qaiku microblogging service and the Apps for MeeGo appstore. But for real content management, you’d still want the features that MidCOM provides.

If you want to modernize a big framework like MidCOM, the obvious first place to start is tests. You want enough coverage that when you change something, you can be sure that it won’t break something else. Otherwise the refactoring effort would be like dancing tango on a minefield.

Flack’s team has built an extensive suite of PHPUnit tests for their MidCOM fork, and recently we made them run in the Travis Continuous Integration service. With Travis we can easily cover not only the environments developers use, but also variants like different PHP versions. So yes, the new MidCOM supports PHP 5.4 without problems.

Support for Midgard2 was added into MidCOM already during my exploratory Ragnaland work back in 2009, but was never finalized then. The renewed MidCOM development efforts have now brought this to the limelight, and now MidCOM runs just as well on both Midgard1 and Midgard2.

The migration to Midgard2 is critical, as the older Midgard generation is starting to show age, and will be EOLd next year. This will allow the Midgard community to focus on a single content repository implementation, and provides developers new powerful tools like MidgardQuery.

Another important improvement is that now our dependency injection container is accessed through a regular static method instead of a custom superglobal. So, use midcom::get('auth') instead of $_MIDCOM->auth. This reduces our dependency on tweaks only a PHP C extension could provide.

Not all of the MidCOM components have been updated to the new APIs. For the less commonly used ones this is probably best to be handled on per-project basis anyway. More on that a bit later.

Collaboration in the PHP space

After years of isolated projects, the PHP space is finally starting to come together. Partly this is due to projects adopting the Composer dependency manager, and partly because there simply are more good-quality, reusable PHP libraries out there.

Much of this activity centers are Symfony. You may have seen projects like Drupal, eZ Publish, and phpBB announcing that they’re porting their applications on top of shared Symfony2 Components. Efforts like Symfony CMF and PHPCR aim to provide even better building blocks for content-oriented PHP applications, and so I’m sure we’ll see even more movement in this space.

With Midgard we’ve also been eager adopters of this new collaborative mindset. We made Midgard2 available via the PHPCR API, and made the Create.js editing interface so generic that projects like Symfony CMF, OpenCms, and TYPO3 have been able to adopt it.

We’ve also done several explorations of how rebasing MidCOM on Symfony Components might look. The initial approach was the MidgardMidcomCompatBundle, a Symfony2 library that allows running MidCOM components inside a regular Symfony application.

The compatibility bundle work gave us a quite good idea how to map concepts between MidCOM and Symfony2. There is quite a lot of overlap! Now that we have a good, stable and tested base with the new MidCOM, you can expect a lot more to happen in this space.

Using Composer for MidCOM installations has already provided an unexpected benefit: we were able to remove MidCOM’s own URL generation library, and start reusing the one from Midgard MVC. Eventually functionalities like access controls, i18n, and routing are likely to follow suit.

New application structure

The traditional way of building Midgard applications was to keep everything in the database: the code, the content, and the templates. This was great for our original usecase of less technical users that needed to edit things without a shell or FTP access.

At the same time, it unfortunately made Midgard applications very hard to manage using standard version control tools. There were scripts for using Midgard’s replication tools to import and export data from the file system, but this obviously wasn’t enough: programmers want to use their favourite editor, not a textarea.

The first step towards the files was taken when MidCOM 2.0 migrated its codebase to the filesystem. But even then things like configuration and templates have remained there.

With the new MidCOM we aim to change this, and bring everything needed to bootstrap and develop and application to standard, version-controllable files. Content remains in the Midgard2 content repository, but everything related to running code should be loaded from files.

Inspired by the Symfony Standard Edition and the CMF Sandbox, we’ve built a new MidCOM Project Template to guide developers to this new approach. The Project Template provides a simple, standardized structure for your MidCOM applications:

• config for MidCOM, Midgard, and component configuration, and for the MgdSchemas
• src for application-specific components
• vendor for common components and libraries, managed by Composer
• theme for application’s layout themes
• web for the MidCOM rootfile and static files like CSS and images

For long-time MidCOM users, the main point here is moving component configuration from sitegroup-config snippets to the config directory, and the Midgard2 style templates to the theme directory.

As soon as the Project Template stabilizes, you’ll be able to bootstrap new MidCOM projects on the current machine simply with:

$ composer create-project midgard/midcom-project-template myproject

This will perform all the necessary steps from fetching package dependencies to creating the project structure and configuring a Midgard2 database. The resulting project can then be managed using your favourite version control system.

Easiest setup ever

Improving MidCOM itself is not enough, however. We also need to improve the life of the developers by making it easier to manage dozens of active projects.

Vagrant provides a very useful tool for this. Designed exactly for software developers who need to deal with different deployment environments, it makes managing local virtual machines a snap.

I feel strongly that this is the right way to run and test applications. Instead of managing your development environments manually, let Vagrant build you virtual machines that closely match the actual deployment environments, without the risk of messing up your own computer, and at the same time allowing you to keep working with your normal development tools.

Vagrant is essentially a wrapper on VirtualBox which provides handy command-line tools for creating and starting and stopping virtual machines. It also comes with a full integration with the Puppet configuration management system that allows us to do the full setup needed for MidCOM on the first run.

The MidCOM Project Template includes a ready-made Vagrant setup. You simply have to go to the setup/vagrant folder, and run:

$ vagrant up

This is a great time to get some coffee. The first Vagrant VM initialization will take quite some time, as it needs to fetch a Ubuntu image, and run all the MidCOM setup on it.

In the end of the process you will have a fully configured MidCOM setup with Midgard2 and PHP 5.3. Just point your browser to http://localhost:8181 and start using it!

If the complexity of the Midgard CMS stack has been putting you off, this is a good way to get started. And experienced developers ought to value the complete isolated environment this approach provides to each MidCOM project.

Building a migration path

While Midgard2 has been the main focus of development at least since 2006, most users of Midgard are still on version 1. Midgard2 would’ve been ready to run since 2008, but as the architectures differ people have been reluctant to make the jump.

In the IKS Salzburg workshop last June we did some planning, and I think now we have a reasonable migration path.

In nutshell the migration path requires the following actions:

• Switching to Flack’s MidCOM fork and making that the official version
• Switching from PEAR to a Composer-based installation
• Building an easy-to-setup project sandbox
• Writing data migration scripts
• Emulating sitegroup and multilang APIs with workspaces

As you can see from this post, a month after our initial planning session the first three steps are already completed. The other two require still work.

This means that for users still on Ragnaroek MidCOM versions, the right time to start testing the new MidCOM and its deployment model is now.

Next steps

Apart from the migration path from Midgard1, there are also other things going on in the MidCOM space. We need to reduce the size of our own codebase by migrating as much as we can to run on top of common PHP libraries like Symfony Components.

And more importantly, we need to make Create.js the new main editing interface in order to provide a modern user experience.

As you’ve probably seen from Content Control’s demo site, MidCOM already runs quite smoothly with Create.js. So the main thing to do is to make all the main components support it, and merge our older toolbar and notifications with the ones from Create.js.

So, a lot of work to be done. But in the end we will have a faster and simpler MidCOM with a great editing tools. And it will not be an isolated island, but instead part of a thriving PHP ecosystem.

Originally written on a hot summer evening on the terrace of the Helion pub in Wilmersdorf, after a long workday in Kreuzberg.