In the wake of the recent release of the Gutenberg accessibility review report, we need to revisit the Gutenberg Editor vs ClassicPress project.
I wrote an article last year covering my journey learning how to develop blocks for Gutenberg. It detailed the various investments I had done to prepare myself for the upcoming Block Editor. Fast forward to today, I can write a few basic blocks in React JS but with some difficulty. However, this is highly affected by the long time period taken to make a block compared to what is needed in the ordinary PHP, HTML,CSS and JavaScript (JS) component development process.
It’s an ambitious project led by Automattic (the For-profit version of WordPress) to change the WordPress TinyMCE editor to a more modern Javascript based blocks editor that mirrors what is in the back end to the front end with minimal (if not no) changes in style. New blocks such as Paragraph, Image, or Headings built with React JS now make it easy for users to write semantic HTML and styling without knowing what’s behind the block, instead using a click and drop approach.
Challenges Gutenberg/Block Editor faced
In as much as Gutenberg has its huge wins, it has/had some blemishes with its development and conceptualization into core.
GPL Licensing issues
In the initial stages, React JS had a MIT license that conflicted with WordPress’ GPL. However, Facebook quick resolved this by changing to GPL. I must say Facebook got the better deal since this will drive React JS to being used in the 32% (+/-) of global websites currently running on WordPress. This step allowed for Gutenberg as a project to grow even in the midst of the other rising issues that came up within the WP community.
Ever changing Block Editor API and Stagnant Documentation
The block editor API kept evolving as a new technology. This resulted to so many things breaking over time and developers giving up on learning this piece of tech. In fact it is one of the reasons, I personally took a break from learning blocks development. Because of the changing Blocks API, the documentation kept changing and eventually died a death of a thousand blades. I am sure this will be rectified by the docs team soon. In the meantime, this does not allow developers to work with the new API if they are not part of the inner circle community or paying for premium tutorials developed by those who keep tabs with the blocks API development.
Accessibility downgrade
WordPress being a large community with the potential of setting global web standards, this new development was lacking and had taken some steps back in terms of accessibility for its platform users. The new block editor was a huge blow to a large part of of its user base such as people with disabilities, government agencies and places of learning with huge accessibility expectations like universities. Gutenberg missed so many aspects in servicing its users’ accessibility needs. This particular issue led to a huge split in opinion by the community to the point of the accessibility team lead, Rian Rietveld resigning and WPCampus leading efforts to do an audit on the Gutenberg project/block editor.
Long Term Support version
As humans, we sometimes get so comfortable and hate change or learning new things. Whatever the reason, developers were worried that Gutenberg was being included in the WordPress Core at a very fast pace. The argument was that the WP team was not giving the community enough time to migrate/teach the users on adoption of the new block editor.
The argument for a long term support (LTS) version is mainly because of the philosophy WordPress holds. The WP promise is that they will try as much not to leave anyone behind but provide support in terms of security and updates. With a major change coming in core, particular voices in the community like Morten Rand-Hendriksen vouched for a WordPress LTS version with good reason but it was not realized as WordPress had a different solution. That is, provide a classic editor plugin that disables the new block editor until 2021.
This became room for skepticism considering that there are a number of users who have not even upgraded their websites from version 3.x of WP. Of course, these can be bumped up by the web hosts like WP Engine is doing, to have all their WP users on the latest versions of Version 5.x.
What if I just want to keep with the TinyMCE editor and really hate the block editor. Maybe I find it hard to use or as a dev, I prefer using Vue JS as an option with no plans of learning React and other heavy Javascript Frameworks?
It’s the end of the backend as we know it.
I don’t want to be the “prophet of React JavaScript Doom”, however, basing on the past, I foresee the whole Admin section of WordPress becoming React JavaScript based. As this article is in writing, WooCommerce, one of commercial products of WordPress .com has released a JavaScript based backend for admins. It is in trial mode and I know this this will give good user data. This data can also drive JS admin plans for WordPress full JS backend. This change, if implemented, will mainly affect Developers who have not embraced or studied Javascript as deeply as Matt Mullenweg communicated in 2016 and 2017.
Phase 2 of WordPress Block growth is to move the navigation menu to a block and the widgets section will get the same treatment. In my view, eventually, the customizer will also be replaced in a bid to realize WordPress editing FrontEnd (my prediction). WordPress Front End editing is not a new concept as it has been tested in plugin form. Also note, one of the motivations given for the rise of Gutenberg was the steep competition with platforms like Medium and Wix. These platforms have majored in front end editing.
What does it mean for the users?
For the final content developer, it means learning which block does what. This is the learning curve that comes with small goodies like importing tweets, Facebook posts as citations etc in the middle of a post.
However, digging the pockets will be the biggest challenge for both the developer and client. Building a custom block takes time and skill. This will be a huge cost for the website owner as a charged passed on for time spent in coding as an hourly rate and as a payment for skills growth.
Equally, this will lead to huge costs for the developers to keep the users on WordPress if they are small businesses with specific needs instead of a basic website. They’ll also need to spend big $$$ to retrain their clients as well as regularly update their themes or plugins to be compatible with Gutenberg.
New or entry-level developers are going to be hit the hardest. Before, many new WordPress developers depended on platforms like stack overflow to pick up a snippet and paste to make a change. However, it will soon require a leveled up skill in JavaScript to do the same in WordPress.
Rush Gutenberg into WordPress core
Why rush it? This was the question on developers lips and fingertips as they rated the Blocks API as incomplete, evolving too quickly and thus unstable and not production ready. This was a good question and some conspiracy theories soon developed. These would later be strengthened as a huge investment of $1.2M was seen coming in from Google and other investors in the form of the newspack project. As a core function of the business arm, this is a good opportunity for Automattic to make some venture capital money.
Enter the WordPress alternative, ClassicPress…
With all of this going on, part of the WordPress community took a revolutionary action to build on the good they see in WordPress and grow that as a new platform called ClassicPress.
Scott Bowler kicked off the project with a handful of contributors (both dev and users) joining in. This would be the alternative to WordPress without Gutenberg and React Javascript as a main promise. This is the line in the sand! The team weighed the price of the challenges that WordPress was bringing on board with the new editor.
Keep ClassicPress democratic
The decision was first to fork version 4.9.x of WordPress without Gutenberg in its core and keep it long term support. This simply means the version 1.x will be kept as close as to the original WordPress version 4.9.0 while beefing it up with security patches. This would give time for users to evaluate whether to move to the upcoming ClassicPress versions with breaking changes.
Note that by 2022, the WordPress-developed Classic Editor plugin might be out of service and not supported or even get broken as Gutenberg/Block API evolves. On the other hand, ClassicPress Version 1.x will be for those who will be hit by the new WP 5.x tide and seeking redress in the near future.
While planning for the next phase for version 2.0 of the ClassicPress project, the team decided that it will be community driven. Any new changes and features, will be coming from the community as suggestions shared via the ClassicPress petitions platform.
How do the ClassicPress petitions work?
ClassicPress community decides the project’s direction. This means you just need to roll up your sleeves and write what you think is good for the project and share the idea with other members via a petition. Other users then get a chance to up-vote it or even throw technical/objective criticism to it. It is then adopted basing on its merits and the community will work together to build it via the open space on Github.
ClassicPress is driving the petitions concept a notch higher by installing a petitions dashboard widget in the core of the software to keep its users in the know of what is suggested, planned, trending and giving a platform for one to share.
Some of the ideas and petitions proposed by the community have been flagged for version 2 and discussions are in place for how to implement them e.g. remove XML-RPC (has many vulnerabilities but is used by many external applications). The idea is to push some of these once core functionalities into a core plugin that can be switched on and off easily by click of a button.
Security first ClassicPress
One of the core values of ClassicPress is to be security tight. In order to reach this goal, ClassicPress has already bumped up its minimum PHP version support to 5.6. This has brought about some speed increase in ClassicPress compared to WordPress and also allows ClassicPress to be more secure. Basing on usage by the community, ClassicPress will bump up the version to 7.0. This is also an idea from the community via the petitions as ClassicPress seeks to be security first and community driven at the same time.
What’s next for ClassicPress?
Version 1.x is already released with minimal changes to the fork of WordPress 4.9.0. ClassicPress needs to build its own plugins and themes repository as they currently really on the one owned by WordPress. However, this has not stopped a number of developers vouching to make their plugins compatible with ClassicPress and even write new ones. There are so many things ClassicPress wants to do which you can read about. You can follow the work on Slack, Github, ClassicPress petitions and the forums.
In my own opinion, ClassicPress has a specific market it serves. Yes, it is a fork (that’s ethical by the way) but it has potential to grow big on its own. It will be boosted by those looking for an option to Blockless WordPress / CMS.
Many other CMSes have since started adopting the block using the open sourced Gutenberg Cloud approach namely Drupal, October CMS and many more in the near future. This “purist” approach by ClassicPress will allow a lot of flexibility for PHP developers who want a minimalist, versatile CMS.
It is noteworthy, that this is not the first time and only time WordPress is being/will be forked. Other WordPress forks have soon died off while others like CalmPress, Publicious are still trying to bud.
Will ClassicPress walk the talk and expectations? I see the potential. What do you think?
Leave a Reply