+ Drupal - Meaningful Untheming


Israel Office



Europe office


06.03.2014 + Drupal - Meaningful Untheming
submitted by: lior

Maybe it's just me.. But I see more and more DG's (Drupal Geezers) find themselves introspecting and thinking about the technology they have invested their past 7-8 years in.

The web is exploding with tons of amazing javascript mvc platforms, crazy socket madness and stunning widgetry all running client-side (in the browser) with amazing sub-second speeds.

Our reality is that we still live in a world where 10% of the functions we use frequently in drupal end with .+_alter - Drupal typically will output whatever markup you want and then you find yourself wrestling with it and altering it to fit the semantic html you want. To actually get Drupal to come close to sub-second performance means to wrap it with so many caches it looks like an Egyptian mummy.


The main challenge I see with Drupal revolves around theming, because Drupal is a great CMS for beginners it bundles every layer of markup possible so it can be tweakable from the admin UI, but in the process if you want clean, simple semantic markup of blocks, menus, views, panels etc... - you really need to know what you're doing. Thus you see more and more Drupal shops experiment with decoupling the front and back side of Drupal. Drupal is awesome in managing content, users, groups and processes but when it renders that information it's sometimes heavy, bloated and inflexible. The way we approach this is through building the interface with angular.js an awesome MVC javascript framework and connecting through web services to the Drupal containing the data. In the past 2 years we have started to experiment with technologies augmenting Drupal - building apis powered by node.js and mongoDB for scalable mobile endpoints, and building angularjs based widgets that we've inserted in to existing Drupal sites. I talked about this in a webinar by acquia 2 years ago but as we reimplemented these fullstack javascript implementations we felt we needed to standardise around a common solution for our internal needs.

We've merged all of the best practices for fullstack javascript development within the project. MEAN is an acronym coined by Valery Koltarov from MongoDB and is used to describe applications built by MongoDB, Express, Angular.js and Node.js. We and over 3200 developers which stared the project in github are awed in the speed and quality that comes when you're actual building what you need and not constantly altering what you got from Drupal. So we have this awesome js framework that knows how to serve content very well but lacks a CMS, and we have a CMS (that we still love) which does an awesome job of managing content but can do a better job serving it. We combined both worlds with the mean module providing a standard way to bi-directionly communicate between instances and Drupal.

The mean module

Although Drupal 8 is coming up there are tons of Drupal 6 sites out there that want to spice up the look and feel yet maintain the content, ccks and views involved. We thought how to expose the data within drupal to rich widgets or single page applications which either feed information in to drupal or use information fro within to provide a dynamic experience. The mean module (at provides the means to export blocks,menus views and variables to one big json file which is accessed by an angular.js service which reads it and makes it available to the mean application.

Integration Strategies

There are two types of patterns that can be implemented using the mean module.

Mean in front is used in many places as an engine for SPA (single page applications) now we can create applications that are built from information which is held in drupal. Mean provides an interface to load various pieces of data from a Drupal sites and to render a single-page application which uses Drupal as an additional data source. We implemented this approach lately with Strauss an established enterprise customer which had an OpenIdeal - Drupal 6 site which they wanted to face lift. You can browse here to see the result and here to peek in to the drupal in the backend which powers it.

After enabling the mean module you can browse /mean/json/help/me and see the following possabilities...

URL stucture: /mean/json/[TYPE]/[NAME]/[ARG1]/[ARG2]/[ARG3]
currently supported TYPE values and their arguments:
- view - returns results for requested Drupal view object, arguments:
  - NAME - view's name
  - ARG1 - (optional) display_name
  - ARG2 - (optional) items per page value (-1 for unlimited, 0 - skip arg)
  - ARG3 - (optional) arguments divided by '+' sign without whitespaces
- menu - output from menu_tree_all_data() function
- load - looks for load_[NAME_mandatory] function and returns its output
(node_load([ARG1]), user_load([ARG1]), menu_load([ARG1]) ...), arguments:
  - ARG1 - ID or name to pass to load function
- help - /mean/json/help/me will output current instruction
- user - /mean/json/user/logout - Logging current user out
  - /mean/json/user/login (along with name and pass values passed as post
  will log user in and return its object)
  - /mean/json/user/session - returns $_SESSION
  - /mean/json/user/me - returns global user object
- get-mean-packet
  - returns set of JSON objects, set at admin/build/mean-packets
  - NAME - packet's name
To skip any optional ARG, use 0, (example: /mean/json/forum_search/0/5)

Angular apps in blocks/panel panes

In many cases we have to continue hosting with Drupal - for instance if you have a governmental site that has been security cleared to run Drupal there is a very slim chance you could change that. With the next approach you can still get the "single page" behaviour or implement a complex widget that you'd rather implement on a client-side MVC rather then in a bunch of spaghetti code in jquery.

We have been working with a financial client from new-york for the past year which has a huge antiquated drupal-5 site and the ability to insert rich angular.js driven application that connect to the data within the drupal site - can create a modern feel even if you're stuck in the past, it also can provide a clear path to fix sites that can't be upgraded because their core has been altered.

Drush support

One of the concepts and tools we've built to help with both types of integrations - has to do in how to swiftly enter the Drupal data in to a mongodb based db so it can be served effectively to mobile devices, widgets and single page applications. We have bundled the mean shadow module with the the mean module which provides a standard way to sending drupal information upon content update to the Mongo/Node based service. To make the initial import of the data in to the mean easy we provide the drupal shanties (shadow entities) command...

Here are some examples of the possible usage..

 Standard example (all the user entities)  drush shadow-entities              
 Type example (all the node entities)      drush shadow-entities node         
 Id example (specific user)                drush shadow-entities user 42      
 Id example 2 (specific node)              drush shadow-entities node 42      
 Bundle example (all the entites of        drush shadow-entities node article 
 bundle article)                                                              

To summarize - is an amazing way to develop cool and modern applications but the mean module integration lets us start building mean apps now and helps them co-exist and augment Drupal.



Thanks for sharing that. It looks very interesting. I'm definitely in the same camp- tired of the altering nonsense and the layers of complexity and all the unbuilding. Do you use this approach for content display or mainly just single page applications and widgets? Wondering how you handle SEO if the former.
this is really exciting. looking forward to tinkering with this. i think just having a basic structure will save a lot of duplicate code and mental overhead.

Add new comment


Welcome popup block