Drupal News

Subscribe to Drupal News feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 1 hour 11 min ago

Drupal core announcements: What's next for core patches after 8.0.0?

Tue, 11/24/2015 - 18:03

Last week, we released Drupal 8.0.0! This amazing milestone signals a new era in Drupal core development, with changes to the changes allowed in patches and a new release cycle with minor versions scheduled every six months.

Now that Drupal 8 is ready for building real sites, with contributed projects already available or being built, the immediate focus for Drupal 8 core will be fixing bugs to help those real sites, as well as fixing any issues in Drupal core that prevent contributed modules from being ported to Drupal 8. Another top priority is stabilizing and completing the core Migrate feature and its user interface, so that existing Drupal 7 and especially Drupal 6 sites can move to Drupal 8 reliably. Finally, a third priority is adding frontend and performance testing to help us make changes more safely. For the next six weeks, we will mainly be committing patches that move us toward these three goals.

Then, after January 6, 2016, we will begin a broader feature development phase for innovations in 8.1.x, 8.2.x, and beyond, so long as we are able to resolve critical issues consistently and keep 8.1.x stable for a reliable scheduled minor release. Read more about the proposed development, beta, and release candidate phases for minor versions.

Drupal 8 core branches and the core issue workflow

Starting today, all patches that are accepted to core according to the priorities above will be committed first to the 8.1.x git branch (even when they are filed against 8.0.x-dev in the core issue queue). Patches that are eligible for patch releases will typically be immediately committed to 8.0.x as well. If we are close to a bugfix release window, the issue may be marked "Patch (to be ported)" and committed just after the bugfix release, to give ample time to catch any regressions or followups before each change is deployed to production sites.

Some patches will only be committed to 8.1.x (for example, if they are too disruptive for a patch release or if they make additions that are only allowed in minor releases). Keep in mind that the open feature development phase for 8.1.x has not started yet, so plan to work on general feature additions and BC-compatible API improvements after it does.

Note that for the time being, patch-release-eligible issues are still filed against 8.0.x-dev in the core issue queue and most 8.1.x issues are still postponed pending the open feature development phase. Later, we will update the core issue metadata and processes as we move into more extensive minor version development.

DrupalCon News: Sessions Announced for DrupalCon Asia

Tue, 11/24/2015 - 15:19

One of the most exciting aspects of preparing for a DrupalCon is selecting the sessions that will be presented. It’s always incredibly cool and humbling to see all the great ideas that our community comes up with— and they’re all so great that making the official selections is definitely not an easy process! This time, the Track Chairs had almost 350 sessions to read through to determine which 50 would be presented in Mumbai.

Drupal Watchdog: Black Box – White Hat

Tue, 11/24/2015 - 11:51

Drupal has a pretty secure structure: a small, simple and stable core that can be extended with tons of modules and themes. From Drupal 7’s initial release on January 5, 2011 until now, there were only 17 core security updates, which is quite a small number for a period lasting longer than four years.

But when it comes to third-party modules and themes, the picture is quite different. Although only modules with official releases are reviewed by the security team, or have security announcements issued, the majority of the 11,000+ third-party modules and themes for Drupal 7 get weekly reports for security issues.

And using custom modules is even more dangerous if they are not tested properly. Let’s face it: no one uses Drupal without modules. That’s why I will share with you some of the best open source tools to improve the security of your website.

Knowing your opponent’s moves helps you better prepare your defenses. That’s why we will try to attack with every known-at-the-moment method of testing vulnerability. All the tools I will show are easy to use without any knowledge of the source code. And the best part is, you can use this strategy indefinitely, if you keep these tools up-to-date. Remember: update first, then test.

Being Up-to-Date

I can’t emphasize enough how important it is to keep all your stuff up-to-date, so let’s start with that idea: If one tiny part of your website has a security breach, the whole system is corrupted. That’s why you should check for updates for the core and the modules you are using. There are reports you can find on Drupal’s official page; if you find that there is a security update available, immediately apply it.

Metasploit + Armitage = Hail Mary!

Start with Kali Linux: it's small, and has Metasploit and Armitage pre-installed. Armitage gives you a GUI, exploit recommendations, and use of the advanced features of Metasploit Framework's Meterpreter. (But remember to get updates every time you're about to run tests.)

Then, get an exact clone of the server; same machine, database, structure, OS version, etc.

NOTE: It is not recommended you use this technique on live websites because there is a chance the server will go down.

Pantheon Blog: Update Your Nginx Config for Drupal 8

Tue, 11/24/2015 - 11:10
If you are still using the same Nginx configuration that you have been for Drupal 7 on your new Drupal 8 install, most things will continue to work; however, depending on the exact directives and expressions you are using, you might notice a few operational problems here and there that cause some minor difficulties.  The good news is that the Drupal configuration recipe in the Nginx documentation has been updated to work with Drupal 8, so if you have a very basic Nginx setup, you can just grab that and you’ll be

a-fro.com: Speed Up Cache Clearing on Drupal 7

Tue, 11/24/2015 - 10:33
Speed Up Cache Clearing on Drupal 7 Cache clearing nirvana may be two vsets away

tl;dr If your D7 site uses features or has many entity types, some recent patches to the features module and the entity api module may deliver dramatic performance increases when you clear Drupal's cache. The magic:

$ drush vset features_rebuild_on_flush FALSE $ drush vset entity_rebuild_on_flush FALSE aaron Tue, 11/24/2015 - 11:33

.VDMi/Blog: Generating menu items in Drupal 8

Tue, 11/24/2015 - 08:02
Drupal 8 comes with a new way to generate menu items from code. In Drupal 7 you would do this with "hook_menu()", in Drupal 8 you use a Derivative Plugin.

Mediacurrent: Weather.com Recognized as Acquia Partner Site of the Year

Tue, 11/24/2015 - 07:18

Last November, Weather.com launched on Drupal and became one of the highest trafficked websites in the world to launch on an open-source content management system (CMS). Today, we're proud to announce that we have been recognized with a 2015 Partner Site of the Year Award

Pantheon Blog: Explicit Drupal: Clear Intentions in Drupal 8!

Mon, 11/23/2015 - 20:36
Much of the conversation in the Drupal 8 development cycle has focused on “NIH vs. PIE.” In Drupal 8 we have replaced a fear of anything “Not-Invented-Here” with an embrace of tools that were “Proudly-Invented Elsewhere.” In practice, this switch means removing “drupalisms,” sections of code created for Drupal that are understood only by (some) Drupal developers. In their place, we have added external libraries or conventions used by a much wider group of people.

OSTraining: Put Drupal Sites in Maintenance Mode Manually

Mon, 11/23/2015 - 20:14

Drupal allows to set a website offline with a few clicks via the admin interfacte.

However, we've seen situatuons where the admin interface becomes unavailable, often via a white screen of death.

In this tutorial, I'm going to show you a manual way to force your Drupal 7 site in maintenance mode.

Greater Los Angeles Drupal (GLAD): GLADCamp 2016 is at SCALE 14x on January 21, 2016!

Mon, 11/23/2015 - 15:43

Greater Los Angeles Drupal Camp (GLADCamp) is a full day of Drupal on January 21st, 2016, at the Pasadena Convention Center in Pasadena, California.

We've partnered with SCALE 14x, the 14th annual Southern California Linux Expo, and are planning an all-day event that's packed with activities, including presentations and sessions.

GLADCamp has a focus on "Drupal for good" and civic engagement. We're still looking for a partner venue where we can feature either a non-profit summit or a Coder's with a Cause "barn raising" to benefit a local 501c3 non-profit, but for now we're ready to announce GLADCamp on January 21st, 2016.

Are you looking forward to warmer weather? Join us at GLADCamp, the sunniest DrupalCamp of the season!

We'll be announcing our call for presentations in the next couple of days.

Stay tuned to this event announcement, the GLADCamp.org website and @GLADCamp on Twitter for upcoming news and announcements.

Register for GLADCamp 2016

To register for GLADCamp 2016, you must register for SCALE. See the SCALE website for more information or register now at https://reg.socallinuxexpo.org/reg6/  

Who should attend GLADCamp?
  • Anyone wanting to know more about how Drupal can help you solve your problems.
  • Anyone wanting to network with others using Drupal in your area, either geographically or in your industry.
  • Anyone wanting to grow their Drupal team, or be hired for Drupal work.
  • Anyone wanting to give back to the Drupal community. The power of Drupal is in the community so contributing back helps us all.
  • Anyone wanting to learn more about Drupal, past, present and the future.
  • Non-profits wanting to learn how to use Open Source and Drupal to amplify your efforts.
GLADCamp needs you!

We can't do it without your help. We need volunteers to help with the following activities:

  • Join the session selection committee! We need a team that accurately reflects our community and expected attendees;
  • Help with info/registration desk (2 hour shifts); answer questions, sign attendees in;
  • Be a timekeeper at sessions in order to keep our presentations on schedule;
  • Join our video team and help record sessions and assist presenters with screen recording software;
  • Design and print signs, posters and badges for GLADCamp; we can provide logo and brand guidelines;
  • Wrangling volunteers for day-of tasks;
  • Organize evening reception, including help finding a location near the Pasadena Convention Center;
  • Print designers: design and print common area signs, posters, badges;
  • GLADCamp set-up and breakdown!
Tags: Planet Drupal

DrupalCon News: The Druplicon Tours India

Mon, 11/23/2015 - 13:26

We couldn't be more excited to bring DrupalCon to India: it's a unique and colorful nation with many amazing cultures. Though the Con itself will be held in Mumbai, we strongly recommend that anyone traveling to India for DrupalCon take the time to tour some of the many fascinating regions of India.

How much does India have to offer? Our friends at Niswey illustrated the Druplicon on a tour of the country, experiencing four unique cultures that India has to offer. Here's the comic, and you can see more information on each frame below.

Web Wash: Build a Blog in Drupal 8: Create and Manage Menus

Mon, 11/23/2015 - 13:22

A website's navigation plays an important part in how easy a site is to use. It's essential that you spend time fleshing out the overall IA (Information architecture) or you'll end up with a site that's hard to use and difficult to navigate through.

Previous versions of Drupal have always offered a simple interface for managing menus, and Drupal 8 is no exception.

In this tutorial, we'll continue building our site by adding in some menus. We'll create a custom menu which'll be used to display links to popular categories, then create an "About us" page and add a menu link to the footer.

Axelerant Blog: How To Set Up Drupal RESTful Caching

Mon, 11/23/2015 - 12:00

The Drupal RESTful module has a multitude of caching options and sorting through them on your own for the first time can be slow. This article will help you get started with Drupal RESTful caching.

NOTE: RESTful 2.x module was recently released. This article focuses on the 1.x RESTful module version and the techniques mentioned below may not work if you are using any other release.

Your caching options can be controlled at various levels in code. Knowing which layer your application needs is just as important as knowing how to execute, but we’ll start off with how, we’ll move on to why later.

hbspt.cta.load(557351, '5ad743d7-d16e-4b64-bc0a-078bc790dea1'); Start with Drupal RESTful Caching

To start caching your endpoint, the initial configuration is setting render to TRUE in the plugin file under render_cache key.

RESTful skips caching your endpoint if this setting is FALSE, which is the default value. In addition to this, Drupal RESTful also ships with support for the entitycache module for entity based endpoints.

Here’s how a typical flow looks like for an endpoint:

function viewEntity($id) { $cached_data = $this->getRenderedCache($context); if(!empty($cached_data->data)) { return $cached_data->data; } // perform expensive stuff and construct payload $values = construct_payload(); $this->setRenderedCache($values, $context); return $values; }

$context is the entity context, like the bundle name, entity ID and any other metadata you might find to be relevant to constructing your cache key. In most cases, just the bundle name, entity type and ID would suffice. RESTful fills in other contextual data like endpoint name, GET parameters, etc. RESTful builds your cache keys in a crafty way so that it is easy to do CRUD operations in bulk. For instance, clearing all caches for the “articles” endpoint would be something like clear("articles::*").

Within the RESTful project, RestfulBase.php houses all the caching primitives, like getRenderedCache, setRenderedCache, clearRenderedCache and generateCacheId. The last function, generateCacheId, constructs the cache key based on the $context supplied to that endpoint.

Preventing Cache-Busting

It is also worth noting that Drupal RESTful caching allows you to override the key generation logic on a per-endpoint basis. This is especially useful when you want to build a custom cache key.

While working on Legacy.com, we had to build a cache key which is agnostic of specific GET parameters. By default, the generateCacheId builds a different key for the following endpoints:

  • articles/23?foo=123456
  • articles/23?foo=567898
  • articles/23?foo=986543

Though a different key for each of these calls makes sense in most cases, it is redundant in some cases. E.g. we return the same payload for all the above 3. To change this behavior, we ended up overriding generateCacheId.

The setRenderedCache, getRenderedCache, and clearRenderedCache operate upon the default cache controller, which can be specified in the plugin using the class key inside render_cache. This value defaults to DrupalDatabaseCache.

This default value can also be explicitly set to your favorite caching backend. In our case, we use the memcache module and set this value to MemCacheDrupal. Again, Drupal RESTful allows you to configure caching backends on a per-endpoint basis.

Managing Caching Bins

Cache backends have this concept of bins, which is an abstraction for similar data which can be grouped together. Examples from the Drupal core are cache_filter and cache_variable.

There is a bin setting for every endpoint in the plugin file, which is cache_restful unless we explicitly specify otherwise. It is advisable to store high traffic endpoints in exclusive bins.

There is an expire setting for each endpoint, which dictates the cache expiration for that endpoint. This defaults to CACHE_PERMANENT, which means that the entry will never be wiped off until it is explicitly selected for clearing.

The alternative is CACHE_TEMPORARY which indicates that it will removed in the next round of cache clearing.

These are the very same constants used in Drupal cache interface’s cache_* calls. There is a middle ground too, which isn’t documented. The expire value can be set in seconds. This is a deviation from Drupal’s convention of mentioning it as a timestamp.

Varying Caching by Role or User

Some endpoints need to be cached for each role, and some for each user. This granularity can be controlled by the granularity setting, which takes either DRUPAL_CACHE_PER_USER or DRUPAL_CACHE_PER_ROLE. This depends to some extent on your authentication mechanism too.

We wrote our own authentication mechanism and had a user created exclusively for the API and serving the endpoints. We gave this user an exclusive role and configured per-role caching for all the endpoints.

Here’s how the plugin configuration looks for one of our endpoints:

$plugin = array( 'label' => t(Recommended Videos'), 'resource' => recommended_videos', 'name' => recommended_videos__1_1', 'entity_type' => 'node', 'bundle' => video', 'description' => t('Get all recommended videos for a given article.'), 'class' => RecommendedVideosResource__1_1', 'authentication_types' => array( 'my_custom_token', ), 'minor_version' => 1, 'render_cache' => array( 'render' => TRUE, 'expire' => CACHE_TEMPORARY, 'granularity' => DRUPAL_CACHE_PER_ROLE, ), // custom settings 'video_sources' => array(youtube', 'vimeo'), ); The anatomy of a Cache key

A cache key using the default key generation logic looks like this:


The corresponding endpoint URL looks like this:


The first part is the API version, followed by the resource name, which is “recommended_videos”. The next part is either a “uu” or “ur” depending on whether it is user level or role level granularity. Next is the entity type (e.g. node) with a prefix “pa”. This is followed by the entity ID part, which is “ei:105486” in this case.

The last part is the truncated key-value list of GET params foo and bar. Each logical section is separated by a “::” so that it is easy to do a selective purge, as in wiping out all endpoints for v1.0 of the API would be a call to clear("v1.0::*").

Note that a GET for a collection of resources like latest comments results in a viewEntity for each item in the collection and as many cache entries. If you want a single cache entry for the whole collection, you have to custom build your payload and call setRenderedCache as shown in the initial endpoint workflow code snippet.

Other Considerations Be Diligent, Validate Cache Strategies Early

RESTful is designed as being very modular from the ground up and has a provision for controlling caching settings for every endpoint. Such a high level of control is both good and bad. Digging through an issue for hours because some settings for an endpoint are misconfigured isn’t fun for anyone. Unless the settings are clear and explicit, it makes issues hard to debug and sort out.

Be diligent and validate your caching strategy from the beginning.

Memcache Stampeding

Another thing to look out for is memcache stampeding. Memcache stampeding occurs when a missing key results in simultaneous fetches from the database server, resulting in a high load. Memcache is designed to prevent too many requests from piling up.

With our work with Legacy.com, we could mitigate the need for passing these requests to Memcache by properly managing our Varnish layer.  We will detail on how we fixed the stampeding issue and constructed a Drupal RESTful Caching strategy in a later post. Stay tuned!

Need help with Drupal RESTful Caching on your team? Learn More Drupal RESTful Caching Resources

The post How To Set Up Drupal RESTful Caching first appeared on Axelerant.

Acquia Developer Center Blog: Integrating Drupal with a Proprietary Analytics Platform: How Parse.ly Did it.

Mon, 11/23/2015 - 10:07
Stefan Deeran

One of the great things about Drupal is its flexible system of nodes and taxonomies. This allows for bespoke categorization of many types of content.

At Parse.ly, we wanted to take advantage of that. Parse.ly, which has an alliance with Acquia to bring joint tech solutions to the worlds biggest media companies, works with hundreds of digital publishers to provide audience insights through an intuitive analytics platform.

Tags: acquia drupal planet

Cryptic.Zone: Where is hook_page_alter in Drupal 8?

Mon, 11/23/2015 - 08:11

In Drupal 7, hook_page_alter was a convenient way to go when we needed to modify page elements that were added by other modules. Drupal 8 does away with this hook - hopefully for the better. To fill the void created by hook_page_alter’s dismissal, the following hooks have been introduced.

ERPAL: Automation is the key to support SLAs

Mon, 11/23/2015 - 06:15

If you want to grow recurring revenue by providing SLAs for your Drupal projects, automation is THE key to offering a reliable response time. Of course, you could build a dedicated 24/7 support team - but the cost will be exorbitant!

There are many tools out there for digitizing your support and automating some of the processes. A well-defined support concept is the key to success. In this blog you'll get an introduction in four foundations of automated support systems. Read more

Red Crackle: Express checkout to increase conversion

Mon, 11/23/2015 - 04:40
In this post, you will learn how to enable express checkout to increase conversions on your site. It's a fairly simple procedure that allows the shopper to proceed directly to the checkout without visiting the Cart. This saves time and ensures that you are able to win the shopper's business quicker.

ThinkShout: Up and Theming with Drupal 8

Mon, 11/23/2015 - 04:00

Drupal 8 is finally here! We’ve been digging into the code and learning how to install D8 in a way that allow us to sync sites and use it for production work. A lot of things have changed, which we covered in our previous article, Up and Running with Drupal 8. The next step is to see what’s changed in the theming layer, installing a basic theme, and working with the new Twig templating system. There’s a good deal to cover, so let’s jump in!

Creating a Theme

The steps for setting up a basic site theme are fairly simple: create a custom/THEMENAME directory in web/themes, and then add a THEMENAME.info.yml file with the following:

name: THEMENAME Theme description: 'D8 theme for THEMENAME site.' package: Custom # base theme: classy type: theme version: 1.0 core: 8.x regions: header: Header content: Content # required! sidebar_first: 'Sidebar first' footer: Footer

Then you can enable your theme (administer » themes) in the interface. Note that uncommenting base theme: classy will cause you to set Classy as a parent theme. We feel that Classy is great if you want a lot of useful examples, but really clutters up the markup, so use at your own discretion. After rc1, the default theme will be ‘stable,’ and you may want to pull all of the core templates into your theme to ensure you’re working from the latest updated template code.

Also, the theme name must not contain hyphens. So /theme-name/ is invalid (it won’t even show up!), but /theme_name/ is fine.

Now we’ll want to start customizing our theme. Let us say we have a content type called ‘blog’ (machine name: blog), with a field type called ‘Publish Date’ (machine name: field_publish_date).

Despite setting the label of field_publish_date to ‘inline,’ it’s wrapping to a new line due to the fact that it’s a simple, unstyled <div>.

Worse, it has no classes to specifically style it. Let’s set ourselves some goals:

  1. Add the inline styling class(s).
  2. Change the markup for this field, so that we have a class for the label.
  3. Add CSS to style the label, but ONLY for the ‘Blog’ content type.

The documentation for this seemingly simple task is obfuscated and evolving right now, but we were able to get it working correctly using the following steps:

Step 1: Turn on twig debug mode. We also found it helpful at this point to make a copy of web/sites/example.settings.local.php in web/sites/default/ and uncomment the following in settings.php:

if (file_exists(__DIR__ . '/settings.local.php')) { include __DIR__ . '/settings.local.php'; }

This will allow you to disable caching during development, which is no longer a simple checkbox in the performance section. Note that disabling caching can be tricky; the drush cr (cache rebuild) command is the most reliable way to ensure the cache is really cleared. You’ll also have to rebuild the cache at least once after turning caching off, so the new cache settings are applied.

Step 2: Make a custom field template.

In this case, the suggested debug fields are:

<!-- FILE NAME SUGGESTIONS: * field--node--field-publish-date--blog.html.twig * field--node--field-publish-date.html.twig * field--node--blog.html.twig * field--field-publish-date.html.twig * field--datetime.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'core/modules/system/templates/field.html.twig' -->

The highlighted line above shows the template currently being used, suggestions for increased specificity, and the file location (core/modules/system/templates/).

We want to update field_publish_date globally, so we’ll create a template called field--field-publish-date.html.twig

To do this, we copy field.html.twig from the core theme (see the ‘BEGIN OUTPUT’ line above for the path), and rename it in our theme’s folder to field--field-publish-date.html.twig. Now when we reload, we see the following (if your cache is disabled, of course, otherwise drush cr will clear the cache):

<!-- FILE NAME SUGGESTIONS: * field--node--field-publish-date--blog.html.twig * field--node--field-publish-date.html.twig * field--node--blog.html.twig x field--field-publish-date.html.twig * field--datetime.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'themes/custom/THEMENAME/templates/field--field-publish-date.html.twig' -->

Now we can begin to update the markup. The relevant code is:

html {% if label_hidden %} ... (we don’t care about the label_hidden stuff) {% else %} <div{{ attributes }}> <div{{ title_attributes }}>{{ label }}</div> ... {% endif %}

To add the inline styling class, we add the following to the top of the template (below the comments):

html {% set classes = [ 'field--label-' ~ label_display, ] %}

And then update the label’s parent div attributes:

before: <div> after: <div>

Now the correct class is in place, but we see no change yet - because the <div> isn’t populating any classes. To fix that, we add the following, again at the top of the template:

html {% set title_classes = [ 'field__label', 'field__publish-date-label', label_display == 'visually_hidden' ? 'visually-hidden', ] %}

And update the div:

before: <div></div> after: <div ></div>

Rebuild the cache (drush cr) and… success! well sort of - we still have to add CSS. Note that we also added a custom class of 'field__publish-date-label' in case we want to style it directly.

Step 3: Add a THEMENAME.libraries.yml file to hold attachment library definitions.

This is pretty simple; it’s a file with the following:

blog: version: 1.x css: theme: css/blog.css: {} js: js/blog.js: {} dependencies: - core/jquery

We then add the directories (/css and /js) and files (blog.css/js). We’ve also added a jQuery dependency, just so you can see how that’s done. If we had something simple that could be done with Vanilla JS we could leave it off. Note that this won’t actually do anything until we follow step 4 below.

Step 4: Add a THEMENAME.theme file to hold theme hooks (this is actually a PHP file, so start it with <?php).

This is the code that appends the library based on the content type. The trickiest part of this is figuring out the correct format of hook_preprocess_HOOK():

function THEMENAME_preprocess_node__blog(&$variables) { $variables['#attached']['library'][] = 'THEMENAME/blog'; ]

The theme hook format for content types is to use node__MACHINENAME format - two underscores.

After that, rebuild your cache (drush cr), and your CSS and JS files should be loading on every instance of that content type, regardless of the page. (full or teaser)

And that’s it! Note that we could have changed the markup in any number of ways to suit our designs, or even make the template specific to the content type as well as the field.


The post was written at the end of 2015 while Drupal 8 was still in a Release Candidate stage. While some effort will be made to keep the post up-to-date, if it’s after 2016, you should probably add the current year to your Google search, or better yet, check the docs on Drupal.org.