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?


Transform the Back Office

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.

Allow custom developments

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.

Kick start projects

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.

Cleaning up the interface

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.

Administration Theming

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!

Adding functionalities

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:

  • Actualités
  • Agenda
  • Annuaire
  • Cartographie
  • Contact

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.

Assets optimisations

Our assets files are concatenated, minimized and cached automatically thanks to our custom built grunt tasks, in order to serve the most optimized assets to the brwoser.

Multi Language

We integrated a full multi lingual administration layer to noewp to help our clients easily touch an international audience. We opted for the use of administrable php constants to translate our sites.

Default markup structure

A key part when trying to optimize our development processes, as making sure everyone applies the same markup logic when coding a view gives us a productivity boost when realising a new theme or maintaining an old one.

Applied Design principles

Another step taken in the direction of improving productivity. We wanted to get away from the situation where every developer codes a css frontend his way, and differently on every project. We acted some design rules to follow, and we even coded some directly in our style guide.


We write our markup with SEO in mind in terms of structure, optimisation, semantic, and micro data. We enhanced the back office to be able to provide SEO optimized page titles and descriptions easily.

Enhanced Search Engine

The default WordPress search engine searches in pages and posts content. We improved it to search in administration modules as well as within the content of files such as pdf.

@Bentoutif Il occupe tout le monde afin que pendant ce temps on parle moins des résultats moyens de l'OL. A la Mourinho. Et ça marche.20 Sep / 09:12