Drupal Planet

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 2 hours 32 min ago

Colorfield: React and Drupal 8 with JSON API 3/3

Tue, 2018-01-16 14:31
React and Drupal 8 with JSON API 3/3 christophe Tue, 16/01/2018 - 22:31 This post focuses on translation issues and various pitfalls that you might encounter while building with React and Drupal: internationalization with and without language fallback, include images with images styles, taxonomy filter, fetch data on the route or the component, sort by weight, deploy in production.
Categories: Drupal

Evolving Web: Drupal 8 Modules We ♥ for 2018

Tue, 2018-01-16 12:00

With so many shiny new Drupal 8 modules emerging this year, we were hard pressed to pick our recommendations for 2018. It came down to asking ourselves: which modules are we excited about implementing in 2018… the ones that will make our projects better, faster, smarter brighter? Read on for our list of Drupal 8 modules we're excited about.

Configuration Split

The Drupal Configuration Split module makes Drupal 8 configuration management more customizable. This means you can set up some configurations that can be edited on the live site, without interfering with your configuration management workflow. Instead of importing and exporting the whole set of a site’s configuration, the module enables you to define sets of configuration to export to different directories that automatically merge again when they are imported.

Content Workflow

If you’ve shied away from implementing complicated workflows in the past, you’ll enjoy how the Content Workflow module makes it easy to set up a simple workflow. This core module enables you to streamline the content publication process by defining states for content (such as draft, unpublished and published) and then manage permissions around these states.

Deploy

The Deploy content staging module makes it easier to stage and preview content for a Drupal site. It’s often used to deploy content from one Drupal site to another. Redesigned for Drupal 8, the new version is based on the Multiversion and Replication modules, making it more efficient and flexible.

Drupal Commerce

The new full release of Drupal Commerce has us very excited to start building ecommerce sites in Drupal 8. Fully rebuilt for Drupal 8, the new Drupal Commerce module doesn’t presume a specific ecommerce business model, enabling developers to customize the module to suit a merchant’s needs.

JSON API

The JSON API module formats your JSON requests and responses to make them compliant with the JSON API Specification. This module is the key to setting up Drupal as a backend so you can implement the font-end with React or your front-end platform of choice.

Schema.org Metatag

Ramp up your SEO with structured data that helps Google categorize and display your pages. The Schema.org Metatag module allows you to add and validate Schema.org structured data as JASON LD, one of Google’s preferred data formats.

UI Patterns

If you’re looking for a way to implement an ‘atomic design’ in Drupal the Drupal UI Patterns project is a nice option. It consists of six modules that allow you to define and expose UI patterns as Drupal plugins. You can use them as drop-in templates for all entity types — paragraphs, views, field groups and more.

Webform

The Drupal webform module has a new release candidate for Drupal 8. A ton of work has been put into the module; it’s like a whole form-building application inside your Drupal site. Quickly integrate forms into any Drupal 8 website. enables you to build, publish and duplicate webforms. You can also manage and download submissions, and send confirmations to users.

Which Drupal 8 modules are doing it for you?

We’d love to hear about which Drupal 8 modules your team is excited about. Leave us a comment.

 

+ more awesome articles by Evolving Web
Categories: Drupal

Manifesto: Looking ahead to Drupalcamp London 2018

Tue, 2018-01-16 07:44
This year’s Drupalcamp London, a three-day knowledge-sharing conference devoted to all things Drupal, promises to be the biggest and best yet. Taking place at City University from 2nd to 4th March, it’s a must-visit event for anyone with more than a passing interest in the open-source CMS – developers, site builders, vendors, agencies and potential. Continue reading...
Categories: Drupal

DrupalEasy: What "The Last Jedi" can teach us about learning Drupal

Tue, 2018-01-16 06:38

Spoiler alert! If you haven't seen “The Last Jedi” yet, this blog post includes what can be considered a minor spoiler. I've seen the movie a few times now (I saw the original Star Wars movie when I was 7 years old, and I've been hooked ever since), and I've been able to fully indoctrinate at least one of my kids in my love for the series. When we first saw the movie on opening night, there was a line of dialog that resonated with me more than usual - I've been thinking about that line for over a month now and have figured out how to relate my love of Star Wars with my obsession for teaching Drupal. 

"The Greatest Teacher, Failure Is"

There's a point in the movie when Yoda is speaking to another character and utters this line. As a former mechanical/aerospace engineering college adjunct professor and a current Drupal trainer, I've always believed that for a lesson to truly take hold, there has to be a little bit of pain - not physical pain, but rather the kind of pain that comes from doing something incorrectly (often numerous times) before realizing the proper way of doing something that leads to a more satisfying, correct (and often efficient) result. As usual, I didn't have the proper words to describe it - thanks to Yoda, I do now.

As I look back at my eleven years in the Drupal community, I can point to more things that I care to admit that I didn't do correctly the first time. If I narrow that list to technical mistakes, it becomes very clear that many of the mistakes I've made have had a direct impact on the curriculum I've written for our various training classes.

As we gear up to teach Mastering Professional Development Workflows with Pantheon for the second time, allow me to share some of the failures I've had in the past and how they've had a direct result on the curriculum for this 6-week class.

  1. "Everything is a content type" - this is something I learned only by repeatedly designing the information architecture for various sites that ended up not being able to completely fulfill all the project's requirements. Understanding the differences between various kinds of entities is key to building a sustainable site that meets 100% of a project's requirements.
  2. "Core search is fine" - I'm embarrassed to say how late I was to get on board the Search API train. Being able to provide faceted search to clients of all sizes is a huge win.
  3. "I don't need the command line" - looking back at the first half-ish of my Drupal career, I used Drush only when absolutely necessary. Not learning basic command line tools until well into Drupal 7 definitely held me back. With Drupal 8, if you want to be a professional Drupal developer, there is no way to avoid it. Luckily, using command line tools like Composer, Drush, and Drupal Console are not only "the right thing to do", but also save time. 
  4. "MAMP is fine" - I was late to the party in moving my local development environment from MAMP and Acquia Dev Desktop to a Docker-based solution. I had played around a bit with virtualized solutions, but once you get accustomed to a professional-grade, modern, Docker-based solution, you'll never go back.

While I could list additional examples (multi-branch development, configuration management, display modes) of previous failures - or even one or two that I feel like I'm currently failing (test-driven development), the point is that sometimes it is necessary to fail in order to really understand the value of a success. 

DrupalEasy's 6-week live, online Mastering Professional Development Workflows with Pantheon, not coincidentally, addresses the failures listed above. The next session begins on February 27, 2018.  

The next session (our 11th!) of our 12-week, live, online more-introductory-focused Drupal Career Online begins March 26, 2018.
 

Categories: Drupal

Hook 42: Never "Just" a Patch

Mon, 2018-01-15 20:20

There's no such thing as "just a typo."

In Drupal, clients and perspective users see the user interface and documentation first. When we give them demos or when they evaluate the Drupal project, they aren’t just evaluating the code. Grammar, punctuation, readability, and spelling all matter. They give the project credibility. It is just as important to maintain the same high standards with the front facing side of Drupal as we do with the code.

I have been working with Drupal for about three years, and contributing back to the project for a little less than two.

I have learned quite a bit, but, most importantly, I have come to the conclusion that there is no such thing as “just” a typo, “just” a grammar issue, or “just” a documentation patch; not all patches have to fix code to be important.

Categories: Drupal

Love Huria: Must have custom drush commands in every Drupal project

Mon, 2018-01-15 17:00

I am working on a project where we use Drush commands a lot …. seriously like A LOT.. That said, while working on the project, I found few drush commands which come quite handy in our day to day operations. We use these commands mostly with deploy hooks and also while working locally.

Everyone uses Drush commands which are kinda in daily use while working on Drupal and we just can’t imagine our life without it in terms of increasing our productivity.

We want to be more and more productive right? Yes, we do. :)

A little bit about...
Categories: Drupal

Jacob Rockowitz: The Webform module now depends on the Contribute module

Mon, 2018-01-15 16:59

After spending the past year experimenting with promoting paid services, talking about sponsored features, and adding an about section to the Webform module. I learned a lot, from my experiments, including not asking for forgiveness.

Importance of contributing to the Drupal community

Not enough people understand and/or realize the importance of contributing to the Drupal community. My last blog post discussed my hope of finding ways to help sustain my commitment and contribution to the Drupal community and ended by stating…

Convincing people that they need to contribute

The challenge is convincing people and organizations that they need to contribute to Open Source. Funding is an ongoing challenge for the Drupal community The problem could be that people don't understand the importance and value of contributing back to Open Source.

Nowhere in Drupal's user interface/experience is our community and Drupal Association promoted and/or acknowledged. Core maintainers are only included in the MAINTAINERS.txt file, which only fellow developers can access. Drupal is not a product that can to be sold but we are a community with an association that needs recognition, support, and contributions.

Everyone needs to be a member of the Drupal Association

It’s surprising how many people and organizations are asking for support in the Webform module's issue queue who are not members of the...Read More

Categories: Drupal

Drupal blog: Happy seventeenth birthday Drupal

Mon, 2018-01-15 15:30

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Seventeen years ago today, I open-sourced the software behind Drop.org and released Drupal 1.0.0. When Drupal was first founded, Google was in its infancy, the mobile web didn't exist, and JavaScript was a very unpopular word among developers.

Over the course of the past seventeen years, I've witnessed the nature of the web change and countless internet trends come and go. As we celebrate Drupal's birthday, I'm proud to say it's one of the few content management systems that has stayed relevant for this long.

While the course of my career has evolved, Drupal has always remained a constant. It's what inspires me every day, and the impact that Drupal continues to make energizes me. Millions of people around the globe depend on Drupal to deliver their business, mission and purpose. Looking at the Drupal users in the video below gives me goosebumps.

Drupal's success is not only marked by the organizations it supports, but also by our community that makes the project more than just the software. While there were hurdles in 2017, there were plenty of milestones, too:

  • At least 190,000 sites running Drupal 8, up from 105,000 sites in January 2016 (80% year over year growth)
  • 1,597 stable modules for Drupal 8, up from 810 in January 2016 (95% year over year growth)
  • 4,941 DrupalCon attendees in 2017
  • 41 DrupalCamps held in 16 different countries in the world
  • 7,240 individual code contributors, a 28% increase compared to 2016
  • 889 organizations that contributed code, a 26% increase compared to 2016
  • 13+ million visitors to Drupal.org in 2017
  • 76,374 instance hours for running automated tests (the equivalent of almost 9 years of continuous testing in one year)

Since Drupal 1.0.0 was released, our community's ability to challenge the status quo, embrace evolution and remain resilient has never faltered. 2018 will be a big year for Drupal as we will continue to tackle important initiatives that not only improve Drupal's ease of use and maintenance, but also to propel Drupal into new markets. No matter the challenge, I'm confident that the spirit and passion of our community will continue to grow Drupal for many birthdays to come.

Tonight, we're going to celebrate Drupal's birthday with a warm skillet chocolate chip cookie topped with vanilla ice cream. Drupal loves chocolate! ;-)

Note: The video was created by Acquia, but it is freely available for anyone to use when selling or promoting Drupal.

Categories: Drupal

PreviousNext: Revisiting technical debt with simple expiry annotations

Mon, 2018-01-15 14:48

Managing technical debt is important for the health of all software projects. One way to manage certain types of technical debt is to revisit code and decide if it’s still relevant to the project and to potentially remove it. Doing so can reducing complexity and the amount of code developers are required to maintain.

by Sam Becker / 16 January 2018

To address this we’ve been experimenting with adding simple annotations to code, which indicate an “expiry”. A nudge to developers to go and reevaluate if some bit of code will still be needed at some point in the future. This can be integrated into CI pipelines to fail builds which have outstanding expiry annotations.

Some scenarios where this has proved to be helpful have been:

  • Removing workarounds in CSS to address bugs in web browsers which have since been fixed.
  • Removing uninstalled modules, which were required only for hook_uninstall.
  • Removing code that exists for features which are gradually being superseded, like an organisation gradually migrating content from nodes into a new custom entity.

Here is an real snippet of code we were able to recently delete from a project, based on a bug which was fixed upstream in Firefox. I don’t believe without an explicit prompt to revisit the code, which was introduced many months earlier, we would have been able to confidently clean this up.

// @expire Jan 2018 // Fix a bug in firefox which causes all form elements to match the exact size // specified in the "size" or "cols" attribute. Firefox probably will have // fixed this bug by now. Test it by removing the following code and visiting // the contact form at a small screen size. If the elements dont overflow the // viewport, the bug is fixed. .form-text__manual-size { width: 529px; @media (max-width: 598px) { width: 100%; } }

The code we've integrated into our CI pipeline to check these expiry annotations simply greps the code base for strings matching the expiry pattern for the last n months worth of time:

#!/bin/bash SEARCH_FORMAT="@expire %s" DATE_FORMAT="+%b %Y" DIRS="./app/modules/custom/ ./app/themes/" SEARCH_LAST_N_MONTHS=4 # Cross-platform date formatting with a month offset. case `uname` in Darwin) function date_offset_month() { date -v $1m "$DATE_FORMAT"; } ;; Linux) function date_offset_month() { date --d="$1 month" "$DATE_FORMAT" } ;; *) esac for i in $(seq 0 $SEARCH_LAST_N_MONTHS); do FORMATTED_DATE=$(date_offset_month -$i) SEARCH_STRING=$(printf "$SEARCH_FORMAT" "$FORMATTED_DATE") echo "Searching codebase for \"$SEARCH_STRING\"." grep -rni "$SEARCH_STRING" $DIRS && exit 1 done exit 0
Categories: Drupal

Freelock : New Year, New Website!

Mon, 2018-01-15 14:37
New Year, New Website! John Locke Mon, 01/15/2018 - 14:37

It's only taken two years since the release of Drupal 8 for us to get our own site updated... Cobbler's children and all. But finally, we are proud to unveil our shiny new site!

But wait, don't you tell your clients you don't need a new site?

Bootstrap Drupal 8 Drupal Commerce Drupal Migration Drupal Planet Drupal upgrade GraphQL React Vue.js
Categories: Drupal

Roy Scholten: 17

Mon, 2018-01-15 14:34
15 Jan 2018 17

Drupal is 17 years old today. Quite an achievement for a web software to stay around, let alone stay relevant for such a long time.

I’ve been around for 12 years. Quite a stretch as well. Getting involved in this open source project as a designer has taught and brought me a lot. I put quite a bit into it as well.

I get a lot of benefits from things I learned in Drupal that I can apply in other contexts.

  • Provide rationale for design decisions. So much typing in issue queue comments!
  • Help people see the other’s point of view and then come to a shared decision.
  • Or agree to disagree, then still make a choice.
  • An appreciation and at least a “gist of things” knowledge of the complexity of software development. It helps with clarifying scope, finding a good place to start, and understanding what is difficult and what can be relatively straight forward.
  • Pragmaticism over purism
  • Edge cases are important
  • There’s a difference between patience and stubborness
  • Accessibility, multilingual, extensibility, modularity are hard but worth it
  • If you can’t imagine why somebody would want do do X, it’s always from a lack of imagination from your part
  • There’s always so much more to do
  • There’s only so much you can do
  • When you start taking things personal it’s probably time to take a break
  • It’s amazing what people can get done when driven by a passion for doing a good thing and doing it well.

… and many returns!

Tags drupal drupalplanet open source
Categories: Drupal

Doug Vann: Adding regular text into the Drupal Date Format field

Mon, 2018-01-15 09:31

Q: "Can you add simple text to a Date Format value in Drupal?" A: YES! [This was news to me]
Preamble:
I was teaching a Drupal 8 class last week and a student asked if we could enter regular text [like the word "date"] into the Date Formate field. I tried it and, of course, some of the letters were translated into PHP Date elements rather than showing all the letters for the word "date."
Ex: "date : M-d-y" became "15am31America/Indiana/Indianapolis : Jan-15-2018" but what we wanted was "date : Jan-15-2018"

It was at this point that I got the bright idea to ESCAPE the letters by adding a BackSlash "\" infront of each letter. SURE ENOUGH!! Now I could see each letter instead of the date translation that each letter stood for.
So... I made this quick video to share with the world just incase someone else can benefit from this discovery!

p.s. I'm quite sure MANY have been using this "trick" for years. But I was excited to discover it on my own after a student brought the idea up! :-)

Link to video http://www.youtube.com/watch?v=gJO0t-KkjX0

VideosDrupal Planet

View the discussion thread.

Categories: Drupal

Dries Buytaert: Happy seventeenth birthday Drupal

Mon, 2018-01-15 08:52

Seventeen years ago today, I open-sourced the software behind Drop.org and released Drupal 1.0.0. When Drupal was first founded, Google was in its infancy, the mobile web didn't exist, and JavaScript was a very unpopular word among developers.

Over the course of the past seventeen years, I've witnessed the nature of the web change and countless internet trends come and go. As we celebrate Drupal's birthday, I'm proud to say it's one of the few content management systems that has stayed relevant for this long.

While the course of my career has evolved, Drupal has always remained a constant. It's what inspires me every day, and the impact that Drupal continues to make energizes me. Millions of people around the globe depend on Drupal to deliver their business, mission and purpose. Looking at the Drupal users in the video below gives me goosebumps.

Drupal's success is not only marked by the organizations it supports, but also by our community that makes the project more than just the software. While there were hurdles in 2017, there were plenty of milestones, too:

  • At least 190,000 sites running Drupal 8, up from 105,000 sites in January 2016 (80% year over year growth)
  • 1,597 stable modules for Drupal 8, up from 810 in January 2016 (95% year over year growth)
  • 4,941 DrupalCon attendees in 2017
  • 41 DrupalCamps held in 16 different countries in the world
  • 7,240 individual code contributors, a 28% increase compared to 2016
  • 889 organizations that contributed code, a 26% increase compared to 2016
  • 13+ million visitors to Drupal.org in 2017
  • 76,374 instance hours for running automated tests (the equivalent of almost 9 years of continuous testing in one year)

Since Drupal 1.0.0 was released, our community's ability to challenge the status quo, embrace evolution and remain resilient has never faltered. 2018 will be a big year for Drupal as we will continue to tackle important initiatives that not only improve Drupal's ease of use and maintenance, but also to propel Drupal into new markets. No matter the challenge, I'm confident that the spirit and passion of our community will continue to grow Drupal for many birthdays to come.

Tonight, we're going to celebrate Drupal's birthday with a warm skillet chocolate chip cookie topped with vanilla ice cream. Drupal loves chocolate! ;-)

Note: The video was created by Acquia, but it is freely available for anyone to use when selling or promoting Drupal.
Categories: Drupal

OSTraining: Create Charts in Drupal 8 with Views

Mon, 2018-01-15 07:50

There are many ways to present data to your readers. One example would be a table or a list. Sometimes you would rather prefer to enhance such data with a graphical chart. 

It can ease understanding of large quantities of data. There is a way to make charts in Drupal with the help of the Charts module and Views.

In this tutorial, you will learn the basic usage of the module in combination with the Google Charts library. Let’s start!

Categories: Drupal

Amazee Labs: Don’t Push it: Using GraphQL in Twig

Mon, 2018-01-15 02:40
Don’t Push it: Using GraphQL in Twig

Using GraphQL in Drupal with Twig instead of React, Vue or the next month's javascript framework might sound like a crazy idea, but I assure you it’s worth thinking about.

Philipp Melab Mon, 01/15/2018 - 10:40

Decoupling is all the rage. Javascript frontends with entirely independent backends are state of the art for any self-respecting website right now. But sometimes it’s not worth the cost and the project simply does not justify the full Drupal + React technology stack.

Besides the technological benefits of a javascript based frontend like load times and responsiveness, there’s another reason why this approach is so popular: It moves control to the frontend, concept and design unit, which matches project workflows a lot better.

Status quo

Traditionally Drupal defines data structures that provide a “standard” rendered output, which then can be adopted by the so-called “theme developer” to meet the clients' requirements. Template overrides, preprocess functions, Display Suite, Panels, Layouts - there are myriads of ways how to do this, and twice as many opinions determining the right one. When taking over a project the first thing is to figure out how it was approached and where the rendered information actually comes from. Templates only have variables that are populated during processing or preprocessing and altered in modules or themes, which makes it very hard to reason with the data flow, if you were not the person that conceived it in the first place.

There are ideas to improve the situation, but regarding the success of decoupling, perhaps it’s time to approach the problem from a different angle.

Push versus Pull

The current push model used by Drupal scatters responsibilities across modules, preprocess functions and templates. The controller calls the view builder to prepare a “renderable” that is altered 101 times and results in a set of variables that might or might not be required by the current theme’s template.

If we would turn this around and let the template define it’s data requirements (as it happens in decoupled projects naturally), we could achieve a much clearer data flow and increase readability and maintainability significantly.

And that’s what the GraphQL Twig module is supposed to do. It allows us to add GraphQL queries to any Twig template, which will be picked up during rendering and used to populate the template with data.

A simple example node.html.twig:

{#graphql query($node: String!) { node:nodeById(id: $node) { title:entityLabel ... on NodeArticle { body { processed } } } } #} <h1>{{ graphql.data.node.title }}</h1> {% if graphql.data.node.body %} <div class="body">{{ graphql.data.node.body.processed }}</div> {% endif %}

 

This is already enough to pull the information we need and render it. Let’s have a look at what this does:

The graphql comment on top will be picked up by the module. When the template is rendered, it tries to match the queries input arguments to the current template variables, runs the GraphQL query and passes the result as a new graphql variable to the template. Simple as that, no preprocessing required. It works for every theme hook. Be it just one complex node type, an exceptional block or page.html.twig.

Imagine we use GraphQL Views to add a contextual GraphQL field similarArticles that uses SOLR to find similar articles for a given node. It could be used immediately like this:

{#graphql query($node: String!) { node:nodeById(id: $node) { title:entityLabel ... on NodeArticle { body { processed } similarArticles { title:entityLabel url:entityUrl { alias } } } } } #} <h1>{{ graphql.data.node.title }}</h1> {% if graphql.data.node.body %} <div class="body">{{ graphql.data.node.body.processed }}</div> {% endif %} {% if graphql.data.node.similarArticles %} <h2>Similar articles</h2> <ul> {% for article in graphql.data.node.similarArticles %} <li> <a href="https://www.amazeelabs.com/%7B%7B%20article.url.alias%20%7D%7D">{{article.title}}</a> </li> {% endfor %} </ul> {% endif %}

 

The module even scans included templates for query fragments, so the rendering of the “similar article” teaser could be moved to a separate component:

node.html.twig {#graphql query($node: String!) { node:nodeById(id: $node) { title:entityLabel ... on NodeArticle { body { processed } similarArticles { ... NodeTeaser } } } } #} <h1>{{ graphql.data.node.title }}</h1> {% if graphql.data.node.body %} <div class="body">{{ graphql.data.node.body.processed }}</div> {% endif %} {% if graphql.data.node.similarArticles %} <h2>Similar articles</h2> <ul> {% for article in graphql.data.node.similarArticles %} <li> {% include 'node-teaser.twig' with { node: article } %} </li> {% endfor %} </ul> {% endif %}

 

node-teaser.twig {#graphql fragment NodeTeaser on Node { title:entityLabel url:entityUrl { alias } } #} <a href="https://www.amazeelabs.com/%7B%7B%20node.url.alias%20%7D%7D">{{node.title}}</a>

 

No preprocessing, a clear path where data flows and true separation of concerns. The backend provides generic data sources (e.g. the similarArticles field) that can be used by the product development team at will. All without the cost of a fully decoupled setup. And the possibility to replace single theme hooks allows us to use existing Drupal rendering when it fits and switch to the pull-model wherever we would have to use complex layout modules or preprocessing functions to meet the requirements of the project.

Future development

There are some ideas for additional features, like mutation based forms and smarter scanning for query fragments, but first and foremost we would love to get feedback and opinions on this whole concept. So if you are interested, join on Slack or GitHub and let us know!

Categories: Drupal

Agiledrop.com Blog: AGILEDROP: Our blog posts from December

Sun, 2018-01-14 17:42
You have already seen what Drupal blogs we trending in the previous month, and now it is time to look at all our blog post we wrote. Here are the blog topics we covered in December.   The first blog post in December was Why Drupal is the most secure CMS. It explains and shows the reasons why Drupal is a secure CMS even though many people doubt that due to being open source. The second was In the beginning, Drupal had an ambition. We talked about Dries keynote from DrupalCon Vienna and his statement that Drupal is for ambitious digital experiences. What are three critical ingredients for… READ MORE
Categories: Drupal

Lullabot: The Out of the Box Initiative

Sat, 2018-01-13 08:42
Matt and Mike the ins and outs of Out of the Box initiative, which endeavors to showcase Drupal's power "out of the box." They are joined by some of the developers from the Out of the Box initiative.
Categories: Drupal

Joachim's blog: Triggering events on the fly

Fri, 2018-01-12 14:45

As far as I know, there's nothing (yet) for triggering an arbitrary event. The complication is that every event uses a unique event class, whose constructor requires specific things passing, such as entities pertaining to the event.

Today I wanted to test the emails that Commerce sends when an order completes, and to avoid having to keep buying a product and sending it through checkout, I figured I'd mock the event object with Prophecy, mocking the methods that the OrderReceiptSubscriber calls (this is the class that does the sending of the order emails). Prophecy is a unit testing tool, but its objects can be created outside of PHPUnit quite easily.

Here's my quick code:

$order = entity_load('commerce_order', ORDER_ID); $prophet = new \Prophecy\Prophet; $event = $prophet->prophesize('Drupal\state_machine\Event\WorkflowTransitionEvent'); $event->getEntity()->willReturn($order); $subscriber = \Drupal::service('commerce_order.order_receipt_subscriber'); $subscriber->sendOrderReceipt($event->reveal());

Could some sort of generic tool be created for triggering any event in Drupal? Perhaps. We could use reflection to detect the methods on the event class, but at some point we need some real data for the event listeners to do something with. Here, I needed to load a specific order entity and to know which method on the event class returns it. For another event, I'd need some completely different entities and different methods.

We could maybe detect the type that the event method return (by sniffing in the docblock... once we go full PHP 7, we could use reflection on the return type), and the present an admin UI that shows a form element for each method, allowing you to enter an entity ID or a scalar value.

Still, you'd need to look at the code you want to run, the event listener, to know which of those you'd actually want to fill in.

Would it same more time than cobbling together code like the above? Only if you multiply it by a sufficiently large number of developers, as is the case with many developer tools.

It's the sort of idea I might have tinkered with back in the days when I had time. As it is, I'm just going to throw this idea out in the open.

Tags: eventsdeveloper tools
Categories: Drupal

Drupal core announcements: Drupal 8.5.0 will be released March 7; alpha begins week of January 17

Fri, 2018-01-12 13:12

Drupal 8.5.0, the next planned minor release of Drupal 8, is scheduled for Wednesday, March 7, 2018. Minor releases include new features, usability improvements, and backwards-compatible API improvements. Here's what this means now for core patches.

The goal of the alpha phase is to begin the preparation of the minor release and provide a testing target for theme or module developers and site owners. Alpha releases include most of the new features, API additions, and disruptive changes that will be in the upcoming minor version.

Drupal 8.5.0-alpha1 will be released the week of January 17

In preparation for the minor release, Drupal 8.5.x will enter the alpha phase the week of January 17, 2018. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. (More information on alpha and beta releases.)

  • Developers and site owners can begin testing the alpha next week.

  • The 8.6.x branch of core has been created, and future feature and API additions will be targeted against that branch instead of 8.5.x. All outstanding issues filed against 8.5.x will be automatically migrated to 8.6.

  • All issues filed against 8.4.x will then be migrated to 8.5.x, and subsequent bug reports should be targeted against the 8.5.x branch.

  • During the alpha phase, core issues will be committed according to the following policy:

    1. Most issues that are allowed for patch releases will be committed to 8.5.x and 8.6.x.

    2. Drupal 8.4.x will receive only critical bugfixes in preparation for its final patch release window. (Drupal 8.3.x and older versions are not supported anymore and changes are not made to those branches.)

    3. Most issues that are only allowed in minor releases will be committed to 8.6.x only. A few strategic issues may be backported to 8.5.x, but only at committer discretion after the issue is fixed in 8.6.x (so leave them set to 8.6.x unless you are a committer), and only up until the beta deadline.

Drupal 8.5.0-beta1 will be released the week of February 7

Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.

The release candidate phase will begin the week of February 21, and we will post further details at that time. See the summarized key dates in the release cycle, allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Categories: Drupal

Drupal blog: How to decouple Drupal in 2018

Fri, 2018-01-12 11:19

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

In this post, I'm providing some guidance on how and when to decouple Drupal.

Almost two years ago, I had written a blog post called "How should you decouple Drupal?". Many people have found the flowchart in that post to be useful in their decision-making on how to approach their Drupal architectures. Since that point, Drupal, its community, and the surrounding market have evolved, and the original flowchart needs a big update.

Drupal's API-first initiative has introduced new capabilities, and we've seen the advent of the Waterwheel ecosystem and API-first distributions like Reservoir, Headless Lightning, and Contenta. More developers both inside and outside the Drupal community are experimenting with Node.js and adopting fully decoupled architectures.

Let's start with the new flowchart in full:

All the ways to decouple Drupal

The traditional approach to Drupal architecture, also referred to as coupled Drupal, is a monolithic implementation where Drupal maintains control over all front-end and back-end concerns. This is Drupal as we've known it — ideal for traditional websites. If you're a content creator, keeping Drupal in its coupled form is the optimal approach, especially if you want to achieve a fast time to market without as much reliance on front-end developers. But traditional Drupal 8 also remains a great approach for developers who love Drupal 8 and want it to own the entire stack.

A second approach, progressively decoupled Drupal, offers an approach that strikes a balance between editorial needs like layout management and developer desires to use more JavaScript, by interpolating a JavaScript framework into the Drupal front end. Progressive decoupling is in fact a spectrum, whether it is Drupal only rendering the page's shell and populating initial data — or JavaScript only controlling explicitly delineated sections of the page. Progressively decoupled Drupal hasn't taken the world by storm, likely because it's a mixture of both JavaScript and PHP and doesn't take advantage of server-side rendering via Node.js. Nonetheless, it's an attractive approach because it makes more compromises and offers features important to both editors and developers.

Last but not least, fully decoupled Drupal has gained more attention in recent years as the growth of JavaScript continues with no signs of slowing down. This involves a complete separation of concerns between the structure of your content and its presentation. In short, it's like treating your web experience as just another application that needs to be served content. Even though it results in a loss of some out-of-the-box CMS functionality such as in-place editing or content preview, it's been popular because of the freedom and control it offers front-end developers.

What do you intend to build?

The most important question to ask is what you are trying to build.

  1. If your plan is to create a single standalone website or web application, decoupling Drupal may or may not be the right choice based on the must-have features your developers and editors are asking for.
  2. If your plan is to create multiple experiences (including web, native mobile, IoT, etc.), you can use Drupal to provide web service APIs that serve content to other experiences, either as (a) a content repository with no public-facing component or (b) a traditional website that is also a content repository at the same time.

Ultimately, your needs will determine the usefulness of decoupled Drupal for your use case. There is no technical reason to decouple if you're building a standalone website that needs editorial capabilities, but that doesn't mean people don't prefer to decouple because of their preference for JavaScript over PHP. Nonetheless, you need to pay close attention to the needs of your editors and ensure you aren't removing crucial features by using a decoupled approach. By the same token, you can't avoid decoupling Drupal if you're using it as a content repository for IoT or native applications. The next part of the flowchart will help you weigh those trade-offs.

Today, Drupal makes it much easier to build applications consuming decoupled Drupal. Even if you're using Drupal as a content repository to serve content to other applications, well-understood specifications like JSON API, GraphQL, OpenAPI, and CouchDB significantly lower its learning curve and open the door to tooling ecosystems provided by the communities who wrote those standards. In addition, there are now API-first distributions optimized to serve as content repositories and SDKs like Waterwheel.js that help developers "speak" Drupal.

Are there things you can't live without?

Perhaps most critical to any decision to decouple Drupal is the must-have feature set desired for both editors and developers. In order to determine whether you should use a decoupled Drupal, it's important to isolate which features are most valuable for your editors and developers. Unfortunately, there is are no black-and-white answers here; every project will have to weigh the different pros and cons.

For example, many marketing teams choose a CMS because they want to create landing pages, and a CMS gives them the ability to lay out content on a page, quickly reorganize a page and more. The ability to do all this without the aid of a developer can make or break a CMS in marketers' eyes. Similarly, many digital marketers value the option to edit content in the context of its preview and to do so across various workflow states. These kind of features typically get lost in a fully decoupled setting where Drupal does not exert control over the front end.

On the other hand, the need for control over the visual presentation of content can hinder developers who want to craft nuanced interactions or build user experiences in a particular way. Moreover, developer teams often want to use the latest and greatest technologies, and JavaScript is no exception. Nowadays, more JavaScript developers are including modern techniques, like server-side rendering and ES6 transpilation, in their toolboxes, and this is something decision-makers should take into account as well.

How you reconcile this tension between developers' needs and editors' requirements will dictate which approach you choose. For teams that have an entirely editorial focus and lack developer resources — or whose needs are focused on the ability to edit, place, and preview content in context — decoupling Drupal will remove all of the critical linkages within Drupal that allow editors to make such visual changes. But for teams with developers itching to have more flexibility and who don't need to cater to editors or marketers, fully decoupled Drupal can be freeing and allow developers to explore new paradigms in the industry — with the caveat that many of those features that editors value are now unavailable.

What will the future hold?

In the future, and in light of the rapid evolution of decoupled Drupal, my hope is that Drupal keeps shrinking the gap between developers and editors. After all, this was the original goal of the CMS in the first place: to help content authors write and assemble their own websites. Drupal's history has always been a balancing act between editorial needs and developers' needs, even as the number of experiences driven by Drupal grows.

I believe the next big hurdle is how to begin enabling marketers to administer all of the other channels appearing now and in the future with as much ease as they manage websites in Drupal today. In an ideal future, a content creator can build a content model once, preview content on every channel, and use familiar tools to edit and place content, regardless of whether the channel in question is mobile, chatbots, digital signs, or even augmented reality.

Today, developers are beginning to use Drupal not just as a content repository for their various applications but also as a means to create custom editorial interfaces. It's my hope that we'll see more experimentation around conceiving new editorial interfaces that help give content creators the control they need over a growing number of channels. At that point, I'm sure we'll need another new flowchart.

Conclusion

Thankfully, Drupal is in the right place at the right time. We've anticipated the new world of decoupled CMS architectures with web services in Drupal 8 and older contributed modules. More recently, API-first distributions, SDKs, and even reference applications in Ember and React are giving developers who have never heard of Drupal the tools to interact with it in unprecedented ways.

Unlike many other content management systems, old and new, Drupal provides a spectrum of architectural possibilities tuned to the diverse needs of different organizations. This flexibility between fully decoupling Drupal, progressively decoupling it, and traditional Drupal — in addition to each solution's proven robustness in the wild — gives teams the ability to make an educated decision about the best approach for them. This optionality sets Drupal apart from new headless content management systems and most SaaS platforms, and it also shows Drupal's maturity as a decoupled CMS over WordPress. In other words, it doesn't matter what the team looks like or what the project's requirements are; Drupal has the answer.

Special thanks to Preston So for contributions to this blog post and to Alex Bronstein, Angie Byron, Gabe Sullice, Samuel Mortenson, Ted Bowman and Wim Leers for their feedback during the writing process.

Categories: Drupal

Powered By