Discussion: What is ClassicPress' philosophy regarding breaking changes/enhancements?

[mikeschinkel]

A lot of the things I would personally like to see improved in WordPress work turn into a breaking change.

A very simple one, for example, would be to remove the call to require wp-settings.php from wp-config.php and instead call it at the end of wp-load.php thus allowing other PHP tools to load /wp-config.php, but this would be a breaking change.

So in specific to this (type of) idea, and in general for other ideas, what is the philosophy of ClassicPress in terms of it alignment or convergence with WordPress over time?

[scottybo]

Speaking personally (and unofficially) I think it's inevitable that breaking changes will be introduced as we forge forward with implementing the needs and desires of our target audience (businesses) - the general consensus is that v2 of ClassicPress is when we'll start to see breaking changes and I hope by the time we get to that point we'll have reached critical mass and are at a point where it's beneficial for plugin and theme developers to be ClassicPress compatible.

I don't have all the answers on how we'll reach this point, but my personal viewpoint is that if we keep doing what we're doing (working hard as a community to solve problems) we'll overcome any roadblocks that come our way.

[Mte90]

Will be better to have in wp-config only settings and not code (and I am not sure if that change will break wp-cli).
Anyway right now we didn't planned anything because we are working on 1.0 that is a LTS version.
I think that plus of ClassicPress is the compatibility with wordpress so remove that can create a problem but we will see after that release.

[mikeschinkel]

Will be better to have in wp-config only settings and not code

Not sure I agree with that, at least not in its entirety. There are a lot of scenarios where the configuration for my projects change based on different logic in /wp-config.php, so even if .env files were used there would still be a need for a PHP file that could modify those configurations before they are baked into stone with define().

Also, what I am proposing is a trivial change that would require (almost?) no discussion as to how to implement, and could provide immediately benefits, and then later we could architect the "perfect" solution.

IOW, don't let the perfect be the enemy of the good. I will add this idea as a proposal as soon as aI get the chance.

(and I am not sure if that change will break wp-cli).

Ironically, one of my reasons for wanting this is to empower tools like WP CLI to more easily load configurations and not have to just through so many hoops.

But even if it breaks WP CLI's current implementation it would be trivial to add if defined('WP_CLI') logic to do it the WordPress way as a special case.

[nylen]

Hi @mikeschinkel!

First of all, ClassicPress is following the semver versioning scheme. You're probably aware, but this means that in the 1.x.x release series there can be no breaking changes from 1.0.0.

So what does the 1.x.x release series support? Basically, as close as possible to full compatibility with WP 4.9.x. If a plugin or theme works in WP 4.9.8 then it should work in ClassicPress 1.x.x too, with no changes.

There are a couple of exceptions though. To get some idea of how we can handle breaking changes, let's look at the breaking changes we've already introduced when moving from WordPress to ClassicPress 1.x.x. There aren't many:

• PHP version must be at least 5.6
• wp_http_supports( array( 'ssl' ) ) must return true, indicating that the site is capable of making outgoing requests using SSL/HTTPS (we're going to require that all communication with our API happen securely).

We've implemented checks in the migration plugin to block the migration if these conditions are not met. Here's an example of such a check failing:

Applying this same concept to ClassicPress v2.0.0 where we may have some breaking changes, ideally we'd add an automated check for each breaking change, and put it in the upgrade path so that the upgrade is only permitted if we think the site will continue to work on the new version.

Now, back to this specific change.

remove the call to require wp-settings.php from wp-config.php and instead call it at the end of wp-load.php, thus allowing other PHP tools to load /wp-config.php

• What kinds of sites will this break?
• Is it possible to detect this breakage automatically?

For this specific change, I'm not sure, but I think this is an exercise we'll need to do for each potentially breaking change. What that looks like will of course depend on the breaking change and whether it's possible to check for breakage on a given site.

I also think we should look for other ways to achieve the same goal that are not breaking changes. For example:

add an environment variable like CLASSICPRESS_PARSE_CONFIG_ONLY that causes wp-settings.php to exit immediately, instead of continuing with the load process

I think this would achieve the same goal of "allowing other PHP tools to load wp-config.php", do you agree?

Another benefit of looking harder for non-breaking ways to achieve goals like this is that we can make changes like that prior to our v1 final release.

Hope that helps, happy to discuss more if you have any questions.

[mikeschinkel]

@nylen Thanks for the details.

I am thinking I really should split this into a 2nd ticket to discuss the specifics of /wp-config.php and leave this as a ticket about ClassicPress philosophy. I assume you agree? If yes, I will create a new one and copy over the relevant comments from you and @Mte90.

[nylen]

I am thinking I really should split this into a 2nd ticket to discuss the specifics of /wp-config.php and leave this as a ticket about ClassicPress philosophy

Yep, that makes sense to me. Thanks!

[BenOvermyer]

@nylen Agreed on the point about 1.x.x adhering (mostly) to WP 4.9.x.

For my part, I'd love to see ClassicPress 2+ break/improve as much as possible around QOL for operations concerns. WordPress is something of a nightmare to maintain right now. The wp-cli tool is absolutely necessary. Running WP in Docker is a bad idea at the moment, what with all the filesystem dependencies.

It'd be interesting to see ClassicPress become a 12 Factor App. That is definitely a breaking change from WordPress.

[nylen]

@BenOvermyer this sounds like a good candidate for petitions.classicpress.net along with some of the "why" and some of the specifics of what needs to change.

[BenOvermyer]

@nylen Done: https://petitions.classicpress.net/posts/104/make-classicpress-a-12-factor-app-ish

[nylen]

Some more discussion on the forums: https://forums.classicpress.net/t/longevity-for-cp/180/17

Now that we have the forums, I think we can close this issue and retire the discussion label.

For reference, here is the subforum for discussion related to core development: https://forums.classicpress.net/c/core-development