Support for ClassicPress

Podlove Publisher
1

Hi to the team!

My name is Marco, and I am blind from birth. For years, I, like many other blind writers, journalists and podcasters, could use WordPress without major problems when interacting with the browser and assistive technologies like screen readers.

The problem

And then came the block editor. It has a whole sleve of problems, many of which are also documented in at least one audit that was made two years ago, and many of whose problems have not yet been addressed. Moreover, new features usually bring with them new accessibility challenges.

For now, many help themselves by hanging on to the Classic Editor plugin. But Automattic have announced that they’ll discontinue this plugin by the end of 2021, and it is then only a matter of time until the block editor will be the only editor option left in WordPress. And unless Automattic change their stance on accessibility and stop treating it as an afterthought or “design hindrance”, this means that WordPress will no longer be feasible as a publishing platform for blind authors and other authors with special needs.

Enter ClassicPress

In the past week, through a tweet from a friend, I discovered ClassicPress. ClassicPress is a fork of WordPress 4.9.8, which was the last full release without any trace of Gutenberg. The fork had its 1.0 release in early 2019, and since then has kept up with all security releases of WordPress 4.9.x, and also has put in a few other enhancements, like a dedicated security section plugin authors can use to group together especially the security-focused options. It is purely community driven and has a democratic process for feature development.

Excited, I tried it out and found a very familiar and comfortable environment with an accessible editor. It is currently missing some other accessibility enhancements in the admin area, but I started backporting these.

And now to my question

I read in the announcement for version 3.0 that the minimum required WordPress version is 5.2. That would make ClassicPress and Podlove Publisher not match up. The questions I have are:

  1. What specific features of WordPress 5.0 to 5.2 are being used that require this WordPress version? Is it mainly PHP 7.0, a version that ClassicPress also runs under and is even encouraging users to migrate to?
  2. If that’s the case, would the team be willing to include ClassicPress support in the Podlove plugins? Or are there other critical features missing from WP 4.9.8 and ClassicPress 1.2 that would make this very difficult to do? If it is only a few missing functions that are not reliant on the block editor, perhaps these could be backported to ClassicPress to make it work?

I fear that Podlove could become unavailable to the blind podcaster community once the Classic Editor support goes away, and a migration to ClassicPress is the only option to continue using a WordPress-like environment for publishing.

Would the team be open to adding ClassicPress support to the Podlove family of plugins? The ClassicPress team have published a guide ClassicPress for Plugin Developers that shows how to find out when running in ClassicPress and how to use the new Security admin section I mentioned above, among other things.

The community is small, and dependent on popular plugins to support ClassicPress to help it grow. And in the case of me and my fellow blind publishers, be able to continue using it at all, too.

Thanks for reading!

Marco

2

Hi Marco,

I don’t think there was a specific reason to set the minimum to WordPress 5.2. I’m likely using some WordPress methods that require 5.0+ but I’d be surprised if they are critical. My assumption is that supporting ClassicPress should not be a major effort. I’d appreciate if someone would try it out and report issues if and when they are encountered.

Regarding PHP requirement: that looks to be fully compatible. We require 7.0+ now but that’s not conflicting with ClassicPress.

1 Like
3

Hi Eric!

Awesome! I got curious and installed the beta zip of 3.5.beta8 on my ClassicPress playground, and so far everything seems to be working. Haven’t actually anything to publish ATM, so haven’t tested all the things yet.

I then got curious and ran the 3.4.1 release plugin through Plugin Doctor - WPSeek.com. It shows only one function that is newer than 4.9, 4.9.6 to be exact, and that is the get_self_link() Function. It is used in some atom feed related work in feed.php.

I then checked the web player plugin, and that has one function that requires WP 5.0: register_block_type(). That sounds a lot like for the block editor.

The Subscribe Button plugin has nothing that is newer than WP 4.7.0.

So the question is, since you recommend WP 5.2, do you have a guard against the get_self_link() usage in place for the publisher, and same for the register_block_type() in the player? Or would it be difficult to add such guards so stuff at least doesn’t crash or so? I haven’t looked at the actual source TBH.

But anyway, I’d say this sounds encouraging for ClassicPress support.

4

@ericteubert Hi Eric, was my above reply at all useful to you? Or did I just uncover the tip of an iceberg that looks to be much larger, e.g., much more complex, than these two functions?

5

Yes thank you, that does sound like it would be rather easy to support at the moment.

Is there anything specifically to mark a plug-in as classic compatible other than lowering the WP version requirement?

6

According to this chapter in the "ClassicPress for plugin developers), tagging with ClassicPress when submitting a compatible version to the WordPress plugin directory, and introducing it to the ClassicPress Plugins forums section are two ways to make support discoverable. And of course, the conditionals for if ClassicPress is detected, and maybe then use the Security section as outlined further down in that document, are the ways to go.

And maybe a guest post on the ClassicPress blog as well, as suggested. Finally, of course, once it is up, submit to the ClassicPress plugin directory as well. However, that is currently still in progress, as indicated.

7

Sounds good, I opened an issue for it on GitHub: https://github.com/podlove/podlove-publisher/issues/1209

8

Hi MarcoZ!
I have used for a month the Podlove Publisher 3.6.1 to get an accessible audioplayer, on my site using ClassicPress 1.31. Because it is so difficult to find a WP mp3-player plugin that is well accessible with keyboard for screenreader users, included fast back and forward. It means that I do not need the podcasting function now; just the playlist got via episodes. I began testing also the feed through WP plugin “podcast player” (by vedathemes). So far all have worked well.

9

Hi all :slight_smile:

I have tested ClassicPress 2.3.1 and it looks like it works with the Podlove-Tools.

Thank you :slight_smile: