Wordpress expert.
2004 stories

On WordPress + Git

1 Share

Can you believe it – we’ve made it through a State of the Word without anybody asking “when is WordPress moving to Git/GitHub?” You may, however, have caught a brief mention of issue trackers in relation to the Triage Team focus for 2019. While it’s very important to make the distinction between Git the version control system (VCS) and GitHub the service, as the answer usually goes, it’s understandably a continued area of interest. Many parts of WordPress have been developed using GitHub as the central tool, along with countless plugins and themes and even the WordPress book.

Here’s the tl;dr (but you should definitely keep reading after this): Changing things up doesn’t just mean “let’s make the GitHub mirror at WordPress/wordpress-develop the canonical and migrate Trac tickets over” – it means imagining what kind of change would be a net benefit to the core development process and eventually the entire .org ecosystem, and then finding the right tools to do it.

To that end, there is a group of people including myself (@helen), @desrosj, and @omarreiss who have been and will continue to be doing more coordinated research and planning around tooling. There is no current planned timeline nor is this a priority on top of the projects already enumerated for 2019, but any potential tooling change is being evaluated as it potentially relates to those projects, especially if it can better support phase 2 of Gutenberg development and the Triage Team.

This is not about chasing the latest and greatest or evangelizing a preference – it’s important to identify the goals we have for the project and what pain points we are experiencing. More specifically than “democratizing publishing”, in the core development process we should be aiming for diverse participation, a faster-but-steady pace of development, predictable and timely feedback cycles, and continuing to build user trust among users of all types. Recent pain points have been merges between branches (especially 5.0 back to trunk), JavaScript package updating, and continued participation when projects move from plugins and GitHub into core and Trac.

Roughly, here are some early thoughts on various moving pieces and potential future improvements.

Repositories and Workflows

  • SVN repositories would need to remain, essentially flipping the mirroring process to go from Git -> SVN, making SVN (and Git) repos on .org read-only
  • Should the core build process continue to be handled as-is or should we move to something like Travis?
  • Integration of more automated testing – visual regression, end-to-end, accessibility, performance
  • Identification of the ideal lifecycle of an issue and process for a pull/merge request – design, docs, review, testing, etc.
  • Identification of contribution workflows (contributor documentation, Git branching methodology, etc.)
  • Security tracking and releasing

Issue Tracker

  • Critical for a Triage Team to review existing issues and to remain active going forward
  • Potential for the bulk triage process to include migration from Trac to another tracker
  • Any issue migration should be determine on a case by case basis by the Triage Team in collaboration with component maintainers; the most automation that should happen is a tool that takes a list of Trac tickets and imports them elsewhere
  • Issue import process needs to take commenter attribution into account
  • Trac would remain in a read-only state
  • How are reports generated and used (i.e. is the built-in filtering capability enough in a given tool or will we need something more robust to support workflows)
  • Is the issue tracker still the best place for feature requests?
  • Implementation of issue templates
  • Identifying existing custom integrations and whether those problems still exist and still need to be solved after a move

Broader Ecosystem (later / bigger question mark)

  • Connectors from GitHub to .org plugin and theme repos (GitHub Actions-powered build+deploy)
  • Automated testing – sniffers, Tide, unit tests, WP and PHP compat testing, Theme Check
  • Aligning plugin and theme review teams

#git, #trac, #triage

Read the whole story
Share this story

Updating the Minimum PHP Version

1 Share

For the millions of sites already running WordPress 5.0, 85% are using PHP 5.6 or above. We’ve also recently observed that showing notifications to encourage users to upgrade their PHP version has been very effective. Yoast SEO experimented with this last year, and found that site owners upgraded their PHP version at twice the rate than before they were showed the notification.

In light of that, I’d like to propose that in April 2019, we bump the minimum PHP version requirement to be 5.6. Sites that choose to remain on 5.5 or below will still receive security updates and possibly bug fixes, but would not be able to upgrade to the latest major WordPress version until they upgraded to a supported version of PHP.

Similarly, I’d like to propose that in April 2019, we bump the minimum MySQL version requirement to be 5.5. 98.5% of WordPress 5.0 sites are using MySQL 5.5 and above.

Depending upon feedback and effectiveness, we can follow up by bumping the required PHP version to 7 as early as December 2019.

Read the whole story
Share this story

Web Content Accessibility Guidelines 2.1—for People Who Haven’t Read the Update

1 Share

Alan Dalton reaches for the glistening box of accessibility guidelines under the tree and unwraps them, taking his time to explain each carefully as he does so. Born unto you is a new guideline, and its name shall be called WCAG.

Brought to you by The CSS Layout Workshop. Does developing layouts with CSS seem like hard work? How much time could you save without all the trial and error? Are you ready to really learn CSS layout?

Happy United Nations International Day of Persons with Disabilities 2018! The United Nations chose “Empowering persons with disabilities and ensuring inclusiveness and equality” as this year’s theme. We’ve seen great examples of that in 2018; for example, Paul Robert Lloyd has detailed how he improved the accessibility of this very website.

On social media, US Congressmember-Elect Alexandria Ocasio-Cortez started using the Clipomatic app to add live captions to her Instagram live stories, conforming to success criterion 1.2.4, “Captions (Live)” of the Web Content Accessibility Guidelines (figure 1) …and British Vogue Contributing Editor Sinéad Burke has used the split-screen feature of Instagram live stories to invite an interpreter to provide live Sign Language interpretation, going above and beyond success criterion 1.2.6, “Sign Language (Prerecorded)” of the Web Content Accessibility Guidelines (figure 2).

That theme chimes with this year’s publication of the World Wide Web Consortium (W3C)’s Web Content Accessibility Guidelines (WCAG) 2.1. In last year’s “Web Content Accessibility Guidelines—for People Who Haven’t Read Them”, I mentioned the scale of the project to produce this update during 2018: “the editors have to update the guidelines to cover all the new ways that people interact with new technologies, while keeping the guidelines backwards-compatible”.

The WCAG working group have added 17 success criteria to the 61 that they released way back in 2008—for context, that was 1½ years before Apple released their first iPad! These new criteria make it easier than ever for us web geeks to produce work that is more accessible to people using mobile devices and touchscreens, people with low vision, and people with cognitive and learning disabilities.

Once again, let’s rip off all the legalese and ambiguous terminology like wrapping paper, and get up to date.

Can your users perceive the information on your website?

The first guideline has criteria that help you prevent your users from asking, “What the **** is this thing here supposed to be?” We’ve seven new criteria for this guideline.

1.3.4 Some people can’t easily change the orientation of the device that they use to browse the web, and so you should make sure that your users can use your website in portrait orientation and in landscape orientation. Consider how people slowly twirl presents that they have plucked from under the Christmas tree, to find the appropriate orientation—and expect your users to do likewise with your websites and apps. We’ve had 18½ years since John Allsopp’s revelatory Dao of Web Design enlightened us to “embrace the fact that the web doesn’t have the same constraints” as printed pages, and to “design for this flexibility”. So, even though this guideline doesn’t apply to websites where “a specific display orientation is essential,” such as a piano tutorial, always ask yourself, “What would John Allsopp do?”

1.3.5 You should help the user’s browser to automatically complete–or not complete–form fields, to save the user some time and effort. The surprisingly powerful and flexible autocomplete attribute for input elements should prove most useful here. If you’ve used microformats or microdata to mark up information about a person, the autocomplete attribute’s range of values should seem familiar. I like how the W3’s “Using HTML 5.2 autocomplete attributes” says that autocompleted values in forms help “those with dexterity disabilities who have trouble typing, those who may need more time, and anyone who wishes to reduce effort to fill out a form” (emphasis mine). Um…🙋‍♂️

1.3.6 I like this one a lot, because it can help a huge audience to overcome difficulties that might prevent them from ever using the web. Some people have cognitive difficulties that affect their memory, focus, attention, language processing, and/or decision-making. Those users often rely on assistive technologies that present information through proprietary symbols, summaries of content, and keyboard shortcuts. You could use ARIA landmarks to identify the regions of each webpage. You could also keep an eye on the W3C’s ongoing work on Personalisation Semantics.

1.4.10 If you were to find a Nintendo Switch and “Super Mario Odyssey” under your Christmas tree, you would have many hours of enjoyably scrolling horizontally and vertically to play the game. On the other hand, if you had to zoom a webpage to 400% so that you could read the content, you might have many hours of frustratedly scrolling horizontally and vertically to read the content. Learned reader, I assume you understand the purpose and the core techniques of Responsive Web Design. I also assume you’re getting up to speed with the new Grid, Flexbox, and Box Alignment techniques for layout, and overflow-wrap. Using those skills, you should make sure that all content and functionality remain available when the browser is 320px wide, without your user needing to scroll horizontally. (For vertical text, you should make sure that all content and functionality remain available when the browser is 256px high, without your user needing to scroll vertically.) You don’t have to do this for anything that would lose meaning if you restructured it into one narrow column. That includes some images, maps, diagrams, video, games, presentations, and data tables. Remember to check how your media queries affect font size: your user might find that text becomes smaller as they zoom into the webpage. So, test this one on real devices, or—better yet—test it with real users.

1.4.11 In “Web Content Accessibility Guidelines—for People Who Haven’t Read Them”, I recommended bookmarking Lea Verou’s Contrast Ratio calculator for checking that text contrasts enough with its background (for success criteria 1.4.3 and 1.4.6), so that more people can read it more easily. For this update, you should make sure that form elements and their focus states have a 3:1 contrast ratio with the colour around them. This doesn’t apply to controls that use the browser’s default styling. Also, you should make sure that graphics that convey information have a 3:1 contrast ratio with the colour around them.

1.4.12 Some people, due to low vision or dyslexia, might need to modify the typography that you agonised over. Research indicates that you should make sure that all content and functionality would remain available if a user were to set:

  • line height to at least 1½ × the font size;
  • space below paragraphs to at least 2 × the font size;
  • letter spacing to at least 0.12 × the font size;
  • word spacing to at least 0.16 × the font size.

To test this, check for text overlapping, text hiding behind other elements, or text disappearing.

1.4.13 Sometimes when visiting a website, you hover over—or tab on to—something that unleashes a newsletter subscription pop-up, some suggested “related content”, and/or a GDPR-related pop-up. On a well-designed website, you can press the Esc key on your keyboard or click a prominent “Close” button or “X” button to vanquish such intrusions. If the Esc key fails you, or if you either can’t see or can’t click the “Close” button…well, you’ll probably just close that browser tab. This situation can prove even more infuriating for users with low vision or cognitive disabilities. So, if new content appears when your user hovers over or tabs on to some element, you should make sure that:

  • your user can dismiss that content without needing to move their pointer or tab on to some other element (this doesn’t apply to error warnings, or well-behaved content that doesn’t obscure or replace other content);
  • the new content remains visible while your user moves their cursor over it;
  • the new content remains visible as long as the user hovers over that element or dismisses that content—or until the new content is no longer valid.

This doesn’t apply to situations such as hovering over an element’s title attribute, where the user’s browser controls the display of the content that appears.

Can users operate the controls and links on your website?

The second guideline has criteria that help you prevent your users from asking, “How the **** does this thing work?” We’ve nine new criteria for this guideline.

2.1.4 Some websites offer keyboard shortcuts for users. For example, the keyboard shortcuts for Gmail allow the user to press the ⇧ key and u to mark a message as unread. Usually, shortcuts on websites include modifier keys, such as Ctrl, along with a letter, number, or punctuation symbol. Unfortunately, users who have dexterity challenges sometimes trigger those shortcuts by accident, and that can make a website impossible to use. Also, speech input technology can sometimes trigger those shortcuts. If your website offers single-character keyboard shortcuts, you must allow your user to turn off or remap those shortcuts. This doesn’t apply to single-character keyboard shortcuts that only work when a control, such as drop-down list, has focus.

2.2.6 If your website uses a timeout for some process, you could store the user’s data for at least 20 hours, so that users with cognitive disabilities can take a break or take longer than usual to complete the process without losing their place or losing their data. Alternatively, you could warn the user, at the start of the process, about that the website will timeout after whatever amount of time you have chosen.

2.3.3 If your website has some non-essential animation (such as parallax scrolling) that starts when the user does some particular action, you could allow the user to turn off that animation so that you avoid harming users with vestibular disorders. The prefers-reduced-motion media query currently has limited browser support, but you can start using it now to avoid showing animations to users who select the “Reduce Motion” setting (or equivalent) in their device’s operating system:

@media (prefers-reduced-motion: reduce) {
  .MrFancyPants {
    animation: none;

2.5.1 Some websites let users use multi-touch gestures on touchscreen devices. For example, Google Maps allows users to pinch with two fingers to zoom out and “unpinch” with two fingers to zoom in. Also, some websites allow users to drag a finger to do some action, such as changing the value on an input element with type="range", or swiping sideways to the next photograph in a gallery. Some users with dexterity challenges, and some users who use a head pointer, an eye-gaze system, or speech-controlled mouse emulation, might find multi-touch gestures or dragging impossible. You must make sure that your website supports single-tap alternatives to any multi-touch gestures or dragging actions that it provides. For example, if your website lets someone pinch and unpinch a map to zoom in and out, you must also provide buttons that a user can tap to zoom in and out.

2.5.2 This might be my favourite accessibility criterion ever! Did you ever touch or press a “Send” button but then immediately realise that you really didn’t want to send the message, and so move your finger or cursor away from the “Send” button before lifting your finger?! Imagine how many arguments that functionality has prevented. 😌 You must make sure that touching or pressing does not cause anything to happen before the user raises their finger or cursor, or make sure that the user can move their finger or cursor away to prevent the action. In JavaScript, prefer onclick to onmousedown, unless your website has actions that need onmousedown. Also, this doesn’t apply to actions that need to happen as soon as the user clicks or touches. For example, a user playing a “Whac-A-Mole” game or a piano emulator needs the action to happen as soon as they click or touch the screen.

2.5.3 Recently, entrepreneur and social media guru Gary Vaynerchuk has emphasised the rise of audio and voice as output and input. He quotes a Google statistic that says one in five search queries use voice input. Once again, users with disabilities have been ahead of the curve here, having used screen readers and/or dictation software for many years. You must make sure that the text that appears on a form control or image matches how your HTML identifies that form control or image. Use proper semantic HTML to achieve this:

  • use the label element to pair text with the corresponding input element;
  • use an alt attribute value that exactly matches any text that appears in an image;
  • use an aria-labelledby attribute value that exactly matches the text that appears in any complex component.

2.5.4 Modern Web APIs allow web developers to specify how their website will react to the user shaking, tilting, or gesturing towards their device. Some users might find those actions difficult, impossible, or embarrassing to perform. If you make any functionality available when the user shakes, tilts, or gestures towards their device, you must provide form controls that make that same functionality available. As usual, this doesn’t apply to websites that require shaking, tilting, or gesturing; this includes some games and music programmes. John Gruber describes the iPhone’s “Shake to Undo” gesture as “dreadful — impossible to discover through exploration of the on-screen [user interface], bad for accessibility, and risks your phone flying out of your hand”. This accessibility criterion seems to empathise with John: you must make sure that your user can prevent your website from responding to shaking, tilting and/or gesturing towards their device.

2.5.5 Homer Simpson’s telephone famously complained, “The fingers you have used to dial are too fat.” I think we’ve all felt like that when using phones and tablets, particularly when trying to dismiss pop-ups and ads. You could make interactive elements at least 44px wide × 44px high. Apple’s “Human Interface Guidelines” agree: “Provide ample touch targets for interactive elements. Try to maintain a minimum tappable area of 44pt x 44pt for all controls.” This doesn’t apply to links within inline text, or to unsoiled elements.

2.5.6 Expect your users to use a variety of input devices they want, and to change from one to another whenever they please. For example, a user with a tablet and keyboard might jab icons on the screen while typing on the keyboard, or a user might dictate text while alone and then type on a keyboard when a colleague arrives. You could make sure that your website allows your users to use whichever available input modality they choose. Once again, this doesn’t apply to websites that require a specific modality; this includes typing tutors and music programmes.

Can users understand your content?

The third guideline has criteria that help you prevent your users from asking, “What the **** does this mean?” We’ve no new criteria for this guideline.

Have you made your website robust enough to work on your users’ browsers and assistive technologies?

The fourth and final guideline has criteria that help you prevent your users from asking, “Why the **** doesn’t this work on my device?” We’ve one new criterion for this guideline.

4.1.3 Sometimes you need to let your user know the status of something: “Did it work OK? What was the error? How far through it are we?” However, you should avoid making your user lose their place on the webpage, and so you should let them know the status without opening a new window, focusing on another element, or submitting a form. To do this properly for assistive technology users, choose the appropriate ARIA role for the new content; for example:

  • if your user needs to know, “Did it work OK?”, add role="status”;
  • if your user needs to know, “What was the error?”, add role="alert”;
  • if you user needs to know, “How far through it are we?”, add role="log" (for a chat window) or role="progressbar" (for, well, a progress bar).

Better design for humans

My favourite of Luke Wroblewski’s collection of Design Quotes is, “Design is the art of gradually applying constraints until only one solution remains,” from that most prolific author, “Unknown”. I’ve always viewed the Web Content Accessibility Guidelines as people-based constraints, and liked how they help the design process. With these 17 new web content accessibility criteria, go forth and create solutions that more people than ever before can use.

Spending those book vouchers you got for Christmas

What next? If you’re looking for something to do to keep you busy this Christmas, I thoroughly recommend these four books for increasing your accessibility expertise:

About the author

Alan Dalton worked for Ireland’s National Disability Authority for 9½ years, mostly as Accessibility Development Advisor. That involved working closely with public sector bodies to make websites, services, and information more accessible to all users, including users with disabilities. Before that, he was a consultant and trainer for Software Paths Ltd. in Dublin. In his spare time, he maintains StrongPasswordGenerator.com to help people stay safe online, tweets, and takes photos.

More articles by Alan

Read the whole story
Share this story

How WordPress Has Changed People’s Lives

1 Share

It’s Friday and we could probably all use a little more positivity in our lives, especially on social media. Morten Rand-Hendriksen recently asked his followers on Twitter how WordPress has changed their lives. Here are a couple of the responses that stood out to me.

As a beginner web designer, who was struggling to find a job/work, WordPress opened the door to web development and enabled me to offer clients control over their websites. That was nearly 10 years ago and I’ve been building with WP ever since.

Keith Devon

I graduated in 2008 right into the thick of the recession. No jobs, nothing – the only way I could put food on the table and pay rent was to build WordPress sites for people. This led to my entire career in UX design, and my life would be very very different without WordPress.

Scott Sullivan

Here’s one you won’t expect. I was in an agency job I hated. I had an interview with Automattic and failed. Devastated, it forced me to look at what I really wanted. I now have my own consultancy.

Chris Taylor

I’d been working in the social field for more than 30 years. In 2015 I had to change and decided to work in the digital world. I casually met the Turin Meetup community and joined them. Then I started to contribute to the Polyglots team. Now, I’m one of the Italian GTE


I’d been working for a hosting company and noticed how many of our users were enjoying it. Decided to go to WordCamp in 2008. The software was great, but the community was what really drew me in. I’ve been using WordPress in my career ever since then.

Ms. Velda

Made a WP website for a friend, then another, then someone who paid me… Today is 6 years and 120 clients later.

Sara Dunn

#WCSEA and specifically @adspedia reminded me that WordPress is about the inspiring people I meet at so many occasions. Beautiful minds & souls who inspired me to build a new and better life 2 years ago. It’s way more than software and individual ego.

Carole Olinger

I started by own consultancy doing WordPress for nonprofits straight out of college. Somehow, I’m still here and still loving it almost a decade later. Meetups and WordCamps (#wcsea!) were so crucial to my learning, developing as a speaker, and networking.

Mark Root-Wiley

I started working with #WordPress in 2012 after my business was sold out from under me by a ‘partner’. I ended up losing everything. Developing WordPress sites contributed to getting my Family out of debt, back on our feet. @Mor10 you’ve been an inspiration along the way…

Damian Saunders

There’s always a lot happening in the WordPress ecosystem and every once in awhile, it’s nice to step back to see how this software, which is used by millions of people across the world, is impacting lives.

I highly encourage you to read the thread in its entirety.  If you’d like to read similar, more in-depth content, check out HeroPress. HeroPress publishes inspirational essays from members of the community once a month.

Read the whole story
Share this story

Erealitatea[.]net Hack Corrupts Websites with WP GDPR Compliance Plugin Vulnerability

1 Share
Erealitatea[.]net Hack Corrupts Websites with WP GDPR Compliance Plugin Vulnerability

We have noticed a growing number of WordPress-based sites that have had their URL settings changed to hxxp://erealitatea[.]net. Further investigations show that the issue is related to a security vulnerability in the WP GDPR Compliance plugin for WordPress (with 100,000+ active installations).

The new General Data Protection Regulation (GDPR) laws in the EU have made the plugin extremely popular. Many sites are looking for an easy way to comply with these new laws, and adding this plugin is a simple solution for many website owners.

Continue reading Erealitatea[.]net Hack Corrupts Websites with WP GDPR Compliance Plugin Vulnerability at Sucuri Blog.

Read the whole story
Share this story

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

1 Share

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.”

Read the whole story
Share this story
Next Page of Stories