Dries Buytaert: Moving the Drupal 8 workflow initiative along

Planet Drupal - Fri, 2017/01/06 - 9:24am

Nine months ago I wrote about the importance of improving Drupal's content workflow capabilities and how we set out to include a common base layer of workflow-related functionality in Drupal 8 core. That base layer would act as the foundation on which we can build a list of great features like cross-site content staging, content branching, site previews, offline browsing and publishing, content recovery and audit logs. Some of these features are really impactful; 5 out of the top 10 most requested features for content authors are related to workflows (features 3-7 on the image below). We will deliver feature requests 3 and 4 as part of the "content workflow initiative" for Drupal 8. Feature requests 5, 6 and 7 are not in scope of the current content workflow initiative but still stand to benefit significantly from it. Today, I'd like to provide an update on the workflow initiative's progress the past 9 months.

The top 10 requested features for content creators according to the 2016 State of Drupal survey. Features 1 and 2 are part of the media initiative for Drupal 8. Features 3 and 4 are part of the content workflow initiative. Features 5, 6 and 7 benefit from the content workflow initiative.Configurable content workflow states in Drupal 8.2

While Drupal 8.0 and 8.1 shipped with just two workflow states (Published and Unpublished), Drupal 8.2 (with the the experimental Content moderation module) ships with three: Published, Draft, and Archived. Rather than a single 'Unpublished' workflow state, content creators will be able to distinguish between posts to be published later (drafts) and posts that were published before (archived posts).

The 'Draft' workflow state is a long-requested usability improvement, but may seem like a small change. What is more exciting is that the list of workflow states is fully configurable: you can add additional workflow states, or replace them with completely different ones. The three workflow states in Drupal 8.2 are just what we decided to be good defaults.

Let's say you manage a website with content that requires legal sign-off before it can be published. You can now create a new workflow state 'Needs legal sign-off' that is only accessible to people in your organization's legal department. In other words, you can set up content workflows that are simple (like the default one with just three states) or that are very complex (for a large organization with complex content workflows and permissions).

This functionality was already available in Drupal 7 thanks to the contributed modules like the Workbench suite. Moving this functionality into core is useful for two reasons. First, it provides a much-requested feature out of the box – this capability meets the third most important feature request for content authors. Second, it encourages contributed modules to be built with configurable workflows in mind. Both should improve the end-user experience.

Support for different workflows in Drupal 8.3

Drupal 8.3 (still in development, planned to be released in April of 2017) goes one step further and introduces the concept of multiple types of workflows in the experimental Workflows module. This provides a more intuitive way to set up different workflows for different content types. For example, blog posts might not need legal sign-off but legal contracts do. To support this use case, you need to be able to setup different workflows assigned to their appropriate content types.

What is also interesting is that the workflow system in Drupal 8.3 can be applied to things other than traditional content. Let's say that our example site happens to be a website for a membership organization. The new workflow system could be the technical foundation to move members through different workflows (e.g. new member, paying member, honorary member). The reusability of Drupal's components has always been a unique strength and is what differentiates an application from a platform. By enabling people to reuse components in interesting ways, we turn Drupal into a powerful platform for building many different applications.

Drupal 8.3 will support multiple different editorial workflows. Each workflow can define its own workflow states as well as the possible transitions between them. Each transition has permissions associated with them to control who can move content from one state to another.Workspace interactions under design

While workflows for individual content items is very powerful, many sites want to publish multiple content items at once as a group. This is reflected in the fourth-most requested feature for content authors, 'Staging of multiple content changes'. For example, a newspaper website might cover the passing of George Michael in a dedicated section on their site. Such a section could include multiple pages covering his professional career and personal life. These pages would have menus and blocks with links to other resources. 'Workspaces' group all these individual elements (pages, blocks and menus) into a logical package, so they can be prepared, previewed and published as a group. And what is great about the support for multiple different workflows is that content workflows can be applied to workspaces as well as to individual pieces of content.

We are still in the early stages of building out the workspace functionality. Work is being done to introduce the concept of workspaces in the developer API and on designing the user interface. A lot remains to be figured out and implemented, but we hope to introduce this feature in Drupal 8.5 (planned to be released in Q2 of 2018). In the mean time, other Drupal 8 solutions are available as contributed modules.

An outside-in design that shows how content creators could work in different workspaces. When you're building out a new section on your site, you want to preview your entire site, and publish all the changes at once. Designed by Jozef Toth at Pfizer.Closing thoughts

We discussed work on content workflows and workspaces. The changes being made will also help with other problems like content recovery, cross-site content staging, content branching, site previews, offline browsing and publishing, and audit logs. Check out the larger roadmap of the workflow initiative and the current priorities. We have an exciting roadmap and are always looking for more individuals and organizations to get involved and accelerate our work. If you want to get involved, don't be afraid to raise your hand in the comments of this post.

Thank you

I tried to make a list of all people and organizations to thank for their work on the workflow initiative but couldn't. The Drupal 8 workflow initiative borrows heavily from years of hard work and learnings from many people and organizations. In addition, there are many people actively working on various aspects of the Drupal 8 workflow initiative. Special thanks to Dick Olsson (Pfizer), Jozef Toth (Pfizer), Tim Millwood (Appnovation), Andrei Jechiu (Pfizer), Andrei Mateescu (Pfizer), Alex Pott (Chapter Three), Dave Hall (Pfizer), Ken Rickard (Palantir.net) and Ani Gupta (Pfizer). Also thank you to Gábor Hojtsy (Acquia) for his contributions to this blog post.


ARREA-Systems: Simple twitter feed with custom block

Planet Drupal - Fri, 2017/01/06 - 1:08am
Simple twitter feed with custom block Fri, 01/06/2017 - 08:08 In this article, we will present how we built a simple twitter feed in Drupal 8 with custom block and without any custom module. This block will display a list of tweets pulled from a custom list as in the example shown in the side bar.

Lullabot: Journey Into the Year of the Fire Chicken

Planet Drupal - Thu, 2017/01/05 - 10:00pm
Mike & Matt are joined by a gaggle of Lullabots to talk successes and failures of 2016, and what we're looking forward to in 2017.

Mediacurrent: Migration with Custom Values in Drupal 8

Planet Drupal - Thu, 2017/01/05 - 2:39pm
Custom Preprocessing

In Drupal 7 there were numerous ways to preprocess data prior to migrating values. This was especially useful when inconsistencies in the data source needed to be addressed. One example I have dealt with in the past was migrating email addresses from an old system that didn’t check for properly formatted emails on its user fields. These errors would produce faulty data in the new Drupal site. I preprocessed the field data for the most common mistakes which reduced the amount of erroneous addresses brought over.


Liip: Drupal 8 Migrate Multilingual Content using Migrate API

Planet Drupal - Thu, 2017/01/05 - 11:24am

As a follow-up to my previous blog post about the usage of Migrate API in Drupal 8, I would like to give an example, how to import multilingual content and translations in Drupal 8.

Prepare and enable translation for your content type

Before you can start, you need to install the “Language” and “Content Translation” Module. Then head over to “admin/config/regional/content-language” and enable Entity Translation for the node type or the taxonomy you want to be able to translate.

As a starting point for setting up the migrate module, I recommend you my blog post mentioned above. To import data from a CVS file, you also need to install the migrate_source_csv module.

Prerequisites for migrating multilingual entities

Before you start, please check the requirements. You need at least Drupal 8.2 to import multilingual content. We need the destination option “translations”, which was added in a patch in Drupal 8.2. See the corresponding drupal.org issue here.

Example: Import multilingual taxonomy terms

Let’s do a simple example with taxonomy terms. First, create a vocabulary called “Event Types” (machine name: event_type).

Here is a simplified dataset:

Id Name Name_en 1 Kurs Course 2 Turnier Tournament

You may save this a csv file.

Id;Name;Name_en 1;Kurs;Course 2;Turnier;Tournament

The recipe to import multilingual content

As you can see in the example data,  it contains the base language (“German”) and also the translations (“English”) in the same file.

But here comes a word of warning:

Don’t try to import the term and its translation in one migration run. I am aware, that there are some workarounds with post import events, but these are hacks and you will run into troubles later.

The correct way of importing multilingual content, is to

  1. create a migration for the base language and import the terms / nodes. This will create the entities and its fields.
  2. Then, with an additional dependent migration for each translated language, you can then add the translations for the fields you want.

In short: You need a base migration and a migration for every language. Let’s try this out.

Taxonomy term base language config file

In my example, the base language is “German”. Therefore, we first create a migration configuration file for the base language:

This is a basic example in migrating a taxonomy term in my base language ‘de’.

Put the file into <yourmodule>/config/install/migrate.migration.event_type.yml and import the configuration using the drush commands explained in my previous blog post about Migration API.

id: event_type label: Event Types source: plugin: csv # Full path to the file. Is overriden in my plugin path: public://csv/data.csv # The number of rows at the beginning which are not data. header_row_count: 1 # These are the field names from the source file representing the key # uniquely identifying each node - they will be stored in the migration # map table as columns sourceid1, sourceid2, and sourceid3. keys: - Id ids: id: type: string destination: plugin: entity:taxonomy_term process: vid: plugin: default_value default_value: event_type name: source: Name language: 'de' langcode: plugin: default_value default_value: 'de' #Absolutely necessary if you don't want an error migration_dependencies: {}

Taxonomy term translation migration configuration file:

This is the example file for the English translation of the name field of the term.

Put the file into <yourmodule>/config/install/migrate.migration.event_type_en.yml and import the configuration using the drush commands explained in my previous blog post about Migration API.

id: event_type_en label: Event Types english source:   plugin: csv # Full path to the file. Is overriden in my plugin path: public://csv/data.csv # The number of rows at the beginning which are not data. header_row_count: 1 keys: - Id ids: id: type: string destination: plugin: entity:taxonomy_term translations: true process: vid: plugin: default_value default_value: event_type tid: plugin: migration source: id migration: event_type name: source: Name_en language: 'en' langcode: plugin: default_value default_value: 'en' #Absolutely necessary if you don't want an error migration_dependencies: required: - event_type

Explanation and sum up of the learnings

The key in the migrate configuration to import multilingual content are the following lines:

destination: plugin: entity:taxonomy_term translations: true

These configuration lines instruct the migrate module, that a translation should be created.

tid: plugin: migration source: id migration: event_type

This is the real secret. Using the process plugin migration,  we maintain the relationship between the node and its translation.The wiring via the tid field make sure, that Migrate API will not create a new term with a new term id. Instead, the existing term will be loaded and the translation of the migrated field will be added. And thats exactly what we need!

Now go ahead and try to create a working example based on my explanation. Happy Drupal migrations!


Flocon de toile | Freelance Drupal: Using the Drupal 8 Cron API to generate image styles

Planet Drupal - Thu, 2017/01/05 - 11:08am

We saw in a previous post how we could automatically generate the image styles defined on a site for each uploaded source image. We will continue this post for this time to carry out the same operation using the Cron API of Drupal 8, which allows us to desynchronize these mass operations from actions carried out by users, and which can therefore penalize performances.


Deeson: New version of Warden, open source site tracker and manager for Drupal

Planet Drupal - Thu, 2017/01/05 - 11:00am

We’re very pleased to announce a new beta release of our popular open source Warden software, developed in-house at Deeson and which reports and keeps track of multiple Drupal websites on different platforms. This version updates the MongoDB PHP driver driver version, but also fixes a number of number of other issues.

As well as this, we’re also planning our next release, which we’re looking at including JavaScript library versions (jQuery, Backbone, React.js etc) and server package versions (Apache, Nginx, Varnish, MySQL etc). This will help provide further information about the package versions being used by sites and servers you’re running, helping you understand where vulnerabilities could be and highlight libraries that need updating.

The Warden server software itself is written in Symfony and can be downloaded from GitHub. It works by providing a central dashboard which lists all the Drupal sites a developer might be working on, highlighting any that need issues, for example those that need updates. It’s composed of two parts - a module which needs to be installed on each of your websites and a central dashboard hosted on a web server.

Hosting companies like Acquia and Pantheon have their own reporting tools, but only if work if you only host websites on their platforms. If you have a number of websites running on multiple platforms, you need Warden to report on them all. Here is a guide to how Warden works.


Agiledrop.com Blog: AGILEDROP: Drupal Blogs from December

Planet Drupal - Thu, 2017/01/05 - 9:08am
Last month we began with an overview of our blogs that were written in November. We promised that from now on, at the beginning of every month, you will be able to see, which Drupal blogs we have written for you over the past month. With that, you will be better informed. So, here's our December's work. Besides an overview of November's blogs from us and from other authors, we began our December's work with Drupal Camps in Middle America. There have been some complaints about the choice of the term Middle America, but we stand by our decision, which we also explained in the blog post.… READ MORE