WPTavern: Video: A Quick Introduction to Gutenberg and the New WordPress Block Editor from LinkedIn Learning
Although WordPress developers and professionals have been inundated with Gutenberg news for more than a year, there’s a whole wide world of users who will learn about the project for the first time when 4.9.8 includes a “Try Gutenberg” prompt in the admin. If you haven’t been following the news closely and are wondering what all of this Gutenberg talk is about, Morten Rand-Hendriksen provides a succinct introduction to the new editor that is coming in WordPress 5.0.
The video was created as part of LinkedIn’s WordPress Essentials Training course. The first part explains the basic concept of a block and includes a mini tour of the new interface, followed by a short overview of where the Gutenberg project is going in the future.
Coffee is a magical thing. It gets you going, clarifies your thoughts, makes you feel all warm inside. I don’t know what I’d do without it. So when we consider installing the Drupal module named after this irreplaceable daily beverage, we see that it has a similar effect. It just makes things better. Am I overstating things? Probably. But I haven’t had enough coffee yet today and I need to get this blog going with some pizzazz.
The 2018 goal for the Drupal Association has been to grow Drupal adoption. This goal cannot be achieved without testing ideas for promoting Drupal within Drupal.org and DrupalCon, the two main channels we have to reach Drupal evaluators. We also can't do this work without your support.
We've refreshed Drupal.org's homepage and top-level menu to include a new persona-based design because developers, marketers/content-editors, and agency owners all have differing needs on their Drupal adoption journey. We're helping people start their exploration to understand and fall in love with Drupal.
The Engineering Team played a key role in the Industry Pages project—from conception to execution. The industry pages help decision makers see how Drupal achieves the vision Dries' set forth when he described Drupal as the platform for ambitious digital experiences.
If you appreciate this work, help support the Drupal Association by joining as a member. Thank you!
The WordPress Community Team announced an update to the CampTix, the plugin used for selling WordCamp tickets, that makes Stripe the default payment method. The gateway was previously available as a beta plugin and could be enabled on a per-site basis but is now available to all WordCamps.
When proposing Stripe as the default payment gateway in April, Hugh Lashbrooke cited the fact that PayPal is entirely blocked and inaccessible in some countries. He also identified Stripe’s simpler UI and larger number of supported currencies as its chief advantages.
PayPal has been the default for years on WordCamp websites but it currently supports only 26 currencies. Stripe supports 136 currencies, allowing WordCamp organizers to offer ticket purchases in more places than before. Previously, some communities were forced to build a local gateway integration to sell WordCamp tickets via PayPal, requiring those sales to be inconveniently funneled through a local bank account. The Stripe gateway option is a welcome update to support WordPress’ growing international community, which held camps in 73 countries in 2017.
It’s important to note that Stripe isn’t fully replacing PayPal. The Camptix plugin allows organizers to activate multiple payment gateways for cases where one or both make more sense, retaining the flexibility to support ticket sales at camps with different payment requirements.
We all have our reasons for the things we do. Money, love, orders, etc. Vladimir Petkov started using WordPress because it solved a problem. As the years went by it continued to solve problems, and he continued to use it. His time to give back didn’t arrive until much later though.
His 7 year old daughter wanted a blog, and WordPress wasn’t completely translated into her language. So Vladimir learned how to translate WordPress, so his little girl (and every other Bulgarian speaker) can use their voice to speak to the world.
Why do you give back to WordPress? If you’d like more info about how you can (no coding required!) drop a note in the comments.
Also, check out Vladimir’s essay.
On July 25, 2018, the Drupal Association will host their next scheduled executive session, which is a private session for the board members.Executive Session Agenda
While the The Executive Session is a private meeting amongst board members, we want to provide insight into what the agenda topics will be.
Executive update from the Executive Director
Committee updates: nominating, revenue, finance, and governance
Preparation for the annual Executive Director performance review
The schedule for Drupal Association Board Meetings is always available on the Association section of the Drupal website.
The American Disability Act (ADA), 1990 provides provisions to secure the rights of specially-abled people. Although, when first passed, it focussed primarily on physical properties, over time it has covered digital spaces too, which means people can take a complaint to the court for discriminating and violating the ADA act.
Accessibility is a more accepted norm when it comes to physical infrastructure, however, when accessibility translates to the digital space, industries across the web are struggling to answer. Higher education is no exception.“The National Association of the Deaf in 2015 slapped Harvard University and Massachusetts Institute of Technology in Massachusetts federal court, accusing them of discriminating against deaf and hard-of-hearing people”
An absence of hard and fast rules to adhere to in the higher education sector often lead institutes to ignore the web accessibility practices.Exploring the Issues in Higher Ed and the ADA Compliance
Lawsuits can be avoided by following WCAG 2.0. Since web accessibility guidelines and best practices are already clear through WCAG 2.0.The ADA Compliance
The ADA not only covers the general non-discriminatory guidelines but also encourages organizations, institutions, and businesses to provide accommodations to people with disabilities so they can have the same level of access to services as everyone else.
The law was amended later in 2008 to fit the conditions of modern society and include the digital space while broadening the term “disability”.
Since, ADA conforms to other state laws, including section 508 of the Rehabilitation Act and existing WCAG 2.0 guidelines, hence the term - ADA Website Compliance. In January 2017, the federal government adopted the Web Content Accessibility Guidelines, (popular as WCAG 2.0) setting the standards with A and AA level for all websites.The Guiding Principles to Web Accessibility - POUR
The WCAG 2.0 consists of 12 guidelines with four arching principles of POUR. These guidelines relate to one simple question: can the users with varying degree of ability ingest the content on your site?“Just as no ramps would exclude people with a wheelchair, videos without caption exclude people who are hard of hearing.”
Accessibility in higher education should not be restricted only to lectures and videos. In the case of a flash-based campus tour, there should be alt-text for visually impaired people. Accessing content should be intuitive. Making navigation easier needs to be part of the plan.
The content needs to be presented in different ways, including assistive technologies, without losing its meaning. The easiest way to do so is by providing alt-text for non-text content. The content should be easier to see and hear.
By no means should the multimedia content be unattainable. In the case of Harvard and Massachusetts Institute of Technology, the content was not perceivable for the deaf and hard-of-hearing people.
Story of Harvard: Harvard and M.I.T. have extensive free materials online, distributed across platforms like Harvard@Home, MIT OpenCourseWare, YouTube, and iTunesU, edX which offers extensive massive open online courses (MOOCs), free to students around the world.
The videos either did not include captions or were inaccurately captioned (read unintelligibly) making it inaccessible for people with hearing ability.
"Accessible" means fully and equally accessible to, and independently usable by, differently abled students and faculty members in a way that they can acquire the same information, engage in the same interactions, and enjoy the same services as sighted students and faculty with substantially equivalent ease of use.
This principle ensures that the content is easy to operate upon. Web accessibility issues are not synonymous with visibility issues, as is the popular myth. They are as much a problem for people with hearing disability as for a person with a neurological or cognitive disorder.
The content on the website needs to be accessible with a keyboard for people with limited motor functions, people with color blindness, and avoiding the use of content and types that cause seizure.“People living with reflex epilepsy have seizures that occur in response to a specific stimulus, like flashing lights or by noises.”
Is the text readable for people with difference in visual ability? This principle ensures that the content appears and operates in a predictable way. This specifically focuses on the issues related to color contrast.
Accessing content should be intuitive and easy. To disable the pop-up button or going back need not be a time-consuming exercise.
Atlantic Cape Community College in 2007 was dragged to court by a visually challenged student after the campus and curriculum proved to be a challenge for him.
Any content - written or multimedia - should be future proof. Efforts should be made to maximize compatibility with current and future user tools. Before the dawn of the 21st century, screen readers were not as popular as they are 18 years later. A decade back even mobile phones were not as ubiquitous.
Assistive technologies are advancing by leaps and bounds, and your site needs to adapt and step up with upcoming trends in hardware and software tools. In order to keep the content robust, higher ed institutes need to adhere to best practices or lose it the way University of California, Berkeley did.
“In a similar scenario in 2017, The University of California, Berkeley, in response to a Justice Department accessibility order, had two options:
1. Update existing content to comply with accessibility standards.
2. Remove more than 20,000 video and audio files from public view.
They chose the latter, the digital equivalent of boarding up the entrance to a building instead of installing a wheelchair accessible ramp.”
In its defense, the Harvard University asked the court to propose rules “to provide much-needed guidance in this area”. This is one of the most infuriating aspects of accessibility compliance in higher education – there has been an absence of hard and fast rules to adhere to. Something that echoes the statement of Harvard.
“It costs significantly less to make a site accessible than it does to procure the lawyer to protect you in an accessibility claim.”
Now that we understand the guiding principles, we are in a better position to deliver a better user experience to all. One thing worth highlighting is - accessibility issues are easier to address before they manifest on your site, not after.
Under WCAG 2.0 priority levels are assigned to each checkpoint based on its impact on accessibility. These levels were the following:
Priority 1: Conforming to this level will make it possible for one or more groups to access the web content. This is level A.
Priority 2: Conforming to this level will make it easy for one or more groups to access the web content. This is level AA.
Priority 3: Conforming to this level will make it easier for most of the groups to access the web content. This is level AAA.
Drupal has been powering higher education websites. In fact, it is one of the most-sought-after CMS for higher education institutes. Read Why Drupal Is Your Best Bet For Your Educational SiteLevel A Conformance
- Provide web pages with titles that describe the topic or purpose of the page.
- Make sure it is navigated in a meaningful manner while providing the options to bypass repeating blocks of content on multiple pages.
- Make sure that the purpose of each link can be determined by the link text alone unless the purpose is ambiguous to all users.
- In case of an input error made by the user, provide text information specifying the item in error and the error itself.
- Provide labels, guidance and instructions, and text alternatives for all non-text content. Controls or input fields must have a name describing their purpose.
- Information must be accessible to different users in multiple ways, including through assistive technologies (such as screen readers) without losing information.
- Using colors that convey visual information, distinguishing visual components, indicating actions or prompting for a response.
- Users must have the ability to fully operate the website through a keyboard interface, including the ability to pause and stop any presentation, audio or adjust the volume.
- Content must not cause seizures. Avoid designing content in a way that is known to cause seizures.
- Compatibility with other user software, like the ones in assistive technologies.
- Provide captions for all live audio content. And provide audio descriptions for all pre-recorded video content.
- Text content and images of text must have a contrast ratio of 4.5:1. Content that serves only design purposes have no contrast requirements.
- Enable the user to resize the text up to 200 percent without any assistive technology.
- Use of text over images, whenever possible.
- Provide multiple ways to locate web pages.
- Ensure the keyboard focus indicator visibility through all interfaces.
- Components with the same functionality must be identified consistently.
- Ensure the security of legal and financial data transactions by making them reversible, and giving the user an opportunity to recheck the input data and the confirmation mechanism before finalizing submission.
- Support all pre-recorded audio content with sign language interpretation and provide extended audio descriptions for all prerecorded video content where there’s no opportunity to pause the foreground audio and provide audio descriptions.
- The contrast ratio between text and images must be 7:1. However, text or images which serve only design purposes do not require contrast or alt text.
- Any pre-recorded audio content must provide users with context-sensitive help. In case the audio-content is not a CAPTCHA it should either:
- must not contain any background sounds
- or the background sounds can be turned off,
- or the background sounds should be at least 20 dB lower than the pre-recorded speech content.
- Provide users with a mechanism to choose foreground and background colors. With the width of blocks of content must not exceed 80 characters or glyphs.
- Line spacing must be at least 1.5 spaces within paragraphs and paragraph spacing must be at least 1.5 times larger than the line spacing.
- Ensure the text can be adjusted up to 200 percent without the use of assistive technologies. The user does not have to scroll horizontally to read a line of text.
- Allow users to postpone or suppress interruptions, except in the case of emergency.
- Ensure the users can continue their activity without much interference or loss of data after re-authentication in case the authenticated session expires.
- Include information on the user’s location within a set of pages. Provide supplementary content for identifying definitions of unusual words or phrases, including idioms, abbreviations, and jargon.
- Provide additional content when users require a more advanced education level than lower secondary education (to 9th grade) to understand the content.
- Changes of web content may only be initiated by the user or the user must be provided with a mechanism to turn off such changes.
It is worth noting that web accessibility compliance may not be realistic for all websites depending on the type of content. Drop a mail at email@example.com and connect with us if you are planning to build a user-friendly education website.blog banner blog image American Disability Act ADA Web Accessibility Drupal Drupal 8 HTML Accessibility Drupal Web Accessibility WCAG Web Content Accessibility Guidelines Accessibility in Higher Education WCAG WCAG 2.0 Blog Type Articles Is it a good read ? On
In the video, Mullenweg shares the progress that’s been made on Gutenberg, WordPress core development, a Gutenberg road map for including it into core, and what to expect after WordPress 5.0 is released.
Be sure to watch the video to the end to catch the memorable, GDPR cookie joke.
WPCampus, a conference focused on WordPress in higher-education takes place this week between July 12-14 at Washington University in St. Louis, Missouri.
If you’re unable to attend in-person or would like to watch the event from home, visit the WPCampus Stream page. Beginning July 13th at 9AM CDT, all general sessions will be streamed live for free. Sessions will be recorded and be available after the event as well.
WPTavern: New Classic Editor Addon Plugin Disables the “Try Gutenberg” Prompt Coming in WordPress 4.9.8
Gutenberg development continues along the roadmap Matt Mullenweg announced at WordCamp Europe with WordPress 4.9.8 set to introduce a “Try Gutenberg” prompt to increase usage and testing. Core design contributors are currently working on a few new iterations of the callout. They are also considering including a section inside the prompt with an option to install the Classic Editor plugin in preparation for Gutenberg.
Developers and agencies have time to install the Classic Editor on client sites that are not ready for Gutenberg, but this will not prevent users from seeing the “Try Gutenberg” prompt. Greg Schoppe, one of Gutenberg’s most outspoken critics, partnered with Pieter Bos to develop a plugin called Classic Editor Addon that changes how the Classic Editor plugin works.
“For agencies supporting many sites, whose users have no way of knowing whether Gutenberg will break their site or not, this nag screen is a danger,” Schoppe commented on our most recent Gutenberg update. “Pre-emptively installing Classic Editor unfortunately won’t suppress the nag notice either, but since Classic Editor is being used as a bellwether of the success of Gutenberg, it’s important that you install it, if you expect issues.”
Schoppe co-wrote the Classic Editor Addon to solve this problem. It suppresses the “Try Gutenberg” prompt and when the new editing experience ships in 5.0, it will automatically suppress Gutenberg as well.
Since the Classic Editor plugin doesn’t remove Gutenberg by default, the addon plugin sets the option to fully replace Gutenberg. It also removes the Classic Editor’s options from the Settings > Writing screen. Schoppe said he believes this is what the Classic Editor plugin should have done out of the box, instead of requiring the user to find the settings screen to replace Gutenberg.
Installing both the Classic Editor and Classic Editor Addon on tens or hundreds of client sites could be time consuming, so Schoppe suggests using a site management dashboard, such as MainWP, ManageWP, or Jetpack, to bulk install both plugins for clients.
According to stats on WordPress.org, Gutenberg is active on more than 10,000 sites and the Classic Editor is active on 4,000+ sites. The “Try Gutenberg” prompt is expected to go out in WordPress 4.9.8, which is targeted for the end of July. The goal for the prompt is to make users aware of the plugin and get more testers involved before Gutenberg lands in WordPress 5.0.
Drupal Association blog: Calling all Drupal Agency Leaders: Participate in the 2018 Drupal Business Survey
The third edition of the annual Drupal Business Survey is here. Exove and One Shoe created the survey in collaboration with Drupal Association, to gain insight of Drupal’s health, focus and latest business trends. It also gives perspective on how Drupal agencies are doing and how customers see Drupal.
We encourage all Drupal business leaders to participate in this year’s Drupal Business Survey.
Participation is anonymous and takes only about 10 minutes. The first results will be presented at the Drupal CEO Dinner at Drupal Europe on Wednesday, September 12, 2018. Analysis and insights will officially be published on Drupal.org.
You can participate anytime now until July 31st, 2018.
The survey can be accessed here.
Acquia Developer Center Blog: Experience Express in Utrecht: Conversational Design and Modern Front-end Approaches at Frontend United
With a uniquely diverse community of designers, developers, and everyone in between, Frontend United is one of the conferences I find I enjoy more and more each time I attend. And this time, in Utrecht, a wide range of designer- and developer-oriented content greeted attendees both within and well outside the Drupal universe.Tags: acquia drupal planet
The best part of my job is teaching Drupal. As a Drupal trainer, I get to meet a lot of Drupalers with really different backgrounds. Some are brand-new to Drupal, some have lots of experience. Listening to them tell of their Drupal journeys, both the highlights and the low points, has given me insights into the different ways people encounter Drupal and some of the most common reasons why they love it, use it and get involved in the community (or not).
I've recently been thinking about the Drupal community from a user experience point of view. I regularly host UI meetups for developers and designers, and I'm also volunteering on Drupal's Admin UI initiative, which is creating an accessible administrative interface based on user data and feedback. Both have taught me to empathize with others and understand why they might be feeling excited, warm and fuzzy, anxious, frustrated or curious about Drupal at any given point. It's also given me ideas about what we can all can do to improve the Drupal experience, including:1. Participate in the community
If you think back to your own best experience with Drupal, there's a decent chance that it was a DrupalCon, DrupalCamp or another time when you had the chance to learn from other Drupalers or share your knowledge with them. It feels inspiring to mentor newcomers, help people solve problems on Drupal Slack or get advice from someone who seems to care. Let's keep it up and look for opportunities to take it further!2. Recognize the challenges that you and others are facing
There's no point in pretending that using Drupal is always smooth sailing. Hiding the challenging parts of our experiences only makes others feel like they're alone or that they've missed something everybody else has understood. Asking new users around the world to tell me about their pain points has shown me, as just one small example, that Drupal terminology can often be intimidating. We all have our issues, and talking about them is the first step toward finding solutions for them.3. Get involved with existing initiatives
Community members are on the job when it comes to refining certain aspects of the Drupal experience. The Promote Drupal Initiative has already enhanced Drupal.org's landing page with the persona-specific information its audience was looking for. Their next step will be devising ways to make it easier for new users to find their way into community engagement. And they're not the only ongoing project that could benefit from your time, expertise or financial support: the Out of the Box Experience Initiative, for example, is helping Drupal to make a better and more helpful first impression when it's installed by a prospective user.4. Imagine new ways of solving problems
The beauty of being part of an open source community is that if you see a problem, you have the power to address it. If you have an idea for helping others have a better Drupal journey, why not try it out? Great user experiences encourage user-base growth and vice versa: a virtuous cycle that I'm committed to supporting.
Inspired by these ideas, I recently decided to run for a position on the Drupal Association's Board of Directors as a "director at large"---a community representative, in other words---because I would love to put my time, energy and knowledge towards growing the community and promoting Drupal to new groups and markets. If you have an active profile on Drupal.org then you can vote in this election here any time before Friday, July 13.
For a video version of this post, here's a recording of my session on the topic at DrupalCamp Montreal:+ more awesome articles by Evolving Web
Let's say that you need to spin up a new Drupal environment in... minutes. To quickly test a new patch to Drupal core, maybe, or to switch between 2 or more clients on the same day and thus to run multiple copies on several websites... In this case, how about taking the quick and easy way and set up a local Drupal site with Lando?
"What is Lando?" you might legitimately ask yourself.
A DevOps tool and Docker container-based technology enabling you to spin up all the services and tools that you need to develop a new Drupal project in no time.
"Why would I choose Lando as a method to set up a local Drupal site?"
Quite a few people in the Drupal community are looking forward to see the JSON API module ship with Drupal 8 core.
- they want to use it on their projects
- the Admin UI & JS Modernization Initiative needs it
- they want to see Drupal 8 ship with a more capable RESTful HTTP API
- then Drupal will have a non-NIH (Not Invented Here) API but one that follows a widely used spec
- it enables them to build progressively decoupled components
So where are things at?Timeline
Let’s start with a high-level timeline:
- The plan (intent) to move the JSON API module into Drupal core was approved by Drupal’s product managers and a framework manager 4 months ago, on March 19, 2018!
- A core patch was posted on March 29 (issue #2843147). My colleague Gabe and I had already been working full time for a few months at that point to make the JSON API modules more stable: several security releases, much test coverage and so on.
- Some reviews followed, but mostly the issue (#2843147) just sat there. Anybody was free to provide feedback. We encouraged people to review, test and criticize the JSON API contrib module. People did: another 1000 sites started using JSON API! Rather than commenting on the core issue, they filed issues against the JSON API contrib module!
- Since December 2017, Gabe and I were still working on it full time, and e0ipso whenever his day job/free time allowed. Thanks to the test coverage Gabe and I had been adding, bugs were being fixed much faster than new ones were reported — and more often than not we found (long-existing) bugs before they were reported.
- Then 1.5 week ago, on June 28, we released JSON API 1.22, the final JSON API 1.x release. That same day, we branched the 2.x version. More about that below.
- The next day, on June 29, an updated core patch was posted. All feedback had been addressed!
I wrote in my comment:
Time to get this going again. Since #55, here’s what happened:
- Latest release at #55: JSON API 1.14
- Latest release today: JSON API 1.22
- 69 commits: ($ git log --oneline --since "March 30 2018 14:21 CET" | wc -l)
- Comprehensive test coverage completed (#2953318: Comprehensive JSON API integration test coverage phase 4: collections, filtering and sorting + #2953321: Comprehensive JSON API integration test coverage phase 5: nested includes and sparse field sets + #2972808: Comprehensive JSON API integration test coverage phase 6: POST/PATCH/DELETE of relationships)
- Getting the test coverage to that point revealed some security vulnerabilities (1.16), and many before it (1.14, 1.10 …)
- Ported many of the core REST improvements in the past 1.5 years to JSON API (1.15)
- Many, many, many bugfixes, and much, much clean-up for future maintainability (1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22)
That’s a lot, isn’t it? :)
But there’s more! All of the above happened on the 8.x-1.x branch. As described in #2952293: Branch next major: version 2, requiring Drupal core >=8.5 (and mentioned in #61), we have many reasons to start a 8.x-2.x branch. (That branch was created months ago, but we kept them identical for months.)
Why wait so long? Because we wanted all >6000 JSON API users to be able to gently migrate from JSON API 1.x (on Drupal ⇐8.5) to JSON API 2.x (on Drupal >=8.5). And what better way to do that than to write comprehensive test coverage, and fixing all known problems that that surfaced? That’s what we’ve been doing the past few months! This massively reduces the risk of adding JSON API to Drupal core. We outlined a plan of must-have issues before going into Drupal core: #2931785: The path for JSON API to core — and they’re all DONE as of today! Dozens of bugs have been flushed out and fixed before they ever entered core. Important: in the past 6–8 weeks we’ve noticed a steep drop in the number of bug reports and support requests that have been filed against the JSON API module!
After having been tasked with maturing core’s REST API, and finding the less-than-great state that was in when Drupal 8 shipped, and having experienced how hard it is to improve it or even just fix bugs, this was a hard requirement for me. I hope it gives core committers the same feeling of relief as it gives me, to see that JSON API will on day one be in much better shape.
The other reason why it’s in much better shape, is that the JSON API module now has no API surface other than the HTTP API! No PHP API (its sole API was dropped in the 2.x branch: #2982210: Move EntityToJsonApi service to JSON API Extras) at all, only the HTTP API as specified by http://jsonapi.org/format/.
TL;DR: JSON API in contrib today is more stable, more reliable, more feature-rich than core’s REST API. And it does so while strongly complying with the JSON API spec: it’s far less of a Drupalism than core’s REST API.
So, with pride, and with lots of sweat (no blood and no tears fortunately), @gabesullice, @e0ipso and I present you this massively improved core patch!
EDIT: P.S.: 668K bytes of the 1.0M of bytes that this patch contains are for test coverage. That’s 2/3rds!
To which e0ipso replied:So, with pride, and with lots of sweat (no blood and no tears fortunately), @gabesullice, @e0ipso and I present you this massively improved core patch! So much pride! This was a long journey, that I walked (almost) alone for a couple of years. Then @Wim Leers and @gabesullice joined and carried this to the finish line. Such a beautiful collaboration!
Then, about 12 hours ago, core release manager xjm and core framework manager effulgentsia posted a comment:(@effulgentsia and @xjm co-authored this comment.) It’s really awesome to see the progress here on JSON API! @xjm and @effulgentsia discussed this with other core committers (@webchick, @Dries, @larowlan, @catch) and with the JSON API module maintainers. Based on what we learned in these discussions, we’ve decided to target this issue for an early feature in 8.7 rather than 8.6. Therefore, we will will set it 8.7 in a few days when we branch 8.7. Reviews and comments are still welcome in the meantime, whether in this issue, or as individual issues in the jsonapi issue queue. Feel free to stop reading this comment here, or continue reading if you want to know why it’s being bumped to 8.7. First, we want to give a huge applause for everything that everyone working on the jsonapi contrib module has done. In the last 3-4 months alone (since 8.5.0 was released and #44 was written):
- Over 100 issues in the contrib project have been closed.
- There are currently only 36 open issues, only 7 of which are bug reports.
- Per #62, the remaining bug fixes require breaking backwards compatibility for users of the 1.x module, so a final 1.x release has been released, and new features and BC-breaking bug fixes are now happening in the 2.x branch.
- Also per #62, an amazing amount of test coverage has been written and correspondingly there’s been a drop in new bug reports and support requests getting filed.
- The module is now extremely well-documented, both in the API documentation and in the Drupal.org handbook.
- We generally prefer to commit significant new core features early in the release cycle for the minor, rather than toward the end. This means that this month and the next couple are the best time to commit 8.7.x features.
- To minimize the disruption to contrib, API consumers, and sites of moving a stable module from core to contrib, we’d like to have it as a stable module in 8.7.0, rather than an experimental module in 8.6.0.
- Per above, we’re not yet done breaking BC. The mentioned spec compliance issues still need more work.
- While we’re still potentially evolving the API, it’s helpful to continue having the module in contrib for faster iteration and feedback.
- Since the 2.x branch of JSON API was just branched, there are virtually no sites using it yet (only 23 as compared with the 6000 using 1.x). An alpha release of JSON API 2.x once we’re ready will give us some quick real-world testing of the final API that we’re targeting for core.
- While the module has reached maturity in contrib, we still need the final reviews and signoffs for the core patch. Given the quality of the contrib module this should go well, but it is a 1 MB patch (with 668K of tests, but that still means 300K+ of code to review.) :) We want to give our review of this code the attention it deserves.
So there you have it. JSON API will not be shipping in Drupal 8.6 this fall.
The primary reason being that it’s preferred for significant new core features to land early in the release cycle, especially ones shipping as stable from the start. This also gives the Admin UI & JS Modernization Initiative more time to actually exercise many parts of JSON API’s capabilities, and in doing so validate that it’s sufficiently capable to power it.
For us as JSON API module maintainers, it keeps things easier for a little while longer: once it’s in core, it’ll be harder to iterate: more process, slower test runs, commits can only happen by core committers and not by JSON API maintainers. Ideally, we’d commit JSON API to Drupal core with zero remaining bugs and tasks, with only feature requests being left. Good news: we’re almost there already: most open issues are feature requests!
For you as JSON API users, not much changes. Just keep using https://www.drupal.org/project/jsonapi. The 2.x branch introduced some breaking changes to better comply with the JSON API spec, and also received a few new small features. But we worked hard to make sure that disruption is minimal (example 1 2 3).1
Use it, try to break it, report bugs. I’m confident you’ll have to try hard to find bugs … and yes, that’s a challenge to y’all!
If you want to stay on 1.x, you can — and it’s rock solid thanks to the test coverage we added. That’s the reason we waited so long to work on the 2.x branch: because we wanted the thousands of JSON API sites to be in the best state possible, not be left behind. Additionally, the comprehensive test coverage we added in 1.x guarantees we’re aware of even subtle BC breaks in 2.x! ↩︎