Skip to Content


Lullabot: What Happened to Hook_Menu in Drupal 8?

Planet Drupal - 24 September 2015 - 6:46am

In Drupal 7 and earlier versions hook_menu has been the Swiss Army knife of hooks. It does a little bit of everything: page paths, menu callbacks, tabs and local tasks, contextual links, access control, arguments and parameters, form callbacks, and on top of all that it even sets up menu items! In my book it’s probably the most-used hook of all. I don’t know if I’ve ever written a module that didn’t implement hook_menu.

But things have changed In Drupal 8. Hook_menu is gone and now all these tasks are managed separately using a system of YAML files that provide metadata about each item and corresponding PHP classes that provide the underlying logic.

The new system makes lots of sense, but figuring out how to make the switch can be confusing. To make things worse, the API has changed a few times over the long cycle of Drupal 8 development, so there is documentation out in the wild that is now incorrect. This article explains how things work now, and it shouldn't change any more.

I’m going to list some of the situations I ran into while porting a custom module to Drupal 8 and show before and after code examples of what happened to my old hook_menu items.

Custom Pages

One of the simplest uses of hook_menu is to set up a custom page at a given path. You'd use this for a classic "Hello World" module. In Drupal 8, paths are managed using a MODULE.routing.yml file to describe each path (or ‘route’) and a corresponding controller class that extends a base controller, which contains the logic of what happens on that path. Each controller class lives in its own file, where the file is named to match the class name. This controller logic might have lived in a separate file in Drupal 7.

In Drupal 7 the code might look like this:

function example_menu() { $items = array(); $items[‘main’] = array( 'title' => 'Main Page', 'page callback' => example_main_page', 'access arguments' => array('access content'), 'type' => MENU_NORMAL_ITEM, 'file' => '' ); return $items; } function example_main_page() { return t(‘Something goes here’); }

In Drupal 8 we put the route information into a file called MODULE.routing.yml. Routes have names that don’t necessary have anything to do with their paths. They are just unique identifiers. They should be prefixed with your module name to avoid name clashes. You may see documentation that talks about using _content or _form instead of _controller in this YAML file, but that was later changed. You should now always use _controller to identify the related controller.

example.main_page_controller: path: '/main’ defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage’ _title: ‘Main Page’ requirements: _permission: 'access content'

Note that we now use a preceding slash on paths! In Drupal 7 the path would have been main, and in Drupal 8 it is /main! I keep forgetting that and it is a common source of problems as I make the transition. It’s the first thing to check if your new code isn’t working!

The page callback goes into a controller class. In this example the controller class is named MainPageController.php, and is located at MODULE/src/Controller/MainPageController.php. The file name should match the class name of the controller, and all your module’s controllers should be in that /src/Controller directory. That location is dictated by the PSR-4 standard that Drupal has adopted. Basically, anything that is located in the expected place in the ‘/src’ directory will be autoloaded when needed without using module_load_include() or listing file locations in the .info file, as we had to do in Drupal 7.

The method used inside the controller to manage this route can have any name, mainPage is an arbitrary choice for the method in this example. The method used in the controller file should match the YAML file, where it is described as CLASS_NAME::METHOD. Note that the Contains line in the class @file documentation matches the _controller entry in the YAML file above.

A controller can manage one or more routes, as long as each has a method for its callback and its own entry in the YAML file. For instance, the core nodeController manages four of the routes listed in node.routing.yml.

The controller should always return a render array, not text or HTML, another change from Drupal 7.

Translation is available within the controller as $this->t() instead of t(). This works because ControllerBase has added the StringTranslationTrait. There's a good article about how PHP Traits like translation work in Drupal 8 on Drupalize.Me.

/** * @file * Contains \Drupal\example\Controller\MainPageController. */ namespace Drupal\example\Controller; use Drupal\Core\Controller\ControllerBase; class MainPageController extends ControllerBase { public function mainPage() { return [ '#markup => $this->t('Something goes here!'), ]; } Paths With Arguments

Some paths need additional arguments or parameters. If my page had a couple extra parameters it would look like this in Drupal 7:

function example_menu() { $items = array(); $items[‘main/first/second’] = array( 'title' => 'Main Page', 'page callback' => example_main_page', ‘page arguments’ => array(1, 2), 'access arguments' => array('access content'), 'type' => MENU_NORMAL_ITEM, ); return $items; } function example_main_page($first, $second) { return t(‘Something goes here’); }

In Drupal 8 the YAML file would be adjusted to look like this (adding the parameters to the path):

example.main_page_controller: path: '/main/{first}/{second}’ defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage’ _title: ‘Main Page’ requirements: _permission: 'access content'

The controller then looks like this (showing the parameters in the function signature)::

/** * @file * Contains \Drupal\example\Controller\MainPageController. */ namespace Drupal\example\Controller; use Drupal\Core\Controller\ControllerBase; class MainPageController extends ControllerBase { public function mainPage($first, $second) { // Do something with $first and $second. return [ '#markup => $this->t('Something goes here!'), ]; } }

Obviously anything in the path could be altered by a user so you’ll want to test for valid values and otherwise ensure that these values are safe to use. I can’t tell if the system does any sanitization of these values or if this is a straight pass-through of whatever is in the url, so I’d probably assume that I need to type hint and sanitize these values as necessary for my code to work.

Paths With Optional Arguments

The above code will work correctly only for that specific path, with both parameters. Neither the path /main, nor /main/first will work, only /main/first/second. If you want the parameters to be optional, so /main, /main/first, and /main/first/second are all valid paths, you need to make some changes to the YAML file.

By adding the arguments to the defaults section you are telling the controller to treat the base path as the main route and the two additional parameters as path alternatives. You are also setting the default value for the parameters. The empty value says they are optional, or you could give them a fixed default value to be used if they are not present in the url.

example.main_page_controller: path: '/main/{first}/{second}’ defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage’ _title: ‘Main Page’ first: '' second: '' requirements: _permission: 'access content' Restricting Parameters

Once you set up parameters you probably should also provide information about what values will be allowed for them. You can do this by adding some more information to the YAML file. The example below indicates that $first can only contain the values ‘Y’ or ‘N’, and $second must be a number. Any parameters that don’t match these rules will return a 404. Basically the code is expecting to evaluate a regular expression to determine if the path is valid.

See Symfony documentation for lots more information about configuring routes and route requirements.

example.main_page_controller: path: '/main/{first}/{second}’ defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage’ _title: ‘Main Page’ first: '' second: '' requirements: _permission: 'access content' first: Y|N second: \d+ Entity Parameters

As in Drupal 7, when creating a route that has an entity id you can set it up so the system will automatically pass the entity object to the callback instead of just the id. This is called ‘upcasting’. In Drupal 7 we did this by using %node instead of %. In Drupal 8 you just need to use the name of the entity type as the parameter name, for instance {node} or {user}.

example.main_page_controller: path: '/node/{node}’ defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage’ _title: ‘Node Page’ requirements: _permission: 'access content'

This obviously means you should be careful how you name your custom parameters to avoid accidentally getting an object when you didn’t expect it. Treat entity type names as reserved words that should not be used for other parameters. Or maybe even add a prefix to custom parameters to ensure they won’t collide with current or future entity types or other automatic mapping.

JSON Callbacks

All the above code will create HTML at the specified path. Your render array will be converted to HTML automatically by the system. But what if you wanted that path to display JSON instead? I had trouble finding any documentation about how to do that. There is some old documentation that indicates you need to add _format: json to the YAML file in the requirements section, but that is not required unless you want to provide alternate formats at the same path.

Create the array of values you want to return and then return it as a JsonResponse object. Be sure to add ”use Symfony\Component\HttpFoundation\JsonResponse” at the top of your class so it will be available.

/** * @file * Contains \Drupal\example\Controller\MainPageController. */ namespace Drupal\example\Controller; use Drupal\Core\Controller\ControllerBase; use Symfony\Component\HttpFoundation\JsonResponse; class MainPageController extends ControllerBase { public function mainPage() { $return = array(); // Create key/value array. return new JsonResponse($return); } } Access Control

Hook_menu() also manages access control. Access control is now handled by the MODULE.routing.yml file. There are various ways to control access:

Allow access by anyone to this path:

example.main_page_controller: path: '/main’ requirements: _access: ‘TRUE’

Limit access to users with ‘access content’ permission:

example.main_page_controller: path: '/main’ requirements: _permission: 'access content'

Limit access to users with the ‘admin’ role:

example.main_page_controller: path: '/main’ requirements: _role: 'admin'

Limit access to users who have ‘edit’ permission on an entity (when the entity is provided in the path):

example.main_page_controller: path: '/node/{node}’ requirements: _entity_access: ‘node.edit’

See documentation for more details about setting up access control in your MODULE.routing.yml file.


So what if a route already exists (created by core or some other module) and you want to alter something about it? In Drupal 7 that is done with hook_menu_alter, but that hook is also removed in Drupal 8. It’s a little more complicated now. The simplest example in core I could find was in the Node module, which is altering a route created by the System module.

A class file at MODULE/src/Routing/CLASSNAME.php extends RouteSubscriberBase and looks like the following. It finds the route it wants to alter using the alterRoutes() method and changes it as necessary. You can see that the values that are being altered map to lines in the original MODULE.routing.yml file for this entry.

/** * @file * Contains \Drupal\node\Routing\RouteSubscriber. */ namespace Drupal\node\Routing; use Drupal\Core\Routing\RouteSubscriberBase; use Symfony\Component\Routing\RouteCollection; /** * Listens to the dynamic route events. */ class RouteSubscriber extends RouteSubscriberBase { /** * {@inheritdoc} */ protected function alterRoutes(RouteCollection $collection) { // As nodes are the primary type of content, the node listing should be // easily available. In order to do that, override admin/content to show // a node listing instead of the path's child links. $route = $collection->get('system.admin_content'); if ($route) { $route->setDefaults(array( '_title' => 'Content', '_entity_list' => 'node', )); $route->setRequirements(array( '_permission' => 'access content overview', )); } } }

To wire up the menu_alter there is also a file with an entry that points to the class that does the work:

services: node.route_subscriber: class: Drupal\node\Routing\RouteSubscriber tags: - { name: event_subscriber }

Many core modules put their RouteSubscriber class in a different location: MODULE/src/EventSubscriber/CLASSNAME.php instead of MODULE/src/Routing/CLASSNAME.php. I haven’t been able to figure out why you would use one location over the other.

Altering routes and creating dynamic routes are complicated topics that are really beyond the scope of this article. There are more complex examples in the Field UI and Views modules in core.

And More!

And these are still only some of the things that are done in hook_menu in Drupal 7 that need to be transformed to Drupal 8. Hook_menu is also used for creating menu items, local tasks (tabs), contextual links, and form callbacks. I’ll dive into the Drupal 8 versions of some of those in a later article.

Categories: Drupal

InternetDevels: Drupal 8 development: useful tips

Planet Drupal - 24 September 2015 - 6:34am

Hello, everyone! The release of Drupal 8 is almost here, but its beta version is already vailable for use. So let's explore Drupal 8 together.

Read more
Categories: Drupal

Matt Glaman: Fixing rotated images uploaded to Drupal from an iPhone

Planet Drupal - 24 September 2015 - 6:16am

iPhones 4 and up store images in landscape mode and use EXIF data to provide proper rotation when viewed. This is a bit quirky as not all desktop browsers provide fixes, or they may not be streamlined. I remember my old project manager telling me their images were showing up "flipped to the side" during mobile QA testing. Sure enough when the image was embedded in HTML it was cocked to the side - however when viewed directly in the browser or desktop it was fine. What? Luckily through some Google-fu I stumbled upon this great blog post detailing how "" True words.

I am guessing you landed here from a Google search and want to solve this problem. You are in luck - check out the project. Originally it spawned , but Dave Reid suggested its better as a standalone module so all files can be fixed - not just sites using File Entity. Typically Drupal takes a "manipulate on render" approach. This module does not. The image will be manipulated on upload to the proper rotation. Here is the reason: what if you want to display the original file and not a derivative? That is going to be embedded in an image tag and probably not render right. Secondly one would have to make sure every single image style added this filter. There is enough button clicking when setting up a Drupal site.

If you wold like to give it a test, checkout out these example files repository from the aforementioned blog:

I also would like to note that ImageCache Actions provides this functionality, but as a submodule and as an image filter. I wish I could remember who pointed this out, but it was discovered a few months after the project. But, again, with my previous arguments a filter does not cut it.

Categories: Drupal

Full menu

New Drupal Modules - 24 September 2015 - 3:03am

This module allow you:
1, output the full menu tree without using expanded choice. Then I could use superfish for main navigation.
2, replace the block title of "system_menu_block" with parent menu item name. Then the left sidebar menu block have a meaning title.

The core Drupal 8 menu block does not support these 2 features.
menu_block moule does not have a workable Drupal8 version, it provide too much options which i do not need them.

Categories: Drupal

Steve Purkiss: Remote DrupalCon - Day 2

Planet Drupal - 23 September 2015 - 1:15pm
Wednesday, 23rd September 2015Remote DrupalCon - Day 2

Let's never do that again

Unlike when I was watching yesterday's Driesnote, I actually quite expected these sorts of words to come out of the mouth of Larry Garfield, aka @crell, long-time Drupal contributor and the reason I stayed up way too late last night after blogging so not strictly Day 2 but deserves a mention as was a superb, insightful session "Drupal in 2020".

The never do that again refers to the four-or-so years spent on developing Drupal 8 with most of that time spent not developing new stuff but just barely catching up with modern technology trends. In order to be relevant even with today's technologies we need to be looking at what we could be doing and Larry shows off a number of impressive development projects which enable PHP to run in a similar way to node.js - even faster in many cases. Well worth a watch!

I ended the night with Ken Rickard's 2020 Vision, an entertaining session from a highly experienced professional reminding us that we are implementing a content management system, not a web publishing tool which comes from the print era, and thus there are many different considerations, and often many of the non-technical ones are overlooked whereas they can prove to be the biggest obstacles.

Day 2 Keynote - Web Psychologist Nathalie Nahai

I'd seen Nathalie talk before so I must admit I wasn't paying much attention until I saw a question pop up on twitter asking how this session mostly on marketing manipulation techniques was relevant to our community. Nathalie quickly focused on how we could use some of the techniques to help our current community as well as attract new people in by simply telling our story. A well-deserved round of applause came when Nathalie remarked:

"This is such a vibrant community it needs to be expressed online much more"

This is a big area of interest to me as I see so many wonderful stories from around the Drupal world yet currently the loudest voices being heard are the ones with funding. I've not an issue with that per se, I believe we could do more by collaborating together on strong marketing messaging.

I know the DA are doing as much as they can with the resources they have available, however I believe there is a place in the market for an organisation which markets the community as a whole - I envisage trucks that turn into training rooms / 24h coder lounges with schwag stores on board so can rock up to camps all over the place ;) But I guess that's another blog for another time - all I know is I'd love to go round the world interviewing the community for all to see & potentially training many more unexplored areas up in our community values of ownership!

Making the Leap: Successful Products as a Web Agency

Drawing from his own experience with Drupal offsite backup service NodeSquirrelDrew Gorton from managed hosting service providers Pantheon gave an interesting talk covering how quite a few product businesses had managed to make the uncommon successful birth from an agency. Drew provides useful insights I empathise with as I much prefer working in the product world however what with my bootstrapping and co-operative ideals it's taking a little longer than I'd hoped for ;)

Self-Managing Organizations: Teal is the new Orange

This was a really interesting session from a company I hadn't heard of before - Liip. Their organisation is around the 120 people mark and they have a self-organising way of working, with the ratio of pay difference between high and low 3-1. I beleive the company is also owned by the staff however I don't think the percentages were detailed, will have to watch again. They said they had no plans and let teams decide their own projects, strategies, etc. Obviously it's not all plain-sailing and provided a for a great case-study in things going certainly a better way in terms of fairer working environments and enabling human beings to grow rather than be stunted by job roles.

I watched a little of Shut up and take my money! which was about integrating the Stripe payment system with Drupal 8. I've done this previously and nothing much seemed to be different on the Stripe side so moved on - the videos are pouring in quick & fast!

I then watched Expose Drupal with RESTful for a short while until I realised it was 7 so moved on to PhpStorm for Drupal Development which was a fairly short session clocking in at 15 minutes however very useful, even pointing out a feature which shows you what features you have and haven't been using. I'm no fan of the licensing on PhpStorm but it does make life much easier so will be harder to give up than my macbook but I guess will have to be done at some point if I'm going to achieve complete Freedom!

Headless D8 in HHVM plus Angular.js

It was noted from the outset that this was a sponsored session from so they would be showing off their product, which I've had the pleasure of playing around with a little on a time-limited trial, however I was suckered in by the buzzwords so I stuck it out. Being at home it was even easier for me to just click the mouse than suffer potential slight embarrasment as I walk out of the session room but in reality that rarely happens and I end up sitting right through the session continually questioning myself as if I were watching the fifth instalment of Jaws wondering wether an incident with a fish will happen at some point.

Suffice to say works with HHVM and Angular.js. I've nothing against sponsor talks or, I think they are both good things, just not this session, for me at least. I guess I wanted to see something shiny, not just a product demo, I feel they could've made a lot more out of the title than they did without having to be so focused on the continual sales pitch. Which I know that's what it was, but felt more like something that should've been out in the exhibit hall. I guess that doesn't get videod and put into the stream though.

I started to watch Altering, Extending, and Enhancing Drupal 8 by Joe Shindelar (@eojthebrave) whom I've had the pleasure of meeting at a number of Drupal events here & in the US. Joe's a great teacher, but for me as I've been playing with Drupal 8 for a while now I decided to skip on, especially when he said "Don't hack core" which is I know the thing, but in Drupal 8 I plan to hack core by simply using its interfaces... it's made for 'hacking' this time. Properly hacking that is of course! I realise this presentation wasn't for me though.

Then I watched a little Building amazing searches with Search API but all was looking pretty similar to 7 so thought I'd put that one on the watch when I have a specific need for it list. Then came along a truly awesome session...

Avoiding and surviving of contribution burnout

As someone who has suffered from depression I am particularly proud of the fact our community can have sessions that cover topics like this. I feel like I'm coming from a different angle as I'm spending most of my time working out how and where I can be of help and it's the client work if anything that's burning me out due to my complete lack of wanting to do anything other than write beautiful code, and I've not yet met a client who has the want or budget to pay me to do that. Sarcasm aside, burnout is a big issue, and something I have an issue with the business/community balance side as I believe one is currently gaining far more benefit out of the other than there should be and I don't really think it's anything that can't be solved with a more balance put back into the situation. That of course is not to make light of anyone's situation, just how I see the situation from my many travels around camps and to CXO meetups and my experience in the world up until now.

Pain Points of Contribution in the Drupal Community

Along similar veins to the previous session, Kalpana Goel delivers another important session trying to untangle the issues surrounding contibuting to the community and how we can potentially go about solving them.

Then I watched around half of Hassle-free Hosting and Testing with DevShop & Behat which looks like an interesting, open, option for self-hosting your own sites. Being a little tired I thought I'd come back to that when I'm more awake one weekend.

Last one for the day was The future of Groups on, which gave an interesting insight into forthcoming changes on, much powered by the persona work done previously, so should be interesting when I log in and tailored content appears for me! It's great to see movement finally here, but I agree with Dries when he said previously it really needs perhaps ten million dollars of investment in it. ATEOTD, if you don't look after your tools you won't be able to make a decent product. It's always been my hope that as we talk about Drupal more, about the Why, and show people around the world what we're building the community will organically scale as people will want to be part of it. I think we have a number of issues in the way of that at the moment - perception, current human fear-driven non-sharing society, and state of internal systems. It's good to see a little focus going on the things we can fix now, hopefully we can scale it up soon so we don't get more fractured across different proprietary community silos just because they're 'easy'.


Well I may not be in Barcelona but I'm certainly ranting like I'm at DrupalCon, just on the record lol! With all the tweets and session-watching I'm certainly getting DrupalCon tired so signing off for the night, looking forward to the final day of sessions tomorrow with another important keynote and of course looking forward to finding out where next year's European DrupalCon will be - hopefully I'll plan a little better and build a little buffer so I don't miss out!

Unfortunately my comments are broken on this site so whilst I'm migrating to Drupal 8, do please tweet me @stevepurkiss or get in touch via my contact form.

tags: drupalconremoteDrupal PlanetPlanet Drupal
Categories: Drupal

Annertech: DrupalCon Barcelona 2015 Day 3

Planet Drupal - 23 September 2015 - 12:06pm
DrupalCon Barcelona 2015 Day 3

Wow! What a day we had at DrupalCon Barcelona 2015. I know, personally, I had the best day i've ever had at a DrupalCon, attending a great keynote on web psychology, a talk that validated my thoughts on design in the browser, an awesome presentation on linked data and the semantic web, and that's without mentioning the BoFs on web apps versus websites and Twitter Bootstrap, and then ... oh man - that was a lot.

So, today's best bits:


Categories: Drupal

Modules Unraveled: 149 Using Panopoly and it's Drupal 8 Future with David Snopek - Modules Unraveled Podcast

Planet Drupal - 23 September 2015 - 10:54am
Published: Wed, 09/23/15Download this episodeProject
  • For people who might not know, what is a Drupal distribution?

    • Out of the box, vanilla Drupal doesn’t do much - you have to install modules and mold it into what you want
    • A distribution is Drupal prepackaged with contrib modules and themes, pre-configured for a specific use case (OOB, X+Y)
  • What is Panopoly?

    • A “starter site” distribution (replacement for vanilla Drupal)
    • A “base distribution” on which to build other distributions
    • A set of Features modules that can be used outside of Panopoly
  • Why would someone want to use Panopoly instead of vanilla Drupal?

    • Improved blank slate
    • Includes some the most popular modules and configuration that almost everyone is using anyway
    • Hide Drupal-isms from site managers and users
    • WYSIWYG, Media, responsive layouts, edit in place, live previews, improved search, UX improvements, a11y improvements
    • Include a bunch of stuff backported from D8: toolbar, responsive bartik, etc
    • Unified content/layout management system built on Panels eco-system
    • Rather than learning all that community knowledge over, re-use a well thought out, tested approach to doing Drupal
  • Some people love Panels, but others hate it. Why would someone who isn’t a “Panels lover” want to use Panopoly?

    • Best of Panels eco-system
    • You build with Views, Entities/Fields, custom code, whatever - the Panels bits tie those things together and allow users to customize them
    • We hide the nastiest bits (page_manager UI) from users and site managers
  • Why would someone want to create their own distro?

    • Boilerplate, build once / deploy lots, maintenance of lots of sites
    • Even small organizations can benefit
  • What advantages do you get by build your distro on Panopoly?

    • Like “base theme” shared work (like WYSIWYG, responsive, etc) and defined approach
    • Focus only on the unique stuff in your distro (by fitting into Panopoly’s architecture)
  • Why would someone want to use one of Panopoly’s Features modules outside of Panopoly?

    • [Quick background on Feature]
    • Dozen or so features
    • If like just a piece of Panopoly (ex. panopoly_wysiwyg) you could steal it!
    • Lots of thought into buttons to enable, filtering for control/security, additional features like Media/Linkit
  • Updating distributions can be hard. What does Panopoly do to help with this?

    • [explain why hard]
    • Docs
    • CI
    • distro_update
  • Security updates in particular can be hard, because you have to wait for the distro to make its own update. How does Panopoly handle them?

    • [mention how handled in the past / security team]
  • What are the plans for Panopoly in Drupal 8?

Episode Links: David on drupal.orgDavid on Twitter (@dsnopek)David on Twitter (@mydropninja)David on webPanopoly project pagePanopoly demo from DrupalCon Austin (demo starts at 18:15)#drupal-scotch on IRC#Panopoly on IRCPanopoly groupTags: planet-drupal
Categories: Drupal

TFA for OAuth2 Server

New Drupal Modules - 23 September 2015 - 8:49am

This module integrates TFA with OAuth2 Server.

At the moment, it just interrupts the Password Credentials ('password') grant type for users who have enabled TFA.

This requires the latest dev version of OAuth2 Server - or apply this patch

Categories: Drupal

InternetDevels: The 10 Commandments of User Interface Design

Planet Drupal - 23 September 2015 - 8:15am

Design is not just what it looks like or feels like, design is how it works.

Read more
Categories: Drupal

Password Reset Help

New Drupal Modules - 23 September 2015 - 8:02am

A simple module extending the default Reset password form.

When a visitor attempts to reset their password more than a number of times (configurable) - it's a sign they're sure they've registered before but can't remember the username and email they've used. To avoid further frustration, we show those visitors a message suggesting to contact customer support by calling a specific phone number for example.

After installing the module, configuration is available at:
Configuration -> People -> Account settings

Categories: Drupal

KnackForge: TRANSLATION in Drupal 7 : How to work with

Planet Drupal - 23 September 2015 - 5:48am

In the previous part, we discussed about the Translation in Drupal 7 works with few snapshots and some makeovers. Now, lets discuss how to work with translation to translate the contents, field values and entity items.

1) Translating Menus

With Drupal core alone, user-defined menu items are not translatable. The Menu translation module, part of the Internationalization (i18n) package, allows users to select a translation mode for each menu.

The following modes are available:

  • No Multilingual Options

  • Translate and Localize

  • Fixed Language

Translate and Localize Menus

There are two ways that menu items will be translated:

  • You can set a language when creating a custom menu item so that the menu item will only show up for that language. Menu items that link to nodes in a particular language will be treated this way.

  • You can localize other custom menu items without a language (for example, menu items linking to views pages). Use the Translate tab to translate the menu item title and description. Translators can also use the 'Translate interface' pages to translate these menu items.


Categories: Drupal

Wim Leers: Making Drupal fly — The fastest Drupal ever is here!

Planet Drupal - 23 September 2015 - 4:59am

Together with Fabian Franz from Tag1 Consulting, I had a session about Big Pipe in Drupal 8, as well as related performance/cacheability improvements.

I’ll let the session description speak for itself:

With placeholders ( having just gone into Drupal 8 Core, BigPipe being unblocked now and actively making its way in, Render Strategies around the corner, and out-of-the-box auth-caching in CDNs + Varnish a true possibility on the horizon, those are really exciting times for Drupal 8 Performance. But there is even more …

Come and join us for a wild ride into the depths of Render Caching and how it enables Drupal to be faster than ever.

The Masterplan of Drupal Performance (Next steps)

Here we will reveal the next steps of the TRUE MASTERPLAN of Drupal Performance. The plan we have secretly (not really!) been implementing for years and are now “sharing” finally with all of you! (Well you could look at the issue queue too or this public google doc, but this session will be more fun!)

Learn what we have in store for the future and what has changed since we last talked about this topic in Los Angeles and Amsterdam and why Drupal 8 will even be more awesome than what you have seen so far.

Also see a prototype of render_cache using the exact same Drupal 8 code within Drupal 7 and empowering you to do some of this in Drupal 7 as well.

Get the edge advantage of knowing more

Learn how to utilize cache contexts to vary the content of your site, cache tags to know perfectly when items are expired and cache keys to identify the objects - and what is the difference between them.

Learn how powerful ‘#lazy_builders’ will allow the perfect ESI caching you always wanted and how it will all be very transparent and how you can make your modules ready for the placeholder future.

See with your own eyes how you can utilize all of that functionality now on your Drupal 7 and 8 sites.

Get ready for a new area of performance

We will show you:

  • How to take advantage of #lazy_builders
  • How to tweak the auto-placeholdering strategies (depending on state of issue at time of session)
  • The biggest Do’s and Don’ts when creating render-cache enabled modules and sites
  • Common scenarios and how to solve them (mobile sites variation, cookie variation, etc.)
  • Drupal using an intelligent BigPipe approach (but a different one, one that is way more like Facebook does it …)
Get to know the presenters

This session will be presented by Wim Leers and Fabian Franz. Wim implemented a lot of what we show here in Drupal 8 and made the APIs easy and simple to use and made cache tags and #lazy_builders a very powerful concept. Fabian has prototyped a lot of this concepts in his render_cache module, introduced powerful Drupal 8 concepts into Drupal 7 and is always one step ahead in making the next big thing. Together they have set out on a crusade to rule the Drupal Performance world to bring you the fastest Drupal ever and with that trying to make the whole Web fast!

Frequently Asked Questions
  • I have already seen the session in Amsterdam and Los Angeles, will I learn something new?

Yes, absolutely. While the previous sessions focused more on the basics, this session will also cover how to use #lazy_builders and custom render strategies to empower your Drupal to be fast.

  • Will there again be a demo?

Yes, there will again be a nice demo :). You’ll love it!

  • Is it even possible to make it even faster than what we have seen?

Yes :)

Slides: Making Drupal fly — The fastest Drupal ever is here!Conference: DrupalCon BarcelonaLocation: BarcelonaDate: Sep 23 2015 - 14:15Duration: 60 minutesExtra information: 


Categories: Drupal

DrupalCon News: Group Photo Timelapse

Planet Drupal - 23 September 2015 - 4:48am

Thank you to everyone who came out to jump in the group photo!  Check us out.

Thank you to Petr Illek for making the timelapse!

Categories: Drupal

undpaul: DrupalCon Barcelona 2015: Get your poster

Planet Drupal - 23 September 2015 - 3:34am

We folks at undpaul love Drupal swag. At DrupalCon Amsterdam, we gave away over 500 shirts for free, which was a huge success. 

drupal planet english
Categories: Drupal

KnackForge: Responsive vertical column layouts using jQuery Plugin

Planet Drupal - 23 September 2015 - 2:22am

Usually while we add contents to a div, it get arranged accordingly to our web styles. But there are some special cases where we need our contents to be arranged in a vertical manner as like the newspaper (or) journal content. To achieve this vertical fashion of content alignment, after a very long and vast search, we found these jQuery plugin to customize the column layouts dynamically based on these plugins:

  • columnizer.js

  • isotope.js

Note: This can be easily acheived with the help of Bootstrap themes as in Drupal 7. These plugin are for the non-bootstrap theming to achieve this kind of result.

The columnizer plugin is such kind of plugin which aligns our content all into a adaptive layout, which is also responsive and kind of interesting too. It does provide us a lot of options to get our content aligned in the layout like newspaper material, journal like stuff and etc.

Now, let us know what's all we need to do are these. Just prepare all your html document and download the columnizer plugin from here

To use columnizer, just call the columnize() function on your jQuery selection, and that’s it! we are ready to go.

Categories: Drupal

Always be shippable

Dries Buytaert - 23 September 2015 - 1:26am

Drupal will soon be 15 years old, and 5 of that will be spent on building Drupal 8 -- a third of Drupal's life. We started work on Drupal early in 2011 and targeted December 1, 2012 as the original code freeze date. Now almost three years later, we still haven't released Drupal 8. While we are close to the release of Drupal 8, I'm sure many many of you are wondering why it took 3 years to stabilize. It is not like we didn't work hard or that we aren't smart people. Quite the contrary, the Drupal community has some of the most dedicated, hardest working and smartest people I know. Many spent evenings and weekends pushing to get Drupal 8 across the finish line. No one individual or group is to blame for the delay -- except maybe me as the project lead for not having learned fast enough from previous release cycles.

Trunk-based development

The past 15 years we used "trunk-based development"; we built new features in incremental steps, maintained in a single branch called "trunk". We'd receive the feature's first patch, commit it to our main branch, put it behind us, and move on to the next patch. Trunk-based development requires a lot of discipline and as a community we have mostly mastered this style of development. We invested heavily in our testing infrastructure and established a lot of processes. For all patches, we had various people reviewing the work to make sure it was solid. We also had different people figure out and review all the required follow-up work to complete the feature. The next steps are carefully planned and laid out for everyone to see in what we call "meta" issues. The idea of splitting one large feature into smaller tasks is not a bad idea; it helps to make things manageable for everyone involved.

Given all this rigor, how do you explain the delays then? The problem is that once these features and plans meet reality, they fall apart. Some features such as Drupal 8's configuration management system had to be rewritten multiple times based on our experience using it despite passing a rigorous review process. Other features such as our work on URL routing, entity base fields and Twig templating required much more follow-up work compared to what was initially estimated. It turns out that breaking up a large task into smaller ones requires a lot of knowledge and vision. It's often impossible to estimate the total impact of a larger feature on other subsystems, overall performance, etc. In other cases, the people working on the feature lacked time or interest to do the follow-up work, leaving it to others to complete. We should realize is that this is how things work in a complex world and not something we are likely to change.

The real problem is the fact that our main branch isn't kept in a shippable state. A lot of patches get committed that require follow-up work, and until that follow-up work is completed, we can't release a new version of Drupal. We can only release as fast as the slowest feature, and this is the key reason why the Drupal 8 release is delayed by years.

Trunk-based development; all development is done on a single main branch and as a result we can only release as fast as the slowest feature.

We need a better way of working -- one that conforms to the realities of the world we live in -- and we need to start using it the day Drupal 8.0.0 is released. Instead of ignoring reality and killing ourselves trying to meet unrealistic release goals, we need to change the process.

Feature branch workflow

The most important thing we have to do is keep our main branch in a shippable state. In an ideal world, each commit or merge into the main branch gives birth to a release candidate — it should be safe to release after each commit. This means we have to stop committing patches that put our main branch in an unshippable state.

While this can be achieved using a trunk-based workflow, a newer and better workflow called "feature branch workflows" has become popular. The idea is that (1) each new feature is developed in its own branch instead of the main branch and that (2) the main branch only contains shippable code.

Keeping the main branch shippable at all times enables us to do frequent date-based releases. If a specific feature takes too long, development can continue in the feature branch, and we can release without it. Or when we are uncertain about a feature's robustness or performance, rather than delaying the release, it will simply have to wait until the next release. The maintainers decide to merge in a feature branch based on objective and subjective criteria. Objectively, the test suite must pass, the git history must be clean, etc. Subjectively, the feature must deliver value to the users while maintaining desirable characteristics like consistency (code, API, UX), high performance, etc.

Feature branching; each feature is developed in a dedicated branch. A feature branch is only merged into the main branch when it is "shippable". We no longer have to wait for the slowest feature before we can create a new release.

Date-based releases are widely adopted in the Open Source community (Ubuntu, OpenStack, Android) and are healthy for Open Source projects; they reduce the time it takes for a given feature to become available to the public. This encourages contribution and is in line with the "release early, release often" mantra. We agreed on the benefits and committed to date-based releases following 8.0.0, so this simply aligns the tooling to make it happen.

Feature branch workflows have challenges. Reviewing a feature branch late in its development cycle can be challenging. There is a lot of change and discussion already incorporated. When a feature does finally integrate into main, a lot of change hits all at once. This can be psychologically uncomfortable. In addition, this can be disruptive to the other feature branches in progress. There is no way to avoid this disruption - someone has to integrate first. Release managers minimize the disruption by prioritizing high priority or low disruption feature branches over others.

Here is a workflow that could give us the best of both worlds. We create a feature branch for each major feature and only core committers can commit to feature branches. A team working on a feature would work in a sandbox or submit patches like we do today. Instead of committing patches to the main branch, core committers would commit patches to the corresponding feature branch. This ensures that we maintain our code review process with smaller changes that might not be shippable in isolation. Once we believe a feature branch to be in a shippable state, and it has received sufficient testing, we merge the feature branch into the main branch. A merge like this wouldn't require detailed code review.

Feature branches are also not the silver bullet to all problems we encountered with the Drupal 8 release cycle. We should keep looking for improvements and build them into our workflows to make life easier for ourselves and those we are implementing Drupal for. More on those in future posts.

Categories: Drupal

Menu Per User

New Drupal Modules - 23 September 2015 - 1:24am

* Menu Per User module is used to show/hide menu(s) per User.


* Install as you would normally install a contributed Drupal module. See:
for further information.


Categories: Drupal

Communications Stack Private Messaging - UI

New Drupal Modules - 23 September 2015 - 12:27am
Categories: Drupal

Tim Millwood: Planning for CRAP and entity revisions everywhere in core

Planet Drupal - 22 September 2015 - 11:46pm
At DrupalCon Barcelona this year I presented with Dick Olsson outlining a plan for CRAP (Create Read...
Categories: Drupal

ActiveLAMP: Setting up a Docker development environment with Vagrant - Part 3

Planet Drupal - 22 September 2015 - 7:30pm

This post is part 3 in the series “Hashing out a docker workflow”. For background, checkout my previous posts.

Categories: Drupal
Syndicate content

about seo