Migrate content to YAML

content/node.c58749a0-bec2-415b-aa25-33eca5cce8b7.yml

@@ -0,0 +1,76 @@
+uuid:
+  - value: c58749a0-bec2-415b-aa25-33eca5cce8b7
+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:16+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: 'Releasing a new project one page at a time'
+created:
+  - value: '2024-04-02T00:00:00+00:00'
+changed:
+  - value: '2025-05-11T09:00:16+00:00'
+promote:
+  - value: false
+sticky:
+  - value: false
+default_langcode:
+  - value: true
+revision_translation_affected:
+  - value: true
+path:
+  - alias: /daily/2024/04/02/releasing-a-new-project-one-page-at-a-time
+    langcode: en
+body:
+  - value: |
+      <p>How do you release a new project?</p>
+
+      <p>Do you build everything and release everything at once?</p>
+
+      <p>I've used the strategy of building and releasing it a page at a time and running two versions simultaneously.</p>
+
+      <p>The main live version stays running, and you use a tool like NGINX or Cloudflare as a gatekeeper to direct traffic to the correct application - either the current one or the new one - based on the requested page.</p>
+
+      <p>When a page is ready, you add it to the list of pages to serve from the new application to put it live.</p>
+
+      <p>If there's an issue, it is also easy to revert to the original page.</p>
+
+      <p>I've used this approach with my website and for client Drupal upgrade projects, where some pages are on Drupal 7 and some on Drupal 10.</p>
+
+      <p>It's not the right approach for every situation, but it's a useful one to have in the toolkit.</p>
+
+              
+    format: full_html
+    processed: |
+      <p>How do you release a new project?</p>
+
+      <p>Do you build everything and release everything at once?</p>
+
+      <p>I've used the strategy of building and releasing it a page at a time and running two versions simultaneously.</p>
+
+      <p>The main live version stays running, and you use a tool like NGINX or Cloudflare as a gatekeeper to direct traffic to the correct application - either the current one or the new one - based on the requested page.</p>
+
+      <p>When a page is ready, you add it to the list of pages to serve from the new application to put it live.</p>
+
+      <p>If there's an issue, it is also easy to revert to the original page.</p>
+
+      <p>I've used this approach with my website and for client Drupal upgrade projects, where some pages are on Drupal 7 and some on Drupal 10.</p>
+
+      <p>It's not the right approach for every situation, but it's a useful one to have in the toolkit.</p>
+
+              
+    summary: null
+field_daily_email_cta: {  }