Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 9 hours 2 min ago

PreviousNext: Safely extending Drupal 8 plugin classes without fear of constructor changes

Thu, 11/02/2017 - 22:34
Share:

From time to time you may find you need to extend another module's plugins to add new functionality.

You may also find you need to alter the signature of the constructor in order to inject additional dependencies.

However plugin constructors are considered internal in Drupal's BC policy.

So how do you safely do this without introducing the risk of breakage if things change.

In this article we'll show you a quick trick learned from Search API module to avoid this issue.

by Lee Rowlands / 3 November 2017

So let's consider a plugin constructor that has some arguments.

Here's the constructor and factory method for Migrate's SQL map plugin

/**
   * Constructs an SQL object.
   *
   * Sets up the tables and builds the maps,
   *
   * @param array $configuration
   *   The configuration.
   * @param string $plugin_id
   *   The plugin ID for the migration process to do.
   * @param mixed $plugin_definition
   *   The configuration for the plugin.
   * @param \Drupal\migrate\Plugin\MigrationInterface $migration
   *   The migration to do.
   */
  public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration, EventDispatcherInterface $event_dispatcher) {
    parent::__construct($configuration, $plugin_id, $plugin_definition);
    $this->migration = $migration;
    $this->eventDispatcher = $event_dispatcher;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration = NULL) {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $migration,
      $container->get('event_dispatcher')
    );
  }

As you can see, there are two additional dependencies injected beyond the standard plugin constructor arguments - the event dispatcher and the migration.

Now if you subclass this and extend the constructor and factory to inject additional arguments, should the base plugin change its constructor, you're going to be in trouble.

Instead, you can use this approach that Search API takes - leave the constructor as is (don't override it) and use setter injection for the new dependencies.

/**    * {@inheritdoc}    */   public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration = NULL) {     $instance = parent::create(       $container,       $configuration, $plugin_id,       $plugin_definition,       $migration     ); $instance->setFooMeddler($container->get('foo.meddler'); return $instance;   } /** * Sets foo meddler. */ public function setFooMeddler(FooMeddlerInterface $fooMeddler) { $this->fooMeddler = $fooMeddler; }

Because the signature of the parent create method is enforced by the public API of \Drupal\Core\Plugin\ContainerFactoryPluginInterface you're guaranteed that it won't change.

Thanks to Thomas Seidl for this pattern

Tagged Drupal 8, Plugins, OOP

Posted by Lee Rowlands
Senior Drupal Developer

Dated 3 November 2017

Comments

Comment by dawehner

Dated 3 November 2017

Nice!! Thank you for sharing it!

Pagination Add new comment

Drop Guard: Automatic updates - a study by the University of North Carolina State

Thu, 11/02/2017 - 11:45
Automatic updates - a study by the University of North Carolina State

A study from the North Carolina State University discovered that projects which are using open source libraries are updated 60% more often when using automatic updates via pull requests. The base of the study are 7,470 repositories on GitHub. This blog post is a summary of the most important facts and highlights of the methods, challenges and tools when it comes to use of automation for reaching a higher security level while using open source libraries.

There are 3 main facts why open source updates are a pain for developers
  1. Developers are always busy and doing updates is no fun

Drupal Planet Business Events Security PHP Study

Web Omelette: My First Book - Drupal 8 Module Development (Or Where I Have Been Lately)

Thu, 11/02/2017 - 07:01

If you’ve been wondering where I’ve been and why I haven’t been writing any articles lately, I am here to put your mind at ease: i’ve been working heavily on my first book about Drupal, called Drupal 8 Module Development. And I am happy to announce that it has finally been published and available for purchase.

Released by Packt Publishing, a leading publishing house for technical books in the Open Source world, my book is a comprehensive guide for developers new to Drupal 8. It aims to introduce you to module development starting from scratch but building up to complex functionalities. In doing so, you learn about all the fundamental subsystems and APIs available to work with in your Drupal module.

As you know, my website mainly focuses on Drupal knowledge via articles about tips and techniques, especially in Drupal 8 (most recently). So if you’ve been finding these helpful, I recommend checking out my book as it contains about 500 pages of great content aiming to help you ramp up your Drupal 8 module development skills. I appreciate each and every one who decides to give it a chance and I hope you find it as useful as I intended it to be.

Here is the list of chapters that will take you on the journey from starting a simple module to writing performant functionality using complex subsystems and APIs:

  • Chapter 1,  Developing for Drupal 8 , provides an introduction to module development in Drupal 8. In doing so, it introduces the reader to the various subsystems and outlines the requirements for running a Drupal 8 application.
  • Chapter 2,  Creating Your First Module , gets the ball rolling by creating the first Drupal 8 module of the book. Its main focus is to explore the most common things module developers need to know from the get-go.
  • Chapter 3,  Logging and Mailing , is about the tools available for doing something every web- based application does and/or should be doing, that is, sending emails and logging events.
  • Chapter 4,  Theming , presents the theme system from a module developer's perspective in Drupal 8.
  • Chapter 5,  Menus and Menu Links , explores the world of menus in Drupal 8 and shows how to programmatically create and work with menu links.
  • Chapter 6,  ata Modeling and Storage , looks at the various types of storage available in Drupal 8, from the state system to configuration and entities.
  • Chapter 7,  Your Own Custom Entity and Plugin Types , takes a hands-on approach creating a custom configuration and content entity type, as well as custom plugin type to wire up a practical functional example.
  • Chapter 8,  The Database API , presents the database abstraction layer and how we can work directly with data stored in custom tables.
  • Chapter 9,  Custom Fields , exemplifies the creation of the three plugins necessary for creating a custom field that can be used on a Drupal 8 content entity type.
  • Chapter 10,  Access Control , explores the world of access restrictions in Drupal 8, from roles and permissions to route and entity access checks.
  • Chapter 11,  Caching , looks at the various cache mechanisms available for module developers to improve the performance of their functionality.
  • Chapter 12,  Javascript and the AJAX API , introduces module developers to the specificities of writing JavaScript in Drupal 8, as well as the powerful AJAX system, which can be used to build advanced interactions.
  • Chapter 13,  Internationalization and Languages , deals with the practices Drupal 8 module developers need to observe in order to ensure that the application can be properly translated.
  • Chapter 14,  Batches, Queues, and Cron , explores the various ways module developers can structure their data processing tasks in a reliable way.
  • Chapter 15,  Views , looks at the various ways module developers can programmatically interact with Views and even expose their own data to them.
  • Chapter 16,  Working with Files and Images , explores the various file and image APIs that allow module developers to store, track, and manage files in Drupal 8.
  • Chapter 17,  Automated Testing , explores the various types of automated test module developers can write for their Drupal 8 applications to ensure stable and resilient code.
  • Annex, Drupal 8 Security , recaps some of the main things module developers need to pay attention to for writing secure code in Drupal 8.

If you find something incorrect or out of place, please use the appropriate errata submission form mentioned in the book. And as always, feel free to drop comments below about the your thoughts on the book. Enjoy and thank you very much for purchasing my book!

Hook 42: October Accessibility (A11Y) Talks

Thu, 11/02/2017 - 01:18

This month we had Nicolas Steenhout joining us to talk about "Accessibility: Don't turn off that JavaScript just yet."

The year is 2017, and JavaScript has never been as ubiquitous. Long gone are the days when in order to be considered accessible, pages had to work flawlessly without scripting. Scripting has also come a long way, and developers are now even leveraging the powers of JavaScript to rewrite content in order to make it more accessible to assistive technologies.

Nextide Blog: Maestro D8 Concepts Part 4: Interactive Task Edit Options

Thu, 11/02/2017 - 01:04

This is part 4 of the Maestro for Drupal 8 blog series, defining and documenting the various aspects of the Maestro workflow engine.  Please see Part 1 for information on Maestro's Templates and Tasks, Part 2 for the Maestro's workflow engine internals and Part 3 for information on how Maestro handles logical loopback scenarios.

Freelock : Freelock Interviewed on Drupal and WordPress Expertise

Wed, 11/01/2017 - 23:42
microphone-with-screen-with-chart.jpg

In September, Freelock was recognized as a leading web development company in Seattle by Clutch. Not only were we thrilled to be featured in that report and ranked as one of the top three web developers in the area, but we are excited to share that as a result, Clutch interviewed us on our web development expertise.

Drupal PlanetSecurityDrupalWordPressDrupal 8CMS

myDropWizard.com: Drupal 6 security update for Autologout 6.x-4.x

Wed, 11/01/2017 - 20:16

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Autologout module to fix a Cross Site Scripting (XSS) vulnerability.

This module provides a site administrator the ability to log users out after a specified time of inactivity.

The module does not sufficiently filter user-supplied text that is shown when logging a user out. This vulnerability is mitigated by the fact that an attacker must have a role with the permission "administer autologout".

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

NOTE: This only affects the Autologout 6.x-4.x branch -- the 6.x-2.x branch (which we also support) isn't vulnerable.

If you have a Drupal 6 site using the Autologout module, we recommend you update immediately.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Commerce Guys: Commerce Braintree integration adds PayPal Express Checkout and PayPal Credit support

Wed, 11/01/2017 - 18:13

Drupal Commerce is more than just a module project. As I laid out in my session at DrupalCon Vienna, it is an entire ecosystem supported by dozens of agencies and powering well over $1.5bn in online transactions annually. This makes Drupal Commerce one of the largest open source eCommerce projects in the world, and it's thanks in no small part to our Technology Partners (comprised primarily of payment providers) that we are able to invest as much of our time in it as we do.

Braintree is one such partner and a fantastic supporter of Commerce 2.x since last Summer. During our sprint to release a beta at DrupalCon Dublin, they sponsored Bojan's time for two weeks to expand and improve the core Payment API.

As a result, they also became the first integrated payment gateway and the test case for any payment provider following their integration pattern - individual iframes embedded into the checkout form for each payment field, making it easy to securely collect payment card data through your own checkout form.

For the initial release of the Commerce Braintree integration on Drupal 8, we targeted basic credit card payment support via their Hosted Fields API. As of this week, we've finalized patches that add support for PayPal Express Checkout and PayPal Credit alongside credit card payment through Braintree. They are a PayPal company, after all!


Customers can pay via credit card on-site or Express Checkout via a modal dialog.

You can test the new features end to end by grabbing the latest release of the Commerce Braintree module and configuring it to work through the Braintree sandbox. If you get stuck, you can find us in the #commerce channel in the Drupal Slack or open an issue in the queue if that's not possible.

Thanks again to Braintree for their support and development sponsorship. If you'd like to learn more about how Technology Partners benefit our ecosystem, consider joining me and Commerce Braintree's D7 co-maintainer Andy Giles this weekend at DrupalCamp Atlanta (Nov. 3-4). I'll present a longer version of my DrupalCon session, Marketing and Selling the Drupal Commerce Ecosystem, and naturally I'll tap Andy to help me answer all your hardest questions. ; )

Acro Media: Video: What to Expect Now That Drupal Commerce 2.0 is Live

Wed, 11/01/2017 - 15:12


Lots of live Commerce 2 sites were actively and successfully selling products to people long before the official launch on September 20th. We ourselves were among the early adopters taking advantage of the new functionality available in Drupal 8. But as with any new-and-not-fully-tested technology, there were the inevitable growing pains: missing functionality, bugs, etc. Fortunately, most of those issues are now in the past.

A few core modules that were buggy but are solid now:

  • Promotions and coupons
  • Taxes
  • Payments (supports 30+ payment gateways!)
  • Products
  • Orders

As an added bonus, the Commerce Shipping module that Acro Media helped develop received a full stable release alongside Commerce 2 (which is especially cool when you remember that Commerce 1 launched with no shipping functionality at all). Commerce Shipping features a much improved API and includes support for UPS and FedEx, with USPS to follow shortly.

Acro Media and other community members have been working on a few other associated modules to go along with the Commerce 2 launch. Here are the details:

  • Point of Sale is going to alpha release
  • Commerce Migrate is going to have a new release (likely not a stable release, however, as there is still work to be done migrating edge cases)

    Ubercart to Commerce 2 migrate is mostly done and includes all core stuff like products, customers, orders, taxes, etc.

    Commerce 1 to Commerce 2 migrate is a little rough but is still very usable; an improved version should be ready in October sometime

A cool new Composer based Commerce Kickstart installer is also available! It represents a great improvement over the original Commerce Kickstart and should be easier for everyone to use. You can find that here.

TLDR: The fully supported, stable release of Commerce 2 is live and has lots of cool stuff with it. If you were hesitant to use it to build sites before, you most certainly can go ahead now.

OSTraining: Using the Focal Point Module for Images in Drupal 8

Wed, 11/01/2017 - 14:24

You most likely created image styles with Drupal's "Scale and crop" image effect. This style allows you to display large images on a smaller scale and save precious screen space.

There is one issue with such styling though. Often the most interesting point of the image gets chopped off. The "Focal Point" contrib module helps avoid this issue.

In this tutorial, you will learn to use this module to select the most important portion of the image you would like to show to your readers. 

ADCI Solutions: Visual regression testing for Drupal using Gemini

Wed, 11/01/2017 - 11:00

Testing a lot of pages after small changes in CSS files - again and again... Looks familiar? Gemini gets you rid of this waste of time. We will show you how to write Gemini tests and extend this tool.

 

Learn about visual regression testing for Drupal

 

Drupal Modules: The One Percent: Drupal Modules: The One Percent —Multiple Registration (video tutorial)

Wed, 11/01/2017 - 02:16
Drupal Modules: The One Percent —Multiple Registration (video tutorial) NonProfit Tue, 10/31/2017 - 21:16 Episode 42

Here is where we seek to bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Multiple Registration, a module which gives you the ability to create role-specific registration pages.

Agiledrop.com Blog: AGILEDROP: 5 sessions about project management from DrupalCon Vienna

Wed, 11/01/2017 - 01:20
In case you have missed some of the Drupalcon Vienna’ session about project management, here they are.    A new Approach for Improving Estimations with Content Discovery Workshops Richard Jones, CTO at Inviqa   The research process connects the client and all participants with each other so that all things are clarified before they start working on a project. In this process, teams plan how they will fulfill the client's requirements. However, it can quickly happen to overestimate the performance of the system, so the assessment is not accurate enough. In this session, a workshop… READ MORE

Erik Erskine: When your composer build breaks

Wed, 11/01/2017 - 00:00

Yesterday a project on github was moved, causing Drupal's own build process, and that of many other websites, to “break”. Here's what happened:

  1. The coder library was removed from github (it's main home is on drupal.org).
  2. Drupal core's composer.json had a reference to the now non-existent repository.
  3. Anyone attempting to obtain Drupal by downloading it's source and running composer install couldn't.
  4. Many other developers who tried to build their websites were similarly left disappointed.

This seems to be a risk that comes with dependency management, and raises the question of should vendor be committed to version control? I'm hoping that this post will help you answer that.

Read more

Aten Design Group: Drupal's Upgrade Path and the Product Approach

Tue, 10/31/2017 - 18:46

Here at Aten, we do a lot of work with Drupal, mostly on large redesign projects for nonprofits and universities. We’ve been in the business for a while now (since 2000), and one thing we’ve been talking about for years is the predicament of “buy-maintain-replace” release cycles. Specifically, website redesigns often fall prey to a problematic purchasing cycle that directly counteracts strategic goals.

It goes like this: first there’s a capital campaign, then a big spike in funding to do a redesign project, followed by modest support budget for a few years. During support, things everyone would like to change start to pile up, often beginning as a “backlog” or “wish list,” inevitably becoming a “gripe list” for all the things that are slowly and surely making your website obsolete. Time passes and the gripe list grows. We hear things like, “Our current website is horribly outdated; it isn’t even responsive.” Rather than invest in old technology and continue addressing the growing list of issues, tasks are pushed off for a future redesign. Eventually, there is a new capital campaign. The cycle starts over, rinse and repeat.

If you’re coming from a product background and you’re programmed to value ongoing development and continuous innovation, this already sounds bad. But if you’re from traditional IT management, you might think of redesigns more like purchasing any other technology solution. You buy it, it gets old, you replace it – often with some form of ongoing support between major expenditures. The smaller the support requirement, the more successful the project. Likewise the longer you can go without upgrading, the more successful the project.

The trouble is, your website, app, etc. doesn’t really work that way. Your website shouldn’t just be checking boxes on functionality requirements the way your phone system or workstations do; rather, your website is the public face and voice of your organization. It needs to keep up and tell your story clearly, every day. It needs to evolve as quickly as your organization does. And that requires ongoing investment. More than that, it requires a fundamental shift in the way decision makers think about planning digital projects.

There’s already a ton of fantastic material about the need to adopt a product approach over the more traditional project mindset. One of my favorite posts on the subject was written back in 2015 by the team at Greenpeace titled, “Product teams: The next wave of digital for NGOs?” I especially love this infographic. The illustration is spot on: first, a huge spike in money and time with a brief climax at launch, followed by diminished investment during a prolonged support period with equally diminished satisfaction, all to be repeated over and over again.

Interestingly, this problematic “buy-maintain-replace” cycle actually aligned closely with the release cycle for previous versions of Drupal. For years, timing for the “buy” stage in the cycle aligned surprisingly well with the stable release for major Drupal versions. First, you built a website on Drupal 4. Support phase ensued. Over a few years wish lists turned to gripe lists. Momentum grew behind doing the next major redesign, right on time for the stable release of Drupal 5. Rinse. Drupal 6. Repeat. Drupal 7.

While we were talking more and more about a product approach, the technology actually lent itself to the project mindset. Quick example: retainers are a big part of our business at Aten, and have been important for helping us support clients in the product approach. With retainers, clients invest consistently in their digital platforms over the long term. We identify strategic priorities together, maintain a backlog, organize sprints and deploy iterative releases. But with past versions of Drupal, an organization still needed to invest heavily for major release upgrades. At some point in the cycle, there were diminishing returns associated with ongoing investment in an outdated system. We started prioritizing tasks based on the fact that a large redesign was looming. We said things like, “Let’s just wait on Drupal 7 for that.” In many ways the underlying platform was promoting a “buy-maintain-replace” development cycle. The product approach was still valuable, but hampered by inevitable obsoletion of the technology.

Enter Drupal 8.

With Drupal 8, there’s a lot to be excited about: configuration management, component-based theming, improved performance, content moderation, modernized development tools, support for API-first architecture, and the list goes on. But I want to focus for a minute on Drupal’s release cycle.

Drupal’s vastly improved upgrade path is a huge win for the platform and a major reason organizations should consider migrating to Drupal 8 sooner rather than later.

With past versions of Drupal, major release upgrades (i.e. D6 to D7) required a significant development effort and usually constituted a major technology project. As I’ve touched on already, upgrades would typically coincide with a complete redesign (again, buy-maintain-replace).

With Drupal 8 the release cycle is changing. The short, non-technical version is this: Drupal 8 will eventually become Drupal 9. If you stay up-to-date with underlying changes to the platform as it evolves, upgrading from 8 to 9 should be relatively simple. It’s just another release in your ongoing development cycle.

With Drupal 8, an organization can invest consistently in its digital platform without the problem of diminishing returns. As long as you adopt the product approach, your platform won’t become outdated. And that’s fantastic, because the product approach is what we’re all going for – right?

Resources and Related Reading:

Elevated Third: Release Notes, Translated: Drupal 8.4

Tue, 10/31/2017 - 18:01
Release Notes, Translated: Drupal 8.4 Release Notes, Translated: Drupal 8.4 Nick Switzer Tue, 10/31/2017 - 12:01

Drupal 8.4 is here! The most current minor release of Drupal 8 officially came out on October 4. This release contains lots of changes that push Drupal 8 forward in some big ways, but what are those changes and what do they mean to you?

The changes introduced in Drupal 8.4 affect everyone from Drupal developers to content administrators and site owners. I’ve broken things down into four categories, and we’ll cover the high points of each one. If you’re interested in really digging into the details, check out the full release notes available on drupal.org.

Security

The initial release of Drupal 8.4 doesn’t contain any major security updates that make it a mandatory update in the hours, or days, immediately after release. That being said, this is still an update that is critical for site security because as soon as a new minor release of Drupal comes out, security issues in previous minor releases are no longer patched.

I recommend updating to Drupal 8.4 as soon as possible because there is always a chance of a critical security release. You don’t want to get stuck dealing with the complexities of updating from Drupal 8.3 to 8.4 when you’re also racing the clock that starts ticking when a security vulnerability is made public.

Browser Support

Drupal 8.4 made some major updates to the versions of Internet Explorer that are supported out of the box. Previously, Drupal supported Internet Explorer 9 and up. Since Microsoft discontinued all support for Internet Explorer 9 and 10 in April of this year, Drupal has followed suit and will only be supporting Internet Explorer 11 moving forward.

No need to panic yet though - your site won’t cease to function in Internet Explorer 9 and 10 as soon as the 8.4 update is implemented, but bugs related to those browsers will no longer be fixed. Starting in Drupal 8.5, which is currently scheduled for release in March of 2018, existing workarounds for these browsers will be removed. This will impact every site differently, depending on how much support your frontend provides for these older browsers, so start talking to your developer now about the best approach for your site.

New and Updated Features

Drupal 8 introduced the idea of experimental modules in core. These are modules the Drupal core team has decided provide valuable functionality and should be included in core but still need testing. Many of them can be used in production releases without any issues, but, until they are officially declared stable core modules in a minor release, there may be breaking changes or non-existent upgrade paths as new minor releases of Drupal come out.

Quite a few notable modules were moved from experimental to stable status in Drupal 8.4, so I’ll provide a quick rundown here.

Datetime Range - Dates are challenging for web developers. Especially when you start dealing with things like ranges and events that span time zones. The Datetime Range module is another great tool in the Drupal developer’s toolbox. The module makes managing date and time ranges and integrating them with other parts of Drupal, much simpler.

Layout Discovery - There isn’t much to see on the frontend with this module, but it’s a really big step forward for Drupal core because standardized layout systems have never been possible with Drupal in the past. This module sets the groundwork for a common layout system across core and contributed modules.

Media - Finally! Media in Drupal core! This is a huge addition and one that will affect the team at Elevated Third in a big way because we have leveraged the contributed Media suite of modules very heavily thanks to its ability to provide a centralized media library that makes media management a breeze for content admins. Transitioning from the contributed Media module to the core Media module will bring it’s own set of challenges, but the good news is that transition does not have to happen immediately.

Inline Form Errors - This is a great little module we’ve used on quite a few sites to make the admin experience better. With Inline Form Errors, we’re able to quickly implement a system for providing users feedback when they fail to complete the necessary actions in a form.

Workflows - This is another piece of functionality lots of Drupal users have been craving. In the past, our team has leveraged the Workbench suite of modules to provide content workflow capability, but now, with Workflows in core, we have the groundwork for providing more advanced content administration experiences without the need for additional contributed modules.

Behind the Scenes/Developer Tools

In addition to everything we’ve already walked through, Drupal 8.4 implemented some major changes under the hood that are worth knowing about. These changes most directly affect developers but impact anyone involved in the Drupal ecosystem because they significantly increase the complexity of this update over previous Drupal core updates.

Symfony updated from 2.8 to 3.2 - When Drupal 8 was released, you probably heard a lot about Drupal “getting off the island” and embracing the standards and practices of the larger PHP development community. Incorporating Symfony into Drupal core made this transition much simpler than it would have been to write all of the required backend components from scratch. Symfony is a PHP framework that provides a huge amount of functionality to Drupal under the hood. Just like Drupal, Symfony also has major releases, and Drupal needs to be sure it’s leveraging the latest and greatest from Symfony. This kind of update won’t often happen because Symfony releases major versions every two years. When a Drupal minor release does incorporate a major Symfony version update, the complexity of the update does increase.

jQuery updated to 3.0 - jQuery is an extremely common Javascript library that has been packaged with Drupal core for a long time. One of the problems with previous major releases of Drupal is that they would get stuck running really old versions of jQuery because Drupal core did not have a minor release system that allowed these kinds of updates. Until this release, Drupal included jQuery 2.x, which will not be receiving feature updates anymore. This update might break some frontend functionality, but leverages the latest and greatest jQuery has to offer.

Drush support - Drush is a command line tool a huge number of Drupal developers leverage to make day-to-day development work much more efficient and easier to manage. It is an invaluable tool for our development team here at Elevated Third. With Drupal 8.4, Drush version requirements were increased, so our team found that we needed to upgrade our tools, in addition to Drupal core. This requires careful planning to be sure everything plays nicely during the update process, and after the updates have been applied.

What happens next?

The Drupal core release cycle works around minor releases every six months. The next expected minor release is Drupal 8.5, in March of 2018. Between now and then, there will likely be multiple patch releases that will introduce bug fixes and security updates, which will be much simpler updates and should be applied as soon as they are released.

Minor release updates introduce more complexity than the Drupal world has ever seen for updates within a major release, but the tradeoff is that when Drupal 9 comes out, you won’t have to completely rebuild!

Stay tuned for my next post detailing the Drupal 8 release cycle, where I’ll dig more into how this works, why and when you should update and what we can expect for the future of Drupal.

Dries Buytaert: Acquia Engage 2017 keynote

Tue, 10/31/2017 - 15:29

This October, Acquia welcomed over 650 people to the fourth annual Acquia Engage conference. In my opening keynote, I talked about the evolution of Acquia's product strategy and the move from building websites to creating customer journeys. You can watch a recording of my keynote (30 minutes) or download a copy of my slides (54 MB).

I shared that a number of new technology trends have emerged, such as conversational interfaces, beacons, augmented reality, artificial intelligence and more. These trends give organizations the opportunity to re-imagine their customer experience. Existing customer experiences can be leapfrogged by taking advantage of more channels and more data (e.g. be more intelligent, be more personalized, and be more contextualized).

I gave an example of this in a blog post last week, which showed how augmented reality can improve the shopping experience and help customers make better choices. It's just one example of how these new technologies advance existing customer experiences and move our industry from website management to customer journey management.

This is actually good news for Drupal as organizations will have to create and manage even more content. This content will need to be optimized for different channels and audience segments. However, it puts more emphasis on content modeling, content workflows, media management and web service integrations.

I believe that the transition from web content management to data-driven customer journeys is full of opportunity, and it has become clear that customers and partners are excited to take advantage of these new technology trends. This year's Acquia Engage showed how our own transformation will empower organizations to take advantage of new technology and transform how they do business.

Annertech: #DrupalCampDublin 2017 - a retrospective

Tue, 10/31/2017 - 13:29
#DrupalCampDublin 2017 - a retrospective

Over the past number of years, Drupal Camp Dublin was becoming more of a showcase/case study event where different speakers display work they had been doing on various websites. This year, we (the Drupal Ireland Association, of which I was chairperson) decided to "go back to our roots" and do two things: create a developer conference for developers, and engage more people from outside of Ireland.

Valuebound: Configure Apache Solr with Drupal for better content search

Tue, 10/31/2017 - 11:20

There have been times when clients are not very satisfied with the default Drupal search as quite a few times it is unable to meet their requirement especially when you need specific search control beyond core e.g. facets and related content. In order to resolve this issue and make search fast for end customers, we can use Apache Solr - an open source enterprise search platform - and configure it with our Drupal site.

In one of our previous blog post, we have discussed “How To Create Custom SOLR Search With Autocomplete In Drupal 7”. Note, before creating custom Solr search,…

Amazee Labs: Amazee Agile Agency Survey Results - Part 1

Tue, 10/31/2017 - 09:00
Amazee Agile Agency Survey Results - Part 1

A few weeks ago I published a call for feedback on a project I've begun to assess agile practices in our industry (Take the Amazee Agile Agency Survey 2017). I would like to share a preliminary overview of the results I have received for the Amazee Agile Agency survey so far. Twenty-five individuals have completed the survey to date, so I have decided to extend the deadline a few more days, to November 5th, in order to gather more responses. Thanks to everyone who has participated so far! 

Josef Dabernig Tue, 10/31/2017 - 10:00 Initial Observations Popular Methodologies

Given the initial survey results, Scrum (or a Scrum hybrid or variant) is the most widespread development process used by agencies. Many teams consider it their top priority in order to deliver a successful project. Following Scrum as methods most use by agencies are Kanban or Waterfall.

ScrumBan (a hybrid of Scrum and Kanban) has not been widely adopted.  

In addition to those processes presented, Holocracy, Extreme Programming or DSDM have also been mentioned.

At Amazee, we began using Scrum to deliver projects a little over two years ago and have made great progress on it since then. In the last year, we also started a maintenance team which uses Kanban. Just recently, we began evaluating ScrumBan as a way of integrating our maintenance team with one of our project teams.

Project Teams 

Agencies ranging in sizes from 1-5 people to over 100 people have responded to the survey. Of those surveyed, the most common team size for project work are, in order from most common to least common:

  • three people or fewer
  • five people
  • four people
  • six people  

In terms of co-located or working remotely, team location varied wildly, but skewed towards 'mostly co-located' with some degree of remote. More than 50% of agencies form a new team with the launch of a new project, followed by stable teams which deliver multiple projects at the same time. Following multiple-project delivery are stable teams which deliver one project at a time.

At Amazee, we started out spinning up a new team with each new project, but soon realized that the constant starting and stopping of mid-sized projects was too disruptive. These days, we use stable teams to deliver multiple projects.

Sprints

Most teams surveyed deliver in two-week sprints. The remaining 33% of respondants deliver anywhere from single-day sprints to month-long sprints.

Team Integration

Frontend and backend developers are usually specialized but mostly work together on one team.

DevOps, QA/Testing, as well as the Scrum Master role, are shown in all variations of integrated or totally separate teams.

UX & Design are split, with this role either in a separate team (or external resource) or as part of a stable team. 

At Amazee, we try to hire T-shaped experts that can work across most disciplines on a team. For example, a Frontend developer may also have experience with backend tasks, which can help alleviate work silos and ticket bottlenecks. 

Staying Connected

Most agency teams rely on written communication to stay connected. This can take the form of tickets or via a chat tool such as Slack.

The majority of teams hold team meetings and 1-on-1 meetings, while fewer teams communicate mainly via blogs, wikis or even pull requests.

The majority of standups last fifteen minutes while some are only 5-10 minutes.

At Amazee, our hubs differ. Our Zurich office holds a company-wide standup that takes about ten minutes, followed by a team-specific standup that takes another ten minutes. Our Austin office holds a company-wide standup, which includes a client, which lasts about fifteen minutes. 

Splitting up the Work 

Many agencies vary in their approach to defininig, writing, reviewing, and estimating tasks and tickets. For most agencies, the project team is involved in each step of the ticket creation process. In others, creating tickets falls to the client, project manager, or product owner. In most cases, a technical lead is involved in the high-level ticket creation and the team is brought in for estimations. 

The most common approach to estimating ticket is time based (hours, days, weeks) followed by story points (t-shirt sizes, fibonacci sequence) 

Client Communication 

When it comes to meetings between the team and the client, the top mentioned options where 'less frequently' followed by 'more or once per week' and 'every two weeks'.

At Amazee, depending on the project size, our teams meet weekly or bi-weekly with the client. Clients are encouraged to talk directly with the team via Slack. We'd like to offer a daily standup with some clients, but haven't figured out how to do this easily as usually a team works on multiple projects at the same time. 

Delivery Practices

Most teams surveyed deliver rolling deployments, pushing code whenever necessary.

Peer reviews / code reviews have been named equally “somewhat in use” as well considered “very important”.

While the majority of agencies considers user testing very important, for automated testing the majority still tends only towards “somewhat in use”.

While a number of agencies have pair programming somewhat in use, Mob programming is mostly unknown.

The majority of teams consider automated deployments / continuous integration very important.

When it comes to story mapping, most agencies are unfamiliar. Those which do implement this tool, however, consider it very important.

At Amazee, peer review for every ticket is a normal part of our development flow. Our developers implement pair programming whenever necessary. This is an excellent practice for sharing knowledge and increasing the team's technical confidence. We are actively exploring story mapping. 

Take our Survey

This initial post is just a taste of the information I have collected, there is a lot more to be shared. Besides the numerical data, I am especially excited about the free-form responses which give valuable insights into the tangible, real-world decisions that are being taken in agencies to define daily agency life.

Before sharing a deeper analysis and the full, anonymous, survey results, I wanted to share this preliminary data to give an idea of what’s coming in. I hope this information is helpful in determining industry alignment or to find inspiration for what to try next.

Our Agile Agency survey will remain open until Sunday, November 5th at midnight UTC -7. After the survey closes, I will tabulate the results and prepare Part 2 of this series where I look forward to sharing my findings.  

Pages