Drupal core version inconsistent in Update Status module
tomrue - December 30, 2007 - 23:30
I am running Drupal 5.5 as shown in the CHANGELOG.TXT, but the Update Status module (5.x-2.0) is seeing core as ver. 5.3. I haven't been able to figure out why. Any suggestions on how to correct this, so the installed version appears correctly, would be appreciated.
Screen caps are on my site at http://tomrue.net/?q=version_inconsistency.
Thanks, and Happy New Year.
Tom
=-=
inspect a fresh download of 5.5 check the system/system.module and compare with the one running on your site, is the ID at the top the same ?
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Yes
Thanks for the reply. Yes, it is.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site), TNG 5.1.4, Gallery 2.1
I take that back.
The foregoing was /modules/system/system.module. I just discovered this in /sites/all/modules/system/system.module. I replaced it, and that fixed it. Thanks!
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site), TNG 5.1.4, Gallery 2.1
Sorry, I take that back too.
Not fixed after all.
At admin/logs/status it's now telling me that I'm running 5.5, but admin/logs/updates is still saying 5.3. I ran Cron, with no change.
Confused.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site), TNG 5.1.4, Gallery 2.1
What if the other files are
What if the other files are also 5.3? Update status usually measures the version of block.info.
So, remove all core files, then replace them with files from the 5.5 archive.
--
The Manual | Troubleshooting FAQ | Tips for posting | How to report a security issue.
Still no joy in Mudville
I removed all core files and replaced them with a freshly downloaded 5.5 archive, careful not to over-write any of the config.php files in /sites/ .
I went through each module, in both module folders, looking for any others that might refer to a core version and found none.
Following your link to "Troubleshooting FAQ", I tried disabling and then re-enabling the System module via PhpMyAdmin as described at http://drupal.org/node/157632. With /sites/all/modules/system disabled (set to 0 in MySql), I got a white screen on the site. When I changed it back to 1, the pages came up normally, but Update Status still sees 5.3.
This seemed like a long shot, but I changed my theme to Blue Marine (from LiteJazz). That made no difference. Then I ran Cron again, and once again on the Status Report page it said 5.5. However, when I manually ran Update Status, it reverted to a report of 5.3.
I looked through the "update_status.module" file looking for the path that it searches to determine the core version, but couldn't find the right line. ??
Or perhaps you can advise me on the proper grep command line to search the contents of files for the string version = "5.5"? Or if not grep, maybe something else along that line?
Thanks for your time.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
sites/all/modules/system is
sites/all/modules/system is not a normal location; as keith says, it has to go.
--
The Manual | Troubleshooting FAQ | Tips for posting | How to report a security issue.
WSOD
I've tried deleting /sites/all/modules/system a few times (and just did so again), and each time I attempt to open the site without it being there, I get a white screen of death on every node. Replacing it brings the site back up. The same is true for the /modules/system folder. If I delete it and leave the other one in place, I get a white screen.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
duplicate modules
I seem to have duplicates of all the core modules in /sites/all/modules, in addition to /modules/.
I specifically checked out block.info, and replaced it in both locations with the one from the fresh 5.5 archive.
I'm wondering, should I try deleting all the core modules that are in /sites/all/modules -- since they apparently don't belong there? (Don't ask me how they got there. I didn't put them there any time recently.) In a fresh install, there would be no modules in that folder. I suppose, then, that there should be no core modules there -- only contribs? However, one thing that's had me stumped is that whenever I try deleting one of them (filter.module or block.module, for example), I get the WSOD mentioned previously.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
I notice you say that you
I notice you say that you discovered this in the system.module in sites/all/modules? Do you have multiple copies of the system module (and possibly other modules) on your site? By default, core modules are installed in subdirectories under the modules directory, not sites/all/modules. However, if you have a copy of core modules that are also in the sites/all/modules directory, those copies are overriding the copies in your modules directory. I think you may have an old copy of core modules in your sites/all/modules directory for some reason, and those are overriding the newer copies in your modules directory. If you have not made any modifications to the code of the core modules in your sites/all/modules directory, you can probably delete (make backups first!) core modules that appear in sites/all/modules.
sites/all/modules is the recommended place to install custom or contributed modules, this allows you to separate your non-core modules and core modules and makes your update process simpler.
It did strike me as odd...
It did strike me as odd that Drupal seems to search for modules in both locations (/modules/ and /sites/all/modules/), but for some reason it appears to me that where there are duplicates, both copies are required. When I've tried disabling one of the duplicate modules (both via admin/build/modules as well as via PhpMyAdmin), regardless of which one, I get a white screen of death. It seems to scan both locations and require both.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
=-=
It does scan both locations, sites all for contributed and custom modules and modules/ for core modules. if you move core modules to sites/all it will still read them even though they really shouldn't be there.
somewhere along the way you added core modules to the sites/all
you may have to disable BOTH modules using phpmyadmin to sort this out properly and get your installation back to a normal drupal environment.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
This is a directory listing
This is a directory listing (ls -l > list.txt) of /modules/, followed by a directory listing of /sites/all/modules/...
The other list is, at /sites/all/modules/ is...
I'll try deleting the core modules from the latter list and post the result. Thanks.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
Deleted modules
Okay, this is what /sites/all/modules looks like now, after deleting each of the modules that comes with core.
Since I'm now getting a white screen on my site, I'll try disabling them in PhpMyAdmin as you say. (As an aside, I ought to prune out some of those contributed modules since I don't have them all activated.)
Thanks.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
Duplicates modules deleted
I removed all the modules that are duplicates of what appear in the /modules folder from /sites/all/modules. With a white screen, I then went to PhpMyAdmin and zeroed out the status on all of them. Still have a white screen.
I then attempted to run update.php, hoping that it would inform MySql of the changes. However, I get a message that says
Do I also need to edit the file of the core modules manually in PhpMyAdmin, so they point to /modules rather than /sites/all/modules?
I'd like to wait for confirmation on this question before proceeding, since I prefer not to make too many manual changes in the database in this way.
Thanks.
Tom
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
=-=
I'd hope you are doing all this on a back up of your DB or that you at least have a back up.
If in the DB the modules are referring to sites/all/ then this should most probably be changed.
also check your apache error logs, for more information on why you are getting a WSOD.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Backups
I backed up the full /drupal/ tree and all databases this morning. Worst case scenario is that I could lose today's edits on my personal site... which I'd rather not since I did make some. I've made no changes my other sites today. Minutes ago I just copied the database again, as I did this morning (though should have done that an hour ago, I guess). I'll give the further edits in PhpMyAdmin a try.
Thanks.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
Edits made
All of the core modules' file names in PhpMyAdmin now refer to /modules/ folder. I also reactivated them, resetting the core modules to 1.
I'm still getting a white screen.
No php errors come up with # tail /var/log/httpd-error.log.
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
Any other tables?
Are there any other Drupal tables in MySql besides System that refer to the locations of core modules?
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
A bunch of Apache errors
They weren't appearing at first, but now I'm getting the following in /var/log/httpd-error.log
I replaced the locales module in /sites/all/modules, since the last line seems to indicate Php was looking for it there. Can you tell what I'm overlooking?
Thanks.
Tom
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
=-=
looks like you may have accidetally deleted a table from the DB ?
inspect a backup for the table it claims to be missing.
Outside of that, I don't know what else to to have you do. I've never been in your situtaion.
you may have to start disabling contrib.modules in an effort to bring your site back up.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Restored backup
I copied this morning's backed up database files into /var/db/mysql and the site's back online -- unfortunately, losing today's content. (No one to blame but myself for not making another backup this evening before I started in PhpMyAdmin.) I can redo today's site changes -- not a big deal.
I'd still like to get the modules straightened out. But not tonight.
Should I return to this discussion thread tomorrow, or start a new thread?
Thanks for your help. At least we identified the problem.
Tom
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
Update Status issue resolved, still with duplicate core modules
After restoring from backup last night, as mentioned, this morning I deleted the core modules from /sites/all/modules/ again, and replaced them with copies known to be current, from a fresh Drupal 5.5 archive. This resolved the problem with Update Status misreading the Drupal core version. Update Status now reports everything as green, including Drupal core. Obviously, although I hadn't been able to identify it by looking at the individual module files, one of them was the culprit and was misinforming Update Status.
I'm not aware of any harm or risk caused by having core modules in both locations (/sites/all/modules/ and /modules/), but I would prefer a normal Drupal environment. (The only inconvenience that the duplication causes that I can see is that, in order to run update.php and not get a white screen, I have to temporarily disable [rename] one of the two filter modules, then change it back. If I don't change it back, after running update.php, I get a WSOD again.)
Thanks especially to VeryMisunderstood, and also to Heine, for helping me diagnose the immediate problem described in the subject of the present thread. If I can't fix the remaining issue by myself (which doesn't look promising), I'll start another thread asking for advice on how to properly get rid of the duplicate core modules, including any actions necessary in PhpMyAdmin.
Happy New Year.
Tom
--
http://tomrue.net
# FreeBSD 6.1, Apache 1.3.24, PHP 5.1.2 mod_perl/1.29, MySql 5.0.18
# Drupal 5.5 (multi site)
=-=
I don't know that there is any real "risk"
BUT...
you'll have to remember to replace those during the next update/upgrade
I'd also venture a guess that you may be using more memory on your server then necessary because of the extra instances of core modules
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )