Patch information shown in update report

Description

The PatchInfo module allows you to add information about patches to a module's .info.yml file. It will show the information prominently in the update report and on the update manager form. See the documentation on the project page or in the README file on how to set this up for Drupal 7 or Drupal 8.

You can also exclude a module from the update check, by specifying the machine readable name of the module on the (extended) update manager settings form.

The module comes with basic Drush integration, i.e. a command to list patches on the whole system or for a specific module in several different formats.

We have used this successfully on numerous Drupal 7 sites to track patches in contributed modules and core. The idea is to have a simple way for developers to add information about patches and have these available prominently in the key places you would check before doing core or module updates. It has served us well over the years and I think it might be useful for other people in the community, too. I just finished the port to Drupal 8, so it might not be as stable as the D7 version, although I did test thoroughly.

Similar projects and how they are different

  • Patch Manager: Comprehensive solution to manage patches via UI, may have security implications, if used on production sites (per project page of module).
  • Drush Make files: Powerful way to build a whole site from a text file, allows you to manage and apply your patches on the way.

Projet page

https://www.drupal.org/sandbox/feyp/2556153

git clone

git clone --branch 8.x-1.x http://git.drupal.org/sandbox/feyp/2556153.git patchinfo

Reviews of other projects

  1. custom_email_template
  2. agegate
  3. sidecomments_now
  4. webform_replay
  5. views_exposed_filters_summary

I will add more reviews here as they are done.

Comments

FeyP created an issue. See original summary.

PA robot’s picture

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

I'm a robot and this is an automated message from Project Applications Scraper.

feyp’s picture

Issue summary: View changes

Added review of custom_email_temaplte.

feyp’s picture

Issue summary: View changes

Added review of agegate.

feyp’s picture

Issue summary: View changes
Issue tags: +PAreview: review bonus

Added review of sidecomments_now and review bonus tag, since it is the 3rd review.

developerchris’s picture

Disclaimer: I am new to reviewing modules so please bear with my mistakes.

I am interested in what you are trying to achieve here do you envisage an automated process to insert issue patches into .info and .info.yml files?

You say you have been using this system yourself for some time. I am curious if no-one else is using the system how are you able to use it?

Please Note: I have not attempted to review the [D8] Code as I have no experience in [D8]

Manual Review [D7]

Individual user account
Yes: Follows the guidelines for individual user accounts.
No duplication
Yes: Does not cause module duplication and/or fragmentation.
Master Branch
Yes: Follows the guidelines for master branch.
Licensing
Yes: Follows the licensing requirements.
3rd party assets/code
Yes: Follows the guidelines for 3rd party assets/code.
README.txt/README.md
Yes: Follows the guidelines for in-project documentation and/or the README Template.
Code long/complex enough for review
Yes: Follows the guidelines for project length and complexity.
Secure code
Yes: Meets the security requirements.

joachim’s picture

Please compare with https://www.drupal.org/project/patch_status.

It looks like these are rather similar.

klausi’s picture

Assigned: Unassigned » stborchert
Status: Needs review » Reviewed & tested by the community
Issue tags: -PAreview: review bonus

manual review:

  1. patchinfo_form_alter(): you should split this up into 2 hook_form_FORM_ID_alter() hooks for clarity.
  2. patchinfo_form_alter(): do not call the renderer here, just add to the nested form render array. Drupal core will render it later for you. Don't use #markup, just add $patch_list to $form.
  3. Please add the differences to https://www.drupal.org/project/patch_status to the project page. Instead of publishing yet another module please improve the existing module which already does a similar job. Module duplication and fragmentation is a huge problem on drupal.org and we prefer collaboration over competition.

Otherwise looks good to me. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

Assigning to stBorchert as he might have time to take a final look at this.

joachim’s picture

Status: Reviewed & tested by the community » Needs work
klausi’s picture

Status: Needs work » Reviewed & tested by the community

Duplication is bad but not an application blocker, anything else that you found or should this stay RTBC?

feyp’s picture

Hi everyone, sorry for not following up sooner.

@DeveloperChris: Thank you for your review! Let me address your question:

I am interested in what you are trying to achieve here do you envisage an automated process to insert issue patches into .info and .info.yml files? You say you have been using this system yourself for some time. I am curious if no-one else is using the system how are you able to use it?

You could certainly create a script, that will automatically update the info file once you apply a patch. But that's not how we use the module. Originally, we documented all patches we applied to a system outside of Drupal (i.e. in a wiki). Every time a patch was applied, a developer would hopefully remember to log in to that wiki and update the documentation. Once there was an update for a system, we would check the wiki first. This was quite a little bit of overhead and sometimes, people would forget to update or check the wiki. So we built this module. The idea was to make it as quick as possible for a developer to document patches. Since you're already in the module folder on the command line anyway, when you apply a patch, it isn't that much of a hassle to quickly edit the info file along the way. Once the patch is added by a developer, it will also be added to version control and deployed to other systems. Less overhead for the developer and for our update team.

Please compare with https://www.drupal.org/project/patch_status. It looks like these are rather similar.

@joachim: Thanks for pointing this out! Obviously, I wasn't aware of patch_status when I posted the application. I have looked at the module and they are indeed quite similar, although there are some differences. As far as I can see, apart from the different approach for tracking patches (patch files on the file system vs. info file), the most important differences are:

  • With PatchInfo you can link to patches outside of drupal.org and use custom descriptions for your patches. You could also add random notes, like "Before you update, check x/do y".
  • PatchInfo will show your patches not only on the update report, but also on the update manager form.
  • With PatchInfo you can exclude some modules from the update check entirely.
  • PatchInfo features a Drush integration, that can list your patches in multiple different ways.
  • PatchInfo has a Drupal 8 version.

If I'm wrong on any of this, feel free to correct me ;). It seems that the maintainer is currently in the process of creating a pluggable patch detection system. Once that is finished, I might indeed extend that module so that it works for our use case.

I was actually in the process of preparing another module for review, because I was, like you, under the impression, that this might be a blocker for the application. But then klausi beat me to it with his review ;). Actually, I don't care that much about the module, but I'd like to be able to publish some of our modules on drupal.org, so that we might give a little bit back to the community. At the time I opened the application, I thought that patchinfo would be a good fit as I wasn't aware of patch_status. Since klausi and others have kindly invested their time into a review and it seems like we are almost finished now, I think it makes sense to continue the application despite the similarity to patch_status at this time and not start all over again with another module. Again, if anyone has different views on this, please let me know.

@klausi: Thank you very much for your review! I have made the changes you suggested and also added a section about patch_status to the project page.

feyp’s picture

Issue summary: View changes
feyp’s picture

Issue summary: View changes

Added review of views_exposed_filters_summary.

klausi’s picture

Assigned: stborchert » Unassigned
Status: Reviewed & tested by the community » Fixed

no other objections for more than a week, so ...

Thanks for your contribution, Patrick!

I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.

Here are some recommended readings to help with excellent maintainership:

You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

Thanks to the dedicated reviewer(s) as well.

feyp’s picture

Thank you @klausi!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

avpaderno’s picture

Title: [D8][D7] PatchInfo » [D8] PatchInfo
Issue summary: View changes