Drupal

Valuebound: Step-by-step guide to Drush & Drush Aliases to make sure your web application has quick releases

Planet Drupal - 3 October 2017 - 1:33am

Have you ever thought that your business needs to make sure that your web application has a quick release in order to sustain the long race. This sort of has become easy to manage by continuous development & continuous integration using Drush & Drush Aliases. Drupal web development is one such place where multiple command-line interface (CLI) tools are available to make developer’s life easy, and among them, the two important things are Drush and Drupal Console.

In this blog, we will take a brief look at Drush & Drush Aliases and how it can make developer’s tedious manual web development tasks easy by offering various commands to…

Categories: Drupal

aleksip.net: Should Facebook be trusted on React and patents?

Planet Drupal - 3 October 2017 - 12:48am
Dries Buytaert, the BDFL of Drupal, has just published a blog post in which he states that “React is the right direction to move for Drupal's administrative interfaces”. A related issue has also been opened on drupal.org.
Categories: Drupal

Agiledrop.com Blog: AGILEDROP: Our Drupal Blogs from September

Planet Drupal - 3 October 2017 - 12:40am
It's the beginning of the new month, so it's time to look at all the Drupal blogs we have written for you in September. First, we have announced that after a long time, we will be present on any Drupal event. During holidays in July and August, we were not so active in that part, so it was right to point out that we were heading to DrupalCamp Antwerp at that time. Our Commercial director Iztok Smolic had a session there and our client adviser Ales Kohek was taking part in any of the Drupal events for the first time. But more about that later. Our second blog topic in September was again… READ MORE
Categories: Drupal

Appnovation Technologies: Appnovator Spotlight: Ed Cann

Planet Drupal - 2 October 2017 - 11:50pm
Appnovator Spotlight: Ed Cann Here's an insight into Ed, the man with the 'Cann do' attitude... Who are you? What's your story? I'm Ed, a welshman born an bred in Swansea. I grew up fiddling with computers from an early age starting with my Commodore +4. After university I decided that Engineering wasn't for me and Web development was where my talent lies so started with a few f...
Categories: Drupal

PreviousNext: DrupalCon Vienna session retro: Test all the things!

Planet Drupal - 2 October 2017 - 8:57pm
Share:

Last week I was fortunate enough to attend and deliver a session at DrupalCon Vienna. The session was based around leveraging and getting productive with the automated testing tools we use in the Drupal community.

by Sam Becker / 3 October 2017

For the kind of large scale projects we work on, it's essential that automated testing is a priority and firmly embedded in our technical culture. Stability and maintainability of the code we're working on helps to build trusting relationships and happy technical teams. I have for a long time been engaged with the developments of automated testing in Drupal core and internally we've worked hard to adapt these processes into the projects we build and fill-in any blanks where required.

I was fortunate enough to be selected to share this at DrupalCon Vienna. Without further ado, I present, Test all the things! Get productive with automated testing in Drupal 8:

Our current testing ethos is based around using the same tools for core and contrib for our bespoke Drupal project builds. Doing so allows us to context-switch between our own client work and contributed project or core work. To make this work we've addressed a few gaps in what's available to us out of the box.

Current State of Testing

I had some great conversations after the session with developers who were just starting to explore automated testing in Drupal. While the tools at our disposal are powerful, there is still lots of Drupal-specific knowledge required to become productive. My hope is the session helped to fill in some of the blanks in this regard.

E2E Testing

Because all of the test cases in core are isolated and individually setup environments/installations, end-to-end testing is tricky without some additional work. One of the touch points in the session was based around skipping the traditional set-up processes and using the existing test classes against pre-provisioned environments. Doing so replicates production-like environments in a test suite, which helps to provide a high-level of confidence tests are asserting behaviors of the whole system. Bringing this into core as a native capability is being discussed on drupal.org and was touched on in the session.

JS Unit Testing

One thing Drupal core has yet to address is JavaScript unit testing. For complex front-ends, testing JS application code with a browser is can become clumsy and hard to maintain. One approach we've used to address this is Jest. This nicely compliments front-ends where individual JavaScript modules can be isolated and individually tested.

Summing up, attending DrupalCon Vienna, presenting the session and meeting the members of the broader community was a great experience. I'm hopeful my session was able to contribute to the outstanding quality of sessions and technical discussions.

Tagged DrupalCon, DrupalCon Vienna, Testing

Posted by Sam Becker
Senior Developer

Dated 3 October 2017

Add new comment
Categories: Drupal

Dcycle: Letsencrypt HTTPS for Drupal on Docker

Planet Drupal - 2 October 2017 - 5:00pm

This article is about serving your Drupal Docker container, and/or any other container, via https with a valid Let’s encrypt SSL certificate.

Step one: make sure you have a public VM

To follow along, create a new virtual machine (VM) with Docker, for example using the “Docker” distribution in the “One-click apps” section of Digital Ocean.

This will not work on localhost, because in order to use Let’s Encrypt, you need to demonstrate ownership over your domain(s) to the outside world.

In this tutorial we will serve two different sites, one simple HTML site and one Drupal site, each using standard ports, on the same Docker host, using a reverse proxy, a container which sits in front of your other containers and directs traffic.

Step two: Set up two domains or subdomains you own and point them to your server

Start by making sure you have two domains which point to your server, in this example we’ll use:

  • test-one.example.com will be a simple HTML site.
  • test-two.example.com will be a Drupal site.
Step three: create your sites

We do not want to map our containers’ ports directly to our host ports using -p 80:80 -p 443:443 because we will have more than one app using the same port (the secure 443). Port mapping will be the responsibility of the reverse proxy (more on that later). Replace example.com with your own domain:

DOMAIN=example.com docker run -d \ -e "VIRTUAL_HOST=test-one.$DOMAIN" \ -e "LETSENCRYPT_HOST=test-one.$DOMAIN" \ -e "LETSENCRYPT_EMAIL=my-email@$DOMAIN" \ --expose 80 --name test-one \ httpd docker run -d \ -e "VIRTUAL_HOST=test-two.$DOMAIN" \ -e "LETSENCRYPT_HOST=test-two.$DOMAIN" \ -e "LETSENCRYPT_EMAIL=my-email@$DOMAIN" \ --expose 80 --name test-two \ drupal

Now you have two running sites, but they’re not yet accessible to the outside world.

Step three: a reverse proxy and Let’s encrypt

The term “proxy” means something which represents something else. In our case we want to have a webserver container which represents our Drupal and html containers. The Drupal and html containers are effectively hidden in front of a proxy. Why “reverse”? The term “proxy” is already used and means that the web user is hidden from the server. If it is the web servers that are hidden (in this case Drupal or the html containers), we use the term “reverse proxy”.

Let’s encrypt is a free certificate authority which certifies that you are the owner of your domain.

We will use nginx-proxy as our reverse proxy. Because that does not take care of certificates, we will use LetsEncrypt companion container for nginx-proxy to set up and maintain Let’s Encrypt certificates.

Let’s start by creating an empty directory which will contain our certificates:

mkdir "$HOME"/certs

Now, following the instructions of the LetsEncrypt companion project, we can set up our reverse proxy:

docker run -d -p 80:80 -p 443:443 \ --name nginx-proxy \ -v "$HOME"/certs:/etc/nginx/certs:ro \ -v /etc/nginx/vhost.d \ -v /usr/share/nginx/html \ -v /var/run/docker.sock:/tmp/docker.sock:ro \ --label com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy \ jwilder/nginx-proxy

And, finally, start the LetEncrypt companion:

docker run -d \ --name nginx-letsencrypt \ -v "$HOME"/certs:/etc/nginx/certs:rw \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ --volumes-from nginx-proxy \ jrcs/letsencrypt-nginx-proxy-companion

Wait a few minutes for "$HOME"/certs to be populated with your certificate files, and you should now be able to access your sites:

  • https://test-two.example.com/ should show the Drupal installer (setting up a MySQL container to actually install Drupal is outside the scope of this article);
  • https://test-one.example.com should show the “It works!” page.
  • In both cases, the certificate should be valid and you should get no error message.
  • http://test-one.example.com should redirect to https://test-one.example.com
  • http://test-two.example.com should redirect to https://test-two.example.com
A note about renewals

Let’s Encrypt certificates last 3 months, so we generally want to renew every two months. LetsEncrypt companion container for nginx-proxy states that it automatically renews certificates which are set to expire in less than a month, and it checks this hourly, although there are some renewal-related issues in the issue queue.

It seems to also be possible to force renewals by running:

docker exec nginx-letsencrypt /app/force_renew

So it might be worth considering to be on the lookout for failed renewals and force them if necessary.

Enjoy!

You can now bask in the knowledge that your cooking blog will not be man-in-the-middled.

This article is about serving your Drupal Docker container, and/or any other container, via https with a valid Let’s encrypt SSL certificate.

Categories: Drupal

Azure Text Analytics API

New Drupal Modules - 2 October 2017 - 2:16pm

Text Analytics API is a cloud-based service that provides advanced natural language processing over raw text, and includes three main functions: sentiment analysis, key phrase extraction, and language detection.

Categories: Drupal

Usable JSON REST formatter

New Drupal Modules - 2 October 2017 - 1:27pm
Categories: Drupal

Material Admin Support

New Drupal Modules - 2 October 2017 - 12:26pm

This module provides functionality for material_admin that must be done in a module. It is not required for using the material_admin theme, but will provide an extension to features.

Active development: https://github.com/briancwald/material_admin_support

Categories: Drupal

Palantir: Drupal 8 is Great for Easy Publishing

Planet Drupal - 2 October 2017 - 12:19pm
Drupal 8 is Great for Easy Publishing brandt Mon, 10/02/2017 - 14:19 Alex Brandt Oct 2, 2017

The #D8isGr8 blog series will focus on why we love Drupal 8 and how it provides solutions for our clients. This post in the series comes from Alex Brandt, Marketing Lead.

In this post we will cover...
  • What changes Drupal 8 has made to the editing experience
  • How Drupal 8 promotes accessibility
  • One way we use Drupal 8 to connect with our audience

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Oh Drupal 8, how do I love thee? Let me count the ways… As a content editor on a small team, I welcome every chance I get to publish something easier, quicker, and more effectively. My first experience publishing content in Drupal was in Drupal 7, and without having previous HTML experience, it was a time-consuming endeavor. Although there is a plethora of different reasons why I love publishing content in Drupal 8, I’ll narrow it down to my top three.

1.) WYSIWYG FTW!

This little bar is my best friend:

A quick WYSIWYG editor (CKEditor) is now standard in Drupal 8 core, which means there’s no need to look up the HTML every time I want to include a link, stylize a heading, or insert an image. The amount of time I save when publishing is awesome, but it also prevents me from using sloppy code that could become an issue later down the line if we migrate content.

2.) Keeping Things Accessible with Alt Text

Drupal 8 now flags when you need alternative text (alt text), and it doesn’t allow you to publish a post without providing these descriptions. We always strive to make our corner of the web equally accessible for all users, and this is a safeguard to make sure we continue doing so. You can read more about why alt text is important in our recent post on accessibility.

This red asterisk prompt displays every time you insert an image.3.) Customization

Just like most institutions, our website is one of the most important marketing tools for our agency. Not only does it provide us with a place to share knowledge with our audience, it provides different ways for our audience to engage with us.

One of the easiest ways we are able to connect with our clients, partners, and community is by creating customizable call-to-action buttons to display in various places on our site. These buttons allow our site visitors to sign up for our newsletter, schedule a time to chat with us, register for a webinar, or any other action we hope they take. By having the ability to customize each button (opposed to only having a generic contact us button), we can make sure the call-to-action buttons fits the content where they are displayed. Drupal 8 makes these buttons easy to create (once we set up our desired fields).

Different options for customizing CTA buttons.Easy Publishing in Drupal 8

All of these features in Drupal 8 allow me to share tailored content with our audience, without becoming bogged down by the technology. And because I know you were wondering, the time it took me to take this blog post from google doc to published? 3 minutes, 17 seconds.

We want to make your project a success.

Let's Chat.
Categories: Drupal

Drupal looking to adopt React

Dries Buytaert - 2 October 2017 - 10:32am

Last week at DrupalCon Vienna, I proposed adding a modern JavaScript framework to Drupal core. After the keynote, I met with core committers, framework managers, JavaScript subsystem maintainers, and JavaScript experts in the Drupal community to discuss next steps. In this blog post, I look back on how things have evolved, since the last time we explored adding a new JavaScript framework to Drupal core two years ago, and what we believe are the next steps after DrupalCon Vienna.

As a group, we agreed that we had learned a lot from watching the JavaScript community grow and change since our initial exploration. We agreed that today, React would be the most promising option given its expansive adoption by developers, its unopinionated and component-based nature, and its well-suitedness to building new Drupal interfaces in an incremental way. Today, I'm formally proposing that the Drupal community adopt React, after discussion and experimentation has taken place.

Two years ago, it was premature to pick a JavaScript framework

Three years ago, I developed several convictions related to "headless Drupal" or "decoupled Drupal". I believed that:

  1. More and more organizations wanted a headless Drupal so they can use a modern JavaScript framework to build application-like experiences.
  2. Drupal's authoring and site building experience could be improved by using a more modern JavaScript framework.
  3. JavaScript and Node.js were going to take the world by storm and that we would be smart to increase the amount of JavaScript expertise in our community.

(For the purposes of this blog post, I use the term "framework" to include both full MV* frameworks such as Angular, and also view-only libraries such as React combined piecemeal with additional libraries for managing routing, states, etc.)

By September 2015, I had built up enough conviction to write several long blog posts about these views (post 1, post 2, post 3). I felt we could accomplish all three things by adding a JavaScript framework to Drupal core. After careful analysis, I recommended that we consider React, Ember and Angular. My first choice was Ember, because I had concerns about a patent clause in Facebook's open-source license (since removed) and because Angular 2 was not yet in a stable release.

At the time, the Drupal community didn't like the idea of picking a JavaScript framework. The overwhelming reactions were these: it's too early to tell which JavaScript framework is going to win, the risk of picking the wrong JavaScript framework is too big, picking a single framework would cause us to lose users that favor other frameworks, etc. In addition, there were a lot of different preferences for a wide variety of JavaScript frameworks. While I'd have preferred to make a bold move, the community's concerns were valid.

Focusing on Drupal's web services instead

By May of 2016, after listening to the community, I changed my approach; instead of adding a specific JavaScript framework to Drupal, I decided we should double down on improving Drupal's web service APIs. Instead of being opinionated about what JavaScript framework to use, we would allow people to use their JavaScript framework of choice.

I did a deep dive on the state of Drupal's web services in early 2016 and helped define various next steps (post 1, post 2, post 3). I asked a few of the OCTO team members to focus on improving Drupal 8's web services APIs; funded improvements to Drupal core's REST API, as well as JSON API, GraphQL and OpenAPI; supported the creation of Waterwheel projects to help bootstrap an ecosystem of JavaScript front-end integrations; and most recently supported the development of Reservoir, a Drupal distribution for headless Drupal. There is also a lot of innovation coming from the community with lots of work on the Contenta distribution, JSON API, GraphQL, and more.

The end result? Drupal's web service APIs have progressed significantly the past year. Ed Faulkner of Ember told us: "I'm impressed by how fast Drupal made lots of progress with its REST API and the JSON API contrib module!". It's a good sign when a core maintainer of one of the leading JavaScript frameworks acknowledges Drupal's progress.

The current state of JavaScript in Drupal

Looking back, I'm glad we decided to focus first on improving Drupal's web services APIs; we discovered that there was a lot of work left to stabilize them. Cleanly integrating a JavaScript framework with Drupal would have been challenging 18 months ago. While there is still more work to be done, Drupal 8's available web service APIs have matured significantly.

Furthermore, by not committing to a specific framework, we are seeing Drupal developers explore a range of JavaScript frameworks and members of multiple JavaScript framework communities consuming Drupal's web services. I've seen Drupal 8 used as a content repository behind Angular, Ember, React, Vue, and other JavaScript frameworks. Very cool!

There is a lot to like about how Drupal's web service APIs matured and how we've seen Drupal integrated with a variety of different frameworks. But there is also no denying that not having a JavaScript framework in core came with certain tradeoffs:

  1. It created a barrier for significantly leveling up the Drupal community's JavaScript skills. In my opinion, we still lack sufficient JavaScript expertise among Drupal core contributors. While we do have JavaScript experts working hard to maintain and improve our existing JavaScript code, I would love to see more experts join that team.
  2. It made it harder to accelerate certain improvements to Drupal's authoring and site building experience.
  3. It made it harder to demonstrate how new best practices and certain JavaScript approaches could be leveraged and extended by core and contributed modules to create new Drupal features.

One trend we are now seeing is that traditional MV* frameworks are giving way to component libraries; most people seem to want a way to compose interfaces and interactions with reusable components (e.g. libraries like React, Vue, Polymer, and Glimmer) rather than use a framework with a heavy focus on MV* workflows (e.g. frameworks like Angular and Ember). This means that my original recommendation of Ember needs to be revisited.

Several years later, we still don't know what JavaScript framework will win, if any, and I'm willing to bet that waiting two more years won't give us any more clarity. JavaScript frameworks will continue to evolve and take new shapes. Picking a single one will always be difficult and to some degree "premature". That said, I see React having the most momentum today.

My recommendations at DrupalCon Vienna

Given that it's been almost two years since I last suggested adding a JavaScript framework to core, I decided to bring the topic back in my DrupalCon Vienna keynote presentation. Prior to my keynote, there had been some renewed excitement and momentum behind the idea. Two years later, here is what I recommended we should do next:

  • Invest more in Drupal's API-first initiative. In 2017, there is no denying that decoupled architectures and headless Drupal will be a big part of our future. We need to keep investing in Drupal's web service APIs. At a minimum, we should expand Drupal's web service APIs and standardize on JSON API. Separately, we need to examine how to give API consumers more access to and control over Drupal's capabilities.
  • Embrace all JavaScript frameworks for building Drupal-powered applications. We should give developers the flexibility to use their JavaScript framework of choice when building front-end applications on top of Drupal — so they can use the right tool for the job. The fact that you can front Drupal with Ember, Angular, Vue, React, and others is a great feature. We should also invest in expanding the Waterwheel ecosystem so we have SDKs and references for all these frameworks.
  • Pick a framework for Drupal's own administrative user interfaces. Drupal should pick a JavaScript framework for its own administrative interface. I'm not suggesting we abandon our stable base of PHP code; I'm just suggesting that we leverage JavaScript for the things that JavaScript is great at by moving relevant parts of our code from PHP to JavaScript. Specifically, Drupal's authoring and site building experience could benefit from user experience improvements. A JavaScript framework could make our content modeling, content listing, and configuration tools faster and more application-like by using instantaneous feedback rather than submitting form after form. Furthermore, using a decoupled administrative interface would allow us to dogfood our own web service APIs.
  • Let's start small by redesigning and rebuilding one or two features. Instead of rewriting the entirety of Drupal's administrative user interfaces, let's pick one or two features, and rewrite their UIs using a preselected JavaScript framework. This allows us to learn more about the pros and cons, allows us to dogfood some of our own APIs, and if we ultimately need to switch to another JavaScript framework or approach, it won't be very painful to rewrite or roll the changes back.
Selecting a JavaScript framework for Drupal's administrative UIs

In my keynote, I proposed a new strategic initiative to test and research how Drupal's administrative UX could be improved by using a JavaScript framework. The feedback was very positive.

As a first step, we have to choose which JavaScript framework will be used as part of the research. Following the keynote, we had several meetings at DrupalCon Vienna to discuss the proposed initiative with core committers, all of the JavaScript subsystem maintainers, as well as developers with real-world experience building decoupled applications using Drupal's APIs.

There was unanimous agreement that:

  1. Adding a JavaScript framework to Drupal core is a good idea.
  2. We want to have sufficient real-use experience to make a final decision prior to 8.6.0's development period (Q1 2018). To start, the Watchdog page would be the least intrusive interface to rebuild and would give us important insights before kicking off work on more complex interfaces.
  3. While a few people named alternative options, React was our preferred option, by far, due to its high degree of adoption, component-based and unopinionated nature, and its potential to make Drupal developers' skills more future-proof.
  4. This adoption should be carried out in a limited and incremental way so that the decision is easily reversible if better approaches come later on.

We created an issue on the Drupal core queue to discuss this more.

Conclusion Drupal should support a variety of JavaScript libraries on the user-facing front end while relying on a single shared framework as a standard across Drupal administrative interfaces.

In short, I continue to believe that adopting more JavaScript is important for the future of Drupal. My original recommendation to include a modern JavaScript framework (or JavaScript libraries) for Drupal's administrative user interfaces still stands. I believe we should allow developers to use their JavaScript framework of choice to build front-end applications on top of Drupal and that we can start small with one or two administrative user interfaces.

After meeting with core maintainers, JavaScript subsystem maintainers, and framework managers at DrupalCon Vienna, I believe that React is the right direction to move for Drupal's administrative interfaces, but we encourage everyone in the community to discuss our recommendation. Doing so would allow us to make Drupal easier to use for site builders and content creators in an incremental and reversible way, keep Drupal developers' skills relevant in an increasingly JavaScript-driven world, move us ahead with modern tools for building user interfaces.

Special thanks to Preston So for contributions to this blog post and to Matt Grill, Wim Leers, Jason Enter, Gábor Hojtsy, and Alex Bronstein for their feedback during the writing process.

Categories: Drupal

Dries Buytaert: Drupal looking to adopt React

Planet Drupal - 2 October 2017 - 10:32am

Last week at DrupalCon Vienna, I proposed adding a modern JavaScript framework to Drupal core. After the keynote, I met with core committers, framework managers, JavaScript subsystem maintainers, and JavaScript experts in the Drupal community to discuss next steps. In this blog post, I look back on how things have evolved, since the last time we explored adding a new JavaScript framework to Drupal core two years ago, and what we believe are the next steps after DrupalCon Vienna.

As a group, we agreed that we had learned a lot from watching the JavaScript community grow and change since our initial exploration. We agreed that today, React would be the most promising option given its expansive adoption by developers, its unopinionated and component-based nature, and its well-suitedness to building new Drupal interfaces in an incremental way. Today, I'm formally proposing that the Drupal community adopt React, after discussion and experimentation has taken place.

Two years ago, it was premature to pick a JavaScript framework

Three years ago, I developed several convictions related to "headless Drupal" or "decoupled Drupal". I believed that:

  1. More and more organizations wanted a headless Drupal so they can use a modern JavaScript framework to build application-like experiences.
  2. Drupal's authoring and site building experience could be improved by using a more modern JavaScript framework.
  3. JavaScript and Node.js were going to take the world by storm and that we would be smart to increase the amount of JavaScript expertise in our community.

(For the purposes of this blog post, I use the term "framework" to include both full MV* frameworks such as Angular, and also view-only libraries such as React combined piecemeal with additional libraries for managing routing, states, etc.)

By September 2015, I had built up enough conviction to write several long blog posts about these views (post 1, post 2, post 3). I felt we could accomplish all three things by adding a JavaScript framework to Drupal core. After careful analysis, I recommended that we consider React, Ember and Angular. My first choice was Ember, because I had concerns about a patent clause in Facebook's open-source license (since removed) and because Angular 2 was not yet in a stable release.

At the time, the Drupal community didn't like the idea of picking a JavaScript framework. The overwhelming reactions were these: it's too early to tell which JavaScript framework is going to win, the risk of picking the wrong JavaScript framework is too big, picking a single framework would cause us to lose users that favor other frameworks, etc. In addition, there were a lot of different preferences for a wide variety of JavaScript frameworks. While I'd have preferred to make a bold move, the community's concerns were valid.

Focusing on Drupal's web services instead

By May of 2016, after listening to the community, I changed my approach; instead of adding a specific JavaScript framework to Drupal, I decided we should double down on improving Drupal's web service APIs. Instead of being opinionated about what JavaScript framework to use, we would allow people to use their JavaScript framework of choice.

I did a deep dive on the state of Drupal's web services in early 2016 and helped define various next steps (post 1, post 2, post 3). I asked a few of the OCTO team members to focus on improving Drupal 8's web services APIs; funded improvements to Drupal core's REST API, as well as JSON API, GraphQL and OpenAPI; supported the creation of Waterwheel projects to help bootstrap an ecosystem of JavaScript front-end integrations; and most recently supported the development of Reservoir, a Drupal distribution for headless Drupal. There is also a lot of innovation coming from the community with lots of work on the Contenta distribution, JSON API, GraphQL, and more.

The end result? Drupal's web service APIs have progressed significantly the past year. Ed Faulkner of Ember told us: "I'm impressed by how fast Drupal made lots of progress with its REST API and the JSON API contrib module!". It's a good sign when a core maintainer of one of the leading JavaScript frameworks acknowledges Drupal's progress.

The current state of JavaScript in Drupal

Looking back, I'm glad we decided to focus first on improving Drupal's web services APIs; we discovered that there was a lot of work left to stabilize them. Cleanly integrating a JavaScript framework with Drupal would have been challenging 18 months ago. While there is still more work to be done, Drupal 8's available web service APIs have matured significantly.

Furthermore, by not committing to a specific framework, we are seeing Drupal developers explore a range of JavaScript frameworks and members of multiple JavaScript framework communities consuming Drupal's web services. I've seen Drupal 8 used as a content repository behind Angular, Ember, React, Vue, and other JavaScript frameworks. Very cool!

There is a lot to like about how Drupal's web service APIs matured and how we've seen Drupal integrated with a variety of different frameworks. But there is also no denying that not having a JavaScript framework in core came with certain tradeoffs:

  1. It created a barrier for significantly leveling up the Drupal community's JavaScript skills. In my opinion, we still lack sufficient JavaScript expertise among Drupal core contributors. While we do have JavaScript experts working hard to maintain and improve our existing JavaScript code, I would love to see more experts join that team.
  2. It made it harder to accelerate certain improvements to Drupal's authoring and site building experience.
  3. It made it harder to demonstrate how new best practices and certain JavaScript approaches could be leveraged and extended by core and contributed modules to create new Drupal features.

One trend we are now seeing is that traditional MV* frameworks are giving way to component libraries; most people seem to want a way to compose interfaces and interactions with reusable components (e.g. libraries like React, Vue, Polymer, and Glimmer) rather than use a framework with a heavy focus on MV* workflows (e.g. frameworks like Angular and Ember). This means that my original recommendation of Ember needs to be revisited.

Several years later, we still don't know what JavaScript framework will win, if any, and I'm willing to bet that waiting two more years won't give us any more clarity. JavaScript frameworks will continue to evolve and take new shapes. Picking a single one will always be difficult and to some degree "premature". That said, I see React having the most momentum today.

My recommendations at DrupalCon Vienna

Given that it's been almost two years since I last suggested adding a JavaScript framework to core, I decided to talk bring the topic back in my DrupalCon Vienna keynote presentation. Prior to my keynote, there had been some renewed excitement and momentum behind the idea. Two years later, here is what I recommended we should do next:

  • Invest more in Drupal's API-first initiative. In 2017, there is no denying that decoupled architectures and headless Drupal will be a big part of our future. We need to keep investing in Drupal's web service APIs. At a minimum, we should expand Drupal's web service APIs and standardize on JSON API. Separately, we need to examine how to give API consumers more access to and control over Drupal's capabilities.
  • Embrace all JavaScript frameworks for building Drupal-powered applications. We should give developers the flexibility to use their JavaScript framework of choice when building front-end applications on top of Drupal — so they can use the right tool for the job. The fact that you can front Drupal with Ember, Angular, Vue, React, and others is a great feature. We should also invest in expanding the Waterwheel ecosystem so we have SDKs and references for all these frameworks.
  • Pick a framework for Drupal's own administrative user interfaces. Drupal should pick a JavaScript framework for its own administrative interface. I'm not suggesting we abandon our stable base of PHP code; I'm just suggesting that we leverage JavaScript for the things that JavaScript is great at by moving relevant parts of our code from PHP to JavaScript. Specifically, Drupal's authoring and site building experience could benefit from user experience improvements. A JavaScript framework could make our content modeling, content listing, and configuration tools faster and more application-like by using instantaneous feedback rather than submitting form after form. Furthermore, using a decoupled administrative interface would allow us to dogfood our own web service APIs.
  • Let's start small by redesigning and rebuilding one or two features. Instead of rewriting the entirety of Drupal's administrative user interfaces, let's pick one or two features, and rewrite their UIs using a preselected JavaScript framework. This allows us to learn more about the pros and cons, allows us to dogfood some of our own APIs, and if we ultimately need to switch to another JavaScript framework or approach, it won't be very painful to rewrite or roll the changes back.
Selecting a JavaScript framework for Drupal's administrative UIs

In my keynote, I proposed a new strategic initiative to test and research how Drupal's administrative UX could be improved by using a JavaScript framework. The feedback was very positive.

As a first step, we have to choose which JavaScript framework will be used as part of the research. Following the keynote, we had several meetings at DrupalCon Vienna to discuss the proposed initiative with core committers, all of the JavaScript subsystem maintainers, as well as developers with real-world experience building decoupled applications using Drupal's APIs.

There was unanimous agreement that:

  1. Adding a JavaScript framework to Drupal core is a good idea.
  2. We want to have sufficient real-use experience to make a final decision prior to 8.6.0's development period (Q1 2018). To start, the Watchdog page would be the least intrusive interface to rebuild and would give us important insights before kicking off work on more complex interfaces.
  3. While a few people named alternative options, React was our preferred option, by far, due to its high degree of adoption, component-based and unopinionated nature, and its potential to make Drupal developers' skills more future-proof.
  4. This adoption should be carried out in a limited and incremental way so that the decision is easily reversible if better approaches come later on.

We created an issue on the Drupal core queue to discuss this more.

Conclusion Drupal should support a variety of JavaScript libraries on the user-facing front end while relying on a single shared framework as a standard across Drupal administrative interfaces.

In short, I continue to believe that adopting more JavaScript is important for the future of Drupal. My original recommendation to include a modern JavaScript framework (or JavaScript libraries) for Drupal's administrative user interfaces still stands. I believe we should allow developers to use their JavaScript framework of choice to build front-end applications on top of Drupal and that we can start small with one or two administrative user interfaces.

After meeting with core maintainers, JavaScript subsystem maintainers, and framework managers at DrupalCon Vienna, I believe that React is the right direction to move for Drupal's administrative interfaces, but we encourage everyone in the community to discuss our recommendation. Doing so would allow us to make Drupal easier to use for site builders and content creators in an incremental and reversible way, keep Drupal developers' skills relevant in an increasingly JavaScript-driven world, move us ahead with modern tools for building user interfaces.

Special thanks to Preston So for contributions to this blog post and to Matt Grill, Wim Leers, Jason Enter, Gábor Hojtsy, and Alex Bronstein for their feedback during the writing process.

Categories: Drupal

Media Lazy Load Formatter

New Drupal Modules - 2 October 2017 - 7:16am

This module allows the option of lazy loading different forms of media via field formatters. Currently only supports the image field formatter.

It uses the JQuery Lazy Load Xt library to lazy load the images on scroll.

Installation:

Enable module.

Usage:
Visit any entity's display mode. If an image is present, the settings form should have a checkbox to choose whether or not to lazy load the image.

Categories: Drupal

faceless

New Drupal Modules - 2 October 2017 - 6:03am

Impersonate is a module that gives you the ability to veiw your website as a certain user (the one you will impersonate) would actually see it. It is great for verifying that the permissions and rules for your users work correctly and that you have the visual result wanted for every role/user.

Categories: Drupal

Acro Media: Video: Shipping in Drupal Commerce 2.x is Better Than Ever!

Planet Drupal - 2 October 2017 - 5:45am

“Shipping” in Commerce 1 meant “get shipping rates.” End of story. If you wanted to do something crazy like actually receive the item or put it in a box in the warehouse, you were out of luck. You could integrate with another system, but otherwise you were really just a storefront.

But Commerce 2.x is a different story. Now you can go from getting rates all the way down to actually receiving the shipment.

Categories: Drupal

Amazee Labs: DrupalCon Vienna Friday Sprints

Planet Drupal - 2 October 2017 - 4:17am
DrupalCon Vienna Friday Sprints

At the end of a great month of cycling, a great week of summits, pieces of training, keynotes and more at #DrupalConEUR, the last and final day of this week-long conference was all about sprinting. Let me share my wrap-up of the DrupalCon’s Friday sprints in this blog post.

Josef Dabernig Mon, 10/02/2017 - 13:17

The Messe Wien conference center was split up into 3 areas: the first-time sprinter workshop, mentored core sprints as well as general sprints. Let’s go through them one by one.

1) The first-time sprinter workshop, brings new contributors up to speed with setting up a Drupal 8 environment, understand the contribution process and find their first novice issues to tackle. This process has been tested at various previous DrupalCons and turns out to be highly effective at recruiting and onboarding potential future Drupal contributors.

The group of sprint mentors runs through duties in the morning. Rachel Lawson (rachel_norfolk) blogged about her experience working together with the highly dedicated team of mentors.

At the first-time sprinter workshop, besides learning tools, processes and the technology, the main emphasis is on being able to collaborate in-person with other community members such as in this case Jen Lampton (jenlampton) from the US together with Chris Maiden (matason) from the UK.
 

2) The mentored core sprints are designed to take those who have gotten their feet wet in the first-time sprinter workshop or already have prior contribution experience to the next level. The setup of the second room with round tables focused on different topics such as Drupal core subsystems or initiatives allows engaging directly with mentors specialized in those skill areas. New contributors will work side-by-side with experienced core contributors on core tasks.

Mentors, such as Fatima Sarah Kahlid (sugaroverflow) from Canada, provide individual advice to those sprinting on an issue. The goal is to help a new contributor on their way through the process and learn from each other.

The mentors all wore green t-shirts and we used name tags for every attendee to make sure it’s easy to know who can help and lower the bar for memorizing hundreds of names within a few hours. This is Michael Lenahan (michaellenahan) making an announcement to the crowd of sprinters at DrupalCon Vienna.

 

3) The general sprints are where all the other magic happens. You will find other Drupal core initiatives and Drupal module maintainers sprint together on topics they care about being moved forward. It is similar to the mentored core sprints format, as we have tables that focus on certain topics but without the official sprint mentors and rather each initiative self-organized with or without a given structure.

A huge spreadsheet is used every year to pre-organize sprints. Here individuals can sign-up for sprints happening during the week and take part in individual sprint initiatives such as working on “Drupal 8 criticals and majors” or “Migrate” or “Usability / Redesign the Admin UI”.

A busy and growing table was the “Search API Family” where Thomas Seidl (drunken monkey) sprinted together with many other contributors on Search API and related modules such as Facets. Note that the Search API module has also been given the price in the Drupal category or the Open Minds award that we held during the week of DrupalCon on Tuesday. Together with Entity API by Wolfgang Ziegler (fago) and GraphQL by Sebastian Siemssen (fubhy) and Philipp Melab (pmelab) it was awarded as most valuable Drupal contributions from Austria.

---

The sprints were concluded with a very special moment, the Drupal Core Live Commit.

Lauri Eskola (lauriii), provisional core committer performed a live commit on stage. The seemingly trivial issue Add @internal to schemaDefinition() methods was reviewed and showed how the process works. The issue had been worked on by three contributors Valery Lourie (valthebald), Kevin Wenger (wengerk) and Gilles Doge (gido) until it went via the Active and Needs Review to Reviewed & tested by the community. Together with the approval from core committer Angie Byron (webchick), Lauri was able to commit the improvement not only to the latest 8.5.x development branch but also to 8.4.x which currently in release candidate mode.

Shannon Vettes (svettes) and Michael Schmid (schnitzel) also joined the stage to share what they sprinted on. This time it was about an initiative that isn’t necessarily related to writing code but helping drive change. Drupal-Petitions.org is designed to create a process & tool similarly to https://www.change.org/ or https://petitions.whitehouse.gov/ where the community can prioritize and gather momentum around ideas of improvements.

---

Wrapping up

Friday was all about sprints. As explained, I’m excited about the many ways that new and existing contributors had been working together.

Special thanks to all sprint mentors, to the great organization by the DrupalCon Events team as well as Thunder as the main sponsor for the Friday sprints.

More photos from Friday and the entire conference can be found in our Flickr collection. Interested in sprinting again? Watch out for Drupal Dev Days in 2018 or other upcoming Drupal events in your area.

Categories: Drupal

Comic Relief Technology Blog: Waste not want not: Upcycle your tech!

Planet Drupal - 2 October 2017 - 2:18am
Working in the charity sector you learn to be pretty resourceful when you need to be, and that doesn’t stop… Read More Waste not want not: Upcycle your tech!
Categories: Drupal

ADCI Solutions: What's the difference between single-page application and multi-page application?

Planet Drupal - 2 October 2017 - 12:51am

SPA approach of website developing is on rise. It’s cool, it’s popular. Everybody wants to chime in and participate. Don’t forget about multi-page approach though: there are many use cases you may love.

 

Read the whole article and learn how to apply those approaches using Drupal, React, Vue.js.

 

Categories: Drupal

Taboo Game Server

New Drupal Modules - 1 October 2017 - 5:17pm

Developed taboo server with Python, which contains modules log-in, log-out, retrieving cards, adjusting difficulty, recording score.

Categories: Drupal

OSTraining: Drupal 8 or Drupal 7

Planet Drupal - 1 October 2017 - 5:00pm

Drupal has long been a techie's choice of open source content management system. It may be harder than WordPress or Joomla to setup but it more than makes up for this with its power and flexibility.

Does Drupal 8 continue this tradition?

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal