oliverdavies.uk/content/node.84ede6fa-2682-4edf-8b22-ee603de0b8c7.yml

uuid:
  - value: 84ede6fa-2682-4edf-8b22-ee603de0b8c7
langcode:
  - value: en
type:
  - target_id: daily_email
    target_type: node_type
    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
  - value: '2025-05-11T09:00:02+00:00'
revision_uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
revision_log: {  }
status:
  - value: true
uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
title:
  - value: 'Patching Drupal'
created:
  - value: '2025-01-14T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:02+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2025/01/14/patching-drupal
    langcode: en
body:
  - value: |
      <p>Yesterday I wrote about <a href="/daily/2025/01/13/patches">how I used a patch file to customise a project in my Nix configuration</a>.</p>

      <p>I'm familiar with patch files from my Drupal contributions, when we used to create and upload patch files and attach them to issues to contribute changes.</p>

      <p>Although patches aren't used to contribute to Drupal any more, you can still apply patches to Drupal code in your own projects if you need to.</p>

      <p>If there's a customisation or fix you need you need to apply, instead of altering and "hacking" the source files, you can apply changes with patch files.</p>

      <p>Instead of Nix, I use <a href="https://github.com/cweagans/composer-patches">composer-patches</a> to automatically apply patches when running <code>composer install</code>.</p>

      <p>For example, in my composer.json file, I can add something like this:</p>

      <pre><code class="json">"extra": {
          "patches": {
              "drupal/default_content": {
                  "Issue #2698425: Do not reimport existing entities (https://www.drupal.org/project/default_content/issues/2698425#comment-15593214)":  "patches/default_content-2698425-do-not-reimport-196.patch",
                  "Issue #3160146: Add a Normalizer and Denormalizer to support Layout Builder (https://www.drupal.org/project/default_content/issues/3160146#comment-14814050)": "patches/default_content-3160146-53.patch"
              }
          },
      },
      </code></pre>

      <p>This will apply these two patch files to the Default Content module (which are the same as running <code>git diff</code> between two commits), which I needed to do for a recent project.</p>

      <p>If the upstream issue is fixed and the patch is no longer needed, they can be removed and the module can be updated to the latest version.</p>

      <p>And this works for core and contrib projects.</p>

      <p>The same as the tmux-sessionizer example, this approach means I can apply any changes without needing to duplicate or alter the code, and it makes it easy to contribute by testing other people's patches or applying and contributing your own.</p>

              
    format: full_html
    processed: |
      <p>Yesterday I wrote about <a href="/daily/2025/01/13/patches">how I used a patch file to customise a project in my Nix configuration</a>.</p>

      <p>I'm familiar with patch files from my Drupal contributions, when we used to create and upload patch files and attach them to issues to contribute changes.</p>

      <p>Although patches aren't used to contribute to Drupal any more, you can still apply patches to Drupal code in your own projects if you need to.</p>

      <p>If there's a customisation or fix you need you need to apply, instead of altering and "hacking" the source files, you can apply changes with patch files.</p>

      <p>Instead of Nix, I use <a href="https://github.com/cweagans/composer-patches">composer-patches</a> to automatically apply patches when running <code>composer install</code>.</p>

      <p>For example, in my composer.json file, I can add something like this:</p>

      <pre><code class="json">"extra": {
          "patches": {
              "drupal/default_content": {
                  "Issue #2698425: Do not reimport existing entities (https://www.drupal.org/project/default_content/issues/2698425#comment-15593214)":  "patches/default_content-2698425-do-not-reimport-196.patch",
                  "Issue #3160146: Add a Normalizer and Denormalizer to support Layout Builder (https://www.drupal.org/project/default_content/issues/3160146#comment-14814050)": "patches/default_content-3160146-53.patch"
              }
          },
      },
      </code></pre>

      <p>This will apply these two patch files to the Default Content module (which are the same as running <code>git diff</code> between two commits), which I needed to do for a recent project.</p>

      <p>If the upstream issue is fixed and the patch is no longer needed, they can be removed and the module can be updated to the latest version.</p>

      <p>And this works for core and contrib projects.</p>

      <p>The same as the tmux-sessionizer example, this approach means I can apply any changes without needing to duplicate or alter the code, and it makes it easy to contribute by testing other people's patches or applying and contributing your own.</p>

              
    summary: null
field_daily_email_cta: {  }