The future of ClassicPress?

General Discussion
1

I was with ClassicPress right from the start - big fan of the entire project. Forgive me if I’m treading familiar ground here.

What I would like to see happen with ClassicPress is this - keep up to date with WordPress releases in the following manner:
WordPress - bloat/gutenberg/jetpack/random-unnecessary features + additional security&features = ClassicPress

I completely understand the desire to branch out, create your own repos, plugin store etc. I get why that is important but as a business critical solution the number one priority for the CMS is security shortly followed by speed. WordPress is clusterf*ck in general of just a jumble of unneccesary features but to forgo cutting edge releases is frankly just a waste. Auttomatic is probably a billion $ company with some very talented individuals under their wing, it’s just not prudent to forgo the latest developments. Some of which are actually useful, not to mention ensure maximum plugin compatibility.

Further if you could get rid of the “wp” text domain that would be a major help, since that’s what most botnets are looking for. (with some sort of plugin convertor :man_shrugging: ) How these botnets find strictly non-indexed sites is really still a mystery to me, if anyone knows why please kindly explain.

A leaner stronger more independant wordpress is what i believe should the aim for ClassicPress. The app store, api etc. are fine and well (although I will say I’m not a fan of being tracked in any form) but really should be on the periphery of priorities here.

I understand this is a hard fork but I just can’t see all that much value in fixing things that aren’t broken. It’s just a slippery slope.

1 Like
2

Welcome @aenon!

We do this already, you can see the current pending backports on GitHub. @james can likely talk more to this though.

We can only do this for plugins on WP 4.9.x, anything else breaks compatibility. That is just the nature of not including GB.

This kind of goes hand in hand with the above comment. If we do this we break compatibility.

As a lean team, everything we have done to date is focused on what will get us the biggest bang for our buck (for a lack of better terminology). We needed the API to push updates, can’t push updates without it, so that was a priority. The plugin store is necessary as it will start an eco-system as we continue to diverge from WP.

So welcome, it sounds like you may be in the right place, take a look around and see what we are about :slight_smile: We are all here to answer any further questions/comments you may have!

6 Likes
3

Hi @aenon - thanks for taking the time to post.

I think ClassicPress is already almost exactly the way you’ve described it above. Except for the “features” part in the first quote, which is being decided by a democratic petition process, rather than just whatever WordPress decides is a good idea for its users.

4 Likes
4

Thanks guys for getting back to me.

That’s great to hear - sorry based on the website and information I could see it wasn’t clear wether you are keepin CP up to date with the latest core WP releases.

Right I understand I assumed this was simply to push CP further out of the WP ecosystem.

This explains why an independant plugin hub is important.

You know the issue that I now fear is that as time elapses the split between modern WP and CP will just get wider - I suppose that’s ultimately the point hence the “Classic” title, but I find it unlikely that a large majority of developers will keep a CP version of their plugin. I mean if we are already seeing compatiblitilty issues at this point I don’t think this bodes well down the line especially if what Automattic are saying about GB are true. They are touting this as the central axel to build from and based on what I’ve seen from their beta products and design tests it does seem to be the case.

Currently I’m using the latest WP with the classic editor plugin. This means GB is still baked into the core code but prior to this it was plugin - would it be possibly to split this again?

Is there not some scenario where you could add the the most neccessary components of GB to ensure future compatibility?

4 Likes
5

I think that would just end up getting incredibly messy and increasingly complicated. :exploding_head:

This is, of course, the big issue. Especially now as we are seeing more plugins saying they won’t support below WP5. Everyone has their own favourite set of plugins and they want to keep using them (or something very similar) on ClassicPress. It’s why I created the “must-have plugins” wiki… to try and get a feel for what was needed and keep track of the options.

Personally, I think having >50,000 plugins to choose from is ridiculous, and a recipe for all sorts of potential security issues. What I would like to see is a small set of essential, well-written and well-maintained plugins that we can feel confident about using. We are working towards this with recent progress on Classic Commerce and Classic SEO. It’s a matter of filling gaps as they appear.

3 Likes
6

The plugin directory is essential for both of these.

The number one security issue for CP/WP is plugins, and the one thing we still rely on from WP is their plugin directory.

5 Likes
7

I completely sympathise with your conundrum here. And again emphasis is on this being a hard fork but my primary draw towards this project is that its “Wordpress without the Nonsense”. The primary advantage of Wordpress is it’s vast ecosystem and whilst I agree that that’s not always a good thing it’s reassuring to know that if there’s ever a new popular service there’s a 95% chance they’ll have a first party or third party integration for WordPress - it’s almost become industry standard and for good cause.

From what I can see ClassicPress will under the current methodolgy really go on to become it’s own thing. I can’t Imagine WP 6 being any less drastic the 5.

What that means in cold hard terms is more time/costs relative to development. Then your almost left thinking how ClassicPress benefits me more than say Drupal. Drupal being traditionally far leaner, securer and faster than WP (by significant margins).

And I take nothing away from your efforts, I really really want you guys to suceed here. I think your Must Have plugins list is a fantastic idea but it’s never going to tick all the boxes. I really think you should open up this compatibility discussion with the community to canvas opinion on what the collective sentiment is towards this issue. Personally I don’t feel fixating the entire future of this project on version 4.9.x is the best solution, what we or at least I want is to retain the 4.9.x functionality/feel with guaranteed future compatibility. Kick all surplus items to the curb but mantain all the essential components, this way I can really see CP gaining much greater traction and becoming a real choice as opposed to the only choice because we’re stuck in a certain way of doing things.

2 Likes
8

This is where the primary issue lays.

Guaranteed compatibility ultimately means you lose the 4.9.x functionality/feel.
While retaining 4.9.x functionality/feel loses the guaranteed future compatibility.

Sadly, there is no way (that I know of) to have it both ways.

As with everything we do, every decision we make is ultimately driven by the community. That is why our first section below the header on the home page on the main website (but still above the fold) is “Community First”. If we saw a majority of users wanting to adding GB related stuff to ‘guaranteed future compatibility’, then we would. That is the great thing about being democratic.

7 Likes
9

Time and cost relative to whom? Trying to follow WP would be a nightmare for the CP team, since we’d have no power over where WP might go, but would be taking on all the responsibilities of remaining 100% compatible. I’m afraid that’s just completely unrealistic.

5 Likes
10

Relative to anyone trying to keep plugins and intergations up to date. It’s fair enough to make a fork or your own custom plugin if you have a large enough team to mantain and audit it, but in any scenario it just adds additional overhead. It also means cutting off from the WP ecosystem, if not now but eventually.

I was under the impression that maximum compatibility was the central feature here, really thats where my confusion stems from.

But shouldn’t the aim be to keep parity with WP core whilst removing all of the undesirable features ala. keeping it looking/working like Classic Wordpress.

I can’t see why that has to be the case isn’t that part of the overall challenge here?

11

I think your confusion stems from what it is you think we should maintain compatibility with. Version 1 of ClassicPress was built on the fundamental basis that it should maintain compatibility with WP 4.9.x (with the exception that we required PHP 5.6+ to improve security a little). It’s essentially a safe haven from WP 5.x while we all catch our breath.

At no stage have we said that we would maintain compatibility with WP 5.x because we have no idea where that might lead. We aren’t interested in breaking compatibility with WP 5.x just for the sake of it, but it is going to happen because we don’t control WP. After all, the reason for creating ClassicPress in the first place is that WP went in a direction that doesn’t suit us. It would be very strange if we then committed to saying we would still follow WP wherever it goes.

The aim of ClassicPress should be to do what our community democratically decides it wants. Speaking for myself, I don’t want it just to keep “working like classic WordPress” because, even if WP 4.9.x, there are lots of things that aren’t so good. Improving upon them will almost certainly break things — unless WP decides to follow us.

5 Likes
12

Agree 100%. That’s not why I’m part of the ClassicPress community. I have zero interest in ClassicPress just being “WordPress without the bad stuff”. We have an opportunity to make something much better than that and to me, that’s what CP is all about and that’s why I’m here.

6 Likes
13

Very similar feeling here. With ClassicPress, we have the opportunity to do what WordPress never could, start shedding the Technical Debt of Yesterdecade™. When you consider what a fork actually is (where a piece of software takes some often-major convergent turn,) it’s actually WordPress that is the fork. ClassicPress is what the community has longed for, for probably a decade now.

I know there are some die-hards who would never convert, but, the ones I really feel for are those being tricked into thinking the Classic Editor plugin is the solution. I suspect when that plugin ceases, we’ll have a surge of registrations over here.

5 Likes
14

The way we get to “a leaner, stronger, more independent WordPress” is as follows:

  • Build our own API so that we can serve updated versions. This was done with v1.
  • Build a plugin directory and start moving less-used features out into plugins. This is already our roadmap for version 2, and it was decided months ago based on community input (top freature requests, etc).
  • Continue improving and hardening security where possible. Backward compatibility is an important concern here, so we are also looking at encouraging developers and users to act differently than they do with WP, for example, using small, single-purpose plugins, and making security settings more easily auditable.

So, I’d argue that actually we are already headed down this path:

Now we can talk about keeping up to date with more recent versions of WordPress.

This is an accurate summary of the current situation. I’ll add that we do of course merge and release all WP security fixes quickly (technically this is actually part of keeping compatibility with WP 4.9.x though not many people realize it).

Generally speaking there’s no problem with backporting specific, minor changes and fixes from WordPress, but each change needs someone to justify and explain it, as well as see it through at a technical level once we’ve agreed it makes sense for ClassicPress to adopt the change.

There is a bit more information about this in our Contributing Guidelines for the main code.

As far as major changes in recent versions of WP, they need to go through our regular process for major changes, i.e. starting with a petition. The “Site health” screen is a recent example of such a change. There is a petition for it but so far this has not gotten much interest from the community.

As above, we need to be more specific here. What specific changes are useful and worth adopting for ClassicPress’ current community and needs?

For each such change the following process needs to be followed:

  • Is it a major change? If so, create a petition.
  • For minor changes, create a GitHub issue or pull request explaining the change, links to relevant information from the WP issue tracker and code etc, why it makes sense for ClassicPress to adopt, and how it has been tested.

Many botnets just look at all active domains, without bothering to check whether they are WP or not, and they certainly don’t bother to obey robots.txt or other indexing guidelines.

Changing e.g. wp-admin to cp-admin would break a huge amount of plugins and other code, so that is basically a non-starter for the foreseeable future. You’re welcome to do this on your own sites but there will likely be a lot of plugins that need modification also.

We could look at (for example) changing the way the login page sends its parameters, but this would be a separate topic that is better suited for a dedicated petition.

6 Likes
15

Thanks guys for all of the updates. I’m beginning to get a much clearer sense of the mission of ClassicPress.

I tested it with woocommerce 3.7 which worked fine but it broke when the new woocommerce admin interface was added (which itself is in early beta).

Now if we take WooCommerce and its ClassicPress equivalent as an example.

Wouldn’t we be better served if we added the parts (compatibility components) that are missing for the wc-admin instance for example as opposed to trying to recreate it as a seperate plugin?

Plugin compatibility is need dependant, one of the great things about wordpress is that almost any feature you can think of exists out there in one form or another.

Perhaps a solution to the compatibility conundrum would be to create more extensive documentation explaining what might be missing and how to add it in order to retain compatibility. That might become insanely complex or long winded but I would hate to see CP lose touch with the rest of the wordpress community. I think of tools like the various booking plugins etc. which might not be widely used tools meaning little community support but mission critical for certain business’s.

2 Likes
16

If I were to answer this in a single sentence it would be something like “no, getting the issue fixed in the plugin or forking the plugin is usually easier”. However this is a complicated question so I’ll try to unpack it a little more.

Our current stance is that as a ClassicPress user you should be using plugins that are known to work with the WordPress 4.9 release series. This is consistent with what we do in the code and how it works with plugins - we set $wp_version to 4.9.x and lots of plugins check this to know what features are available for them to use.

If we start adding major features from later WordPress versions, what should we set $wp_version to? We can leave it as 4.9.x, in which case that is no longer strictly accurate, or we can set it to 5.x, in which case lots of plugins will start thinking that Gutenberg is available. Either way we risk breaking things.

Also important: what are these compatibility components specifically? This answer is different for each case, and so the best solution is different too. I suspect that for WC the missing pieces are Gutenberg-related code, which would be a nightmare (on several different levels) to package up into a form that is suitable for ClassicPress.

We also see cases where plugin authors release a new version but don’t test it with WP 4.9.x and it breaks something, even though 4.9 is in their range of supported versions. Often they fix this themselves after some prodding.

For now, it seems that the best general solution is still to use plugins that have kept compatibility with WP 4.9.x. For Yoast and WooCommerce specifically, we know that isn’t going to happen, so we have alternatives that are under active development by the community.

I’m happy to look at specific cases of other plugins also, but in general we need to know as much as possible about why, specifically a plugin is incompatible with ClassicPress and WP 4.9.x.

10 Likes