"Purge" functionality to work in parallel with "Revert" [#1732766]

I'm imagining that "Purge" would either delete everything from the database tables for a module implementing Features that isn't managed by Features, or just clean out the tables.

Use case (really common for me at work, actually):

I have a dev site A and a production site B.

I create something on site A and deploy it B using Features by pushing it to a git repository owned by the client.

Later, the thing I created is no longer needed for whatever reason - maybe I culled in a refactor or maybe the client has changed their mind about something. I delete it from site A and from my feature and I push my changes to the feature to the git repository.

Currently, to delete the "thing" from site B I have to do one of the following:

Log into the production site and delete it manually after deploying my Feature - unprofessional, error-prone, I might not have access to login to prod like this
Write an update script to make the changes to the database - maybe simple, maybe super time consuming and requires extra testing time, kinda the thing Features was invented to avoid
Leave the thing in site B but deploy something else to hide it - what a mess!

Having the ability to "Purge" everything related to a module that the Feature doesn't know about would be great.

Would also need the ability for a module to flag that it isn't "purgeable" - Strongarm would be the best example of a module in this category.

Edit:

I'd like to mention that I'm aware that some modules like Views and Context don't suffer this problem as they run straight from the exported code but then on the other hand CCK constantly complains about fields that contain data and weren't deleted but aren't defined in any Feature for the current content type.

This feature almost exclusively benefits modules that take the code of a Feature to populate the database on import then exclusively reference the database from then on.

Comment	File	Size	Author
#10	1732766-features_delete-10.patch	15 KB	hefox
#10

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

thedavidmeister CreditAttribution: thedavidmeister commented 15 August 2012 at 14:18

Related #1059666: More precise spec

Comment #2

mpotter CreditAttribution: mpotter commented 22 August 2012 at 17:07

This is on our "road-map" as something we call an "installable Feature". As you mentioned, they get installed on Site B, but don't remain as a real "Feature".

However, in this mode, Features ends up looking more like a Configuration Management system and starts to overlap more with the CMI in Drupal 8, and stuff like the Configuration project. So we are still trying to decide exactly how Features would support this kind of functionality.

Comment #3

thedavidmeister CreditAttribution: thedavidmeister commented 23 August 2012 at 00:39

support it as a backport of the D8 work? I mean, if that is doing the job well, why not?

Comment #4

thedavidmeister CreditAttribution: thedavidmeister commented 23 August 2012 at 05:12

another use case:

Site A is a site that was built pre-Features (or by someone who doesn't use Features) and now the client wants to deploy new functionality so they've asked to "Feature-ize" the existing site.

Site B is a dev site that is cloned from Site A, Site C is a clone of Site A that can be used to test that everything will deploy smoothly when things are pushed from Site B to Site A.

Having the ability to easily "purge" the database in Site C would be really useful to try and identify any gaps in the functionality covered by the features that might only be plugged by legacy config that only exists because it was in the database cloned from Site A.

At the moment, can create a fresh Site C with stuff pushed from B, but it would generally be easier to "ween" off Site A's database one module at a time than try to recreate every module's functionality all at once.

Comment #5

mpotter CreditAttribution: mpotter commented 23 August 2012 at 13:05

I think I misunderstood your original use case. We have no plans to ever make Features "delete" any data on your site. If a Field is no longer used in a Feature, it's really up to you to delete it. There is just too much chance of accidental data loss with any sort of "purge" feature. Exportables like Views/Ctools/etc are "pure" exportables and don't suffer from this trouble as you said. But the "faux" exportables, such as Fields are not handled by core in a way that would make this kind of functionality easy, which is why Features has already resisted doing anything like this.

The Configuration project linked above already attempts to backport the D8 CMI functionality, so give that a try.

What I was talking about in #2 is a way to make Site B forget that something was installed via a Feature. But not to actually "purge" or delete anything from the database.

"Revert" works because Features knows exactly what was exported. To purge "everything not managed by Features" would be magic since there is really no way for Features to know what all is implemented by a module that isn't exported.

The bottom line is this is something better handled by a contrib module and not something we plan to add to core Features.

Comment #6

thedavidmeister CreditAttribution: thedavidmeister commented 24 August 2012 at 10:49

Indeed, "purge" would have to be implemented by contrib modules that integrate with the Features API. I wouldn't expect it to be part of Features core for the exact reason you outlined - that "pure" exportables don't need it, and "faux" exportables are often only not "pure" because they've been poorly implemented.

Nonetheless, I do think there would be some place for an exposed hook or similar in the Features API allowing contributed modules integrating with Features to implement their own "purge" functionality.

ie, yes, I agree that it would be impossible for Features to implement a magical purge and that this functionality is something that would be better left to contrib modules. I do think it would be nice if there was a unified/consistent interface for them all to hook into though.

What I'm suggesting is something in the Features API that can be implemented by external modules if the maintainers see the value in it, that is accessible to the end-user/site-builder where they can "clean out" the database tables without completely uninstalling the module.

Obviously, this functionality could really be implemented anywhere, in any Feature-esque contrib module. I just thought that to me, conceptually, it sits very nicely next to the Features "revert" system and Features has already nicely captured the attention of the Drupal community at large, whereas any new-release contrib module would have to fight for attention and dev time for quite a while.

If this is something that's already part of the D8 framework then that's just good news for me I guess, I'll just have to wait it out :)

btw, mpotter, thanks for taking the time out to reply to my thread, it's much appreciated.

Comment #7

mpotter CreditAttribution: mpotter commented 24 August 2012 at 13:06

Status:

Active

» Postponed

OK, that makes sense. When we re-architect Features for D8 I'll keep this functionality in mind. For now I think I'm going to mark this as "postponed" since it needs to be addressed with Features 2.x API stuff.

Comment #8

Kristina Katalinic CreditAttribution: Kristina Katalinic commented 22 May 2013 at 23:38

Here is my scenario when purge functionality would come in really handy.
Suppose I develop some features for a client. The features modules I created and installed on clients site has added some content types, configurations, fields etc. In a nutshell client has asked for certain "features (read functionality) "to be added to their site. All good so far....but the client decides they don't want to pay for my work even thou they are keeping all the functionalities I added via features modules (basically a smart@@s). Not nice, not common, but it happens. When it does however I'd like the ability to retract my work, essentially no pay no play. Why not just take them to court? Because sometimes its cheaper to cut your loses and accept you wont be getting paid for the work you've done and simply be content by knowing that you can remove/purge your work from clients site thus not allowing them to steal from you. I guess if this happened to a few clients of this sort they'd soon think twice about not paying their developers :)

Comment #9

thedavidmeister CreditAttribution: thedavidmeister commented 22 May 2013 at 23:57

#8 - In the meantime revert your relevant commits in git and write an update script to drop relevant configuration from the db.

Comment #10

hefox CreditAttribution: hefox commented 23 May 2013 at 16:30

Status:

Postponed

» Needs work

File	Size
1732766-features_delete-10.patch	15 KB

depends on #2001356: Update features_test to use field_instance/field_base and move to own directory so settings needs work into till that goes in (as this won't apply)

This patch adds a new hook, hook_features_delete, that deletes the item from the system. It's implemented for most of the components that implement hook_features_rebuild. The ones that are not implemented are ones I don't feel like dealing with the edge cases for or would require more time than I feel like giving a patch I'm am unlikely to use XD (languages, menu_links, user_permissions). Each of the implemented components are covered by the test added. If anyone updates to add the missing components, update the tests. However, I believe this is good enough to go without those components, which can be added in their own issues.

It will run on uninstall of a module *only* if a variable is set to true. That variable can be set via the settings tab, under a collapsed fieldset, with warnings about data loose.

My motivation to do this now is that if can get it in before 2.0, it's an excellent time to add a new hook (as people are more likely to notice it) so other modules that want it can be updated.

Comment #11

thedavidmeister CreditAttribution: thedavidmeister commented 25 June 2013 at 14:02

Rather relevant #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed.

That issue will remove the ability to "disable" a module in D8.

This means that uninstalling a module will uninstall that module's dependencies as well, and you lose all your data for both modules.

This means that making new hooks that module's can implement to "purge" their config and/or content (not sure if Features would want to go near the latter) without touching the "installed" state of a module (because you can't "just disable" it any more) could have much stronger use-cases once D8 is released.