{"id":64713,"date":"2024-09-07T12:21:06","date_gmt":"2024-09-07T06:51:06","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=64713"},"modified":"2024-09-09T10:43:25","modified_gmt":"2024-09-09T05:13:25","slug":"mastering-configuration-synchronization-in-drupal-10","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/mastering-configuration-synchronization-in-drupal-10\/","title":{"rendered":"Mastering Configuration Synchronization in Drupal 10"},"content":{"rendered":"

Introduction<\/strong><\/h2>\n

Drupal’s Configuration Management system, introduced in Drupal 8 and refined in Drupal 10, allows developers to manage site configurations in a standardized and predictable manner. Whether you are working in a team or managing multiple environments (like development, staging, and production), Configuration Synchronization ensures consistency and reliability across all setups. This blog will guide you through the entire process of Configuration Synchronization in Drupal 10, covering necessary modules, commands, and best practices.<\/p>\n


\nWhat is Drupal Configuration Synchronization?<\/strong><\/h2>\n

Drupal Configuration Synchronization is the process of managing and synchronizing site configuration between different environments (e.g., development, staging, production). Configuration in Drupal refers to settings that determine how a site behaves, including content types, views, fields, and user permissions. Unlike content, which changes frequently and is stored in the database, configuration is more stable and is typically managed as code.<\/p>\n

Configuration synchronization ensures that the settings and configuration across multiple environments are consistent, allowing for predictable behavior and reducing the chances of configuration drift, where different environments might have different settings due to manual changes or oversight.<\/p>\n


\nWhy Do We Need Configuration Synchronization?<\/strong><\/h2>\n

Configuration synchronization is essential for several reasons:<\/p>\n

    \n
  • Consistency Across Environments: It ensures that all environments (development, staging, production) are identical in terms of configuration, which is crucial for testing and deploying updates.<\/li>\n
  • Version Control: By exporting configuration into code, it can be versioned using Git or another version control system, allowing teams to track changes, roll back to previous versions, and collaborate more effectively.<\/li>\n
  • Disaster Recovery: In case of accidental deletion or misconfiguration, you can quickly restore the site to a previous state using the configuration stored in the code.<\/li>\n
  • Deployment: When deploying changes from a development environment to production, configuration synchronization makes it easy to apply these changes without manual intervention, reducing the risk of errors.<\/li>\n
  • Rapid Development: Configuration synchronization allows for the reuse of configurations across different environment and reduce development cost.<\/li>\n<\/ul>\n


    \nUnderstanding Drupal Configuration<\/strong><\/h2>\n

    In Drupal 10, configuration data is stored in YAML files. These files contain settings for content types, views, taxonomy vocabularies, and more. The configuration is stored in the config directory within the site\u2019s files directory, typically located at sites\/default\/files\/config_HASH\/sync, where HASH is a unique identifier generated by Drupal.<\/p>\n

    When you export your site\u2019s configuration, Drupal writes these settings into YAML files that can be stored in a version control system. Conversely, importing configuration reads these files and applies the settings to the site.<\/p>\n


    \nWhat Data Will Be Considered as Configuration?<\/strong><\/h2>\n

    In Drupal, the State API<\/strong> is used to store temporary or internal site information that isn\u2019t part of the site\u2019s main configuration. This data is not meant to be synchronized across different environments like development or production. Instead, it’s used for things that are specific to a particular environment or session.<\/p>\n

    State Data vs. Configuration Data:<\/strong><\/h3>\n
      \n
    • Configuration Data:<\/strong> These are settings that define how your site works, like content types, views, and user permissions. This data is stored in YAML files and synchronized across all your environments.<\/li>\n
    • State Data:<\/strong> This is more like temporary or environment-specific information. It\u2019s saved in the database and is not synchronized across environments.<\/li>\n<\/ul>\n

      Examples of Configuration Data:<\/strong><\/h3>\n
        \n
      • Content Types:<\/strong> Definitions of different content types like Articles or Events.<\/li>\n
      • Views:<\/strong> Configurations for custom views, such as lists of content or user profiles.<\/li>\n
      • Taxonomy Vocabularies:<\/strong> Definitions of terms and categories used for tagging content.<\/li>\n
      • User Roles and Permissions:<\/strong> Settings that control user access and permissions on the site.<\/li>\n
      • Menu Structures:<\/strong> Configuration for the main navigation menu and submenus.<\/li>\n<\/ul>\n

        Examples of State Data:<\/strong><\/h3>\n
          \n
        • Last Cron Run Time:<\/strong> Records when the last automated task (cron job) was performed.<\/li>\n
        • Module Settings:<\/strong> Temporary settings used by modules, such as feature toggles or user preferences.<\/li>\n
        • User Login Status:<\/strong> Information related to active user sessions or login statuses.<\/li>\n
        • Cache Data:<\/strong> Data stored temporarily to improve site performance, like cached views or pages.<\/li>\n
        • Temporary File Paths:<\/strong> Paths for files used temporarily during operations, like import\/export tasks.<\/li>\n<\/ul>\n


          \nConfiguration Management System in Drupal<\/strong><\/h2>\n

          Drupal\u2019s Configuration Management System (CMS) revolves around the concept of the active configuration and the staged configuration.
          \nActive Configuration:<\/strong> This is the configuration that the site is currently using. It is stored in the database and is automatically updated when you make changes through the Drupal UI.<\/p>\n

          Staged Configuration:<\/strong> This refers to a configuration that has been exported to YAML files and is ready to be imported back into the site. The staged configuration is typically stored in the sync directory.<\/p>\n

          The Config file locations are mapped in the\u00a0settings.php\u00a0file, It is recommended to have the configuration files out of the root directory.<\/p>\n

          $settings['config_sync_directory'] = '..\/config\/sync';<\/pre>\n

          \nConfiguration Workflow<\/strong><\/h2>\n
          The typical workflow for managing configuration in Drupal involves three main steps: exporting, versioning, and importing.
          \nExport Configuration:<\/strong> Export the current site configuration to YAML files.
          \nVersion Configuration:<\/strong> Add the exported files to version control (e.g., Git) and push changes to a remote repository.
          \nImport Configuration:<\/strong> Import the configuration on another environment (e.g., staging or production) to apply the changes.<\/p>\n

          \nConfiguration Export<\/strong><\/h2>\n
          Exporting configuration is the first step in the configuration management workflow. This process writes the active configuration to YAML files in the sync directory.<\/p>\n
          Exporting Configuration<\/strong><\/p>\n
            \n
          1. Navigate to the site\u2019s admin interface: Configuration<\/strong> > Development<\/strong> > Configuration synchronization.<\/strong><\/li>\n
          2. Click on the Export<\/strong> tab.<\/li>\n
          3. You can export the entire configuration or specific parts of it.<\/li>\n
          4. Click Export to download the tar.gz file containing all the YAML configuration files.<\/li>\n<\/ol>\n
            \"synchronization\"
            drupal config export<\/p><\/div>\n
            Alternatively, you can use Drush, a command-line shell and scripting interface for Drupal, to export configuration:\r\n\r\ndrush config-export OR drush cex\r\n\r\n<\/pre>\n
            \"drush-cex\"
            config export<\/p><\/div>\n
            This command exports the entire configuration to the sync directory.<\/p>\n

            \nConfiguration Import<\/strong><\/h2>\n
            After exporting and versioning the configuration, you\u2019ll want to import it into another environment. This process reads the YAML files from the sync directory and updates the active configuration in the database.<\/p>\n
            Importing Configuration<\/strong><\/p>\n
              \n
            1. Navigate to the site\u2019s admin interface: Configuration<\/strong> > Development<\/strong> > Configuration synchronization.<\/strong><\/li>\n
            2. Click on the Import<\/strong> tab.<\/li>\n
            3. You can choose to import the entire configuration or specific parts.<\/li>\n
            4. If you are importing a complete set of configurations, make sure you have the relevant YAML files prepared.<\/li>\n
            5. Upload the tar.gz file containing the YAML configuration files. This file is usually the result of a configuration export from another environment.<\/li>\n<\/ol>\n
              \"config
              drupal config import<\/p><\/div>\n
              Alternatively, you can use Drush, a command-line shell and scripting interface for Drupal, to import configuration:\r\n\r\ndrush config-import OR drush cim\r\n\r\n<\/pre>\n
              This command imports the configuration from the sync directory and applies it to the active configuration.<\/p>\n

              \nConfig Split<\/strong><\/h2>\n
              Config Split is a contributed module in Drupal that allows for the management of different configurations in different environments. It is particularly useful for handling configurations that should vary between environments (e.g., development, staging, and production).<\/p>\n
              you can install config split module using command line -\r\n\r\ncomposer require drupal\/config_split\r\n\r\ndrush en config_split\r\n\r\n<\/pre>\n
              Use Case Example:<\/strong><\/p>\n
              Let Suppose we have a Drupal site that requires different email settings in development and production environments. The goal is to ensure that email functionalities are configured appropriately for testing and live use.<\/p>\n
              Using Config Split, you can create different configuration splits for your environments:<\/p>\n
              Development Split:<\/strong> Create a configuration split for development with settings for a test email address.
              \nProduction Split:<\/strong> Create a configuration split for production with settings for real email addresses.<\/p>\n
              How It Works:<\/strong><\/p>\n
                \n
              • You define multiple configuration splits in the Config Split settings.<\/li>\n
              • Each split specifies which configuration settings should be included or excluded.<\/li>\n
              • During the export and import process, Drupal uses these splits to manage environment-specific configurations seamlessly.<\/li>\n<\/ul>\n

                \nHow to Segregate Configuration Between Non-Prod and Prod Environments?<\/strong><\/h2>\n
                To effectively manage and segregate configuration between non-production (e.g., local, dev, qa, prod) and production environments, follow these practices:
                \n1. Navigate to the site\u2019s admin interface: Configuration<\/strong> > Development<\/strong> > Configuration Split Settings<\/strong>.
                \n2. Click Add Configuration Split Settings<\/strong>.
                \n3. Enter the label and the folder name, Select the modules you want to split and click save.<\/p>\n
                \"Config
                Drupal Config Split<\/p><\/div>\n
                Use Different Configuration Directories:<\/strong>
                \nConfigure Drupal to use different sync directories for different environments. For example, in your settings.php file, you can specify different directories for non-production and production environments:<\/p>\n
                \/\/ Configure the Config Split module for different environments\r\n$config['config_split.config_split.local_split']['status'] = FALSE;\r\n$config['config_split.config_split.dev_split']['status'] = TRUE;\r\n$config['config_split.config_split.qa_split']['status'] = FALSE;\r\n$config['config_split.config_split.prod_split']['status'] = FALSE;\r\n\r\n<\/pre>\n
                Note:<\/strong> You should adjust the true\/false status of the configuration splits based on your current environment. For example, if you are in the dev environment, you would enable dev_split and disable others.
                \nMake sure your directory structure for the configuration is correctly set up to match the config_sync_directory path specified in the settings.php file:<\/p>\n

                \nConclusion<\/strong><\/h2>\n
                Drupal 10’s Configuration Synchronization system is a powerful tool that ensures consistency across different environments, simplifies deployment, and enhances collaboration through version control. By understanding and properly utilizing the export and import processes, you can maintain a stable and predictable Drupal site across development, staging, and production environments.With this approach, you’ll have a robust workflow that minimizes the risk of configuration drift and keeps your Drupal site\u2019s configuration under control.<\/p>\n","protected":false},"excerpt":{"rendered":"
                Introduction Drupal’s Configuration Management system, introduced in Drupal 8 and refined in Drupal 10, allows developers to manage site configurations in a standardized and predictable manner. Whether you are working in a team or managing multiple environments (like development, staging, and production), Configuration Synchronization ensures consistency and reliability across all setups. This blog will guide […]<\/p>\n","protected":false},"author":1708,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":284},"categories":[3602],"tags":[3709,4862,5859,5096],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/64713"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1708"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=64713"}],"version-history":[{"count":13,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/64713\/revisions"}],"predecessor-version":[{"id":65482,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/64713\/revisions\/65482"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=64713"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=64713"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=64713"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}