Write a patch

Video loading...

  • 0:01
    Write a patch
  • 0:02
    Learn Drupal Ladder
  • 0:04
    with Addison Berry
  • 0:07
    In this lesson, we're going to be looking
  • 0:09
    at how to write our own patches.
  • 0:11
    A patch is the way that the community gives something back.
  • 0:14
    So if you have fixed a problem, or if you're trying to provide
  • 0:18
    a new feature, and you've fixed that yourself-- written all of the code
  • 0:22
    up, or improved that documentation that's in the code-- the way
  • 0:26
    that you contribute that back to the communities is through a patch.
  • 0:29
    So what we'll be doing is looking at how to use Git in order
  • 0:32
    to create that patch, and then upload that to a Drupal.org issue,
  • 0:36
    so that the community can help us with it.
  • 0:40
    So starting on the DrupalLadder.org website,
  • 0:43
    going to the Drupal ladder tab, to the main Drupal ladder,
  • 0:46
    we are going to be doing the lesson that's called, write a patch.
  • 0:50
    And once we get in here, the first thing that we want to do,
  • 0:54
    as usual, is look at our prerequisites that we have.
  • 0:58
    This lesson also uses the same sandbox version of Drupal 8
  • 1:02
    that we've used in previous lessons.
  • 1:04
    So you should have that set up.
  • 1:06
    You'll need to have Git.
  • 1:08
    We'll also be working with the issue we created in the, getting
  • 1:11
    started in the issue queue lesson.
  • 1:14
    And then you'll also want a way to be able to capture a screen shot,
  • 1:17
    because we want to take a picture of the work
  • 1:19
    that we've done when we upload it to our issue.
  • 1:21
    And so when we get into the steps themselves,
  • 1:24
    we're going to start off by creating a branch for us to work in,
  • 1:28
    then making our edits, and then creating the patch.
  • 1:31
    So first, let's go ahead and actually go to the Drupal sandbox.
  • 1:36
    So that's my main code base that I'm going to work from.
  • 1:41
    And I'll do a quick git branch, just to make
  • 1:43
    sure that I know which branch I'm on, which is 8.x, which is correct.
  • 1:49
    So now we want to create our own working branch.
  • 1:52
    And the best practices would say that I
  • 1:55
    name that in a meaningful way.
  • 1:57
    So I'm going to my issue that I created in the sandbox.
  • 2:01
    So this is my issue from earlier, and I'm
  • 2:03
    going to grab the node ID, or the issue ID number out of the URL.
  • 2:09
    And I'm going to use that for my branch name.
  • 2:11
    So Git branch, and then if you type in a name of something,
  • 2:13
    it's going to create a branch.
  • 2:14
    So I'm going to put in the issue ID number, and then a description
  • 2:18
    of it, so that when I'm looking at it, if I have multiple branches,
  • 2:20
    I know which branch has which work in it.
  • 2:25
    And now that I've created the branch,
  • 2:27
    I need to actually be in that branch.
  • 2:30
    I'm still in my 8.x branch code base.
  • 2:33
    So I'm going to check out-- I have a shortcut for co.
  • 2:37
    You should type the full word check out there,
  • 2:40
    and then the branch name.
  • 2:42
    And then when I do a git branch, we'll see that the asterisk
  • 2:46
    is next to that one.
  • 2:47
    So I'm currently in my working branch,
  • 2:50
    and not in the main 8.x branch.
  • 2:52
    So I can go nuts, and I'm not actually changing the core stuff.
  • 2:59
    So we've done that first set.
  • 3:00
    The next thing is to actually make our changes.
  • 3:04
    So we need to go in and do the changes
  • 3:06
    we want to create the patch, and then
  • 3:09
    get the patch code into our branch.
  • 3:14
    So within this branch, you can open up any text
  • 3:19
    editor you want, any way you want.
  • 3:20
    You can do it from the command line.
  • 3:22
    I use Text Mate.
  • 3:23
    I could do this from the command line, like that.
  • 3:25
    Or, I can just use Explorer or Finder, and go and just open up.
  • 3:30
    But basically, this is where you just work on files the way
  • 3:33
    that you're used to working on files in whatever editor you want.
  • 3:37
    So the path.module is the file that we need to make this change in.
  • 3:44
    So I'm going to go ahead and open that up in my editor.
  • 3:47
    And I need to go to line 139, I believe.
  • 3:52
    Or you could search through here for the text.
  • 3:56
    So this is the description text on that form field,
  • 4:00
    and that's what we want to change.
  • 4:02
    Let me come back here, and I'm just going
  • 4:04
    to copy and paste this text, the correct text
  • 4:08
    that we want to use here.
  • 4:10
    I'll go ahead and paste that in.
  • 4:13
    Voila, save it, double check, make sure that I'm not doing any work
  • 4:18
    parse errors by doing that.
  • 4:20
    OK, now that I have the actual change
  • 4:22
    in the code, what I need to do is go back and check it, and see.
  • 4:28
    So I'm going to go into my sandbox site, and go add some content.
  • 4:36
    And just add an article, doesn't matter
  • 4:37
    what content we're adding here.
  • 4:39
    I just want to go to where the bug was, and where the fix is.
  • 4:41
    So this is the fix.
  • 4:43
    This is the correct text that I've just added.
  • 4:46
    So that looks fine, and it doesn't look
  • 4:48
    like it's messing anything else up.
  • 4:49
    And I'm not getting any parse errors, or anything like that.
  • 4:51
    So I think everything's good.
  • 4:54
    I'm going to go ahead and take a screenshot to show everybody what
  • 4:58
    the patch I created, what it does, so people can see the end result,
  • 5:02
    without having to necessarily apply it.
  • 5:05
    So I'll do that, and then I'm just going to put a little red box
  • 5:10
    around it, the actual text change, just to highlight
  • 5:16
    what changed on this page.
  • 5:18
    And I'll give it a name.
  • 5:21
    And I'm just going to save this to my desktop,
  • 5:25
    because I'll need it later to upload to the actual issue.
  • 5:27
    But at least I've captured what I've done in a screen shot,
  • 5:31
    and now what I need to do is go back and commit this code.
  • 5:36
    It's good, I like what happened, everything's
  • 5:39
    fixed just the way I want to be.
  • 5:41
    So now let's go ahead and go through the process of doing a commit.
  • 5:46
    So before I actually pull the trigger and do a commit,
  • 5:50
    let's do a quick Git status.
  • 5:51
    Always a good idea before committing.
  • 5:54
    Make sure you know what you're committing.
  • 5:55
    So let's see what's changed.
  • 5:57
    We can see that the path module changed.
  • 5:59
    I can see which files modified.
  • 6:02
    But if I actually want to see exactly what changed,
  • 6:04
    let's do a git diff, and then that basically gives
  • 6:07
    me what a patch file looks like.
  • 6:09
    And it shows me which lines have been changed.
  • 6:13
    So I can see I'm removing the optionally specify
  • 6:16
    to the alternative URL text.
  • 6:18
    So that looks correct.
  • 6:20
    That's the only change that I want to have in this commit.
  • 6:23
    So that's fine, so I can hit q to quit out of there.
  • 6:28
    And go ahead and do my commit.
  • 6:31
    I'm going to do am, so that I am adding the modified stuff
  • 6:35
    and leaving a message.
  • 6:36
    We want to put that issue number directly in there,
  • 6:39
    so it's handy to have it in my branch name.
  • 6:44
    So that's the issue number, and then I
  • 6:46
    need to put a description of what it is, just sort of describing what
  • 6:51
    this commit is, and then hit Enter.
  • 6:53
    And that commits it to my local repository.
  • 6:56
    So it now committed that change, and it's in there.
  • 6:59
    If I do a git log, I can see that's the last commit.
  • 7:03
    So there was code before, and now I've
  • 7:05
    made a change subsequent to that.
  • 7:08
    You can also use git show to actually show you the last commit.
  • 7:14
    So this shows everything that I did.
  • 7:16
    So everything looks good.
  • 7:17
    That is correct, those the changes that I wanted to do.
  • 7:21
    So again, I'll hit q, and get out of there.
  • 7:24
    Clear my screen.
  • 7:27
    Now that we've done the commit, we're
  • 7:29
    going to move down to the last part, which
  • 7:31
    is to actually submit a patch.
  • 7:34
    So we need to create an actual patch file,
  • 7:37
    and then add that to our issue on Drupal.org.
  • 7:41
    And you can see it's pretty simple.
  • 7:44
    We're basically just going to do a git diff an output that to a file
  • 7:49
    with a .patch ending on it.
  • 7:52
    You can see that the convention for naming the patch file
  • 7:56
    has a description, the issue number, and also the comment number.
  • 8:01
    So I'm going to go back to my issue here, and find the last comment
  • 8:04
    number, which is number three.
  • 8:05
    That means when I leave my comment with my patch,
  • 8:08
    that'll be comment number four.
  • 8:10
    So I want to know that before I name my patch.
  • 8:14
    So let's go back in here to command line.
  • 8:18
    Now git diff-- I want to get a diff of my branch to the 8.x branch,
  • 8:24
    so we can find what those differences are,
  • 8:26
    and then output that.
  • 8:27
    So that's what the angle bracket is for.
  • 8:31
    Output that to-- and I'll just give it a description.
  • 8:34
    I'm going to paste the issue number, and then
  • 8:36
    my comment numbers is four, .patch.
  • 8:40
    So that's how we name our patch files
  • 8:42
    so everybody's clear where that patch
  • 8:46
    actually came from on Drupal.org.
  • 8:50
    And do an ls, you can see that my patch
  • 8:53
    file is now in my Drupal site.
  • 8:55
    So it's been created successfully.
  • 8:59
    And now we can go back to the actual issue,
  • 9:01
    and I can scroll down here to the post
  • 9:04
    and comment, and add my patch and my screenshot, along with a comment
  • 9:09
    about what's going on.
  • 9:11
    The first thing I always do when I'm submitting a patch
  • 9:13
    is change the status, because it's a patch that's attached,
  • 9:17
    and it needs review now.
  • 9:18
    And if you don't change it, it's easy to forget.
  • 9:21
    And then that's annoying, so I always try and do it first.
  • 9:24
    So I'm leaving a comment, just sort of explaining what I've done.
  • 9:28
    And now I'm going to upload-- first, this is my screenshot.
  • 9:33
    It doesn't matter what order you do it in, obviously.
  • 9:35
    But I uploaded the screenshot, and now I'm going to go into my sandbox
  • 9:39
    site, and grab my patch file.
  • 9:42
    And go ahead and attach that one.
  • 9:47
    And that's it.
  • 9:48
    Now I can go ahead and save it.
  • 9:51
    And once it saves and the page reloads, you'll see,
  • 9:54
    we drop down here to my new comment.
  • 9:57
    It has needs review status, and it has my two files there, attached.
  • 10:01
    I can click on the patch file, and read
  • 10:04
    the patch file, just like anybody else's patch on Drupal.org.
  • 10:09
    Once you've uploaded to patch, we have
  • 10:12
    a test bot that will do automated tests on the patches that
  • 10:17
    are in the queue.
  • 10:18
    You can read about that in the instructions.
  • 10:20
    And I just want to show you, in our sandbox patch, it doesn't do it.
  • 10:23
    But here in the real issue, you can see when your patched
  • 10:28
    passes the tests, it shows green.
  • 10:30
    If it didn't, it would show red.
  • 10:32
    So we just need to wait for the test bot to get around to it
  • 10:35
    and test it.
  • 10:36
    Doesn't happen in our sandbox issue queue,
  • 10:38
    so I wanted to just show you what that look like.
  • 10:41
    And then the last thing we have here is you could, for bonus steps,
  • 10:45
    you can re-roll the patch.
  • 10:46
    It's essentially the same steps as we've done before.
  • 10:50
    You just would upload it again, changing the comment
  • 10:53
    number in your patch file name.
  • 10:55
    So creating patches is pretty simple.
  • 10:58
    Once you can identify the problem, and you know how to fix it,
  • 11:01
    it's a matter of making sure that you have the right code,
  • 11:04
    that you create your own branch, make your changes,
  • 11:07
    and then submitting your patch to the site.

The Learn Drupal Ladder

Loading ...

Write a Patch

Loading...
11 minutes 8 seconds // Drupal 8 // HDCC //

In this video we will write our own patch to resolve an issue. We will take a screenshot of the issue before and after our patch, and upload the images and patch to the Drupal.org issue queue. This video follows the instructions in the Write a patch lesson on drupalladder.org.

Additional resources:
There are no resources for this video. If you believe there should be, please contact us.

Share