Just so you know, and this probably isn’t the most modern/bleeding edge process or platform, but as a modern-ish dev who’s interested in using and leveraging the cloud service equivalent for tracking changes to my self-hosted WordPress files, this is my process.

Note, this process presumes there are like-minded people in a similar situation who might need to know this method of accomplishing my goal (to disable those unwanted ads). It’s sort of collaborative planning taking it on faith that someone will want to know this information at some point. I give as much (probably erring on too much) information and context as I can, to help future users find the information.

1. Open a support ticket with wordpress.com or wordpress.org regarding wanting to remove “just in time” ads for wordpress.com and Jetpack services from within the WordPress content management and administrative dashboard.
2. After some back and forth, get a line of code from the support folks to do this.
3. Double-check the patch code with Google. Literally copy/paste it or part of it into a Google Search and see if (indeed) this fix has been suggested at other times and places.
4. Desire to track/share the fix.
5. Create a public (because it’s free to make public repos) repository on GitHub (or any other git-supporting cloud/web service – I use GitHub because I’m relatively old in the business, and it was the only choice when I signed on – that I knew of) to host the changed file example.
6. Clone the repository to a local, working directory on my computer (I used GitHub Desktop Client because I’m lazy, but you can find and use a terminal-based command to do the same thing).
7. Use FTP to download a copy of the PHP file in question from one of my WordPress blogs (this time it was ~/wp-includes/functions.php where ~ is the home directory of the WordPress install, where LocalSettings.php lives) and put it in the cloned repo directory.
8. Edit the README.md to say where the file belongs, so people can find it, and check in this initial version of functions.php to record the standard version, pre patch. Also note the version of WordPress this file comes from. Commit
9. Make a copy of functions.php on server in case I screw it up and have to revert. Name it functions.php.old.
10. Make change to functions.php on server and test for ability to continue running WordPress on that instance. Keep an eye on it to ensure intended function.
11. Copy change to local functions.php and do another commit and push to GitHub repo, with appropriate remarks. In order to avoid human error, just use FTP to download it back to the local repository for pushing it to the GitHub Repository.

Note that there is no immediate benefit to me to do this, except that I believe that what goes around comes around. It takes a lot of these little efforts to keep the tech world spinning, so I share info like this when I can.

It will also help me when/if the next upgrade blows away my copy of functions.php and I can’t remember how I did this last time, but that may take a while to be profitable for me.