It is with great pleasure that I can announce the first release of the MasterPress plugin for WordPress. This product represents around 24 months of planning, design and development, and I’m thrilled to be able to finally get the word out.
It’s not the destination, but the journey that counts…
Now that I’ve stamped MasterPress with that elusive 1.0 number, I’m not sure I buy this quote – the destination is a nice place too. But the journey has been a long and (hopefully) interesting one, and I’d like to share a little more about how this product came to be.
Like many successful products, MasterPress was created to scratch an itch. That niggling thought I’ve carried around with me for years, that while there were some great content management systems around, I still couldn’t find one that works just the way I wanted it to. I’m sure this is, or at least has been, a familiar state of mind for a lot of web developers out there.
2009: Learning to get along with WordPress
In 2009 I became tired of trying to build my own content management system, which was an ongoing side project, and decided it was time to embrace one of the major platforms that many others were using. I spent some time playing around with 3 of them:
- ExpressionEngine: the product that the cool-kids were flocking to, and many of the smartest minds on the web still swear by today. I did build one client site with ExpressionEngine, and I couldn’t quite get past the structure of the backend, which just never felt quite right to me at the time. It appears that ExpressionEngine has improved a lot with the release of version 2, but I haven’t quite had the time since then to take another look.
- Drupal: The über-powerful CMS. I’ll admit that I never gave Drupal a serious chance, and I’m sure it’s a powerhouse once you know your way around. But for me, Drupal had a very steep learning curve, and my fear about clients not quite grasping ExpressionEngine were about ten-fold toward Drupal.
- WordPress: in my mind, WordPress was easily the most accessible user interface to jump into at the time. But in 2009, WordPress really did feel like a “blog engine”, given that custom post types were yet to arrive with version 3.
So I chose to work with WordPress, as it just made the most sense to me. While WordPress core wasn’t quite so powerful in 2009, the plugin ecosystem was great even then. And one plugin I really liked working with, which some of you may remember, was Flutter by Freshout.
2010: Contributing to Magic Fields
Life was good with WordPress and Flutter – I could set up “custom write panels” to create different types of content, which acted very much like the custom post types WordPress users know and love today. (Side note: Flutter was itself a continuation of a plugin called Custom Write Panel, by Rhymed code). Another crucial feature of Flutter was the ability to define custom fields of specific types attached to these write panels, giving you the ability to heavily customise the content entry experience for clients.
New development on Flutter started to slow down in 2009, so David Valdez (@gnuget) and Edgar G. (@hunk) kept the ball rolling with another plugin called Magic Fields, which I quickly adopted. I used Magic Fields for quite a few projects at the time, and found myself hacking away at the stylesheets and PHP files to tidy up the user interface, as I’ve always liked things to “look the part”.
In September 2010 I decided to stop hacking away, learn how to use git properly, and fork the github project. Around this time I was building a site that used a lot of multi-item field groups, leading to content entry screens which were a little overwhelming to say the least. So I came up with a way to collapse these field groups down to summary views, which turned out to be a great way to present a lot of custom field data to users in a fairly concise way. The Magic Field guys agreed, and brought my changes into the plugin for version 1.5 which was quite well received – this was a huge honour for me, thanks again to David and Edgar.
2010 – 2011: The API
I continued to work away at Magic Fields on the side, but didn’t do a whole lot more on the user interface. There was another aspect of both Magic Fields and WordPress I found to be a little tough to work with – the developer API. I started coding away on an object-oriented API which would allow custom fields to be accessed hierarchically via objects, instead of the “get” function calls they were using at the time.
Originally this API was more concerned with the custom field data created by Magic Fields, but as I worked on it I started to see a lot of benefit in wrapping up more and more of the WordPress API as well. This work was the foundation for what has now become the MasterPress API. I’m really very proud of this part of MasterPress – it’s a lovely API to work with (yes, only a developer would say that).
2011 – Building the product
The Magic Fields project was in a tough place at the start of 2011. Custom post types had been introduced into WordPress in June 2010, so many people rightly wanted the Magic Fields plugin to scrap the custom write panel setup. Magic Fields continued to be developed and was later released as a completely rewritten 2.0 in October 2011. In the meantime I decided to go it alone and build something of my own, completely from scratch. I also decided to build this product as a premium plugin striving for a level of polish befitting of a commercial product.
So, armed with a copy of the superb Professional WordPress Plugin Development book I set about learning how to build this thing on my own. Long story short, 2011 was a very intense year of designing intricate interfaces in Photoshop, creating a lot of very tricky PHP, HTML, JavaScript and CSS code for the administrative sections of MasterPress, and bringing all of the work I’d done on the object-oriented API into the product as well.
On the side of all that, I was developing a number of web sites for The World Economic Forum (using MasterPress as I went), and home life involved helping to look after a little girl, with another little guy arriving in October. Fairly busy 🙂
Alas, by the end of 2011 I reached a point where I had built a really nice plugin. I’d be able to release this thing really soon! So I thought …
2012 – the year I realised that releasing a product is hard work
Without going into too much detail here are all the things I had to do in 2012:
- Design a product web site
- Build a product web site, with all the latest bells and whistles like responsive design and high resolution images.
- Write over 900 PHP class and method posts for the developer documentation, each with examples.
- Write about 40 long-form posts for the getting started guide and remaining sections of the developer guide.
- Create a Pty Ltd company structure
- Get legal help to write up Terms and Conditions and a Privacy Policy.
- Keep cranking out client work
- Continually improve the MasterPress software
- Live
This was, in short, one of the hardest years of my life. I have a newfound respect for anyone who has ever created something like this – whether that’s creating software, building hardware, writing a book, releasing an album, or any of the million other things you could think of.
2013 – the “finish” line.
So here we are in 2013, and I’m really happy to have made it this far. Hopefully this product will fill a need for a lot of people – if it does, that’ll mean all kinds of new challenges in the year ahead.
I really must thank my family and friends too for all of their patience and support in the last 2 years. And for this fabulous special-edition launch poster too:
Thanks for reading!