Followed upgrade steps but "core-required" didn't change
I started with 6.6 working fine -- I've downloaded upgrades and installed them several times (tried both 6.7 and 6.8). I think I followed all the steps (went offline; saved DB; saved Sites, Files, ini.php; disabled all modules but Core/Required; deleted 6.6. files; unzipped 6.7/6.8 into same place; copied back old Sites, Files, ini.php; ran install.php). With modules enabled and back online, the site runs well, BUT...
"/reports/updates" stills shows "Security update required!" and Core - required (under /build/modules) shows all elements are still 6.6.
Just in case, I replaced my old "settings.php" with "default.settings.php" from the new download; edited it with correct settings (it works), but no change.
So, what am I missing?
Many thanks for any help!
Title here should have been "update" (not "upgrade")
Used wrong term. It was an update, 6.6 to 6.7 or 6.8
Run update.php
You need to run update.php and check for any errors it reports.
---
"Nice to meet you Rose...run for your life." - The Doctor
My first public Drupal site - EyeOnThe503
update.php was run
Failed to include that I did run "update.php" (not install.php). It ran successfully each time (4 or 5); showed no errors. This is part of my confusion.
The version of your
The version of your installation is defined at the very top of modules/system/system.module. What can you see there?
gpk
----
www.alexoria.co.uk
Top of /system.module includes "define('VERSION', '6.8');"
Thanks for the reply.
Mystery remains.... Here are the lines from the top:
<?php
// $Id: system.module,v 1.585.2.26 2008/12/11 17:39:42 goba Exp $
/**
* @file
* Configuration system that lets administrators modify the workings of the site.
*/
/**
* The current system version.
*/
define('VERSION', '6.8');
CHANGELOG.txt shows 6.8
For good measure, I checked CHANGELOG.txt. Here's what it shows:
// $Id: CHANGELOG.txt,v 1.253.2.20 2008/12/11 17:39:41 goba Exp $
Drupal 6.8, 2008-12-11
----------------------
- Removed a previous change incompatible with PHP 5.1.x and lower.
Drupal 6.7, 2008-12-10
----------------------
- Fixed security issues, (Cross site request forgery and Cross site scripting), see SA-2008-073
- Updated robots.txt and .htaccess to match current file use.
- Fixed a variety of small bugs.
What is the full filesystem
What is the full filesystem path to your Drupal installation and to the system.module file?
Also if you have left the 6.6 copies lying around under /modules, /profiles or /sites/*/modules then they may get picked up instead of the new ones.
What version are the Core - optional modules showing?
gpk
----
www.alexoria.co.uk
Full filesystem path ++
Thanks again for staying with me. Hope it's useful to others, too.
Filesystem path to Drupal installation: /www/www/files, includes,... (e.g., and rest of Drupal files here). (There are a couple subdomains off of /www/... , but those are running Drupal 5.) Should the Drupal files be in a directory named Drupal under www/www/ ? As noted 6.6 has been, and is, running fine.
Path to system.module: /www/www/modules/system/(system.module here)
Looked for 6.6 files elsewhere in installation location; didn't find any (tho I may not know all the places to look)
Core-optional modules also show 6.6
dfs
Can you try clearing the
Can you try clearing the caches at admin/settings/performance in case for some reason the version info is cached but is not updating.
>I may not know all the places to look
The ones I suggested, basically. Or if you have shell access you could do, from /www/www,
find . -name system.module -printAlso what is the version info in the system.info file?
gpk
----
www.alexoria.co.uk
Clearing cache; search, system.info
* I cleared caches a day or so ago, and again just now. The security alert goes away (got my hopes up) until I go to /reports/updates, then comes back.
* I'll have to check w/ support at my host (ICDSoft) about shell access.
* system.info contents:
; $Id: system.info,v 1.4 2007/06/08 05:50:56 dries Exp $
name = System
description = Handles general site configuration for administrators.
package = Core - required
version = VERSION
core = 6.x
; Information added by drupal.org packaging script on 2008-12-11
version = "6.8"
project = "drupal"
datestamp = "1229018427"
------------------
Thank you!
System modules
gpk...
Your questions led me to look more closely at the /system module. In the www/modules directory, the files in the /system module all referred to 6.8. However, when I looked at the /system module in the www/sites/all/modules directory, the files were still 6.6. (Because I copied the /sites directory and added it back after installation.)
So, on the chance that this was the source of the problem, I replaced the 6.6 /system module in the sites/all/modules directory with a copy of the 6.8 /system module from the www/modules directory. Cleared caches again for good measure.
Didn't fix the problem. BUT it does make me wonder if there is some other item I saved and added back that could be causing the problem. I saved/brought back /sites, /files, and /ini.php.
Thoughts?
dfs
Um if I may ask, why do you
Um if I may ask, why do you have a copy of the system/ module folder in sites/all/modules? You need to remove all core modules from there since any module in sites/all/modules, sites/default/modules or sites/[sitename]/modules will override stuff in plain ol' modules.
gpk
----
www.alexoria.co.uk
I removed the system module
I removed the system module from /sites/all/modules. It blew up the site (some fatal error I failed to record). I moved a new 6.8 system module back into sites/all/modules. Whew, only the pre-existing problems remained. (I guess even if it defaults to the wrong directory [sites/all/modules], having the 6.8 system module there hasn't helped.)
Any idea why that would happen?
Could there be another 6.6 module in sites/all/modules that would effect the core?
I am learning a lot; thanks.
To revert the 5 required
To revert the 5 required core modules (filter, node, block, user, system) to the correct locations you would probably have to edit the {system} table in the database, correcting the paths shown there. Then you should be able to get rid of the copies that shouldn't be in sites/all/modules. For other core modules it's probably best to disable them all, get rid of the naughty ones and then re-enable. Drupal will auto-discover whatever it can find each time you visit the modules admin page.
gpk
----
www.alexoria.co.uk
This is really is beyond my
This is really is beyond my skill level, but --- used phpMyAdmin to locate table named "system" in site DB. First three filenames in the table start with "modules/". The only one that seems like it might be relevant is "modules/drupal/drupal.module" Besides the first three, all the rest of the filenames in the table start w/ "sites/all/modules".
Located filename "sites/all/modules/system/system.module"
Changed the "Value" for the "Field" named "filename" from "sites/all/modules/system/system.module" to "modules/system/system.module".
Site still used 6.6. The new filename value persisted when I exited/then re-entered edit mode; however, it reverted to original value when I exited and re-entered the "system" table.
The "info" area for "sites/all/modules/system/system.module" contains:
a:10:{s:4:"name";s:6:"System";s:11:"description";s:54:"Handles general site configuration for administrators.";s:7:"package";s:15:"Core - required";s:7:"version";s:3:"6.8";s:4:"core";s:3:"6.x";s:7:"project";s:6:"drupal";s:9:"datestamp";s:10:"1229018427";s:12:"dependencies";a:0:{}s:10:"dependents";a:0:{}s:3:"php";s:5:"4.3.5";}
Anything useful here?
Really appreciate the help.
dfs
>however, it reverted to
drupal.module is a leftover from an earlier version of Drupal (4.7.x or 5.x - I can't remember when it was retired).
>however, it reverted to original value when I exited and re-entered the "system" table
That shouldn't happen unless you visit the modules admin page I think, which causes a "re-scan" (auto-discovery) of all modules present.
The info field is also showing 6.8
"version";s:3:"6.8";gpk
----
www.alexoria.co.uk
Enable PHP module, create a
Enable PHP module, create a new node, PHP input format:
<?phpprint dirname(realpath('./index.php')) . '/' . drupal_get_path('module', 'system');
?>
gpk
----
www.alexoria.co.uk
Enabling PHP module --
Not really sure what to do with this, so I improvised:
I added your lines to the php.ini file. No change. Then I put it in a php file I created (called it sys.php) that I put in the root directory. I took my life (or at least a couple hours of it) in my hands and ran .sys.php; got fatal error message, but no lasting impact.
What is this intended to do?
Thanks....
Go to the modules admin
Go to the modules admin page, there is one called PHP, turn it on, then Create content -> page or story, select PHP input format under the body textarea and then paste the code into the textarea. Submit/Save.
It will tell you which system.module is being used by Drupal.
gpk
----
www.alexoria.co.uk
Great instructions. And
Great instructions. And the answer is..... /home/[sitename]/www/www/sites/all/modules/system
Now my question is... if the system module in /sites/all/modules is updated to 6.8, why doesn't the site run on 6.8? (I ran update.php again in case that might make a difference; also emptied caches.)
Well yes, both copies seem
Well yes, both copies seem to be 6.8 so goodness knows where the 6.6. is coming from.
There must be something obvious I've forgotten. It might still be worth getting the core modules in the "right place" first - it may become apparent what's going on in the course of doing this.
gpk
----
www.alexoria.co.uk
For anyone checking this
For anyone checking this forum, my most recent effort involved adding, enabling and running the System Info module at http://drupal.org/project/systeminfo [Thanks to Gumugum at http://drupal.org/node/109366] Under the "Drupal" section, it returned "Version 6.8"
Still a mystery. Sherlock, are you following this?
Well I'm largely convinced
Well I'm largely convinced that your site is running 6.8, I'm just at a bit of a loss as to where the 6.6 is coming from. Unless it is cached somewhere and the cache is not clearing properly.
May be worth doing a search for this problem.
gpk
----
www.alexoria.co.uk
To get it working with core modules in /modules...
1. Backup the database
From Drupal admin interface:
2. Put site in offline mode
3. Disable all non-core modules
4. Disable all core - optional modules
Now in your FTP client or however you manage the files:
5. Move *all* the core modules out of sites/all/modules. Maybe just rename this folder to sites/all/modules-2delete, and move any contrib modules you need back into a new sites/all/modules (you could do that bit later).
At this stage your site should be inacessible and you should get drastic looking PHP error messages. :-D
6. Now go back into the database and edit the filenames for the 5 required modules: block, filter, node, system, user. Make sure there is only one entry for each of these (I can't think how there could be more but worth checking).
7. Your site should now be accessible again, use the special PHP page we created to check the right system.module is being used. You can now re-enable non-required and contrib modules, put the site back in online mode and delete the modules-2delete folder when you are happy with everything.
A final thought - it is in theory possible to have 2 different sites that accidentally have the same database specified in settings.php ...
gpk
----
www.alexoria.co.uk
* I've started dealing w/
* I've started dealing w/ core modules in sites/all/modules. Looks to me like all 5 are in the "system" table (along with other modules). Have to break for while; back tomorrow.
*Also ... wondering... I added CiviCRM recently. Since that requires INNODB, I set that as the engine in the Civi DB. The site DB is still MylSAM. Any chance that might have something to do with this issue?
Thanks
>Any chance that might have
>Any chance that might have something to do with this issue?
Not unless that bundles the whole of Drupal in the download...
gpk
----
www.alexoria.co.uk
Similar Issue
I am having a similar issue. Updating site from 6.6 to 6.8. Very Very VERY frustrated. I first followed all of the steps exactly (at least 10 times and counting), and am still getting the reported version at 6.6.
Then I noticed under my /var/www/html/sites/all/modules folder a directory for drupal-6.6. Thought that looked odd, so removed it and replaced it with the drupal-6.8 files. Now I've gotten a series of errors and the white screen of death when I run update.php.
Since I am a newbie, and not very proficient with PHP, this is starting to make me wish I'd used a different CMS.......(I know, I know: I'm being overly dramatic, but this is really getting me down).
Good thing I have an automatic restore script, or I'd be even more cranky...
Hummmm
Ok -- this is seriously hackalicious, but I got the version to update by doing the following:
1) Followed all the update instructions up to the point of copying my /sites directory back into /var/www/html
2) Went into /var/www/html/sites/all/modules/drupal-6.6, and emptied it of files
3) Copied all of the files that were in the untarred drupal-6.8 directory into the /var/www/html/sites/all/modules/drupal-6.6 directory
4) Ran update.php -- but WITHOUT renaming the /var/www/html/sites/all/modules/drupal-6.6 directory (which I had done all previous times)
Sounds (and looks) like voodoo, but it did the trick, and now my site is happily reporting that its been upgraded to 6.8. Worst 12 hours I've had in a looong time.
Thanks!
I've had the same problem and your workaround seemed to work. All real strange stuff, but apparently it's updated to 6.8 :)
By the way, update.php still showed "no updates available" but I ran it anyway - witch worked obviously.
Thanks for your fix :)
Jasper.
Damn, while upgrading to 6.9
.
Thanks for the hack
I am glad I found these posts. Since I only just installed Drupal for the first time in October and have been playing with it for the past few weeks, I experimented with this update. I have two sites, and on one web site I did the Update and on the other I tried to do a clean install. I had the same nightmare with both. I just completed a "successful" update and it is telling me in the status report that I need to update to 6.8.
Interestingly enough, that Update consisted of nuking my entire 6.6 installation, re-installing 6.6 and then running update to 6.8. It still didn't work. It's nice to know that I am not alone :-)
>it is telling me in the
>it is telling me in the status report that I need to update to 6.8.
What version is shown at the top of the page?
gpk
----
www.alexoria.co.uk
the non-upgrade
When I went back to look, the Status report page indicated 6.6 not 6.8 even though the Update.php reported a successful update. I have torn this installation apart attempting to get it done right. I am now back to a clean 6.6 install with no optional modules of any kind. The sites/all folders are empty, modules are moved into a new folder... I moved the 6.8 folders into my formerly functional 6.6 install and the page displaying Drupal no longer functioned as expected. The problem is that my browser returned a http 500 error when I ran update.php.
I would start clean with a 6.8 install except I cannot seem to erase the trail left by Drupal 6.6 on my hosted server. Even with full admin permissions, I cannot get rid of the settings file. grrrrrrr
In the end I discovered the mistake I had made in my privileges and I was able to successfully complete the 6.8 clean install. That error was not a factor in my 6.6 to 6.8 upgrade and as happy as I am that I now have a secure platform, I dread doing this again for 7.0 at which point my sites will be live.
You really should not have
You really should not have any core modules in sites/all/modules. The idea is to have only your own personal stuff (settings, custom modules/themes, contrib modules you need for your site) in the sites folder and then all other stuff is "Drupal core" that can be replaced with a new version as and when you upgrade. The only other files you *might* have modified are /.htaccess and /robots.txt. There may also be a folder /files if the site used to run 4.7.x or earlier.
From the other point of view, the new version of Drupal is not just the /modules folder, you also need /includes and all the other stuff. If these are under the sites/all/modules folder they won't get picked up (though the modules do, which is a mixed blessing).
gpk
----
www.alexoria.co.uk
Thank You
I upgraded successfully to 6.8 and status report says 6.8.
Updated a fresh install of 6.6, no contrib mods yet.
Same issue with a twist
Maybe this will be of some help to the dev's. I upgraded 2 different sites. One is hosted in the main system directory /public_html and the other is in a subdirectory of the main directory. The one in the subdirectory upgraded to 6.8 with no issues. The one in the main directory is still showing 6.6 using the exact same steps I successfully upgraded my other installation with. Hope this helps.
System Info Module
I just ran the system info module and this is the info I received on the core modules.
Block 6.4 modules/modules/block/block.module 0Color 6.4 modules/modules/color/color.module 0
Comment 6.4 modules/modules/comment/comment.module 0
Contact 6.4 modules/modules/contact/contact.module 0
Database logging 6.4 modules/modules/dblog/dblog.module 0
Filter 6.4 modules/modules/filter/filter.module 0
Help 6.4 modules/modules/help/help.module 0
Menu 6.4 modules/modules/menu/menu.module 0
Path 6.4 modules/modules/path/path.module 0
PHP filter 6.4 modules/modules/php/php.module 0
Poll 6.4 modules/modules/poll/poll.module 0
Profile 6.4 modules/modules/profile/profile.module 0
Search 6.4 modules/modules/search/search.module 0
Statistics 6.4 modules/modules/statistics/statistics.module 0
Syslog 6.4 modules/modules/syslog/syslog.module 0
System 6.4 modules/modules/system/system.module 0
Trigger 6.4 modules/modules/trigger/trigger.module 0
Update status 6.4 modules/modules/update/update.module 0
Upload 6.4 modules/modules/upload/upload.module 0
User 6.4 modules/modules/user/user.module 0
Node 6.8 modules/node/node.module 0
Ping 6.8 modules/ping/ping.module 0
Taxonomy 6.8 modules/taxonomy/taxonomy.module 0
Throttle 6.8 modules/throttle/throttle.module 0
Tracker 6.8 modules/tracker/tracker.module
It almost looks as if I went into myphp admin and removed one of the 'modules/' in the file directory that it should solve itself. I still have to look in the directory itself with the ftp client yet.
I hope this helps.
Temporary Fix
I've come up with a temporary fix to get the problem resolved in the first place but it seems that there is still a lingering problem that maybe someone more experienced will have a solution too. In my case it appeared that all of my 6.8 files were located in /public_html/modules/. There were also 6.4 files located in /public_html/modules/modules/. For some reason in the system table in my database, some of the filepaths were pointing to the directory with the 6.4 files. The easiest fix was to copy /public_html/modules to /public_html/modules/modules. Do note that you need to copy the files and not move them. If the actual problem gets resolved you don't want your site to go down. Also, this is really only a work around and doesn't solve the actual problem. I also changed the file paths in my system table in the database to modules/* and not modules/modules/*. I then ran the update.php and voila. My sites were running with no errors. Now this is why this was a workaround and not a solution. When I finished all of that I tried to delete /public_html/modules/modules/ by first renaming it. However, this caused php errors and would not load the website. This is where I think someone more proficient might be able to help. I'm guessing there is a php file or something trying to call the modules from /public_html/modules/modules/. Hope this is helpful to some. Also, hope this helps fix the problem. Thanks.
>my 6.8 files were located
>my 6.8 files were located in /public_html/modules/
Good. That's where they should be.
>6.4 files located in /public_html/modules/modules/
Not good. I would not be surprised that this might cause conflicts.
>For some reason in the system table in my database, some of the filepaths were pointing to the directory with the 6.4 files.
By design, Drupal scans the entire directory structure underneath the modules/ folder, looking for all modules (IIRC it actually looks for the .info files). So I'm not surprised if it "finds" the copies under modules/modules/. I don't think that a "broken" installation like this is something that Drupal should really try to work round.
To fix it "properly" I suggest:
1. Disable all modules except "core - required" (block, filter, node, system, user).
2. In the {system} table in the DB check that the filepaths for the core - required modules are pointing to the correct location
3. Move the modules/modules/ folder outside the modules/ folder (e.g. rename it "modules-oops" and move it up a level; you can delete it later). This is important, since otherwise Drupal is likely once more to "autodiscover" the copies in the wrong location.
4. You should now be able to re-enable the other modules.
gpk
----
www.alexoria.co.uk
I attempted this and still
I attempted this and still received a fatal error message.
>received a fatal error
>received a fatal error message
And the details...?
gpk
----
www.alexoria.co.uk
I attempted this and still
*Duplicate*
gpk -- many thanks for
gpk -- many thanks for hanging in with this!
I started this topic just about a month ago, and although I dropped out (w/o fixing the problem) a while back, I wanted to give you (and fellow seekers) an update.
I came back to this a few days ago and decided I needed a fresh start; my site was pretty bare bones, so not a huge loss. I created a new subdomain, set it up with 6.8 and a new database. I added the 6.8 modules I wanted (theme was/is core, with some css tinkering that I did again). I did bring in the old [files] folder to avoid a lot of uploads. The site is now (completely) 6.8, tho I know that unexpected things happen.
I'm glad to be done with the constant warnings about the need to update (tho I didn't take them too seriously), and I assume that the next update/upgrade will be less risky than going from a fix.
I know this won't work for lots of folks; in fact, it will be more trouble for me on two other sites that were cloned from the same original site.
And 'll be watching to see if your suggestion here works for people.
I learned a lot from your posts; thanks again.
dfspdx
OK, glad it's working, the
OK, glad it's working, the important thing is I think that you have a fresh codebase.
When you next upgrade make sure you don't end up with duplicate copies of modules lying around (or old copies) underneath the main Drupal folder. Sorry, you've probably worked that much out by now!!
In principle it would be possible to connect the database from your problematic install to a fresh codebase and after a bit of fiddling in the {system} table it should all work, but I can quite appreciate your preference to start afresh!
Best,
gpk
----
www.alexoria.co.uk
Damn, while upgrading to 6.9
Damn, while upgrading to 6.9 I'm having the exact same problems.. I followed the instructions (and even with copying all 6.9-files into /sites/all/modules/drupal-6.6) I'm getting "no updates available" in update.php. Any suggestions?!
the same issue
nevermind, I guess I didn't run the process the right way