Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 45 min 56 sec ago

Conocimiento Plus: What Google Code-In and Drupal meant to me

Tue, 03/02/2015 - 18:24
The more I learn, the more I realize how much I don’t know. - Albert Einstein Background I was thirteen when I first got access to a computer, I had no idea about how to connect to internet and when I was fourteen I had watched a documentary about Google and discovered that there was […]
Categories: Elsewhere

Lullabot: Understanding JavaScript behaviors in Drupal

Tue, 03/02/2015 - 18:00

I can barely remember the first time I added JavaScript to a Drupal page using a custom module. I'm sure looked at the documentation, took the example snippet, tweaked it, tested it, and moved on to something else. It was only later, using a debugger, that I saw how Drupal's "behavior" system worked and realized that my code was not being executed as I expected.

In this article, we'll cover the key facts about Drupal behaviors, then look at a real Drupal project to inspect its behaviors and optimize them.

Categories: Elsewhere Time to start translating Drupal 8!

Tue, 03/02/2015 - 17:33

Drupal 8 is in the beta releases stage getting closer to supporting an upgrade path. It is still in development and there are still some interface changes expected. As per the beta changes policy interface string are unfrozen and user experience improvements are prioritized. On the other hand, I don't know of major initiatives to change the interface strings and I believe most of the interface should be considered stable at this point.

As we are getting close to releasing beta versions with support for the upgrade path, that means more sites will start to use pre-release versions of Drupal 8. This helps find bugs and we would love the multilingual system to be (even more) thoroughly tested as well. We need translations for that to happen. We also need translators to look at source strings, so they submit issues found in them.

So while the user interface is not yet frozen, there are various good reasons to start translating Drupal 8 now. How fast should you plan to complete translations? Strings will likely be frozen with the first release candidate (which is cut when there are no more critical issues against Drupal 8). However that release candidate may become a release if no more critical issues found as early as a couple weeks after, so starting translation at RC1 would be too late to be ready for the release. You should consider starting sooner than later.

To make that process easier, we introduced a new Drupal 8 translation status page at which lists the languages by completion status based on the last exported Drupal 8 translations available. Congratulations to the Spanish, Danish and Finnish team for being the top three! We also made it easy to access the multilingual demo from that page and included some advice on translation readyness as well as a step by step guide to new contributors.

You are encouraged to start translating Drupal 8, organize local translation sprints and test your translations by installing the new version in your own language. Big Drupal events like DrupalCon Bogota host multiple days of sprints where translators should join and take their space. The next big event coming up in Europe is Drupal Dev Days in April with a week of sprints.

All of the new Drupal 8 APIs should be supported now on the site including default shipped configuration. If you find something on the Drupal 8 user interface that is not translatable, submit a Translation template extractor issue and tag with "Drupal 8 compatibility".

Balu Ertl collected a list of 1200 "easy" Drupal 8 strings to translate to your language. These are 1, 2, 3 or 4 words long.

One final tip to get started faster. does not (yet) support matching of strings that slightly changed from Drupal 7, however it brings in exact translations of modules that were added to core, such as Views. To match slightly changed strings, you can do the following:

  1. Download the complete Drupal 7 translation of your language.
  2. Using the Export tab on your language, export a full translation template (with untranslated and translated strings included) of Drupal 8.
  3. Use the gettext msgmerge tool to find fuzzy matches locally.
  4. Review and correct the translations locally.
  5. Finally import the new translations to the site with the "Multiple contributors" user for proper attribution.

Thanks for making Drupal 8 happen!

read more

Categories: Elsewhere

Aten Design Group: Responsive Images in Drupal: Part 1

Tue, 03/02/2015 - 17:17

Solid imagery can make or break a design. In our current world of changing screen sizes, screen resolutions, and bandwidth the effective use of imagery has not only become more important, but a lot more challenging.

You may want to serve up a scaled-down image in an effort to optimize performance. You may want a scaled-up image to optimize for high resolution devices. Or you may want to serve the same image, cropped differently to work better with layout changes at different breakpoints. HTML5’s ‘picture’ element addresses these challenges, and so many more.

Using Drupal, we can automate the creation of the needed versions of a single image, making content creation that much easier. In part 2 we’ll look at opening up control over the art direction of the images, while still maintaining the design’s layout rules.

Setting up the image stack

First we need to create the image styles for our breakpoints. We have three contexts to plan for; small, medium, and large displays. There should be an image style for each, and for now it should have a Scale and Crop effect set to our dimensions.

Setting up Breakpoints

Drupal needs to be made aware of the breakpoints our site uses, and the Breakpoints module does just that. Install Breakpoints and its dependency, CTools. The Breakpoints module has two ways to define breakpoints, in the interface or in your site theme’s .info file. We’ll use the interface (admin/config/media/breakpoints) to create three breakpoints.

Next you need to create a Breakpoint Group (admin/config/media/breakpoints/groups/add). Imagine you have several more breakpoints defined, but you want to pick specific ones to apply to one component of the site. With Breakpoint Groups, you have that ability.

Setting up the Picture module

While the Breakpoints module handles the definition and organization of breakpoints, the Picture module uses Breakpoint Groups to create the markup. Enable the Picture module and add a new Picture Mapping (admin/config/media/picture).

After you’ve chosen your Breakpoint Group, you’ll have some options as to what should happen at each breakpoint. In our case we want to match each breakpoint up to the appropriate image style we created earlier.

Applying this to an image field

Once all this has been set up, we can now use our Picture Mapping as a field formatter for an image field on the site. Visit the Manage Display tab for a content type with an image field, and set the Format to the Picture Mapping we set up.

One important thing to notice is the Fallback Image Style. This is what image will be used in browsers that do not support media queries.

Wrapping up

If you create a piece of content, the rendered image should get switched out if you view the full node and resize the window. The only downside to this is Drupal is deciding what the focal point of the image is, which may not always be desirable. In the next part of this tutorial, we’ll look at using the Manual Crop module in order to give that control back to content editors.

Categories: Elsewhere

EchoDitto Tech Blog: Rapid Drupal Scaffolding with Yeoman

Tue, 03/02/2015 - 17:06

Simple things should be simple, complex things should be possible.

– Alan Kay

The Console module in Drupal 8 has a lot of developers excited, seeing as it has built in support for scaffolding out and generating modules at the command line. This particular feature will put Drupal in line with some of the other more MVC-like frameworks out there, like Ruby on Rails or Laravel, which both have a suite of supporting libraries that take some pain out of development by generating reliable boilerplate code.

This is all well and good, but what about Drupal 7? The Drupal 8 release date may still be a bit far off, and even then many Drupal 7 sites will still need maintaining, as a lot of contrib modules will be slower still to make the complete switch. Yet, we can have our proverbial cake and eat it too. Yeoman is a language-agnostic scaffolding framework which relies on Node.js. By allowing the user of the generator to input specific variables to fit their needs, it gives you the flexibility of creating best-practices code on the fly, while still being unique to a specific use-case.

One Yeoman generator in particular that's proven particularly useful is Drupal Entities, which allows for rapid creation of Entities, i.e. the underlying class for Nodes, Content Types, and so on. It also proved to be an excellent example of how to make a Drupal-specific version of a generator—and was good inspiration to locate other common custom Drupal development tasks that could have their complexity mitigated. One common use case I've run into is creating custom Field and Views Formatters, in particular integrating a jQuery plugin to the output of a Views list or multivalued-field, while still preserving the formatter settings. Thus began my hacking.

We are already big fans of the Owl Carousel Module here at Echo, which is a fantastic integration of the Owl Carousel jQuery plugin with Drupal, and is utilized on a number of our sites. It not only provides Field and Views formatters, but also unlimited settings groups (controlling, e.g., speed, width and number of items in each carousel), which are dynamically assigned to variables in the DB, and then can be loaded individually in any number of instances on the front-end of the site (if you had more than one carousel on a page, for instance). To me, this presented the perfect architecture to make a generic version to use as a template for integrating other JavaScript plugins.

Essentially, the structure of the code that one makes generic to work with Yeoman mirrors the directory of the actual application/module, so in this case our file structure is incredibly familiar. Aside from our .json configuration files, you'll see our app directory (where the templates live) is loaded with some familiar Drupal file extensions: .module, .info, .install, etc.

We also have theme, submodule modules and includes directories which house more of these underscore-prefaced templates, which are essentially PHP files that Yeoman treats as plain text files. After the user is prompted for a number of values, (in this case, the name of the module, the name of the plugin being integrated, and some meta-information about the settings--i.e., whether it is a boolean, integer, or string), Yeoman traverses the templates, finding and replacing any reference to those variables, which are delimited by templating tags. Here's an example hook in one of these files with several variables that will be replaced by the user supplied values on the command line:

<?php   /** * Implements hook_library(). */ function <%= moduleName %>_library() { $library = libraries_get_path('<%= libraryName %>');   $libraries['<%= pluginName %>'] = array( 'title' => '<%= pluginProper %>', 'website' => '<%= pluginSite %>', 'version' => array(), 'js' => array( $library . '<%= relativeScriptpath %>' => array( 'scope' => 'footer', ), ), 'css' => array( $library . '<%= relativeStylepath %>' => array( 'type' => 'file', 'media' => 'screen', ), ), );   return $libraries; }

So after paring the module down to its core and assuring every value was being dynamically populated, I tested out whether it all came together by generating a Module that integrates a JS plugin called oriDOMi. The result was that I only needed to perform maybe a half an hour of debugging—simply fixing the initialization method in the JavaScript so that it was calling on the correct nested JSON object settings group. Of course, many hours were spent getting the generator ready, but essentially this lays the groundwork to let developers focus on enhancing the front-end integrations they're doing, as opposed to worrying about how a client or even another developer will manage the inevitable need to change something as trivial as how fast something should animate. The resulting module is available online, if you'd like to see what the output looks like here.

Here's is a bonus pic of the result of that particular test generation:

Placeholder text generated from Gluten Ipsum.

The entire source of the generator itself is available at GitHub, where you can peruse the code. You'll find installation and usage instructions as well, and as always, if you've found something that could be improved, please fork and make a pull request! Additionally, an in depth guide to making your own generators for Drupal may be on the way—but until then, the documentation for Yeoman is a wonderful starting point.

Tags: codeyeomandrupalgeneratornode.jsphpmvcconsolecliyonpmmodule
Categories: Elsewhere

Tag1 Consulting: How to Maintain Contrib Modules for Drupal and Backdrop at the Same Time

Tue, 03/02/2015 - 16:26
Part 1 - Reuse the Same Code

In mid-January, the first version of Backdrop CMS was released. Backdrop is a fork of Drupal that adds some highly-anticipated features and API improvements to the core Drupal platform while focusing on performance, usability, and developer experience.

read more

Categories: Elsewhere

Károly Négyesi: The brutal truth about security

Tue, 03/02/2015 - 03:00

I have cared a lot, even too much about designing secure APIs for Drupal. To create a software which made it easy to write secure custom code and hard to write insecure. I placed this in front of other concerns including developer and user experience. Sounds nice, isn't it? But in truth, I was trying to tend a garden in the nuclear winter. By and large the Internet is so insecure that making it slightly easier to write more secure code is a trifling concern. It is enough that Drupal is not a house of cards of security wise and indeed it is not. Let other concerns win over security in API design. I was wrong. And I am out.

Categories: Elsewhere

CivicActions: Backdrop CMS: A Drupal 8 Alternative

Tue, 03/02/2015 - 01:30

There's a lot of excitement about Drupal 8 and it's imminent release. There's also a lot of angst. Yes, Drupal 8 is super slick and full of frameworky, object oriented coolness. The thing is, a lot of people have invested a lot of time learning how to do things in Drupal 7, and the idea of learning how to do things in Drupal 8 can be pretty daunting. This is where Backdrop aims to step in and serve developers and end-users who want to continue doing things mostly the Drupal 7 way, but not fall behind the new technology (or product support) curve.

So what motivated this fork in early D8 development?

Drupal 7 took some time to take hold - there were several reasons for this:

1) D7 is different enough from D6 that it took a considerable investment of time and money to learn (it was more enterprise focused).

2) D7 is often times more abstracted than D6. E.g.: The Commerce suite of modules is extremely powerful, and is considered by most Drupal developers to be the defacto solution for ecommerce, but it is more of a construction kit than a fully asembled product. Whereas, in D6, Ubercart is the way to go for ecommerce, which is pretty close to being fully functional right out of the box. The Commerce vs. Ubercart example serves to highlight the differences in approach between the two.

3) Somewhere along the way from D6 to D7, Drupal stopped being a community filled with people of all skill sets, and more of an elite dev community. This is great, but leads to some interesting challenges. First, it causes a talent shortage - some smaller outfits only require an entry level to mid level Drupal dev (we have all heard about the shortage of Developers available for hire - it's more accurate to say there is a shortage of non-elite level employees for hire). Second, a talent pool comprised of only elite level devs means that the limited talent available to do Drupal work will command a higher price point. This makes Drupal more expensive to implement, and often precludes businesses that would otherwise consider it as a web solution.

Backdrop has a well defined philosophy.

The first and most defining tenet of which is to serve small businesses, non-profits, schools or just any organization that doesn't have a big budget. By continuing to use most of the now familiar D7 api, Backdrop lets devs work with and extend what they already know, thereby lessening the talent pool strain which in turn leads to more affordable web development solutions.

A second tenet of the Backdrop philosophy is that it should be easy to use. Site builders who don't have coding experience should be able to use it without a lot of ramp up time.

A third tenet of the Backdrop philosophy is that contrib developers should be valued over core developers. The idea here being that the more hands there are in core (and focus on core development), the more potential for wonkyness awaits module developers who will be trying to hook into an api in constant flux.

A fourth tenet is that backdrop should be low resource. Speaking from a package size perspective, the most recent version of D8 beta has a 17.2 MB package, whereas Backdrop is 3.9MB.

Lastly, and perhaps the most notable tenet of the Backdrop philosophy, is that they are committed to releases being well planned, small, and on time. These have all proven to be a struggle for D8.

So, how is it different from D7?

Side by side, Backdrop and D7 look a lot alike: both come with the default Bartik and Seven themes, and the same default content types. Looking a little more closely, there are enhancements to Backdrop that help get things moving a little more quickly.

1) A dropdown admin menu with sensible options comes baked in.

2) The annoying admin overlay is gone.

3) All themes are fully responsive.

4) Backdrop comes stock with "Layouts", which I would kind of liken to a scaled down, much lighter weight version of panels, with a much more intuitive, simplified ui, but is still very powerful.

5) Blocks are a lot smarter. They have selection rules that when combined with Layouts, enhance the Panels like experience, but with a learning curve soft enough to make a novice developer productive quickly.

6) Configuration Managment! Sick and tired of confusing features conflicts? Yeah, me too. Configuration management is a breeze to use, and makes migrating database / config settings from server instances fast and easy.

How is Backdrop extended? Just like in D7 = with modules.

There are already a few that have been ported over from D7, but creating a new Backdrop module is almost the same as a creating one in D7 (it's pretty much just a difference in namespacing), and all of the coding conventions and hooks appear to be the same. For example, Backdrop doesn't come with any kind of wysiwyg functionality, and I wanted one with a local install I created, so I went to, downloaded the Ckeditor module and the corresponding js library, installed it, and made one change to the .info file, where core was defined as 7.x: I removed this line and replaced with "backdrop = 1.x." After doing this, Ckeditor was available, and I was able to use it. This is possible because Backdrop has a convenient conversion layer in place, that replaces the Drupal namespace in modules to the Backdrop namespace.

Another cool thing about the Backdrop project is that it lives on Github, which differs from Drupal, that hosts it's own repo. This is fine, but I think in the spirit of being extra open-sourcey, and encouraging developers from all disciplines to collaborate and discover this project, hosting it on github seems like a great idea. So, you can find the project, here:

If you want to read the project api docs, they can be found here:

Or, if you want to have a look at the project website, that can be found here:

And if you wanna get an instance setup quickly without downloading anything, you can fire up an instance on Pantheon, here: - you'll need to setup a Pantheon acct, but it's free and easy to create.

Happy site building!

Categories: Elsewhere

Mediacurrent: Dynamic Data in Quick Tabs

Mon, 02/02/2015 - 22:18

Quick Tabs is a great module, but if your tabs are named Today, Tomorrow, and the name of the day of the week for the next day, it is not obvious how to make the third tab say “Saturday”, “Sunday”, or anything else that changes.

After a quick search for a preprocess function for Quick Tabs didn’t result in a perfectly outlined tutorial, I decided that I would need to dig just a bit.  

Categories: Elsewhere

more onion - devblog: D7: How not to use hook_entity_*

Mon, 02/02/2015 - 22:02

Recently I came in a situation where I wanted to extend all entities of a specific type (payment) to reliably have a provide (and store) an additional property. At first glance this seems like a no brainer: simply use hook_entity_* to save/update/load the property to or from the database and that should do it. Turns out it isn't … and there is a lot to learn about how entities work in D7.

Lets take a look at a specific example.

Categories: Elsewhere

Matt Grasmick: Remove language from all Drupal aliases

Mon, 02/02/2015 - 21:27

Drupal's locale module includes a lot of great features for supporting multilingual sites. One such feature is the ability to associate a language with a path alias. This allows you to have one node with two versions (let's say an English version and a Spanish version)--each with its own alias.

But your use case may not require language-specific paths per node. Maybe you want to call a spade a spade-- you've got a Spanish node or and English node and that's it. No fancy multiple versions.

Well then you've got a bit of a problem--a few actually. This can wreak havoc with aliases, and pathauto in particular. The solution is the Local Path Ignore module. It ignores the language of a given path, and instead forces all paths to have a language of "undefined," effectively allowing path aliases to behave the way you'd expect--one path per node.

7.x, drupal, locale, i18n, language, pathauto, alias, path
Categories: Elsewhere

Annertech: The 5 best modules to eliminate spam on a Drupal website

Mon, 02/02/2015 - 20:31
The 5 best modules to eliminate spam on a Drupal website


Categories: Elsewhere

Károly Négyesi: This is the future of Drupal

Mon, 02/02/2015 - 18:36

I got these gems from a person at Acquia. I followed up with someone supposedly higher up in the chain but never got an answer. Needless to say I was just an expert helping [redacted] and not someone who makes the decisions for them:


Our colleagues have previously spoken regarding [redacted] web properties. I’m reaching out to introduce myself and see if it would make sense to discuss your web plans for 2015.

Acquia is a Gartner leading web content management provider. Our platform taps into the cost-effective and flexible benefits of open source while providing world-class support for our clients’ websites.

Second email:

Acquia was founded by the creator of the Drupal project and our organization works along side Drupal users to propel their digital properties.

Mind you, this is two years after someone from Acquia pitched Drupal to Matt Mullenweg. I hoped selling open source that some people poured their heart into differs from selling a sack of potatoes. That the salesmen would at least get some rudimentary training on the community their livelihood depends on. That they won't talk like a Dilbert cartoon. I am wrong. And I am out.

Categories: Elsewhere

Code Karate: Site5 Hosting: A shared hosting solution for designers and developers

Mon, 02/02/2015 - 18:01

Code Karate has recently posted numerous times on the importance of hosting and finding a reliabl

Categories: Elsewhere

SitePoint PHP Drupal: Effective PDF Generation in Drupal

Mon, 02/02/2015 - 18:00

A few months ago I had a client requirement for PDF generation, in this case to generate certificates that could be viewed online or printed. I spent some time looking into the best Drupal options available and picked up some advice along the way on how best to accomplish these aims. After mentioning my results to several people, it seemed that PDF generation was a common requirement and now I have the same need again on a personal project, so it seemed a good case study to walk you through what I found.

Why not just print?

If your requirements are simple, it may be easier to just to tell your website users to print and there’s nothing stopping them doing this. If we want a level of control over what is printed or we want to distribute files for printing, then we need to look into other options.

Web vs Print

PDF generation takes a slight change of mindset. As web developers, we have spent a lot of time convincing designers from a print background to stop producing pixel perfect designs that will be difficult to reproduce on the web. If you want to introduce PDF generation or any form of high designed print output, then we need to relearn some of our old skills we left behind. The nature of print means that it is precise and often needs pixel (or millimeter) perfect design.

What am I trying to accomplish?

I am currently working on a board game and I want to allow players to be able to create their own cards that can be shared on the website and printed for use in the game. We have a specific size and layout that these cards will always be and need to conform to, here’s the initial design that we will partially recreate:

PDF options in Drupal

There are two options in Drupal for creating PDFs. The Print module and Views PDF. Views PDF initially seemed the better option as it would allow us to leverage the power of views and the myriad options it offers. However, it has the PHP module as a dependency and as far as I know, is reliant on the eval() function. PDF generation has the potential to be a server intensive task and this method seemed inefficient to me, aside from my reluctance to ever have any kind of PHP evaluation module enabled in Drupal.

This caused me to settle on the print module, which is also better supported and offers many other options for output that may prove useful.

Next we need to decide on our PDF generation library, I am going to suggest you use wkhtmltopdf and explain why later, as I want to build something to compare first. Do this by visiting the wkhtmltopdf website and follow the instructions for your setup. Remember it will need to be installed on local and production sites. After installing you need to create an alias to the wkhtmltopdf executable into your Drupal libraries folder, i.e.:

ln -s /usr/bin/wkhtmltopdf /var/www/sites/all/libraries/wkhtmltopdf

Continue reading %Effective PDF Generation in Drupal%

Categories: Elsewhere

Drupal core announcements: No Drupal 6 or Drupal 7 core release on Wednesday, February 4

Mon, 02/02/2015 - 16:14

The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, there haven't been enough changes to the development version since the last bug fix release three months ago to warrant a new release. A Drupal 7 bug fix release during the March release window is likely instead.

Upcoming release windows include:

  • Wednesday, February 18 (security release window)
  • Wednesday, March 4 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Elsewhere

Drupal Association News: Infographic: Who Attends DrupalCon?

Mon, 02/02/2015 - 16:06

Did you know that DrupalCon isn’t just for developers? The community survey we conducted at the end of 2014 turned up some interesting facts, including the fascinating statistic that only about half of DrupalCon attendees self-identify as developers? With project managers, C-level executives, and Drupal sales and marketing experts in attendance, DrupalCon is a great place to meet a wide array of passionate Drupal users and advocates.

So, who goes to DrupalCon? Check out the infographic below for a more complete picture of who attends the biggest Drupal conference on earth.


Categories: Elsewhere

Web Omelette: 6 steps for new Drupal 8 developers

Mon, 02/02/2015 - 09:00

So you are taking the plunge into learning Drupal 8 for the purpose of developing sites, modules, themes, etc. You're a great Drupal 7 developer, familiar with many drupalisms but you don't have tons of experience for modern PHP frameworks, principles and practices. Well, Drupal 8 still includes many of the old drupalisms but still attempts to keep in line with times and modernise itself.

In this article I want to outline 6 steps I believe you should take to get started learning how to develop custom modules and/or themes in Drupal 8. On top of these 6 builds everything else.

The first three are PHP related in a more general fashion, while the last three target aspects of Drupal 8 itself.

1. Learn Object Oriented Programming

One of the biggest difference between Drupal 7 and 8 for developers is the way code is written. It's still PHP but it's now much more object oriented. Global procedural functions are still in place but most of the logic happens in classes.

In case you don't have much experience with Object Oriented Programming in PHP, this is the first thing you need to learn, brush upon or revise (depending on your level). There are many resources available out there, all scattered as hyperlinks in this section. There are also courses you can take, both free and paid.

Without quite a solid OOP foundation, you won't be able to understand much of how Drupal 8 modules are built.

2. Learn how to use Composer

One of the consequences of modernizing PHP has been the introduction of the Composer package manager. Projects are no longer built without it as it does a great job of installing, updating and managing in general the external libraries and dependencies of your project. Not to mention its very helpful autoloader.

Drupal 8 uses Composer to manage external PHP libraries and dependencies (such as Symfony components, Guzzle, etc) and there is talk about the ability to handle also contrib modules. So make sure you know how Composer works and even start using it in non-Drupal projects.

3. Get familiar with Symfony

One of the main points of contention (back then) in the Drupal 8 development cycle was the introduction of Symfony components. Some people didn't really agree with this great shift from they Drupal way, but others embraced it wholeheartedly. I am in the latter group as I love Symfony and used it even before developing anything in Drupal 8.

Drupal 7 developers are often being told that knowing Symfony is not required in order to develop in Drupal 8. While technically true, you still end up learning a lot of it through the Drupal experience. That being said, I strongly recommend learning some Symfony before. It is a great modular framework and knowing its concepts will really help you out in understanding how Drupal 8 is built (for the components it uses I mean). Once you can build a small website in Symfony, you'll enjoy developing in Drupal 8 that much more because concepts will be similar a lot of the time. Not too mention that you can use Symfony to build apps on its own.

4. Routing and controllers

Just like with Drupal 7, when starting to learn Drupal 8 you need to create the obligatory hello world module (creating a page with a parameter in the URL( usually world) that displays the text Hello + parameter). This example introduces you to many important things:

  • Module folder structure
  • Routing (no more hook_menu) through routing.yml files that map to Controller methods
  • Controller classes which have various methods that can be mapped to routes
  • Access arguments for these routes
  • Rendering markup to the page inside the Controller methods
  • etc

So I really recommend giving this a go.

5. Plugins

Another important concept you'll need to get familiar with is Plugins. Admittedly, this not the easiest to grasp, but it is super important because it's everywhere. Not to worry though, it's not rocket science.

Many old Drupal 7 implementations of various concepts have been transformed to plugins: info hooks, blocks, field formatters, views handlers, etc. Understanding plugins is therefore also very important for being able to extend default Drupal functionality.

6. Dependency injection and the service container

The last step I am going to mention here is dependency injection. Drupal 8 uses the Symfony dependency injection container to manage service instantiation and injection into classes that need them. This helps decouple functionality and increases testability.

However, many people are scared of this concept, mainly because they don't grasp it. I wasn't super comfortable either before understanding it. But you should definitely learn what it means, why we use it and how we use it. Because it is a very simple concept that is used all the time in procedural code as well.

You can already find many tutorials out there on Drupal 8 that load services statically through the \Drupal class. It is much faster to write so people (me included) prefer it when writing about D8. I usually also tend to make a note that using dependency injection is preferred in theses cases.

Not understanding what the service container and dependency injection is will easily let you fall into the habit of just statically requesting services and coupling your code like it was procedural. Once you are clear on this point, this will hopefully not happen any more and the sight of a \Drupal::get('some_service') will make you think twice.


There you have it. What I think are the first 6 steps you should take when learning Drupal 8 for the first time. Of course there are many other important things to learn and do but I believe they build on top of this foundation. Of course, this is me writing so others may have different opinions (very much welcomed in the comments). So let's discuss.

var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Categories: Elsewhere Logs, The Easy Way

Sun, 01/02/2015 - 23:00

Your team invested countless hours in development.

Your QA people can barely keep their eyes open - they have worked so hard. Your lead developer who's responsible for the deployment is almost dehydrated from so much pressure and sweat.

But it's all worth it. Your app is live. Now everybody goes to sleep, and your pampered app, is all alone, serving your data to the entire world.

You forgot one thing - to give it a phone to call home, and tell you something went wrong.

Continue reading…

Categories: Elsewhere

DrupalOnWindows: Distinct options in a views exposed filter: The Views Selective Filters Module

Sun, 01/02/2015 - 07:00

You have built an application where there was a taxonomy or options field with more values defined in them than what was really being used after release. And these fields are being used as exposed filters in a View. This basically means that you end up with an option in an exposed filter that yields no results when selected. Not a good UI behaviour, and confusing for the end user.

Language English
Categories: Elsewhere