Setup WordPress for Testing Trac Tickets
-
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
andnpm
.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 (orgit clone https://github.com/WordPress/wordpress-develop.git wpdev
and enter your GitHub username and password) - Copy
{laragon}/www/wpdev/wp-config-sample.php
towp-config.php
, and enter change the database name to bewpdev
, and user to beroot
, with blank password - Still in terminal, type
cd wpdev
, enter, thennpm install && grunt build
- If using nginx, find
{laragon}/etc/nginx/sites-enabled/auto.wpdev.conf
(if using apache, use that instead) and removeauto.
from its name. - In that file, find the line that starts with
root
(or sometimesdefine ROOT
), and addbuild/
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/
, rungrunt 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 type
grunt 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 thesrc
directory to thebuild
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.
-
maybe I could use procfile to do everything under "Create Development Site"? Not familiar with that yet.
-
@mnelson4 : Sure, you can use Procfile to create this entry Menu > Laragon > Create Development Site
We can automate it. I'll help.
-
@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.
-
@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.
-
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.
-
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)
-
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 withdefine ROOT
. Little things like that tend to throw us bewildered types off.
-
@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 theroot
vsdefine ROOT
, I double-checked and its definetely justroot
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 bedefine ROOT
like it was for you.
So, thanks and good luck!
-
@mnelson4 Thanks for the education on the difference between SSH and HTTPS cloning. Did not know that! Always learning something new...
-
@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.)
-
@mnelson4 It didn't ask me for my github username and password...