Development News

WPTavern: MapLibre Launches as Official Open Source Successor to Mapbox GL JS

Wordpress Planet - Fri, 01/15/2021 - 23:51

In December, Mapbox shocked its open source contributor community with the news that Mapbox GL JS version 2.0 would be released under a proprietary license. The JavaScript library powers interactive, customizable vector maps on many high profile websites like CNN, The New York Times, Ancestry, Strava, Shopify, Facebook, and more. Older versions remain open source but Mapbox will only be investing in developing new features for the proprietary version going forward.

Multiple parties started their own forks immediately following Mapbox’s announcement. In an effort to avoid fragmentation, the community worked together to merge their ideas under one project. One month later, MapLibre GL is now the official open source successor to Mapbox GL JS. The project’s founders represent a diverse group of companies who relied on the open source software, including MapTiler, Elastic, StadiaMaps, Microsoft, Ceres Imaging, WhereGroup, Jawg, Stamen Design, and more.

“In December 2020, Mapbox released the second version of their JavaScript library for publishing maps online,” MapTiler founder and CEO Petr Pridal said. “However, this time all the new features were overshadowed by a change in the license: previously free as in freedom, it became closed for external contributors and usage was restricted to people with active Mapbox subscriptions. One has to pay even for loading this JavaScript library.”

Pridal said the MapLibre project name is a shortened form of “Map library restarted (or reinvented),” with libre referring to freedom and independence. Its founders agreed that MapLibre should be provider-independent, so developers can load maps from their preferred providers or self-hosted maps.

The community-led fork may also become home to MapLibre GL Native, as contributors are considering a proposal to put MapTiler’s open source fork of Mapbox’s mobile map SDKs for Android and iOS under the MapLibre umbrella.

Mapbox is used by WordPress.com as well as in Jetpack for the Map block. The library is also used in many plugins on WordPress.org, some with tens of thousands of users. Plugin developers who have integrated Mapbox GL JS version 1.13 or older will want to check out the MapLibre project as an open source alternative to Mapbox’s proprietary 2.0 update.

WPTavern: A Multi-Theme System, the Decade-Long Wait for Grandchild Themes, and Themeless Templates

Wordpress Planet - Fri, 01/15/2021 - 21:04

Around 2010, child theming had finally caught its stride. Bigger theme shops were starting to take note, and some were implementing advanced parent themes that were meant to serve as a “framework” for creating child themes. The theme development community hit a bit of a brick wall amid this explosion of child theming. Grandchild themes became a topic of debate.

One of the use cases for child themes was to protect customizations made by end-users. When the parent theme was updated, those changes remained intact within the child theme. Users could get bug fixes and enhancements without worry. It was an ingenious system.

However, another use case for child themes was to create vast customizations of the parent theme. Many of these child themes were marketed and sold to end-users. The problem? There was no way for users to protect their customizations if and when the developer updated the child theme. WordPress had no grandchild theme concept or any other sort of cascading theme system beyond the parent-child relationship.

So, the problem remained. Unsolved.

Some businesses such as StudioPress and its Genesis parent theme thrived over the years with this system. Others moved along. In reality, child theming became a niche feature that WordPress never expanded upon in any meaningful way. Theme authors were left to their own devices. With the arrival of the customizer and the expansion of page builders, code customizations almost disappeared. Most modifications were handled via an interface launched from the WordPress admin. The average user had little need to DIY their way through custom templates. Thus began child theming’s drizzle into near obscurity.

Gutenberg’s site editor, which will likely land in WordPress this year, had seemed to be the upcoming final blow to the child theming paradigm. Everyone from developers to end-users will be able to roll out custom templates directly from the WordPress admin.

However, should we be rethinking the role of a hierarchical theming system?

Full Site Editing is already introducing an extra level to the hierarchy. Traditionally, WordPress theming had a two-tier template hierarchy. In the future, it will add a tier for user-created templates. If that is possible, why not go ahead and throw in grandchild themes? Or, simply do away with such arbitrary limitations altogether?

A new pull request to the Gutenberg repository essentially creates a multi-theme system. Or, rather, it creates a multi-theme templating system. Aside from the style.css, functions.php, and theme.json files, block-based themes are essentially a collection of templates.

The patch is proposing that users should be able to opt into this multi-template system. They would have the option to keep templates from an old theme around when they switch to a new one. While not currently implemented in the pull request, he also proposes allowing users to clone templates from their old theme.

“In recent months, there have been whispers around the future possibility of multiple themes being active, templates being ‘themeless,’ etc.,” wrote patch creator. “This branch is an implementation of that. The idea behind this implementation is there can only be one active theme at a time, but the wp_theme taxonomy can be used to link up individual templates / template parts with one or more themes at a time.”

It does not fulfill the dreams of a decade-old grandchild theme system. However, it could provide some precedent for exploring a full hierarchical theme system.

With the simplification and further standardization of how themes work, we should be dusting off old ideas and shoving them into a new light.

Full Site Editing will eventually solve the grandchild theme problem regardless of whether it had intended to. With the new tier of custom user templates, the upgradability problem created years ago will simply disappear. Users will be able to readily update their parent and child themes without fear of losing customizations. WordPress will safely store their custom templates in the database. It will even keep their design changes via the Global Styles system. Maybe, just maybe, child themes will begin to reach their initial height of popularity.

With the proposed system, users could mix and match templates from unrelated themes. If this happens, it begs the question of whether theme templates are even necessary.

Last year, Rich Tabor opened a discussion on the possibility of a single master theme for WordPress. In that system, WordPress would create a set of base templates. Theme authors could simply override the pieces that they wanted. They could even pare themes down to simple style.css and theme.json files.

That almost seems to be a recipe for bland and boring themes. However, if you couple it with a template directory on WordPress.org similar to what GutenbergHub has already introduced, users could pick and choose the templates they want. It could be both wondrous and disastrous, but I would not mind exploring the idea.

WordPress and its Gutenberg project have a lot of options on the table. Theme building could become interesting in the next year or two.

Update: some names have been removed from this post at the request of the people in question. While this is not standard procedure, they were removed because they were not integral to the story in this instance.

Drupal In the News: On Its 20th Birthday, Drupal Poised To Capture The Next Generation Of The Digital Experience Market

Main Drupal Feed - Fri, 01/15/2021 - 14:38

20 years ago, the Drupal project started in a dorm room—today it is a billion dollar industry.

PORTLAND, Ore., U.S.A and LOCAL AREA HERE, January 15, 2021—Drupal, the world’s leading open source digital experience platform (DXP), celebrates 20 years of community-driven innovation. Since its founding 20 years ago, Drupal has touched millions of lives. One in 30 sites on the web is powered by Drupal, and that means most users of the web have experienced Drupal—even if they don't know it. 

Drupal has pioneered the evolution of content delivery across multiple channels. Whether powering conversational user interfaces (CUI) for smart devices, pushing content to digital signage for New York Metropolitan Transportation Authority (MTA), or serving as the core content store for augmented reality experiences, Drupal’s sophisticated architecture and platform stand ready for the future of digital content. 

Redefining digital experiences

7 years ago—on the eve of Drupal's birthday—Drupal founder and project lead, Dries Buytaert, laid out his belief that the web was entering a new era. 

Mobile had transformed the web, but I believed this was just the beginning. The mobile web was the first example of a new web defined by digital experiences that conform to a user's context and devices,” says Buytaert. “Since then, Drupal has defined itself as the leading platform for ambitious digital experiences, and as channels and devices proliferate, Drupal will continue to lead the open source DXP market.

Powered by a global community of innovation

As part of this 20 year milestone, we celebrate our community of more than 100,000 contributors who made Drupal what it is today,” says Heather Rocker, executive director of the Drupal Association. “Success at this scale is possible because the Drupal community exemplifies the values of open source and proves that innovation is sustained by healthy communities. One of our key goals at the Drupal Association is to convene the resources necessary for continued project innovation, and we do that through the collaboration of a global community that continues to grow year after year.

In fact, Drupal contribution increased by 13% in a year when many industries contracted due to the COVID-19 pandemic. Drupal's open source model has built a robust and thriving ecosystem of individual contributors, professional service providers, and end-user organizations that is well positioned to capitalize on the next 20 years of digital innovation. 

Drupal continues to evolve, serving needs around the globe and expanding into new markets.  Future-looking priorities include a continued positive impact on the Open Web, the cultivation of a diverse and inclusive open source community, and an increased focus on editorial experience and usability—to make the power of the Drupal digital experience platform even more accessible.  

2021 will be marked with year-long celebrations happening around the world with particular focus at DrupalCon in April. Related 20th birthday events can be found on social media through the hashtag #CelebrateDrupal and at CelebrateDrupal.org.  

About Drupal and the Drupal Association

Drupal is the open source digital experience platform utilized by millions of people and organizations around the world, made possible by a community of 100,000-plus contributors and enabling more than 1.3 million users on Drupal.org. The Drupal Association is the non-profit organization focused on accelerating Drupal, fostering the growth of the Drupal community, and supporting the Project’s vision to create a safe, secure, and open web for everyone.

 
###
 
For more information or interview requests contact Heather Rocker,  heather@association.drupal.org
 

Dries Buytaert: Drupal celebrates 20 years!

Main Drupal Feed - Fri, 01/15/2021 - 13:15

On January 15, 2001, exactly 20 years ago, I released Drupal 1.0.0 into the world. I was a 22 years old, and just finished college. At the time, I had no idea that Drupal would someday power 1 in 35 websites, and impact so many people globally.

As with anything, there are things Drupal did right, and things we could have done differently. I recently spoke about this in my DrupalCon Europe 2020 keynote, but I'll summarize some thoughts here.

Why I'm still working on Drupal after 20 years Me, twenty years ago, in the dorm room where I started Drupal. I'd work on Drupal sitting in that chair.

I started Drupal to build something for myself. As Drupal grew, my "why", or reasons for working on Drupal, evolved. I began to care more about its impact on end users and even non-users of Drupal. Today, I care about everyone on the Open Web.

Optimizing for impact means creating software that works for everyone. In recent years, our community has prioritized accessibility for users with disabilities, and features like lazy loading of images that help users with slower internet connections. Drupal's priority is to continue to foster diversity and inclusion within our community so all voices are represented in building an Open Web.

Three birthday wishes for Drupal Me in 2004, giving my first ever Drupal presentation, wearing my first ever Drupal t-shirt.

Drupal's 20th birthday got me thinking about things I'm hoping for in the future. Here are a few of those birthday wishes.

Birthday wish 1: Never stop evolving

Only 7% of the world's population had internet access when I released Drupal 1 in 2001. Smartphones or the mobile web didn't exist. Many of the largest and most prominent internet companies were either startups (e.g. Google) or had not launched yet (e.g. Facebook, Twitter).

A list of technology events that came after Drupal, and that directly or indirectly impacted Drupal. To stay relevant, Drupal had to adjust to many of them.

Why has Drupal stayed relevant and thrived all these years?

First and foremost, we've been focused on a problem that existed 20 years ago, exists today, and will exist 20 years from now: people and organizations need to manage content. Working on a long-lasting problem certainly helps you stay relevant.

Second, we made Drupal easy to adopt (which is inherent to Open Source), and kept up with the ebbs and flows of technology trends (e.g. the mobile web, being API-first, supporting multiple channels of interaction, etc).

The great thing about Drupal is that we will never stop evolving and innovating.

Birthday wish 2: Continue our growing focus on ease-of-use

For the longest time I was focused on the technical purity of Drupal and neglected its user experience. My focus attracted more like-minded people. This resulted in Drupal's developer-heavy user experience, and poor usability for less technical people, such as content authors.

I wish I had spent more time thinking about the less technical end user from the start. Today, we've made the transition, and are much more focused on Drupal's ease-of-use, out-of-the-box experience, and more. We will continue to focus on this.

Birthday wish 3: Economic systems to sustain and scale Open Source

In the early years of the Open Source movement, commercial involvement was often frowned upon, or even banned. Today it's easy to see the positive impacts of sponsored contributions on Drupal's growth: two-thirds of all contributions come from Drupal's roughly 1,200 commercial contributors.

I believe we need to do more than just accept commercial involvement. We need to embrace it, encourage it, and promote it. As I've discussed before, we need to reward Makers to maximize contributions to Drupal. No Open Source community, Drupal included, does this really well today.

Why is that important?

In many ways, Open Source has won. Open Source provides better quality software, at a lower cost, without vendor lock-in. Drupal has helped Open Source win.

That said, scaling and sustaining Open Source projects remains hard. If we want to create Open Source projects that thrive for decades to come, we need to create economic systems that support the creation, growth and sustainability of Open Source projects.

The alternative is that we are stuck in the world we live in today, where proprietary software dominates most facets of our lives.

In another decade, I predict Drupal's incentive models for Makers will be a world-class example of Open Source sustainability. We will help figure out how to make Open Source more sustainable, more fair, more egalitarian, and more cooperative. And in doing so, Drupal will help remove the last hurdle that prevents Open Source from taking over the world.

Thank you A group photo taken at DrupalCon Seattle in 2019.

Drupal wouldn't be where it is today without the Drupal community. The community and its growth continues to energize and inspire me. I'd like to thank everyone who helped improve and build Drupal over the past two decades. I continue to learn from you all. Happy 20th birthday Drupal!

1xINTERNET blog: Celebrating twenty years of Drupal

Main Drupal Feed - Fri, 01/15/2021 - 10:49
During the year 2021 we will be focusing on highlighting our work at 1xINTERNET and our solutions made with Drupal. We call this series “Celebrate 20 years of Drupal” where we will highlight 20 projects through the year that we are involved in and where Drupal has been used.

WPTavern: New Local Blueprint Enables One-Click Setup for Testing Full Site Editing

Wordpress Planet - Fri, 01/15/2021 - 08:21

If you haven’t yet tested the Gutenberg team’s progress on the full site editing (FSE) project, WordPress developer Carrie Dils has created a blueprint for Local that makes it easy to jump right in. Full site editing is phase 2 on the Gutenberg roadmap and is one of the main focuses for WordPress core development in 2021. (Check out What Is Full Site Editing and What Does It Mean for the Future of WordPress for a more in-depth look at why it is critical for end users to provide feedback during its development.)

Local is one of the most popular free development tools for WordPress that allows users to set up new testing sites with one click, along with a host of more advanced features. Blueprints make it possible for users to save any site as a Blueprint so that it can be used as a quick start setup option later. The blueprint includes all files, databases, config files, and Local settings. Dils’ full site editing blueprint includes the following:

  • Gutenberg plugin (with “Full Site Editing” experiment enabled)
  • WordPress theme experiments (these are themes with support for full site editing) with the Twenty Twenty-One Blocks theme enabled
  • Gutenberg test data (demo blog posts that use the most common Gutenberg blocks)

Follow Dils’ instructions for downloading and installing the FSE blueprint on MacOS or Windows. Local does not yet have an easy way for installing and sharing blueprints to other Local users, so you will need to add it to the right place within the application’s files. If you find that you don’t have a Blueprints folder, it may be because it is hidden or because you have never created a blueprint before. Once the zip file is in the right location, you will see the full site editing blueprint among the advanced options when you set up a new site:

Once your site is set up, you can start exploring the brave new world of full site editing. (Be prepared – it is far from production ready but FSE is at a critical time in its development where it needs testing from real users to be a success.) The Gutenberg plugin may need to be updated to the latest. Your new site editing playground can be launched from the Site Editor menu item.

On the frontend you will find the Twenty Twenty Blocks theme activated. You can also test using the Twenty Twenty-One (TT1) Blocks theme, which was added to the WordPress.org Themes directory today, or any of the other experimental block based themes included in the blueprint. Click around, explore the template browser, try editing the template parts, change the global styles, and see how it’s coming along.

The current state of full site editing is rough. It’s hard to tell a feature from a bug at times, but once you get familiar with navigating it you might consider joining the FSE Outreach Experiment. This is an effort to test different aspects of site editing in order to ground the interface in real world feedback as it is developed. For the past few weeks, contributors have been testing the interaction between editing a post versus editing templates.

Anne McCarthy posted the first call for testing to the Make Test blog with instructions for participants.

This call for testing is designed to explore the interaction between the two editing experiences (post vs. template editing) to make sure it’s clear when you’re editing each, granular saving works properly, etc. Ultimately, being able to edit templates like index, single, or archive directly is a huge leap forward compared to what’s been possible in the past! Unlocking this level of customization gives you far more control to build the site you want and this call for testing is to help ensure it’s as intuitive as possible.

The second testing challenge should be published soon. Anyone can contribute by following along with the test script and leaving comments on the post or logging them as issues on GitHub. Participants are also invited to join the #fse-outreach-experiment channel on WordPress Slack for updates or questions regarding testing.

Axelerant Blog: Axelerant Celebrates Drupal By Giving Back

Main Drupal Feed - Fri, 01/15/2021 - 07:49

Open-source has the power to change the world, but, as we depend on it for democratic innovation, open-source also depends on us to thrive. At Axelerant, we know and own this; hence we’re constantly engaging in different open web communities, including Drupal’s.

Why are we writing this? First of all, we are always keen to shine a light on our team members because our people-first culture makes Axelerant succeed. Second, in a knowledge sharing spirit, we are willing to put out what has worked for us (and what we struggle with) regarding contributing and our community involvement.

We are celebrating Drupal’s 20th Anniversary, and we are proud of being part of that history for over a decade. What better way to celebrate than recognizing and sharing the stories of the people involved, the makers that keep the ball rolling.  

Celebrating our people and the community has been among our values since the beginning. Drupal’s 20th anniversary is one of those occasions where both of these values come together in demonstrating Axelerant’s commitment to be a productive part of the amazing Drupal community through its team.

Here, we want to share a few stories from team members who recently contributed and inspired us with their Drupal journey.

Gizra.com: From CI to CD - by example on Travis and Pantheon

Main Drupal Feed - Fri, 01/15/2021 - 00:00
Last year, Mariano had a proposal: let’s try to automatically deploy after successful testing on Travis. We never had anything like that before, all we had is a bunch of shell scripts that assisted the process. TL;DR: upgrading to CD level was easier than we thought, and we have introduced it for more and more client projects. This is a deep dive into the journey we had, and where we are now.

undpaul: Drupal celebrates its 20th anniversary

Main Drupal Feed - Fri, 01/15/2021 - 00:00
Today, just 20 years ago, the first version of Drupal, Drupal 1, was released. Many technologies have emerged in these 20 years, became relevant, lost their relevance again and disappeared. But not Drupal. We join in a loud (and somewhat off-key) "Happy Birthday" in our minds for its 20th birthday. Great that Drupal and its wonderful community have been part of the web world for so long!

Drupal Association blog: Happy 20th Birthday, Drupal

Main Drupal Feed - Thu, 01/14/2021 - 23:46

Today, on Drupal's 20th birthday, we are kicking off celebrations that will last throughout 2021. Together, let’s celebrate 20 years of Drupal and our Community - the inspired makers that keep Drupal innovative. 

As part of this 20-year milestone, we celebrate our community of more than 100,000 contributors who made Drupal what it is today,” says Heather Rocker, executive director of the Drupal Association. “Success at this scale is possible because the Drupal community exemplifies the values of open source and proves that innovation is sustained by healthy communities.”

To kick things off, we have a few ways for you to get involved:

  • Promote the official Press Release of Drupal's 20th birthday to your local tech media
  • Submit your Drupal birthday celebration to Community Events 
  • Post a selfie of your celebration on Celebrate Drupal
  • Submit Drupal milestones to the 20 Years of Drupal History timeline
  • Share your excitement and what you’re doing to celebrate on social media - and be sure to add the hashtag #CelebrateDrupal
  • Participate in our 'Drupal Doodle' event - where we're looking for celebratory banners to feature on Drupal.org
  • Propose content for DrupalCon North America 2021 that showcase the ambitious digital experiences you’ve created with Drupal
  • Register for DrupalCon

With so much to celebrate, today's activities are only the beginning. Keep an eye on this blog, the @drupalassoc on Twitter, and Drupal Association on Linked In for more activities throughout 2021. 

WPTavern: Show and Hide Content via the Block Visibility WordPress Plugin

Wordpress Planet - Thu, 01/14/2021 - 22:23

Nick Diego’s Block Visibility is not the only plugin to take on the challenge of controlling when blocks are visible on the front end. Other plugins like EditorsKit do a fine job of it. However, Block Visibility is a solution users should not overlook, even if they have already begun testing other options.

Diego first released the plugin in August 2020. Since then, he has added routine updates that have added value without shifting its focus.

One of the biggest reasons to use this plugin is that it is a standalone project. It is purely about doing one thing and doing it well. Its settings are all about giving users complete control over how they want to manage block visibility. From my experience with it, the plugin does its job better than alternatives.

It may not have a large number of installs, but if its five-star rating on WordPress.org is any indication, it at least has a happy user base.

Diego does have plans for a pro add-on. The tentative release date is set for Spring 2021. He seems to be moving forward with that launch after adding some foundational code in the recent version 1.4 release.

“As Block Visibility grows, there will be advanced and/or niche functionality that will be useful for certain users,” wrote Diego in the 1.4 release announcement. “Think integrations with other third-party plugins. There will always be a free version of the plugin but some of these additional features will ultimately be provided by a premium (paid) add-on called Block Visibility Pro.”

In my previous job, one of my primary products focused on membership solutions. There is a seemingly endless number of possibilities that users dream up to control content visibility. I have little doubt that a pro add-on is necessary for catching all of the edge cases.

How the Plugin Works

Block Visibility is easy to use. End-users click a toggle switch, select from a date-picker, or tick a radio box. Their blocks are shown or hidden on the front end based on their selections. It does not get much simpler than that.

The plugin adds a new “Visibility” tab for each block, which displays the visibility controls. The exception to this is for inner blocks. For example, the Columns block has controls, but the inner Column blocks do not. However, this can be enabled for inner blocks via the “Full Control Mode” on the plugin’s settings screen.

There are three primary types of options:

  • Hide the block from everyone.
  • Time-based start and stop dates for displaying.
  • Visibility by user role.
Block Visibility’s controls in the inspector.

Hiding the block from everyone might be useful for users who are testing on a page or for blocks that are a work in progress. Start and stop dates create the potential for drip or trial content on membership-based sites, especially when combined with the role-based visibility options.

These basic options will cover the majority of scenarios that the average user will need them for.

One of the nicer features of the plugin is that it adds a transparent gray overlay, dashed border, and icon to each block that has visibility options set. This is shown when the block is not selected in the editor. It is one of those small touches that make the plugin useful.

Overlay for blocks with visibility options.

There is one confusing piece of the UI. There are two instances where there is a “public” option. That label immediately makes me think that the block should be visible to everyone. However, reading the description is necessary. These options are for showing content to logged-out users only. I would rather see these two options renamed to “logged out” for clarity.

A Promising Future

While Block Visibility is a solid plugin right now, we are barely scratching the surface of what will be possible in the long run. In version 1.4, released two weeks ago, Diego added preliminary compatibility with Full Site Editing. This means visibility options will no longer be confined to the post or page content.

“Once every piece of content on a website is a ‘block,’ you will be able to easily control the visibility of practically anything on a WordPress website,” wrote Diego in the version 1.4 announcement post. “From dynamic navigation menus to user specific headers and footers, the possibilities are endless!”

Gutenberg’s site editor is a beta feature right now, but the plugin’s integration seems to already work well. I ran a quick test to show a custom nav menu to shop customers only. I had no problems on my end.

Setting visibility options for a menu in Gutenberg’s site editor.

Users will not be limited to such basic needs in the future. Imagine showing ads in a sidebar to logged-out users. Imagine adding a time-sensitive holiday sale banner in the header. Imagine designing a homepage template that displays different content to subscribers vs. visitors.

There are ways to do all of this today by piecing various plugins together, using custom shortcodes, or writing code. However, when an entire site is made of blocks, you only need one method to control anything’s visibility. Literally.

Golems GABB: Drupal and Flutter: native mobile app experiences for your audience

Main Drupal Feed - Thu, 01/14/2021 - 21:41
Drupal and Flutter: native mobile app experiences for your audience Editor Thu, 01/14/2021 - 23:41 Drupal and Flutter: adding native mobile app experiences to Drupal

Even if your Drupal website is doing great, its audience engagement and user experiences can always reach new heights — the heights at which you can almost hear the fluttering of the wings!

It’s the Flutter framework that will be the main topic of this blog post from the Golems Drupal team. We will discuss what Flutter is, how it works, what benefits and features make it the solution of choice for more and more developers, and how Drupal and Flutter are combined for creating native mobile app experiences.

What is Flutter? Brief introduction and overview of benefits

Flutter is a free and open-source cross-platform UI toolkit or framework that helps developers quickly and easily build beautiful apps for mobile, web, and desktop. The applications are natively compiled from a single codebase.

Community Working Group posts: A Change to the CWG and a Call for New Members

Main Drupal Feed - Thu, 01/14/2021 - 20:27

Serving on the Drupal Community Working Group has been one of the most fulfilling experiences of my career in open source. Since 2013, I’ve had both the honor and the privilege to work alongside some of the most thoughtful, patient, and devoted members of our community to help develop processes and structures for community governance, resolve conflicts, and help make the Drupal project and community a more friendly and welcoming place for everyone. That work has at times been challenging, but it has also provided many opportunities for learning and growth.

All good things must come to an end, however, and as announced at DrupalCon Europe last month, I’ve been working with the other members of the CWG over the last year on a plan to step down from my current position on the Conflict Resolution Team and make way for fresh talent and leadership. 

As our Code of Conduct states, “When somebody leaves or disengages from the project, in whole or in part, we ask that they do so in a way that minimizes disruption to the project. This means they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off.”

In my case, this means that while I will no longer be one of the people responsible for fielding incident reports or acting as a facilitator to help community members resolve conflicts, I will continue to be available to the current members of the team on an as-needed basis to help provide background and context for past issues. I will also continue to serve as a member of the CWG’s Community Health Team, working on projects to proactively improve community health, such as updating our Community Code of Conduct. I also plan to spend more time advocating within the broader open source community for improved community management structures and processes.

With this transition comes an opening within the Conflict Resolution Team, who is currently engaged in a search for new members, which is being led by Tara King (sparklingrobots). You can learn more about the kinds of folks we are looking for in our last call for members from 2018; additionally, all members are expected to abide by the CWG’s Code of Ethics.  

As per the CWG's charter, new members of the CWG’s Conflict Resolution Team are appointed to up to two 3-year terms by the group’s Review Panel, which consists of the two community-elected Drupal Association board members, plus an independent representative appointed by the board as a whole.

If you are interested in being considered, please reach out to Tara or email drupal-cwg@drupal.org. In addition to the openings on the Conflict Resolution Team, we are looking to fill several roles on our Community Health Team for people looking to help make a positive difference in our community.

In closing, I want to thank all of my past colleagues on the CWG: Donna, Angie, Roel, Adam, Mike, Emma, Rachel, Jordana, and Alex, as well as the countless community members who have helped us out in various ways over the years. Drupal is better because of you and your contributions.

Chapter Three: The Best Part Is No Part

Main Drupal Feed - Thu, 01/14/2021 - 18:06

I once sat on a mountain and deeply contemplated the mysteries of Drupal development. Actually, I live on a mountain, so I do this every day, and the title of this post isn't a Zen revelation, I stole that from Elon Musk.

I'm not trying to build rockets and send humans to Mars, and I don't want to draw too many parallels between what I do and the complexity of that enterprise, but we do solve some complex problems of critical importance to our clients. Every efficiency we can gain improves outcomes.

Bounteous.com: Acquia Site Studio: Why You May Need It for Your Next Drupal Project

Main Drupal Feed - Thu, 01/14/2021 - 15:33
Explore a brief tour of Acquia Site Studio and learn why it could be a solid fit for your next project.

Sooper Drupal Themes: Drupal Browser Support Community Survey Results

Main Drupal Feed - Thu, 01/14/2021 - 11:38
What browsers are Drupal sites tested on in 2021?

Internet Explorer is still relevant to a minority of respondents. Unfortunately for DXPR, this number was three times higher in the separate survey that we sent to our clients. Internet Explorer was not only relevant to 60% of our clients... it was relevant to all our "Enterprise" clients which means we cannot drop IE in QA testing our Drupal Layout Builder, even in 2021. 

Safari is becoming less relevant, with 1 out of 4 respondents giving a pass on QA testing in this browser. Edge is still at 75%, but with Edge being based on Chromium I wouldn't be surprised if this number will be lower next year unless they start developing a lot of new features that are not found in Chrome.

What devices are Drupal sites tested on in 2021?

Desktop is still number one but there is only one respondent who does not test on mobile. I wonder if there is a future where Desktop will become less relevant than other device types for Drupal "applications". Maybe the question should be "when" and not "if".

What version(s) of Drupal are we using in 2021?

No surprise that Drupal 9 has the highest score, because all new projects should be starting on Drupal 9. the majority of Drupal sites currently online runs Drupal 7, according to data that depends on the "update module" being turned on, so it's no surprise to see that over half of the respondents are still working on Drupal 7 in 2021.

The same data I linked above, together with the data from this survey, suggests that the upgrade from Drupal 8 to 9 is not really as trivial as advertised.

Bonus question: What Drupal hosting platforms are you working with, in 2021?

It's no surprise to me that Pantheon.io is the most popular choice here, and I'm also happy to see they are getting more competition. Amazee.io with their Lagoon platform is a (relative) newcomer to the Drupal platforms market and they are getting traction.

I had not heard about OpenShift before. Apparently, it's an on-premise cloud platform. An interesting concept considering increased pressure on data security and end-user privacy. 

Who filled out this survey?

This survey was mostly filled out by agency-side Drupal professionals. 14% of respondents are client-side, i.e. working at a company that uses Drupal. 

Thank you

Thank you for helping us and our readers make better decisions about what Drupal environments to support!

Liip: Celebrate Drupal's 20th birthday with rokka

Main Drupal Feed - Wed, 01/13/2021 - 23:00

Put Drupal glasses or masks on any image using the rokka.io image service:
https://rokka-fun.liip.to/drupal

Make sure to share using twitter using the #CelebrateDrupal hashtag.

Thanks to Christian Stocker for swiftly implementing the idea on rokka.io and Nico Grienauer for providing the gimmicks.

WPTavern: WordPress Proposal To Align Release Cycle With Industry Standard

Wordpress Planet - Wed, 01/13/2021 - 21:52

Yesterday, Francesca Marano opened a proposal for changing the phases of the core WordPress release cycle. It was a recap of a discussion the began in October 2020. The goal is to align the platform’s phases with the larger development industry standard.

Aside from naming, WordPress has mostly followed the software industry in how it tackles its release cycle. Following a well-known convention can make it easier for developers outside of the WordPress ecosystem to transition into it. It would also allow developers to follow cycles of other projects, many of which are WordPress dependencies. This sort of standardization is generally viewed as a good thing throughout the software development world.

Based on the ongoing discussions since October, there is a consensus on renaming the phases to align with the standard. The following table shows what each phase would be renamed to:

PhaseCurrent NameProposed Name1Planning and securing team leadsPreliminary Planning2Development work beginsAlpha3BetaBeta4Release candidateRelease Candidate5LaunchGeneral release

However, this is a two-part proposal. Simply renaming the phases does not change how the release cycle works. To follow the standard strictly, WordPress would need to change when code is committed too.

How To Handle the Beta Phase

There is one point of contention with how to handle the Beta stage. The standard calls for no additional code changes other than new bug fixes introduced earlier in the cycle. For the WordPress project, this creates a problem.

WordPress will be 18 years old this year. Over the years, it has racked up a ton of older bugs. These are often fixed later in the cycle, sometimes during the Beta stage. These older bugs may not have been a part of the Preliminary Planning phase, but does that mean they should wait until the next release to go in? Strictly following the proposal, they should be put on hold.

It would also introduce a hard freeze on any enhancements set for the release but incomplete.

“I worry that we aren’t allowing space for older bugs that aren’t specific to the planned features in the release,” wrote Josepha Haden in a comment on the initial discussion. “I also worry that by calling hard freeze earlier in the process we narrow the window for feature inclusion too much. I don’t like limiting ourselves to feature specific bugs right now, since that excludes so many of our volunteer contributors. It’s harder to work on features since they are complex and fast-moving, and older bugs present more opportunities for casual contributors.”

On the flip side, there is potential that a bug fix could introduce new, unforeseen bugs. The later it is added during Beta, the less likely such bugs are noticed before the General Release phase. Waiting for the next cycle provides more time for testing.

One of the benefits of this system is that almost no new bugs would be created during Beta. This would allow volunteers to shift more efforts to testing and fixing issues that emerged in Alpha.

WordPress has always marched to the beat of its own drum. It can more closely follow standards while breaking free from strict confines when it makes sense to do so for the project. Beta-stage bug fixes not intended for a particular release could be handled on a case-by-case basis. We have people in leadership positions who are capable of making these calls when they arise. With automatic updates for minor releases, I am less concerned about late-stage bugs.

Tonya Mork proposed two solutions for defect work to continue in and around the release cycle. Both would require that WordPress branch off at Beta, providing contributors an avenue to push forward fixing bugs.

The first proposal calls for an earlier feature freeze, providing two or three weeks before Beta 1. This period at the end of the Alpha phase would be solely dedicated to defect work.

The second solution moves this defect work to overlap the previous release’s Beta and Release Candidate. This allows work to continue during the time between major releases. It could also shorten the overall major release cycle.

This second solution is also consistent with Joost de Valk’s thoughts on handling defect work. “I think we should just branch off earlier, and keep trunk open for normal business,” he said on the proposal. “That way, everything can be worked on all the time, but it won’t be included in the next release depending on when you commit it. That’s fine, every piece of open source software I know in the world works like that, except for WordPress.”

Many plugin and theme developers already find it tough to keep up when changes drop in the Beta or Release Candidate phases. Having a clear and defined point where changes land will benefit the extension ecosystem, also helping end-users in the long run. This second solution would do that.

There is nothing wrong with combining both solutions either. Since the plan would be to branch off at the Beta phase, the second solution is already in place by the act of branching. The real discussion is over whether the project should dedicate a block of time during its Alpha stage that focuses purely on bug fixes.

Comments on the proposal are open through January 20 before moving toward a final decision.

The next proposal: semantic versioning, anyone? Anyone? Is this thing on?

WPTavern: WPScan Can Now Assign CVE Numbers for WordPress Core, Plugin, and Theme Vulnerabilities

Wordpress Planet - Wed, 01/13/2021 - 20:52

WPScan, a security company that maintains a database of WordPress vulnerabilities, has been officially designated as a CVE (Common Vulnerability and Exposures) Numbering Authority (CNA). The company joins 151 organizations from 25 countries that participate in the CVE Program as CNAs. These organizations are authorized to assign CVE Identifiers (CVE IDs) to vulnerabilities within their own distinct scopes of work, contributing to CVE’s list of records for publicly known security vulnerabilities.

WPScan’s scope includes WordPress core, plugin, and theme vulnerabilities. The company has catalogued more than 21,905 vulnerabilities since 2014 in its database, which it makes available to the community through an API. That API is also used by the WPScan Security Scanner plugin, which is installed on 5,000+ websites.

Being designated as a CNA helps WPScan better manage WordPress vulnerabilities by assigning them unique IDs that are recognized across the industry.

“Asking MITRE to assign CVEs for each of our vulnerabilities would have been too time consuming in the past,” WPScan founder and CEO Ryan Dewhurst said. “Although some security researchers will go through this process directly with MITRE, we didn’t due to the volume of vulnerabilities we have to manage. And security researchers only requested them themselves very rarely. The new process means that we ourselves can assign CVE numbers directly to vulnerabilities. This will result in many more WordPress related vulnerabilities being assigned CVE numbers.”

WPScan is a team of three security researchers who come from penetration testing backgrounds and have worked within security consulting for the past 10 to 15 years. The company started with a simple Ruby script in 2011, which identified vulnerabilities in self-hosted WordPress sites. For the past two years, Automattic has sponsored the company’s efforts in maintaining the database, as WPScan has transitioned to become a sustainable business by selling access to its API.

Dewhurst said the company’s customers include “some of the biggest security plugins and hosting companies in the world,” but many of them don’t advertise the fact that use a third-party to source the vulnerabilities. Most of WPScan’s enterprise customers are security plugins, companies, and hosts that integrate data from the vulnerability database into their own products and services.

“Our business is doing well,” he said. “Right now we are trying to find the right balance between being a business and making money, while also benefiting the community as much as possible.”

Mediacurrent: Can I See the Menu, Please? Building and Integrating a Menu in Drupal

Main Drupal Feed - Wed, 01/13/2021 - 19:51

By nature, menus are complicated. They’re not easy to work with, build, or style, and yet they are probably the single most important navigation element of any website. Despite their complication, they need to be perfect to serve their purpose. A menu can make or break a website. They can make your browsing experience a pleasant one, or can drive you to leave a website frustrated and likely never to return.

When it comes to menus and forms, it is best to let Drupal dictate the direction rather than build them independently of Drupal. By adhering to Drupal’s best practices we can save a lot of time, effort, and frustration. For example, rather than writing your menu’s markup before you see it being printed by Drupal, it is best to build your menu in Drupal and see what the markup looks like. Then you can use Drupal’s markup as a starting point for writing your menu’s markup. 

This is going to be a lengthy post (mostly because it includes a lot of code snippets), but this article will cover all you need to accomplish the following:

 Editor's note: This blog was originally published on June 3, 2019, and has been updated to include two new tutorial videos. They can be found at the end of the post. 

Build a Multi-Level Menu Component in Pattern Lab

For the purpose of keeping the content clean, I'll be linking to code snippets from Github Gists.

Let’s start by building a pretty straight forward multi-level menu component in Pattern Lab. If you’ve used Pattern Lab or KSS Node you know most components require at least three files: 

  • .twig for the component markup and logic
  • .yml or json for demo links or content
  • .scss for the menu styles
  • In some cases you may also need a Javascript file

For a more in-depth explanation on building and integrating components read our blog series.  
Note: This series is over three years old and many things have changed since then, but the basics of building a component still apply.

Building the component
  1. In your theme’s components, location create a new directory called navigation
  2. In the navigation directory, create the following three files:
    • navigation.twig
    • navigation.json
    • navigation.scss
  3. Inside navigation.json add the code below:
    Menu data structure
  4. The data above represents an array of items. You may notice some of the links have nested arrays (i.e. below). These represent submenus in the menu tree. The items array above is only intended to simulate the menu’s data for our component. In Drupal, the array will be provided when we add menu links to Drupal’s Main Menu.
  5. Inside navigation.twig add the code below:
    Menu logic and markup
  6. If the code above does not look familiar to you it’s probably because you’ve never used a Twig Macro. I will explain the macro in detail shortly, but for now, let’s move on to completing the component.  I have also recorded a screencast on Twig Macros.
  7. Finally add the following styles in navigation.scss
    Menu CSS styles
Update Drupal’s Menu Macro to Achieve Better Markup

Not having the right markup for the menu, or any other element for that matter can really complicate things for us when it’s time to style. We are going to modify the macro so it matches the markup of the main-menu component, and as a result, the styles we wrote for the component will apply to the Drupal menu.

Menu Macro Explained

Let’s step through this macro line by line to understand what it does. To keep things simple we are going to ignore all the custom classes we added above and focus on the macro itself.

  • Twig macros can be called from other twig templates, and it's also possible to call them from within the same twig template where it was written (as is the case here by using the variable name _self). So, with this import statement, we imported the macro and set it as a variable called menus.
  • Using the menus variable we then assign a name to it (menu_links), which will take the following parameters: items, attributes, and 0). This name can be anything you wish.
  • Now we declare the macro again but this time with its new name, menu_links, and pass the slightly modified parameters items, attributes, menu_level
  • Now that we’ve updated the arguments, we self import the macro again to make use of it 
  • Before writing any markup, we first check whether there are menu items to render
    • If there are items in our main menu we start writing the markup. However, since we may have a multi-level menu, we want to make sure we identify the top level menu from nested (submenus), menus in the tree.  
    • This is where we first check if the menu_level is 0 (zero).
    • If it is the top level menu, we print a <ul> and we pass Drupal’s attributes in addition to our custom classes.
    • If menu is not top level (submenus), then we simply print a <ul> with its corresponding class.

Learn more about Macros in Twig Templates.

Looping Through the Menu Tree

Looping through the items array allows us to intersect each item and apply classes or attributes.

  • First, we loop through the items array (for item in items), and for each item, we print a <li> to which we pass an array of CSS classes using attributes.addClass() method.  However we do this only if we have access to Drupal's attributes ({% if attributes %}).  If not, we manually print the same classes on the list item. 
  • For each item and link, we pass a series of things such as:
    • The link title
    • The link url
    • Is the link in the active trail,
    • ... and others.
  • Inside the list item, we check to see if that particular item has other items or submenus({% if item.below %})
  • When submenus exist, we make use of the macro again to repeat the process of printing the menu. This is where the macro saves us from writing duplicate code.
  • For each level of submenus we are increasing the menu_level by 1 and printing it as part of the submenu class. This is handy if we want to target a specific submenu in the tree.
  • Finally, we close all previously open actions/tags (i.e. for loops, if statements, lists, and macro).

RESOURCE: I recently ran into a blog post by Tamas Hajas where he has a great way to address classes and states on a menu. Check it out: Drupal 8 Twig: add custom CSS classes to menus

Looking at the Rendered Menu after Macro Improvements

Now that we have a better understanding on how the macro works, and after making the improvements discussed above, the markup for the menu would look something like this:

 

These styles are as bare as possible. They are simply to make the menu look presentable and could use a lot of improvements. This is what the multi-level menu looks like:

 

Create a Twig Template Suggestion for the Main Menu

Our ultimate goal is to update Drupal’s menu system to render using the navigation component. 

Follow these steps to enable Twig Debugging in your theme. Then, you can inspect your site, which will allow you to see the various template suggestions that Drupal uses to render the page; including your navigation menu. The debug information looks like this:

Under File Name Suggestions notice two template names: menu.html.twig & menu--main.html.twig. The X next to menu.html.twig indicates Drupal is using this file to render the Main Menu. The second file, menu--main.html.twig, is what Drupal is suggesting we create if we only want to alter the Main navigation and not other menus.  The word "main" in the file name represents the Drupal machine name for that menu.

Under Begin Output notice the path where menu.html.twig can be found, the example above is pointing to Drupal’s stable theme.

To ensure we only affect the main menu and not other menus on our site, we are going to make a copy of Drupal’s menu.html.twig in our theme and then override it. This is recommended rather than modifying Drupal core’s template. Let’s start:

  1. Copy the menu.html.twig template from core/themes/stable/templates/navigation/ into [site_root]/themes/custom/<your-theme>/templates/navigation/menu.html.twig (if these folders do not exist yet in your theme go ahead and create them).
  2. Following the golden rule “Never hack core”, we want to make a copy of Drupal’s menu template in our own theme. Replace the core theme’s name with your core base theme if you are not using stable.
  3. Next, In your theme rename the newly copied template to menu--main.html.twig.
    Copying menu.html.twig into our theme will affect other menus. This is why we are renaming the template so it only affects the main menu (menu--main.html.twig). Replace ‘main’ with whatever your menu’s machine name is if you are not using Drupal’s Main Menu. This can be found in Drupal’s Menus page (admin/structure/menus).
  4. After clearing Drupal’s cache, inspect the menu again and you should see the X next to menu--main.html.twig which means Drupal is now using our custom twig template suggestion to render the menu.
Create a Multi-level Menu in Drupal
  • Let’s make sure we have a menu we can see in Drupal. Let’s create a multi-level menu using the Main Navigation menu (Structure | Menus | Main Navigation).
  • Add as many links as you wish. Be sure to add nested items so we end up with a multi-level menu.
  • In addition, ensure each of the submenu’s parent links are set to “show expanded”. You will see the option on the Add/Edit Link page.
  • Finally, go to Structure | Block Layout and click Configure next to Main Navigation
    • Change Number of levels to display to Unlimited. This will ensure dropdowns are rendered and display in your navigation.
Integrate the Main Menu component with Drupal’s Menu

The last part of the process is to integrate all the work we’ve done with Drupal, so our Navigation is rendered with the markup, styles, and behavior we implemented when we built the component.  

  1. In your editor, open [site_root]/themes/custom/<your-theme>/templates/navigation/menu--main.html.twig
  2. Delete all the content in the twig template except for the comments, and then paste the code below into it
{% include '@your-namespace-here/navigation/navigation.twig' %}
  1. Clear Drupal’s cache
  2. Reload Drupal’s page

Since we moved the macro to the component’s location, all we need to do in the menu--main.html.twig template is to call our Navigation component by using a Twig include statement. 

If we did our job right, Drupal’s menu should now look and behave the same way as our component. In addition, if you inspect the Drupal page, the menu should reflect the same markup as the main-menu component.

Drupal Libraries

As a best practice, we should create a drupal library to attach any styles and javascript to our component. See this article for adding CSS and JS to a page or component.

If your navigation is displaying unstyled that's because a Drupal library does not exist.  Create one as follows:

  • Inside /themes/custom/<your-theme>/your-theme.libraries.yml add the following code

navigation: css: component: dist/css/navigation.css: {}

Your compiled css path may be different.

This library has already been attached above inside navigation.twig

By doing this any styles we wrote for the component will apply to the main navigation when it’s rendered in Drupal. Drupal libraries have no effect in Pattern Lab.

After completing the steps above, clear your Drupal’s cache and reload your Drupal site. You should see your Drupal menu being rendered with all the styles and markup we wrote throughout this post,

What about Accessibility?

You should always ensure your menus and navigations are accessible. It is the right thing to do. However, don't yell at me for not following my own advice. In an effort to keeping this tutorial simple, I opted to omit anything related to accessibility. Perhaps part two can focus on that ;-)

Video Tutorials


In Closing

I’d like to admit that I went about the long way to get the main menu working on both, Pattern Lab and Drupal. There are other ways to accomplish this by using contrib modules such as Simplify Menu (full disclosure, I am a co-maintainer of the module), and perhaps Twig Tweak among several others, however, the approach I took here gives you the most control and that can make all the difference if you are dealing with a pretty advanced or complicated menu.

Pages