Forking WordPress - brainstorming / collection of thoughts on how to do this

fork-wordpress-we-must.txt

Agreeing with https://www.danhendricks.com/2018/02/wordpress-fork/ .. and quite a few others: Gutenberg is the end as we know it (of WordPress). IMHO the beginning of the end is called "Theme Customizer". A half-broken, badly documented implementation of quite good idea. Customizer Changesets (formerly known as "Transactions") arrived just a few versions ago, while it should have been part of the Theme Customizer from the very start. And the list goes on .. but that is not the purpose of this document.

Let's start something new, with the old. Fork WordPress, before its too late, to avoid Gutenberg, the shallow try to turn WP into something like Squarespace or Wix.

My personal suggestions are:

- Fork WP 4.9.4
- Backport anything worthwhile that arrives in 5.0 (security fixes, useful UI improvements etc.)
- Make a lot of hardcoded, baked-in stuff optional, or at least add options to disable them
- Prepare a compatiblity layer to enable most existing plugins to continue working properly with this fork, too

1. Fork WP:
- create a github group and invite all interested parties
	- give it a nice work title, eg. "The WP-Forking Group" or something
- create a github repo and just include WP 4.9.4 for now, ie. do NOT clone the full repository which is found eg. at https://github.com/WordPress/WordPress
- tag it with 4.9.4
- create two branches, a) the development branch for future works and b) a backport branch

2. Make currently hardcoded / baked-in, pre-defined features optional
There have been more radical suggestions to fork and then branch off WP with different purposes, eg. Blog, CMS and so on, but IMHO that is only going to divide the focus and also, important work power, too much from the main goal, ie. having a worthwhile, reliable continuation of the current state of WP.

Thus, I suggest keeping the focus on one branch and slowly adding options (either as "theme-feature", constant or direct WP option) to enable or disable features on demand. Also, adding this as an additional step to the WP installer, so that one does not have to do this all manually in the wp-config or other files for immediate inclusion.

Features that are currently baked-in, but should be optional / disable-able:

a) the WP comment system - a lot of blogs disable commenting altogether, and when the main usage purpose is Content Management, then its superfluous anyway; AFAIR the current method is using a purpose-built plugin to fully disable comments.

b) Theme Customizer - the idea is nice, but the UI is quite sluggish and not so straight-forward / integrated as quite a bunch of already available frameworks and solutions; currently, there is no way to disable this

c) Gutenberg - there should be a choice whether you want to use this or the "old" classic WP editor; currently, we are forced to a rather bad documented, feature-lacking block-wise content-focused backend editor; there are certainly at least 50+ different more mature solutions for this around, eg. Visual Composer, Elementor, Avia, Beaver Page Builder, and so on

3. Compatiblity Layer:

The "old" way to add additional options / settings to the WP editor is using the Meta Box API / UI. Supposedly there is something similar, but quite not the same, in the future WP 5.0 aka Gutenberg Editor. We should watch strongly the on-going porting efforts and use that achieved knowledge to add a compatiblity layer, if required.

I suggest making this one optional as well - so its not active UNTIL you explicitely say so. Could be created as a future plugin or a separate plugin being bundled, just like Akismet comes pre-bundled with WP.

4. Basic requirements:

I totally agree with having PHP 7 as the minimum required version. I've been using nothing else for years, and always try to push sites of clients into the current decade by preparing and then switching them to PHP 7. There are no benefits I'm aware of in keeping this fork PHP 5.x-compatible, but lots to gain, esp. performance-wise, but also in programming features, to keep everything PHP 7+ :)

5. Getting existing stuff in shape:

There is a lot of already existing features in the WP core, which have been neglected for years. 

One big example would be the Media DB .. situation.
Even if it was just some kind of category or tagging option, just about anything to improve its structure would do. At best, one would be able to easily create (sub)directories and move or upload images to them. Maybe a hierarchic tree browser or something for a quick overview.

Just about anything to IMPROVE it natively would help; esp. when having to work with large image collections and archives, it tends to be a tooth-gnashing effort to not get lost.

6. Add lots of gooooood documentation:

In a conversation with a fellow developer, this was the major topic: Documentation. What he says translates roughly to: "We are increasingly annoyed by the ongoing need of micro-management, just to get some proper documentation or clues at hand with specific parts of the core, plugins (and so on)"

Bad or next to non-existant documentation is one of the major issues with WordPress. Also with the struggle to put all into some fancy "handbook" instead of just keeping the Codex, and IMPROVING (on) it. If the tool is the issue, choose the one best suited for the task (eg. DokuWiki) and transfer all pre-existing data IN ONE GO.

So, my suggestions are:
- add helpful comments EVERYWHERE, whether it be PHP (PHPDOC!) or JavaScript (there is something called JSDoc, too; http://usejsdoc.org/)
- even short, quirky or cranky comments are more helpful than none at all
- use ENGLISH as the main interlinuga franca! (I've seen LOTS of plugins and themes with totally unreadable = worthless comments, because some sub-dialect of Spanish or Portugese AND including horrible grammar and spelling mistakes)
	- on a side note: english inside the comments, not exclusively; so i18n / l10n should be kept as it is, or even better, improved, but thats another topic ..
	- on another side note: My native language is German; I prefer staying in one lanugage though - we program in English, most of the original documentation is English, thus we should keep English as the main / base language, to have a base level to work from / see everyone on the same level (this phrase doesnt translate too well)
- Always keep in mind, that: Just because YOU understood the train of logic which lead to THIS point, doesnt mean that everybody else will instantly grok it, too!

Appendix: Writing documentation definitely is a major PITA, but at least the 'old' WP Codex style with using lots of initial examples first, was and is rather helpful and instantly getting one somewhere, while a lot of the reinvented "WordPress Handbook" thingy is getting you nowhere UNTIL you scroll waaaaaaaaaaaaaaaaaay down to the comments section. Even the PHP documentators have learned by now that this is a rather user-UNfriendly move.

So, these are my current few thoughts to this topic. Your thoughts? Suggestions? Ideas? Add them below this gist :)

I agree completely with everything you have said here. These are just some comments and thoughts:

"There have been more radical suggestions to fork and then branch off WP with different purposes, eg. Blog, CMS and so on, but IMHO that is only going to divide the focus and also, important work power, too much from the main goal, ie. having a worthwhile, reliable continuation of the current state of WP."

Agree. One Fork To Rule Them All™ (I realize that is self-contradicting, but you get what I mean, and it is kind of funny). I agree that it would be nice if it was easier for users to enable/disable components that they don't need (ex: Emoji-by-default is So. Damn. Lame.), but still ONE platform. There is one Laravel but many extensions.

"Supposedly there is something similar, but quite not the same, in the future WP 5.0 aka Gutenberg Editor."

There is Gutenberg Custom Fields and it is a great start, however, it is currently not (I realize that it is in development!) in the same league as Carbon Fields, ACF Pro or Titan (to a lesser extent). I was going to list Redux, but at the time of this post, their web site is currently unable to establish a database connection, LOL.

"3. Compatiblity Layer"

I'd also like to be more aggressive about removing cruft, particularly since this would be a new/optional fork. Automattic is trying to fix things that aren't broken while maintaining old irritations. Some simple things include updating dependencies like jQuery and removing JQMIGRATE [by default, but a simple define( 'WP_COMPAT_MODE', true); could throw them back - just an example]. There are many others, but those are easy and work with a majority of modern plugins/themes. I would also make it the default (to encourage better coding from third parties), but optional.

It is somewhat risky to have such changes the default (yet optional), but I think that it would encourage a lot better code quality from third-party jokers (something that every WP developer fights on a daily basis).

Controversial opinion that I would allow discussion and democracy to decide: I believe that PHP 7 should be the minimum requirement (as of the date of this post). At minimum, we should not support versions of PHP that are no longer supported. If you want to run it on some ancient third-world cPanel host with a broken header image and PHP 5.2, you should probably run Automattic.

"4. Documentation"

While I agree with this (I have an obsession with documentation), I'm not sure of the best way to manage/maintain this. I have some ideas, but it would be a separate topic of discussion.

I agree that English should be a required minimum, but I don't want to exclude talented developers who do not speak it as a first language. It would be nice if we had some sort of community of volunteers (call it 'translatewp.org' or something) to assist with translations. Though I have a love of language, sadly, I do not speak a second one fluently.

"Customizer"

I hate Customizer and front-end editing. Customizer has crappy documentation and there are no killer frameworks to deal with it (though I did recently find one that is very good). Personal opinion: Front-end editing does not belong in core and should be handled by plugins. That said, in order to maintain compatibility, I am not suggesting that it be removed from a fork. I... just don't like any of it.

Honestly, I don't even like dealing with content editors. I deal with them as required by client deliverables. I feel like Core should be kept basic and let the client/user/consultant decide the best tool/plugin for the job.

Automattic's problem is that they are trying to develop the same core for WordPress.com as WordPress.org. For this reason, I can justify a separate fork, which is what we are talking about here.

Semi-Related Rant

SVN sucks.

Epilogue

I (as you probably do) have many other ideas that I think would make WordPress better, however, some would require significant core changes and/or possibly/probably break compatibility (which is not the goal). For this fork, there are plenty of ways to keep it simple yet make simple improvements.

Similar to the W3TC fork, we keep changes minimal at first. As adoption expands, our user base gets to dictate more dramatic changes.

I added proposed criteria for choosing a project name. It would help with building awareness and also be a starting point for repo/domain/chat room names, etc.

I volunteer to register the domain(s) and host site(s) related to the project. However, I'd prefer that someone with better Git, CI and unit-testing skills manage a GitHub repo. I will create a GitHub organization for the project(s), but we need a GitHub guru to moderate. To begin, it will take a lot of effort to rename instances of WordPress (while preserving all copyright notices, etc).

First, though, we need a name for the project.

Naming suggestions: Worthwhile Process SCNR :)

Just wanted to say I agree with what you have written here, I like the name 4thPress which I read in a tweet I believe.
I am not the greatest coder but all of my client's websites are built using WP, I have written a plugin I use which I affectionately call "Hide Stuff" - I started this plugin when I realized all the crap that WP throws in to my sites (injecting emoji css in the header is the most egregious, imho) the plugin has gotten ridiculous with the amount of things I have to turn off.
Plugin compatibility would seem to be a problem, my suggestion would be to ignore plugin compatibility and focus on cleaning up 4.9 core, getting rid of all the crap, and worry about plugins later. I use, at most, 2-3 plugins on my sites and have found that usually I can code functionality in to the theme.

While the discussion seems to have stalled instantly after mentioning having to choose a project name first .. I've been working on my very own storage-agnostic CMS kit again. Which as a matter of fact is going to be compatible to WP, at least on a low level (Read: its going to use WPs filter and action hook API, plus the Shortcode API, plus getting a "WP Compatiblity Plugin", which should allow most simple plugins to work without or just very small modifications).

Aside of that, I just a backronym like the one for PHP: "WP is not WordPress" or something - IF it has to use "WP" at all. I'm still rather happy with the original "FourthPress" monicker, though :)

cu, w0lf.