ClassicPress quickly becoming obsolete? Let's fix that!

General Discussion
1

A concern that needs to be addressed soon.

Recently (In the last 6 months or so) there has been a trend towards no longer supporting WordPress 4.x. Initiated by Automattic as far as I can tell from their mailings. As a result MANY MANY plugins on wordpress.org now “require” WordPress 5.0+ even if they technically don’t - that’s in their readme.

This means that if you look for a plugin in ClassicPress today tons of (popular) plugins will claim to not work on it.

If this continues Classicpress will be dead in the water soon with no up-to-date plugins to extend it.

Likewise, with the onslaught of those ridiuculous blocks and now patterns. The theme market is pretty much doomed. I see no effort being made to onboard theme makers. Granted, I’m not involved in theme making so I’m not exactly in the loop either.

Anyway, without themes, Classicpress will be dead in the water soon as well.

Is there a plan or strategy about countering, or even fixing, this?

One way would be to try and attract theme makers that are disgruntled with Blocks and have THEM keep making themes aimed at Classicpress while attracting their user bases to move on to CP.
Everybody wins.

And for plugins. Perhaps CP should update in a way that it’s compatible with WordPress 5.0 plugins. This would extend the life of ClassicPress and remove the urgency of becoming obsolete for a few years.
I’m not very involved with ‘core’ development, but I can’t imagine this being very hard.

A good start would probably be adding the specific functions of WP5, and not just by copying them from the actual WP5, as that probably won’t work. But adding same name functions that do the same so that plugins can use it.
I’m not super looking forward to do this as I feel wholly inadequate for it. But if there is some effort being made I can surely assist in a bunch of places either with ideas/guidance or code.

If I’ve missed something in terms of discussion or documentation please link them below.
If there are ideas floating around to promoting Classicpress, please link them below.

As a community we probably could pull together and do something about it on a large enough scale for it to matter for Classicpress as a whole.
Though I’m not sure what. So some fruitful discussion is required I’m sure.

Thoughts? Ideas? Let’s hear it.

5 Likes
2

Thoughts: The premise of CP (from what I personally have gathered) is to NOT BE WP. and most specific, not to be WP > 4.9.x. So would not porting any(thing) other than security patches be OUTSIDE of the CP mission.

Themes would be a much deeper discussion wherein IMO CP could use a Theme Repo yet, from what I gather—again—is that CP is having a hard time getting someone/anyone to help out with Plugin Reviews which, is the key to growing a repo. You can mirror this talking-point as to the Theme Review discussion’s needs.

What [I] have been doing is taking OLDER WP themes (Automattic annual default themes) that are older than TwentySixteen and creating Child Themes for these. You will notice that even the oldest themes of theirs, like TwentyEleven* (which has some nice features BTW) are updated even to handle minimal Blocks and body_class functions. You should be able to remove most of these functions using __return false in a hook or build your Child Theme with and option to NOT LOAD certain greater-than 4.9.x functionalities.
*GitHub - tradesouthwest/elevenwider: Child theme for WordPress Twentyeleven theme built for ClassicPress Example 2011 child theme- For CP.

3

Like it or not but for all intents and purposes ClassicPress IS WP at the moment. And will be for the foreseeable future. Regardless of where devs take it. CP right now literally is WP.

That means that if most WP plugins move on and break compatibility the project fails. Simply because there are not enough CP specific plugins to even consider not using WP plugins.

Similar issue with themes. And even documentation to some extent.
Search for ClassicPress stuff and you won’t find much if anything at all.

As such bringing a basic form of compatibility from WP 5 to ClassicPress would probably fix that for the time being and gives cp the much needed time to make a difference and go in a different direction as planned.

That’s just simple logic.

At the moment there is this situation where many WP plugins and themes are still compatible and relevant enough so ClassicPress can use them to grow and eventually veer off into a different direction. But As I alluded to in my initial post, that window is closing…

2 Likes
4

Ensuring compatibility means including the block editor. CP was born to avoid it.
Seems counterproductive to adopt it now to “stay alive” as you suggest.
The only reason why CP is not compatible with WP is the block editor, full site editing and related stuff.

1 Like
5

Im not saying to add blockeditor at all.
Wp5 included a ton more new/changed functions and methods other than blocks.

2 Likes
6

I’ve actually started work on a compatiblity plugin to address that a while ago. Others apparently did so to, but if nobody wants to step up, I’m happy to help out and drop some efforts into it, aka a github repo, with releases :slight_smile:

cu, w0lf.

ps: might not get around that anyway, as I’ve started working on a light-weight fork of the “official” replacement plugin for the current standard PayPal payment gateway for WooComerce. It apparently is working only 50% of the time, and thus features abysmal plugin ratings … reminds me a bit of Gutenborg in that regard :wink:

1 Like
7

Actually, WP 5.0 was solely the block editor. Other enhancements were moved to future releases.

May '18 4.9.6 Privacy, PHP polyfills, TinyMCE 4.7.11
Dec '18 5.0 Block editor, code reorganization, JS translations, post labels, REST
Feb '19 5.1 Site Health, JS build, GB 4.8, multisite metadata, cron
May '19 5.2 Recovery mode, PHP min 5.6, GB 5.4, dashicons
Nov '19 5.3 PHP 7.4 support, admin a11y, GB 6.5 (block markup change), big image handling, email verify, date time changes
Mar '20 5.4 GB 7.5, editor fullscreen default, new blocks (social), gradients, menu custom fields
Aug '20 5.5 Plugin auto update, update plugin from zip, step 1 jQuery migrate, sitemaps, lazyload, block directory, patterns, template part variable parameters
Dec '20 5.6 Core auto update, app passwords, GB 9.2, step 2 jQuery update, PHP 8 support, batch REST
Mar '21 5.7 step 3 jQuery update, lazyload iframe, https migration, robots API, admin color update,resend password, GB 9.9
Jul '21 5.8 WebP support, widget screen, theme.json, template editor, plugin field for Update URI, drop IE11, GB 10.7 (site edit blocks, duotone)
Jan '22 5.9 site editor, block themes, nav block, global settings API, block locking, tax hooks, cap query, language switcher, PHP 8.1 support, GB 11.9

You can write some shim functions for blocks, but that’s about it. What else were you referring to?

8

https://developer.wordpress.org/reference/since/5.0.0/
https://developer.wordpress.org/reference/since/5.1.0/
https://developer.wordpress.org/reference/since/5.2.0/
https://developer.wordpress.org/reference/since/5.3.0/
And so on…

Loads of pages of changed/new functions in WP5 that are not block related, but ARE used by plugins.

Adding a bunch of these and perhaps dummy functions for others may increase compatibility in a meaningful way.

9

Developers CAN create plugins and themes for CP which would be compatible. All you really need to do is load a plugin or theme on CP FIRST, and then test it. If it passes then you CAN test it on WP but you just can not submit it to WP repo if it does not pass their review.

So maybe I am missing the point of obsolete since a repository for CP plugins already exists and hopefully the future would garner a theme repo as well.

Rome wasn’t built in a day. —unknown

3 Likes
10

Personally, I am creating a new theme for WP but I am making sure that it is compatible with CP (because I use CP).
The other theme I uploaded to the Repo WP is CP compatible.
Now I also have a plugin for CP in the works.
My question is whether it is appropriate to create cross-compatible themes or plugins, or to create a specific version for CP.
For example: in my themes, I have included some theme settings for blocks (which I hate, but that pro-block WP users may be looking for). However, it is clear that if I decide to put the theme in a CP repo, I would have to remove those features.

11

I don’t develop themes so just answering in regards to plugins.

You can check if the plugin is running on CP or WP and manage accordingly; however, you would need to be clear about what functionality was available in CP and which in WP to avoid confusing users.

However, I’d suggest that if the functionality between CP and WP is the same that a single plugin is fine even if the functionality is delivered in slightly different ways, but if the functionality differs between the two platforms, I’d have two versions.

12

Agreed. The plugin I’m developing, however, is intended for CP. It would certainly work with WP as well, but I decided not to care too much about compatibility with it.

1 Like
13

You wouldn’t have to remove those features. Remember that people can migrate from WP to CP, so that means they can have block in their content. Just as a WP theme needs to still handle classic content in addition to block markup, a CP theme can have styles that affect block classes. If the theme has settings specific to blocks, however, you might want to make those conditional on the $wp_version variable.

14

Don’t forget the ‘extra’ code CP users load and never use in a shared plugin/theme.
Ideally it’d be 2 plugins or themes if you’re including newer functions for WP.

I’m torn on that too for AdRotate (Pro), use newer functions in WP and replace them with CP compatible stuff.
But I hate the idea of people having to load a bunch of code they’ll never use.

But, if compatibility in CP would be extended and that extra stuff is limited to blocks or small things… Then that’d be much less of an issue :wink:

1 Like
15

Fortunately you don’t need to have users “load code they never use” (not that it would matter, actually, modern servers and PHP could probably load an entire App that is never used without even affecting any load time). You can use Best practice to detect a ClassicPress Install | ClassicPress Documentation to check if it is a CP install for example, and load your “CP only” code or not load “WP only” code depending on that.

However my plugins for example run on both WP and CP, and I never came across the need to separate the code bases. As long your plugin is compatible with WP 4.9, there’s no need to do this acrobatic exercise.
Of course, if your plugin is not compatible with that version of WP, it would probably just be better to not ship that plugin to CP/make another plugin that actually works with CP/WP 4.9

It is certainly not within our goals to start including either shims for blocks, or actual blocks related code.
Not only because the very core of CP is “no blocks”, but because it is useless to start with. Blocks will not work on CP no matter what.

As for the other new features/functions that WP has and CP does not, I rather would prefer we actually spend time maintaining security (which has been and still is honestly lacking, even if the parts that should receive updates are hard to exploit, or close to impossible, they are there/have been there way too long), and adding new features unique to CP or improving existing features, something that will actually distinguish CP from WP rather than making it a zombie-frankenstein-doppelganger of WP.

I would also like to reply to

Search for ClassicPress stuff and you won’t find much if anything at all.

We have a 100% covered documentation for CP at https://docs.classicpress.net/
The reason you can’t find results in google when searching, is mostly that this is mostly duplicate content and google of course will prioritise the original + the one that 50K users click on it, versus 1.
Another reason to actually start distinguishing CP from WP by adding new, unique features and not copy even more. That just gives us the image of the “copy pasta wannabes”.

There are unfortunately not many people talking about CP in their blogs or else, and that is the other reason you can’t find lots of contents or how to’s in the net. That, is entirely up to the community and its users (which as in any community, have a lack of contribution willingness and are not involving personally. This is just normal, and the only reason WP is so widely covered is that it grew to be a giant powering over 50% of the web probably. This happened because while WP Grew, it was basically the only viable solution, and probably still is, for noobs to devs. This may, or may not change in CP overtime. Not if we keep being the copy pasta folks, however, that much is sure.)

1 Like
16

I completely agree. I’ve been thinking about it: currently it doesn’t make sense to divide plugins and themes based on installation type. CP and WP are still overlapping, so it’s better to do a preliminary check of the type of installation on which you are installing the plugin (or theme). So far, however, my themes and plugins work for both. Implementing blocks (via add_settings, mainly) don’t stand in the way.

Just today I was reading that WP is implementing block themes (argh!) and has already made a distinction with “classic” themes. Now, this will probably imply (I haven’t read anything about it), a progressive abandonment of the traditional way of developing themes, and therefore the distance between WP and CP will become even more evident and irreversible.

It is clear, therefore, that CP will need new blood. I see it, unfortunately, in the scarcity of news about it (few bloggers actually talk about it), in the slowness of blog updates and script updates, due to the scarcity of developers available to collaborate. I, personally, would like to help in my spare time, but unfortunately I don’t know the dynamics and functionality of CP core to take on the task: I’ve always built themes and plugins (few in truth), and not even very complex, so my usefulness would be very minimal. For example: I made available on Github a plugin to create tables (to be used in the development of my plugins that required them) because I didn’t like the system created by WP and I found it complicated.

But it is certain that CP would deserve much more. It’s a project that has an ambition that I fully support: to keep simple what was born to be simple. Of WP it will be necessary to continue to take what is good (it would be stupid not to), discarding what is not, but it is clear that sooner or later CP will have to start walking on its own legs and acquire its own identity, otherwise it will die.

I’m going to write something in my blog about CP (I haven’t actually done that yet), hoping it will be read enough. The effort has to go in this direction: talk about CP and try to get people talking about CP. But it’s clear that whoever is “in charge” of the project, maybe should look for more visibility, even on social media. On Twitter, the last post is from 2021…

2 Likes
17

Facebook is continuously updated by me at least with releases. I don’t have access to other social media of CP, but I’d maintain at least the update notification, it does not cost much. About blogging, I used to write some blog posts about CP on my own site and also on CP itself and interestingly those are the only posts I even ever received comments to (on my site), so it is actually worth it. However that takes time.

I think us less experienced devs and users can help where we can. For example I provided a couple new features that made it to CP core. It was no big “whoa” feature, and anyone with little PHP knowledge can do such things. We need help in DOC writing, etc all shown here Currently Active Projects
Now also I’m setting up a testing project (see Release testing system | Help needed - #9 by ElisabettaCarrara) which is basically something anyone can help with - it needs basically no knowledge (actually the less experienced the better because it helps catching UX issues)

I think (no, I know) the main issue is like in any society or group: we do a lot of talking and not much action. This is unfortunately just normal. I believe Pareto principle - Wikipedia pretty much applies here as well.
So for example assuming we really have 5k users (we do not, but that is the number of sites that supposedly use CP), we would have roughly 1k “vital fews”
We do not have 1k vital fews, we have some perhaps 3 vital fews. That makes it 15 users. And that pretty much correlates to the amount of voters on polls, commenters on posts, and voices on releases. We rarely have more than 10 distinct voices.

So there you go. Does someone really want to develop a paid product for 15 active users? Nope. Not even a fool would do that.
Does someone want to contribute where they can because they want to, or because they require the project alive, or because they are fools? Yep. Perhaps, we should update our tagline again :rofl:
(note, this is not intended to offend anyone or complain - it’s just facts, and perhaps there’s a better word for describing “those who contribute to a project that has basically no safe future nor reward” than fools, but I couldn’t find any. “Courageous Pioneers” maybe :wink: )

18

I think the only way to “fix” ClassicPress and keep it relevant, is to move away from WordPress which would introduce breaking changes and make ClassicPress its own CMS.

This is the conversation for that:

5 Likes
19

Totally agree with that. WP 4.9.x was a good starting point, now take it from there. I also think linking to the WP plugins and themes from within the CP panel should be abandoned. It would be best to offer users of CP a similar experience with a CP repository to make it as userfriendly as possible. Most people don’t even know github exists let alone be “how this stuff works”. The KISS principle should be applied as far as I’m concerned.

6 Likes
20

I haven’t yet given up on my tutorial blog that is dedicated to CP. It’s in development, but it’s only a part of the writing business I’m building, and so the progress on it is slow, as I have so many other concerns.

1 Like