Problem/Motivation
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.
Comments
Comment #1
catchComment #2
catchComment #3
YesCT CreditAttribution: YesCT commentedNoticed in #1887136: PHP warning/notice when disabling and uninstalling modules
For example,
admin/config/regional/translate/settings
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"?
Comment #4
baisongSince #1199946 is closed (fixed), is this task still waiting on any milestone? Or can the documentation changes be started now?
Comment #5
catchThis 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!
Comment #6
Barry Madore CreditAttribution: Barry Madore commentedI'm willing to begin tackling this. It seems to me that we'll need to:
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.
Comment #7
Barry Madore CreditAttribution: Barry Madore commentedAfter 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:
I'll create issues for each type of fix and make them children of this meta issue.
Comment #8
Barry Madore CreditAttribution: Barry Madore commentedComment #9
xjmThanks @bmadore! Nice work.
Themes actually still have a disabled status, so it's just the cases that refer to modules that we should fix.
Comment #10
David_Rothstein CreditAttribution: David_Rothstein commentedNote: #2081873: Re-implement module disabling in a temporary/debugging capacity that is environment aware and explicit about risks to data integrity
Comment #11
Barry Madore CreditAttribution: Barry Madore commentedThanks @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.
Comment #12
Barry Madore CreditAttribution: Barry Madore commentedComment #13
catch@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.
Comment #14
khanson CreditAttribution: khanson commentedI've created a google docs spreadsheet to track who is working on which section of the code base: https://docs.google.com/a/fisdap.net/spreadsheets/d/1xegYOvdEwxG32Bc1WC8...
Comment #15
xjmComment #16
xjmThanks @khanson! Can you make the google doc public edit ("with link") so that anyone can access it going forward?
Comment #17
xjmThe doc was shared with me and I switched it to be publicly editable. Thanks!
Comment #18
xjm#2232605: Themes cannot be uninstalled has gone in and should make this a lot easier.
Comment #19
moshe weitzman CreditAttribution: moshe weitzman commentedComment #20
xjmComment #21
yoroy CreditAttribution: yoroy commented#2035079: [PP-3] Figure out what to do with the install/uninstall modules page might well have impact on this.
Comment #22
Devin Carlson CreditAttribution: Devin Carlson commentedAll of the child issues are now fixed, are there any other documentation changes that need to be addressed in this meta?
Comment #23
catchThis was originally for code comments so I think in terms of this meta-issue we're OK.
https://www.drupal.org/node/2193013 is the change notice for the original patch.
#2035079: [PP-3] 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!