Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 9 min 22 sec

Mediacurrent: Introducing Metatag 1.5

il y a 0 s

One of the most commonly used modules for helping with a Drupal 7 site’s SEO is Metatag. A rewrite of the Drupal 5 & 6 module Nodewords, Metatag provides a flexible system for customizing the meta tags used on a website. Using various meta tags it is possible to exert some control over how search engines analyze each page, and how the content looks when it is shared over social networks.

Catégories: Elsewhere

Arthur Foelsche: One click deployment? How about one push?

il y a 1 heure 27 min

Yes, yes, one click deployment is amazing. And yet so last year. So I say, hell no, we want one push deployment. The dream cheeky USB button is neat. Let's deploy sites with it. This project is an example of how you might be able to do it: Deploytron.

Ok, so what does this really mean? With virtualized development environments, continous integration tools, and continous delviery tools we should be able to make changes to production sites predictably and easily. Deployment isn't an after thought, it's simply another step in the development process. And its easy. Hosting services are marketing tools to do specifically this. But frankly, it takes the fun out of it. 

You should be able to launch a site with some fan fare. Deliver a Deploytron box to your client and let them hit the button. Put names in a hat and let somebody in the office press the button. See how long it takes your cat to step on it. 

Categories: Planet Drupal
Catégories: Elsewhere

Lullabot: Deane Barker and the Art of Content Management

il y a 4 heures 8 min

Jeff talks to Deane Barker of Blend Interactive about the art and practice of content management, the joy of solving complicated problems, and his upcoming O'Reilly book Web Content Management.

Catégories: Elsewhere

Trellon.com: How Drupal.org is lowering the barrier to become a module maintainer

il y a 5 heures 32 min

Before anything else, I want to point out that while this post will focus on maintaining a contrib module on drupal.org, that is just one of the many ways to contribute to the Drupal project. Every contribution is important whether it's a core patch, a documentation edit, a translation, or something else. If you use Drupal, please consider how you might be able to give back to the community. If you're already contributing, then thank you!

Catégories: Elsewhere

Acquia: Drupal replaces in-house CMS at Digital Agency - meet John Doyle

il y a 5 heures 40 min
Language Undefined

In April 2015, I was excited to talk with John Doyle, General Manager Technology & Solutions Architecture at the Australian full-service digital agency Komosion, to explore their decision to adopt Drupal to replace other technologies, including an in-house CMS they'd invested 10 years of work in. In this podcast, John very clearly lays out what Komosion's priorities were in making this decision, the benefits for the agency and its clients, and the future he sees using Drupal as the basis for future work.

Catégories: Elsewhere

Drupal core announcements: Recording from May 29th 2015 Drupal 8 critical issues discussion

il y a 8 heures 22 min

It came up multiple times at recent events that it would be very helpful for people significantly working on Drupal 8 critical issues to get together more often to talk about the issues and unblock each other on things where discussion is needed. While these do not by any means replace the issue queue discussions (much like in-person meetings at events are not), they do help to unblock things much more quickly. We also don't believe that the number of or the concrete people working on critical issues should be limited, so we did not want to keep the discussions closed. Here is the recording of the first meeting from today in the hope that it helps more than just those who were on the meeting:

Unfortunately not all people invited made it this time. If you also have significant time to work on critical issues in Drupal 8 and we did not include you, let me know as soon as possible.

Catégories: Elsewhere

Cocomore: Awesome DrupalCamp Spain 2015 in Jerez!

il y a 9 heures 31 min

Last week, some colleagues from Cocomore and I attended DrupalCamp Spain 2015. Spanish Drupal community is awesome, and they have put all their efforts in making an unforgettable event again in this 6th edition (the 5th I have attended).

The event was divided into different activities for the three days: Business Day and Sprints on Friday, and sessions on Saturday and Sunday.

read more

Catégories: Elsewhere

LevelTen Interactive: DrupalCon LA 2015 Video: Pantheon Interview

il y a 16 heures 36 min

On Wednesday’s blog post, we debuted our first interview from DrupalCon. If you missed the Roundtable Interview, you can catch the first episode here. The interviews first appeared during our weeklong live broadcast with Periscope and Twitter.... Read more

Catégories: Elsewhere

DrupalCon News: Share your Drupal Development Knowledge at DrupalCon

jeu, 28/05/2015 - 17:14

Barcelona is one of the most cosmopolitan cities in Europe and we want to infer the same spirit for the Coding and Development track. This is an exciting moment in the web development industry and we plan to take advantage of that. The DrupalCon Barcelona Coding and Development track is focused on preparing developers for the future of the web development universe.

Catégories: Elsewhere

InternetDevels: DrupalTour Rivne

jeu, 28/05/2015 - 16:55

Any morning starting with DrupalTour journey is great ;) Especially if the point of destination is only 70km away. This time we visited Rivne, welcome on board!

We decided to slightly change the concept of the event. It’s much more convenient to communicate with visitors in calm atmosphere of conference halls — we all can concentrate purely on reports and questions.

Read more
Catégories: Elsewhere

Drupal for Government: Step 4 - going the final mile with citizen politics and openspending.org

jeu, 28/05/2015 - 16:52

In the past three posts we've looked at how the Charlottesville Expense Budget might be made more transparent through maps and visualizations.  The final stage in our process is getting the data we've collected added to a larger data set - in this case we're going to use openspending.org as a repository for our work.   This means that even if this site fails (gasp) the work we do will not be lost, and may contribute to a larger and greater good (perhaps a stretch right now, whatev).

Using views data export we can create a CSV file that has all the needed fields for openspending.org - they're a pretty flexible group Amount and Date are the only required fields, we've added Merchant (thanks to the SCC data for that) as well as categories and locations (thanks to John Pfaltz for that).

Catégories: Elsewhere

VM(doh): Drupal cache_form Table Eating Disk Space? Here's a Fix.

jeu, 28/05/2015 - 15:30

A problem we hear about quite often is a huge cache_form table. Drupal by default caches all form data (typically for 6 hours). During peak traffic times, that can be a lot of form data being cached. When the form cache is cleared during Drupal's cron, the following DELETE query is used:

DELETE FROM cache_form WHERE (expire <> 0) AND (expire < UNIX_TIMESTAMP(NOW()));

However, InnoDB does not release disk space back to the file system on DELETE queries, and that can easily lead to a very large .ibd file for that table.

The three most common "fixes" we see being discussed are:

  1. mysqldump - Many people recommend exporting the table via mysqldump and then importing it again. While this does reclaim the disk space, your cache_form table will be locked during the dump and the import, and any users who filled out forms during that small time gap in between the dump and the import will have their form data lost.
  2. OPTIMIZE TABLE (or ALTER TABLE "Engine=InnoDB") - Another recommendation often seen is to run OPTIMIZE TABLE on the cache_form table. However, this will also negatively impact your users by locking the cache_form table during the process. The ALTER TABLE is also mentioned here because it essentially does the same thing on InnoDB.
  3. TRUNCATE - Probably the most common recommendation we see is to simply TRUNCATE the cache_form table. That will instantly free up all of the disk space that table is using, but it will also delete ALL cached form data.

Fortunately, Percona Toolkit contains a great tool to do online schema changes, and it even works if you are running a cluster. We have a client whose cache_form table legitimately grows to ~20GB during peak traffic times, but their site has almost no form usage outside of normal business hours. Running the following as a maintenance task just before the start of the day when there is the least amount of data that legitimately resides in cache_form typically results in a shrinkage down to less than 50MB:

pt-online-schema-change --host 127.0.0.1 --port 3306 --user bender --alter "ENGINE=InnoDB" D=database,t=cache_form --execute

This runs an ALTER TABLE, but with a few extra things going on under the hood. Instead of simply copying the table, it also creates triggers on the original table so that any new data being written to the original table are also written to the new table. When the process is done, it then atomically renames the tables and drops the original.

Catégories: Elsewhere

ThinkShout: DrupalCon LA - A Designer's Perspective

jeu, 28/05/2015 - 15:00

Oh, man. After coming back from DrupalCon Los Angeles with my team at ThinkShout, my brain still hurts... but in a good way. You know, in that same way you feel after binge watching Dr. Who on Netflix leading up to the season finale where The Doctor and Clara… oops. No spoilers. Point being: it’s a feeling of intense brain explosion followed by inspiration and motivation to get up and kick some ass.

Besides attending some fantastic design and UX sessions, I also presented my own session about designing on a budget and led a BoF about design and prototyping in Drupal. I made a lot of awesome new friends and reconnected with some old ones as well.

All in all, it was a great conference and LA was a fantastic host city. My team from ThinkShout and I covered a lot of ground - we found some great bars and restaurants, including my favorite stop, Grand Central Market (where I had an amazing octopus tostada from La Tostaderia).

But anyway, you’re not here to read about bars and restaurants in LA. Let’s talk Design at DrupalCon.

One thing that’s really impressed me about DrupalCon is just how much the breadth of UX and Design content has expanded over the last few years. This was my fourth DrupalCon: my first was 2011 in Chicago, followed by ‘13 in Portland and ‘14 in Austin. I was excited to see there were several sessions in the UX and Design track this year that were less technical, and more about design thinking and problem solving. Personally, I enjoy these kind of talks because I tend to walk away with some new insights into my own process. Design is not the same thing as Front End Development, and DrupalCon is finally realizing and embracing this.

Common Design Themes from DrupalCon LA

Attending DrupalCon is a great way to get your finger on the pulse of what’s happening in the Drupal community. I’ve noticed a lot of changing trends in the years since my first DrupalCon, starting with the prevalence of responsive design. In the first DrupalCon session I gave in Portland in 2013, only about half the room raised their hands when I asked how many had worked on a responsive Drupal site. This year, nearly everyone raised their hand when I asked the same question. At this point, responsive design is implicit when designing a new Drupal site.

Here are some other design and UX trends from this year’s DrupalCon:

  1. People are applying design thinking about much more than how a website looks. Megan Erin Miller, a designer at Stanford University, gave a fantastic talk about using Service Design to design end-to-end experiences. According to Erin, "designing a website is not just about designing good user experience. It’s about designing new processes, new identities, and new partnerships." I couldn’t agree more. Erin compared the process of building a website to designing a theme park. When you go to a theme park, your experience isn’t just about what happens when you ride the roller coaster. A good theme park experience starts when you see an ad on TV or get an email offer and book your trip online or over the phone. When you get to the theme park, your whole experience is planned and designed, from the moment you walk in the gate, to when you queue up in line for the roller coaster, and on to dining and buying souvenirs. As designers, we should be thinking of our websites as products and how our users interact with these products from all possible channels, and not just what browser they’re using on what device. I’m always looking for new perspectives for my personal design process, and I hope to use some service design techniques in my client work.

  2. Components, components, and more components! Just as the topic of "responsive design" dominated DrupalCon’s design sessions in years past, this year’s hot topic was component-based design. As websites and web apps get more complex and responsive, design needs to be streamlined and simplified. One way we can do that is to design modularly. Gone are the days of creating unique layouts for every page on a website (phew!). Instead, we need to be creating design systems that can be applied efficiently across the entire responsive website. Two great component-based design sessions from DrupalCon LA were, “The New Design Workflow,” and “To The Pattern Lab!” In addition to these sessions, I also attended a very informative BoF about CSS Style Guides lead by the one and only John Albin Wilkins. At ThinkShout, we already take a component-based approach to design, but I certainly learned some great new ideas and techniques!

  3. Longform Storytelling is the new black. As Drupal shifts its focus towards publishing and news, content creators are embracing rich longform articles and stories. According to Kristina Bjoran and Courtney Clark of Forum One, "People generally learn more and remember more when more of their senses are engaged by a story. Stories that include images get about twice the engagement as text-only stories. Stories told with visual elements are instantly captivating. The more senses that are engaged, the more emotions will be engaged and the more memorable the experience will be." We are including longform content features in many of our new client’s websites at ThinkShout, and it was really great to hear how other industry leaders do it successfully as well.

Design, Drupal, and the Future

Each year, the Drupal Association puts more thought into diversifying the session lineup, and it shows. There was a very conscious effort to get more design and UX content, as well as speakers from diverse experiences and backgrounds. To that, I say "Huzzah!" As someone who’s been designing Drupal sites for many years now, it’s great to see the design process being treated as more than just “making it look pretty.” Design and UX is now a core component of DrupalCon, and I’m proud to have helped along the way.

After a week of learning and sharing new ideas, meeting amazing people, and eating some darn good Mexican food, my brain is full and my heart is heavy. I can’t wait to see you all next year!

Catégories: Elsewhere

Annertech: 10 Top Drupal Modules to help increase SEO

jeu, 28/05/2015 - 14:04
10 Top Drupal Modules to help increase SEO "We want to rank number one on Google" - every client ever.
Catégories: Elsewhere

Jim Birch: Essential Drupal: The Style Guide Module

jeu, 28/05/2015 - 13:00

Site builders and front end themers rejoice at the greatness of the Drupal Style Guide module.  This module creates a page on your Drupal 6 or Drupal 7 site, displaying all the common html elements, and how your theme displays them.  It is a fantastic tool to work with your designer and client to show them the applied styles of your theme, and great for the themer to make sure you hit all the elements.

Hooking into the module is easy too.  If you have elements that you need to add, whether it be in a custom module or part of your theme, you can easily add more using hook_styleguide_alter().  You can also use the sub-module, Style guide palette to add colors to the style guide.  There is singular permission for whom can add those colors.

The only permission for Style Guide is to View theme style guides.  I've made this site's available to anonymous users, feel free to check it out at http://jimbir.ch/admin/appearance/styleguide

Read more

Catégories: Elsewhere

Drupal CMS Guides at Daymuse Studios: Utilizing the Power of the Play Button with Drupal

jeu, 28/05/2015 - 04:46

I'll show you how to add media overlays or watermarks with Drupal's ImageCache Actions module to create a call to action on image previews in this tutorial.

Catégories: Elsewhere

LevelTen Interactive: DrupalCon LA 2015: Roundtable Interviews

mer, 27/05/2015 - 22:33

A few weeks ago, the team was in Los Angeles for DrupalCon 2015. Our very own Kyle Taylor took his iPad and mic and interviewed developers, freelancers, and some of the top Drupal Agencies that attend the week long event. ... Read more

Catégories: Elsewhere

Lullabot: Making The Most Of Mobilegeddon

mer, 27/05/2015 - 22:30

On April 21, 2015, Google rolled out a set of changes to its search algorithm so sweeping it dubbed them "Mobilegeddon." Together, these updates dramatically boosted the impact of a site’s "mobile-friendliness" on its search rankings. Google says the changes will have "significant impact in our search results", though at least for now it only affects search results on mobile devices.

Catégories: Elsewhere

DrupalCon News: The Content Strategy Track: the Content Management System meets its purpose!

mer, 27/05/2015 - 20:08

This year, DrupalCon Europe will include a dedicated track on Content Strategy. Let me explain why this is exciting news and a unique opportunity!

Content Strategy has been around for several years now. It defines how we create, manage and maintain quality content that is used to obtain our project goals or answer user needs.

If you’re reading this, you are likely very familiar with Drupal as the leading professional Content Management System and framework.

Catégories: Elsewhere

OpenConcept: Best practices for generating patches and interdiffs

mer, 27/05/2015 - 17:27

I've often been asked how I generate both patches and interdiffs at the same time, because the instructions on drupal.org currently detail the two processes separately, and different documentation pages give different instructions.

So, I thought I'd share the process that works for me, providing real-world examples from an issue that I've worked on.

If you find a better process, please blog about it and post a link in the comments!

This tutorial assumes that:

  • You know what patchfiles are,
  • You know how to use the command-line (the instructions should work in both *NIX and Windows), and,
  • You have a beginner-level knowledge about Git.
High-level workflow overview

My patching workflow works roughly like this:

  1. Before you make a patch, make an issue to post it to.
  2. Make your patch in an environment that makes as few assumptions as possible. I use a fresh Drupal site installed with the Minimal install profile, and I only install the bare minimum set of modules that I need to make the module I want to patch work.
  3. To make the first patch in an issue:
    1. Before making any changes, make a new branch named after the NID of the issue and the comment number you intend to post the patch to.
    2. Make your changes and commit them to the new branch. If you make more than one commit, squash them down to a single commit when you feel that you're ready to post the patch.
    3. Generate a patchfile with git format-patch — this will add extra metadata to help Git and other humans in the future.
  4. If there are already patches in the issue, and the most-recent patch no longer applies, re-roll the old patch first and upload it, then make your changes in a separate patch.
  5. If there are already patches in the issue:
    1. Download the most-recent patch and commit its changes to a branch named after the NID of the issue and the comment number that you got the patchfile from.
      • If it no longer applies, re-roll and upload it first, then make your changes in a separate patch.
    2. Checkout the starting branch again.
    3. Make a new branch named after the NID of the issue and the comment number you intend to post the patch to.
    4. Apply the most-recent patch to the new branch but don't commit it yet.
    5. Make your changes in the new branch and commit them to the new branch. If you make more than one commit, squash them down to a single commit when you feel that you're ready to post the patch.
    6. Generate a patchfile with git format-patch — this will add extra metadata to help Git and other humans in the future.
    7. Generate an interdiff by git diff-ing against the branch from step 5a.

... if none of this makes sense yet, don't worry: I'll explain it below. Hopefully once you've run through it a couple of times, you can use this high-level overview as a reference.

Detailed workflow 1. Making a new issue

Before you make a patch, you should have an issue to post it to.

  1. Create a ticket on Drupal.org, and propose your changes.
    • Use the Issue summary template.
      • If you're reporting a bug, add a section with Steps to Reproduce the bug. This will help module maintainers see the need for your patch!
      • Especially for bug reports, it's helpful to compare what the module does now with what you want it to do. This also helps module maintainers see the problem.
    • Good metadata is important! I usually need to spend a bit of time finding a succinct Title, choosing the most-appropriate Category and Component, re-reading the guidelines for setting a Priority, and choosing good issue tags.
      • Since this is a new issue, and you haven't attached a patch yet, leave the issue status set to Active.
      • If you intend to provide a patch right away, you may assign the issue to yourself.
    • Take note of the node ID in the URL of the issue (e.g.: for https://www.drupal.org/node/2290031 the Node ID is 2290031) — you'll need it when patching.
2. Set up your environment for patching

Accidentally making assumptions about the Drupal site you're working on increases the risk that your patch will break other people's work, won't get accepted, will take a long time to be accepted, or will be rolled back later on. So, it's important to write your patch on an environment that makes as few assumptions as possible.

In some cases, trying to reproduce a problem (or adding a feature) in a clean environment will also help you to identify future problems, or see a solution that doesn't require patching.

  1. Set up a fresh Drupal site to write your patch on.
    • Use the Minimal install profile.
  2. Enable only the bare minimum set of modules that you need to make the module you want to patch work (e.g.: the Facet API module requires ctools and a search module, like core's search).
  3. Clone the module you want to patch (e.g.: git clone --branch 7.x-1.x http://git.drupal.org/project/facetapi.git).
    • You can copy and paste the Git command from the project page's Version control tab (e.g.: https://www.drupal.org/project/facetapi/git-instructions).
    • Take note of the branch you start from.
3. Making the first patch in an issue

The first patch to an issue does not need an interdiff.txt, but generating your first patch as follows makes generating interdiffs easier in the future.

  1. From the starting branch, create a new branch named after the Node ID of the issue and the comment number you intend to post it to (e.g.: 2290031-3 — git checkout -b 2290031-3).
    • The Node ID is in the URL of the issue (e.g.: for https://www.drupal.org/node/2290031 the Node ID is 2290031).
    • Note that if you're logged into Drupal.org, the "Add comment" section title shows the next comment number (e.g. Add comment #10).
  2. Make your changes in this branch, add them, and commit them.
    • If you make more than one commit, you'll need to squash it down to a single commit using git-rebase.
    • The commit message you enter here will be seen by others, but it will not be used as the final commit message. I simply enter the name of the branch (e.g.: git commit -m "2290031-3").
  3. Run git format-patch $starting_branch (e.g.: git format-patch 7.x-1.x).
    • This generates a patch file and places it in the repository.
    • Alternately, you could generate a patch with git diff $starting_branch, but I like git-format-patch better because it adds a bit of metadata that will help Git to apply your patch without someone having to re-roll it as often.
  4. Move the patch file out of the git repository to prevent you accidentally committing it later.
    • This is a good time to rename your patch.
    • Note that if you use Dreditor, you can use it to generate a patch name for you by clicking the Patchname suggestion button in the Files fieldset.
  5. Check out the starting branch, to prevent you from accidentally branching off it later.
  6. Upload the patch to the issue.
    • Don't forget to un-assign the issue! Many maintainers ignore assigned issues, regardless of what the issue's Status is, because they assume assigned issues have someone actively working on it right now.
    • Don't forget to set the Status to Needs review. This helps others to know there's a patch attached and that patch is ready for someone else to look at.
4. Re-rolling a patch

If the maintainer(s) have been making a lot of commits to the starting branch, git(1) or patch(1) may not be able to figure out how to apply the patch file any longer. If this happens, the patch will need to be rerolled.

If you're making a subsequent patch to an issue, and the previous patch doesn't apply, re-roll the patch first, then make your changes in a separate patch. Doing so makes it easier for both you to generate interdiffs; and it makes it easier for the maintainer(s) (and anyone else following the issue) to understand what's going on.

  1. Make sure your repository is up-to-date (git pull).
  2. Download the most-recent patch.
  3. Double-check whether it is necessary to re-roll the patch (git apply --check /path/to/most-recent.patch).
    • If you see nothing, then the patch does not need to be re-rolled and you can skip this section entirely.
    • If you see error: patch failed, then you will need to re-roll the patch.
  4. Find when the most-recent patch was made.
    • If the most-recent patch was made with git-format-patch, the first line of the patchfile (From $commit_id $date) will tell you everything you need to know. Take note of the commit ID and jump down to step 6.
    • If the commit ID or date is not available in the patchfile, you can get a rough guess by looking at the date-stamp on the comment that the most-recent patch was uploaded in will work instead.
      • Sometimes Drupal.org displays the time since the comment was posted (e.g.: "yesterday"). Double-click to change to an exact date.
    • Take note of how to write the date in ISO 8601 format (yyyy-mm-dd, e.g.: 2014-06-20).
  5. Search git log to find a commit from that day or earlier (git log --before=$iso_8601_date e.g.: git log --before=2014-06-20).
    • Take note of the commit ID (e.g.: 9e26034949aac609bb8537ef5a189033a3665baa).
  6. Check out the commit ID (e.g.: git checkout 9e26034949aac609bb8537ef5a189033a3665baa).
    • Git will tell you that You are in 'detached HEAD' state. This is okay.
  7. Create a new branch named after the Node ID of the issue and the comment number you intend to post it to (e.g.: 2290031-6 — git checkout -b 2290031-6).
  8. Apply the patch (git apply --index /path/to/most-recent.patch e.g.: git apply --index make_inactive_active-2290031-4.patch).
  9. Commit the patch.
    • The commit message you enter here will be seen by others, but it will not be used as the final commit message. I simply enter the name of the branch (e.g.: git commit -m "2290031-6").
  10. Rebase the branch onto the most-recent commit of the starting branch: git rebase --onto $starting_branch (e.g.: git rebase --onto 7.x-1.x).
    • You might get merge conflicts. If you do, fix them, taking notes on what you did, and follow Git's instructions for finishing the rebase.
    • In rare cases, if you get merge conflicts, it's because the maintainer(s) significantly changed how the code works. If this is the case, you might have to about the rebase and start the patch fresh (see 3. Making the first patch in an issue). Make sure to very clearly state in the comment where you post the patch that you tried re-rolling but the code had changed too much and you were forced to start from scratch.
  11. If and only if the rebase completed successfully, run git format-patch $starting_branch (e.g.: git format-patch 7.x-1.x).
    • This generates a patch file and places it in the repository.
    • Alternately, you could generate a patch with git diff $starting_branch, but I like git-format-patch better because it adds a bit of metadata that will help Git to apply your patch without someone having to re-roll it as often.
  12. Move the patch file out of the git repository to prevent you accidentally committing it later.
    • This is a good time to rename your patch.
    • Note that if you use Dreditor, you can use it to generate a patch name for you by clicking the Patchname suggestion button in the Files fieldset.
  13. Check out the starting branch, to prevent you from accidentally branching off it later (git checkout $starting_branch, e.g.: git checkout 7.x-1.x).
  14. Upload the patch to the issue.
    • Don't forget to un-assign the issue! Many maintainers ignore assigned issues, regardless of what the issue's Status is, because they assume assigned issues have someone actively working on it right now.
    • Don't forget to set the Status to Needs review. This helps others to know there's a patch attached and that patch is ready for someone else to look at.
    • Make sure you very clearly state that you are just re-rolling and there are no changes (or, if you got merge conflicts, state how you resolved them and why).
5. Making a subsequent patch in an issue

If there's already a patch in an issue, and you want to change it, you will need to generate an interdiff to help the maintainer(s) understand what you're changing.

  1. Make sure your repository is up-to-date (git pull).
  2. Download the most-recent patch.
  3. Create a new branch named after the Node ID of the issue and the comment number of the most-recent patch (e.g.: 2290031-6 — git checkout -b 2290031-6).
    • If you generated the last patch and the branch is still in your repository, you can skip down to step 7.
  4. Apply the patch (git apply --index /path/to/most-recent.patch e.g.: git apply --index make_inactive_active-2290031-6.patch).
  5. Commit the patch.
    • I simply enter the name of the branch (e.g.: git commit -m "2290031-6").
  6. Checkout the starting branch (git checkout $starting_branch, e.g.: git checkout 7.x-1.x).
  7. Create a new branch named after the Node ID of the issue and the comment number you intend to post it to (e.g.: 2290031-7 — git checkout -b 2290031-7).
  8. Apply the patch again (git apply --index /path/to/most-recent.patch e.g.: git apply --index make_inactive_active-2290031-6.patch).
    • If you want to take the patch in an entirely new direction, you can skip this step, but you should have a really good reason for throwing away other people's work (which they might have volunteered), and you should very clearly state those reasons in the comment you post in step 15. Make sure you follow the Drupal Code of Conduct.
  9. Make your changes in this branch, add them, and commit them.
    • If you make more than one commit, you'll need to squash it down to a single commit using git-rebase.
    • The commit message you enter here will be seen by others, but it will not be used as the final commit message. I simply enter the name of the branch (e.g.: git commit -m "2290031-7").
  10. Run git format-patch $starting_branch (e.g.: git format-patch 7.x-1.x).
    • This generates a patch file and places it in the repository.
    • Alternately, you could generate a patch with git diff $starting_branch, but I like git-format-patch better because it adds a bit of metadata that will help Git to apply your patch without someone having to re-roll it as often.
  11. Move the patch file out of the git repository to prevent you accidentally committing it later.
    • This is a good time to rename your patch.
    • Note that if you use Dreditor, you can use it to generate a patch name for you by clicking the Patchname suggestion button in the Files fieldset.
  12. Generate an interdiff (git diff $previous_patch_branch > interdiff.txt e.g.: git diff 2290031-6).
  13. Move the interdiff out of the git repository to prevent you accidentally committing it later.
    • Interdiffs are usually just named interdiff.txt, regardless of what issue number or comments they relate to, so take careful note of where you move it to so that you don't confuse it with another interdiff later.
  14. Check out the starting branch, to prevent you from accidentally branching off it later (git checkout $starting_branch, e.g.: git checkout 7.x-1.x).
  15. Upload both the patch and the interdiff to the issue.
    • Don't forget to un-assign the issue! Many maintainers ignore assigned issues, regardless of what the issue's Status is, because they assume assigned issues have someone actively working on it right now.
    • Don't forget to set the Status to Needs review. This helps others to know there's a patch attached and that patch is ready for someone else to look at.
    • Make sure you upload the correct interdiff! Interdiffs are usually just named interdiff.txt, regardless of what issue number or comments they relate to, so make sure you upload the right one!
  16. Delete the interdiff.txt so you don't get confused and upload an old interdiff later.
Conclusion

I'm posting this in the hopes that it will help others in the future. If you have questions, ask them in the comments and I'll try to answer them and update the blog post with corrections, so you can refer to this post in the future without digging through the comments as well.

Topic: 
Catégories: Elsewhere

Pages