Setup WordPress for Testing Trac Tickets


  • | 4005 points

    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

    1. Open Laragon.
    2. Click Menu -> Quick App -> Blank. Name it "wpdev"
    3. 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)
    4. 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
    5. Still in terminal, type cd wpdev, enter, then npm install && grunt build
    6. If using nginx, find{laragon}/etc/nginx/sites-enabled/auto.wpdev.conf (if using apache, use that instead) and remove auto. from its name.
    7. In that file, find the line that starts with root (or sometimes define ROOT), and add build/ onto it.
    8. 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

    1. Find the ticket from trac.wordpress.org that you want to apply, and take note of its ticket number
    2. 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.
    3. After applying the patch, you should run grunt build again (to re-sync the changes made to the src directory to the build directory)
    4. 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.

  • | 4005 points

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


  • administrators
    | 97034 points

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


  • | 4005 points

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


  • | 4005 points

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


  • administrators
    | 97034 points

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


  • | 4005 points

    @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)


  • | 112 points

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


  • | 4005 points

    @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!


  • | 112 points

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


  • | 4005 points

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


  • | 112 points

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


Log in to reply
 

Looks like your connection to Laragon was lost, please wait while we try to reconnect.