Development News

WPTavern: WordPress Designers Explore Proposal to Simplify WP Admin Navigation

Wordpress Planet - Mon, 05/06/2019 - 20:20

The admin can be intimidating to navigate if you’re just getting started with WordPress. After installing a few plugins, top-level menu items begin to pile on. This adds even more complexity to grapple with in a narrow space with long lists of items hidden behind flyout menus that make managing WordPress on mobile a frustrating experience.

The admin dashboard design hasn’t changed significantly since the MP6 plugin was merged into WordPress 3.8 in 2013. This project brought updated typography and improved contrast to the admin but didn’t tackle the increasing complexity of admin navigation.

A new proposal on trac aims to simplify the left sidebar navigation to improve accessibility, usability, and scalability by replacing the flyouts with accordion menus. Designer Dave Martin shared some mockups originally created by Joen Asmussen, and describes them as “a very early, exploratory concept.”

Martin listed several reasons for exploring a new design, including the inaccessibility of the hover/flyout menus and how poorly they scale on mobile interfaces. He also cited the abundance of top-level menu items that are rarely used, which he said contributes to the cognitive weight of admin navigation by still being permanently visible.

The major changes included in this proposal include the following:

  • Flyout menus are replaced with accordion behavior. This scales all the way from mobile to desktop, and affords better accessibility.
  • Menu is made 80px wider (240px vs. 160), affording a 14px minimum font size for all items, perhaps bigger icons in the future, more relaxed spacing, enhancing usability and accessibility.
  • Sidebar is grouped in major sections, “Site”, “Design”, “Tools” and “Manage”.
  • “Updates” are moved to a subsection of “Manage”, making Home a single item.
  • Items related to content on your site (such as “Posts” and “Pages”) are moved under “Site”.
  • Clicking major menu items just opens or closes the accordion, as opposed to go directly to the first subsection. This unifies the mobile and desktop behavior. You can keep the accordion open if you use it all the time (each click will save state, so you’ll see the same open/closed sections upon page refresh).
  • All “Settings” subsections are moved under “Manage”, along with “Plugins & Blocks” and “Users”.
  • Separators group major categories, like “Site” and “Design” together
  • Dashboard is renamed “Home”, because all of WordPress is a Dashboard, and “Home” is where you can get an overview at a glance.

WordPress core committer John Blackbourn commented on the proposal, recommending further exploration of what the menu could look like for different user roles and whether that might affect the appearance, grouping, and behavior of the menu items. For example, roles with more limited publishing capabilities, such as a subscriber, would see very few menu items.

There’s also a bit of discussion regarding the use of the word ‘Site’ where some might better understand that section as ‘Content.’ As this is just an initial mockup, nothing is set in stone and many iterations will likely follow.

Even with many changes expected as the concept evolves, the proposed design significantly reduces cognitive load, especially for new users who may not be as familiar with the admin menu. An updated admin navigation design might lend itself well to being tested as a feature plugin. As with any major change in WordPress, there are many considerations for how it will affect plugin developers. Major visual overhauls like this are exciting, but it takes time to get it right. This proposal already shows a lot of promise but needs more feedback and participation from diverse user groups across the WordPress community.

Amazee Labs: Using Twig with Storybook and Drupal

Main Drupal Feed - Mon, 05/06/2019 - 18:54
Using Twig with Storybook and Drupal

Using UI pattern libraries in Storybook allow us to build a collection of front end UI components that can be used to build bigger components, even full web pages. However, frontend/backend integrations can be fraught with difficulties. In this piece, I’ll explain our process to make these challenges easy, even when using GraphQL fragments inside Twig templates.

Jamie Hollern Mon, 05/06/2019 - 20:54 What Drupal and GraphQL do well

At Amazee Labs, we build decoupled web applications using GraphQL and Drupal. We’ll touch on the reasons that we use this approach in this article, but if you’d like to know more, check out these blogs:

Drupal is known for its complex and unwieldy theming and rendering system. Data to be rendered comes from across the system in the form of templates, overrides, preprocess functions and contributed modules such as Panels and Display Suite. Sometimes trying to track down where data is being generated or altered is like a murder mystery. 

Thankfully, GraphQL Twig simplifies the situation massively. Each template has an associated GraphQL query fragment that requests the necessary data. This “pull” model (as opposed to Drupal’s normal “push” model) means that finding where the data comes from and how it is structured is really easy. We don’t need to worry about preprocessing or alteration of data, and this method lets us keep the concerns separated.

Advantages of UI component libraries

The main advantage of using a UI component library (also known as a pattern library) is that it facilitates the reusability of components. This means that when a component is created it can be used by any developer on the project to build their parts of the front end and in turn can be used to make larger and more complex components.

There are multiple extra advantages to this, the most obvious being the speed of development. Since all components are simply made up of smaller components, building new ones is usually much quicker, since we don’t need to reinvent the wheel.

This also makes maintenance a breeze, since we’re only maintaining one version of any component. If we decide that all buttons on the frontend need to have an icon next to the text, we simply change the button component and this change will apply everywhere that the component is used.

Finally, the reusability of components in a pattern library means that the UI is consistent. Often, web projects face difficulties where there are multiple versions of various components, each with their own implementation. This is especially true of larger projects built by multiple people, or even multiple teams, where no single person knows the entirety of the project’s implementation details. Thanks to the reusability of our components, we only have one implementation per component.

Challenges of using Drupal, GraphQL, and Storybook together

If done poorly, using pattern libraries like Storybook can be difficult and cause problems during the integration phase(s) of development. The main issue is usually that the frontend and backend developers have different approaches and different goals when developing. 

The frontend developer wants to create the best UI they can in the most efficient way possible, using the paradigms and approaches that are standard or preferred. Unfortunately, at times the implementation doesn’t sync well with the data structure that the backend developers receive from Drupal, so the frontend needs to be refactored or the data structure needs to somehow be altered.

How to make it work

I won’t go into detail on our implementation of the Storybook library, but we keep Storybook in the same repo as our Drupal application, outside the root. We then define a base storybook theme and using the Components module (built by my talented colleague John Albin), we define our path to the Storybook Twig templates as a component library in our .info.yml file. This way, the Drupal theme has access to all of our templates.
 

component-libraries: storybook: paths: - ../../../../storybook/twig

We then create our project-specific theme, which extends the base Storybook theme, and start to work on our integration. A generic page.html.twig file might look like this:
 

{#graphql query { ...Header ...Footer } #} {% extends '@storybook/page/page.html.twig' %} {% block header %} {% include '@storybook/navigation/header.html.twig' with graphql only %} {% endblock %} {% block content %} {{ page.content }} {% endblock %} {% block footer %} {% include '@storybook/footer/footer.html.twig' with graphql only %} {% endblock %}

So, how does GraphQL tie in here? Well, this is the really clever part. Our developers can create the GraphQL snippets to get the data needed for a specific component, and Storybook allows us to use JavaScript to use this data as mock fixtures. This means that the frontend can be built with realistically structured data, so no refactoring of templates or data alteration on the backend is needed. And since we already have the GraphQL snippet, this automatically works when run in Drupal. 

Conclusion

At Amazee, we use a UI component library because it makes sense to build a maintainable, reusable and consistent set of components for our frontend that also encourages faster development. We also try our best to streamline our integration processes so that all of our developers are more closely aligned and developing solutions that make it easier for their colleagues to use, learn and extend easily. 

Storybook gives us the power to build a component library using mock data that is structured in the exact manner that our GraphQL queries deliver it. This means no refactoring, building both queries and templates only once and an overall smooth integration process. 

Want to know more about using GraphQL and Twig? Check out our webinar
 

qed42.com: EVERYTHING YOU NEED TO KNOW ABOUT DRUPAL 8.7

Main Drupal Feed - Mon, 05/06/2019 - 15:13
EVERYTHING YOU NEED TO KNOW ABOUT DRUPAL 8.7 Body

Drupal released its latest version - Drupal 8.7.0 on 1st May 2019. The latest version of Drupal 8.7.0 accomplishes tasks like making page layouts, media management and decoupled web experiences easier to manage and deliver, conserving production time and effort and it was recently revealed at DrupalCon Seattle 2019.

Core objectives when developing Drupal 8.7 were to:

  • Make Drupal easy for content creators and site builders
  • Make Drupal easy to evaluate and adapt.
  • Keep Drupal impactful and relevant
  • Reduce total cost of ownership for developers and site owners
JSON:API at Core:


The latest Drupal 8.7 update includes JSON:API as a part of the Drupal core!  
This makes Drupal an API first platform for building both decoupled and coupled applications. JSON API module exposes the entities as a standards-compliant web API and data can then be pulled from third-party URLs or API’s.

JSON:API is designed specifically to minimize both the number of requests and the amount of data transmitted between clients and servers. This efficiency is achieved without compromising readability, flexibility, or discoverability.

By enabling the JSON:API module, you can immediately create a full REST API endpoint for every type(content, taxonomy, user, etc.) in your Drupal application. JSON:API inspects your entity types and their bundles to dynamically provide URLs to access every entity using the standard HTTP methods, GET, POST, PATCH, and DELETE.

JSON:API adopts the philosophy that the module should be production-ready. This means the module is highly opinionated about where your resources will reside, what methods are immediately available for them, and allows Drupal Core's permissions system control the access. The configuration pages are no longer present in this upgrade (Drupal 8.7). This means that you can get an API-driven Drupal application up and running with minimal effort.

Watch the JSON:API demohere!

Stable Layout Builder

The Stable Layout Builder was released with Drupal 8.6 as an experimental module and now it is stabilized in Drupal 8.7.

Drupal 8's Layout Builder allows content editors and site builders to easily and quickly create visual layouts for displaying content. Users can customize how content is arranged on a single page, across content types, or even create custom landing pages with an easy to use drag-and-drop interface.

Explore the sections below to find out how to get started with Layout Builder and how to apply it to templated content types. Layout Builder is anchored on one of Drupal’s stronger features – the ability to create structured content; but it faces some of the same accessibility challenges encountered by  WordPress’ Gutenberg editor. Drupal's Layout Builder offers a single, powerful visual design tool for three use cases:

Layouts for templated content: The creation of "layout templates" that will be used to layout all instances of a specific content type (e.g. blog posts, product pages).
Customizations to templated layouts: The ability to override these layout templates on a case-by-case basis (e.g. the ability to override the layout of a standardized product page).
Custom pages: The creation of custom, one-off landing pages not tied to a content type or structured content (e.g. a single "About us" page).

Watch the Demo of Drupal 8 Layout Builderhere!

Media Library

Drupal 8.6 had Media Library in the Drupal core, which was a part of Media Initiative. In Drupal 8.7 Media Library comes with a new stylish and handy user interface. Which makes it nice to look and nice to work with. Media library is now stable.

  Third-party library updates
  • Guzzle has been updated from 6.3.0 to 6.3.3.
  • Previously, Drupal packaged a copy of the PEAR Archive_Tar library in a Drupal core namespace. In Drupal 8.7, this has been deprecated and replaced with a proper Composer dependency on this library. The dependency has also been updated to version 1.4.6.
  • Stylelint has been updated from 9.1.1 to 9.10.1. Stylelint version: https://github.com/stylelint/stylelint/releases/tag/9.10.1
  • Coder to ^8.3.1
  • CKEditor has been updated to 4.11.3.
  • Twig has been updated to 1.38.4.
  • A number of other PHP dependencies have also been updated, including:
  • composer/installers to 1.6.0
  • composer/semver to 1.5.0
  • egulias/email-validator to 2.1.7
  • paragonie/random_compat to v2.0.18
  • Most symfony/* components to v3.4.26
  • symfony/http-foundation to v3.4.27
  • symfony/polyfill-* to v1.11.0
  • typo3/phar-stream-wrapper to v2.1.0
Other updates you can find in Drupal 8.7 are: Internet Explorer 9 and 10 will not be supported in Drupal 8.7

The 8.7.0 release is a final goodbye to Internet Explorer 9 and 10. It removes a workaround that still existed in D8.5 and D8.6 Issue link: Internet Explorer 9 and 10 support dropped from Drupal 8.4.x

Goodbye PHP 5 support

Drupal 8.7 is the last release to support PHP 5. Updates for existing websites that use PHP 5 are still possible, but a warning will be displayed. In release 8.8, Drupal security updates will require PHP 7.

Entity updates will not be automatic

In new Drupal 8.7.0 release, the support for automatic entity updates has been removed. The reason is data integrity issues and conflicts. So the drush entity: updates (drush entup) command no longer works. Changes to entities will now be performed using standard update procedures.

Symfony 4 and 5 compatibility issues resolved

Additionally, numerous critical Symfony 4 and 5 compatibility issues are resolved in this release.

Changes to base themes (Stable, Classy)

This release includes some small changes to the core's base themes (Stable, Classy). Themes that extend one of these base themes should review the following changes. JavaScript messages template changes. Pager CSS ID changed from "pagination-heading" to a unique ID.

 

These Drupal upgrades are gradually getting us ready for Drupal 9. If you have questions regarding Drupal upgrades we are here to help. Drop us a word at .

sonvir.choudhary Mon, 05/06/2019 - 20:43

Promet Source: The Truth about Automated Web Accessibility Testing: It’s Complicated

Main Drupal Feed - Mon, 05/06/2019 - 03:24
In a world where global positioning systems appear to have a handle on every square inch of the roads we’re traveling on, doesn’t it seem like there should be automated website accessibility testing tools that function as well as -- if not better -- than manual testing?  The fact is ... it’s complicated.

WPTavern: Gutenberg Plugin for OctoberCMS Now in Beta

Wordpress Planet - Fri, 05/03/2019 - 23:01

Last week we reported on Laraberg, a Gutenberg implementation for Laravel that is now in beta. The project was based on Gutenberg.js, a package that makes it easier to bring Gutenberg into other applications.

Nick Khaetsky, a backend developer at Biz-Mark, took Laraberg and used it to build a Gutenberg plugin for the open source OctoberCMS, which is based on Laravel. OctobeCMS was launched in 2015, and still captures only a tiny sliver of the CMS market share, but it is growing in popularity among the top one million websites, according to stats from BuiltWith. The CMS has a growing ecosystem of more than 700 themes and plugins.

The Gutenberg for OctoberCMS plugin is now in beta. It allows developers to embed Gutenberg in the backend via their own model by creating a Polymorphic relation. The plugin integrates Laraberg but all of its blocks are standard from the Gutenberg.js package. It doesn’t include anything custom.

Most aspects of Gutenberg are working in the beta, including common blocks, formatting, layout, and embed blocks, custom styles, and block settings.

None of WordPress’ standard widgets work in the plugin and Khaetsky said he plans to remove them in future updates.

Anything that requires media uploading, such as the gallery block, inline images, and cover block, are not working. Khaetsky said he is working on getting the plugin integrated with the native OctoberCMS Medialibrary. He encouraged anyone who wants to contribute to that effort to submit a PR to the plugin’s GitHub repository.

Khaetsky’s free plugin is MIT-licensed and available in the official OctoberCMS plugin marketplace. The plugin’s adoption is limited to developers who know how to implement it, but it already has 39 installations. Documentation is available on the plugin listing.

WPTavern: Block Options Plugin Rebrands to EditorsKit, Expands Beyond Block Visibility Management

Wordpress Planet - Fri, 05/03/2019 - 20:35

WordPress plugin developer Jeffrey Carandang has rebranded his Block Options plugin to EditorsKit. Carandang created Block Options prior to co-founding CoBlocks, which was recently acquired by GoDaddy. It began as a plugin for controlling block visibility, inspired by his Widget Options plugin, but has since grown to include more features for managing Gutenberg blocks. EditorsKit now offers the following capabilities:

  • Devices Visibility Options
  • User Login State Visibility
  • Display Logic
  • Advanced Custom Fields Integration
  • Block Guide Lines

“As much as I love the name ‘Block Options,’ it has started to become too generic and has been used a lot on the Gutenberg editor itself,” Carandang said. “So, I have decided to change the name to something that stands out and fits the purpose more – page building block options for the new editor.

“The name EditorsKit came from ‘Editor’s Toolkit.’ I’ve been progressively moving towards building a set of tools that will help users navigate through the editor more conveniently, besides giving them visibility control.”

Version 1.4 of the plugin introduces the new Block Guide Lines feature, one of the features to go beyond visibility management. It allows users to toggle guide lines on/off for titles and editor blocks to check element boundaries. Carandang said the feature becomes especially useful when handling nested blocks.

The last major release of the plugin also improves the UI and UX with a new “Visibility Settings” modal for managing all visibilities in the same place. The modal includes an “Advanced” tab for more complicated options that are more likely to be used by developers, such as custom display logic and ACF visibility support.

Under the umbrella of its new branding and website, Carandang plans to expand EditorsKit to include more tools, with the next set focused on developers. Next on the roadmap is a setting to toggle Auto Save on/off and theme support for page template body classes.

Check out a quick preview of the improved interface and new features below:

Drupal Association blog: Make our membership campaign a success

Main Drupal Feed - Fri, 05/03/2019 - 19:04

This month, we're running a membership campaign to grow our base of support and connect with more of the Drupal ecosystem. We're challenging you to take one step this month to brighten Drupal's future: invite your colleagues and clients to join the Association for Drupal's future.

By building a broader membership base, we're securing a financial future for supporting the Drupal community. A large, global base of members who contribute to sustain the Association are a force! Every member who participates is making an impact and a statement that Drupal is here to stay.

Thank you for taking the time to share this campaign.

The campaign page is full of information on our work toward current goals that help fulfill our mission. If you are using Drupal or contributing to the project, there's some part of what we do that helps you and the community at large.

Drupal Association blog: Make our membership campaign a success

Main Drupal Feed - Fri, 05/03/2019 - 19:04

This month, we're running a membership campaign to grow our base of support and connect with more of the Drupal ecosystem. We're challenging you to take one step this month to brighten Drupal's future: invite your colleagues and clients to join the Association for Drupal's future.

By building a broader membership base, we're securing a financial future for supporting the Drupal community. A large, global base of members who contribute to sustain the Association are a force! Every member who participates is making an impact and a statement that Drupal is here to stay.

Thank you for taking the time to share this campaign.

The campaign page is full of information on our work toward current goals that help fulfill our mission. If you are using Drupal or contributing to the project, there's some part of what we do that helps you and the community at large.

Lullabot: Using Laravel’s Homestead for Drupal Projects

Main Drupal Feed - Fri, 05/03/2019 - 18:35

For a long time now, I’ve preferred Vagrant for local development. My starting point of choice for using Vagrant on a project has been the excellent trusty32-lamp VM, maintained by Andrew Berry. However, with Ubuntu 14.04 reaching end of life, Andrew thought to merge the best of trusty32-lamp VM with Laravel’s Homestead.

Post Status: An Interview with Reyes Martínez of Frontity — a new WordPress framework

Wordpress Planet - Fri, 05/03/2019 - 17:48

Previously known as Worona, Madrid-based Frontity is close to launching their eponymous public beta, described on Github as both “an alternative rendering engine for WordPress,” and “a React framework to create WordPress themes.” Frontity, the framework, runs separately from WordPress on Node.js and uses the WordPress API to generate HTML and AMP pages. Unlike other approaches to “headless” WordPress, Frontity is the first to be built exclusively for WordPress.

PS: Can you give us an overview of Frontity’s history and how your company, product, and brand has developed?

Reyes Martínez

RM: It all started back in 2015 when Pablo Postigo and Luis Herranz created Worona, a free WordPress plugin to turn blogs into mobile apps. Pablo and Luis discovered a lot of people were concerned about the way their WordPress sites performed on mobile devices. They thought it would be a powerful solution to build an open source platform that could be extended by other WordPress developers.

I met Pablo and Luis in late 2015, loved their project and joined them. I was used to working with WordPress as a content editor, but I didn’t have a technical background. So I mostly started helping by writing blog posts, social media content, documentation, and providing user support. Now I’m in charge of Frontity’s marketing and communications. (I still don’t code but would love to learn at some point!)

After that first prototype, they decided to develop a free platform not just for creating mobile apps. The idea was that any WordPress user could build mobile apps, progressive web apps, or add Google AMP to their blogs in a very easy way. This was Worona 1.0, which was launched in February of 2017. Thousands of WordPress users joined that journey, and we’re truly thankful for that. At that time we already used React and fetched the blog’s content using WordPress’s REST API. The mobile apps were created with Cordova.

Although Worona had a loyal following, we were aware that mobile app usage was slowly declining. People don’t want to download an app for every blog they read. Plus, Apple stopped supporting apps from app generation platforms like ours. This became a serious problem as we couldn’t grow under that scenario.

That’s when we decided to bet on the mobile web and started working on a new framework for building Progressive Web App themes (based on React) on top of WordPress. In 2018 we rebranded to Frontity and got financial backing to make the project grow. Although our main goal was to keep the code open source, we decided to use it internally and release a product exclusively to WordPress publishers (we called it Frontity PRO), so we could see what happened and gather feedback.

Frontity PRO is a proprietary mobile theme built on React for WordPress blogs and news sites. It implements Progressive Web App technologies and uses the REST API to fetch the content, along with our WordPress plugin, WordPress PWA.

By the time Frontity PRO was created, we also contributed to the official WCEU PWA. Building a PWA from the ground up is a difficult and time-consuming task, but we had created a framework to precisely solve that problem. It was the perfect time to test it out and give back to the community.

We have worked with Spanish media companies since we launched Frontity PRO, and the result has been great. Our theme has allowed them to deliver faster and more engaging mobile experiences, which has been proven to increase their pageviews and ad revenue. Our internal framework has served content to more than 20 million readers. Some of our major clients were part of ADSLZone group. Others include Medios y Redes, Tendenzias or Coches.com. They all use WordPress.

During this time, we realized that many of our clients’ tech teams were considering using our framework to develop their own custom themes. This was one of the main reasons that made us think about open sourcing it — it seemed the perfect moment. Plus, this was our original vision.

A few months ago, we finally decided to go straight for that vision. We set aside the development work of Frontity PRO to place all our focus on Frontity.org, the open source framework. Our next milestone is to release the first beta version in the next few weeks. (Early May 2019.) More than 300 developers have already signed up to try it out. We are really excited about this project and believe it can make a real impact in the WordPress ecosystem.

Since our resources are limited, we are looking for some financial backing again to bring contributors on board and build a thriving community of people interested in WordPress and React.

PS: What problems does Frontity solve? (And whose problems are they?) Will Frontity make frontend development more accessible to people who are new to React?

RM: In order to create a WordPress theme with React, developers need to learn and configure lots of different things: bundling, transpiling, routing, server rendering, retrieving data from WordPress, managing state, managing CSS, linting, testing,…

There are already some amazing React frameworks, such as Next.js and GatsbyJS, that can work with WordPress, but they’re not focused exclusively on it. As a result, there’s still some complex configuration and additional tooling left to the developer.

This is what Frontity aims to solve; we want to make everything much simpler for WordPress developers and more accessible to those who are new to React. Each part of the framework has been simplified and optimized to be used with WordPress, and developers don’t need to figure out what tools to use for things like CSS or state management.

Everything is ready so they can get WordPress and React to work together in an easier way.

How does Frontity differ from Genesis, _s, or WP Rig — from the developer and designer’s perspective, and in the end user’s experience?

RM: Genesis, _s or WP Rig are fantastic frameworks to develop WordPress themes based on PHP. These themes use the PHP WordPress rendering engine, which means they rely on a server-side architecture where almost every interaction that is made by the user on his device needs to wait for the server to render the new result. Our framework is focused on developers who want to create a React frontend and connect it to a WordPress backend using the REST API. We can call this a client-side architecture, where all the logic and rendering happen directly on the device and the calls to the server are limited only to data sourcing.

In the last few years, web development has evolved a lot. One of the main reasons is the shift to mobile devices and the need for fast web experiences. Achieving this is not easy using a server-side architecture. This is why client-side libraries like React are becoming so popular.

From the developer perspective, everything changes! A theme developed with Frontity and React has zero PHP in it, only JavaScript and CSS. This might sound like a radical change, but there is a trend of developers using WordPress as a headless CMS with a decoupled JavaScript frontend for whom our framework can be quite useful.

How does Frontity the framework fit into a business model or revenue stream for Frontity the company?

RM: We won’t develop any business model in this initial phase. The framework will always be 100% free and open source. Right now, we are focused on building a community of developers and contributors around the framework.

Possible monetizations in the future are a hosting solution, premium support, or a marketplace of paid themes.

What opportunities do you see for WordPress developers now and in the near future?

RM: With the shift to Gutenberg as well as the rise of headless CMS approaches, the WordPress community has started considering React for their projects. Beside this, modern libraries like React are becoming essential to rich user experiences.

The client-side approach to theme-building opens a world of new possibilities: storing and pre-fetching content, animations within themes, offline experiences, and more. It also has enormous benefits in terms of performance, UX and design.

React presents an opportunity to accelerate things in the WordPress ecosystem, build modern and engaging frontend experiences, and extend what developers can do with this powerful CMS.

Pictured in the Frontity team photo above, from left to right, back row first: Eduardo Campaña (developer), David Arenas (developer), Carmen Fernández (no longer with the company), Mario Santos, (Community), Reyes Martínez (Marketing & Communications), Pablo Postigo (Founder & CEO), and Luis Herranz (Founder & Lead developer).

Hook 42: Community, Development and Leadership at DrupalCon 2019

Main Drupal Feed - Fri, 05/03/2019 - 17:43
Community, Development and Leadership at DrupalCon 2019 Lindsey Gemmill Fri, 05/03/2019 - 17:43

Gábor Hojtsy: Present your own "State of Drupal 9" session, get slides here!

Main Drupal Feed - Fri, 05/03/2019 - 09:27

I am about to present about Drupal 9 at DrupalCamp Belarus in May and then at Drupal Developer Days Transylvania in June . I already presented an Acquia webinar with Dries Buytaert on the topic, and was on the Lullabot Podcast discussing Drupal 9 with Angie Byron and Nathaniel Catchpole. I am a firm believer that this know-how should spread as far and wide as possible. I should not be needed to travel around the globe to present the topic and people should not spend the same time again to redo slides for their local presentations. There is no intellectual property here to hide, as many people should be aware and excited and participating as possible. The topic should be presented at Drupal Meetups, Camps, and inside your own companies. So the natural next step for me was to create an open source slideshow.

I took all that we learned from the webinar and Dries' keynote at DrupalCon Seattle as well as new technology that emerged since then. I also used a free slide template and Google Slides so you can make a copy for yourself and add your own contact information as well as edit the slides down to shorter or longer timeslots. The 51 slides in my test run for about 35 minutes, leaving 10 minutes for discussion in a 45 minute slot. You would likely need to cut content for shorter sessions. There are only basic buildup animations, so if you need to present offline that is also an option. Edit in your contact/introduction info and export and present as PDF.

The 1.0 version of the slides have been presented by Christian Fritsch at DrupalCamp Munich last week and I updated some content to the current 1.1 version as it is available now. I'll keep updating slides based on all your feedback. I shared the slides with public comments allowed, so keep the feedback coming there, comments here or some other way you can get ahold of me.

Resources to watch/listen to learn more include:

  1. Dries' State of Drupal presentation from DrupalCon Seattle
  2. Lullabot Podcast on Drupal 9
  3. Acquia Webinar on Drupal 9

Thanks to Acquia for funding me to create this slideshow and thank you for presenting it!

WPTavern: WordCamp US 2019 Tickets Now on Sale

Wordpress Planet - Fri, 05/03/2019 - 04:29

Tickets for WordCamp US 2019 went on sale this week. The event will be held November 1–3, 2019, in St. Louis, MO, at America’s Center Convention Complex.

For just $50, attendees will have access to everything throughout the three-day event, including more than 40 speaker presentations, workshops, “birds of a feather” meetups, and Contributor Day. The price also includes lunches, morning and afternoon snacks, admission to the WordFest party on Friday night, and a commemorative tee shirt with a surprise gift.

This year, parents bringing children children under 9 years old have a separate ticket option where they can indicate whether or not they are interested in on-site child care during the conference. There is no additional cost for selecting the “Parent with Kids” ticket option. Organizers are currently considering various options for childcare.

WordCamp is about diversity, this is not a catch phrase, it is not just a moment. It is about real people, doing real things, in the real world across gender, generation and culture. WordCamp embraces the world. #WordCamp #WordPress @WordCamp #WCUS pic.twitter.com/GdcCDNJYed

— WordCamp US (@WordCampUS) May 2, 2019

WordCamp US organizers have secured a block of hotel rooms at The Marriott St. Louis Grand with a special rate for conference attendees ($149/night). It is located directly across from the official venue. They anticipate the hotel block will sell out quickly. Attendees can follow the link from the WCUS website to reserve a room.

Attendee Services is now open, and this includes assistance with visa applications. Any prospective attendee who requires a visa may request a letter from WCUS organizers for the application. Requests must be made before September 1, 2019, in order to be processed in a timely way.

Speakers will be notified of their acceptance in June and the full schedule will not be announced until July. Volunteer applications will also open in July. Check out the WordCamp US 2019 Timeline to get a quick overview of what’s next and follow @WordCampUS on Twitter for all the latest.

DEV :: Drupal, Skepticism and Spaceships...: Where is drush?

Main Drupal Feed - Thu, 05/02/2019 - 22:58
Where is drush? Unifex Fri, 05/03/2019 - 10:58

Part of me is suspecting that I may be one of the lucky 10,000 today but I figure it's worth putting this out there because if I wasn't aware of this then there may be others too. It turns out that the version of Drush that you just installed may not be the version of Drush that executes your command.

So, as it happens there's a number of ways to install Drush. Older OSs may have it in the package management system, you may have just installed it globally using the instructions on the site, or, if your project is managed by composer it may have been installed as a site-local version. In my case I had messed it up just a little and had multiple versions hanging around and, despite having definitely downloaded and installed drush 8.2.3 to /usr/local/bin/drush and I confirmed that this was being called via which drush when I ran drush --version it informed me I was running version 9.6.2.

The thing that I didn't know... Drush will check the directory the site is in to see if there is a local-site version installed and pass off the request to that. So despite having Drush 8.2.3 installed and called from the command line the request was finding the local copy and returning results from that. If it wasn't for the fact that this was a Drupal 7 site and I'd inadvertently installed Drush 9.x locally via composer (Drush 9.x doesn't support Drupal 7.x) I'd never have known that this was how it worked.

Big thanks to Kirill for correcting my brain meat on this.

Planet Drupal

WPTavern: WPCampus’ Gutenberg Accessibility Audit Finds “Significant and Pervasive Accessibility Problems”

Wordpress Planet - Thu, 05/02/2019 - 19:59

WPCampus has published the results of the Gutenberg accessibility audit the organization commissioned from Tenon, LLC. The audit was crowdfunded by the WordPress community and Matt Mullenweg and Automattic pledged to cover the balance to ensure it would be fully funded.

Tenon’s analysis includes a 329-page technical audit of the editor along with user-based testing that included people with various disabilities. WPCampus’ announcement presents Tenon’s findings in a measured and diplomatic way, encouraging the community to use the report for improving WordPress:

Please use this report as what it is intended to be: constructive feedback in support of the WordPress project. We hope this report generates discussion about accessibility, excitement about inclusive design, and action toward improving the editing experience.

Beyond its use for WordPress core, the audit is also a valuable resource for those extending Gutenberg and more broadly for developers who are building React-based projects.

Tenon’s report includes a 34-page Executive Summary, highlighting key findings from the usability testing and technical review. It’s important to note that the audit was conducted on WordPress version 5.0.3 in January 2019. Since that time the Gutenberg and Accessibility teams have resolved an additional 116 accessibility issues, which will be included in WordPress 5.2 next week.

As expected, Tenon’s results show that overall the markup generated by Gutenberg is “clean, semantically correct and accessible” but that “Gutenberg’s user experience is consistently poor.” The audit found that Gutenberg fails to comply with all 30 of the WCAG 2.1 Success Criteria.

Tenon’s findings confirm the statement WordPress’ Accessibility Team published in October 2018 regarding the editor’s overall level of accessibility:

“The accessibility team will continue to work to support Gutenberg to the best of our ability. However, based on its current status, we cannot recommend that anybody who has a need for assistive technology allow it to be in use on any sites they need to use at this time.”

At that time, many WordPress contributors urged leadership not to ship an editor with critical accessibility issues that prevented people using assistive technologies from moving forward with the latest version.

Tenon’s Executive Summary concludes that the new editor is a step backwards for people with disabilities:

Gutenberg has significant and pervasive accessibility problems, the likes of which amount to a step backwards for users with disabilities over the legacy editor. Our user-based testing – backed by data from our technical review – indicates that the accessibility problems are severe in nature. We feel concerned that Gutenberg’s current accessibility issues will prove problematic for website owners who deploy Gutenberg to content creators in protected populations or for website owners who are themselves part of a protected population. Therefore, organizations which have high risk profiles should consult legal counsel before using it and may want to choose to use the legacy editor instead.

Tenon recommended that Gutenberg’s developers aggressively tackle the issues uncovered in the technical report, given the size of WordPress’ user base. The full report essentially functions as a guide for anyone who wants to contribute to the new editors’ accessibility. It is an excellent resource that outlines each issue with solutions and recommended code, making it easy for developers to get started with meaningful contributions right away. Tenon has created a collection of 84 issues on GitHub based on the findings in the audit and six of them have already been resolved/closed.

Drupal In the News: Drupal 8.7.0 release marks rigorous, unique update to Drupal 8

Main Drupal Feed - Thu, 05/02/2019 - 17:54

Release offers all-new stable layout builder, meets web accessibility guidelines
 
Washington D.C., Wednesday, May 1, 2019 - The Drupal community announces an update to Drupal 8. This new version — Drupal 8.7.0 — is a leap forward in the Drupal content manager experience as a creative tool streamlining workflows and improving efficiency within teams. Drupal 8.7.0 also maintains the project's commitment to web content accessibility guidelines, enabling screen readers or keyboards to navigate options — meaning this version is accessible to all. 
 
Drupal's newly stable Layout Builder module enables a drag-and-drop editing experience, which means no custom code or theming is required in order to lay out pages. But Drupal goes far beyond similar offerings by competitors, empowering content editors with increased power and flexibility: enabling management of templated layouts, support for powerful overrides based on content-type, and support for one-off landing pages. 
 
“Not only can this version support basic use cases, it also supports advanced use cases,” said Drupal Founder Dries Buytaert. “These types of templated layouts and workflow updates are not available in competitors’ layout building tools.” 
 
Drupal 8.7.0 provides significant improvements over all past versions of Drupal, particularly by including JSON:API as a stable module in core. By enabling the JSON:API module, all Drupal entities such as blog posts, users, tags, comments and more become accessible via the JSON:API web service API. This is a powerful, standards-compliant, web service API to pull content into JavaScript applications, digital kiosks, chatbots, voice assistants and more. This propels Drupal further into the lead among headless content management systems, making it the clear choice for the backbone of digital experiences beyond the web.
 
Drupal 8.7.0 provides the JSON:API for reading and modifying resources, interacting with relationships between resources, and filtering, sorting, and pagination of resource collections. It also supports complex workflows, allowing for a staging or approval process. 
 
Tim Lehnen, Executive Director of the Drupal Association, said, “Drupal 8.7 is a milestone release for the Drupal project. It simultaneously extends Drupal's lead as a powerful, API-first content framework, and leapfrogs competitors' tools for content editors.” 

In addition to being incredibly powerful, JSON:API is easy to learn and put into practice, and uses all the existing tooling to test, debug, and scale Drupal sites. 

“This feels like the dawn of a new chapter for Drupal and its authoring experience and we’re certain we’ve only scratched the surface,” said Caroline Casals, a developer at Phase2 - a digital experience agency. 
 
Overall, this version streamlines the user experience for Drupal content creators and site builders, allowing front-end developers to work easily and efficiently. More than two years’ of commits from the open source community built this rigorous release. 
 
“On behalf of the Drupal Association and the Drupal community, I want to thank all of the contributors who made the Drupal 8.7.0 release possible,” Lehnen said. 
 
 
 
About Drupal
Drupal is content management software. It is used to make many of the websites and applications you use every day. Drupal has great standard features, easy content authoring, reliable performance, and excellent security. What sets it apart is its flexibility; modularity is one of its core principles. Its tools help you build the versatile, structured content that ambitious web experiences need.
 
About the Drupal Association
The Drupal Association is dedicated to fostering and supporting the Drupal project, the community and its growth. The Drupal Association helps the Drupal community with funding, infrastructure, education, promotion, distribution and online collaboration.
 

###

Hook 42: Did Someone Say Drupaldelphia? Philly Philly!

Main Drupal Feed - Thu, 05/02/2019 - 16:27
Did Someone Say Drupaldelphia? Philly Philly! Lindsey Gemmill Thu, 05/02/2019 - 16:27

WordPress.org blog: WordPress 5.2 RC2

Wordpress Planet - Thu, 05/02/2019 - 16:17

The second release candidate for WordPress 5.2 is now available!

WordPress 5.2 will be released on Tuesday, May 7, but we need your help to get there—if you haven’t tried 5.2 yet, now is the time!

There are two ways to test the WordPress 5.2 release candidate: try the WordPress Beta Tester plugin (you’ll want to select the “bleeding edge nightlies” option), or you can download the release candidate here (zip).

For details about what to expect in WordPress 5.2, please see the first release candidate post.

This release includes the final About page design. It also contains fixes for:

  • Proper translation of the recovery mode notification emails (#47093).
  • Improvements to the way Site Health works with multisite installs (#47084).
Plugin and Theme Developers

Please test your plugins and themes against WordPress 5.2 and update the Tested up to version in the readme to 5.2. If you find compatibility problems, please be sure to post to the support forums so we can figure those out before the final release.

The WordPress 5.2 Field Guide has also been published, which details the major changes.

How to Help

Do you speak a language other than English? Help us translate WordPress into more than 100 languages!

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

It’s the start of May
and the release is coming.
We all give a cheer!

Lullabot: Lullabot Podcast: Drupal 9 with Angie Byron, Gábor Hojtsy, and Nathaniel Catchpole

Main Drupal Feed - Thu, 05/02/2019 - 13:03

Matt and Mike talk with Angie "Webchick" Byron, Gábor Hojtsy, and Nathaniel Catchpole about the next year's release of Drupal 9. We discuss what's new, what (if anything) will break, and what will remain compatible.

InternetDevels: Meet JSON:API in Drupal core: API-first Drupal future is here!

Main Drupal Feed - Thu, 05/02/2019 - 11:45

“After soliciting input and consulting others, I felt JSON:API belonged in Drupal core.”

Dries Buytaert, creator of Drupal

Read more

Pages