Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hi
I just upgraded two Drupal 7.4x sites to 7.50 and see lots of errors on what appears to be old module entries in the system table (schema versions indicate Drupal 6.x). All of these modules are not present anymore on the filesystem (understandable as they would not work) but I'm prompted to restore them anyway.
The same for left-overs entries of Drupal7 modules that where deleted from disk (instead of uninstall).
Messages like
User warning: The following module is missing from the file system: atom_reference. In order to fix this, put the module back in its original location. For more information, see the documentation page(link is external). in _drupal_trigger_error_with_delayed_logging() (line 1128 of /x/httpd.www/includes/bootstrap.inc).
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2764131-3.patch | 1.56 KB | David_Rothstein |
Comments
Comment #2
cilefen CreditAttribution: cilefen commentedThere have been about 6 issues opened for this recently. All can be handled by reading and following the documentation: https://www.drupal.org/node/2487215
Comment #3
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI guess it's probably better for the message not to recommend a specific solution, when that solution (although usually correct) isn't always applicable, and when the documentation actually has several different suggested solutions for different scenarios...
Here is one possible way to improve that.
I left the "moved within the file system" message alone since for that one I think the default solutions is essentially always correct.
Comment #4
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedI agree with the message change, RTBC.
This is a string change, right?
Comment #5
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedOh and maybe we should add a backtrace somewhere or allow setting a variable to get a backtrace?
Hacking core to find out who the hack is calling that is ... really bad.
Comment #6
cilefen CreditAttribution: cilefen commentedComment #7
stefan.r CreditAttribution: stefan.r commentedI'm fine with that change as well.
Comment #9
stefan.r CreditAttribution: stefan.r commentedCommitted and pushed to 7.x, thanks!
Comment #11
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI guess kind of... it will probably run through t() on display, but I don't think it will ever appear on localize.drupal.org.
We should use the issue tag for the right release though :)