Disabled update module shouldn't produce a status report warning

In general, core doesn't know the context of where update module is being used. This is something the site builder and then owner should be taking control over.

It would be okay if this was informational, but shouldn't be a warning. My patch removes it from the warnings list.

There are many situations where it's perfectly reasonable to disable the update module, such as in an enterprise environment where you monitor for updates via other dedicated means and don't want the performance impact of having Update enabled in production.

What is the performance impact of Update being enabled in production? By default it only checks once per day and you can disable extension checking too.

I think we might need security team, release manager and product manager thoughts before changing this.

I think if the use-case for uninstalling Update can be made then maybe having a setting that's not the default might be the way to go - although I'm not convinced. In fact, the whole being able to disable update checking is weird. I think we should be able to stop automated checking but still leave a button around for people to do a manual check.

Somehow this didn't make it into the issue yet, but @catch pointed out that https://www.drupal.org/project/update_notifications_disable exists for this purpose. I think I'd suggest porting that to Drupal 8 instead of doing this in core.

@Dane Powell, I agree in general about not having bad warnings, but disagree about update status in particular. Having update status turned off should be a warning, because you will miss the most serious warning your site can give you, which is a security update being required.

I strongly disagree with downgrading to info, we have thousands of sites running outdated and insecure versions of core and contrib modules. Update status and this warning obviously isn't fixing that issue, but removing the strong encouragement to enable it isn't going to help.

I don't see the problem with installing update_notifications_disable. Could possibly live with adding an override to $settings though so not marking by design just yet.

There are 4 reasons (I can think of) why update module may need to be disabled:

1. Some drupal hosting companies provide remote updates for customers, and customers should not be updating their sites on their own
2. Your site has a requirement to not report statistics/contact the cloud
3. Your infrastructure doesn't allow the webs to reach the internet
4. You use a custom update system, or a distribution performs updates for you

Warnings should be reserved for universal issues affecting your site functionality and that are actionable. IMHO it should not be used to pester people to do certain things. Having update enabled by default with the shipped profiles is a good idea, and possibly throwing a warning when trying to disable it. But once a decision is made to disable it, the site shouldn't be reminding the user. (See #2880374: Experimental modules and themes should not have warnings after being installed, #2877128: [META] Evaluate status report warnings and determine which should be reduced to info, removed, etc., and #2766491: Update status should indicate whether installed contributed projects receive security coverage for more discussion)

I wholeheartedly agree with this proposal.

#15 says:

Warnings should be reserved for universal issues affecting your site functionality and that are actionable. IMHO it should not be used to pester people to do certain things.

Spot on. Many, many sites are just being upgraded automatically (Pantheon in the managed Drupal world, but also plenty of web hosts with one-click install / updates) and/or have different channels anyway (RSS/Twitter, monitoring service, Acquia Remote Administration, Tag1's QUO, etc.) to know when an update is required.

#10

What is the performance impact of Update being enabled in production?

I've seen many times Update Manager's outbound requests hanging and causing issues on sites with high-traffic in particular. Granted it was more in the D6/D7 days but unless Symfony improved things it could still be happening.

I think we should be able to stop automated checking but still leave a button around for people to do a manual check.

I support that. It's a good trade-off with uninstalling the module altogether. Stopping automated checking could also come with a big fat warning asking you if you're really sure what you're about to do. We all need to keep in mind if they can, they will. Unless you shutdown Drupal saying you need to update now, many people won't update because they don't have to. It's like having 123456 as the most used password in 2017.

#15

we have thousands of sites running outdated and insecure versions of core and contrib modules. Update status and this warning obviously isn't fixing that issue, but removing the strong encouragement to enable it isn't going to help.

True, but the main reason I've seen users aren't upgrading is due to the complexity of managing Composer dependencies (and probably also minor versions scaring people a lot, e.g. WBM => content_moderation). I'm seeing this every. single. day. As a matter of a fact I've never seen as many outdated sites as with D8.

I really like #2 patch approach because it make it possible to choose the behaviour. All sites that we host for our clients are not allowed to talk to the Internet directly and updates are monitored separately, so removing this warning from production environments would be a good thing.

Reroll of #2 for 8.7.x.

version bump

The patch works fine, and allows disabling the warning message, if the Update module has been disabled:

Default

Update warning message disabled via settings.php

+$settings['update_warning_disable'] = FALSE;

Besides Update module there are many other use cases to suppress warnings in status report. With the current approach we may end up with a bunch of such settings, one for each warning. Why not just add a more general setting to suppress any type of warnings?
Something like this.

$settings['suppress_status_report'] = [
  'system.update_status',
];

reverted:
--- b/core/assets/scaffold/files/default.settings.php
+++ a/core/assets/scaffold/files/default.settings.php
@@ -291,15 +291,6 @@
*/
$settings['update_free_access'] = FALSE;

-/**
- * Disable update notifications warning.
- *
- * If you have intentionally uninstalled the update module and are monitoring
- * for updates via another method, you can use this flag to disable the
- * warning about the disabled module on the status report.
- */
-$settings['update_warning_disable'] = FALSE;
-
/**
* External access proxy settings:
*

reverted:
--- b/core/assets/scaffold/files/default.settings.php
+++ a/core/assets/scaffold/files/default.settings.php
@@ -291,15 +291,6 @@
*/
$settings['update_free_access'] = FALSE;
-/**
- * Disable update notifications warning.
- *
- * If you have intentionally uninstalled the update module and are monitoring
- * for updates via another method, you can use this flag to disable the
- * warning about the disabled module on the status report.
- */
-$settings['update_warning_disable'] = FALSE;
-
/**
* External access proxy settings:
*

#28 seems like a really good idea. I think actually this could be something that is in configuration and not settings.php - because then it'd be simple for someone to build a UI in contrib that let's you configure which warnings you are ignoring from the system report page.

Needs a reroll

Reroll of #7, used by lightning_core.

Here is a backport of #7 to Drupal 7.

Perhaps I can add one more use case that hasn't been mentioned yet. Do say if there's a better way to solve my issue.

I want to force updating modules through composer. Having the update module enabled means someone could update one in production environment via the UI. Bad. So I want to disable update notifications in production but have it enabled in development and staging, with Cron running in at least one of those so I get emailed.

This issue is still missing a case for what's wrong with just using the contrib module for sites/platforms where suppressing the warning is desirable. I'm not totally opposed to a config option, but it's not clear why a secret config flag is needed over the existing contrib solution.

Also, both release managers have indicated that we're not comfortable simply nerfing the warning to an info message, so removing credit for rerolls of that approach since we documented that. Thanks!

Having a solution in contrib could well be the optimal way forwards here.

However the Update Notifications Disable module is not that solution IMO.

The way it works is by having its files all named update (update.info, update.module). The module name is Update Notifications Disable, so a human sees that in the list of installed modules for the site. But a machine sees that there is a contrib module named "update", which masks and overrides any core module with the same name. Any attempt to enable core's update notifications enables the contrib one instead. So it makes it impossible to enable core update.

There are all kinds of reasons why I wouldn't use this approach on any site I maintain.

• Things go wrong, for example:
  • #282919: Kills Update Notifications completely
  • #3164275: Not compatible with core 8.9.* and above anymore
• It's way too clumsy to recommend as the documented way to get around this issue. You just shouldn't have a contrib module that intentionally clashes with core's namespacing. Modules should name the files (for the main module included in the project) to be the same as the project key name.
• The only way to uninstall this module is to remove its files, so core can't see it's there. Again, that's not standard behaviour for a module.
• Following from that, as explained in #37, my use case is that I want all updates to take place on development sites only, so want the update module disabled in production. That means not having the files present in production. Composer lets you have packages included only in development (composer require --dev), but there doesn't appear to be a switch to only include when not in dev. I could hack that (with post-install-cmd, or similar), but I'd then have a module present in production but not in development or staging. I would not be able to test changes before deploying. So, this module also does not work along the grain of good composer staged deployment practice.

So, yes, let's solve this in contrib rather than core. But if that's the way forwards, let's do it the Drupal way, invoking a hook that modifies the status of this message from warning to informational. Does such a hook exist? If so, I'd gladly write the module.

PR created for #84

Thanks for the patch, although what it does is simply downgrade the warning to information for all sites at all times. I'm pretty sure the consensus from comment #14 onwards has been that this poses a security risk, and we need a solution that is either configurable or comes from contrib. I suspect the reason this has made little headway is that we (the community, and specifically the core maintainers) need to agree which approach is preferred. It may also be that this is not causing a problem for many of the more experience core developers, so the debate has lacked traction so far, but I may be wrong about that.

Either way: We need to discuss and agree the desired approach, then code it.

To be able to do this properly in contrib, I think #309040: Add hook_requirements_alter() is required, but that itself seems to have some issues. I think #41 explains well why https://www.drupal.org/project/update_notifications_disable doesn't cut the mustard.

This suggest to me that #28/#31 is the way forward.

Patch #36 is working on drupal/core (9.4.2)

Attached rerolled patch against Drupal Version 9.5x,,
Kindly review patch,,

Patch #32 has been working for me on several Drupal 9.4.x sites, works great.

Still needs work per #47

#309040: Add hook_requirements_alter() just landed. It is much easier now to suppress this warning.

Rebased the current MR as that is not mergeable.

Ideally, there would be a way for expert administrators to disable this warning.

I agree with this direction proposed in the issue summary. Instead of downgrading the warning for everyone, wouldn't it be better to provide something like a switch in settings.php that admins and people in corporate, centrally-managed SaaS hosting situations could use to downgrade/disable this?

Removing credit for maintaining an MR that implements an approach we've already indicated is not acceptable by the release managers as per #39 and #40. Thanks!

Also, the fact that the contributed module may have some issues with it is a problem with that contributed module, not a reason to remove intentional security warnings from core.

Once autoupdates is in core, we should probably replace the current warning with a warning about autoupdates not being enabled. I could see that warning having a no-UI config option to disable the warning for hosting platforms where autoupdates is done on a staging environment or as part of a custom deployment workflow. It might be best to create a new issue for core autoupdates for that as part of the UX gate, and close this as a duplicate once it exists. Thanks!

Re-roll for Drupal 10.3.x.

Re-roll for 10.3.x branch, above one has little issue in finding file.

All issues should target the 11.x branch.

In addition, there is a merge request open, so please refrain from making changes by submitting patches. It's hard to see what changed without an interdiff, and it creates confusion to have both patches and a MR.

Facing issues here, not getting edit button while trying to target existing MR against 11.x

Even facing issue while creating new branch against 11.x :
Not able to search branch 11.x

Already 11.x selected however when create new button, getting error:
Failed to create branch '2869592-disabled-update-module-status': invalid reference name '11.x'

@smitghelani, @solideogloria, @pooja_sharma, @hswong3i. It is an important part of working on an issue to read the comments and the issue tags to determine what to do. Not all issues at needs work needs an MR updated. And comment #39 and #40 explained that the approach here is not acceptable. This was stated again in #60. The work here is an issue summary update and to provide the information asked for in #39.

Okay @quietone got your concerns, Thanks for flagging it out along with constructive feedback, recently I just have started exploring contribution. As this issue comments are too long due to which some comments that needs to be addressed remain unnoticed unintentionally, however try to make it sure contribute meaningfully in the right direction

I agree with #39 & #40, maybe it's best to think of something else instead of hide the warnings information from core itself, especially from a security perspective where transparency & awareness of potential risks are crucial.

If this request still needs, then I believe suggested one contrib module approach 'll fit well in this scenario.

Reroll for Drupal 10.2.7

Re-roll for Drupal 10.3.1

Adding new patch for 10.3.5

Hi @quietone,

I understood all the concerns mentioned in old chats, but it was necessary step required in lightning_core module, as it is added as dependency patch and not working with latest Drupal versions like 10.3.x and 11.x. So, for time being or i can say till we find alternative and most promising solution for this issue, we need something to keep this thing running in our project as it is.

So, that's why added new patch to replace it in lightning_core. But, lightning_core is still bottle neck with this issue and merge request with replaced patch is also in pending to merge. So, looks like I need to find some alternative options to get rid of it.

Hi @smitghelani,

I had the same problem with an older site with the Lightning distro on and I fixed it by adding this in my composer file:
"patches-ignore": {
"drupal/lightning_core": {
"drupal/core": {
"2869592 - Disabled update module shouldn't produce a status report warning": "https://www.drupal.org/files/issues/2869592-remove-update-warning-7.patch"
}
}
}

Hope that helps you!

Re-roll for Drupal 11.0.6

Rerolled to 11.x

Given #309040: Add hook_requirements_alter() is in core since 9.5.x and up, seems the update_notifications_disable contrib could be ported to use that mechanism to suppress or alter the warning, not the problematic methodology it used per the summary here.

I’d strongly be in favor of closing this as “works as designed”

Prior post:

Given #309040: Add hook_requirements_alter() is in core since 9.5.x and up, seems the update_notifications_disable contrib could be ported to use that mechanism to suppress or alter the warning, not the problematic methodology it used per the summary here.

I’d strongly be in favor of closing this as “works as designed”

I disagree. The use of that contrib module is not the only use-case where the warning occurs. It also occurs if you actually disable the update module, for example if the server doesn't have access to the Internet, and the check for updates creates network connection errors in the logs every time cron runs. That's my use-case.

Never mind. I re-read the issue summary and see what the contrib module is attempting to solve. Still, I'm not in favor of closing this until there's a workable solution.

@solideogloria: I think you misunderstand my point and the intention of that contrib module. It (was?) is implemented using a methodology that might have been necessary pre 9.5.0 core, but which has various problems. There's a better way now. If that contrib was ported to modern Drupal and used hook_requirements_alter(), it would actually do what it's supposed to - silence this warning. That's the whole point why that contrib module exists. So if you're in one of the use cases from comment #15 (or any other use case) where silencing this warning is actually a good move, install the (updated, and working properly) contrib module, once it has a new release. 😅

But we don't want to change this behavior in core, for all the reasons the release managers have already written (and which I fully support).

Opened #3523667: Use hook_requirements_alter() to only silence the warning, not take over the whole update.module namespace for the better solution to this problem.

#3523667: Use hook_requirements_alter() to only silence the warning, not take over the whole update.module namespace now has a working MR for a new branch. See also #3523761: Add dww as a co-maintainer for the 2.0.x branch. Or, I could move it into a whole new contrib project, something like update_hide_uninstalled_warning or something.

https://www.drupal.org/project/update_notifications_disable/releases/2.0... is now out.

Adding new patch for 10.4.7

In order to stop having to keep creating patches you can do this instead:

composer config --json extra.patches-ignore '{"drupal/lightning_core": {"drupal/core": {"2869592 - Disabled update module shouldn't produce a status report warning": "https://www.drupal.org/files/issues/2869592-remove-update-warning-7.patch"}}}'
composer require 'drupal/update_notifications_disable:^2.0@RC'
drush en update_notifications_disable

I'm uploading a new patch, this make it compatible with drupal 11.2.0-rc2

Please use the contributed module instead of continuing to post patches on this closed issue. Thanks!

Saving credits for a few folks that helped manage the issue discussion here, and then locking the issue to prevent further patches from being posted. If you think the functionality of the contrib module needs improvement, please file issues against it instead of core. Thanks everyone!