WordPress learning from the code in

My knowledge of WordPress is increasing quickly with little bits of time here and there, and I think I have finally found some functionality that will require me to develop a proper plugin, there doesn't seem to be a plugin that gives the same functionality of node references in Drupal (although that appears to be giving way to more generic entity references). Basically I want to add another post type and make a reference to it from normal posts. I have to trawl through the plugins some more but so far nothing does exactly what I want.

WordPress from the ground up

Introduction

I have been putting some time aside to learning WordPress recently, in the the past I have had to do little bits and pieces on WordPress sites or a fiddle with something that doesn't quite work on a site built by someone else on top of a specialized theme that has been purchased. I wanted to learn how WordPress works from the bottom up.
I also want to get a feel for how much customization is possible and the feasibility of using WordPress as a development framework. I have a personal project in mind that theoretically I could build in Drupal, however Drupal is a bit weighty for what I want and a WordPress based project should be much easier for people to set up and install.

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.

When buying and reading books just works

A quick post about Kindle, Amazon and something just working

Whilst thinking about another blog post I wanted to write I remembered a book I read a long time ago: The Computer Connection by Alfred Bester. I decided I wanted to read it again, hooked up my Kindle to company wireless, went online, purchased from Amazon and a few seconds later the book is ready for me to read on the bus journey home to-night.

Important to me is that:

• I can choose to read it on my phone, Ipod touch or PC
• My partner can read the same book on her kindle if she wishes
• I can keep everything in sync across these devices
• I can do the things I can do with a real book, but with extras added.

My book is not locked to one device, not keyed to scanning my retinas to ensure only I can ever read it or any other such non-sense. Amazon (and booksellers I presume) can make a profit without putting my reading experience into a straitjacket.

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.