Development News

Agiledrop.com Blog: Interview with Adam Bergstein, aka Nerdstein: Should Drupal 8 core development slow down?

Main Drupal Feed - Mon, 11/12/2018 - 14:10

Adam Bergstein is the maintainer of SimplyTest.me, runs the Drupal Coffee Exchange and participates in the Governance Task Force that just released its community proposal. Learn how Adam, aka Nerdstein, feels about Drupal 8 core development.

READ MORE

Dries Buytaert: Why Drupal's Layout Builder is so powerful and unique

Main Drupal Feed - Mon, 11/12/2018 - 12:02

Content authors want an easy-to-use page building experience; they want to create and design pages using drag-and-drop and WYSIWYG tools. For over a year the Drupal community has been working on a new Layout Builder, which is designed to bring this page building capability into Drupal core.

Drupal's upcoming Layout Builder is unique in offering a single, powerful visual design tool for the following three use cases:

  1. 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).
  2. 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)
  3. 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).

Let's look at all three use cases in more detail to explain why we think this is extremely useful!

Use case 1: Layouts for templated content

For large sites with significant amounts of content it is important that the same types of content have a similar appearance.

A commerce site selling hundreds of different gift baskets with flower arrangements should have a similar layout for all gift baskets. For customers, this provides a consistent experience when browsing the gift baskets, making them easier to compare. For content authors, the templated approach means they don't have to worry about the appearance and layout of each new gift basket they enter on the site. They can be sure that once they have entered the price, description, and uploaded an image of the item, it will look good to the end user and similar to all other gift baskets on the site.

Drupal 8's new Layout Builder allows a site creator to visually create a layout template that will be used for each item of the same content type (e.g. a "gift basket layout" for the "gift basket" content type). This is possible because the Layout Builder benefits from Drupal's powerful "structured content" capabilities.

Many of Drupal's competitors don't allow such a templated approach to be designed in the browser. Their browser-based page builders only allow you to create a design for an individual page. When you want to create a layout that applies to all pages of a specific content type, it is usually not possible without a developer.

Use case 2: Customizations to templated layouts

While having a uniform look for all products of a particular type has many advantages, sometimes you may want to display one or more products in a slightly (or dramatically) different way.

Perhaps a customer recorded a video of giving their loved one one of the gift baskets, and that video has recently gone viral (because somehow it involved a puppy). If you only want to update one of the gift baskets with a video, it may not make sense to add an optional "highlighted video" field to all gift baskets.

Drupal 8's Layout Builder offers the ability to customize templated layouts on a case per case basis. In the "viral, puppy, gift basket" video example, this would allow a content creator to rearrange the layout for just that one gift basket, and put the viral video directly below the product image. In addition, the Layout Builder would allow the site to revert the layout to match all other gift baskets once the world has moved on to the next puppy video.

Since most content management systems don't allow you to visually design a layout pattern for certain types of structured content, they of course can't allow for this type of customization.

Use case 3: Custom pages (with unstructured content)

Of course, not everything is templated, and content authors often need to create one-off pages like an "About us" page or the website's homepage.

In addition to visually designing layout templates for different types of content, Drupal 8's Layout Builder can also be used to create these dynamic one-off custom pages. A content author can start with a blank page, design a layout, and start adding blocks. These blocks can contain videos, maps, text, a hero image, or custom-built widgets (e.g. a Drupal View showing a list of the ten most popular gift baskets). Blocks can expose configuration options to the content author. For instance, a hero block with an image and text may offer a setting to align the text left, right, or center. These settings can be configured directly from a sidebar.

In many other systems content authors are able to use drag-and-drop WYSIWYG tools to design these one-off pages. This type of tool is used in many projects and services such as Squarespace and the new Gutenberg Editor for WordPress (now available for Drupal, too!).

On large sites, the free-form page creation is almost certainly going to be a scalability, maintenance and governance challenge.

For smaller sites where there may not be many pages or content authors, these dynamic free-form page builders may work well, and the unrestricted creative freedom they provide might be very compelling. However, on larger sites, when you have hundreds of pages or dozens of content creators, a templated approach is going to be preferred.

When will Drupal's new Layout Builder be ready?

Drupal 8's Layout Builder is still a beta level experimental module, with 25 known open issues to be addressed prior to becoming stable. We're on track to complete this in time for Drupal 8.7's release in May 2019. If you are interested in increasing the likelihood of that, you can find out how to help on the Layout Initiative homepage.

An important note on accessibility

Accessibility is one of Drupal's core tenets, and building software that everyone can use is part of our core values and principles. A key part of bringing Layout Builder functionality to a "stable" state for production use will be ensuring that it passes our accessibility gate (Level AA conformance with WCAG and ATAG). This holds for both the authoring tool itself, as well as the markup that it generates. We take our commitment to accessibility seriously.

Impact on contributed modules and existing sites

Currently there a few methods in the Drupal module ecosystem for creating templated layouts and landing pages, including the Panels and Panelizer combination. We are currently working on a migration path for Panels/Panelizer to the Layout Builder.

The Paragraphs module currently can be used to solve several kinds of content authoring use-cases, including the creation of custom landing pages. It is still being determined how Paragraphs will work with the Layout Builder and/or if the Layout Builder will be used to control the layout of Paragraphs.

Conclusion

Drupal's upcoming Layout Builder is unique in that it supports multiple different use cases; from templated layouts that can be applied to dozens or hundreds of pieces of structured content, to designing custom one-off pages with unstructured content. The Layout Builder is even more powerful when used in conjunction with Drupal's other out-of-the-box features such as revisioning, content moderation, and translations, but that is a topic for a future blog post.

Special thanks to Ted Bowman (Acquia) for co-authoring this post. Also thanks to Wim Leers (Acquia), Angie Byron (Acquia), Alex Bronstein (Acquia), Jeff Beeman (Acquia) and Tim Plunkett (Acquia) for their feedback during the writing process.

DrupalBASE: Creating visualization styles

Main Drupal Feed - Mon, 11/12/2018 - 10:55

Visualization styles are configuration entities that store a reference to a drawer plugin (its Id) and a set of configuration defaults. These styles are used to create drawings. As VisualN defines it, a drawing is a ready, self-contained piece of markup (or render array) with possibly styles and scripts attached. Almost anything can be a drawing: a chart, an image gallery or even a web app.

In a sense, they are similar to image styles which are applied to an original image in order to get a styled one. In the case of visualization styles, they are applied to sets of data to get a drawing as a result. Though some drawers don't even need data to create a drawing.

Visualization styles can be created either using Available drawers preview UI or directly using VisualN > Visualization Styles administration page. Once created, they can be used anywhere on the site to create drawings: views, fields, blocks, embedded into content via ckeditor, tokens etc. Multiple styles can be created for the same drawer.

On the screenshot below a style is created for the Linechart Basic drawer provided with VisualN module.

To create a visualization style, its label must be set and drawer plugin selected. If selected drawer plugin configuration form provides required fields, those must be set up too.

Code Karate: Drupal 8 Image Widget Crop Module

Main Drupal Feed - Sat, 11/10/2018 - 15:46
Episode Number: 216

The Drupal 8 Image Widget Crop Module is a handy module for allowing your content editors on your website to crop images after they upload them. Have you ever uploaded an image on a website and had it automatically crop the image for you in a way that just looks wrong? This module solves that problem!

Tags: DrupalContribDrupal 8Image HandlingSite BuildingDrupal Planet

WPTavern: Matt Mullenweg Addresses Controversies Surrounding Gutenberg at WordCamp Portland Q&A

Wordpress Planet - Sat, 11/10/2018 - 15:30

Matt Mullenweg joined attendees at WordCamp Portland, OR, for a Q&A session last weekend and the recording is now available on WordPress.tv.

The first question came from a user who tried Gutenberg and turned it off because of a plugin conflict. She asked if users will have to use Gutenberg when 5.0 is released. Mullenweg said one of the reasons Gutenberg has been tested so early is to give plugin developers time to get their products compatible. He also said that it has been the fastest growing plugin in WordPress’ history, with more than 600,000 installations since it was first made available.

In response to her question he said users will have the option to use the Classic Editor and that the team is considering updating it to include per-user controls and the possibility to turn it on/off for different post types.

Subsequent questions went deeper into recent controversies surrounding Gutenberg, which Mullenweg addressed more in depth.

“The tough part of any open source project – there’s kind of a crucible of open source development which can sometimes be more adversarial and sometimes even acrimonious,” he said. “Working within the same company, you can kind of assume everyone is rowing in the same direction. In a wide open source ecosystem, some people might actually want the opposite of what you’re doing, because it might be in their own economic self-interest, or for any number of reasons.

“I liken it much more to being a mayor of a city than being a CEO of a company. I’ve done WordPress now for 15 years so I’m pretty used to it. It might seem kind of controversial if you’re just coming in, but this is not the most controversial thing we have ever brought into WordPress. The last time we had a big fork of WordPress was actually when we brought in WYSIWYG the first time. Maybe there’s something about messing with the editor that sets people off.”

Mullenweg commented on how polarizing Twitter can be as a medium and how that can impact conversations in negatives ways. He said people tend to read the worst into things that have been said and that has been a new challenge during this particular time in WordPress’ history. WordPress tweets are sprinkled into timelines along with politics and current events in a way that can cause people to react differently than if the discussion was held in a trac ticket, for example.

One attendee asked, “With Gutenberg there’s a lot of uncertainty. Where do you see the tipping point where you see people become more favorable to Gutenberg than the Classic Editor?”

“Part of getting these two plugins, Gutenberg and Classic Editor, out early, was that it could remove uncertainty for people,” Mullenweg said. “Months before they were released you could kind of choose your path. The hope is that the 5.0 release day is the most anti-climactic thing ever. Because we have over a million sites that have either chosen to not use Gutenberg, which is totally ok, or have already opted in and have been getting these sometimes weekly updates. We have hosts that have been actually been pre-installing, pre-activating Gutenberg with all of their sites.”

Mullenweg said hosts that have pre-installed Gutenberg have not reported a higher than normal support load and that it has basically been “a non-event.” It’s the users who are updating to 5.0 after many years of using WordPress who will have the most to learn.

“Gutenberg does by some measures five or ten measures more than what you could really accomplish in the classic editor,” Mullenweg said. “That also means there’s more buttons, there’s more blocks. That is part of the idea – to open up people’s flexibility and creativity to do things they would either need code or a crazy theme to do in the past. And now we’re going to open that up to do WordPress’ mission, which is to democratize publishing and make it accessible to everyone.”

Gutenberg’s current state of accessibility has been a hot topic lately and one attendee asked for his thoughts about the recent discussions. Mullenweg said there is room for improvement in how this aspect of the project was handled and that WordPress can work better across teams in the future:

Accessibility has been core to WordPress from the very beginning. It’s part of why we started – adoption of web standards and accessibility things. We’ve been a member of the web standards project for many many years. We did kind of have some project management fails in this process where we had a team of volunteers that felt like they were disconnected from the rapid development that was happening with Gutenberg. Definitely there were some things we could do better there. In the future I think that we need – I don’t know if it makes sense to have separate accessibility as a separate kind of process from the core development. It really needs to be integrated at every single stage. We did do a lot, as Matias did a big long post on it. We’ve done a ton of keyboard accessibility stuff, there’s ARIA elements on everything. One of their feedbacks was that we did it wrong, but we did it the best that we knew how to and it’s been in there for awhile. There’s been over 200 closed issues from really the very beginning. We also took the opportunity to fix some things that had been poorly accessible in WordPress from the beginning. It’s not that WordPress is perfectly accessible and all WCAG AA and it’s reverting. It’s actually that huge swaths of WP are inaccessible – they just might not be considered core paths from the current accessibility team but I consider them core.

In response to a question about the future of React in WordPress, Mullenweg went more in depth on the vision he had when he urged the WordPress community to learn JavaScript deeply in 2015. At that time he said “it is the future of the web.” He described how each block can be a launching point for something else – via a modal, such as updating settings, doing advanced things with an e-commerce store, zooming in and out of those screens from the editor. This was perhaps the most inspirational part of the Q&A where the potential of Gutenberg shines as bright as it did in the early demos.

“The other beautiful thing is that because Gutenberg essentially allows for translation into many different formats,” Mullenweg said. “It can publish to your web page, your RSS feed, AMP, blocks can be translated into email for newsletters, there’s so much that the structured nature of Gutenberg and the semantic HTML it creates and the grammar that’s used to parse it, can enable for other applications. It becomes a little bit like a lingua franca that perhaps even crosses CMS’s. There’s now these new cross-CMS Gutenberg blocks will be possible. It’s not just WordPress anymore. It may be a JavaScript block that was written for Drupal that you install on your WordPress site. I mean, hot diggity! How would that have ever happened before? That’s why we took two years off; it’s why we’ve had everyone in the world working on this thing.”

JavaScript is what makes this cross-platform collaboration possible and it’s already evident in the work the Drupal Gutenberg contributors are doing, as well as the platform-agnostic Gutenberg Cloud project. When Gutenberg is released in 5.0, it will enable more for WordPress and the web than we can predict right now.

“This is not the finish line,” Mullenweg said. “5.0 is almost like the starting point. Expect just as much time invested into Gutenberg after the 5.0 release as before – to get it to that place where we don’t think it’s just better than what we have today but it’s actually like a world-class web-defining experience, which is what we want to create and what you all deserve.”

Code Karate: Drupal 8 Contact Storage Export Module

Main Drupal Feed - Fri, 11/09/2018 - 21:49
Episode Number: 215

In this episode, we cover the Drupal 8 Contact Storage Export Module. This episode covers a module that adds additional functionality to the Contact Storage Module (which we covered in episode 213). This module allows you to export your contact form submissions to a CSV file. It's a simple module that serves a very specific purpose. If you need to export your contact form submissions, this is how you do it!

Tags: DrupalContribDrupal 8Site BuildingDrupal Planet

WPTavern: WordPress 5.0 Release Date Update to November 27

Wordpress Planet - Fri, 11/09/2018 - 20:06

The WordPress 5.0 release date has been pushed back to November 27. The previous schedule outlined the possibility of a slip date where the first target date could slip by up to eight days if necessary.

“As discussed during the Core devchat this week, the initial November 19th target date is looking a bit too soon for a release date,” Gutenberg technical lead Matias Ventura said in today’s announcement on the make.wordpress.org/core blog. “After listening to a lot of feedback — as well as looking at current issues, ongoing pull requests, and general progress — we’re going to take an extra week to make sure everything is fully dialed in and the release date is now targeted for November 27th.”

Ventura outlined a new plan where beta 4 and beta 5 releases will coincide with Gutenberg 4.3 and 4.4 releases. RC1 is expected to be released November 19. He said contributors will be posting daily high level updates on the current status of the release, including things like open pull requests to be reviewed and outstanding bugs, to the #core-editor channel.

The announcement also includes a short video demonstration of Gutenberg fully integrated with the new default Twenty Nineteen theme.

Given the recent pushback on the timeline from prominent WordPress developers and business owners, the updated November 27 timeline may still not offer enough time to resolve the issues remaining and allow the ecosystem to prepare training materials that accurately reflect late stage UI changes.

At a spontaneous Q&A session at WordCamp Portland this weekend, Matt Mullenweg said WordPress 5.0 was branched from 4.9.8 so this release has been tightly wound to the previous one to allow for a more seamless transition.

The next targeted release day falls on the Tuesday after Cyber Monday, which should be a relief to anyone running a WordPress-powered e-commerce site. If WordPress misses the updated November 27 release date, it will be pushed back to the secondary target date of January 22, 2019.

Drupal blog: The end of PHP 5

Main Drupal Feed - Fri, 11/09/2018 - 17:28

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

If you are still using PHP 5, now is the time to upgrade to a newer version of PHP.

PHP, the Open Source scripting language, is used by nearly 80 percent of the world's websites.

According to W3Techs, around 61 percent of all websites on the internet still use PHP 5, a version of PHP that was first released fourteen years ago.

Now is the time to give PHP 5 some attention. In less than two months, on December 31st, security support for PHP 5 will officially cease. (Note: Some Linux distributions, such as Debian Long Term Support distributions, will still try to backport security fixes.)

If you haven't already, now is the time to make sure your site is running an updated and supported version of PHP.

Beyond security considerations, sites that are running on older versions of PHP are missing out on the significant performance improvements that come with the newer versions.

Drupal and PHP 5 Drupal 8

Drupal 8 will drop support for PHP 5 on March 6, 2019. We recommend updating to at least PHP 7.1 if possible, and ideally PHP 7.2, which is supported as of Drupal 8.5 (which was released March, 2018). Drupal 8.7 (to be released in May, 2019) will support PHP 7.3, and we may backport PHP 7.3 support to Drupal 8.6 in the coming months as well.

Drupal 7

Drupal 7 will drop support for older versions of PHP 5 on December 31st, but will continue to support PHP 5.6 as long there are one or more third-party organizations providing reliable, extended security support for PHP 5.

Earlier today, we released Drupal 7.61 which now supports PHP 7.2. This should make upgrades from PHP 5 easier. Drupal 7's support for PHP 7.3 is being worked on but we don't know yet when it will be available.

Thank you!

It's a credit to the PHP community that they have maintained PHP 5 for fourteen years. But that can't go on forever. It's time to move on from PHP 5 and upgrade to a newer version so that we can all innovate faster.

I'd also like to thank the Drupal community — both those contributing to Drupal 7 and Drupal 8 — for keeping Drupal compatible with the newest versions of PHP. That certainly helps make PHP upgrades easier.

WPTavern: WPWeekly Episode 337 – Gutenberg User Experiences, Release Timelines, and the Classic Editor

Wordpress Planet - Fri, 11/09/2018 - 17:21

In this episode, John James Jacoby and I break down what’s happening with Gutenberg. We discuss our trials and tribulations with the editor, the release timeline, and calls from members of the community to delay WordPress 5.0 until January. We also share details on how long the Classic Editor plugin will be supported. Last but not least, we talk about the possible release strategy of shipping point releases every two weeks after WordPress 5.0 is released.

Stories Discussed:

How to Add an Image to A Paragraph Block in Gutenberg

Adding Aligned Images to Paragraphs in Gutenberg Is Not as Tough as I Thought

WordPress 5.0 Beta 3 Released, RC 1 Expected November 12

WordPress 5.0 needs a different timeline   

WordPress 5.0 is Not Ready

Classic Editor Plugin May Be Included with 5.0 Updates, Support Window Set to End in 2021

WPWeekly Meta:

Next Episode: Wednesday, November 14th 3:00 P.M. Eastern

Subscribe to WordPress Weekly via Itunes

Subscribe to WordPress Weekly via RSS

Subscribe to WordPress Weekly via Stitcher Radio

Subscribe to WordPress Weekly via Google Play

Listen To Episode #337:

Agiledrop.com Blog: Top Drupal blog post from October 2018

Main Drupal Feed - Fri, 11/09/2018 - 15:12

We’ve prepared for you an overview of the best Drupal blog post written in the previous month - October 2018. Enjoy.

READ MORE

ComputerMinds.co.uk: Beware File::getFileUri()!

Main Drupal Feed - Fri, 11/09/2018 - 14:06

I'll keep this short and sweet, but we thought this would be a useful tip to share with the world as a potential security issue with the combined use of File::getFileUri() and FileSystem::realpath().

Consider the following code excerpt :

$file = File::load($some_file_uri); if ($file) { $uri = $file->getFileUri(); $file_realpath = \Drupal::service('file_system')->realpath($uri); }

Seems pretty harmless right? Load up the file from $some_file_uri , If we have a valid file then get the URI and then grab the real path.

Wrong (potentially, depending on what you do with $file_realpath).

If $file is a valid file, but for whatever reason the file is no longer physically located on disk, then $file->getFileUri() will return a blank string.

It turns out that passing this blank string $uri into \Drupal::service('file_system')->realpath($uri) will return the full webroot of your site!

Depending on what you were doing with said $file_realpath, it could then be a security issue.

We were handling a user webform submission and then sending the submission over to a CRM system... because $file_realpath was now the webroot of the site, then code that followed to archive the user submitted file ended up archiving the entire webroot and sending this over to the client's CRM system. 

Luckily in this instance, the archive was only ever available temporarily server side and then went directly to the clients own CRM system, but in another circumstance this could have easily been a very serious security issue.

Fortunately the fix is quite simple, ensure the the $uri returned from ->getFileUri() is valid by some method, before passing through realpath(). Here, I now validate the uri matches what I know it should be for the current webform submission.

if ($file) { $uri = $file->getFileUri(); $webform_id = $webform->get('id'); $submission_id = $webform_submission->get('sid')->getValue()[0]['value']; $valid_file_scheme = strpos($uri, 'private://webform/' . $webform_id . '/' . $submission_id . '/') !== FALSE; if ($valid_file_scheme) { // Proceed with the rest of the code.. } }

 

Matt: Gutenberg in Portland Oregon and Podcasts

Wordpress Planet - Fri, 11/09/2018 - 04:45

I’ve had the opportunity to talk about Gutenberg at two great venues recently. The first was at WordCamp Portland which graciously allowed me to join for a Q&A at the end of the event. The questions were great and covered a lot of the latest and greatest about Gutenberg and WordPress 5.0:

Last week I also joined Episode 101 of the WP Builds podcast, where as Nathan put it: “We talk about Gutenberg, why Matt thinks that we need it, and why we need it now. We go on to chat about how it’s divided the WordPress community, especially from the perspective of users with accessibility needs.”

They may be out of seats already, but I’ll be on the other coast to do a small meetup in Portland, Maine this week. As we lead up to release and WordCamp US I’m really enjoying the opportunity to hear from WordPress users of all levels all over the country.

WPTavern: Calls to Delay WordPress 5.0 Increase, Developers Cite Usability Concerns and Numerous Bugs in Gutenberg

Wordpress Planet - Fri, 11/09/2018 - 00:03

Developers and business owners are waiting anxiously in the wings, as Gutenberg is 11 days away from its debut in WordPress 5.0. There is still a chance that the release could be delayed to the secondary date (January 22, 2019), but the decision has not yet been announced.

“I am lukewarm on the 19th, but not because of the number of open issues (which isn’t a good measure or target) — more that we’ve been a day or two behind a few times now,” 5.0 release lead Matt Mullenweg said during yesterday’s dev chat. He said that reports “from the field” continue to be good and companies that have already installed and activated the plugin haven’t reported a higher than normal support burden.

“My concern can be summed up as this,” Aaron Jorbin said. “There are approximately 400 issues that need either code or a decision to punt. Assuming five minutes per issue, that means there are about 33 hours worth of bug scrubs that need to take place between now and RC.”

“I don’t think we can make a decision on moving the date in the next 45 minutes,” Gary Pendergast said in response to concerns raised at the meeting. “I do think it’s fair to say that the Gutenberg and 5.0 leadership teams are hearing all the feedback, and are actively looking whether the timeline is still correct.”

Mullenweg said open issues are not a good measure of whether the release is on target but the numerous bugs the community is encountering has precipitated a flurry of posts advocating for the release to be delayed.

In a post titled “WordPress 5.0 needs a different timeline,” Joost de Valk, author of Yoast SEO, cites accessibility concerns and the stability of the project as reasons for a delay. de Valk identifies himself a strong supporter of Gutenberg and his team has already built compatibility and Gutenberg-first features into their plugin, which has more than 5 million active installs.

“It’s arguably one of the biggest leaps forward in WordPress’ editing experience and its developer experience in this decade,” de Valk said. “It’s also not done yet, and if we keep striving for its planned November 19th release date, we are setting ourselves up for failure.”

de Valk gave two reasons for why he believes the November 19th timeline to be untenable:

There are some severe accessibility concerns. While these aren’t new and a few people are working hard on them, I actually think we can get a better handle on fixing them if we push the release back. Right now it looks to me as though keyboard accessibility has regressed in the last few releases of Gutenberg.

The most important reason: the overall stability of the project isn’t where it needs to be yet. There are so many open issues for the 5.0 milestone that even fixing all the blockers before we’d get to Release Candidate stage next week is going to prove impossible. We have, at time of writing 212 untriaged bugs and 165 issues on the WordPress 5.0 milestone.

WordPress developer Mark Root-Wiley published a post the same day titled “WordPress 5.0 is Not Ready.” He outlined why he believes the release needs to be delayed and suggested the project pursue more auditing and quality assurance testing before shipping it out.

“WordPress 5.0 can and should be a positive change to WordPress, but if it is released in late November as planned, it won’t be,” Root-Wiley said. “There are simply too many bugs in the editor, and the experience is not polished enough. This is because the rate of development has prevented systematic quality assurance (QA) and user testing. Both types of testing are required to ensure the editor is ready and to increase the community’s confidence in the update.”

Root-Wiley describes a buggy experience when attempting to write blog posts with the new editor, which echoes many others’ recent experiences.

“I’m doing my best to give feedback, but it’s exhausting and there are so many little bugs that I struggle to isolate and replicate the one I’m reporting without running into another,” Root-Wiley said. “How is it possible for me to find so many bugs without trying from just writing 1.5 blog posts?”

Root-Wiley also suggested removing what he deemed to be unnecessary features in order to streamline the editing experience and focus on the fundamentals. These features include the tables block, paragraph background colors, spotlight and fullscreen mode, dropcaps, verse block, among others.

“The pace of development has been blistering,” Root-Wiley said. “That speed has been great for developing a lot of features and iterating on those features quickly, but it hasn’t allowed for sufficient testing. What’s needed now is more time for people to find and report bugs with the editor features in their proposed final state.”

Gutenberg criticism is often characterized as coming from people who are resistant to change, but these strong messages about delaying the release come from developers who believe the new editor is the future and have heavily invested in contributing to its success.

Both de Valk and Root-Wiley’s posts seem to have resonated with many who have had similar experiences with the editor. Other core developers and committers have also publicly lent their voices to the call to delay the release.

My thoughts are very much aligned here. I'm super excited for the release — I think it's crucial for WordPress' success. But I don't think it, nor the ecosystem, are quite ready following the shortened release cycle. https://t.co/R0nZt0mk41

— Mike Schroder (@GetSource) November 7, 2018

This: https://t.co/wpcQ02qcTw They are missing almost every milestone on their release schedule, leaving me 1 week to test with RC before Thanksgiving, and plugin/theme authors no time to develop/test with stabler code. It should just come out with their backup January date.

— Lisa Woodruff (@lisa_m_woodruff) November 8, 2018

Opinions on Gutenberg’s readiness vary wildly depending on the person’s perspective and involvement in the project. Those who are working on it full-time have not publicly offered opinions indicating that it might not be ready for the November 19 timeline.

“The 5.0 milestone is in a very manageable place, but if the volume becomes more worrying in the next couple days or it becomes clear milestones won’t be made, we’ll revise as needed,” Gutenberg technical lead Matias Ventura Ventura said during yesterday’s dev chat. He confirmed that the fast pace of development will continue.

Regardless of when 5.0 is released, users can count on getting minor releases every two weeks to address bugs and issues that pop up after Gutenberg is in the hands of millions more users.

“Hopefully as people get used to the more regular cadence they can plan around it, much like they used to complain a ton about, but then got used to, 3 major releases a year,” Mullenweg said during the dev chat.

In 2016, Mullenweg began describing how WordPress could become “the operating system of the web,” with open APIs that others can build on. While that idea encompasses a lot more than just release schedules, WordPress seems to be moving in the direction of shipping updates that come more frequently and eventually more invisibly in the background, similar to how users update their browsers. Releasing Gutenberg in its current state, with frequent updates following, could prove to be a major testing ground to see if greater world of WordPress users are ready to embrace this new era of rapid iteration.

Dries Buytaert: The end of PHP 5

Main Drupal Feed - Thu, 11/08/2018 - 23:19

It's easy to take PHP for granted. The Open Source scripting language is used by nearly 80% of the world's websites.

According to W3Techs, around 61 percent of websites on the internet still use PHP 5. PHP 5 was first released fourteen years ago. Fourteen years is a long time, and makes it easy to take it for granted.

Now is the time to give PHP 5 some attention. In less than two months, on December 31st, security support for PHP 5 will officially cease. (Note: Some Linux distributions, such as Debian Long Term Support distributions, will still try to backport security fixes.)

If you haven't already, now is the time to make sure your site is running an updated and supported version of PHP.

Beyond security considerations, sites that are running on older versions of PHP are missing out on the significant performance improvements that come with the newer versions.

Drupal and PHP 5 Drupal 8

Drupal 8 will drop support for PHP 5 on March 6, 2019. We recommend updating to at least PHP 7.1 if possible, and ideally PHP 7.2, which is supported as of Drupal 8.5 (which was released March, 2018). Drupal 8.7 (to be released in May, 2019) will support PHP 7.3, and we may backport PHP 7.3 support to Drupal 8.6 in the coming months as well.

Drupal 7

Drupal 7 will drop support for older versions of PHP 5 on December 31st, but will continue to support PHP 5.6 as long there are one or more third-party organizations providing reliable, extended security support for PHP 5.

Earlier today, we released Drupal 7.61 which now supports PHP 7.2. This should make upgrades from PHP 5 easier. Drupal 7's support for PHP 7.3 is being worked on but we don't know yet when it will be available.

Thank you!

It's a credit to the PHP community that they've made it easy for all of us to take this programming language for granted. But that can't go on forever. It's time to move on from PHP 5 and upgrade to a newer version so that we can all innovate faster.

I'd also like to thank the Drupal community — both those contributing to Drupal 7 and Drupal 8 — for keeping Drupal compatible with the newest versions of PHP. That certainly helps make PHP upgrades easier.

Hook 42: BADCamp 2018 Retrospective: A GatsbyJS Primer

Main Drupal Feed - Thu, 11/08/2018 - 21:27

Now that I’ve settled back down in Alaska after a fun trip to Berkeley for BADCamp, I’m finally digesting all of the info I gathered throughout the week. As always, it was cool to look over the schedule and see what topics were getting a lot of attention; and, without a doubt, it seemed like GatsbyJS was the hot-ticket item this year. So here’s a primer on what GatsbyJS is and why the Drupal community seems so head-over-heels for this up and coming site generator.

Kanopi Studios: BADCamp + Accessibility = Education, Inspiration and Opportunity

Main Drupal Feed - Thu, 11/08/2018 - 15:51

Now that the excitement of BADCamp has worn off, I have a moment to reflect on my experience as a first-time attendee of this amazing, free event. Knowing full well how deeply involved Kanopi Studios is in both the organization and thought leadership at BADCamp, I crafted my schedule for an opportunity to hear my colleagues while also attending as many sessions on Accessibility and User Experience (UX) as possible.

Kanopi’s sessions included the following:

The rest of my schedule revolved around a series of sessions and trainings tailored toward contributing to the Drupal community, Accessibility and User Experience.

For the sake of this post, I want to cover a topic that everyone who builds websites can learn from. Without further ado, let’s dive a bit deeper into the accessibility portion of the camp.  

Who is affected by web accessibility?

According to the CDC, 53 million adults in the US live with some kind of disability; which adds up to 26% of adults in the US. Issues range from temporary difficulties (like a broken wrist) to permanent aspects of daily life that affect our vision, hearing, mental processing and mobility. Creating an accessible website allows you to communicate with 1 in 4 adults you might otherwise have excluded.

What is web accessibility?

Accessibility is a detailed set of requirements for content writers, web designers and web developers. By ensuring that a website is accessible, we are taking an inclusive attitude towards our products and businesses. The Web Content Accessibility Guidelines (WCAG) are a globally acknowledged set of standards that help us publish content that fits within the established success criteria. These guidelines are organized into the following four categories.

WCAG Categories:

  • Is your website perceivable? This applies to non-text content, time-based media (audio and video), color contrast, text size, etc.
  • Is your website operable? This ensures that content is easy to navigate using a keyboard, that animations and interactions meet real-user requirements, buttons are large enough to click, etc.
  • Is your website understandable? This means that text content is easy to read for someone at a ninth grade reading level, that interactions follow design patterns in a predictable manner, that form errors are easy to recover from, etc.
  • Is your website robust? This means that content should be easy to interpret for assistive technologies, such as screen readers.

The World Wide Web Consortium (W3C) is an international community whose mission is to lead the Web to its full potential. They have also published a checklist to aid our efforts in meeting WCAG success criteria.

How can we be successful in making the web accessible?

Industries have varied requirements when it comes to web accessibility. WCAG has three levels of compliance, ranging from A to AA to AAA. A conformity has the lowest set of requirements and AAA has the strictest set of requirements; so strict, in fact, it may be impossible to achieve across an entire site.

Efforts to meet these standards fall on every individual involved in the process of creating a website. Although there are many tools that aid in our journey, we reach accessibility through a combination of programmatic and manual means.

The most important thing to keep in mind is the fact that achieving success in the world of accessibility is a journey. Any efforts along the way will get you one step closer towards a more inclusive website and a broader audience base.

Please Remember: Once Kanopi helps you launch an accessible site, it’s your job to maintain it. Any content you add moving forward must be properly tagged; images should have proper alt text and videos should have captions. Users come to your site because they love your content, after all! The more you can make your content accessible, the more you will delight your users.

Interested in making your site more accessible? Check out some of the resources I linked to above to join in learning from my peers at BADCamp. If you need more help getting there, let’s chat!

The post BADCamp + Accessibility = Education, Inspiration and Opportunity appeared first on Kanopi Studios.

MidCamp - Midwest Drupal Camp: MidCamp is Coming

Main Drupal Feed - Thu, 11/08/2018 - 15:50
MidCamp is Coming

MidCamp is returning for its sixth year next March 20-23, 2019. We’ll be back at DePaul University for four days of presentations, professional training, contribution sprints, and socials. Designers, developers, and users will be able to brush shoulders with Drupal service providers, hosting vendors, and other members of the broader web development community.

Agenda Overview

This year we have some changes to our general agenda. We’ll be adding summits for the first time! We’ve also moved our sessions to Thursday and Friday so that attendees get some of their weekends back. A high-level agenda is as follows:

  • Wednesday, Mar 20 - Summits, Training, and Contribution Sprints

  • Thursday and Friday, Mar 21-22 - Sessions

  • Saturday, Mar 23 - Contribution Sprints

Stay Tuned for these Upcoming Dates

Stay tuned into the website and our newsletter for some upcoming dates.

  • NOW! - Ticket sales are open on Eventbrite. Spread the word and get your tickets early: https://midcamp2019.eventbrite.com/

  • Nov 14, 2018 - Our website will be fully up and running. It will be ready to open our call for papers.

  • Dec 12, 2018 - Call for papers will close and travel information will be available on the website.

  • Jan 9, 2019 - We will open the registration for training and summits.

  • Jan 16, 2019 - Announce Featured speakers on the website.

  • Jan 23, 2019 - We will post the Final schedule for the website.

Help us Make MidCamp!

It’s not too late to get involved with MidCamp 2019. We’re on MidCamp Slack. You can also contribute by telling us what topics you’re interested in seeing in the 2019 program.

 

Join the conversation

Community: Introducing the Drupal Governance Task Force 2018 Proposal

Main Drupal Feed - Thu, 11/08/2018 - 14:20

Drupal is one of the most successful open source projects in the world. Governance is fundamental to the project's success.

The community and the code has been built from the ground up. And as the code has grown, so has the community.

When communities are first emerging it's easy to bring newcomers along, but over time the community begins to mature, change, and then needs to adapt. Challenges and opportunities emerge as evolution occurs, and our community needs to navigate them strategically.

A Governance Task Force has been meeting weekly since May to put together the strategic proposal we now share with you. We've synthesized ideas, discussions, and experiences from people we've interviewed, and we've revisited the themes that emerged from the community listening project run by Whitney Hess and by previous governance discussions.

This Drupal Governance Task Force 2018 Proposal serves two purposes.

Firstly, it's clear that for community evolution to occur there needs to be broad agreement and buy-in. People are comfortable jumping in and building a new module, but community change and action is hard. People talked to us openly about the unclear processes and barriers holding back community progress.

We heard strong perceptions that support from Dries or the Drupal Association is needed before initiatives could be created or scaled; real or otherwise, this is affecting community progress and action. Speaking to people from the Drupal Association, the Community Working Group and other initiative leaders, they also feel limitations. But to change their terms of reference and priorities they also need to have a community directive.

The community is stronger and more influential than we sometimes assume  --- when we are speaking together.

That's why at the heart of this proposal is a new community governance structure.

The second purpose of the proposal is to create a starting point --- a framework. We’ve been practical, highlighting a range of actions that form a backbone for community evolution. It’s not a defined roadmap, and it’s not a list of every idea we had or heard. We welcome the discussion, debate and idea generation that this document will spark. We want to hear your solutions on how to get change done, and what you would like to contribute.

We strived to make practical recommendations with the potential to make progress, lower barriers, and help our community to continue to evolve with time.

Throughout this process we have heard people say they believe change is necessary. Change is necessary for the longevity of Drupal the project and the code. Change is necessary to create a new generation of Drupallers — the people we want to help build ambitious things and to have the chance to build a career within our community.

It is hard to not feel the project is at a crossroads. We’ve climbed the mountain of Drupal 8, we sit at the peak and look to the valley below.

Where we go next, and who we take with us, is up to you.

We hope this proposal helps.

David, Ela, Stella, Lyndsey, Rachel, Hussain, and Adam

File attachments:  Drupal-Governance-Task-Force-Proposal-2018.pdf

Sooper Drupal Themes: Drupal Costs & TCO: Proprietary vs. Open Source

Main Drupal Feed - Thu, 11/08/2018 - 10:37

The real cost of creating and maintaining a new website can be hard to estimate even for the best among Drupal professionals. By using the Total Cost of Ownership (TCO) methodology, organizations can ensure that both direct and indirect expenses of operating a website are considered and calculated rather than just emphasize on the initial spending. In this article we are going to take a look at what are the Drupal costs of owning a website versus using a proprietary software.

There are some key considerations to decide on before diving into building a website:

  1. Open Source vs. Proprietary License
  2. Creating and Managing Web Content
  3. Re-designing and Updating Content
  4. Future Upgrades and Longevity
  5. Long Term Savings
Custom Code - a necessity of the past?

OPTASY: Predictive UX in Drupal: Can We Create Anticipated User Experiences in Drupal 8?  

Main Drupal Feed - Thu, 11/08/2018 - 08:33
Predictive UX in Drupal: Can We Create Anticipated User Experiences in Drupal 8?   silviu.serdaru Thu, 11/08/2018 - 08:33

What do you get when you put together: Drupal 8 + AI + UX? Drupal8's content management features and integration capabilities, AI, for storing and interpreting data and building a predictive model and UX for anticipating user behavior while adding a “human touch” to the equation? You get predictive UX in Drupal!

Is it possible? Can we implement predictive UX in Drupal and thus create anticipated user experiences that:
 

  • help you deliver meaningful content only    
  • simplify user choice
  • simplify users'... lives?
     

But how does machine learning actually power these predictive user experiences? What's the whole mechanism behind?

Pages