>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3569860. --> Reported by: [catch](https://www.drupal.org/user/35733) Related to !790 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The project description of Drupal CMS helper says:</p> <blockquote><p> This module is meant to be an internal helper to provide functionality to Drupal CMS that <em>has not yet</em> been added to Drupal core. Its use outside of Drupal CMS-based projects is not supported. </p></blockquote> <p>(emphasis added)</p> <p>My understanding of this sentence is that the module should contain only polyfills - e.g. transparent implementations of upstream fixes that can be removed as soon as they're released (but also shouldn't break when they're released if the module isn't updated first).</p> <p>However it looks like in addition to polyfills, glue code is also creeping in.</p> <p>e.g. <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/drupal_cms/-/work_items/3567584" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/drupal_cms/-/work_items/3567584</a></span> implemented custom functionality for Drupal CMS to workaround a core limitation. The non-workaround version of that fix will require configuring the search view/block differently, or installing and configuring a new contrib module. This introduced a required step for Drupal CMS site owners- they would have to change their configuration before the code was removed, otherwise their search block would break.</p> <p>For Drupal CMS this would mean either:<br> 1. Issue a release without the polyfill and mandatory update steps for site owners (which most won't follow since they don't actually update 'Drupal CMS' just get the helper module updated via composer, or potentially automatically. Even if it was a major release, people will still miss it.<br> 2. Keep the code around indefinitely, possibly adding more code to add a hook_requirements() warning linking to a change record.<br> 3. Write an update hook to update poeple's views/block configuration to the new values. This is something we explicitly avoid for shipped views with Drupal core because when we did it, people would have customised those views in unexpected ways, and the views would break or the update would fail to complete. We add update hooks when the schema of the views itself changes, but not to change things in specific views. It can also get very error prone when you have multiple updates against the same config entity, one for schema changes, one for changing values.</p> <p>As it turned out, there was a 12 year old active core issue, already worked on this week, fixing exactly the problem being worked around. I spent at least 3 hours discussing the workaround with @phenaproxima yesterday, plus how ever much time to implement it and then revert it again. RTBCing the core patch happened within about 20 minutes of realising it was fixing the exact issue, so no time was saved doing the quick fix, exactly the opposite of that.</p> <p>In this case there was also a contrib module providing the same functionality that could have been used - this would not have imposed mandatory update steps on sites or permanent maintenance burden to the Drupal CMS codebase then, although the contrib module is low usage and also only exists because the core issue wasn't fixed. But still less intrusive than custom Drupal CMS-specific code.</p> <p>Adding functionality like this specific to Drupal CMS is also confusing, because there's no clear reason for why it works in Drupal CMS or not without. For temporary polyfills that will be available upstream within weeks or months this is justifiable, I don't think it is for fixes not even linked to an active issue. If genuine situations like that arise, they should be maintained in separate modules with an open issue to try to remove them again (e.g. when an existing contrib or core issues is identified).</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-data-model-changes">Configuration changes</h3> > Related issue: [Issue #3569875](https://www.drupal.org/node/3569875) > Related issue: [Issue #1503146](https://www.drupal.org/node/1503146) > Related issue: [Issue #3569884](https://www.drupal.org/node/3569884) > Related issue: [Issue #3569887](https://www.drupal.org/node/3569887) > Related issue: [Issue #3541137](https://www.drupal.org/node/3541137) > Related issue: [Issue #3564197](https://www.drupal.org/node/3564197) > Related issue: [Issue #3551708](https://www.drupal.org/node/3551708) > Related issue: [Issue #3569949](https://www.drupal.org/node/3569949)