Setup WordPress for Testing Trac Tickets

mnelson4

This tutorial is for setting up WordPress in Laragon so you can test patches from WordPress Trac.

Prerequisite: you'll need Laragon WAMP, not just Laragon Portable. You'll need to run node and npm.

Create Development Site

Video: https://drive.google.com/file/d/12Y-7QRUpA6V1207fCDvxxG6kmgyRipY0/view

Open Laragon.
Click Menu -> Quick App -> Blank. Name it "wpdev"
Click "Terminal", and in the terminal type git clone git@github.com:WordPress/wordpress-develop.git wpdev and then enter (or git clone https://github.com/WordPress/wordpress-develop.git wpdev and enter your GitHub username and password)
Copy {laragon}/www/wpdev/wp-config-sample.php to wp-config.php, and enter change the database name to be wpdev, and user to be root, with blank password
Still in terminal, type cd wpdev, enter, then npm install && grunt build
If using nginx, find{laragon}/etc/nginx/sites-enabled/auto.wpdev.conf (if using apache, use that instead) and remove auto. from its name.
In that file, find the line that starts with root (or sometimes define ROOT), and add build/ onto it.
In laragon, click "Stop All" and "Start All'. Now your copy of the development version of WordPress should be running at wpdev.test.

Apply Patches

Find the ticket from trac.wordpress.org that you want to apply, and take note of its ticket number
From {laragon}/www/wpdev/, run grunt patch:{ticket-number}. Eg if you wanted to apply the first patch from [Trac ticket 43443](https://core.trac.wordpress.org/ticket/43443), you would typegrunt patch:43443`, and then it would ask you which one of the uploaded patches you'd like to apply.
After applying the patch, you should run grunt build again (to re-sync the changes made to the src directory to the build directory)
When you're all done testing and want to undo the patch, run git checkout .
See https://make.wordpress.org/core/handbook/tutorials/working-with-patches/#applying-a-patch for more information.

mnelson4

maybe I could use procfile to do everything under "Create Development Site"? Not familiar with that yet.

leokhoa

@mnelson4 : Sure, you can use Procfile to create this entry Menu > Laragon > Create Development Site
We can automate it. I'll help.

mnelson4

@leokhoa yeah ok I'll read up on Procfiles. Maybe having a command to create a WP development site would be better than my earlier idea to create a fork of Laragon with everything pre-setup (see https://forum.laragon.org/topic/1044/laragon-for-wordpress-core-contributions/2). I'm afraid that would be more work to maintain, whereas having a command to download and set everything up would be more light-weight.

mnelson4

@leokhoa regarding implementing this in a procfile:
how would I execute the equivalent of "Menu -> Quick App -> Blank. Name it "wpdev""?
Executing the terminal commands and editing files seems straightforward (just separate them all by &).
I'm also not sure if I can get user input about what name they'd like for the WP development site.

leokhoa

@mnelson4 :

how would I execute the equivalent of "Menu -> Quick App -> Blank. Name it "wpdev""?

What do you think about implementing a command line for that purpose?

laragon create "Blank" wpdev

I'm also not sure if I can get user input about what name they'd like for the WP development site.

They can change the name in Procfile or they can just rename the folder after creating.

Still in terminal, type cd wpdev, enter, then npm install && grunt build

Procfile is very powerful. Instead of doing a list of commands manually, you can specify this in the Procfile:

Run Grunt: npm install & grunt build & grunt watch pwd=C:\laragon\www\wpdev autorun

pwd: Intructs Laragon to run the command in that directory
autorun: When Laragon starts, it will auto trigger the commands.

mnelson4

@leokhoa

What do you think about implementing a command line for that purpose?

I think developers would like it, for uses like this. (But it's always nice to have were GUI-based alternatives for non-developers.)
I think it would also be great if, eventually, common setup tasks (like enabling xdebug, or setting up for phpunit, or installling WP CLI) were commands (and the most common ones had GUI-based alternatives).

They can change the name in Procfile or they can just rename the folder after creating.

Right, I'd really like this to be usable by non-developers (eg, I see the potential to allow non-developers to contribute to testing to WordPress core without needing to write/edit any code or commands). Eg, I like how when I use the "Quick App" option for WordPress, there is a prompt for the site's name, and voila! I'd ideally like to have a prompt asking users what name they'd like.

Procfile is very powerful...

Ya that would be really handy- ie, we could start grunt watch without the user needing to remember to enter those commands each time. That'd be great.
But in your grand design, should the Procfile be shared? (eg, I thought it was supposed to just contain commands for a particular local install)

maguijo

First off, thank you for this! It was very helpful. I'm not a new developer but new to trying to help the Wordpress core and feeling very much like a bewildered newbie at the moment!

Today, trying to follow these instructions I discovered the url for cloning the development package has to be https://github.com/WordPress/wordpress-develop.git

Ergo: git clone https://github.com/WordPress/wordpress-develop.git wpdev

Also, in the instructions to find the line that begins with root, that line actually begins with define ROOT. Little things like that tend to throw us bewildered types off.

mnelson4

@maguijo thanks for passing on what you learned.
That URL is for cloning the repo using HTTPS, whereas the link I originally put is for cloning it with SSH. This article explains some differences: https://help.github.com/articles/which-remote-url-should-i-use/ but the main difference is SSH requires you to create a private key and uploading it to GitHub, whereas HTTPS just requires inputting your username and password. I updated the instructions to include your recommendation.
Regarding the root vs define ROOT, I double-checked and its definetely just root for me. I'm no nginx/apache expert, but it might be because of a difference in version. Regardless, I updated the instructions to also mention the line could be define ROOT like it was for you.
So, thanks and good luck!

maguijo

@mnelson4 Thanks for the education on the difference between SSH and HTTPS cloning. Did not know that! Always learning something new...

mnelson4

@maguijo ya, that type of learning is what I find I often get from contributing to open source. For example, I didn't know HTTPS is actually the one recommended by GitHub! (I personally prefer SSH, now that I've gone through the hassle of setting it up, because I don't need to give my username and password each time.)

maguijo

@mnelson4 It didn't ask me for my github username and password...