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.It would be nice to remove the Features UI from installations while still being able to use exported feature modules. Other projects like Context and Views do this.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 1948280-features-split-ui.patch | 16.46 KB | impleri |
Comments
Comment #1
impleri CreditAttribution: impleri commentedAnd a quick (potentially dirty) patch against 7.x-2.x-dev HEAD.
Comment #2
mpotter CreditAttribution: mpotter commentedThis needs a whole lot more work. Features can already be removed in most cases since the hooks implemented by the exportables are generally already part of other modules. For example, ctools and views exports don't need Features module to work, so in a sense Features is *all* UI.
Now, if you wanted to separate the drush functionality from the UI that might make some sense. But I'm not sure you'll get much out of this. Definitely something very low on my priority list since the performance gains from removing the UI bits is pretty minimal.
Comment #3
impleri CreditAttribution: impleri commentedIt's more that every exported features module depends on features. Do you suggest turning off all features modules after exporting/importing so that the features module can be disabled?
Comment #4
mpotter CreditAttribution: mpotter commentedimpleri: definitely not. Pure Features such as Views and Ctools exportables will disappear from your site if you disable those feature modules. They don't get "imported" into the database, they only exist as code. You are probably correct that some of the dependencies on the Features modules should be examined since a Views exportable certainly does not require the Features module to be enabled.
But back to my original comment, what is driving this need? It's a very complex issue that has very little benefit that I can see.
Comment #5
impleri CreditAttribution: impleri commentedThe primary need I see is to ensure that people who would access to the Features UI (e.g. other developers) on a production environment are not tempted to interact with it. While some things such as the Field UI can be disabled to prevent developers misusing tools, making it so that they could not export any of their changes from the UI would help enforce this.
A bit of context: our particular workflow is based on the model of develop -> staging -> production. When anyone pushes to the production branch, a post-receive hook fires and pushes the changes to the production environment, clears the caches, and reverts all features modules. However, this has caused some issues because developers have made changes to items in the production environment through the UI, exported them to the develop environment, and caused a lot of mess because the dev environment was working on changing the site architecture. Making it so that someone could not export changes on the production environment without enabling a Features UI module would help reduce this a bit more. Granted, this may be a bit of a fringe case here, but I think having the UI separate from the core Features module would be beneficial (and perhaps aesthetically pleasing to those who like to see /admin/structure sparse on production environments).
Comment #6
mpotter CreditAttribution: mpotter commentedWell, that's what the "administer features" and "manage features" permissions are for. If your developers are logging into the user-1 account on Production, that's a whole different issue. Change the user-1 password on Production, set up developer accounts with an "administrator" roles and then control the permissions you want. That's what the permission system is for.
I guess if somebody came up with a good complete patch that accomplished this, I wouldn't be opposed to using it. I'm just warning people that this would be a complex issue (not as simple as your first patch). Actually splitting into 2 modules means doing it right, like most of the stuff in features.admin.inc would be in the UI module. Not just removing/disabling the admin menu hooks.
Comment #7
impleri CreditAttribution: impleri commentedYeah. Generally we keep the user-1 account for our firm (so that clients don't mess up things unless we know they're familiar enough with Drupal), and it makes it easier for us so that we don't need to track our staff member accounts (for when one leaves or we hire someone new). Having to go through 90+ sites and (1) check to see if a staff member has an account and (2) change their permissions would be a very time-consuming process.
This isn't a very high priority for me, but I'll look further into separating the two modules more fully...eventually. It's more of a wishlist item to save time when developers new to the team spend time building the content types and having their changes wash away on a git push.
Comment #8
DamienMcKenna@impleri: How about using hook_menu_alter() to disable those menu paths entirely on production?