On the status report, if you have uninstalled the Update module you will get a big scary warning:

Update notifications are not enabled. It is highly recommended that you enable the Update Manager module...

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. In these cases, the warning is just a distraction and contributes to a "crying wolf" mentality.

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

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

Dane Powell created an issue. See original summary.

Dane Powell’s picture

Issue summary: View changes
Status: Active » Needs review
FileSize
1.68 KB

This patch adds a flag that can be used via settings.php to disable the warning.

Dane Powell’s picture

FileSize
1018 bytes

This patch is identical to #2 but without the modifications to default.settings.php, which is applicable to composer-based installs.

Dane Powell’s picture

Dane Powell’s picture

vaplas’s picture

IMHO, that the amount of danger of such an opportunity greatly exceeds the possible benefits.

I hope the enterprise developers сan solve case from IS without the solution out of the box. And I hope that the problem with updates will be solved through simplification (like #606592: Allow upgrading core with the update manager), not through ignoring :)

japerry’s picture

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.

Dane Powell’s picture

I guess I'd prefer the approach in #7 since it solves this without requiring user intervention, although it is more of a functional change than what I proposed in #2.

Dane Powell’s picture

Status: Needs review » Reviewed & tested by the community
alexpott’s picture

Status: Reviewed & tested by the community » Needs review

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.

xjm’s picture

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’s picture

Title: Disable warning about update notifications » Disabled update module shouldn't produce a status report warning

That module is an okay workaround, but I agree with japerry in his comment here that core is fundamentally abusing the use of warnings, and it's a problem that should be solved in core, not just worked around. The best solution in my mind would be to reduce the severity of the warnings to info messages. That's not something solved by a contrib module.

xjm’s picture

@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.

catch’s picture

Status: Needs review » Needs work

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.

japerry’s picture

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 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 security coverage for more discussion)

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.