I think adding a switch should be based on the feature’s intended users.
- Application passwords (developers) - use a filter to enable it. Can be left enabled. Plugins that may need it should be able to enable it, something similar to
add_theme_support(). Enable it if plugin/theme declares support for it. - Automatic webp generation (users) - add a checkbox to enable it under Media settings.
- Sitemaps should be left as is. They are important and with Classic SEO unmaintained at this time, that’s good to have.
- Site health should be left as is.
- Error recovery should be left as is.
Anything else we’re missing? We don’t have to decide every feature’s fate at this point. We may come up on a feature we want disabled or add a switch while working on the fork. At that time we can figure out what the best option is.
Since it’s a major version, I would recommend dropping official support for PHP 5.6. It may still work, but we shouldn’t waste our time chasing it. Any issues coming up with 5.6 will not be fixed.
Our primary focus should be the removal of blocks and JSON themes code. Any additional changes should be made after unnecessary code has been removed. Mixing things will cause problems debugging issues.
@MattyRob do you think we should proceed with your approach, applying changes one file at a time? Or should we take Alvaro’s WP-CMS, ensure blocks and JSON theme code is removed, and then begin applying any CP related stuff?
You’ll know better than me, but from my end, it seems that using WP-CMS as a starting point and making it into CP would be more efficient:
- We don’t have to remove any CP features we’re not keeping, we just bring in what we want.
- All the docblocks are already back to the original WP docblocks, so we can add CP stuff.
- Blocks (and maybe JSON theme) code has already been removed, so we just need to check if anything else is left.
Is there anything I’m missing?
As a side question, should we drop composer.json? We are listed on Packagist, but I’m not sure if we have access to that account.