Backport WP5 trac tickets


As mentioned in Slack today

I have a question about trac commits that have been committed since the code was ported that are not related to gutenberg in any way, like php 7.3/4 fixes will these be backported? Or do they need pull requests? Is there already procedure in place for that?

The change in question were:

I have already ported and tested the changes to my local Classic dev install and my php 7.4 server so I can provide the diff if needed.

Maintain fork using "negative diff" approach

Hi @Pross, good question.

For now, I’d be happy to get these specific changes for PHP 7.3+ compatibility ported over to ClassicPress, so please do submit a PR. It may be a little while until we merge it, though, since we’re currently busy preparing for the first beta release.

Longer-term, I’ve started planning for a general effort to port relevant WP 5 (and 4.9.x) changes back over to ClassicPress on an ongoing basis. We have a web app that can help with this:

It’s not finished, right now it just shows a list of commits and not much else. The goals for this app are the following:

  • Allow viewing each change and showing a diff, as well as a diff against the ClassicPress source tree that includes information about any conflicts
  • Allow discussing each change
  • Allow marking a change as “not wanted” or submitting a PR

And then a couple more things that would be nice:

  • In the commit messages as shown in the app and as submitted in a PR, turn [changeset] and #ticket references into fully-qualified links
  • Decipher and link together “backport” commits from different WP branches

As you can see, there are a lot of commits to sort through, so we will probably also want to split the commits by pages and add a filter for commits we haven’t decided what to do with yet.

The code for this app is at - pull requests welcome there too.

I haven’t documented how to develop against this app locally yet, so I’ll write some basics here.

Basically you need to be running at least PHP 7.1 (you can use phpbrew for this if you don’t have it installed locally).

Then you can set up your .env file with a MySQL database and run the following:

php artisan migrate
php artisan serve --host=bots.classicpress.local --port=8000

Some more information about how the app uses git repos to do its work, and the setup needed to make that part work, is here:

To test the app features related to logging in, you’ll need to set up a GitHub OAuth app at and fill in the relevant details in .env also.


@Mte90 is also working on sorting through this list of changes to find other things that we might want (REST API performance improvements, bugfixes, etc).


Right now is not easy, I scraped manually the last 2 months of tickets
Take that list as as very alpha early super working in progress because I have to check every ticket and also the code and I am evaluating if add tickets that has a patch and postponed to 5.1 but are ready, especially for bugfixes in this case.
And also we need to discuss to every ticket or group of tickets, so is only a pad to write this links and info.


You might want to wait until we have that app working :wink:


Originally posted on GitHub, here is how to port WP changesets over to ClassicPress using git (no need to manually edit files, unless there are conflicts):

Let’s make sure that we port over whole changesets from WordPress, rather than whole tickets or partial commits at once. This will make it easier to track our work and make sure that we have everything.

Since exists, the easiest way to do this is using git.

Rough steps, using changeset 43832 (trac, GitHub) as an example:

# add and fetch WordPress git history
git remote add wp
git fetch wp
# reset to latest ClassicPress code
git fetch origin
git checkout origin/develop -B develop
# start a new PR branch
git checkout -b merge/wp-r43832
git cherry-pick 894e8472

This magic number 894e8472 comes from looking through the lists at and for a commit that happened at the same time as the commit on WP Trac, with the same message and the same internal ID (git-svn-id: [email protected]):

git-svn-id:[email protected] 602fd350-edb4-49c9-b593-d223f7449a82

There may be merge conflicts during the cherry-pick command, but in this case the changes I wanted were applied without me ever having to edit any code files. This is great because this way I know I got exactly the changes I wanted.

So I followed the steps from @HongPong above, and the resulting PR is Note I left a record of what I did in the PR message.

Here are the pieces of information you need to record when porting changesets:

  • WP SVN changeset link
  • wordpress-develop git commit hash

Using the same example from :

Merges / WordPress/[email protected] to ClassicPress.

I plan for the web-based tool I described above to read and interpret these lines out of our commit messages.

split this topic #7

A post was split to a new topic: Maintain fork using “negative diff” approach


We now have a command-line script that does most of the work of backporting changes for us:

To use it:

  • Identify the WordPress revision number for the commit you want to port (note, this is not the same as the WP ticket number)
  • Change to your ClassicPress source directory
  • Run bin/ XXXXX where XXXXX is the revision number you identified earlier
  • Follow the instructions provided by the script.

More coming soon!


Might be a dumb question. Isn’t PHP 7.3 compatibility one of the issues (#263) that needs to be completed for v1.0?


Yes, and accordingly, is in the 1.0.0-rc1 milestone.

Keep in mind you replied to an old comment that was written when we were still in the alpha release stage.