{
    "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": "\n          <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>\n\n<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>\n\n<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>\n\n<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>\n\n<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>\n\n<p>For example, in my composer.json file, I can add something like this:<\/p>\n\n<pre><code class=\"json\">\"extra\": {\n    \"patches\": {\n        \"drupal\/default_content\": {\n            \"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\",\n            \"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\"\n        }\n    },\n},\n<\/code><\/pre>\n\n<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>\n\n<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>\n\n<p>And this works for core and contrib projects.<\/p>\n\n<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>\n\n        ",
            "format": "full_html",
            "processed": "\n          <p>Yesterday I wrote about <a href=\"http:\/\/default\/daily\/2025\/01\/13\/patches\">how I used a patch file to customise a project in my Nix configuration<\/a>.<\/p>\n\n<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>\n\n<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>\n\n<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>\n\n<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>\n\n<p>For example, in my composer.json file, I can add something like this:<\/p>\n\n<pre><code class=\"json\">\"extra\": {\n    \"patches\": {\n        \"drupal\/default_content\": {\n            \"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\",\n            \"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\"\n        }\n    },\n},\n<\/code><\/pre>\n\n<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>\n\n<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>\n\n<p>And this works for core and contrib projects.<\/p>\n\n<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>\n\n        ",
            "summary": null
        }
    ]
}