Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
For extensive background discussion, see http://groups.drupal.org/node/210973.
In short, the problem is that we'd like some types of user interface improvements which are added to Drupal 8 core to also be available to Drupal 7 sites. However, we often don't want to do it as a straight backport of the Drupal 8 patch, because that can risk breaking other modules, and it conflicts with our goal of making Drupal 7 point releases as stable as possible.
Proposed resolution
Based on the discussion in the above groups.drupal.org post, the proposal here is to add a new module to Drupal core in which backported UI updates can be added (e.g., using hook_form_alter() and the like), rather than adding such "risky" changes to core modules themselves.
This will allow sites which require extra stability to not enable the module at all, while sites which want to take advantage of the latest changes can keep it on.
Note that there are several contrib modules which do something similar:
http://drupal.org/project/backports
http://drupal.org/project/edge
http://drupal.org/project/fixcore
Adding such a module to core would allow these efforts to be combined (at least for the most conservative, agreed-upon changes) and also would make the module automatically available to Drupal sites which might not know to go out and download it on their own.
The module would (at a minimum) be enabled by default in the standard install profile, because there's no reason not to. It might also be automatically enabled in other situations too, depending on what we decide.
Note that the mere fact that this is a separate module can, in some cases, help with stability even when a site chooses to turn it on. For example, the module can be given a very high weight, so that its hooks run after those of other modules, and the alter code can be written in a conservative way so as not to alter things that it appears other modules have already altered first. This would help minimize the chance of conflicts with contrib/custom modules.
Remaining tasks
- Decide if this is a good idea, and implement it if so.
- Add some code to the new module. Something like #1164812: Improve UX for machine names for fields. might be a good place to start, unless it's already included in a D7 point release when we work on this.
User interface changes
A new module will appear on the modules page (unless we decide to make it a hidden module?).... And obviously, sites which turn this module on will get additional user interface changes as time goes on.
API changes
None.
Comments
Comment #1
catchI think this is a good idea, the main concern I'd have is figuring out the balance between things that go in the module vs. things everyone gets, but we can only do that once the module is in anyway.
Comment #2
klonosThere's no need for us to decide/debate over what should be enabled or not by default. The module can have a config page that lists all available fixes/backports/whatever along with a checkbox next to each one, allowing users to selectively enable these. Fix Core already does it this way.
This would also make it easier to troubleshoot things once we've spotted that the source of evil is this specific module. People would start disabling recently enabled features/fixes, until their issue goes away. Then they leave the specific fixes to be blamed disabled until we figure out what's wrong and perhaps provide a solution for that too ;)
Comment #3
David_Rothstein CreditAttribution: David_Rothstein commentedJust a heads-up for anyone who's interested that I'm going to revive some of this discussion at CapitalCamp this weekend:
http://capitalcamp.org/content/drupals-backport-policy-how-enjoy-future-...
Comment #4
klonos...anything interesting worth sharing that came out of that David?
Comment #5
David_Rothstein CreditAttribution: David_Rothstein commentedOops, never responded to that... and now it's almost next year's CapitalCamp :)
The session I gave last year was not heavily attended (apparently Saturday mornings are not a time a lot of people like to show up for a policy discussion!). And though I talked about this some, we didn't get too far into the details in the discussion phase.
That said, the overall trend of the opinions people expressed during the discussion was that they preferred stability over new features in an already-released version of Drupal core. Which for the purposes of this issue I would translate to mean that they would not be interested in enabling this module on their sites (which means it would definitely be a good place to put new features that are focused on new sites).
Anyway, I'm still interested in seeing this happen but probably won't have time to work on it anytime soon. At this point, I'm moving it to Drupal 8 also, although (by definition) it could still be backported to Drupal 7 as well.
Comment #5.0
David_Rothstein CreditAttribution: David_Rothstein commentedmention custom modules in addition to contrib
Comment #7
Fabianx CreditAttribution: Fabianx at Tag1 Consulting commentedI am still +1 to doing something like that.
Comment #19
quietone CreditAttribution: quietone at PreviousNext commentedI think it is time to close this one, especially given End of life announcement and changes to Drupal 7 support - PSA-2023-06-07.