As a developer, I truly think that WordPress is an amazing platform to work with. I tend to use it as a CMS mostly, I find that it's packed with nice features that make our lives easier when developing, allowing us to build great sites. I'm also a big fan of the administration interface, its design and all the functionalities that are available in there.
On the other hand, WordPress is a main stream open source project, which means that's it's not tailored to yourself, and may not reflect what the client wants at first. So, how did we tackle this issue and managed to propose to our customers an administration plateform that is actually useful for them?
WordPress has a very capable admin interface with many features. Maybe too many we can actually argue as far as our clients are concerned, as we found out that plenty of interface elements weren't particularly useful to them. There was room for improvements in order to make administration easier.
We have a strong demand for custom developments from our clients. We provide hand made solutions for their needs, so we needed a development environment that would be able to welcome our development processes and tools.
Who, as developer didn't face the same same routine when starting a new project? You install, WordPress, donwload some plugins, organise your files into folders... We wanted a way to automate this as mush a possible to avoid loosing energy.
The Back Office
We improved the back office in different steps. First, we cleaned up the interface by removing or rearranging default WordPress Elements. We followed by changing more deeply the default look, to lean towards a rather personalised theme. We then improved our product by bundling more functionalites with time.
This was our first step. We knew that when working with WordPress, you have at hand a very wide set of features at your disposal to administer your site. On the other hand we also knew that some interface elements wouldn't be used by our clients and some other might be a bit daunting, or distracting. That's why we used WordPress hooks and filters to hide some bits of the interface, modify some others, give more importance to certain ones, in order to achieve a clearer and simpler UI. The default dashboard for example, has been completely changed, to focus on module administration, and stats.
We started using WordPress more than 4 years ago, which at the time, was around version 3.0.something, and the admin interface design, as you can imagine, was far from having the look it has today. Our approach was to give the admin a visual refresh that would serve the administrator by serving him a more pleasant workspace, as well as giving the admin a more branded product look, and when you look at the default WordPress administration skin today, it seems that we were visionary!
We benefited from having a particular administration setup to auto include certain plugins that in our sense, improve the back office. I've for example, never been a big fan of the page list, that we replace by a tree view. We have integrated a suite of default plugins which includes a security plugin, a SEO one, an analytics one, a cache one, a migration one and so on. This pack adds some power to our default install.
Allowing custom developments
We do a lot of hand made solutions for our clients. Those web applications are built in house, with our own tools and methods. It was all very good to have a fancy administration interface, but it also needed to work with our custom php framework.
Interfacing a php framework
On one hand, we had WordPress. By default, when coding with WordPress you can code at theme level, or at plugin level.
When building a theme, the default WordPress way of working is via template files, and functions. From the PHP point of view, you can use objects, but it's mostly procedural, and with no mvc pattern.
If you write a plugin, it's a bit different, you are responsible of the plugin logic and architecture, you can do some Object Oriented Programming or some MVC if you want. But how to maintain coding standards accross severals plugins? How to prevent code duplication?
On the other hand, NOE interactive has its own PHP framework called NOEPHP. It's based on a collection/model design pattern, a bit like Backbone.js, and it is used for all the company's in house developments.
With NOEWP, I worked on bridging the gap between those two worlds, in order to ensure we could be effective in coding cutsom websites on top of WordPress. It has been made possible by the extreme modularity of WordPress and its hooks and filters system. It allow us to interface our tools without having to modiy any of the WordPress core files.
Creating custom administration modules
Now having between our hands a fully capable CMS, and a fully mastered framework on top of it, we got to work and created a series of administration modules for our clients. When we create a new module, we version it in a way to keep a clean version, and ensure that when we'll need it again, we won't have to restart all over. This product approach allowed us to improve our modules over time, they gained functionalities, more stability. It saved us a lot of energy. We now have over 20 modules to choose from including some of those:
Noe Starter Theme
Our team of several persons develop several websites per month. Based on this fact, we created the NoeStart theme in order to capitalize on each development we do and make sure everyone gets a head start when beginning a new project.