Per issue #1199946 the concept of disabled modules has been completely removed. We need to scour existing documentation and code to find and change references to enabled/disabled modules.

Proposed resolution

Find and change all existing references to enabled-enabling/disabled-disabling modules and change to reflect concept of installing/uninstalling.

Remaining tasks

  • Do inventory of codebase to find references to enabled/disabled modules
  • Create separate issues for each module, identifying the task as either documentation change or code change
  • Complete changes via the newly created issues

Original report by @fubhy

Follow-up for #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

In order to keep the patch at #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed as reviewable as possible we agreed to not fix every single place in the documentation that talks about disabled/enabled modules as that would've easily caused the patch to settle somewhere close to 500kb which is something we really want to avoid for such a fundamental change of the underlying system.

Hence, once it get's committed, we will have to fix/remove/clean-up a lot of places in core where the documentation still refers to disabled/enabled modules or potentially even change variable names that suggest the existence of such ($enabled_modules / $disabled_modules, etc.). That's what this issue is about.


catch’s picture

Status: Active » Postponed
catch’s picture

Status: Postponed » Active
YesCT’s picture

Noticed in #1887136: PHP warning/notice when disabling and uninstalling modules
For example,
says "Check for updates of disabled modules and themes"

but maybe we just remove that totally? Does it make sense to "Check for updates of uninstalled modules and themes"?

baisong’s picture

Issue summary: View changes

Since #1199946 is closed (fixed), is this task still waiting on any milestone? Or can the documentation changes be started now?

catch’s picture

This isn't waiting on anything that I know of.

@YesCT/#3. I have a feeling that checks for not-installed projects found in the filesystem, not just disabled modules, so it might just be a re-word, but we should definitely check that yes!

Barry Madore’s picture

I'm willing to begin tackling this. It seems to me that we'll need to:

  • inventory instances needing a documentation fix
  • create new child issues for these fixes (per module?); for example, one for system.module that outlines the changes necessary for the /admin/help/system page
  • knock off each fix one by one

Does this make sense?

Also, if I understand the issue correctly, wouldn't this same fix be required for documentation about enabled/disabled themes?

Let me know if I'm on the right track or not and I'll assign this to myself and begin work.

Barry Madore’s picture

Title: Fix documentation that refers to enabling/disabling of modules » [Meta] Fix documentation that refers to enabling/disabling of modules
Assigned: Unassigned » Barry Madore

After talking with xjm, I confirmed that an inventory resulting in separate issues for each instance is the way to go. She clarified that there are two types of fixes that will be necessary:

  • documentation instances
  • code instances -- places where there are dead links/hooks referring to disabled modules; these will require code fixes not documentation fixes

I'll create issues for each type of fix and make them children of this meta issue.

Barry Madore’s picture

Issue summary: View changes
xjm’s picture

Thanks @bmadore! Nice work.

Also, if I understand the issue correctly, wouldn't this same fix be required for documentation about enabled/disabled themes?

Themes actually still have a disabled status, so it's just the cases that refer to modules that we should fix.

Barry Madore’s picture

Thanks @xjm for the clarification. @xjm and @David_Rothstein, is it wise to to hold off on making extensive documentation (and potentially code) changes if the whole disabling of modules debate is still open? It is implied in #2081873 that there may yet be a chance to re-introduce a disable module option in D8.

I'll continue the effort to document enable/disable language instances as this will be helpful regardless but will hold off on creating a slew of change tasks until I understand better the finality of the disable situation in core.

catch’s picture

@bmadore most of the stale references are places that used to be doing disabling, but now do uninstalling. So regardless of that issue I think it makes sense to get core consistent with itself now.

khanson’s picture

I've created a google docs spreadsheet to track who is working on which section of the code base:

xjm’s picture

Issue tags: +TCDrupal 2014
xjm’s picture

Thanks @khanson! Can you make the google doc public edit ("with link") so that anyone can access it going forward?

xjm’s picture

The doc was shared with me and I switched it to be publicly editable. Thanks!

xjm’s picture

#2232605: Themes cannot be uninstalled has gone in and should make this a lot easier.

moshe weitzman’s picture

Component: base system » documentation
xjm’s picture

Issue tags: +Triaged D8 critical
yoroy’s picture

Devin Carlson’s picture

All of the child issues are now fixed, are there any other documentation changes that need to be addressed in this meta?

catch’s picture

Status: Active » Fixed

This was originally for code comments so I think in terms of this meta-issue we're OK. is the change notice for the original patch.

#2035079: Figure out what to do with the install/uninstall modules page is the place to sort out inline help text, and once that issue is completed (as well as some of the module uninstall validation that's happening as part of CMI dependency work) it'll be easier to update site admin-facing docs.

Going to go ahead and mark this fixed. If there are any additional documentation follow-ups they should be new issues rather than re-opening this one (but add a link here of course).

Great to see all the sub-issues in!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.