By yagraph on

Hi all, and thanks for your attention,

With Drupal 6.13 I did have a session bug who continually disconnect the admin user after his connection (or maybe I did something wrong).
This cause me to do a not-so-clean update.php with Drupal 6.14, with settings.php on "$update_free_access = TRUE;", and contributed modules and themes not disabled ....

At the end of the update process, it seems the update works, but a lot of errors appeared (Duplicate entries and etc.). Anyway the session bug disappeared and my site is up to work.
Except... the update status module still say I'm using Drupal 6.13 despite the fact i'm sure it's 6.14... And I've the same bug with a contributed module, who show a previous version number despite the fact I've updated it.

I did try to redo update again and again, but with same errors... searched google and this forum with no success...

And the icing on the cake, I dot not have database backup with drupal 6.12, which could have allowed me to restore all before my 6.13 problems.

So... Here is my answer : is there a way to clean the database with phphMyAdmin, or a alternative way ?
I'd really like to fix this mess and have an update status module who display correct informations.

Can you help me ?
Thanks,
yagraph

⋅ Categories: Drupal 6.x

Comments

vm’s picture

vm commented

the version of core is pulled from the system.module. Check to ensure that the version of your system.module is consisent with the version in Drupal 6.14.

also ensure that your backedup files, are not backed up in your drupal installation anywhere. I've seen other issues on the forums where users had two modules folder which caused issues when duplicate module were unintentionally left.

yagraph’s picture

yagraph commented

Thanks for your quick reply !

I've just checked my system.module :

/**
* The current system version.
*/
define('VERSION', '6.14');

... So it look correct but update status module do not see it ?

I have no duplicated module folder neither...
It's a mystery !

Maybe another clue : My cronjob, despite correctly configured, do not work... Maybe a bad server setting with my host provider ?

jdrichmond’s picture

jdrichmond commented

I believe that the version number comes from the Drupal code and not from the database. Not for sure on that, but it seems to be the case for modules.

I would suggest re-uploading the files for Drupal 6.14. All of your custom themes, modules, etc should be located in the sites folder so don't overwrite it.

yagraph’s picture

yagraph commented

Thanks for your quick reply too :)

I have already tried that, with sadly no success...

But you give me another idea : back update to Drupal 6.13, and then to Drupal 6.14... But is it safe ?

jdrichmond’s picture

jdrichmond commented

I would make sure that you have cleared the cache in your browser and in Drupal first. I wonder if it isn't hanging onto that value even though the changes were made. If that doesn't work then make another backup of your files and database and then give your idea a try.

rcrusoe’s picture

rcrusoe commented

a more general comment on doing the 'upgrade' from 6.13 to 6.14 -
caveat: my involvement with Drupal is through CiviCRM which is the primary application I'm working with as opposed to generic Drupal, and worse yet I've been away from it for a prolonged period and am in the midst of 're-entry' doing testing with the latest releases of both - hosted on Bluehost with the current correct versions of PHP and MySQl, etc.
That said, I was blown away by the progress made while I was 'away' and excited about how much everything had matured, wow, look at all the impressive sites running Drupal - sheesh, Bob Dylan and LedZeppelin for cripesakes. This is going to be a piece of cake.
Fresh install of Drupal 6.13, found an interesting theme and some other stuff, installed the latest 3.x beta of Civicrm, and was doing some tweaking. Getting ready to install a new beta release of CiviCRM and of course felt obliged to do the Drupal 6.14 update, since after all it's a security update really, or so I thought, and not a major rev change or anything.
Since my brain and dev environment and all had been pretty much erased in several Total Recall ops, I considered myself a good guinea pig pseudo-newbie and started out down the dusty road.
God forbid I would be a real newbie doing this on a production site. I know there must be someone out there with a quick and dirty way to do the upgrade, and found some stuff about doing it as a patch, but unless I'm missing something the Standard Method is a real joke in 2009 with software that is this far along in its life. Start by reading Update.txt - look at the revision date on the file for example. Then progress through the steps starting with things like back up your whole site, delete all the files in your drupal root, use a text editor to modify settings.php to change the permissions, etc etc and then by the way don't close your browser until you've finished step 10.
Done it in the past and got through it, but this time the site is completely broken. This is not an update, folks. If you needed to do a security update to Windoze and the directions started by telling you to back up your whole system, then delete all the files and directories in C:\Windows, reinstall your os and apps and then restore the backups of your data how loud would you laugh and howl? It could happen and does, of course, but we're better than that. This is called a wipe and clean install. For my test environment I've already wasted more time than it's worth and would normally just delete everything and do a clean install of 6.14. But what if I had a production site?
Please tell me I'm stupid and point me to the right way to do this without breaking a site.

Regards,
Howard Johnson

vm’s picture

vm commented

Those with a production site that is important to them, can, as I do, test the upgrade in a test environment. This gives one the ability to work through the issues without bringing their production site to a screeching halt. Back ups are always a best practice. Continuing down the path of the Microsoft analogy (Though I see a major difference here), it does do backups. It creates a restore point, so that if needed you can roll back the changes.

settings.php only has to be altered if settings.php changes. Most of the time this file goes unchanged. There are cases however where it does and in these cases obviously one would copy and paste the $db_url string to the new settings.php file.

There are some shortcuts that can be taken with regards to updating/upgradng within the same major version. I've posted my methods and reasoning in numerous threads such as this one.

Contrib modules add yet another layer of complexity, and another layer of risk with upgrades/updates.

There are only so many things that can be worked on at one time by those involved in developing core. It is simple economics. How best to satisfy unlimited wants and desires with limited resources.

rcrusoe’s picture

rcrusoe commented

Thanks for the additional information, I've found some useful information trying to get the site straightened out - guess that's what test sites are for, eh. Some additional thoughts in another thread here http://drupal.org/node/586800 including a 'lazy man's upgrade process' which I'll have to try out.
Thanks again.
Howard Johnson

azsinglguy’s picture

azsinglguy commented

I, too, had issues with the 6.13 upgrade to 6.14. Did everything right (I thought) but was continually met with the evil Security Update message. My issue was with the Block module. In my module list, it said 6.13 - so I uploaded the Block module again. Still: 6.13, even though the actual module info said 6.14. Check your System table to make sure everything is where it should be: I had originally FTP'd the Block module into the Aggregator module when doing the upgrade. Duh. Upgraded the correct Block module, deleted the one that didn't belong, ran update.php and all was well again. 99% of you are going, "What a jerk!" For the other 1%: you don't have to tell anyone you put a core module in the wrong place.