Leapfrog the Drupal Learning Curve & Architect the Perfect Solution in 3 Simple Steps
Steve Purkiss
Sun, 10/09/2016 - 14:06
"Drupal has a steep learning curve" is something I hear time and again, however I feel this is a misguided perception and something we need to work towards changing - especially now focus is on the adoption journey. Learning how to 'Drupal' is actually incredibly easy - the trick is to understand exactly what Drupal is and how to mould it to your needs - this is what I'm going to show you how to do in three simple steps.
Step 1: Discover what Drupal doesn't know
This is by far the most important step of the process, hence why I go into much further detail than the other two - skim if you so wish but I assure you the story is there for a reason!
We've been here before
As of writing, Drupal has been around for 15 years and has solved many problems associated with building a wide range of web sites and applications, embedding this knowledge in either the core Drupal distribution or one of the 35,000+ modules available on the drupal.org site. Drupal's decision to only provide backwards-compatibility for content and not functionality means this functionality has had the ability to improve over time and make the most of innovation in technology, for example the recent big jump from mostly procedural programming to object-oriented.
A note about the jump from procedural to object orientation
This latest jump was a big one - Drupal was developed before object orientation was available in PHP (the language Drupal is written in), and so developed its own system of 'hooks'. You use hooks to interact with Drupal core to override functionality in order to make Drupal do what you want it to do for you. You can think of hooks like the ones on a coat stand - the trouble here was as different modules and themes overrode hooks, like an overloaded coat stand with many different coats on each hook, it became increasingly harder to work out what hook was changing what and when in the process it was changing it.
There are still hooks in Drupal 8, but these may disappear in future versions of Drupal as the migration to object-orientation continues. An added benefit is more backwards compatibility than before for future versions, so the change between versions 8 and 9 shouldn't be as pronounced as the change from 7 to 8 as we don't have to perform again such a big move as changing the fundamental way the entire code works. I believe there's plans to support backwards compatibility over two major versions from now on, so 9 will be backwards compatible with 8, 10 with 9, but not 10 with 8 - YMMV, etc.!
Knowledge carried throughout generations
The key point to understand here is what Drupal brings along with it as it progresses from version to version. Whilst the underlying code may change in order to improve and make the most of the latest innovation in programming languages, the knowledge, experience, and best practices gained and shared from its deployment to millions of sites is maintained in the API and module layer. It is unlikely what you are trying to build is unknown to Drupal in some way or another, it has dealt with everything from simple brochureware sites which look the same to everyone to sites such as weather.com where everyone who visits sees a personalised version of the site. As I often like to quip, I've never been asked for Rocket Science and even if I was, NASA uses Drupal ;)
This development process is fundamentally different to how other systems on the market work, with many other popular ones focusing on ease of use at the expense of progressive innovation, and is why you see Drupal have a larger share of the market on sites with complex requirements. The adoption of semantic versioning means there are now minor releases which include bug fixes along with both new and experimental functionality, and a new version of Drupal is released every six months. We are already up to version 8.2, and with current focus on 'outside-in' it is becoming easier for people used to systems other than Drupal - or none at all - to use Drupal, however it is not easy to visualise your end goal and know how to get there, or there is a module or modules already out there which could help you along the way to achieve your desired outcome without having to code anew.
To help overcome this out-of-the-box experience there are many ongoing initiatives to provide default content, make module discovery easier, build focused distributions, etc. but they will all take time. There is a way to approach development which means you don't end up going down the wrong path or developing functionality which already exists, it is to discover what exactly it is you want to build Drupal doesn't already know about and focus only on functionality required which is specific to your situation and no other.
What makes you different?
I recently provided the architecture for a high-profile specialist travel site - a six-figure project which unfortunately as with many projects I'm involved in I'm under non-disclosure agreements, doesn't mean I can't talk about the approach I took though, and this is a particularly good example.
As they were merging a number of existing systems I could've just looked at the existing data, however there is nothing to say those systems were designed well and we don't want to fall into the trap which I see many times where people re-create bad systems. Drupal is a very flexible system, many others require you to fit your data into how they work. So by asking the client to explain how their organisation worked and what was different about themselves as opposed to other similar organisations I discovered there were six distinct areas:
Activity - their offerings were split into distinct activity types
Resorts - they operate their own resorts
Accommodation - each resort contains one or more different types of accommodation
Region - the organisation had their own definition of a region, some spanning more than one country
Departure Gateways - they fly out from a limited number of airports
Arrival Gateways - resorts are serviced by one or more local airports
Everything else on the system was something Drupal would have dealt with before in one way or another - number of rooms, features of accommodation and resorts, and so on. These could easily be achieved using fields, taxonomy terms, and everything else Drupal provides out-of-the-box.
Design with the future in mind
I also took the time to observe the operations of the organisation as I walked around their office. I noticed the majority of people were answering calls, so I asked what exactly they had to deal with on the phone - people wanting more information on particular deals, issues with accommodation crop up from time to time - all the usual a travel company would have to deal with but more so here as they owned and operated the resorts. The point here is there's a whole wealth of user requirements contained here which although weren't in the scope of this current phase of development, by having them in mind when designing a system it should make it easier to extend to accommodate their needs as and when budgets and time allow.
If you only design a system for buying via the web you may find when a member of staff is trying to help a customer on the phone the process is unnecessarily complicated, or extending the system to cope with this new use case is particularly hard if you haven't taken this scenario into consideration to start with. Not to say it can't be done, and is easier to adapt now Drupal 8 is more object-oriented, but it's always good to have the future in mind - some of this you will be able to see, some you'll need to extract from key stakeholders, you'll be surprised sometimes with what you find out which you'll then be glad you asked. Here I knew the latest version of Commerce for Drupal 8 has the ability to set up different buying processes so it would be able to cope easily with phone orders if it were ever a requirement.
Design for different rates of change
It is feasible I could've used Drupal's built-in content types to build the system, but this would've limited the system to this particular use-case, making it harder to cope with different buying processes like the one mentioned above. It also did not sound right - an "airport" isn't a content type, it's an entity. It has content - facilities etc. but the thing itself is an entity. So I created six custom entities, and it sounded much better especially when you went to create a view - "list accommodation in resort". By simply teaching Drupal what was different about this particular organisation, we extended Drupal's "knowledge" and leveraged everything else it had to offer to deal with the functionality it does know about, like date ranges, durations, prices, and so on.
Whilst the front-end of a website may go through many enhancements and refreshes, the core business model of an organisation - especially one such as this which is well-established and operated for many years, does not change as much, if at all. In this example they mentioned they may add new activities, and they offered packages which covered more than one activity but their current system couldn't cope with this, which is why activity was treated as a separate entity.
By encoding the core business model of an organisation as high up the chain as you can with Drupal, you end up with a far more flexible system to cope with the faster-moving changes such as views to list out particular promotions, plus ensure longevity by enabling future development of those core parts of the system. I also wanted to make it a little more difficult for them to change any of this as this is critical to the operation of the organisation, so if changes were needed they would have to go through a harder process than changing a view, but there should be a good reason for any changes needed to the core business model so happy with the custom entity approach taken.
Seeing the wood for the trees
It's not only when architecting systems you need to take this approach to Drupal - another small example is when I helped someone out a couple of weeks back who was having problems getting a product listing displaying exactly how he wanted it to using Drupal 7. He had tried a number of different types of views (Drupal's user interface for manipulating database queries) but none of them would do what he wanted, which was to provide a faceted search facility, listing the results grouped by category. You'll see this functionality on most e-commerce sites these days, for example click on Televisions and it'll provide you a list grouped by manufacturer, or perhaps size - the point is it's not Rocket Science, it's been done before, it shouldn't be hard to do, so something else was causing the issue here. Sometimes it's hard to see the wood for the trees, so you need to take a step back and take a logical think about the situation.
We delved into the problem and through a series of questions worked out the thing he wanted to do which was different was he wanted a number of fields to be displayed at the group level - the name of the group, an image, and a description. None of the various combinations of views he had tried provided the ability to display more than one field, and rewriting the field output in the view did not apply to group by fields. Although there are a number of ways to achieve this from different parts of Drupal, I implemented the simplest way I knew which was to output the taxonomy term ID as the field to group by, and overwrite the template in order to load the details of the taxonomy term so we could easily grab the fields we needed.
I can almost hear others screaming at me to use display modes or some other functionality available as I'm sure there's other ways this can be achieved which are 'better', however as I spend most of my time dealing with back-end issues and not front-end and as we only had limited time and budget to solve the issue, this worked as a solution for the situation at hand so we went with it.
The take-away here is to go with what solves the majority of the problem, the thing you see or can imagine seeing other people using, and focus on what is specific to your needs. Faceted searching, listing products, grouping products by category - all standard functionality and should be simple to achieve in Drupal. Outputting multiple fields for a grouping category title? Not so much.
Step 2: Modularise Your Requirements
Drupal is a modular system, so you need to modularise your requirements by breaking them down as much as you can. Yes, what you're wanting to do has more than likely been done before, but maybe not in your exact combination - if it has then cool, you don't have to do anything as there's already a module/distribution/theme/etc. out there for you! Many times there isn't though, and every organisation has their differences, so you need to break your requirements down in order to deal with them successfully.
In our example above where we have a faceted search listing out products grouped by category, by splitting it up into "faceted search", "list products", and "group a view by category" we are going to get much better results when searching for answers than if we search for "faceted search grouped by taxonomy", which is more specific to our use-case than the majority of uses. You're more likely to end up with someone else's specific situation who also has had issues solving it and may forever skip past the actual solutions you are looking for. Be as generic as you can with generic requirements, then be as specific as you can with the ones you identified as particular to your situation, in this example we could've searched for "override view field output" and it would've brought us results for how to override using views templates, which is how we solved the problem there.
Once you align your vocabulary more closely with Drupal's generic, modular functionality, you'll enjoy much more success with your searches - it takes a little logical thought and remembering it's not Rocket Science! Far too many times I've seen sites where little or no research has been done as to what's already out there and people have essentially forked Drupal, creating their own monster significantly increasing the amount of work it takes to maintain and extend the site when it's not necessary.
Every line of code you produce is technical debt - even if you decide not to use the module you find which does what you need or part of what you need, you can study the tried-and-tested code, copy it into your module and use as a base for your work. A good example is detailed in my previous blog post about creating a Drupal Console command where I found code which did some of what I wanted so I based my work on it because I knew what had already been written worked and there was no point in me writing it again.
Step 3: Only Develop Specifics, Share Where Possible & Grow Drupal!
If you find you have to develop specific functionality for your site, have a think about if it would be of use to anyone else, or whether you're going to be the only person in the world doing this specific thing. As mentioned above, every line of code you write is something you or your client is going to need to support your/themselves. If you publish a module to the drupal.org module repository you not only have the possibility of others sharing the maintenance of the code but they may also provide enhancements, and stable module releases are covered by the security advisory policy which doesn't mean they secure your module, but if an exploit is found and reported the 40+ strong Drupal Security Team are there to help. Even if you just create a sandbox project you may discover others find the code useful and provide feedback.
If you're working for a client and they are worried about sharing code, or you're the end client and worry about losing competitive advantage, remember software is easy to copy and it's the rest of what you do which sets you apart from your competition. In our travel example above, it's the resorts they own which provide the value to the customer, not the software code which enables people to book a stay in them.
Currently there is a lack of sharing code on the implementation side - there's a lot of factors for this including competition between suppliers, infrastructure ease of use or lack thereof, and a general lack of co-operation in some industries. The result is many people end up writing similar code when they could be starting at a higher level, collaborating with industry peers, sharing development and maintenance costs, and going towards pushing the Drupal project forward. The more we can do out-of-the-box, the better it gets for all concerned as projects cost less, launch quicker, and we can focus on code which isn't out there already which is specific to the organisation itself, so spending the development budget on genuinely useful code instead of code which could be freely available to us in the first instance. Remembering how much we started with for free may be of help creating impetus to share any code we develop.
Although my site here doesn't do much functionally I haven't had to write a single line of code to be able to use the web to communicate my message to you, something I believe is amazeballs! Drupal can and does provide code for generic websites, however it's up to industries to collaborate and build their modules and distributions, and/or some enterprising people to build code and distributions for them, as we see in some areas such as e-learning and government.
I'm honestly shocked when I hear projects haven't contributed any code back, especially larger projects lasting longer than a year - I worry about how much technical debt they've incurred and feel sorry they haven't helped Drupal to grow, it's only by contributing code the Drupal product itself has reached this amazing level of innovation. I understand there are reasons, however I never see it as "contribution", more akin to riding a bicycle - I can stare at it as long as I like but until I push my feet down on the pedal it's not going to take me anywhere, I don't call it "contribution", just how the bike works!
I hope this post has been of help, do feel free to comment below, or get in touch with me if I can be of help with anything specific.
Happy Drupaling!
Main Drupal 8 Learning Curve image courtesy @sgrame. Other images attributed inline, the rest are public domain, found on pixabay.
Category
Tutorials
Tags
Drupal Planet
Drupal Architecture
Data modeling
drupal
Add new comment