[upstream] Data loss: `drush config:import` deletes config (e.g. code component + component config entities) and bypasses config system data integrity checks
>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3573022. --> Reported by: [bernardm28](https://www.drupal.org/user/3624259) >>> <h3 id="overview">Overview</h3> <p>I have a hosted website, and I used 3 code components to overcome minor issues that were minor and were mostly just client-side or specific overrides from some css styles.<br> Everything seems to work well until I go back to the website, and my page is WSOD.<br> Upon further examination and local testing, I guess that something upstream at the hosting level created a deployment, and Drush did a Drush deploy and deleted the configuration of my code components.</p> <p>Here are the steps to reproduce it:</p> <ol> <li>Make a code component, anything, even the most basic will work. </li> <li>Make sure you click on Add to components at the end of it so it shows up in the canvas side panel and can be dropped on a page.</li> <li>Then go to any page and add that component to the page. Like normal.</li> <li>Then do a drush cim and wipe that component config. Because for some reason there was an unschedule deployment and the host deployed something, and it ran a drush deploy.</li> <li>Normally, at that point I would have thought o no forgot to save that component. My options i thought, would be either: Create the component again and somehow hope the host doesn&rsquo;t do an unscheduled deployment, or try to somehow add that to the codebase so it does not disappear on me.</li> <li>Now if the issue was only the inconvenience of it disappearing, that would be one thing, but it did more.</li> <li>Because that config had also something saved at the database layer now the canvas page where you dropped it is WSOD(white screen with error) and the only way i found for it to come back is to delete the components_component_id from the canvas_page__components that follow the js.something pattern. How do I come back from that? well i have to run this command</li> </ol> <p><code> ddev drush sqlq "SELECT * FROM \`db\`.\`canvas_page__components\` WHERE \`components_component_id\` LIKE '%js.%' ORDER BY \`components_component_id\` ASC LIMIT 300 OFFSET 0;"</code></p> <p>and then delete those records from the database, which gets rid of WSOD, but that's so much work, and no site editor would want to do such a risky thing as editing their database, and they should not.</p> <h3 id="proposed-resolution">Proposed resolution</h3> <p>So if <code>drush cim</code> is always going to delete the configuration and mess up the components, then either code components in the database should show an error at the component level, and not the WSOD or deleting that configuration should remove such code components from the database record.</p> <p>Otherwise, anyone who uses DrupalCMS with Canvas on any given host could one day wake up to their whole site been WSOD by those components being deleted.<br> Usually, drush cim is fine, and the consequences are that you lose some progress, but in this case the stakes are high as the website itself won't load the whole page.</p> <p><img src="https://www.drupal.org/files/issues/2026-02-12/Screenshot%202026-02-11%20at%205.40.34%E2%80%AFPM.png" width="600" height="600" alt="wsod message"></p> <p>That's all you get, whether that's an internal page or your homepage; if that component is gone, nothing is left but that on the frontend. Once you login you can see an error on the canvas page, but I'm not showing the error page. There is a better experience if anything, the non-login user should see maybe the previous revision that had no errors?</p> <p><img src="https://www.drupal.org/files/issues/2026-02-12/Screenshot%202026-02-11%20at%205.39.16%E2%80%AFPM.png" width="600" height="600" alt="wordpress error per block"></p> <p>It would be great if we could localize the error to the code component block itself as WordPress does. Instead of WSOD(white screen of death), we could just say this block is broken, and then the user can delete it or recreate it. Granted, recreating a block without telling me the host is wiping it at a random time is a bad user experience. They won't ever make any progress.</p> <p><img src="https://www.drupal.org/files/issues/2026-02-12/Screenshot%202026-02-11%20at%204.07.30%E2%80%AFPM.png" width="600" height="600" alt="error message broken code block"></p> <p>This is the error you get with no way of fixing it from there, or what could have broken. If possible, it would be great if that error gave you an option to load a previous revision or just remove the block that caused the failure.</p> <p>Worth noting that undo last action won't do anything in this case.</p>
issue