Development News

Tandem's Drupal Blog: Lando + Contenta CMS + Nuxt Pt. 1

Main Drupal Feed - Fri, 01/25/2019 - 00:00
January 25, 2019 Set up a headless Drupal architecture in Lando Why? Headless architectures offer many advantages to app construction. From the COPE (create once publish everywhere) strategy, to parallell development of the frontend and the backend of the app, but getting the infrastructure right can be a bit tricky. Let's take a look at ho...

Drupal Association blog: A Step in a New Direction. Farewell from Amanda Gonser.

Main Drupal Feed - Thu, 01/24/2019 - 18:49

When I joined the Drupal Association over 4 years ago, I didn’t ‘do Drupal’ and I didn’t have the faintest idea of what ‘the community’ was. These were things I read about in the job description for DrupalCon Coordinator, but didn’t mean anything to me yet. Now, as I prepare to leave Drupal - the Association, the community, the Con, the project - I can actually ‘do Drupal’ (albeit it on a Drupal 7 site, tsk tsk I know) and have such respect and care for the people that I have been lucky to work with from the community.

The journey from Point A to Point B, has been just that - a journey, with many steps in between.

My first DrupalCon was DrupalCon Los Angeles 2015 and it was full of firsts: the first time I met the Track Team who I had seen on the planning calls for months and who were surprised how short I was ‘in real life’; the first time I walked farther than a marathon in one single building; the first time I waltzed to the front of a session room to introduce myself to one of the many volunteer speakers to thank them for contributing; the first time I gained the understanding of how big, how passionate, how special this community was and how important DrupalCon was to all of them.

Since that Con, I have done my best to serve the community that makes Drupal so successful and special. There have been many volunteers, multiple Cons, too many emails to count, and a lot of smiles. As I prepare to step down from my role at the Drupal Association, there are many moments/projects that I am proud that we achieved together:

  • We’ve gone from not tracking diversity of our speakers at all to having our DrupalCon Seattle 2019 lineup be comprised of 50% speakers from underrepresented groups.
  • We held our first DrupalCon in India to serve an incredibly enthusiastic and growing community in what was one of my most memorable Cons ever.
  • We’ve taken the challenge of creating a sustainable and productive DrupalCon Europe and approached it with new eyes and ideas, to craft a new model that is community-driven and on course to be a great event to serve our European contributors.
  • We’ve continued to open our community to new and different audiences, working to create a welcoming environment along with relevant and compelling content for anyone who Drupal impacts- from the CTO to the content editor and marketer.

There are countless other moments that I also consider special - the hugs, the thank you notes that I’ve received, the inside jokes, the staff retreats, the volunteer dinners - thank you for those. In addition to the magic I have felt within our larger community, I also am grateful to the truly fantastic team at the Drupal Association who works to serve the community every single day; I am grateful to have worked with such talented, driven, and fun teammates.

My last day will be February 1, and between now and then I'll be reaching out to all the volunteers involved in the upcoming event to put you in touch with the great team that will succeed me. I am more than confident that the Association, the community, and the project will continue to grow, change, and prosper. Thank you for letting me be part of that, it has been a true privilege to serve you.

In my time here, I learned that to do well in my job, I needed to do my best for all of you. So even though I won’t see you at DrupalCon Seattle 2019, imagine me whizzing by you at speed-walk pace with a smile, shouting lovingly at you to squeeze in the group picture, or receiving a handwritten card from me thanking you for contributing to the Con.

Dries Buytaert: How to decouple Drupal in 2019

Main Drupal Feed - Thu, 01/24/2019 - 16:18

The pace of innovation in content management has been accelerating — driven by both the number of channels that content management systems need to support (web, mobile, social, chat) as well as the need to support JavaScript frameworks in the traditional web channel. As a result, we've seen headless or decoupled architectures emerge.

Decoupled Drupal has seen adoption from all corners of the Drupal community. In response to the trend towards decoupled architectures, I wrote blog posts in 2016 and 2018 for architects and developers about how and when to decouple Drupal. In the time since my last post, the surrounding landscape has evolved, Drupal's web services have only gotten better, and new paradigms such as static site generators and the JAMstack are emerging.

Time to update my recommendations for 2019! As we did a year ago, let's start with the 2019 version of the flowchart in full. (At the end of this post, there is also an accessible version of this flowchart described in words.)

Different ways to decouple Drupal

I want to revisit some of the established ways to decouple Drupal as well as discuss new paradigms that are seeing growing adoption. As I've written previously, the three most common approaches to Drupal architecture from a decoupled standpoint are traditional (or coupled), progressively decoupled, and fully decoupled. The different flavors of decoupling Drupal exist due to varying preferences and requirements.

In traditional Drupal, all of Drupal's usual responsibilities stay intact, as Drupal is a monolithic system and therefore maintains complete control over the presentation and data layers. Traditional Drupal remains an excellent choice for editors who need full control over the visual elements on the page, with access to features such as in-place editing and layout management. This is Drupal as we have known it all along. Because the benefits are real, this is still how most new content management projects are built.

Sometimes, JavaScript is required to deliver a highly interactive end-user experience. In this case, a decoupled approach becomes required. In progressively decoupled Drupal, a JavaScript framework is layered on top of the existing Drupal front end. This JavaScript might be responsible for nothing more than rendering a single block or component on a page, or it may render everything within the page body. The progressive decoupling paradigm lies on a spectrum; the less of the page dedicated to JavaScript, the more editors can control the page through Drupal's administrative capabilities.

Up until this year, fully decoupled Drupal was a single category of decoupled Drupal architecture that reflects a full separation of concerns between the presentation layer and all other aspects of the CMS. In this scenario, the CMS becomes a data provider, and a JavaScript application with server-side rendering becomes responsible for all rendering and markup, communicating with Drupal via web service APIs. Though key functionality like in-place editing and layout management are unavailable, fully decoupled Drupal is appealing for developers who want greater control over the front end and who are already experienced with building applications in frameworks like Angular, React, Vue.js, etc.

Over the last year, fully decoupled Drupal has branched into two separate paradigms due to the increasing complexity of JavaScript development. The so-called JAMstack (JavaScript, APIs, Markup) introduces a new approach: fully decoupled static sites. The primary reason for static sites is improved performance, security, and reduced complexity for developers. A static site generator like Gatsby will retrieve content from Drupal, generate a static website, and deploy that static site to a CDN, usually through a specialized cloud provider such as Netlify.

What do you intend to build?

The essential question, as always, is what you're trying to build. Here is updated advice for architects exploring decoupled Drupal in 2019:

  1. If your intention is to build a single standalone website or web application, choosing decoupled Drupal may or may not be the right choice, depending on the features your developers and editors see as must-haves.
  2. If your intention is to build multiple web experiences (websites or web applications), you can use a decoupled Drupal instance either as a) a content repository without its own public-facing front end or b) a traditional website that acts simultaneously as a content repository. Depending on how dynamic your application needs to be, you can choose a JavaScript framework for highly interactive applications or a static site generator for mostly static websites.
  3. If your intention is to build multiple non-web experiences (native mobile or IoT applications), you can leverage decoupled Drupal to expose web service APIs and consume that Drupal site as a content repository without its own public-facing front end.

What makes Drupal so powerful is that it supports all of these use cases. Drupal makes it simple to build decoupled Drupal thanks to widely recognized standards such as JSON:API, GraphQL, OpenAPI, and CouchDB. In the end, it is your technical requirements that will decide whether decoupled Drupal should be your next architecture.

In addition to technical requirements, organizational factors often come into play as well. For instance, if it is proving difficult to find talented front-end Drupal developers with Twig knowledge, it may make more sense to hire more affordable JavaScript developers instead and build a fully decoupled implementation.

Are there things you can't live without?

As I wrote last year, the most important aspect of any decision when it comes to decoupling Drupal is the list of features your project requires; the needs of editors and developers have to be carefully considered. It is a critical step in your evaluation process to weigh the different advantages and disadvantages. Every project should embark on a clear-eyed assessment of its organization-wide needs.

Many editorial and marketing teams select a particular CMS because of its layout capabilities and rich editing functionality. Drupal, for example, gives editors the ability to build layouts in the browser and drop-and-drag components into it, all without needing a developer to do it for them. Although it is possible to rebuild many of the features available in a CMS on a consumer application, this can be a time-consuming and expensive process.

In recent years, the developer experience has also become an important consideration, but not in the ways that we might expect. While the many changes in the JavaScript landscape are one of the motivations for developers to prefer decoupled Drupal, the fact that there are now multiple ways to write front ends for Drupal makes it easier to find people to work on decoupled Drupal projects. As an example, many organizations are finding it difficult to find affordable front-end Drupal developers experienced in Twig. Moving to a JavaScript-driven front end can resolve some of these resourcing challenges.

This balancing act between the requirements that developers prioritize and those that editors prioritize will guide you to the correct approach for your needs. If you are part of an organization that is mostly editorial, decoupled Drupal could be problematic, because it reduces the amount of control editors have over the presentation of their content. By the same token, if you are part of an organization with more developer resources, fully decoupled Drupal could potentially accelerate progress, with the warning that many mission-critical editorial features disappear.

Current and future trends to consider Over the past year, JavaScript frameworks have become more complex, while static site generators have become less complex.

One of the common complaints I have heard about the JavaScript landscape is that it shows fragmentation and a lack of cohesion due to increasing complexity. This has been a driving force for static site generators. Whereas two years ago, most JavaScript developers would have chosen a fully functional framework like Angular or Ember to create even simple websites, today they might choose a static site generator instead. A static site generator still allows them to use JavaScript, but it is simpler because performance considerations and build processes are offloaded to hosted services rather than the responsibility of developers.

I predict that static site generators will gain momentum in the coming year due to the positive developer experience they provide. Static site generators are also attracting a middle ground of both more experienced and less experienced developers.


Drupal continues to be an ideal choice for decoupled CMS architectures, and it is only getting better. The API-first initiative is making good progress on preparing the JSON:API module for inclusion in Drupal core, and the Admin UI and JavaScript Modernization initiative is working to dogfood Drupal's web services with a reinvented administrative interface. Drupal's support for GraphQL continues to improve, and now there is even a book on the subject of decoupled Drupal. It's clear that developers today have a wide range of ways to work with the rich features Drupal has to offer for decoupled architectures.

With the introduction of fully decoupled static sites as an another architectural paradigm that developers can select, there is an even wider variety of architectural possibilities than before. It means that the spectrum of decoupled Drupal approaches I defined last year has become even more extensive. This flexibility continues to define Drupal as an excellent CMS for both traditional and decoupled approaches, with features that go well beyond Drupal's competitors, including WordPress, Sitecore and Adobe. Regardless of the makeup of your team or the needs of your organization, Drupal has a solution for you.

Special thanks to Preston So for co-authoring this blog post and to Angie Byron, Chris Hamper, Gabe Sullice, Lauri Eskola, Ted Bowman, and Wim Leers for their feedback during the writing process.

Accessible version of flowchart

This is an accessible and described version of the flowchart images earlier in this blog post. First, let us list the available architectural choices:

  • Coupled. Use Drupal as is without additional JavaScript (and as a content repository for other consumers).
  • Progressively decoupled. Use Drupal for initial rendering with JavaScript on top (and as a content repository for other consumers).
  • Fully decoupled static site. Use Drupal as a data source for a static site generator and, if needed, deploy to a JAMstack hosting platform.
  • Fully decoupled app. Use Drupal as a content repository accessed by other consumers (if JavaScript, use Node.js for server-side rendering).

Second, ask the question "What do you intend to build?" and choose among the answers "One experience" or "Multiple experiences".

If you are building one experience, ask the question "Is it a website or web application?" and choose among the answers "Yes, a single website or web application" or "No, Drupal as a repository for non-web applications only".

If you are building multiple experiences instead, ask the question "Is it a website or web application?" with the answers "Yes, Drupal as website and repository" or "No, Drupal as a repository for non-web applications only".

If your answer to the previous question was "No", then you should build a fully decoupled application, and your decision is complete. If your answer to the previous question was "Yes", then ask the question "Are there things the project cannot live without?"

Both editorial and developer needs are things that projects cannot live without, and here are the questions you need to ask about your project:

Editorial needs
  • Do editors need to manipulate page content and layout without a developer?
  • Do editors need in-context tools like in-place editing, contextual links, and toolbar?
  • Do editors need to preview unpublished content without custom development?
  • Do editors need content to be accessible by default like in Drupal's HTML?
Developer needs
  • Do developers need to have control over visual presentation instead of editors?
  • Do developers need server-side rendering or Node.js build features?
  • Do developers need JSON from APIs and to write JavaScript for the front end?
  • Do developers need data security driven by a publicly inaccessible CMS?

If, after asking all of these questions about things your project cannot live without, your answers show that your requirements reflect a mix of both editorial and developer needs, you should consider a progressively decoupled implementation, and your decision is complete.

If your answers to the questions about things your project cannot live without show that your requirements reflect purely developer needs, then ask the question "Is it a static website or a dynamic web application?" and choose among the answers "Static" or "Dynamic." If your answer to the previous question was "Static", you should build a fully decoupled static site, and your decision is complete. If your answer to the previous question was "Dynamic", you should build a fully decoupled app, and your decision is complete.

If your answers to the questions about things your project cannot live without show that your requirements reflect purely editorial needs, then ask two questions. Ask the first question, "Are there parts of the page that need JavaScript-driven interactions?" and choose among the answers "Yes" or "No." If your answer to the first question was "Yes", then you should consider a progressively decoupled implementation, and your decision is complete. If your answer to the first question was "No", then you should build a coupled Drupal site, and your decision is complete.

Then, ask the second question, "Do you need to access multiple data sources via API?" and choose among the answers "Yes" or "No." If your answer to the second question was "Yes", then you should consider a progressively decoupled implementation, and your decision is complete. If your answer to the second question was "No", then you should build a coupled Drupal site, and your decision is complete.

Evolving Web: Insights Into The New Drupal Admin UI Design

Main Drupal Feed - Thu, 01/24/2019 - 14:17

We at Evolving Web are really excited to see the progress being made on improving the Drupal admin UI. As a designer, I’m curious about the process that drives such a huge project. I talked to the designer in charge of the refreshed interface, Cristina Chumillas, and got super interesting insights into what’s behind the new design.

Claro – fresh and clear

So far, Cristina and the team developed a new theme which is called “Claro”. The main UX problems in the existing admin UI have not been addressed yet. However, the visual refresh is already a great improvement! In Spanish, “Claro” means “clear” and this seems to be the main motivation.

The old admin interface (left) and the new UI design (right).

I especially like the new colour palette that is a literal refresh with grey tones that are slightly bluish and a primary blue that is very lively. Compared to the old warm colour scheme, this simple step results in a much more modern look. The contrast has been increased a bit, which has several positive effects. It helps create a clear hierarchy and, of course, it helps make the interface more accessible. 

Interaction Design Challenges

I asked Cristina about the biggest challenge in the redesign. She said that complying with the latest accessibility standards was a tough one. 

“We are not designing for a private company, we are designing for Drupal and this means for anyone. The design has to be accessible for anyone.”

One example Cristina gave me was the form field designs. The initial form fields were similar to those in the Material Design system, with the label inside the input field. Once you select the field, the label floats to the top. It is an elegant technique that has become popular over the last few years. However, Cristina remarked that this kind of animated form design caused a problem with accessibility.

“We decided not to implement something that is super fancy.”

I appreciate the fact that the team behind the new Drupal design puts the user front and centre. The purpose of the redesign is not to create something original for the sake of being extraordinary. On the contrary, the goal is a clear design that prefers well-known design patterns over personality. This doesn’t mean that they kept the old form UI, which was mainly the browser default. The new form design is simple, but clear and therefore very usable.

Form field examples of the old UI (left) and of the new design system (right).

  Hierarchy & Proportions

The new UI system is extensive. It includes different states of interactive elements which results in a very consistent design from page to page. Sometimes, these little details make a huge difference. Let’s compare the old and the new second-level of the toolbar. The size ratio between the font size and the icon is not very balanced in the current UI. The chevron buttons have the heaviest visual weight which makes it difficult for the active page to stand out. 

Old second level toolbar (left) and new toolbar (right)

The new design uses the primary blue for highlighting active states. The chevrons are simple and don’t draw too much attention. The third-level of the menu is visually separated by a light blue background which also communicates depth.

Typography – Fluid and Flexible

I asked Cristina what she enjoyed most during this project. She didn’t have to think long:

“Typography! – Something that I’m really looking forward to implementing is Fluid Typography.”

Fluid Typography is a CSS trick which adjusts the font size and line height based on screen size. Instead of jumping from one size to the next bigger size at a breakpoint, the changes are fluid. This creates a really smooth responsive web experience.

Image credits:

Cristina and her team decided to use system fonts instead of a brand typeface in the new UI. She told me that it’s not about branding when you create a functional user interface. They didn’t want the typeface to take too much attention. Cristina pointed out that it is the functionality and usability of software like Drupal that counts. A smooth user experience with the application itself is more important than the branding. Besides, other elements such as the colour palette help with the recognition of the brand.

“Using system fonts feels more natural, more like working with your system and for the user it is not really important that it is Drupal or something else. It is just a tool.”

System font examples (Apple, Windows Vista and KDE)

Another reason for the use of system fonts, Cristina told me, is that sometimes the font is changed to the system font anyway, for instance in other languages that are not included in the character set. Depending on the language, the range of word length is huge as well. When designing an interface like Drupal, you have to keep it flexible anyway.

“There are some languages that are short, and then there is German…” 

As a last question, I asked Cristina, if she had one ultimate tip for other designers to improve their UI design. Her advice was: “Keep in mind that when we are dealing with content management UI, it is not about advertising, not about branding. UI should not be invisible, but it should serve a purpose.” 
“It should serve the user needs?” I suggested.
“Exactly! The [admin] UI should be useful for creating content – in our case, because that’s what Drupal is for – instead of being super fancy.”

About Cristina and the team

Cristina Chumillas is a very experienced designer with a background in graphic design and frontend development. She has been active in the Drupal community for many years and works as Creative Director and partner at Ymbra, a Drupal web agency based in Barcelona. The other designers contributing to the Claro theme are Sascha Eggenberger, Archita Arora as well as Dennis Cohn.

Next steps

Following the work on these visual improvements, the team will continue with this user-centered approach and address functionality issues. Suzanne and I helped figure out usability problems in different CMS’s in a comparative study in November and are currently working on a follow-up study to gather more data about how editors create more complex content. Cristina told me that our findings will help guide the the user experience of the Drupal admin interface. We can’t wait to see the results of the next steps!


+ more awesome articles by Evolving Web

OpenSense Labs: Blend of VueJS and Drupal

Main Drupal Feed - Thu, 01/24/2019 - 13:55
Blend of VueJS and Drupal Shankar Thu, 01/24/2019 - 19:25

That’s a beautiful view!”, you exclaim when you witness the sunset while standing on a beach with waves touching your feet. That is when you come out of the rut, leave behind the humdrum life of city and ‘really’ feel a natural beauty. There is another view in the digital landscape that will make you exclaim, “wow!”, and that is Vue.

Vue.js is fantastic for developers to build applications faster and make it more attractive and user-friendly. In combination with Drupal, one of the leading open source content management systems, Vue JS can be a brilliant option for web development needs.

A trip down memory lane: JavaScript frameworks

JavaScript framework is great for creating modern applications. There is an interesting piece from freeCodeCamp on JavaScript’s development and how it came through.

Browsers that we see today are did not have the sort of functionalities until the early 2000s. They were much less powerful and, performance-wise, there was no feasibility in creating intricate applications inside them.

Introduction of Google Maps and Gmail, that ran inside the browser, started bringing in the much-needed change. Asynchronous network requests were made a reality by Ajax. Eventually, development started happening on top of the web platform while the platform itself - that constitute browsers, the web standards, the browser APIs, and the JavaScript language - was being worked upon by engineers.

First major projects developed upon JavaScript were libraries like jQuery and Mootools that offered a nicer API for interacting with the browser in addition to the provision for solutions to bugs and inconsistencies among numerous browsers. Then, Backbone, Ember, Knockout among others burst onto the scene as modern JavaScript frameworks followed by React, Angular and Vue which have gained popularity in recent times.

The rise of VueJS

VueJS is one of the popular JavaScript frameworks. The official site of VueJS states that it is a progressive JavaScript framework that is used for developing user interfaces. In complete contrast to monolithic frameworks, it is incrementally adoptable and its core library emphasises on the view layer and can be easily incorporated with other libraries or existing projects. It is an astounding solution for intricate single page applications when leveraged alongside modern tooling and supporting libraries.

The usage of VueJS has seen a tremendous rise over the years as represented in the graph below.

Usage statistics of VueJS | Source: BuiltWith

VueJS scores heavily when it comes to high traffic websites. Organisations in need of a web development solution that can scale well during a high spike in traffic are opting for VueJS as can be seen in the graphical representation below.

Meritorious features of VueJS

Following are some of the benefits of VueJS:

Smaller in Size

A JavaScript framework triumph depends upon its size. Size of the JavaScript framework is directly proportional to its usage. With that being said, VueJS is very beneficial with its small size. The size of the VueJS framework is around 18-21KB which means it does not take much of your time while downloading and using it. Small size has no effect on the speed as it is fast and snappy.

Easy development

Adding Vue to an existing web project is quite easy and you can begin coding very swiftly without the need for knowing anything about JSX, ES2015 or build systems to get started. Familiarity with HTML and JavaScript in addition to reading their guide can assist in building something basic within a day that is very advantageous for a fast-paced development team where you are required to pick up something very quickly.

Moreover, it has a simple structure which is great for both small and large scale template development and saves a lot of time as a result. You can even trace the blocks with errors due to its simple structure.

Easy integration

It facilitates developers while integrating with existing applications which makes it a great prospect for developing new web applications and changing the pre-existing applications. The integration is possible because it has components for everything.

Exhaustive Documentation

The documentation of VueJS is very detailed, simple to understand and constitutes several code examples. It has a growing community of developers that can assist when needed.

Immense flexibility

It is simpler to write an app with VueJS swiftly and run it straight from the browser. Or you can even develop an intricate application leveraging ES6, JXX, components, routing, bundling among others. You can even write a template in HTML or in JavaScript or you can use JSX. You get the liberty to structure the application in a way that suits you.

Model-view-viewmodel architecture

Its MVVM architecture (Model-view-viewmodel) helps in facilitating two-way communications for easy management of HTML blocks.

Implementing VueJS with Drupal

Like VueJS, Drupal is very scalable and has been powering high-traffic websites around the world. It also has been outperforming other leading content management frameworks in this criteria.

The blend of Drupal and VueJS, which are both preferred for their scalability, can be a remarkable option. 

One of the ways of utilising VueJS with Drupal is the development of single page application as we have discussed in an earlier blog. It involves the installation of Drupal 8 on the local system followed by the creation of custom content types, adding views, and enabling REST API.

Then, you can start building front end with VueJS and create single page application. This would involve setting up of Vue project with Vue CLI. Once this is done, the addition of Vue router and Vue resource is performed. Vue router, the official router for VueJS, deeply integrates with VueJS core is similar to the angular router (of Angular JS) and react router (of React JS). Vue resource is the plugin for VueJS that offers services for making web requests and govern responses. Then, you can start modifying main.js file to use Vue routers and Vue resources and modify the app.js to work with the router followed by setting up of app components and routers.

Use case

Arbetsförmedlingen, Swedish Public Employment Service, benefitted from the amalgamation of Drupal and VueJS. Drupal Europe 2018 had a session that talked about how a video platform that was built for the Swedish government.

The platform used podcasts, video on demand and live broadcast for the dissemination of their content. They needed a new platform where these different sorts of media could be imported and metadata could be added for easily grouping them and filtering them out.

Drupal was the ultimate choice because of its great content management system, robust multilingual support, user management, and open source platform. Being lightweight with a production-ready build, VueJS was chosen as the desired JavaScript framework. Its compatibility with twig was a bonus. So, development recipe constituted Drupal, the combination of VueJS and twig and an API endpoint.

RESTful Web Services and Serialisation modules were enabled that gave the ability to create normal views as REST export and Axios, a promise-based HTTP client that has an easy-to-use API and can be leveraged in both the browser and NodeJS, was used for the consumption of data. Theme structure comprised of the twig, JS and CSS. Pluggable VueJs components were utilised and event handling configuration was shown through ‘Load More’ button.


The amalgam of Drupal and VueJS can be a rewarding solution that can help fulfil your digital transformation dreams.

We are devoted to providing ambitious digital experience to our partners through a suite of services.

Ping us at to get the best out of Drupal and VueJS amalgamation.

blog banner blog image VueJS Drupal 8 Blog Type Articles Is it a good read ? On

WPTavern: WordPress Names Josepha Haden New Executive Director, Joost de Valk Marketing and Communications Lead

Wordpress Planet - Wed, 01/23/2019 - 22:23

During the 2018 State of the Word address, Matt Mullenweg acknowledged lessons learned in the process of releasing WordPress 5.0. One of those was the need for various teams across the project to work together better. The friction during the 5.0 development cycle was beneficial in that it surfaced areas where the project can grow and sparked conversations that are already leading to improvements.

Last week Mullenweg announced that WordPress is expanding its leadership team to include Josepha Haden in a new Executive Director role and Joost de Valk as the Marketing and Communications Lead. These new roles better distribute project leadership to more individuals who have demonstrated the ability and judiciousness to guide large, diverse teams towards success. Haden will be overseeing WordPress’ contributor teams and de Valk is leading the marketing team and overseeing improvements to WordPress’ websites and other outlets.

The Executive Director role is particularly critical for the health of the project, as contributor and community feedback pours in across so many different mediums. Tracking all of this information and taking it into consideration amounts to a full-time job. In her first week in the new role, Haden is seeking feedback regarding the challenges contributors face when working on the project. She identified seven challenges which seem to resonate with many who have commented:

  • Coordinating on collaborative work between teams
  • Aligning our work better to project goals/values
  • Understanding team roles, leadership structures, and decision making
  • Clarifying the differences between open source and open commit
  • Tracking conversations and progress across the project
  • Raising project-wide concerns more easily
  • Improving how we recognize and celebrate success

Responses from contributors have so far revolved around a similar theme – the desire for more clearly-defined projects and goals for teams, along with more communication from leadership.

“Define goals and deliverables for each project deliverable,” Daniel Bachhuber suggested. “Once these are defined, it’s much easier to estimate the level of effort and resources required. Distinguish between full-time sponsored, part-time sponsored, and completely volunteer labor. Each of these three do not work at the same pace. It’ll be much easier to estimate a team’s velocity if you know what type of labor you have to work with.”

Meagen Voss offered some valuable insight from a newer contributor’s perspective. She said the leadership of the project is very unclear and that people could benefit from that information being more prominently published. She also suggested that WordPress explore the idea of having ambassadors for each team to facilitate communication and collaboration across projects.

You get to know your team very well, but no so much other teams. I’ve met some great folks in Slack and am getting to know the two groups I’m involved in super well. But if I have an issue or a question that needs to be addressed to another group, then I would have to hang out in that team’s channel for a while to figure out who the right person is to get in touch with. Identifying “ambassadors” or points of contact for each group could be a quick and helpful way to address that.

The conversation is still open for contributors to jump in and share their own challenges and suggestions. Haden plans to follow up with the next steps after gathering more feedback. Action born out of these conversations has the potential to greatly improve contributors’ experiences working together, resulting in fewer people burning out on communication struggles or losing momentum from lack of clearly defined objectives.

Matt: Thich Nhat Hanh on Tea

Wordpress Planet - Wed, 01/23/2019 - 21:27

Drink your tea slowly and reverently, as if it is the axis on which the world earth revolves – slowly, evenly, without rushing toward the future.

— Thich Nhat Hanh in The Miracle of Mindfulness

Promet Source: Better Instructions for Your Drupal Content Types

Main Drupal Feed - Wed, 01/23/2019 - 19:40
Besides Title, the most common field label found on a content type form is Body. Of course, this is where you place the body of your content. It’s your blog post, your how-to instructions, or maybe an event description. You know exactly what needs to be provided in this field because you are the trained author. What happens when the scenario includes many authors with varied skills? Without clearly visible instructions for the form and the form fields, content authors can make mistakes. There are four default features in Drupal 8 that provide instructions for content authors.

OPTASY: Progressively Decoupled Drupal: Moving Towards a Standard Workflow

Main Drupal Feed - Wed, 01/23/2019 - 17:11
Progressively Decoupled Drupal: Moving Towards a Standard Workflow silviu.serdaru Wed, 01/23/2019 - 17:11

Progressively decoupled Drupal has gone from concept to buzzword. Until recently, when we've started to witness sustained efforts being made to set up a standard workflow for implementing this architecture.

New dedicated modules have been developed to fit those use cases where just a few particular blocks, affecting the website's overall performance, need to be decoupled. All while preserving Drupal's standard robust features.

Features too famous among content editors and site builders to be sacrificed in the name of high speed and rich UX. 

We've gradually shifted focus from “Why would I choose progressive decoupling over a headless CMS?” to:

Mediacurrent: Contrib Half Hour updates for 2019

Main Drupal Feed - Wed, 01/23/2019 - 16:40

Just over a year ago I decided to repurpose an internal contrib-focused meeting and make an open meeting to support contributing to Drupal, called the Contrib Half Hour. Along the way we moved its time a little later to avoid conflicting with another important community initiative and then restructured it to add focused meetings for certain topics. To make things even better, almost all meetings have been recorded and uploaded to our Youtube channel. 2019 is going to see some additional changes that I'm excited to start on.

Our Q&A have issues

Throughout the year it became apparent that there was a huge overlap between the Q&A meetings, where we'd focus on general questions and discussions from the community, and the issues lab, where we'd focus on specific project issues. While there's definitely a case for both, the overlap became somewhat naturally as the Q&A days had us often look at Drupal issues.

As a result of this we're going to combine the Q&A and Issues Lab days into one that'll be more open ended, letting us focus on general discussions some days and specific issues other days.

The testing shall continue until code improves

We're also continuing our dedication to helping people learn how to write code tests for their modules and themes. While during 2018 we focused on functional testing for Drupal 7 and 8, I'm aiming to expand our coverage (ba-dum-dum) in 2019 to also include unit testing.

I'd also like to open an invitation for folks to join our testing lab who are starting to write tests to join our labs where we'll be able to help.

Upgrade Lab: Time to upgrade

It was announced late last year that Drupal 9 will be released in June 2020 and that Drupal 7 and 8 will reach their end-of-life in November 2021. The main driving factor behind these dates is that the various libraries Drupal 7 and 8 depend upon will all have reached their end-of-life in November 2021 and so will no longer receive security updates from their respective maintainers. To avoid needing to come up with a plan to provide security coverage for a huge number of out-of-date 3rd party libraries, the Drupal core maintainers are dropping support when the other libraries also stop being supported.

It was also revealed that the usual upgrade anxiety for major releases of Drupal (5 to 6, 6 to 7, etc) would not be the case for Drupal 9. The plan is two release Drupal 9.0.0 and the final minor release of Drupal 8 on the same day, with the only difference being that all deprecated D8 APIs are removed from D9. As a result it will be relatively easy to upgrade from Drupal 8 to 9, “just” update all contrib code and custom code to no longer use the deprecated APIs along the way, and in theory everything should just work.

With this in mind we think it's time for people running Drupal 6 and 7 sites to start looking to upgrade to Drupal 8. Towards that goal we're going to have a regular meeting where we look at the steps to upgrade a site to Drupal 8 using the bundled Migrate system. We'll look at what's involved, how it works, how to plan for it, and how to help contributed modules support Drupal 8's upgrade solution. I'm intending that we'll be able to collaborate on improving both core and contrib's upgrade functionality, and in so doing help all sites looking to upgrade. I'm also hoping that we might be able to provide some assistance to folks attempting custom upgrades using Migrate's APIs, but we'll see how it goes.


Our schedule for the next few months looks like this:

  • January 3: Q&A
  • January 10: Turning custom code into OSS
  • January 17: Q & A & Issues
  • January 24: Testing Lab
  • January 31: Upgrade Lab
  • February 7: Presentation TBD
  • February 14: Q & A & Issues
  • February 21: Testing Lab
  • February 28: Upgrade Lab
  • March 7: Presentation TBD
  • March 14: Q & A & Issues
  • March 21: Testing Lab
  • March 28: No meeting
  • April 4: Upgrade Lab
  • April 11: Presentation TBD
  • April 18: Q & A & Issues
  • April 25: Testing Lab
  • May 2: Upgrade Lab
  • May 9: Presentation TBD
  • May 16: Q & A & Issues
  • May 23: Testing Lab
  • May 30: Upgrade Lab
Same Bat Time!

We're going to continue meetings at the same time each month, using the same video conferencing provider:

And remember, if you're not able to join us then you can always catch up later as all meetings are recorded, when I don't forget to hit the record button that is.

See you then!

Chromatic: Getting Ready for the Drupal Global Contribution Weekend

Main Drupal Feed - Wed, 01/23/2019 - 16:26

This coming weekend is the Drupal Global Contribution Weekend where small local contribution groups volunteer their Drupal development at the same time throughout the world. This year there are local groups gathering in Canada, England, Germany, India, Russia, Spain, and the United States.

TIP Solutions: Hotellinx ERP system to Drupal Commerce integration

Main Drupal Feed - Wed, 01/23/2019 - 12:24
The task was to integrate an ERP system (more specific Hotel management system called Hotellinx) which is (and should always stay or be) a single source of truth (SSOT) for the products they have and administer. If you want to sell these products from another system like a webshop you need to transfer the data there to showcase your goods to customers. Another way of explaining that is to say the webshop is only to make a purchase but all the data is stored to the ERP system or SSOT. Planet Drupal Drupal 8 hotellinx Integration Commerce

ADCI Solutions: Getting started REST API with Symfony 4

Main Drupal Feed - Wed, 01/23/2019 - 10:24

We fell in love with Symfony back then when its components were added to Drupal 8. We keep on learning and teaching how to use this powerful PHP framework for projects with complicated business logic.
In this Symfony 4 tutorial, we will create a basic server back-end structure for your application using the REST API architecture style. 

Sounds fun? You may find the article here.  


OSTraining: How to Rewrite the Output of Views Fields in Drupal

Main Drupal Feed - Wed, 01/23/2019 - 10:06

One of our customers asked how to tweak the fields of a table output by Views to give the table a cleaner look.

They were looking for a way to merge the fields of the first and second columns. They also wanted to display the file download link just with an icon.

There are a couple of ways to achieve this. One of them is to rewrite the output of Views’ fields.

This tutorial will explain how to rewrite the results of any Views’ field. We can rewrite the results, regardless of what display the view is using (table, list, grid, etc).

WPTavern: WooCommerce Launches New Mobile Apps for iOS and Android

Wordpress Planet - Wed, 01/23/2019 - 05:35

This week marks the first public release of WooCommerce’s new mobile app for Android and the improved version for iOS. WooCommerce began beta testing the Android app late last year and the original iOS app has been updated to offer the same features.

This first release should be considered a basic start that is mostly useful for tracking store performance with detailed stats and getting alerts for new orders and product reviews. Users cannot add or edit products and the app does not yet allow for switching between stores. The first release offers basic order management and fulfillment but does not include the ability to change order status. The mobile apps don’t yet live up to their tagline of “Your store in your pocket,” but it’s a good starting place.

According to the Google Play Store, the WooCommerce app has been installed more than 10,000 times and the response from users has been mixed. The app is averaging a 2.5-star rating after early reviews from 45 users. The iOS app has received similar responses. Many of the negative reviews are due to connection/login issues and the requirement for stores to use Jetpack.

“This has promise, but get rid of the need for Jetpack,” one reviewer wrote. “There are other secure ways of syncing up. Other apps have done it for years. This app has been long overdue, but is poor in execution when you need to install a plugin that tends to bog down your site and that most don’t need. Give an alternative means of syncing and allow us to edit at least the basics of a product on the go.”

WooCommerce marketing representative Marina Pape explained the Jetpack requirement in a post announcing the mobile apps’ launch:

The Jetpack plugin connects your self-hosted site to a account and provides a common authentication interface across lots of server configurations and architectures.

Both Apple and Google only allow a single trusted sender for pushes for security reasons (read more), making Jetpack the best way for us to give you modern mobile app features like push notifications.

In order to connect sites with the app, Jetpack creates a shadow site on’s servers and syncs quite a bit of data. Although this list of data is transparently outlined, the Jetpack requirement is a deal breaker for some users. They either object to sharing their data or believe the plugin will slow down their stores. Until the app’s features are more compelling than the detriments users perceive in Jetpack, it may lose a few users based on this requirement.

According to BuiltWith, WooCommerce is now the most popular shopping cart technology used by 22% of the top 1 million websites, with competitors Shopify and Magento not too far behind at 17% and 13% respectively. Having a new mobile app should help WooCommerce remain competitive, but the team needs to keep iterating on the app to make it more useful for those managing stores on the go.

WPTavern: Gutenberg Phase 2 to Update Core Widgets to Blocks, Classic Widget in Development

Wordpress Planet - Tue, 01/22/2019 - 21:11

Gutenberg phase 2 development is underway and one of the first orders of business is porting all existing core widgets to blocks. This task is one of the nine projects that Matt Mullenweg outlined for 2019, along with upgrading the widgets-editing areas in wp-admin/widgets.php and adding support for blocks in the Customizer.

Contributors on phase 2 are also developing a Classic Widget, which would function as a sort of “legacy widget block” for third-party widgets that haven’t yet been converted to blocks. There may be many instances where plugin developers have not updated their widgets for Gutenberg and in these cases their plugins would be unusable in the new interface without the option of a Classic Widget. This block is still in the design stage.

The widgets.php admin page will need to be completely reimagined as part of this process. Mark Uraine, a designer who works at Automattic, created some mockups to kick off the discussion about what this screen might look like.

These mockups are just explorations of where widgets may be headed next, and they do not take into account everything that will be required of this screen.

Nick Halsey, one of the maintainers for WordPress’ Customize component recommended abandoning this screen altogether in favor of showing widget block areas in the Customizer:

The widgets admin screen has a fundamental disconnect with the way that widget areas actually work – with different areas showing in different parts of the screen and potentially on different parts of the site. It will be very difficult to clearly reflect the frontend page structure on this screen in a way that users will be able to understand. Experimenting with contextual approaches to this experience in the customizer offers numerous opportunities for this fundamental problem to be solved. Starting with the visible edit shortcuts that are already in core, revamped widgets could be edited directly on the frontend (of the customize preview) or in an overlay that is more directly related to the display on a particular screen. The ability to navigate to different parts of the site within the customize preview solves a problem that this screen will never be able to address.

Getting blocks to work in the Customizer is also part of phase 2, but conversation on the ticket related to wp-admin/widgets.php indicates the team is not going to abandon this screen just yet.

“While this screen will eventually be deprecated in the future, especially as more of the site is built in Gutenberg, it’s a necessary “baby step” to get us all there together,” Uraine said. “Maybe the best thing is to keep the existing layout, but just allow the use of all blocks within the accordion content areas? This will keep our resources and investment minimal on this particular piece with just a few suggested tweaks to the mockup in the initial post. It will also allow us to move to the Customizer more quickly.”

Gutenberg accessibility contributor Andrea Fercia encouraged contributors to address accessibility before creating visual mockups by designing the information architecture first. He encouraged them to organize the required information and controls while thinking about how someone might navigate them in a linear way.

“The customizer is not fully accessible,” Fercia said. “The admin widgets screen is the only place where persons with accessibility needs have a chance to manage widgets without having to face big accessibility barriers.”

Discussion on the future of the widget management screen continues in the ticket and contributors are looking to get more input during this exploration stage. There’s also a project board where anyone can share a blog post with their own explorations.

Porting widgets to blocks has its own project board if you want to follow along or jump in on an issue. Most of the core blocks are already finished and a handful are still in progress.

Updating the widgets management page and bringing blocks into the Customizer is a major overhaul but will further unify WordPress’ interface for editing and previewing content. Widgets have served WordPress well over the years, making it easy for users to customize their websites without having to know how to code. The feature has also survived many evolutions, eventually making its way into the Customizer five years ago in WordPress 3.9. One of the limitations with widgets is that they can only be used in “widgetized” areas. Transforming widgets into blocks removes that limitation and makes it possible to use widgets in posts and pages as well.

Virtuoso Performance: Announcing the Soong project - developing a general-purpose ETL framework

Main Drupal Feed - Tue, 01/22/2019 - 20:10
Announcing the Soong project - developing a general-purpose ETL framework mikeryan Tuesday, January 22, 2019 - 02:10pm

I'd like to invite members of the open-source community, particularly (but not exclusively) those involved with PHP, to join in designing and developing a general-purpose ETL framework for data migration. The vendor name for packaging components of this project is soong, and git repos for existing components are under the GitLab account "soongetl".

Note: Finally having finished composition of this lengthy monologue, it's clear to me that it's very ambitious (some might say arrogant) of me to write with the expectation that this will grow into a large and robust open-source ecosystem. Very well - it is ambitious, and the effort may very well fall flat on its face. C'est la vie...

Who am I?

I'm Mike Ryan - a lot of people in the Drupal community know me, but not so much the wider open-source community. Almost eleven years ago at a Drupal meetup in Boston, amongst general agreement that everyone hates to do data migration, Moshe Weitzman looked across the table at me and said "there's an opportunity here." Since then data migration into Drupal has been the primary focus of my professional life, first in partnership with Moshe, then as an Acquia employee and finally as a solo consultant. Over the years I've created several migration-related contrib modules for Drupal, was part of the team integrating migration into Drupal core for D8, and have been involved in dozens of real-world migration projects.

Why am I doing this? I think we can do better

Just within Drupal, the migration framework can be improved:

  1. Each step of Drupal migration support has been a port of the previous - from the hook-based Drupal 6 version, to the inheritence-and-composition model in Drupal 7, to the plugin-based system in Drupal 8, technical debt has accumulated. I've wanted for a while to start over with a clean slate - given my experience (and others), what would we do differently starting from scratch? Can we step back and re-examine the assumptions we've been carrying forward?
  2. At a specific technical level, the biggest itch I've wanted to scratch is decoupling the components. Within the migration system as it is in D8 today, pretty much every component knows everything about every other component. At one point we had a destination plugin which was using some of the migration's source plugin configuration - that one made my eye twitch!
  3. There's also the coupling of the migration system with Drupal - in particular, migration classes *are* Drupal plugins (i.e., their interfaces extend PluginInspectionInterface) rather than being *managed by* Drupal plugins. I would like to see migration classes be all about migration, rather than worry about being plugins as well. And once the basic migration classes are no longer Drupal plugins, then it's a small step to them being entirely independent of Drupal...
The larger PHP community

With Drupal 8, we’ve often talked about “getting off the island” in terms of benefiting from much fine PHP work done outside of the Drupal community. We haven’t talked so much about going in the opposite direction - making our own fine work available for use beyond Drupal. To my knowledge, the only published example of this so far is Kris Vanderwater (EclipseGC) with the plugin library.

Likewise, we Drupal developers don’t have a monopoly on good migration ideas - by moving the general-purpose aspects of migration into a separate open source project, we have the opportunity to benefit from new ideas and new talent.

The community we build

The major key to success for any large open-source project like this is a thriving community. After seeing open-source projects like Drupal grow organically - and face growing pains as they find themselves dealing with community problems reactively rather than proactively - if a community does form around this project, I would like to establish a supportive and welcoming tone from the beginning.

Diversity in particular remains an issue in the tech industry in general, and open-source especially - and a lack of diversity is difficult to correct after the fact. In building a community around this framework, my hope is that we draw a diverse set of developers in the beginning, in the hopes that seeding the garden well will be, if not self-sustaining, at least more sustainable. How to do that, I'm not certain - a concerted outreach effort could easily end up looking like Pokemon Go, searching for unique creatures to collect. Apart from starting with a good Code of Conduct, I'm open to suggestions!

Another aspect of community-building is providing opportunities for relative novices (whether new to open-source development, new to PHP, or new to migration). The proposed architecture involves myriad small, well-focused packages - an extractor here, a set of related transformers there, integrations for specific frameworks and APIs... Individual transformers, in particular, will generally be very simple. This ecosystem thus will provide ample opportunities for novices to gain experience with mentorship and also establish an online presence.

Now, all that being said, what about The Ethics of Unpaid Labor and the OSS Community (also see the recent Twitter discussion in the Drupal community)? In reaching out to underrepresented groups and to novices, we are reaching out to the people who have the least ability to work on open source for free. One way to ameliorate this effect may be to explicitly try to draw in students - whether in formal programs or teaching themselves software development - who will benefit from some free practical education and mentorship. Down the road, if this framework does start being adopted in real-world applications, we can look at ways to get sponsorships for people who maintain projects within the ecosystem. At any rate, as the community here grows I expect this will be an ongoing conversation.


Yes, I'm willing to cop to selfish reasons to pursue this.

  1. Simple ego: I'm proud of the work I've done on migration in Drupal, and think it can be useful on a larger stage. Being old enough to see retirement on the horizon, I admit I'm thinking of this as my magnum opus - the last major contribution I make to open source. I would love to leave behind a significant piece of quality software with a vital community behind it.
  2. Money: I've done fine as a Drupal data migration specialist. I hope to do better by expanding my market beyond Drupal, working on a wider variety of migration projects. Yes, retirement is on the horizon but, given earlier attempts at consulting which went less well than my "migration period" has, my funds put that horizon farther out than I'd like...
What's done so far?

Early last year I started playing around with a proof-of-concept in a single repo, getting a single basic ETL migration scenario running with a decoupled class structure based on the basic architecture of the Drupal migration system. Much of the work after getting the initial POC running was figuring out appropriate boundaries between components, and gradually introducing features beyond the most basic ones I started with. And then breaking pieces out into separate source repos, and figuring out those boundaries.

My role

This will certainly change according to the number and skills of contributors who join into this effort (assuming there are some!), but what I'm aiming for in terms of my own role:

  1. Primary architect of version 1 of Soong. This would mean being the primary maintainer of architecture documentation and the repository of central interfaces/base classes. Per "selfishness" above - I have an architectural vision I want to see brought to fruition. Others may take it in different directions after that, but V1 is mine! tl;dr - I don't want to be BDFL; I do want to be BDF1.
  2. Community leader. Per "community" above, I have a vision for building a diverse and vibrant open-source community from the ground up. Unlike the technical architecture, however, this plays less to my strengths, so I will be happy to defer as better-suited people show leadership in the community.
  3. Mentorship. I'd like to help people up their development skills, their open-source involvement, and their understanding of the pits and perils of data migration.
Why did it take me so long?

After having it in the back of my head for a few years, I finally started creating repos and putting my thoughts into actual interfaces and classes several months ago. Why did I wait until now to share my work with the larger community? I certainly felt seen when I read this:

Frankly, there's an element of imposter syndrome here - I wanted to be sure I wasn't exposing any dumb ideas! Well, enough of that - instead, I now stipulate that you will find dumb things I did here, and ask that you help smartify them.

The architecture itself

There's a ways to go documenting the architecture as it is currently implemented in soong/soong, but right now it broadly looks like this:

  1. A Task accepts configuration defining a migration process, and implements operations - most notably migrate, but it may also support other operations like rollback, status, analyze, … The following steps describe the migrate operation.
  2. The task constructs the configured Extractor, which obtains data from a source such as a SQL query, a CSV file, an XML/JSON API, etc.
  3. Iterating over the extractor returns one DataRecord (collection of named DataProperty instances) at a time containing source data. The task creates an empty DataRecord representing the destination data.
  4. The task configuration defines a transform pipeline keyed by destination property names. For each of these properties, a sequence of one or more Transformer classes with corresponding configuration is invoked to determine the destination property value - usually, the first one will be configured to accept one or more source property names, and the results will be fed to subsequent transformers, with the final result assigned to the named property in the destination DataRecord.
  5. The destination DataRecord is passed to the configured Loader to be loaded into the destination store - a SQL database, a CSV file, etc.
  6. If an optional KeyMap is configured within the task, it is used to store the mapping from the source record's unique key to the destination record's unique key. This enables keyed relationships to be maintained even if keys change when migrating, as well as enabling rollback.

To try out a couple of working demos, git clone and follow the README.

Initial technical priorities
  1. One of those infamous hard problems in computer science is naming things. Before we go too far, let's figure out how best to name things - I think Extractor/Transformer/Loader are pretty solid, but let's discuss whether other components (like Task) could use better names. Also, let's decide what naming conventions for implementations should look like - e.g., should CSV extractor and loader classes both be named CSV (or for that matter, Csv) with namespaces alone distinguishing them, or should they be CSVExtractor and CSVLoader?
  2. The initial architecture, as I've said before, comes from my narrow experience in Drupal. I'm sure there are plenty of other good migration ideas out there - maybe there's even a package I've missed that's good enough that this effort would better be directed towards improving it rather than starting from scratch. I did do some research last year and did not find any PHP ETL packages that appeared to have wide adoption or as much flexibility, but with more eyes on it (eyes that have seen more beyond Drupal than I have) let's see if we can do a thorough review of prior art and see if there are some good ideas which may influence this effort. And let's look beyond PHP as well - are there ETL frameworks written in other object-oriented languages which may provide some architectural inspiration?
  3. Review the boilerplate for Soong code repos (based on - let's go over what we've got there (especially the code of conduct and contributing guidelines).
  4. Test all the things! Before adding new stuff, we need to add tests for the existing components, and set up automated testing on Gitlab.
Technical goals
  1. For V1, require PHP 7.1 and leverage strict type checking. I expect future versions to require PHP 7.4 and leverage typed object properties.
  2. The central interface package soong/soong ideally should not depend on anything other than PSR interfaces. It should be approached as if it were a PSR itself - a completely general interface for ETL functionality not dependent on any non-standard interfaces.

Again, I know I am getting way ahead of myself here by imagining an active open-source community will quickly spring up here. I have talked to Drupal people about my ideas on occasion, and I expect there will be some interest there, but I very much hope other open-source developers can join this effort and provide different perspectives. I do believe strongly that a standard ETL library with a core of simple standard interfaces (making a simple move-my-stuff-from-here-to-there application a breeze) plus the flexibility to build complex systems to handle many types of data will be extremely valuable across many domains.

If I may try your patience a bit longer - I've spent a substantial portion of my time since my last contract pulling these thoughts together, and I am now in need of paid work (contact me if you need some data migration done!). I may fantasize about being sponsored to work fulltime on Soong, or be hopeful there's someone with a project that they think will benefit from Soong and thus I can make progress here in the course of solving their migration problem. Realistically, my next contract (or employment) most likely will not involve Soong development, so once I'm working I won't have as much time to manage this project - let's hope plenty of people join in to pick up my slack!

If you've made it this far, thank you for your time and I look forward to your merge requests!

Tags Drupal Planet Drupal PHP Migration Use the Twitter thread below to comment on this post:

— Virtuoso Performance (@VirtPerformance) January 22, 2019

Manifesto: Grow as a Drupal developer: embrace the community!

Main Drupal Feed - Tue, 01/22/2019 - 14:24

So far in our series of posts about helping you become a better Drupal developer,  we’ve talked a lot about contribution from an individual point of view. But Drupal is community first! Even if you believe you’ve already reached your potential as a developer, remember people before you said and subscribed to the motto:  Come. Continue reading...

The post Grow as a Drupal developer: embrace the community! appeared first on Manifesto. Review driven development?

Main Drupal Feed - Tue, 01/22/2019 - 11:06

We've heard of test-driven development, behaviour-driven development, feature-driven development and someone has probably invented buzzword-driven development by now. Here's my own new buzzword phrase: review-driven development. At ComputerMinds, we aim to put our work through peer reviews to ensure quality and to share knowledge around the team. Chris has recently written about why and how we review our work. We took some time on our last team 'CMDay' to discuss how we could make doing peer reviews better. We found ourselves answering this question:

Why is reviewing hard? How can we make it easier?

We had recently run into a couple of specific scenarios that had triggered our discussion. For one, pressure to complete the work had meant reviews were rushed or incomplete. The other scenario had involved such a large set of code changes that reviewing them all at the end was almost impossible. I'm glad of the opportunity to reflect on our practice. Here are some of the points we have come away with - please add your own thoughts in the comments section below.

1. Coders, help your reviewers

The person that does the development work is the ideal person to make a review easy. The description field of a pull request can be used to write a summary of changes, and to show where the reviewer should start. They can provide links back to the ticket(s) in the project's issue tracking system (e.g. Redmine/Jira), and maybe copy across any relevant acceptance criteria. The coder can chase a colleague to get a review, and then chase them up to continue discussions, as it is inevitable that reviewers will have questions.

2. Small reviews are easier

Complicated changes may be just as daunting to review as to build. So break them up into smaller chunks that can be reviewed easier. This has the massive benefit of forcing a developer to really understand what they're doing. A divide & conquer approach can make for a better implementation and is often easier to maintain too, so the benefits aren't only felt by reviewers.

3. Review early & often

Some changes can get pretty big over time. They may not be easy to break up into separate chunks, but work on them could well be broken up into iterations, building on top of each other. Early iterations may be full of holes or @TODO comments, but they still reveal much about the developer's intentions & understanding. So the review process can start as early as the planning stage, even when there's no code to actually review. Then as the changes to code take shape, the developer can continually return to the same person every so often. They will have contextual knowledge growing as the changes grow, to understand what's going on, helping them provide a better review.

4. Anyone can review

Inevitably some colleagues are more experienced than others - but we believe reviews are best shared around. Whether talking about your own code, or understanding someone else's code, experience is spread across the team. Fresh eyes are sometimes all that's needed to spot issues. Other times, it's merely the act of putting your own work up for scrutiny that forces you to get things right.

5. Reviewers, be proactive!

Developers like to be working, not waiting for feedback. Once they've got someone to agree to review their work, they have probably moved onto solving their next problem. However well they may have written up their work, it's best for the reviewer to chase the developer and talk through the work, ideally face-to-face. Even if the reviewer then goes away to test the changes, or there's another delay, it's best for the reviewer to be as proactive as possible. Clarify as much as needed. Chase down the answers. Ask seemingly dumb questions. Especially if you trust the developer - that probably means you can learn something from them too!

6. Use the tools well

Some code changes can be ignored or skipped through easily. Things like the boilerplate code around features exports in Drupal 7, or changes to composer.lock files. Pointers from the developer to the reviewer of what files/changes are important are really helpful. Reviewers themselves can also get wise as to what things to focus on. Tools can help with this - hiding whitespace changes in diffs, the files tab of PRs on github, or three-way merge tools, for example. Screenshots or videos are essential for communicating between developer & reviewer about visual elements when they can't meet face-to-face.

7. What can we learn from

The patch-based workflow that we are forced to use on doesn't get a lot of good press. (I'm super excited for the gitlab integration that will change this!) But it has stood the test of time. There are lessons we can draw from our time spent in its issue queues and contributing patches to core and contrib projects. For example, patches often go through two types of review, which I'd call 'focussed nitpicks' and the wider 'approach critiques'. It can be too tempting to write code to only fulfil precise acceptance criteria, or to pass tests - but reviewers are humans, each with their own perspectives to anticipate. Aiming for helpful reviews can be even more useful for all involved in the long-run than merely aiming to resolve a ticket.

8. Enforcing reviews

We tailor our workflow for each client and project - different amounts of testing, project management and process are appropriate for each one. So 'review-driven development' isn't a strict policy to be enforced, but a way of thinking about our work. When it is helpful, we use Github's functionality to protect branches and require reviews or merges via pull requests. This helps us to transparently deliver quality code. We also find this workflow particularly handy because we can broadcast notifications in Slack of new pull requests or merges that will trigger automatic deployments.

What holds you back from doing reviews? What makes a review easier?

I've only touched on some the things we've discussed and there's bound to be even more that we haven't thought of. Let us know what you do to improve peer reviewing in the comments!