Drupal 10 Workflow

February 16, 2024

Developing, making significant changes, or troubleshooting directly on a live Drupal website is indeed considered bad practice, despite the ability to do so through CMS and user logins. Here are several reasons why:

1. Data Loss Risk: Mistakenly deleting or altering content can lead to data loss, which might not be recoverable. In a local testing environment, any mistake would not affect your live website.

2. Downtime: Unintentional errors could lead to the site crashing or experiencing downtime, impacting all users on the website and possibly leading to loss of revenue or user trust.

3. Visibility of Work-in-Progress: Changes made live are immediately visible to end-users. If work is not fully completed or if there are bugs, this can result in a poor user experience.

4. Performance Issues: Extensive changes can temporarily degrade website performance, resulting in slower page load times for visitors during the update process.

5. Lack of Version Control: With local testing, you can use version control systems like Git to track changes, revert to previous versions if needed, and collaborate more effectively with other developers.

For these reasons, it’s recommended to adopt a workflow that involves local development, then testing (on a separate test environment if possible), and finally deploying to the live site. Small content changes (like creating a blog post, updating page text) can be done directly on the live site through the CMS, but all code and substantial changes should go through a proper workflow.

Drupal’s configuration management system helps in this regard by allowing you to export and import site configuration (like content types, views, fields, etc.) between different environments. This way, you can safely make and test changes in a local or staging environment and then import the configuration changes to the live site once you’re ready.