Calling all Systems Engineers and DevOps leads!

Posted by DrupalCon News on February 3, 2015 at 8:33pm

A developer has just uploaded code that "worked on their machine" to your web site and it brought your company to a screeching halt. What do you do?

If you have answers that help solve this question, then we want YOU at DrupalCon Los Angeles!

This Month in Drupal Documentation - January 2014

Posted by Drupal core announcements on February 3, 2015 at 7:02pm

Here's an update from the Documentation
Working Group (DocWG)
on what has been happening in Drupal
Documentation in the last month or so. Sorry... because this is posted
in the Core group as well as Documentation, comments are disabled.

If you have comments or suggestions, please see the DocWG home
page
for how to contact us. Thanks!

Notable Documentation Updates

  • Work is still ongoing on writing the so-called hook-help texts for
    the Drupal 8 core modules - that are the help texts that are displayed
    by the help module within your site. To help with this, see
    https://www.drupal.org/node/1908570 and find a child issue in the
    sidebar that is still open.
  • Most of this help texts need to be reviewed again, because this
    task started nearly two years ago and in the meantime UI changes have
    been made. An easy way of reviewing these without installing Drupal 8
    locally is to use http://simplytest.me/ to roll out the latest Drupal 8
    dev version. For more detailed information, see
    https://www.drupal.org/node/2283477.

The API reference site, https://api.drupal.org, has recently been updated:

  • The theme is now responsive.
  • Reference links for constants have been added, linking to functions that use the constant: see constant KernelEvents::REQUEST
  • There's a new Events topic for Drupal 8 that already has links to the Symfony event constants in it; more will be coming: see Events
  • Topic pages can now have sub-topics: see Views plugins

See the DocWG page for how to contact us, if you'd like to be listed here in our
next post!

Thanks for contributing!

Since 1 January, 213 contributors have made 601 total page revisions,
including 5 people who made more then 20 edits: lolandese, sidharrell,
satraa,jhodgdon and webchick.

On the weekend 17/18 January, a global sprint weekend took place in
during which we also worked on documentation, working on the hook_help
texts and the install.txt for Drupal 8.

Thank you to everybody who took part!

In addition, there were many many commits to Drupal Core and
contributed projects that improved documentation -- these are hard to
count, because many commits combine code and documentation -- but they
are greatly appreciated too!

Documentation Priorities

The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.

The two meta issues to update and review of help texts
currently have a high priority: Not only do we need them for a good user
experience of Drupal 8, they also need to be translated once they are
ready.
Working on them is also a good way to find out already how
Drupal 8 will work for site builders and site administrators.

If you're new to contributing to documentation, these projects may
seem a bit overwhelming -- so why not try out a New contributor
task
to get started?

Upcoming Events

Report from the Working Group

Since there is a re-curring demand for curated documentation, the
Working Group is discussing different option of how best to create and
implement them.
In January, we also had a meeting with staff of the Drupal Association,
to discuss the state of the of improvements on drupal.org to make
documentation and related tasks more user-friendly.

What Google Code-In and Drupal meant to me

Posted by Conocimiento Plus on February 3, 2015 at 5:24pm
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 […]

Understanding JavaScript behaviors in Drupal

Posted by Lullabot on February 3, 2015 at 5:00pm

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.

Time to start translating Drupal 8!

Posted by Localize.drupal.org on February 3, 2015 at 4:33pm

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 https://localize.drupal.org/translate/drupal8 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. Localize.drupal.org 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

Responsive Images in Drupal: Part 1

Posted by Aten Design Group on February 3, 2015 at 4:17pm

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.

Image style list

Image style effects

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.

Breakpoints module configuration

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.

Breakpoints module group configuration

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.

Picture module image style mapping

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.

Picture module field configuration

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.

Rapid Drupal Scaffolding with Yeoman

Posted by EchoDitto Tech Blog on February 3, 2015 at 4:06pm

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.

The app structure mirrors the way the Drupal module should output.

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:

The OriDomi Drupal formatter in action. 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

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

Posted by Tag1 Consulting on February 3, 2015 at 3:26pm
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

Backdrop CMS: A Drupal 8 Alternative

Posted by CivicActions on February 3, 2015 at 12:30am

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.

The backdrop vertical logoBackdrop 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 Drupal.org, 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: https://github.com/backdrop/backdrop.

If you want to read the project api docs, they can be found here: https://api.backdropcms.org/

Or, if you want to have a look at the project website, that can be found here: https://backdropcms.org/.

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

Happy site building!

Topics

Dynamic Data in Quick Tabs

Posted by Mediacurrent on February 2, 2015 at 9:18pm

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.  

D7: How not to use hook_entity_*

Posted by more onion - devblog on February 2, 2015 at 9:02pm

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.

Tags:

Remove language from all Drupal aliases

Posted by Matt Grasmick on February 2, 2015 at 8:27pm

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

The 5 best modules to eliminate spam on a Drupal website

Posted by Annertech on February 2, 2015 at 7:31pm
The 5 best modules to eliminate spam on a Drupal website

//-->

Drupal 8 allows configuration of domains your site will respond on

Posted by J-P Stacey on February 2, 2015 at 5:46pm

As of slightly over a week ago, Drupal 8 permits you to hardwire in settings.php not just the old $base_url default, but a list of regular expressions which, if the incoming request domain doesn't match any of them, cause the server to respond to the browser with HTTP 500: effectively what looks to the world like a server error. This is in addition to the options of configuring your webserver layer to do the same.

Read more of "Drupal 8 allows configuration of domains your site will respond on"

Site5 Hosting: A shared hosting solution for designers and developers

Posted by Code Karate on February 2, 2015 at 5:01pm

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

Effective PDF Generation in Drupal

Posted by SitePoint PHP Drupal on February 2, 2015 at 5:00pm

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%

New Wave PHP with Lorna Jane Mitchell

Posted by Acquia on February 2, 2015 at 4:34pm
Language Undefined

Lorna Jane Mitchell is back to show us some great reasons for upgrading your projects to PHP 5.3 or newer. Drupal 8's minimum version requirement is already up there at 5.4.5 (as of 2015.Feb.02), so we're doing well! Lorna and I have a quick chat about her history and experience, open source versus proprietary software development ("Projects and companies that work in that open source technology space make much better use of tools ... and they are wonderful, free, and well-supported tools!") ... specifics of how and why the PHP "Renaissance" is happening, and Drupal 8 as a PHP meta-project before she gets down to her jam's Drupal Camp presentation.

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

Posted by Drupal core announcements on February 2, 2015 at 3:14pm

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.

Infographic: Who Attends DrupalCon?

Posted by Drupal Association News on February 2, 2015 at 3:06pm

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.

 

6 steps for new Drupal 8 developers

Posted by Web Omelette on February 2, 2015 at 8:00am

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.

Conclusion

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"});

Pages

Subscribe with RSS Subscribe to Drupal.org aggregator - Planet Drupal