Drupal

OPTASY: How to Integrate Alexa with Your Drupal 8 Website: A Step-by-Step Guide

drupal.org aggregator - Fri, 05/18/2018 - 12:05
How to Integrate Alexa with Your Drupal 8 Website: A Step-by-Step Guide radu.simileanu Fri, 05/18/2018 - 16:05

Just imagine: a user asks Amazon Alexa to read out loud to him/her the headline of your latest blog post! Or maybe to look for a specific section on your Drupal site! Or, even better: quit imagining this and start implementing it instead! Right on your website. And here's how you integrate Alexa with your Drupal 8 website via the Alexa integration APIs.

A 7-step tutorial:
 

  • on how to get Alexa to “talk to” your site users/online customers
  • on turning your site's content into the needed “raw material” for setting up your custom Alexa skills
  • on how you can leverage Drupal 8's outstanding third-party integration capabilities to “fuel” your implementation plan with
     

So, here's how it's done: 
 

Categories: Drupal

Zivtech: Drupal 8 Content Moderation Tips & Tricks

drupal.org aggregator - Fri, 05/18/2018 - 11:19

The Content Moderation core module was marked stable in Drupal 8.5. Think of it like the contributed module Workbench Moderation in Drupal 7, but without all the Workbench editor Views that never seemed to completely make sense. The Drupal.org documentation gives a good overview.

Content Moderation requires the Workflows core module, allowing you to set up custom editorial workflows. I've been doing some work with this for a new site for a large organization, and have some tips and tricks.

Less Is More

Resist increases in roles, workflows, and workflow states and make sure they are justified by a business need. Stakeholders may ask for many roles and many workflow states without knowing the increased complexity and likelihood of editorial confusion that results.

If you create an editorial workflow that is too strict and complex, editors will tend to find ways to work around the  system. A good compromise is to ask that the team tries something simple first and adds complexity down the line if needed.

Try to use the same workflow on all content types if you can. It makes a much simpler mental model for everyone.

Transitions are Key

Transitions between workflow states will be what you assign as permissions to roles. Typically, you'll want to lock down who can publish content, allowing content contributors to create new drafts only.

Read more
Categories: Drupal

Drupal blog: Working toward a JavaScript-driven Drupal administration interface

drupal.org aggregator - Fri, 05/18/2018 - 11:18

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

As web applications have evolved from static pages to application-like experiences, end-users' expectations of websites have become increasingly demanding. JavaScript, partnered with effective user-experience design, enable the seamless, instantaneous interactions that users now expect.

The Drupal project anticipated this trend years ago and we have been investing heavily in making Drupal API-first ever since. As a result, more organizations are building decoupled applications served by Drupal. This approach allows organizations to use modern JavaScript frameworks, while still benefiting from Drupal's powerful content management capabilities, such as content modeling, content editing, content workflows, access rights and more.

While organizations use JavaScript frameworks to create visitor-facing experiences with Drupal as a backend, Drupal's own administration interface has not yet embraced a modern JavaScript framework. There is high demand for Drupal to provide a cutting-edge experience for its own users: the site's content creators and administrators.

At DrupalCon Vienna, we decided to start working on an alternative Drupal administrative UI using React. Sally Young, one of the initiative coordinators, recently posted a fantastic update on our progress since DrupalCon Vienna.

Next steps for Drupal's API-first and JavaScript work

While we made great progress improving Drupal's web services support and improving our JavaScript support, I wanted to use this blog post to compile an overview of some of our most important next steps:

1. Stabilize the JSON API module

JSON API is a widely-used specification for building web service APIs in JSON. We are working towards adding JSON API to Drupal core as it makes it easier for JavaScript developers to access the content and configuration managed in Drupal. There is a central plan issue that lists all of the blockers for getting JSON API into core (comprehensive test coverage, specification compliance, and more). We're working hard to get all of them out of the way!

2. Improve our JavaScript testing infrastructure

Drupal's testing infrastructure is excellent for testing PHP code, but until now, it was not optimized for testing JavaScript code. As we expect the amount of JavaScript code in Drupal's administrative interface to dramatically increase in the years to come, we have been working on improving our JavaScript testing infrastructure using Headless Chrome and Nightwatch.js. Nightwatch.js has already been committed for inclusion in Drupal 8.6, however some additional work remains to create a robust JavaScript-to-Drupal bridge. Completing this work is essential to ensure we do not introduce regressions, as we proceed with the other items in our roadmap.

3. Create designs for a React-based administration UI

Having a JavaScript-based UI also allows us to rethink how we can improve Drupal's administration experience. For example, Drupal's current content modeling UI requires a lot of clicking, saving and reloading. By using React, we can reimagine our user experience to be more application-like, intuitive and faster to use. We still need a lot of help to design and test different parts of the Drupal administration UI.

4. Allow contributed modules to use React or Twig

We want to enable modules to provide either a React-powered administration UI or a traditional Twig-based administration UI. We are working on an architecture that can support both at the same time. This will allow us to introduce JavaScript-based UIs incrementally instead of enforcing a massive paradigm shift all at once. It will also provide some level of optionality for modules that want to opt-out from supporting the new administration UI.

5. Implement missing web service APIs

While we have been working for years to add web service APIs to many parts of Drupal, not all of Drupal has web services support yet. For our React-based administration UI prototype we decided to implement a new permission screen (i.e. https://example.com/admin/people/permissions). We learned that Drupal lacked the necessary web service APIs to retrieve a list of all available permissions in the system. This led us to create a support module that provides such an API. This support module is a temporary solution that helped us make progress on our prototype; the goal is to integrate these APIs into core itself. If you want to contribute to Drupal, creating web service APIs for various Drupal subsystems might be a great way to get involved.

6. Make the React UI extensible and configurable

One of the benefits of Drupal's current administration UI is that it can be configured (e.g. you can modify the content listing because it has been built using the Views module) and extended by contributed modules (e.g. the Address module adds a UI that is optimized for editing address information). We want to make sure that in the new React UI we keep enough flexibility for site builders to customize the administrative UI.

All decoupled builds benefit

All decoupled applications will benefit from the six steps above; they're important for building a fully-decoupled administration UI, and for building visitor-facing decoupled applications.

Useful for decoupling of visitor-facing front-ends Useful for decoupling of the administration backend 1. Stabilize the JSON API module ✔ ✔ 2. Improve our JavaScript testing infrastructure ✔ ✔ 3. Create designs for a React-based administration UI ✔ 4. Allow contributed modules to use React or Twig ✔ ✔ 5. Implement missing web service APIs ✔ ✔ 6. Make the React UI extensible and configurable ✔ Conclusion

Over the past three years we've been making steady progress to move Drupal to a more API-first and JavaScript centric world. It's important work given a variety of market trends in our industry. While we have made excellent progress, there are more challenges to be solved. We hope you like our next steps, and we welcome you to get involved with them. Thank you to everyone who has contributed so far!

Special thanks to Matt Grill and Lauri Eskola for co-authoring this blog post and to Wim Leers, Gabe Sullice, Angela Byron, and Preston So for their feedback during the writing process.

Categories: Drupal

mark.ie: My Approach to PatternLab?

drupal.org aggregator - Fri, 05/18/2018 - 10:43
My Approach to PatternLab?

I'm sometimes asked for an overview of my general approach to PatternLab. Simple: put everything for each component in the same directory!

markconroy Fri, 05/18/2018 - 15:43

When working with PatternLab, which I use for all my Drupal themes, including the theme for this website, I don’t use the full atomic approach. I don't use the approach of atoms > molecules > organisms > etc. I’m sure many people seriously disagree with me for that ( I do think it's a very clever concept). Instead I’ve renamed things to match the language we use with our clients.

I tried talking about atoms and molecules to some clients and their eyes glazed over. Clients do not want a science lesson. They do not want to be told that we are going to take two of these atoms, and mix them with one of these atom, and eventually we'll have water. No, they want to know what their final website is going to look like. When I changed the conversation and started talking about ‘Building Blocks’ (what we call our Drupal paragraph types), site blocks (Drupal's search block, branding block), display types (Drupal's view modes such as teaser, search result), etc, they immediately understood. Then we started hearing things like, "Oh, so we can create a page by adding a number of different building blocks?" and "I see, so the search results page is made up of a group of pages using the 'Search Result' display type?". And my response, "Yes!". You see, we are using plain English to ease with understanding.

Another aspect of my approach that I really like is that _everything_ for each of my components is within the same directory. For example, if it’s a nested paragraph component such as an accordion (so we need a paragraph type called 'Accordion' and one called 'Accordion Item') each template and css and js and readme and json and yaml is all in the same folder. That means when I want to reuse one in another project, I don’t need to remember what sub-particles (atoms/molecules) are used to create the organism. It also means my CSS is scoped to that specific component and doesn’t bleed out of it, so making changes or adding new features is very easy, you just scope the new component's CSS to it, so it won't affect other previously-created components.

Now the top bar of my PatternLab that used to say Atoms | Molecules | Organisms, etc has tabs for:

  • Base
    • Colours
    • Spacing
    • Breakpoints
  • Basic Elements
    • Headings
    • Paragraphs
    • Lists
  • Site Blocks (Drupal Blocks)
    • Search Block
    • Login Block
    • Branding Block
  • Building Blocks (Paragraph Types)
    • Accordion
    • Image with Text
    • Video
  • Content
    • Display Types (View Modes)
      • Teaser
      • Card
      • Search Result
    • Lists (Views)
      • Blog
      • Search Results
    • Content Types
      • Basic Page
      • Blog
      • Event
  • Page Sections (Regions)
    • Header
    • Footer
    • Sidebar
  • Sample Pages
    • Homepage
    • Blog Listing Page
    • Blog Node

After that, I have Backstop.js set up to regression test all of these, so each time I create a new component I can quickly run the visual regression tests and check that nothing has broken. Since all my CSS/JS is scoped to each individual component, it's rare if something is.

Categories: Drupal

Weekly useful Drupal things to know thread

Drupal - Open Source Content Platform - Fri, 05/18/2018 - 10:08

What's a useful tip or technique or tool (or anything) that you picked up and think others should know about?

(Check out the weekly post schedule in the sidebar)

submitted by /u/AutoModerator
[link] [comments]

Specbee: 5 Reasons Why Media Industry is Choosing Drupal CMS Over Other Platforms in 2018

drupal.org aggregator - Fri, 05/18/2018 - 09:24
The high demand for creating a seamless digital experience across numerous devices and channels has challenged the classic approach of the media industry. The changing technology landscape and the business models have forced the companies to think out-of-the-box to drive customer interaction and avoid competitive differentiation to catch up with them.
Categories: Drupal

Paragraphs Horizontal Rule

drupal.org - Modules - Fri, 05/18/2018 - 09:08

A simple paragraph type that allows the user to insert a horizontal rule <hr> into the page.

By default there are two possible horizontal rule 'types' (CSS classes) that can be applied to the paragraph.

  • Thin (hr--thin)
  • Thick (hr--thick)

These values can be altered via the hook_paragraphs_hr_allowed_values_alter function.

e.g.

Categories: Drupal

Blank Node Title

drupal.org - Modules - Fri, 05/18/2018 - 08:33
Categories: Drupal

Zoocha Blog: User login in Drupal 8 with AWS Rekognition

drupal.org aggregator - Fri, 05/18/2018 - 07:43
User login in Drupal 8... Drupal Web Development titi 18 May 2018 Idea We've recently attended the AWS London summit and this year it seemed like the focus was AI and machine learning. One of the services I've been meaning to play with is Rekognition, whichh can do face detection and compare two faces among many other things. While sitting in one…
Categories: Drupal

OpenSense Labs: Drupal ensuring the Web Accessibility Standards

drupal.org aggregator - Fri, 05/18/2018 - 05:48
Drupal ensuring the Web Accessibility Standards Akshita Fri, 05/18/2018 - 15:18

Just like land, air, and water are meant for everyone, the web was designed to work for all people and expel any hindrance, irrespective of the surroundings and capabilities of people. But the effect of incapacity (of individuals) in the light of the fact that the web standards don’t include all in itself has become a barrier. Creating quite the paradox in the situation. 

Before completing this blog, my ignorance led me to believe that web accessibility was limited to ‘accessibility only for people with disability’. Another thing that I was coxed to believe was that it is almost synonymous with visibility issues. But it is as much for a person with auditory disabilities as it is for a person with cognitive or neurological disabilities. However, I realized I was not the only one associating such wrong notions with disabilities and web accessibility. Lack of awareness and taboos associated with disabilities often mislead us.

Ensuring that people with disability have equal and inclusive access to the resources on the web, governments and agencies follow certain guidelines in order to establish equal accessibility for all without any bias. 

What are Web Accessibility Standards and why do they matter? “Web Content Accessibility Guidelines (WCAG) is developed through the World Wide Web Consortium process with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.”

The WCAG explains how the web content be made more accessible to people. Here the word "content" refers to any and every kind of information in a web page, such as text (include heading and captions too), images, sounds, codes, markup - anything that defines the layout and framework.  

Take examples of physical infrastructures like ramps and digital vision signboards, which can be used by anyone, in a similar fashion web accessibility is for everyone.

When you go out in the noon, the level of contrast can be an issue as much for a person with 6/6 vision as it can be for a person with visibility issues. Or say, older people (due to aging) face problems with changing abilities, as much as people with “temporary disabilities” such as a broken arm or lost glasses. Thus, not only web accessibility standards ensure justice for people with disability but, it is inclusive for all. 

According to the Convention on the Rights of Persons with Disabilities by the United Nations, enjoying equal human rights is a fundamental freedom. To ensure the dignity of people with disability is not a subject of ridicule, governments across the globe signed a treaty for easy web accessibility. 

How does Drupal help?

A person may face an issue either when building a website or when using it. The WCAG ensures that both the times the guidelines are followed. The World Wide Web Consortium (W3C) guidelines are then divided into two: ATAG 2.0 and WCAG 2.0. Authoring Tool Accessibility Guidelines (ATAG 2.0) addresses authoring tools and Web Content Accessibility Guidelines (WCAG 2.0) addresses Web content and is used by developers, authoring tools, and accessibility evaluation tools. 

Drupal conforms to both the guidelines. The initiative started with Drupal 7 accessibility and the community has been committed to ensuring that accessibility for all. 

What Drupal does...

The community has an accessibility team which works to identify the barriers both at the code level and the awareness level to resolve them. As a person using assistive technologies to browse the web, Drupal is built to encourage and support the semantic markup (which comes out-of-box in Drupal 8 now).

One can realize that the improvements are meant for both the visitor and administrator in the:

  • Color contrast and intensity
  • Drag and Drop functionality
  • Adding skip navigation to core themes
  • Image handling
  • Form labeling
  • Search engine form and presentation
  • Removing duplicate or null tags
  • Accessibility for Developers
Modules For Accessibility

Following are some of the Drupal modules which will assist you in keeping up with the accessibility standards. 

  1. Automatic Alt text
    The basic principle at work here is the idea of easy perceivability. Any and every information should be, thus, presented in such a way that is easily perceivable to the user. It is required for any non-text information like images and video to describe the content in the form of text for the screen readers to read it. 



    The Automatic Alt text module automatically generates an alternative text for images when no alt text has been provided by the user. This module works great for the websites and portals with user-generated content where the users may even not be aware of the purpose and importance of the Alternative text. 

    It describes the content of the image in one sentence but it doesn’t provide face recognition. 
     
  2. Block ARIA Landmark Roles
    Inspired by Block Class, Block ARAI Landmark Roles adds additional elements to the block configuration forms that allow users to assign a ARIA landmark role to a block.
     
  3. CKEditor Abbreviation
    The CKEditor Abbreviation module adds a button to CKEditor which helps in inserting and editing abbreviations in a given text. If an existing abbr tag is selected, the context menu also contains a link to edit the abbreviation.

    Abbr tag defines the abbreviation or an acronym in the content. Marking up abbreviations can give useful information to browsers, translation systems, and help boost search-engines.
     
  4. CKEditor Accessibility Checker
    The CKEditor Accessibility Checker module enables the Accessibility Checker plugin in your WYSIWYG editor. A plugin, the module lets you inspect the accessibility level of content created and immediately solve any accessibility issues that are found.
     
  5. High Contrast
    On April 13, 2011, Joseph Dolson published an article "Web Accessibility: 10 Common Developer Mistakes" stating the most common mistakes related to web accessibility and quoted that most of the issues have "more to do with a failure to understand what constitutes accessible content than with a failure to understand the technology"

    In most of the surveys, poor contrast level is often cited as the most commonly overlooked feature by the developers.

    High Contrast module, provides a quick solution to allow the user to switch between the active theme and a high contrast version of it helping them pull out of the problem.

  6. htmLawed
    According to the "Ten Common Accessibility Problems" an article by Roger Hudson, failure to use HTML header elements appropriately is one of the key accessibility issues. 

    The htmLawed module utilizes the htmLawed PHP library to limit and filter HTML for consistency with site administrator policy and standards and for security. Use of the htmLawed library allows for highly customizable control of HTML markup.

  7. Style Switcher
    The Style Switcher module takes the fuss out of creating themes or building sites with alternate stylesheets. Most of the accessibility issues have been confronted at the theming level. With this module, themers can provide a theme with alternate stylesheets. Site builder can add other alternate stylesheets right in the admin section to bring it under the right guidelines of accessibility. Allowing special styling of some part of the site, the module presents all those styles as a block with links. So any site user is able to choose the style of the site he/she prefers.

  8. Text Resize
    The handiest feature giving the end users just the right autonomy to resize the text as per their comfort of the eyesight. The Text Resize module provides the end-users with a block that can be used to quickly change the font size of text on your Drupal site. 

    It includes two buttons that can increase and decrease the size of the printed text on the page.

  9. Accessibility
    A module for the developer, Accessibility module gives you a list of available Accessibility tests, (most of which are) aligned with one or more guidelines like WCAG 2.0 or Section 508. 

    It immediately informs the site maintainer about the missing an “alt” attribute in an image, or if the headers are used appropriately. Further, each test can be customized to fit your site’s specific challenges, and customize messages users see for each test so that you can provide tips on fixing accessibility problems within the context of your site’s editing environment.

Drupal 8 Features for Accessibility 

Other than the modules that can assist you to overcome web compatibility issues, here is a list of top Drupal 8 features for easier web accessibility. 

  1. Semantics in the Core
    When an assistive device scans a web page for information, it extracts the data about the Document Object Model (DOM), or the HTML structure of the page. No further information is read by the screen reader.

    Often these assistive devices only allow a user to select to read the headings on the page or only the links. It prioritizes according to the hierarchy in which the headings and links are presented making browsing easier for users of assistive devices. 

    Drupal 8 is based on HTML5. Presenting new and better semantic components HTML5 is, in fact, one of five major initiatives outlined in Drupal 8 development. It allows theme developers to control where to use the new semantic elements and opt out entirely if they so choose. 

    When we compose semantically correct HTML, we’re telling the browser and the assistive technology what type of content it is managing with and how that information relates to other content. By doing this, assistive technology is all the more effortlessly ready to carry out its activity since it has a structure that it can work with.
     
  2. Aural Alerts
    Often page updates are expressed visually through color changes and animations. But listening to a site is a very different experience from seeing it, therefore, Drupal provides a method called “Drupal.announce()”. This helps make page updates obvious in a non-visual manner. This method creates an aria-live element on the page.

    This also lets the user know of any alert box appearing along with providing instructions to screen reader users about the tone as well. Text attached to the page is read by the assistive technologies. Drupal.announce accepts a string to be read by an audio UA. 
     
  3. Controlled Tab Order
    The accessibility issues also crop when a user uses different mediums while navigating the web. Not every user uses a mouse to navigate the website. The TabbingManager, in Drupal, is an awesome medium to direct both non-visual and non-mouse users to access the prime elements on the page in a logical order. It, thus, permits more control when exploring complex UIs.

    The tabbing manager helps in defining explicit tab order. It also allows elements besides links and form to receive keyboard focus. Without breaking the tab order it places the elements in a logical navigation flow as if it were a link on the page.
     
  4. Accessible Inline Form Errors
    It is important to provide the necessary feedback to users about the results of their form submission. Both the times when successful and when not.  This incorporates an in-line feedback that is typically provided after form submission.

    Notifications have to be concise and clear. The error message, in particular, should be easy to understand and provide simple instructions on how the situation can be resolved. And in case of successful submission, a message to confirm would do. 

    Drupal forms have turned out to be impressively more open to the expansion of available inline form errors. It is now easier for everyone to identify what errors they might have made when filling in a web form.

  5. Fieldsets
    Fieldset labels are utilized as systems for gathering related segments of forms. Effectively implemented label gives a visual diagram around the shape field gathering. This can, to a great degree, be valuable for individuals with cognitive disabilities as it viably breaks the form into subsections, making it easier to understand.

    Drupal presently uses fieldsets for radios & checkboxes in the Form API. This helps towards additionally upgrading forms in Drupal.

Conclusion

However good the features Drupal offers, in the end, it is up to the organizations to strategize and build the websites and applications around the web accessibility.   

We ensure that our different teams and interaction work together in order to make the Web more accessible to people with disabilities. At OpenSense Labs we design and develop the web technologies to ensure universal accessibility. Connect with us at hello@opensenselabs.com to make the web a better place. 

blog banner blog image Blog Type Articles Is it a good read ? On
Categories: Drupal

Agiledrop.com Blog: AGILEDROP: A Short Introduction to Headless Drupal

drupal.org aggregator - Fri, 05/18/2018 - 05:39
It is a well-known fact by now that Drupal is a very flexible and an extremely agile CMS. Even though it is arguably the most customizable CMS of all, the awesome people behind Drupal aren’t just resting on their laurels due to this. If you’ve been keeping up with any Drupal news or in fact CMS news at all, you might have heard of the term ‘headless’. While the term might sound very odd, it defines something really awesome. So let’s take a look at what headless Drupal is in this post and why it’s so great.   Difference Between Headless and ‘Normal’ Drupal When you run a default Drupal… READ MORE
Categories: Drupal

Need suggestion/help transferring Drupal site to Android. (RESTful Services help).

Drupal - Open Source Content Platform - Fri, 05/18/2018 - 05:19

Hey, guys I am interning at a web-dev company which uses Drupal, they asked me to create a Drupal equivalent of the site in Android, their site isn't that responsive, so when I make a web view it breaks.

There are tuts online on how to simulate it using Views adding an article to a view and deleting it. I understood that we have to authenticate before doing that, but in the big picture when I write a log-in system like functionality for every request the user who logged in make should be sent along with authentication again? or is there another way, Please do tell me if I am getting everything wrong.

submitted by /u/Syntax_3rror
[link] [comments]

List Style Type

drupal.org - Modules - Fri, 05/18/2018 - 05:08
Overview

This module provides a field that can be added to entities, which allows editors to control the list-style-types for the ordered lists in the content, on a page-by-page basis. Editors can use this field to affect nested lists to as deep a level as they'd like.

Use case

This module is intended for the (very specific) use-case where site editors need an easy way to control the list-style-types for all of the ordered lists appearing on one page.

For example, if the lists on one page should look like this...

Categories: Drupal

Valuebound: GraphQL: A Beginners Guide

drupal.org aggregator - Fri, 05/18/2018 - 03:08

GraphQL is the new frontier in Application Programming Interfaces (APIs) - a query language for your API and a set of server-side runtimes (implemented in various backend languages) for executing queries. Further, it isn't tied to any specific database or storage engine; instead backed by your existing code and data.

If you are a Javascript developer then there are better chances that you have heard of it. But you are not sure about it. To help you out, I have written this blog post so that you can easily figure out what exactly is GraphQL and how to make most of it. When you will complete this GraphQL blog cum tutorial, you will be able to answer:

  • What is GraphQL

Categories: Drupal

Dries Buytaert: Working toward a JavaScript-driven Drupal administration interface

drupal.org aggregator - Thu, 05/17/2018 - 13:42

As web applications have evolved from static pages to application-like experiences, end-users' expectations of websites have become increasingly demanding. JavaScript, partnered with effective user-experience design, enable the seamless, instantaneous interactions that users now expect.

The Drupal project anticipated this trend years ago and we have been investing heavily in making Drupal API-first ever since. As a result, more organizations are building decoupled applications served by Drupal. This approach allows organizations to use modern JavaScript frameworks, while still benefiting from Drupal's powerful content management capabilities, such as content modeling, content editing, content workflows, access rights and more.

While organizations use JavaScript frameworks to create visitor-facing experiences with Drupal as a backend, Drupal's own administration interface has not yet embraced a modern JavaScript framework. There is high demand for Drupal to provide a cutting-edge experience for its own users: the site's content creators and administrators.

At DrupalCon Vienna, we decided to start working on an alternative Drupal administrative UI using React. Sally Young, one of the initiative coordinators, recently posted a fantastic update on our progress since DrupalCon Vienna.

Next steps for Drupal's API-first and JavaScript work

While we made great progress improving Drupal's web services support and improving our JavaScript support, I wanted to use this blog post to compile an overview of some of our most important next steps:

1. Stabilize the JSON API module

JSON API is a widely-used specification for building web service APIs in JSON. We are working towards adding JSON API to Drupal core as it makes it easier for JavaScript developers to access the content and configuration managed in Drupal. There is a central plan issue that lists all of the blockers for getting JSON API into core (comprehensive test coverage, specification compliance, and more). We're working hard to get all of them out of the way!

2. Improve our JavaScript testing infrastructure

Drupal's testing infrastructure is excellent for testing PHP code, but until now, it was not optimized for testing JavaScript code. As we expect the amount of JavaScript code in Drupal's administrative interface to dramatically increase in the years to come, we have been working on improving our JavaScript testing infrastructure using Headless Chrome and Nightwatch.js. Nightwatch.js has already been committed for inclusion in Drupal 8.6, however some additional work remains to create a robust JavaScript-to-Drupal bridge. Completing this work is essential to ensure we do not introduce regressions, as we proceed with the other items in our roadmap.

3. Create designs for a React-based administration UI

Having a JavaScript-based UI also allows us to rethink how we can improve Drupal's administration experience. For example, Drupal's current content modeling UI requires a lot of clicking, saving and reloading. By using React, we can reimagine our user experience to be more application-like, intuitive and faster to use. We still need a lot of help to design and test different parts of the Drupal administration UI.

4. Allow contributed modules to use React or Twig

We want to enable modules to provide either a React-powered administration UI or a traditional Twig-based administration UI. We are working on an architecture that can support both at the same time. This will allow us to introduce JavaScript-based UIs incrementally instead of enforcing a massive paradigm shift all at once. It will also provide some level of optionality for modules that want to opt-out from supporting the new administration UI.

5. Implement missing web service APIs

While we have been working for years to add web service APIs to many parts of Drupal, not all of Drupal has web services support yet. For our React-based administration UI prototype we decided to implement a new permission screen (i.e. https://example.com/admin/people/permissions). We learned that Drupal lacked the necessary web service APIs to retrieve a list of all available permissions in the system. This led us to create a support module that provides such an API. This support module is a temporary solution that helped us make progress on our prototype; the goal is to integrate these APIs into core itself. If you want to contribute to Drupal, creating web service APIs for various Drupal subsystems might be a great way to get involved.

6. Make the React UI extensible and configurable

One of the benefits of Drupal's current administration UI is that it can be configured (e.g. you can modify the content listing because it has been built using the Views module) and extended by contributed modules (e.g. the Address module adds a UI that is optimized for editing address information). We want to make sure that in the new React UI we keep enough flexibility for site builders to customize the administrative UI.

All decoupled builds benefit

All decoupled applications will benefit from the six steps above; they're important for building a fully-decoupled administration UI, and for building visitor-facing decoupled applications.

Useful for decoupling of visitor-facing front-ends Useful for decoupling of the administration backend 1. Stabilize the JSON API module ✔ ✔ 2. Improve our JavaScript testing infrastructure ✔ ✔ 3. Create designs for a React-based administration UI ✔ 4. Allow contributed modules to use React or Twig ✔ ✔ 5. Implement missing web service APIs ✔ ✔ 6. Make the React UI extensible and configurable ✔ Conclusion

Over the past three years we've been making steady progress to move Drupal to a more API-first and JavaScript centric world. It's important work given a variety of market trends in our industry. While we have made excellent progress, there are more challenges to be solved. We hope you like our next steps, and we welcome you to get involved with them. Thank you to everyone who has contributed so far!

Special thanks to Matt Grill and Lauri Eskola for co-authoring this blog post and to Wim Leers, Gabe Sullice, Angela Byron, and Preston So for their feedback during the writing process.

Categories: Drupal

Working toward a JavaScript-driven Drupal administration interface

As web applications have evolved from static pages to application-like experiences, end-users' expectations of websites have become increasingly demanding. JavaScript, partnered with effective user-experience design, enable the seamless, instantaneous interactions that users now expect.

The Drupal project anticipated this trend years ago and we have been investing heavily in making Drupal API-first ever since. As a result, more organizations are building decoupled applications served by Drupal. This approach allows organizations to use modern JavaScript frameworks, while still benefiting from Drupal's powerful content management capabilities, such as content modeling, content editing, content workflows, access rights and more.

While organizations use JavaScript frameworks to create visitor-facing experiences with Drupal as a backend, Drupal's own administration interface has not yet embraced a modern JavaScript framework. There is high demand for Drupal to provide a cutting-edge experience for its own users: the site's content creators and administrators.

At DrupalCon Vienna, we decided to start working on an alternative Drupal administrative UI using React. Sally Young, one of the initiative coordinators, recently posted a fantastic update on our progress since DrupalCon Vienna.

Next steps for Drupal's API-first and JavaScript work

While we made great progress improving Drupal's web services support and improving our JavaScript support, I wanted to use this blog post to compile an overview of some of our most important next steps:

1. Stabilize the JSON API module

JSON API is a widely-used specification for building web service APIs in JSON. We are working towards adding JSON API to Drupal core as it makes it easier for JavaScript developers to access the content and configuration managed in Drupal. There is a central plan issue that lists all of the blockers for getting JSON API into core (comprehensive test coverage, specification compliance, and more). We're working hard to get all of them out of the way!

2. Improve our JavaScript testing infrastructure

Drupal's testing infrastructure is excellent for testing PHP code, but until now, it was not optimized for testing JavaScript code. As we expect the amount of JavaScript code in Drupal's administrative interface to dramatically increase in the years to come, we have been working on improving our JavaScript testing infrastructure using Headless Chrome and Nightwatch.js. Nightwatch.js has already been committed for inclusion in Drupal 8.6, however some additional work remains to create a robust JavaScript-to-Drupal bridge. Completing this work is essential to ensure we do not introduce regressions, as we proceed with the other items in our roadmap.

3. Create designs for a React-based administration UI

Having a JavaScript-based UI also allows us to rethink how we can improve Drupal's administration experience. For example, Drupal's current content modeling UI requires a lot of clicking, saving and reloading. By using React, we can reimagine our user experience to be more application-like, intuitive and faster to use. We still need a lot of help to design and test different parts of the Drupal administration UI.

4. Allow contributed modules to use React or Twig

We want to enable modules to provide either a React-powered administration UI or a traditional Twig-based administration UI. We are working on an architecture that can support both at the same time. This will allow us to introduce JavaScript-based UIs incrementally instead of enforcing a massive paradigm shift all at once. It will also provide some level of optionality for modules that want to opt-out from supporting the new administration UI.

5. Implement missing web service APIs

While we have been working for years to add web service APIs to many parts of Drupal, not all of Drupal has web services support yet. For our React-based administration UI prototype we decided to implement a new permission screen (i.e. https://example.com/admin/people/permissions). We learned that Drupal lacked the necessary web service APIs to retrieve a list of all available permissions in the system. This led us to create a support module that provides such an API. This support module is a temporary solution that helped us make progress on our prototype; the goal is to integrate these APIs into core itself. If you want to contribute to Drupal, creating web service APIs for various Drupal subsystems might be a great way to get involved.

6. Make the React UI extensible and configurable

One of the benefits of Drupal's current administration UI is that it can be configured (e.g. you can modify the content listing because it has been built using the Views module) and extended by contributed modules (e.g. the Address module adds a UI that is optimized for editing address information). We want to make sure that in the new React UI we keep enough flexibility for site builders to customize the administrative UI.

All decoupled builds benefit

All decoupled applications will benefit from the six steps above; they're important for building a fully-decoupled administration UI, and for building visitor-facing decoupled applications.

Useful for decoupling of visitor-facing front-ends Useful for decoupling of the administration backend 1. Stabilize the JSON API module ✔ ✔ 2. Improve our JavaScript testing infrastructure ✔ ✔ 3. Create designs for a React-based administration UI ✔ 4. Allow contributed modules to use React or Twig ✔ ✔ 5. Implement missing web service APIs ✔ ✔ 6. Make the React UI extensible and configurable ✔ Conclusion

Over the past three years we've been making steady progress to move Drupal to a more API-first and JavaScript centric world. It's important work given a variety of market trends in our industry. While we have made excellent progress, there are more challenges to be solved. We hope you like our next steps, and we welcome you to get involved with them. Thank you to everyone who has contributed so far!

Special thanks to Matt Grill and Lauri Eskola for co-authoring this blog post and to Wim Leers, Gabe Sullice, Angela Byron, and Preston So for their feedback during the writing process.

Categories: Drupal

Prepared Data

drupal.org - Modules - Thu, 05/17/2018 - 13:36

A batch processing framework for preparing expensive data.

Concept / About this module

Suppose you have a site with pages which are mostly static, thus you want your
pages to live in your cache for a long time - but they're only *mostly* static,
not always. You instead have one or a couple of dynamic parts on your page,
which want to show some (at least almost) current information. Examples:

Categories: Drupal

Mustache Templates

drupal.org - Modules - Thu, 05/17/2018 - 13:26

Integrates Mustache.php plus Mustache.js into Drupal.

Includes a generic framework to build DOM content which can be automatically synchronized on the client-side. Any RESTful Json endpoint can be used for automatic content synchronization.

Using Mustache.php by

  • Copyright (c) 2010-2015 Justin Hileman

Using Mustache.js by

Categories: Drupal

Party GDPR

drupal.org - Modules - Thu, 05/17/2018 - 10:37

Under development.

Integration between the party module and the gdpr module.

Categories: Drupal

Pages