In the wake of the recent release of the Gutenberg accessibility review report, we need to revisit the Gutenberg Editor vs ClassicPress project.
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.
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.
It’s the end of the backend as we know it.
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.
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.
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?