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 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.