Gary Pendergast announced this morning that the Classic Editor plugin will be officially supported until December 31, 2021. The plugin eases the transition for sites where plugins or themes are not yet compatible with Gutenberg and gives users the opportunity to preserve their existing workflows.
“Since the Classic Editor plugin is central in this transition, we are considering including it with upgrades to WordPress 5.0,” Pendergast said. “New WordPress installs would still add it manually, and we’ve included it in the Featured Plugins list to increase visibility. If you have thoughts on this idea, please leave a comment.”
Pendergast clarified that “officially supported” means that the plugin “will be guaranteed to work as expected in the most recent major release of WordPress, and the major release before it.” He also said the project will evaluate the continuing maintenance of the plugin in 2021 and may possibly extend the date.
The post has already received quite a bit of feedback and generally positive reactions to the prospect of including the Classic Editor along with 5.0 updates for existing sites.
WordPress Core Committer Pascal Birchler asked for a clarification on what “we” referred to in Pendergast’s post, and Pendergast clarified that he is speaking on behalf of the WordPress project. Other commenters pressed for more information, as the announcement was delivered as something that had already been decided and the conversation surrounding the decision was not public.
“I’m grateful for the communication on a hard date for support of the classic editor,” Darren Ethier commented on the post. “It helps many people depending on WordPress for their livelihood to make plans surrounding things depending on it. But for volunteers who ‘show up’ at meetings and in contributing, the process for arriving at these kinds of decisions in an open source project is very opaque and seems to be increasingly so.”
This announcement highlights a trend in recent decision making for the project where decisions on important items appear to have been made behind closed doors without community input. Matthew MacPherson’s proposal for an independent accessibility audit, which had broad support from the community, was shut down in a similar way. MacPherson was named WordPress 5.0’s accessibility lead but didn’t seem to be fully vested with the power to lead that aspect of the release in the community’s best interests. I asked MacPherson if he could further clarify how the decision to forego the audit was reached, as it seemed even a surprise to him in the GitHub issue thread. He said he had “no comment” on how the decision came about.
WPCampus is now pursuing an accessibility audit in order to better serve its community of more than 800 web professionals, educators, and others who work with WordPress in higher education.
“We’re receiving a lot of interest and I’m holding meetings with potential vendors to answer their questions,” WPCampus director Rachel Cherry said. “We’ve received a lot of messages from individuals and organizations wanting to contribute financially.”
The recent report from the accessibility team demonstrates critical issues that prevent the team from recommending Gutenberg to users of assistive technology. These issues also have a major impact on those using WordPress for higher education, as the law requires them to meet certain standards. Several in this particular industry commented on Pendergast’s post to advocate for shipping the Classic Editor plugin with new installs as well.
“Many organizations who use WordPress are required by law to provide accessible software under Section 508,” Rachel Cherry said. “Until such a time when the accessibility of Gutenberg has been improved, and Section 508 compliance is clear, these organizations will require use of the Classic Editor.
“Not to mention the users who will be dependent upon the Classic Editor to have an accessible publishing experience.
“Please consider bundling Classic Editor with all versions of core, new and updated, going forward so that every end user has the easy and inclusive option of using it from day one.”
Elaine Shannon, another WordPress user who works in academia, also commented on the Pendergast’s post to recommend having the Classic Editor bundled with new versions of WordPress, due to many education sites running on multisite installations.
“Some institutions are on managed hosts, where they’ll receive 5.0 without initiating the update themselves,” Shannon said. “Others are managed by on-campus IT services, where one campus admin will push the update and affect thousands of users. In many cases, these are MultiSites where end users – the ones who need the choice of whether to use Gutenberg or Classic Editor – do not have the ability to add a plugin. So regardless of whether these users are in a brand-new shiny install or just an updated existing one, many users are going to need to fall back to the Classic Editor, and if it’s not bundled with Core there will be some folks left having to contact their administrator.”
Pendergast’s post said the WordPress project is considering including the plugin with upgrades to 5.0 but did not identify where or when that decision will be made. However, users who depend on the plugin now have a clear idea of how long it will be supported.
“As for the EOL on Classic Editor support, that’s probably more clarity than [the core team] has ever really given on a feature-to-plugin transition and I’m in favor of having that hard date,” WordPress core developer Drew Jaynes said. “It sets the right tone that the plugin is not intended as a long-term solution, rather a stopgap with a definitive EOL.”
Mmmm. Why do I keep sensing a terrible amount of BS around this whole topic regarding the current editor and the fact that we need to use a plugin to keep using it when, in fact, a simple filter in the functions.php file of a theme can be used to keep using the current editor?
Classic Editor is actually extant in WP 5 and so therefore by extension the filter to turn on and off the block editor to get to it could be controlled by a switch in te writing settings of WordPress. It’s very frustrating as a user with specific requirements to see how clumsy all this is being implemented. I ultimately would like to use the block editor at some stage down the line when it better fits my workflows, but not yet. Not till it is more useable.
Perhaps somebody from WordPress could illuminate me as to why it is necessary to have to use a plugin to use the current editor. Why do they feel that they have to be so controlling in how, when and which editor should be used?