Disabled modules don't get text format replacement run on their data

This is a freakin' edge case, who does anything like that? On a living site, if you have data by a module which you accidentally disable you reenable immediately. This is not critical, far from it.

For me, this is a simple won't fix - unless we broaden the topic and discuss "Some (maintenance) hooks needs to be invoked in disabled (but installed) modules, too".

I think this one has been overridden by #914458: Remove the format delete reassignment "feature".

@catch, thanks. My argument for this being critical was that (a) it's a regression from Drupal 6, and (b) it leaves your site in a broken state (content missing) with no obvious way to recover from it. It's true that it's something of an edge case - however, people do temporarily disable modules all the time, when the needs of their site have changed. Websites evolve over time, and Drupal has to allow for that.

In any case, it's not "minor".

The suggestion in #1 is interesting. The only problem is that hook_filter_format_delete() takes full format objects as parameters, rather than format IDs. Passing a long-ago deleted format object into the hook would therefore require keeping that info around in the meantime. One could argue, perhaps, that there is no reason to send anything but format IDs to that hook anyway (and if people are considering removing that hook entirely in other issues, then we can certainly consider changing its parameters here). Anyway, #1 sounds like it's hopefully less controversial of a solution.

Barry's approach, though, was also intended to address field storage engines that are unable to perform the update. I am not sure where we are with that, in actually understanding all possible field storage engines (not just SQL and MongoDB).

While in the long term we would like to solve this more generically (for other maintenance-style hooks as well) I am not sure there is a need to do that here, unless we have enough examples of other hooks that have similarly dire consequences when they are not invoked in a disabled module and whose behavior is a regression from Drupal 6. If not, I think we could safely focus just on the filter module here. If contrib modules have the same needs for their hooks, they could always implement something in parallel (and then wait until Drupal 8 to generalize the approaches).

OK, reading the priorities carefully, I believe we can settle on major:

"For issues which have significant repercussions, but do not render the whole system unusable. For example a PHP error which is only triggered under rare circumstances or which affects only a small percentage of all users."

I think that accurately describes this bug.

The D6 behavior was not insecure (rather the other way around, it was actually introduced to fix a security issue and as a side effect fixed this too). D6 was just somewhat nonsensical, in that when you deleted a text format it never gave you the chance to convert it to something besides the default text format, which in some cases makes no sense. But once you did choose to delete the format, D6 behaved like it said it would, including for disabled modules. Barry's patch is simply the logical extension of the code that is already in Drupal 6.

This issue is taken care of by #914458: Remove the format delete reassignment "feature".

If that issue ever gets committed, we can close this then.

@David: You keep on telling that we'd have a regression from D6, but that is not true. D6 invalidly filters text using the default format if the actually assigned format does not exist. This bug has been fixed for D7, by giving modules a chance to react on text format updates and deletions.

This issue seems to be all about handling text formats that we have been stored by disabled modules. The problem is not limited at all to text formats. It applies to everything, since no API hooks are invoked for disabled modules. Therefore, this issue is a duplicate of #734710: API functions that invoke hooks don't work as expected when a disabled module is being uninstalled

That issue is for Drupal 8, is more general, and also focuses on update.php. So it can't be a duplicate.

I understand that the backend has changed between Drupal 6 and Drupal 7, but the sense in which this is a regression is from the site administrator's perspective. They don't know how it all works necessarily underneath - all they see is this:

1. In Drupal 6, you go to delete a text format and it tells you "Content with this format will be replaced with format X" and that's what happens.
2. In Drupal 7, you go to delete a text format and it tells you "Content with this format will be replaced with format Y" and sometimes, that's not what happens.

@David: Your last comment on #914458: Remove the format delete reassignment "feature" sounds like you'd agree with everyone else that it is viable solution for D7. With that patch, text formats are no longer deleted, but disabled only. Your particular use-case of assuming that content of a disabled module still works after removing a format is therefore covered -- although it is insane to assume data integrity for any disabled module in the first place.

At least for now.