Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 21 min 31 sec ago

OpenLucius: Protect your social intranet better | Two-factor authentication in your Drupal system

Thu, 31/03/2016 - 16:49

Probably you have heard about this before: ‘Two-factor authentication’. When you are a frequent user of Facebook, Twitter or LinkedIn you have quite likely seen it before; for sure you have been asked to provide your telephone number.

At first I was reluctant because then ‘they’ know all about you. But in the course of the time social media accounts have become very important, you don’t want a stranger to be able to hack into your account and steal your identity on Facebook, Twitter or LinkedIn.

Hence, I have now entered my phone number on these three social media. If I want to change my password, I will need to confirm this now through a verification code that is sent to my telephone number. A person with malicious intent usually does not know your number, so chances of hacking your account – by guessing and then changing your password – will be minimized.

Two-factor authentication of for example Facebook

This kind of extra security is called ‘two-step authentication’ / ‘two-factor authentication’. To take the example of Facebook: when logging in, the standard verification exists out of a username and password, something you ‘know’. The second step is authentication with something you ‘have’, such as a Smartphone, a fingerprint scanner, or a bank card reader.

This should not only be used to change passwords, but can also be used as an additional security when logging in to your social intranet:

Categories: Elsewhere

Valuebound: How to build your Drupal 8 theme using Bootstrap & Less

Thu, 31/03/2016 - 14:26

Bootstrap is a true blessing for web developers which is a sleek, intuitive and powerful mobile first front-end framework for faster and easier web development. When you mix that with LESS pre-processor you get a mighty tool for creating a Drupal 8 theme.

In this tutorial we will be looking into initiating your own custom theme using Drupal’s Bootstrap base theme. The Drupal Bootstrap base theme bridges the gap between Drupal and Bootstrap framework. Drupal 8 being relatively new, has very little documentation available to use Bootstrap, which now has a stable release for Drupal 8.

To spare you some frustration and as a source of resource for our staff, I've arranged an orderly guide for making your own sub-theme.

  1. Download, extract and place the Bootstrap…
Categories: Elsewhere

Jeff Geerling's Blog: Streaming PHP - disabling output buffering in PHP, Apache, Nginx, and Varnish

Thu, 31/03/2016 - 05:14

For the past few days, I've been diving deep into testing Drupal 8's experimental new BigPipe feature, which allows Drupal page requests for authenticated users to be streamed and loaded in stages—cached elements (usually the majority of a page) are loaded almost immediately, meaning the end user can interact with the main elements on the page very quickly, then other uncacheable elements are loaded in as Drupal is able to render them.

Here's a very quick demo of an extreme case, where a particular bit of content takes five seconds to load; BigPipe hugely improves the usability and perceived performance of the page by streaming the majority of the page content from cache immediately, then streaming the harder-to-generate parts as they become available (click to replay):

Categories: Elsewhere

Joachim's blog: The Lazy Maintainer's Handbook, Part 1: Frequent Releases

Thu, 31/03/2016 - 02:59

Every now and then I think about writing a series of posts called 'The Lazy Maintainer's Handbook', covering various aspects of how to maintain a project (or several) on without it being a huge burden on your time (which a lot of people, and companies, think is the case). However, I never get much past the pondering stage. Since it's safe to say that I'm never going to manage to come up with the right order to write these in, I'm just going to start in the middle. Here goes.

Like with all software, bugs are a problem in the world of Drupal. In Drupal contrib, like with any software that has releases, we can classify bugs into three types:

  • bugs which are reported, but have no fix,
  • bugs which have a fix, but the patch hasn't been committed,
  • bugs which have been fixed, but are not part of a release yet.

The first and second type can involve a fair amount of work, and I will cover in another post in the future how much a LM can or should do about them.

The third type though is where the LM can really shine: all that needs to be done here is to make a release. What could be simpler? And let's be clear, making a release is a very quick job. I can do the whole thing in about a minute (though I've not timed it, yet).

For one thing, if you're still writing the release notes by hand, then stop: Git Release Notes for Drush does that for you.

Here's my process:

  • $ git tag This lists all the existing tags, so I can see what the next release number should be.
  • $ git tag 7.x-1.2 This creates the tag for the new release.
  • At this point, it's a good idea to check this in a graphical git client, to check for stupid mistakes like making the tag on a local development branch, or the wrong major branch. (I've done that at least once.)
  • $ git push origin 7.x-1.2 This creates the tag on the remote repository.
  • $ drush release-notes This creates the release notes, using all the commit messages between the previous commit and the commit you just made. (Another reason to use the standard format for commit messages: it will turn the #12345 issue numbers into tags for to then render as links.)
  • Select the output from the command and copy it.
  • Go to your project's page on and click the 'Add new release' link.
  • Select the new tag.
  • Copy and paste the release notes.

I speed this up even more by having a bash alias for 'drush release-notes | pbcopy', which on OS X puts the text output by the Drush command onto the clipboard, so I can skip the selecting and copying step.

It's quick, right? Fun, even! Why don't maintainers do it more often? The reasons I can think of are:

  • the current branch HEAD (and thus -dev release) is unstable and badly broken
  • maintainers are worried about making releases too frequent and making site builders update all the time
  • maintainers have fallen prey to the 'just one more fix' syndrome, and are waiting for another issue (or issues) to be resolved.

Let's address these shall we?

The branch is unstable

This can happen when you're still on alpha releases, and something's caused you to take a new direction in development. This is a tough case: there's no going back, and you're stuck going forward. The only thing I would advise here is to look at the git history since the last release and see if there's a commit between then and now that could be tagged as the next alpha: for instance if the first few commits after the alpha were simple bug fixes. To try to prevent this problem, I recommend making a release immediately before you take a new direction in development, and if it's a very large rewrite, starting a new major branch, even if that means abandoning the 1.x branch at the alpha stage.

If a major rewrite happens and you're on beta releases or stable releases, then you're doing it wrong: a major rewrite should be cause to start a new major branch.

The last release was recent, and users may dislike frequent releases

Inspecting and testing new releases takes time. More importantly, perhaps, it has quite a high cognitive cost, as for each module you update, you need to review the release notes to look for any changes that might affect your site's functionality, and any parts of your site's codebase that make use of that module's code. It's also a bit stressful, because if something does break, it could be in a part of the site you don't think to check, so the first you'll hear of it is when your client or project manager calls in a panic two days later.

Understandably then, a lot of developers and site builders put off module updates, or don't bother with them until there's a security release.

This may be a time saving, but I don't believe it's an effort saving. Suppose you're on release 1.0 and releases 1.1 and then 1.2 come along. You can either upgrade to each one when it comes out, or you wait for 1.2 and then upgrade straight to that.

Doing two upgrades seems like more work, because you're only having to check the site once.

But I would counter that it's less overall cognitive load, because each single release has fewer changes. If releases are frequent, and include only up to a dozen or so commits, then it's easier to scan down the list of issues in the release notes, and maybe see that they're all very minor bug fixes, or clearly only affect functionality that your site doesn't use.

Ultimately, I don't think postponing upgrades pays off, because eventually, you'll have to bite the bullet and upgrade past several version numbers. Worse, you may have your hand forced when a security update comes along, and you'll be in the situation of having to read the release notes for all the versions you skipped and assessing them, while your site is on fire.

So I think small, frequent releases are actually a good thing, even from the point of view of existing users.

From the point of view of new users, they're a great thing: new users get better code, with fixed bugs. And that applies to existing users as well of course.

(A future episode in this series will cover an idea I've had for ages, of a metric for when you should do a release: after so many commits or weeks have passed.)

You're waiting for just one more fix

Don't. It might never come. In my experience, it probably won't. You'll think to yourself, 'just one more week and someone will review this patch', or 'I'll write a patch for this in the next week'. That week becomes two, and a month, and a year, and even more. I've seen comments on issues called 'Plan for a 1.0 release' where the maintainer says 'I'll make a release in the next two weeks' and that comment is over a year old. I saw one of those comments recently that was two years old. It was mine.

Fight the urge to wait for more fixes. Yes, you want your module to be good, even maybe perfect. But tell yourself: if you release now, you're still making it better. So here's what you need to do:

  • If you're still not on a stable release, release another alpha or beta. The real purpose of unstable releases should be to get people to test your code. You really want them to be testing something recent, not code that's six months old.
  • If you're on stable releases, just release another one. Those issues you were waiting for can go in the next release (or the one after…)

Hopefully that should assuage concerns regarding one's responsibility as a maintainer.

But as a lazy maintainer, what's the benefit to you?

  • Your recent fixes are out there and in use. A bug isn't truly eradicated until a release is made that includes the fix.
  • Fewer duplicate issues filed. With fewer bugs that are fixed in dev but not in a release, there's less chance of people encountering them.
  • More users, because the age of the most recent release is a metric people use when evaluating a module.
  • Users are using a more recent version of the code, which means newer bugs are more likely to get caught. (Because seriously, how many people are actually trying out the dev release, unless they're forced to by unreleased fixes?)

Get the code out. Dev code serves nobody. Releases are what matters.

Categories: Elsewhere

Chapter Three: Overriding Drupal 8 Configuration Values in settings.php

Wed, 30/03/2016 - 20:31

In previous versions of Drupal you would see values from settings.php on the coniguration pages. For instance $conf['mymodule_setting_value'] = 'My Value'; would display "My Value" in the text field and whenever you would try make a change to the field and try hit save button the value of the field would reset to the value specified in settings.php . However in Drupal 8 overridinen configuration form values in settings won't reflect in the form.

There is an issue on for that and developers already found a solution and it should be fixed in Drupal core soon.

Categories: Elsewhere

Doug Vann: Delivering Training On Drupal 8 Site Building And Pantheon Workflow At TexasCamp2016

Wed, 30/03/2016 - 19:24

It's 2016 and pretending like Drupal 8 doesn't exist is not an option. Which is why you will find me in Dallas this weekend spreading the love for Drupal 8! Almost 5 months out from its November 2015 launch it is gaining more traction and visibility at Drupal events.

I am still seeing many many many sites starting in Drupal 7 these days, but when I had the opportunity to provide a day of training at the inaugural TexasCamp, I knew what I had to do. I knew that many ppl would be showing up wanting to understand Site Building in the new world of Drupal 8. I also knew that the biggest game changer in D8 [IMO] is Configuration management. Therefore I HAD to cover that aspect of Drupal 8 and I had to do so WITHIN THE CONTEXT of Site Building.

This is not as far a departure from previous Drupal 7 trainings I have performed in dozens of camps, user groups, LinuxFests, and private clients. Where possible, I have always tried to bring in at least some element of DevOps into the training. With Drupal 8, there simply is no avoiding the topics of DevOps, multi-stage development, or call it what you will.

A Perfect pairing of Drupal 8 and Pantheon! I have always advocated that anyone testing Drupal 7 or Drupal 8 should whip up a quick, free, and easy Pantheon sandbox. For many years I have led many classrooms full of fresh minds through the process of building their first Drupal site on the Pantheon platform. Even though many attendees are beginners, they often come from companies who either have already invested a great deal into Drupal, or soon will. This is thanks largely to the "Ownership Society" that Drupal promotes. It will be exciting to see the response from my 1st full day of Drupal 8 training!

Drupal Planet

View the discussion thread.

Categories: Elsewhere

Drupal Association News: Two new board members for the Drupal Association

Wed, 30/03/2016 - 19:00

At the Drupal Association, we love to highlight that contribution comes in all forms. We are extremely grateful to the Association board members who contribute an enormous amount of time and are so generous with their knowledge and contacts in building a stronger Drupal community. Anyone who has ever served on or worked with a board knows that it's important, hard, and sometimes fun work. 

We're thrilled that two more folks are joining us on the board. Help us welcome them both:

Steve Francia, Class Director

Steve Francia was just nominated and elected to a Class Director seat on the board, a three year term. Steve Francia is a very active member of the open source community. He has been responsible for two of open source's largest projects as the Chief Operator of the Docker project and the Chief Developer Advocate of MongoDB, as well as creating some of the top community-based open source projects: Hugo, spf13-vim, Cobra and Viper. He has spoken all over the world delivering inspiring talks and workshops and has even organized a few conferences. He's written books for O'Reilly, blogs at and tweets as @spf13. He's used Drupal since Drupal 4. He lives outside NYC and enjoys having fun outdoors with his wife and four children.

Shyamala Rajaram, At-Large Director

Shyamala Rajaram is the newly elected At-Large Director. With over a decade of experience in designing and developing solutions using open source platforms, Shyamala has acquired a rich and varied expertise in many different technologies related to web, mobile and cloud. She is a co-founder and Director of Social Media Solutions at UniMity Solutions based in Chennai, India. Shyamala manages and builds the Drupal Solutions Practice at UniMity, including their hugely popular Drupal-based Social Workspace platform. Shyamala is an active participant in the Drupal community and has made contributions to the enhancements, usage and adoption of Drupal ( redesign and Drupal 8 Mobile initiative being the main ones). She is an Engineer from the Indian Institute of Technology, Madras—one of India’s premier technology institutions.

Categories: Elsewhere

Cheppers blog: Drupal Global Training Day 2016 Budapest

Wed, 30/03/2016 - 18:25

Global Training Days is an initiative of the Drupal Association organized quarterly in many cities around the globe. The event is a great opportunity to make the attendees familiar with the basics of Drupal, the content management system. The goal of the trainings is to introduce Drupal to a wide audience and teach the attendees 'how to Drupal' on an introductory training. 

Categories: Elsewhere

ImageX Media: ImageX Announces Two New Client Reviews on

Wed, 30/03/2016 - 17:29

ImageX is pleased to announce the submission of two new client reviews on, a research firm who reviews the top development, design, and marketing companies. ImageX chose to participate with Clutch’s research efforts in an effort to provide transparency to the marketplace, where both Clutch, as well as past and present ImageX clients, would have an opportunity to provide feedback, analysis and general assessments of our work and services.

Categories: Elsewhere

Dries Buytaert: Examples of how to make Drupal outside-in

Wed, 30/03/2016 - 16:58

The authoring experience improvements we made in Drupal 8 appear to be well-received, but that doesn't mean we are done. With semantic versioning in Drupal 8, we can now make more UX changes in follow-up releases of Drupal 8. So now is a good time to start moving Drupal's user experience forward.

The goal of this post is to advance the conversation we started over a month ago in a blog post called Turning Drupal outside-in. In this blog post, we'll show concrete examples of how we could make site building in Drupal easier by embracing the concept of outside-in. We hope to provide inspiration to designers, core contributors and module maintainers for how we can improve the user experience of Drupal 8.2 and beyond.

What is outside-in?

In Drupal you often have to build things from the ground up. If you want to make a list of events you need to wade through 20 different menu options to a user interface with configuration options like "boolean" and "float", build a content type, content, and then a view. Essentially you need to understand everything before you can build anything.

In an "outside-in" experience – or what Kevin OLeary (Director of Design, OCTO) calls Literal UI – you can click anything on the page, edit its configuration in-place, and watch it take effect immediately.

Over the past few years Drupal has adopted a more outside-in approach, the most obvious example being Drupal 8's in-place editing. It enables you to edit what you see with an uninterrupted workflow, faster preview, and removes the need to visit the administration backend before you can start editing.

To evaluate how outside-in can be applied more broadly in order to make Drupal easier to use, Kevin created a few animated gifs.

Example #1: editing menu items The current inside-out experience

Editing menu options in Drupal has already become more outside-in with contextual links. The contextual links take away some of the guesswork of finding the proper administration UI, but once you arrive at the configuration page there is still a lot of stuff to take in, only some of which is relevant to this task.

The current inside-out experience for editing a menu item: adding a menu link and changing its position involves 2 separate administration pages, 4 page refreshes and more than 400 words of text on the UI.

Anyone familiar with Drupal will recognize the pattern above; you go to an administration UI, make some changes, than you go back to the page to see if it worked. This context switching creates what UX people call "cognitive load". On an administration page you need to remember what was on the site page and vice-versa.

To complete this task you need to:

  1. Find the contextual link for the menu (not simple since it's on the far side of the page)
  2. Choose the correct option "edit menu"
  3. Find and click the "add link" button
  4. Type the menu link name
  5. Type the menu link path beginning with a forward slash
  6. Understand that this change needs to be saved
  7. Scroll to the bottom of the page
  8. Save the link
  9. Find the link in the list of links
  10. Understand that dragging up/down in this abstraction is equivalent to moving right/left in that actual page
  11. Scroll to the bottom of the page
  12. Save the menu

The problem is not just that there are too many pages, clicks, or words, it's that each step away from the actual page introduces new opportunities for confusion, error and repetition. In user testing, we have seen users who were unable to find the contextual link, or to understand which option to choose, or to find the "add link" button, or to add a path, or drag-drop links, or to save before leaving the UI. When these things happen in context feedback about whether you are "doing it right" is immediate.

The proposed outside-in experience

The proposed outside-in experience for editing a menu item. Rather than moving out-of-context to an administration page to get the job done, configuration happens right on the page where you see the effect of each action. You start adding a menu item simply by selecting the menu on the page. Both the menu item and the item's path are in focus to reinforce the connection. As you type a path is proposed from the link text.

Now all you need to do is:

  1. Click the menu on the page
  2. Find and click the "add link" button
  3. Type the name of the menu item
  4. Revise the menu item's path if needed
  5. Drag the link to its new location
  6. Close the drawer

One important aspect of this approach is that all actions that produce a visible change have bi-directional control and bi-directional feedback. In other words, if you can drag something in the configuration drawer you should also be able to drag it on the page, and the changes should happen simultaneously.

Example #2: adding a block to a page The current inside-out experience

The process of adding a block can be difficult. Once you discover where to go to add a block, which is in itself a challenge, the experience requires a lot of reading and learning, as well as trial and error.

The current inside-out experience for adding a block. Not all steps are shown.

To complete this task you need to:

  1. Figure out where to go to place a block
  2. Go to /block-layout
  3. Go to /display-regions to find out where the region is on the page
  4. Go back to /block-layout
  5. Find the region and click "add block"
  6. Find the block you want to place and click "place block"
  7. Configure the block
  8. Read about how blocks can appear on multiple pages and for different content types and roles
  9. Read what content types are
  10. Read what roles are
  11. Read what a "path" is
  12. Read how to find the path for a page
  13. Go back to the page and get its path
  14. Go back to /block-layout and add the path to the visibility settings
  15. Drag your block to the position where you want it
  16. If your blocks are arranged horizontally, learn that "up and down" in the block layout UI will mean "left and right" on the actual page
  17. Find the"back to site" link
  18. Go back to the page to see if you did it right

Eventually you'll use what you just learned, but Drupal makes you learn it first instead of just showing what is immediately necessary. Both the task and the learning can be simplified by bringing the configuration closer to the object you are configuring.

The proposed outside-in experience

The proposed outside-in experience for adding a block. Everything happens on the actual page rather than on an administration page. Places where things can be added appear on hover. On click they show thumbnails that you can filter with autocomplete.

Now all you need to do is:

  1. Choose where to place the block
  2. Find the block you want to place
  3. Place the block
  4. Close the drawer

The "plus" button, the drop target (blue dotted rectangle) and the autocomplete are all commonly understood patterns used by other software. The task requires no or little explanation as the interactions reveal the process. By starting with selecting the location of where to place the block, we avoid the need for drag-and-drop and the complexity of dragging a block on a page that requires scrolling.

Principles and patterns

These examples show the principle that rather than taking the site builder to a separate administration backend, the experience should begin with the actual page and show how the changes will be seen by the end-user. The patterns shown here are less important. For example the animated gifs above show two different approaches to the options panel and there are certainly others. The important thing is not yet where the panel comes from or how it looks, but that the following criteria are met:

  • An option panel is triggered by direct interaction.
  • When triggered it only shows options for what you selected.
  • It primarily shows configuration options that produce a visible change to the page. More complex options could be accessed through an 'Advanced options' link.

The ideas in this post are meant to provide some food for thought and become the seed of some patches for Drupal 8.2. Rather than dive right into development, we're looking to the Drupal community to take these designs as a starting point to prototype and user-test more outside-in experiences in Drupal.

The next post in this series will cover outside-in experiences with more complex contexts and the problem of "leaky abstractions". If you don't want to miss the next blog post, make sure to subscribe.

Special thanks to Kevin OLeary for advocating outside-in thinking. Thanks to Preston So, Gábor Hojtsy, Angie Byron, Bojhan Somers and Roy Scholten for their feedback.

Categories: Elsewhere

Four Kitchens: Meet Aquifer: A build system for easier Drupal development

Wed, 30/03/2016 - 16:36

Using a build system streamlines the development process, reduces errors in repetitive steps, and keeps the code repository lean and well organized. Aquifer—a command line interface that makes it easy to scaffold, build, test, and deploy your Drupal websites—has become a valuable part of the Four Kitchens development process. …

Categories: Elsewhere

Valuebound: How to write the custom Drush Commands in Drupal 8?

Wed, 30/03/2016 - 15:27

Writing custom drush commands in Drupal 8 is not exactly like Drupal 7 but it is similar. Here also, we are implementing hook_drush_command().   

The only difference is in the file structure.  As we all know In Drupal 8 ‘.module’ file is not mandatory in the module root folder. Hence In Drupal 8 for creating custom drush commands, we only need two files.


Where,description will be listed under Other commands: (custom_drush_command)

'description' => 'Echo the name you type with Say…

Categories: Elsewhere

Lullabot: Injecting services in your D8 plugins

Wed, 30/03/2016 - 09:51

Drupal 8's plugin system is one of the most flexible and widely used subsystems in Drupal. If you are a developer, chances that you will write plugins in Drupal 8 are high.

A couple of months ago I made a case in favor of unit tests in a series of articles. Today I have good news for you, your plugins are good candidates for testing! Before you get carried away by overexcitement, it's likely that your plugins depend on other parts of the system, and that complicates things a little bit. In these cases, it is a good idea to inject the services that include the dependencies you need. Dependency injection is an alternative to the static \Drupal::service. If you don't inject your services you will have a hard time writing unit tests for your plugin's code.

There are, at least, two widely spread patterns in Drupal 8 in order to inject services into your objects. The first uses a service to inject services. The second uses a factory method that receives Drupal's container. Both of these involve the dependency injection container, although you can still inject services using other manual techniques.

Injection via services

When you declare a new service you can also specify the new service’s dependencies by using the arguments property in the YAML file. You can even extend other services by using the parent property, having the effect of inheriting all the dependencies from that one. There is thorough documentation about writing services on The following example defines a service that receives the entity manager:

services: class: Drupal\my_modyle\Plugin\MyPluginManager arguments: ['@container.namespaces', '@cache.discovery', '@module_handler', '@entity.manager']

You cannot use this pattern directly to inject services to a plugin, since your plugin cannot be a service. This is because services are one-instance classes, a global object of sorts. Plugins are –by their definition– multiple configurable objects of a given class. However, the plugin manager is a great candidate to be a service. If you declare your plugin manager as a service, and inject other services to it, then you are only one step away from injecting those services into the actual plugin instances. To do so you only need to do something similar to:

class MyPluginManager extends DefaultPluginManager { protected $entityManager; … public function createInstance($plugin_id, array $configuration = array()) { $instance = parent::createInstance($plugin_id, $configuration); $instance->setEntityManager($this->entityManager); return $instance; } }

As you can see (aside from the lack of docblocks for brevity), every time that your plugin manager creates an instance of a plugin it will set the entity manager for that particular instance. in this scenario you only need to write setEntityManager in your plugin. This strategy is a mix of service injection and setter injection.

Factory injection

The other big injection pattern in Drupal 8 involves adding all your dependencies as arguments in the constructor for your class (also known as the constructor injection pattern). This pattern is very straightforward, you just pass in all the dependencies upon object creation. The problem arises for objects that Drupal instantiates for you, meaning that you don't get to do new MyClass($service1, $service2, ...). How do you pass the services to the constructor then? There is a convention in the Drupal community to use a factory method called create. To implement it you need to write create static method that will receive the dependency injection container as the first parameter. The create method should use the container to extract the services from it, and then call the constructor. This looks like:

class MyOtherClass { … public function __construct($service1, $service2, ...) { // Store the services in class properties. } public static function create(ContainerInterface $container) { // new static() means "Call the constructor of the current class". // Check PHP’s late static binding. return new static( $container.get('service1'), $container.get('service2'), … ); } }

There is the remaining question of "who calls the create method with the container as the first parameter?". If Drupal is instantiating that object for you, then the system should know about the _create method pattern_ for that particular object.

The default plugin manager (\Drupal\Core\Plugin\DefaultPluginManager) will use the container factory (\Drupal\Core\Plugin\Factory\ContainerFactory) to create your plugin objects. It is very likely that your new plugin manager extends from the default plugin manager –via code scaffolding or manual creation–. That means that by default if you add a create method to your plugin, it will be ignored. In order to have your new plugin manager use the create pattern, the only thing your plugins need is to implement the ContainerFactoryPluginInterface. In that case your plugin will look like:

class MyPluginBase extends PluginBase implements PluginInspectionInterface, ContainerFactoryPluginInterface { protected $entityManager; … public function __construct(array $configuration, $plugin_id, $plugin_definition, EntityManagerInterface $entity_manager) { parent::__construct($configuration, $plugin_id, $plugin_definition); $this->entityManager = $entity_manager; } public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) { return new static( $configuration, $plugin_id, $plugin_definition, $container->get('entity.manager') ); } }

The plugin manager will detect that the object that it's about to create implements that interface and will call the create method instead of the basic constructor.

The plugin system is so extensible that you may run into corners where those techniques are not enough. Just know that there are other ways to achieve this. Some of those, for instance, involve using a different factory in the plugin manager, but that is out of the scope of this article.

Sometimes the create factory method pattern can be considered a bit more robust, since it does not involve injecting the services to an object that doesn't need them –the plugin manager– only to pass them down to the plugin. Regardless of the approach that you use, you are now in a good position to start writing unit tests for your plugin class.

Categories: Elsewhere

Unimity Solutions Drupal Blog: Elected to Board of Drupal Association

Wed, 30/03/2016 - 09:16

Excited to share I have been elected to the Board of Drupal Association, The support and campaigning of all my friends and well-wishers and the Drupal community has helped me get to this prestigious post! Thanks all for your confidence in me! Looking forward to my contributions to Drupal in this new role.

Categories: Elsewhere Docker and Travis-CI

Tue, 29/03/2016 - 23:00

If you have ever had to setup Travis-CI, I'm sure you know where the biggest pain point is - debugging the machine.

We have lost so many hours on intermediate commits, waiting for Travis to spin up a new box, run the scripts only to see it fail on the last command. Not to mention how hard it is to debug a webapp on a machine you don't have direct access to, and there is no browser.

But there's a new and better way - we can use Docker inside Travis.

What does that mean? In short, it means that setting up Travis, and debugging your test scripts has just become much easier. You can do all the setup, and the debugging from your own local computer!

Behat tests running from within the container

Continue reading…

Categories: Elsewhere

Web Wash: Lightning Talk: Page Manager and Panels in Drupal 8

Tue, 29/03/2016 - 21:34

At March's Sydney Drupal user group, I did a lightning talk on Page Manager and Panels in Drupal 8. In the talk, I demonstrate both modules and show you how to create a custom homepage with a few clicks. You can watch the whole talk in the video above.

Panels in Drupal 8 has changed considerably. The UI for building pages is now offered by Page Manager, with Page Manager UI installed, and not Panels itself. The UI also changed, but I think it's much easier to use than in Drupal 7, but that's my opinion.

Categories: Elsewhere

Annertech: Decoupling Features (so your support time sleeps easier at night)

Tue, 29/03/2016 - 21:31
Decoupling Features (so your support time sleeps easier at night)

You're working on a client's existing site, and they ask for some new functionality. Your first thoughts are: "Yay, some work!" Quickly following that you think: "What do they want? How am I going to build it?" The often unasked question, however, is "How can I integrate this new functionality with what they already have, without making maintenance a nightmare, or even worse, impacting existing functionality?"

This is a tough ask, as the new feature has the potential to reach across multiple pages, content types and styles.

Categories: Elsewhere

Four Kitchens: Trip Report: MidCamp 2016

Tue, 29/03/2016 - 20:15

MidCamp 2016 was just over a week ago in Chicago. For those unfortunate folks who couldn’t make it to the Second City, here are some highlights. …

Categories: Elsewhere

Acquia Developer Center Blog: Drupal 8 Module of the Week: Search API

Tue, 29/03/2016 - 19:58

Each day, more Drupal 7 modules are being migrated to Drupal 8 and new ones are being created for the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some of the most prominent, useful modules, projects, and tools available for Drupal 8. This week: Search API.

Tags: acquia drupal planetsearchapache solracquia searchSearch API
Categories: Elsewhere

Drupal core announcements: Drupal 8.1.0-rc1 on April 6 and what it means for 8.0.x

Tue, 29/03/2016 - 19:35
Start:  2016-04-05 12:00 - 2016-04-07 12:00 UTC Organizers:  xjm catch Event type:  Online meeting (eg. IRC meeting)

Drupal has adopted semantic versioning and a scheduled release cycle starting with Drupal 8.0.0. This means that it is possible within a major Drupal version to add new functionality in a backwards-compatible way, and there is no need to wait for Drupal 9 for improvements. The first such version, Drupal 8.1.0, is going to be released on April 20th 2016, including such improvements as the experimental Drupal Upgrade UI module (for migrating from Drupal 6 and 7) and the BigPipe module (to enhance perceived site performance).

To prepare for Drupal 8.1.0, we released two beta versions in March. Announcements for beta1 and beta2 detail the significant changes made since Drupal 8.1.0. Now, we are ready to create Drupal 8.1.0-RC1, the first release candidate, on April 6, 2016. This means several things in terms of support for Drupal 8.0.x versions and allowed patches in Drupal 8.1.x:

  • Starting April 6, the 8.1.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.
  • To ensure a stable and timely release candidate, a commit freeze for the 8.1.x branch will begin April 5 at 12:00 UTC.
  • April 6 is also the final scheduled patch release window for 8.0.x, and it will not receive further development or support after that date aside from its final security release window on April 20 (which will not include bug fixes). Site owners and module or theme authors should prepare to update to 8.1.x.
  • As a consequence, all outstanding issues filed against 8.0.x will be automatically migrated to 8.1.x after the final 8.0.x patch release. Future bug reports should be targeted against the 8.1.x branch.
  • 8.2.x will remain open for new development during the 8.1.x release candidate phase.

See the Drupal core release cycle overview, Allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Minor versions like Drupal 8.1.0 may include changes to user interfaces, translatable strings, themes, internal APIs like render arrays and controllers, etc. (See the Drupal 8 backwards compatibility and internal API policy for details.) Developers and site owners should test the release candidate to prepare for these changes.

Categories: Elsewhere