When and why to choose to use a Drupal custom entity

Introduction

Entities introduced into Drupal 7 and a number of contrib modules significantly improved the data modelling capabilities of Drupal. Prior to entities we were stuck with add-hoc solutions and data modelling that was essentially based on making modifications to data structures designed for page related content.

It is still not trivial to get started with entities however, especially difficult to get past the ingrained response to solving every data modelling problem by creating a new content type and adding fields.

Drupal as a framework (the role of entities)

Introduction

This is my second post in a series of related posts about Drupal entities the first is here.

If Drupal was predominately a framework as opposed to a customisable CMS then you would expect that a skilled PHP programmer with a good understanding of appropriate design patterns from other frameworks (MVC etc.) could reasonably quickly start from scratch with Drupal to build a moderately complex and well designed website.

Unfortunately this is not the case at the moment, the learning curve for Drupal is still too steep for most people to pull this off. One aspect of the "Drupal way" is to not re-invent the the wheel and to use from the massive selection of community contributed modules to implement your required functionality, and this works well for relatively simple sites.

Of course you could point out that Drupal is essentially a CMS, but it is increasingly being used for functionality that goes far beyond a traditional CMS and in those cases it is fair to ask how does it stack up as a framework. Sometimes software like Drupal will also be described as a content management framework (CMF), it may put things in perspective to see a list of software that could be considered in a similar space.

Where Entities step in to raise the bar for Drupal is in the role of modelling data.

Sometimes you have to write code, maybe your requirements are not mainstream enough to have a custom module or you have to integrate with a bespoke API or your clients are using Newsweaver rather than MailChimp or you have to integrate a bunch of contrib. modules in a way that was never envisaged. Of course all those wonderful custom modules required development and Drupal core requires a continual injection of developers that can work on the next generation of Drupal required for the ever involving web.

Not surprisingly the higher paid developer roles expect you to write quite a lot of code...

Background to Drupal entities

Introduction

The first of a series of related posts about Drupal custom entities, all will be linked into here as they are published. If not useful in themselves I hope to at least provide lots of links to useful entity resources online.

Entities were introduced into Drupal 7, they fundamentally change the way you can deal with things in Drupal and pave the way for some vast improvements in the use of Drupal as a development framework (rather than a CMS with customizable bits and modules that can be bolted on).

Entities are not proving easy for people to get into, although embraced by a number of contributed modules, many working Drupal developers don't fully understand or use them and although there are plenty of resources and explanations about them it is not easy to get started using them.

I believe that a key factor in the small number of developers embracing entities is that they are not directly exposed to site builders in Drupal 7, there is no sliding scale of entity use in core, you have to know about how they work and get your hands dirty.

Mastery of Entities may have been 'Take it or leave it' for a lot of developers building Drupal sites in Drupal 7 but I think for Drupal 8 they will be vital knowledge for anybody building medium to large Drupal sites.

Shoddy Drupal security advice from stopthehacker.com

Getting back into twitter and quickly encountering some of the things I dislike about the current social media and information saturation: shoddy content pushed out merely for traffic purposes and that thinly disguised advertising.
This article 10 Simple steps to protect your Drupal site is bad, bad, BAD. Apart from the fact that there is no distinction between upgrade and update (are you really going to do all that just to update a module?) there is some lame advice about file permissions (755 is more secure than 644 really???).

New WordPress blog on the way

I started blogging about language learning many years ago (about seven I think), at the time using a service like Blogger was the path of least resistance, I was working on publishing platforms for online Journals and magazines and didn't at work, at home I wanted to learn languages not more of the same.

Now I feel a need to have an online presence that represents me centrally on the web and I want to control that rather than being enslaved to an online service. I have had (although my name is Christopher David Hall I always associate the full 'Christopher' as being in trouble as that is the only time anyone calls me that) for some time now but put nothing there.

Themeing Drupal 7: Depends on the team

Another steep learning Curve.

A quick comment, following some discussion with other Drupal developers and interested parties last week at the last Bristol & The West, UK Drupal group meetup. It quickly became clear that my search for simplicity in themeing Drupal is ultimately doomed. I know too many ways to do things, there are too many valid approaches.

The consensus appears to be that the skill-set and availability of members in the team will make a huge difference. Having a front-end developer that does not know Drupal inevitably moves a lot of the load back to the back-end developer (or at least introduces a heavy training/knowledge sharing penalty).

Although I can imagine a happier world where the developer is mostly concerned with making sure that the data is there and managing the display tab and view modes in content types, there are lots of times where this is simply not practical.

I shouldn't need a helper module to give me clues about where various bits of the page are being themed. I may have to trace theme functions in the code or trawl through a disparate set of template files that individually give no clue to their heirachy or conceptual inheritance.

Quite a few people seem to be looking forward to Twig in Drupal 8 another post on that soon I think.

Themeing Drupal 7: Checking fields

Introduction

A very general thought, will add more specifics when I have done a bit more investigation.
Considering the template end of themeing (so ignoring theme functions for this thought experiment) and restricting to a node template or field templates. Assuming you have have a set of various different fields (some with multiple values perhaps) and you wish to customise the display of the content somewhat perhaps wrapping some of the fields in html to make a carousel or for something else. Is there ever a case where you need write complex PHP in the template/s?

Drupal as framework pt2 where is my front controller?

Introduction

Continuing thoughts on Drupal7 (and to be fair probably just an exercise in tidying up my brain and not much use to others) as a web development framework, I highlighted one of the major difficulties in part 1 in that you need to know a lot about Drupal before you can use it as a framework.
This post is a quick pointer if you come from a pure framework background and are trying to understand how Drupal 7 works.

Drupal bean module

Introduction

The Drupal Bean module makes blocks into fieldable entities, providing some useful UI features for blocks out of the box and allows developers to create new block types in code via ctools plugins. From the documentation:

"Each bean instance has a corresponding block. Users interact with them in the same way they might use any other block in Drupal. The Bean module does not attempt to interface with the placement of blocks. Bean deals only with the creation of customized, fieldable blocks."

I haven't tried Beans yet but can see how useful they could be, particularly in some places where views are overloaded. Filling bean content via EntityFieldQueries is a viable approach (and probably often better) to many problems that are solved with view blocks.

Further Reading

An interesting looking implementation of beans is the relevant content bean. This is feature in the following bean module tutorial:

The article Views without views discusses beans and this module also.

Drupal 7 admin, some thoughts

Introduction

I keep labelling posts with pt1 and I do intend to re-visit them, however getting tired with that so this is labelled with 'some thoughts', I can always get back with some more thoughts at some stage. Basically for my own consumption, I want to come back later and see where the land lays regarding admin in Drupal 7 and compare to Drupal 8 as appropriate.

Admin interfaces and user experiences are improving, one or two legacy Microsoft based cms interfaces I have had the pleasure to play on were truly appalling things that only worked properly in IE etc. etc. and just made you feel like not wanting to add/edit content rather than making it easy for you to do so.

In light of the above I can see where Drupal administration can seem like a pleasant breath of fresh air, however compared to where it could be, if marking a report card for a student I think Drupal would get a "could do better". When I come back with some more thoughts then I will make a few comparisons but just for now, Wordpress is better, feels much more intuitive. If anybody who has used both wants to argue the point I would be happy for your comments. Note I am not saying Wordpress is better and I recognise that Drupal has a bigger scope but the admin in Wordpress wins out in my opinion (and many others).

Two well known tweets sum up the perceptions around Drupal vs Wordpress:
Dries: RT @chx1975: WordPress is now approximately where Drupal was around Drupal 5 w/ content types. See you in 2015.
and
Dries: Agreed, and fair enough. RT @newoceans_en: @Dries Drupal 7 will hopefully be where WordPress was around 5 years ago regarding UX.

Handing over a Drupal application to a client who has experience of Wordpress can be a little painful, to take a quote from Katherine Senzee when being interviewed about the Overlay (mentioned and linked to below).

I chose it (Drupal) because it was developer friendly, now it is kind of funny that I am spending my time making it end-user friendly.

Some embarrassments

Media assets

Core Drupal leaves something to be desired in the media department, this is to some extent addressed by the Media module. A contributed module, that adds a lot of functionality, however a number of issues will be addressed in version 2 of the module which is still unstable (unfortunately). Some enhancements were made via the media browser plus module but this project doesn't appear to be keeping up with or working well with the media module.

Perhaps things will look a little better on this front in a month or two.

Taxonomies/Menus

These are all by default rather awkward to administer and apply when the taxonomies or menus are large and the widget options for editing don't provide you with something that can easily be handed over to a client.

The overlay

Maybe some people like the overlay feature, but generally it seems to cause occasional errors, hard to work with clients that have old crufty machines or browsers etc. and sometimes errors depending on what other modules you have installed (in my experience). You can hear a bit of a discussion about this here in a Drupal voices podcast..

Maybe I need to spend more time with it, but the overlay doesn't seem to offer me anything that aids in quickly helping me train clients to administer their Drupal site, by default I find myself disabling the overlay module.

Some useful helpers

Dashboard and Shortcuts

The customizable dashboard and shortcuts are a terrific boost to quickly making a site administration better to hand over to clients. Shortcuts to things that they have permissions to use appear nicely in the gray bar (assuming you are using the Seven administration) theme. You can add blocks to the dashboard and make it a the main link they can go to, to re-orientate themselves.

Views

Maybe after one of my previous posts this may seem surprising but views really come into their own in admin, you can provide a tool for the end-user to query their data, very easily with views. Simply creating some of these views and providing a block with links to them in a block on the admin dashboard can go a long way towards making a better admin experience for end-users.

Drupal framework learning curve pt1

Introduction

Drupal is a development framework for people who know PHP and know Drupal, one step more than a pure development framework

Another start to a multi-part posting, this time working in on something that took a little longer to occur to me than perhaps it should. Drupal has a big learning curve for anybody who needs to do custom development. Drupal is often described as a cms that is moving (or already moved) to being a development framework. To use Drupal as framework however requires a good knowledge of Drupal (duh obviously, but bear with me).

Typical frameworks

Development frameworks are typically built on top of a programming language. So for example you may be a PHP developer who picks up a new framework built on PHP or a Ruby programmer who picks up a framework built on Ruby.

Development frameworks are typically built using well known design patterns. The MVC pattern being a prime example (often mistaken by recruitment consultants as an actual framework in it's own right). To this extent experience with one or more frameworks can boost the uptake of a new framework. For a developer or team that has experience with relevant technologies, the programming language and some of the patterns used, new frameworks can be picked up quite quickly.

Drupal as a framework

To use Drupal as a framework you need to know Drupal, you need to know PHP, you need to know about a lot of contributed modules that extend Drupal's core technology, you need to know about the changes from earlier versions (to help make sense of some of the documention that is there) and you need to have spent time learning where to find help and further information. Drupal has nothing to compare with the documentation of many other frameworks.

Granted that pure frameworks don't do anything out of the box themselves and that Drupal is primarily targeted at people that will not program with it, however it seems the overhead for even an experienced programmer to pick up and start running with Drupal is still too high and the patterns you need to help you navigate it too obscured.

What do you think about the Drupal learning curve?

Drupal 7 views vs entityFieldQuery pt1

Introduction

This is the first part of a discussion in which I am hoping to layout a few basic thoughts, get some feedback and then come back with later posts and concrete code examples and design patterns. I am finding it difficult to easily start discussions with other Drupal developers on this topic as it is too easy to slip into a "code everything yourself vs views" discussion. In Drupal 6 Views have become almost engrained as the standard way to solve many problems, some problems that can and should be solved in different ways in Drupal 7 and onward.

Increasingly though I am seeing in comments and posts elsewhere discussion around the new contender for solving some of these problems. A contender that felt like the antidote to the overloading of the 'views metaphor' as soon as I started working with Drupal 7 although I still haven't worked out all the wrinkles. That contender is the EntityFieldQuery.

A very good article was written by Neil Hastings on Building Energy.gov without Views.

I still appreciate views

I am not anti-views, they are very useful, packed full of features, extended by many other modules etc. Often views are the obvious choice for admin tools/reports for users and can be used to give more power to non-technical users. Combined with other modules such as bulk operations or editable fields for example; you can achieve something very quickly that would take a lot of work otherwise.

What I have and do struggle with sometimes is the incredibly complex and 'if it works don't knock it' solutions that can be wrangled out of views. If it takes a fresh developer over an hour trying to work out what is going on with a complex views solutions before they can start debugging a problem, then something is wrong. Once you get beyond a certain point the time you save with simpler views can be quickly lost debugging quirks or behavior that is not what you expect. As you move into contextual filters, relationships etc. there is a lot to learn, using views from within code and the views api, the learning curve can be quite steep.

One thing that views are very good at is a quick route from raw content type to selection and display, there is nothing directly in the EntityFieldQuery that maps to this, so how does it rival views......

Abastraction for data retrieval

EntityFieldQuery rivals views as an abstraction layer for retrieving data. Fundamentally you need to select entity ids (node ids when dealing with node based content) based on some criteria. The database structure Drupal uses doesn't make this very elegant at the database level, tables for each (field and revision of the entity). Selecting your data with sql queries also ties you into a particular storage method.

No code here yet, just a discussion, suppose you have a small content type (a few fields) that needs to undergo some kind of selection process and then get displayed somewhere in a page (perhaps a carousel or similar). A view on the content type that gets displayed as a block would be a typical approach.

Alternatively with very little code you can provide a block with hook_block_info(), specify the block content as the output of a function within hook_block_view(). The function that outputs the content can call on EntityFieldQuery for the node selection and assemble the render array (or return no content if appropriate).

On its own this approach doesn't sound very interesting, however now you have a lot of flexibility to apply randomization, filtering based on taxonomies, caching of the content simply, or basing your cache key on weirdness (that makes sense of your requirements), filters based on things that may be hard to apply in a view, combining selection from multiple queries etc. etc. Maybe drive something from a context using the context module or a cookie the user carries or ... and not worry about whether any of these things integrate with (or can be integrated with) views. You may have to take a simple requirement and add complexity later.

What is more there are lots of ways to customize the output, not least the introduction of custom node view modes in Drupal 7 these can help when building your render array this is key for displaying the different aspects of content in various different ways.

Enterprise level solutions

Ultimately you can define your own entities and extend EntityFieldQuery (it is a PHP class) to meet some of your specific requirements. Defining your own implementation of the EntityFieldControllerInterface or extending the default implementation gives all the potential power you need. Even moving your entity storage to MongoDB

Summary

Although it seems clear that the role of views is (or should be) changing for Drupal 7 onwards, there is not a lot of guidance or clear examples of best practice. I am hoping to generate a little discussion and find out/confirm what the best practice should be.

Break out from Drupal (from the inside)

Quick post: sometimes you (or someone you are working with) may need to break out from Drupal, and generate a special page perhaps based on some existing php code that has been adapted or similar, but that is now pulling data from drupal.

The following code is a brief example of an approach that allows foo.php (in this example) to have full access to any to any variables you may create from querying Drupal and perhaps pick up arguments from the url. foo.php in this case is now responsible for generating the page output.

The use of drupal_exit(); in this case still allow modules to implement exit hooks.

/**
 * Implements hook_menu()
 */
function my_module_menu() {
 
  $items = array();
 
  $items['foo'] = array(
    'title' => t("Foo"),
    'type' => MENU_NORMAL_ITEM,
    'page callback' => 'my_module_foo_page',
    'page arguments' => array(),
  );
 
  return $items;
}

/**
 * My module foo page callback
 */
function my_module_foo_page($arg1 = false, $arg2 = false, $arg3 = false) {
  
  //do some regular Drupal stuff here, populate some variable etc. 

  drupal_add_http_header('Content-Type','text/html');
  include_once('foo.php');
  drupal_exit();
}

Welcome new hook_module_implements_alter

Introduction

Whilst trying to debug something in Drupal 7, I came across a nice new hook a while back. hook_module_implements_alter allows you to hook into any calls to module_implements. You get to find out which hook is being called, and as a bonus to you get to see which modules are returning implementations for the hook and block them if you so wish.

Why is this useful?

I have to admit that this doesn't appear immediately useful, however Jamie has already described very well how you can use this hook. In very quick summary if a module is doing something in a hook that you don't want it to do, you can intervene, you can step in block it and if necessary provide your own implementation, the post I have linked to provides a good explanation of this.

There are other ways in which this hook may be useful, brutally simple to start with is just to quickly find out which hooks are being called for a page request and which modules are returning implementations for them.

function {mymodule}_module_implements_alter(&$implementations, $hook) {  
  drupal_set_message("<pre>" . print_r($hook,true) . "</pre>");
  drupal_set_message("<pre>" . print_r($implementations,true) . "</pre>");
}

This will naturally print a long list, which can be useful in emergencies, this hook could be used for more sophisticated debugging.

Drupal taxonomy manager module

Introduction

I am going to start using this blog to record more technical stuff and ideas, particularly Drupal related, sometimes just random thoughts or comments sometimes, more heavyweight. Hopefully if I tag well and re-organise the blog it should be possible to keep track of various disparate threads and ideas.

Drupal admin is still somewhat awkward in areas, especially in areas like menus and taxonomy where an incredible amount of functionality and a strong api is hampered by administration difficulties in some cases. Managing taxonomies in the administration interface is prime example.

The Taxonomy manager module is a terrific administration module that brings the regular administration of taxonomies forwards in leaps and bounds.

The module

The module has worked well for me in two different scenarios so far, firstly in populating and administrating taxonomies it is far far easier to use than the default Drupal administration. In a few cases I have been able to use this module where I would normally consider populating a taxonomy programmatically. Secondly in the case of a programmatically populated taxonomy that had a huge number of entries normal Drupal admin crashed on display in my web-browser. The taxonomy manager module gracefully handled the display with paging.