Fix text for update manager checkbox for disabled extensions

Added a patch for removing the checkbox for updating disabled modules, also removed it from the schema configuration file.
Please review.

I am currently working on it.

I also had to update some tests as they were checking for disabled extensions.

Starting from this issue, while searching for old references regarding the "disabled extensions", I made up a list of the following files I've discovered:
KernelTestBase.php @523
simpletest.module @483
node.module @1307
update.inc @563

I have also found a connected issue: https://www.drupal.org/node/2338167

I have also found a connected issue: https://www.drupal.org/node/2338167

Regarding the issue above, I spoked with alexpott, and for now, until the release I will post a separate patch documenting the deprecated status variable. Moving the discussion into the respective issue.

As for the questions about the references in some files for the "disabled extensions", I think there should be a separate meta issue, for finding/removing all these references.

I have also attached a screenshot.

I have applied the patch.
It's gone. Ok.

The patch looks fine to me.

This issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed a16cbda and pushed to 8.0.x. Thanks!

This needs to be rolled back since it's based on an incorrect assumption about what this checkbox does. (A reasonable assumption, though, given how the checkbox is labeled...)

This feature is not just for checking disabled modules, but uninstalled modules also.

You can easily verify that by installing a version of Drupal 8 from before the patch here was committed and then adding either https://www.drupal.org/node/2302087 (module) or https://www.drupal.org/node/2442867 (theme) to the site's filesystem. With the checkbox checked, Drupal 8 will warn that both of these are outdated.

This behavior makes sense, especially for security issues. Although rare, there have been cases where a module had a security issue that could be exploited simply by having the code in the filesystem.

Here's a rollback patch.

It would probably be a good idea to follow this up with a separate issue (for both Drupal 8 and Drupal 7) to improve/clarify the wording on this checkbox and other places in the admin interface that use this setting.

I've reverted the earlier patch. Let's rescope this issue to update the text for the checkbox for Drupal 8 rather than removing it. Thanks!

Working on updating the Patch at DrupalConLA... Patch to come.

Here is a new patch... Needs Review, wasn't sure if I should work to change the 'disabled' variable in the twig file to 'uninstalled'

"Enabled" vs "Uninstalled" doesn't look right to me. Seems like we either want "Enabled" vs "Disabled" or "Installed" vs "Uninstalled"?

In my earlier patch I tried to just fix the parts where it was very specific about saying "Disabled module" or "Disabled theme" and left the ones where it was using "enabled"/"disabled" a bit more generally. But perhaps it does make sense to move everything over to "installed"/"uninstalled" consistently.

I updated the template to use "Installed"/"Uninstalled" instead of "Enabled"/"Uninstalled".

In Drupal 7 we had installing (i.e. downloading the module code into the correct directory), enabling it (by ticking the tick box on the Modules page) which creates the appropriate database tables

Yes, although that distinction of "install" vs "enable" is not used consistently - see also #2543066: "Install new module" and "Install new theme" links are confusing

To cut it short: enable - uninstall is a legacy that we probably have to live with, and if it were to be change it needs to be changed at quite a few different places.

I agree - especially because of the above let's not change any "enable" to "install" in this patch. Consequently I'm not sure we should change "disable" to "uninstall" in cases where it is displayed right next to "enable", although we could (see my comment in #31).

I think the simplest thing to do here is just change cases where "disabled" is mentioned on its own. Those would be the most confusing. That's what I was trying to do in #26, I believe. "Enabled/disabled" displayed together is not as bad, I don't think.

Reuploading #26 for review.

Although I can't contribute much to the ongoing discussion, I can confirm that the patch 26 replaces the 'Disabled' references for 'Uninstalled' wherever it is mentioned on its own.

According with the comments of this issue, I verified the patch 26 and I confirm that it updates the text on the tickbox.

Committed 6352680 and pushed to 8.0.x. Thanks!

For the backport I guess we just want to clarify that it's disabled/uninstalled (rather than only disabled).

Backported to D7. Just improved the tickbox label wording as per #45.

@talhaparacha, good job.

This looks good to me changing it to RCTB.

@talhaparacha, good job.

This looks good to me changing it to RCTB.

-    '#title' => t('Check for updates of disabled modules and themes'),
+    '#title' => t('Check for updates of disabled or uninstalled modules and
+      themes'),

This shouldn't be broken onto multiple lines, since it's a basic translatable string.

I also think it should be "disabled and uninstalled" rather than "disabled or uninstalled". That reads more clearly to me (since we're checking updates of both, not either). Anyone else agree/disagree?

I guess either could be clearer depending on your point of view :) In any case here's a new patch that changes the wording and also fixes the line wrapping.

The errors seem unrelated to this patch. I have added an interdiff between 47 and 52.

This shouldn't be broken onto multiple lines, since it's a basic translatable string.

@David_Rothstein, I did not know that can cause problems.

I think this patch is good to go moving to RTCB.

Thanks. Regarding multiple lines, I'm pretty sure it won't cause problems - just more of a code style thing not to break up single function calls like that.

Bah, the testbot has become unhinged :)

Given the translatable string addition, I'll probably hold this off until after the upcoming release anyway to give translators more time to adjust to it after commit.

Committed to 7.x - thanks!

Changing tags since the release that includes this will probably be labeled Drupal 7.50 to indicate it contains some big changes.