I don't know If i am missing something essential, but why do I have to re-upload all the files to upgrade from 5.1 to 5.2? Surely all files can't have changed?

Comments

ideveloper’s picture

I just updated all files and drupal still works fine.

Just make sure you don't replace the file sites/default/settings.php as this file contains your database settings.

tdimg’s picture

According to the update notes, you have to use the new settings.php - just make sure you copy your settings from your existing to your new.

But I agree with the thread starter, why not use the patch system for all changes, and not just for those that fix the critical security issues?

Jerimee’s picture

From 5.1 to 5.2, they just took out this piece of code (lines 139 - 150):

/**
 * We try to set the correct cookie domain. If you are experiencing problems
 * try commenting out the code below or specifying the cookie domain by hand.
 */
if (isset($_SERVER['HTTP_HOST'])) {
  $domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']);
  // Per RFC 2109, cookie domains must contain at least one dot other than the
  // first. For hosts such as 'localhost', we don't set a cookie domain.
  if (count(explode('.', $domain)) > 2) {
    ini_set('session.cookie_domain', $domain);
  }
}

Besides this, settings.php is exactly the same.

cog.rusty’s picture

That was moved into the code, I think, and a new variable $cookie_domain was added to setting.php.

tdimg’s picture

Well considering that this is about 50% of the processed php code of settings (i.e. not including all those comments), it changed quite a lot.

For a php novice/noob/etc. it's also just easier to copy his/her database settings from his old settings into the new than to spot the difference between the versions, especially with that amount of comments.

And just a reminder, I said it because the person I replied to said that you can just keep your old settings.php, which imho is misleading. But if that isn't a problem for you, then I will keep my mouth shut in the future and let others continue to spread "half truths" and such.

cog.rusty’s picture

You don't have to. You can upload only the files that have changed, no problem. It is just that for most people it takes less effort to upload the whole package, especially since you don't know from what version they are updating.

Boletus’s picture

But the thing is, how do I know which files have changed? Comparing dates aren't that user friendly.

When you upload the whole shebang, you still have to delete the install.php from the uploaded files. Right?

cog.rusty’s picture

You don't have to delete install.php, it is useful for adding sites to a multisite by accessing it from another URL. And if you visit it from the same URL it just tells you "site already installed". But you could rename it until you need it.

About getting the new files, the only easy and practical way I have found is getting CVS updates for the DRUPAL-5 branch using something like TortoiseCVS. Perhaps you can configure it to bring you the files with a DRUPAL-5-2 release tag created after a specified date.

JirkaRybka’s picture

The real trouble with updating comes, if you decided to custom-patch core modules. For instance, I needed to patch user.module, to get rid of a mail-error-detection bug, and change wording of some tabs to allow localization (always trouble, when English texts are identical on very different functions, making it impossible to localize differently).

On each new Drupal version, I'm now required to redo all the patches before proceeding to update.

But if I knew for sure that the file (user.module in my case) haven't changed, It'll be much easier for me, I'll be able to just use the already patched old file without further analysis.

cog.rusty’s picture

If this is about few files, using the CVS browser can be very handy. You can see when and how a file changed.See:

http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.module?v...

JirkaRybka’s picture

Thanks, this looks handy. I wasn't even aware that there's such a thing accessible for the public.