By worldsailor on

Background – I run a couple of multsite drupal installations – one is drupal 6 and the other is drupal 7. They are on different hosting providers. Both are on shared hosting. I’m fairly confident in my technical skills, but I’m not a PHP coder and this upgrade to 7.32 has me flummoxed.

  • Hosting provider restored drupal and DBs back to 10-1-14
  • As soon as primary site was restored (within 5 minutes) set maintenance mode on all 3 sites.
  • Backed up drupal installation and DBs
  • Followed steps in UPGRADE.txt as exactly as possible – ended up doing these steps several times to make sure I followed them exactly.
  • After uploading all the 7.32 core files, ran update.php – success completing 4 DB updates for my top level site.
  • Set maintenance mode off and logged user 1 off
  • Cannot log any user on
  • Restore DB from backup, still cannot log any user on
  • Delete 7.32 files and upload backup 7.31 files (DB restored in previous step) – everything just works.

I have backups of all files and DBs from before update and after update.

There has to be something simple that I’m missing. After 3 days I’m out of ideas.

At least I got a shower today, so I got that going for me, which is nice.

Can anyone provide some new insight?

⋅ Categories: Drupal 7.x

Comments

john_b’s picture

john_b commented

If you are running 7.31 you need to patch for the security issue urgently, as an interim measure. Changing one line of code is enough (Option 3 here).

The easy way to update is usually from command line with drush. I would highly encourage you to install drush on the server. Then it takes a few seconds to run an update: on a mutlisite installation, go to the site's folder (e.g. sites/example.com) and issue command drush up and sit back. Even if the update fails, at least you have only spent 10 seconds on the task!

It may be that some piece of code is missing: not sure how you are uploading files. Using drush automates the process and can avoid small human error.

Failed login usually points to a cookie problem. If you had replaced settings.php (which I assume you have not) I would be looking for something non-standard in your working or non-working settings.php such as a setting for $cookie_domain. When a cookie is set in the browser, a session is opened for that user in the sessions table of the database. By examining the cookies which are getting set on the working site (and probably not getting set on the non-working site) you can prove this to yourself.

If you feel willing to work from command line and install drush (and hosts who support Drupal properly have it installed already), I would try that path first before more major debugging.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

worldsailor’s picture

worldsailor commented

Thanks John_B,

Restored DBs and files (7.31) again from local backups - this time with option 3 patch pre-applied. This time I only restored my root site. Not that there is much difference in restore time. Just a few files in /sites and a couple of DB restores.

I will determine whether drush is available, but I don't think so - no access to file system beyond drupal root and no apparent command line tool.

I'm using Filezilla for up/downloads and maintaining a mirror file structure on my local machine. I just drag and drop from my local file structure to the hosting site or vice versa.

I've tried both modifying the settings.php files and not. It doesn't seem to matter.

Where is the cookie store on the server? Is it in the sessions table? Some other table in the DB? I clear cookies automatically on my browser.

Thanks again for the patch tip.

john_b’s picture

john_b commented

Cookies are in sessions table.

Every time cookies are cleared in your browsers you will of course be logged out of every site which uses cookies for authentication (most sites with login, including almost all Drupal sites).

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

worldsailor’s picture

worldsailor commented

Thanks for your assistance John_B. Turns out that the auto-clearing of cookies in my browser didn't get reconfigured after an upgrade a couple of months back. So what looked like update issues was really a PEBKAC problem.

Teach me to assume anything!

You were very helpful and too kind.

Many thanks,
w