uuid: - value: 99c87aed-1bac-4f19-9ae2-15e2ccd9cd02 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:03+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: 'Easy feature flags' created: - value: '2024-12-22T00:00:00+00:00' changed: - value: '2025-05-11T09:00:03+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2024/12/22/feature-flags langcode: en body: - value: |

I recently switched to self hosting the MP3 files for the episodes of the Beyond Blocks podcast.

The first step was to upload the files, followed by updating the player on the episode pages to use the HTML audio element.

As I didn't want the player to switch immediately, I wrapped the new code in a feature flag (or feature toggle) to keep the original player active.

Later, I could swap the player by enabling the feature flag.

How I did it

Feature flagging is a straight forward concept.

You isolate the code you want to be togglable within a conditional - i.e. an if statement - that you can easily change in the future.

My website built with Sculpin, so I can add self_host_podcast_episodes: false to my sculpin_site.yml file.

This will be available as site.self_host_podcast_episodes and I can use this in my code to show the appropriate player.

Something like:

{% if site.self_host_podcast_episodes %}
        Show the new player.
      {% else %}
        Show the old player.
      {% endif %}

Here's the thing

I like feature flags as you can separate deploying a feature from releasing it.

The code can be deployed but not active until the feature is enabled.

It's easy to enable, and easy to revert if needed.

In Drupal applications, I use the Feature Toggle module, so I can toggle feature flags by logging in and updating a checkbox.

I also wrote a module with a Twig function so I can check if a feature toggle is enabled directly in a Twig template - the same as I'm doing in Sculpin.

format: full_html processed: |

I recently switched to self hosting the MP3 files for the episodes of the Beyond Blocks podcast.

The first step was to upload the files, followed by updating the player on the episode pages to use the HTML audio element.

As I didn't want the player to switch immediately, I wrapped the new code in a feature flag (or feature toggle) to keep the original player active.

Later, I could swap the player by enabling the feature flag.

How I did it

Feature flagging is a straight forward concept.

You isolate the code you want to be togglable within a conditional - i.e. an if statement - that you can easily change in the future.

My website built with Sculpin, so I can add self_host_podcast_episodes: false to my sculpin_site.yml file.

This will be available as site.self_host_podcast_episodes and I can use this in my code to show the appropriate player.

Something like:

{% if site.self_host_podcast_episodes %}
        Show the new player.
      {% else %}
        Show the old player.
      {% endif %}

Here's the thing

I like feature flags as you can separate deploying a feature from releasing it.

The code can be deployed but not active until the feature is enabled.

It's easy to enable, and easy to revert if needed.

In Drupal applications, I use the Feature Toggle module, so I can toggle feature flags by logging in and updating a checkbox.

I also wrote a module with a Twig function so I can check if a feature toggle is enabled directly in a Twig template - the same as I'm doing in Sculpin.

summary: null field_daily_email_cta: { }