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: |
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.
But, when upgrading a project, the business logic may not need to change.
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.
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.
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.
Most custom applications, though, tend to be rewritten and the old business logic discarded.
If it works, why rewrite it?
Migrate what you can and only rewrite what you need.
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.
format: full_html processed: |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.
But, when upgrading a project, the business logic may not need to change.
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.
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.
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.
Most custom applications, though, tend to be rewritten and the old business logic discarded.
If it works, why rewrite it?
Migrate what you can and only rewrite what you need.
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.
summary: null field_daily_email_cta: { }