oliverdavies.uk/content/node.6d12e45b-2c1f-4931-9dcf-c96084d99c8f.yml

86 lines
4.1 KiB
YAML
Raw Normal View History

2025-07-10 00:14:12 +01:00
uuid:
- value: 6d12e45b-2c1f-4931-9dcf-c96084d99c8f
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:24+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: |
Reuse what you can.
created:
- value: '2024-01-04T00:00:00+00:00'
changed:
- value: '2025-05-11T09:00:24+00:00'
promote:
- value: false
sticky:
- value: false
default_langcode:
- value: true
revision_translation_affected:
- value: true
path:
- alias: /daily/2024/01/04/reuse-what-you-can
langcode: en
body:
- value: |
<p>A lot is different between Drupal 7 and 10, with the introduction of Composer, object-orientated code, Symfony components and other third-party libraries, to name a few things.</p>
<p>But, when upgrading a project, the business logic may not need to change.</p>
<p>How it integrates with the new version of Drupal may change - it may use a different module, such as Paragraphs instead of Field Collection, or be within a Controller or Service class instead of a Drupal "hook", but if the majority of the logic can remain the same, it might as well be reused instead of written from scratch.</p>
<p>Presumably, it works as it does in Drupal 7, which may not be the case after it's been rewritten, as bugs and issues may have been introduced.</p>
<p>This is the approach I took when migrating the Override Node Options module to Drupal 8. I picked a test, migrated it from SimpleTest (Drupal 7) to PHPUnit (Drupal 8), ported enough code to make it pass, and moved to the next test.</p>
<p>Most custom applications, though, tend to be rewritten and the old business logic discarded.</p>
<h2 id="here%27s-the-thing">Here's the thing</h2>
<p>If it works, why rewrite it?</p>
<p>Migrate what you can and only rewrite what you need.</p>
<p>As someone who works on fixed-price projects and includes a bug-free guarantee, it's in my interests to deliver working and stable software as soon as possible, which is also in my client's interests as they get their new software sooner and not from a drawn-out process where everything is re-done from scratch.</p>
format: full_html
processed: |
<p>A lot is different between Drupal 7 and 10, with the introduction of Composer, object-orientated code, Symfony components and other third-party libraries, to name a few things.</p>
<p>But, when upgrading a project, the business logic may not need to change.</p>
<p>How it integrates with the new version of Drupal may change - it may use a different module, such as Paragraphs instead of Field Collection, or be within a Controller or Service class instead of a Drupal "hook", but if the majority of the logic can remain the same, it might as well be reused instead of written from scratch.</p>
<p>Presumably, it works as it does in Drupal 7, which may not be the case after it's been rewritten, as bugs and issues may have been introduced.</p>
<p>This is the approach I took when migrating the Override Node Options module to Drupal 8. I picked a test, migrated it from SimpleTest (Drupal 7) to PHPUnit (Drupal 8), ported enough code to make it pass, and moved to the next test.</p>
<p>Most custom applications, though, tend to be rewritten and the old business logic discarded.</p>
<h2 id="here%27s-the-thing">Here's the thing</h2>
<p>If it works, why rewrite it?</p>
<p>Migrate what you can and only rewrite what you need.</p>
<p>As someone who works on fixed-price projects and includes a bug-free guarantee, it's in my interests to deliver working and stable software as soon as possible, which is also in my client's interests as they get their new software sooner and not from a drawn-out process where everything is re-done from scratch.</p>
summary: null
field_daily_email_cta: { }