Skip to Content


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

Cocomore: DrupalCon Barcelona interim report

Planet Drupal - 22 September 2015 - 3:00pm

Hola! On Tuesday the DrupalCon 2015 in Barcelona has officially started. It is the day when the lectures are starting, the group photo is to be shot and the first day after greetings, sprints and parties with the community...

Categories: Drupal

Steve Purkiss: Remote DrupalCon - Day 1

Planet Drupal - 22 September 2015 - 2:03pm
Tuesday, 22nd September 2015Remote DrupalCon - Day 1 Release Drupal 8 and momentum will come   “Is Drupal losing momentum? Yes”.   Not the words I was expecting to hear (happens to me a lot this year) come out of Drupal’s founder Dries Buytaert as he took to the stage in Barcelona for this year’s European wing of the DrupalCon conference for his regular “Driesnote”, but as I sit here back in rainy England after having to sell my DrupalCon tickets last week I certainly empathised. Dries explains this lull happens every time at this point between major version releases and assures us a big spike will come when Drupal 8 is released, so all we can do at the moment is work as fast as possible to get Drupal 8 out.   <shameless_plug> I’m certainly excited about working on Drupal 8 projects, so do get in contact if I can be of help with any architectural, development, or other interesting work which is hopefully changing the world for the better in some way - I’d love not to miss another DrupalCon ;) Shameless plug over, it’s on with the keynote...   Move to a more sustainable release process   Once Drupal 8 is out there Dries suggests using a system of feature branching so that you can always be shippable ( This seems like a much more sensible approach than the current one, enabling timed releases and adaptability as different features encounter different issues along the way hopefully meaning they won’t have as much impact on each other as they have in the current release cycle so we don’t have to experience this huge effort to get everything working all at the same time going forward.   Whilst I think this is a good approach I fear this opening up to a huge amount of functionality being able to potentially go into core as it’s easier to develop, which is where the question of different cores for different uses comes in. There was a blog post a while back about how Drupal could evolve more like Linux has with distributions - personally I see that more attractive than putting all the things in core over time, especially if one of the major focus of our efforts in the future is to be for the non-coders as Dries goes on to cover in his keynote.   Put non-coders first to increase our impact   Dries continues to cover Drupal’s market position, suggesting our focus should now be on the user experience to make it easy to do things with Drupal. There is no point in providing functionality for non-coders if they can’t figure out how to use it so personally I’m glad to see a focus on this, and with the growing community of front-end developers, UX people and other job roles I daren’t guess as I’ll no doubt offend as it’s not my area of expertise - I believe it’ll gradually happen.   Whilst WordPress has focused heavily on user experience, Drupal has focused much more on the developer experience. Now we have achieved so much on the developer experience side of things it is time to focus on the user experience, and to cut back from comparing to WordPress as Drupal has moved on much further in terms of technology capabilities and instead to focus on the majority of sites out there which currently have no CMS. By focusing on the usability side it will be much easier for people to see how advanced Drupal is and actually make use out of it themselves instead of being baffled by terminology and ‘Drupalisms’.    Drupal 8 will be the go-to platform for sites and apps   Dries then talks about Drupal’s technological relevance in the future as many other front-end frameworks appear and develop and are certainly here to stay. He outlines the future not as one of a completely de-coupled Drupal as you miss out on a lot of Drupal’s goodness by taking that approach and instead talks about ‘progressive decoupling’ where Drupal is much more integrated into the front-end process. I tend to agree here and put it down to current lack of appreciation of Drupal’s capabilities simply because there are so many, and as Drupal 8 is adopted more I am sure more examples will fuel the interest and we will see some interesting ‘mash-ups’ - if I had unlimited time & funds I’d certainly be hooking up views to my Oculus VR - do feel free to sponsor that one lol!   Here’s the slides from Dries’s DrupalCon Barcelona 2015 Driesnote:   Slides:   Video:   Other sessions from Day One Once the keynote had finished I was pleasantly surprised to see the sessions appear almost immediately on youtube, here’s a link to the Drupal Association’s video list where they appear:   DrupalCon Barcelona 2015: The Prenote!   Always a fun kick-off to DrupalCon, always a laugh and a song, watch it if you didn’t get to go along!   Content Strategy for   For a long time now, the online home of the Drupal community, has been maintained mostly by the community however recently thanks to funding more and more is being done to improve the site which is the biggest online Drupal site there is. Tatiana (@tvnweb) who works for the Drupal Association as product owner of details the process of the work done so far to categorise the content and uses of and covers the current and future developments.   The main area of change is around managing of projects which is moving to organic groups and should provide a much more comprehensive way of collaborating online than the current functionality provides. I am certainly enjoying all the improvements which have been regularly appearing of late and am excited about the growth that these changes will hopefully provide by making it easier to see, understand, and become part of the Drupal community, something which has been up until now quite a mystery to many people!   How to diversify your business beyond Drupal   This was a journey through the trials and tribulations of Amazee Labs as they grew into different service offerings and geographical locations - always interesting to hear the issues surrounding business and a lot to be learned from one of Europe’s top Drupal agencies!    Winning and delivering big projects from a small agency perspective   An interesting take on how to approach the business scene from a different angle focusing on your individual strengths as an agile, small business.   Configuration Deployment Best Practices in Drupal 8   If you want to get down-and-dirty with CMI on Drupal 8 then this is the session for you. See how to move config from one environment to another, something which was nigh-on impossible in Drupal 7 so yay to CMI!   Solving Drupal Performance and Scalability Issues   Tine Sørensen, whom I’ve had the pleasure of meeting at a few Drupal events but sadly missing out this time :(, delivers a useful session covering many issues of dealing with performance and scalability from both the technical and human side of things. Often there’s many low-hanging fruit but it’s sometimes hard to get developers to work on them as they want to work on perhaps things which means they can code more like refining sql queries coming out of Drupal. Instead of this, Tine’s approach is to get the low-hanging fruit out of the way then look at the situation again as there’s hidden costs of changing what comes out of Drupal in terms of sustainability. Tine mentions the graphics library GD being one culprit, with ImageMagick being a replacement using much less resources.    There’s way too many good bits of information in Tine’s session for me to highlight here so do watch the session as often many of these easy-to-rectify things are overlooked and the blame is put on Drupal for being slow when all it takes is a little tweaking to get it running just fine!   Drupal 8 theming   I thought I’d finish off the day by watching MortenDK’s theming talk. For the first time in a long time I was sitting there wondering what had happened as there seemed to be a calmer Morten presenting - a testament to the work that’s gone into changing how front-end developers work with Drupal and I could empathise with him when he says he now looks at Drupal 8 code with a sense of relief as that’s how it also feels from a back-end developer’s point of view especially if like me you came originally from an object-oriented way of working 15 years ago then had to learn Drupal’s hook system!  

Final thoughts

Drupal 8 is a game-changer and I’m excited about the possibilities - especially as the community grows around the world. Meanwhile, it’s back to youtube until I pass out on this no-frills DrupalCon experience - sad to be missing out on all the networking & fun times but sh*t happens, one lives and learns... ;) tags: drupalcondrupalDrupal PlanetPlanet Drupal
Categories: Drupal

Realityloop: The calm before the storm

Planet Drupal - 22 September 2015 - 1:39pm
23 Sep Brian Gilbert

The Realityloop team is currently at DrupalCon Barcelona. During the opening keynote this morning Dries Buytart attempted to investigate several questions regarding Drupal's place at the moment.

In particular I was interested when he asked "Is Drupal losing momentum?", even before he continued I thought to myself that this is mostly people waiting on Drupal 8 to get released.

Looking at statistics he showed that this loss of momentum has ocurred in the past, as you can see in the image from Dries' slides shown below, Drupal lost momentum before the release of Drupal 7.

This is known as the Osbourne Effect which posits that "Announcement of a new release slows adoption of the current version." I know that we have clients that are contributing to this as I've had several discussions that start with "should I upgrade my site now or wait until Drupal 8 is released?".

This is a somewhat complex question that depends a large part on the functionality that is required by your site, the budget you have to invest towards module porting, and also the time at which the conversation took place.

The key thing is that after the release, at least since Drupal 6, there has always been a surge in adoption once the next version gets released.

As part of the core mentoring team I am a firm believer that you can predict this by looking at the number of contributors for each release:

  • Drupal 5 - 472+ contributors
  • Drupal 6 - 741+ contributors
  • Drupal 7 - 950+ Contributors
  • Drupal 8 - 3,000+ contributors

To me this indicates that there will be quite the surge once Drupal 8 is released, and the exciting news is that RC1 has now been scheduled for release on October 7th.

The Realityloop team is committed to Drupal, and although we are a team of 3, we've been involved in the development of over 100 contributed modules and are already scheduling time to begin work on porting many of the modules that still have a place in Drupal 8.

Drupal already powers close to 50% of the top 100,000 websites, and with one of the largest developer communities of any open source project I truly believe that once Drupal 8 goes stable there will be a surge in growth and a storm of really great sites for us to build.

If you have an upcoming project and would like to talk about building it with Drupal 8 or are interested in supporting the porting of any modules to Drupal 8, please do get in touch with me from October 4th: 

  • Brian Gilbert  Ph +613 8609 6966

If you are interested in hearing more about Drupal 8 the Realityloop team are currently also organising Drupal Camp Melbourne, and unconference which will be held on November 27th and 28th 2015.


drupal planet
Categories: Drupal

Annertech: DrupalCon Barcelona 2015 Day 2

Planet Drupal - 22 September 2015 - 12:33pm
DrupalCon Barcelona 2015 Day 2

DrupalCon Barcelona. Day 2. The Annertech crew were up early (especially given our late night last night) and arrived at the convention centre. Here's our team's "best of the day" list - including one from Marta Paz, whom we've picked up as an honorary Annertechie for the week.

Mark "I loved the talk by Tim Millwood and Dick Olsson about revisions in Drupal 8. We see a lot of tenders for large projects asking for an "audit trail" and the approach being taken with multiversions/revisions looks very, very promising."


Categories: Drupal

Annertech: DrupalCon Barcelona 2015 Day 1

Planet Drupal - 22 September 2015 - 12:25pm
DrupalCon Barcelona 2015 Day 1 The Annertech team descended on DrupalCon Barcelona on Monday. Sun on our faces, wind at our backs, day one saw us all getting busy. Mark and Andrew worked their way through some accessibility issues for Drupal 8 - writing patches, reviewing patches, and move issues along the queues. Stella attended the business summit. Tommy, Gavin, and Anthony all completed Acquia-certification exams.
Categories: Drupal

Cheeky Monkey Media: Building a custom module part 2

Planet Drupal - 22 September 2015 - 12:22pm

This tutorial is written for new drupal developers or php developers who want to learn drupal. You can find the part 1 of the tutorial here: tutorial part 1

Last time, we created a simple recipe module with save and load functionality. The user interface is not very friendly yet, and users have to enter a recipe id in the url to load it.

Today, we are going to improve the usability of the module by adding some UI element to it. By the end of the tutorial, you will be able to add, and...

Categories: Drupal

OSTraining: What Does Delta Mean in Drupal?

Planet Drupal - 22 September 2015 - 11:44am

When you are adding Views, you may have seen an extra option called "Delta".

Several students have asked us about the purpose of this field, because it wasn't clear.

The Delta option is available throughout the site, but ordinary users are most likely to encounter it inside Views. Here's how the "Delta" options appear in Views:

Categories: Drupal

RestWS Schema

New Drupal Modules - 22 September 2015 - 11:17am
  • Install and update the restws_schema Drupal 7 module per usual (ideally with Drush)
  • Optionally enable restws_schema_ui module.
Categories: Drupal

Nuke Drupal Frontend

New Drupal Modules - 22 September 2015 - 10:39am
What is it?

Removes Drupal's frontend, when using Drupal as a services layer only.


  1. Uninstalls frontend-only core modules (some are truly only useful when Drupal renders the frontend)
  2. For all other core modules, removes access to the paths only useful to Drupal's frontend
  3. Redirects disallowed paths to user login or, (if allowed) to the admin screen
  4. Properly redirects entity frontend paths to their corresponding edit screen
  5. Remaps breadcrumbs to match the new backend-only experience
Why bother?

To help avoid confusion when not using Drupal's built-in frontend.

Categories: Drupal
Syndicate content

about seo