Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By ianr on
I got the message today about 5.4 and 6.4, and my first thought was to upgrade immediately! (I run one site with 5.3, another (not critical one) with 6.3).
But then I read the update.txt, and thought - you've got to be joking.. Wipe all the files? Turn off all the contributed models? etc etc?
I'd expect that I MIGHT have to do that between a major release ie say from 6.x to 7.x, but surely not between something like a 5.x to 5.x+1! Surely the interfaces haven't changed, surely it's just bug fixes, and I can just copy the CHANGED modules over the top of the old ones? Surely I don't really need to back up configuration files, and .htaccess files, just to put some bug fixes in?
Yep, I know I'm new to drupral (and I like it a lot) and I know I have the expertise to follow the 'gut and replace' upgrade instructions, but I suspect a lot of people aren't, and that it shouldn't be that hard! I've never had that much work to do updating other web software!
And of course, if it is hard to do, less people will do it.. Which will leave plenty of drupral sites out there without security fixes...
Ian
[Title edited because the mis-spelling of Drupal was bugging me - Michelle]
Comments
Upgrades vs patches
No it isn't that hard.
You are reading the instructions for a Drupal 5 to Drupal 6 type upgrade. Yes, for just patching Drupal you just need to upload the changed file. If the patch involves a database change (it happens rarely), you will need to visit update.php to apply that. Those that can't tell from looking at the changes should just visit update.php anyway and it will tell them if there is a database update.
But ideally you would try it all out on a test site first. And the paranoid would still have backups etc.
Note that there will be much bigger changes between 6.0beta3 and 6.0beta4 - it isn't a security patch like 5.3 to 5.4 is, its ongoing development progress.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
then better instructions need to be in the upgrade.txt
I was reading the instructions in the upgrade.txt, so if that ISN'T what I need to do, the instructions need to be updated..
Looking at http://drupal.org/upgrade/downloading-drupal-gui - it is a bit simpler, but also wants everything to be removed, and then selectively copied back, with re installation of modules.
As per my post at the top, I don't think going from 5.x to 5.x+1 should require you to re do the whole site code base and re install modules! If so, drupral is not going to have a good future, as a lot of people aren't going to install an update if they have to re install every module, and then configure them all again...
I just did a compare of the 5.3 image to the 5.4 - 44 files were changed, 231 stayed the same. So the update instructions should have been copying those 44 files over the top of the old ones, and then possibly running update.php.. Which is what I'm about to try and do (after backing up of course).
That's what other software that I've use on a web server has done..
With 6.3 to 6.4, there are 148 files that have been changed or added, and 4 deleted. So with that one, with it being a beta etc, I can see the sense in killing the whole thing and starting again...
Not required to reinstall
Not required to reinstall modules. I just copy back the whole folder "sites" to replace. Inside this "sites" folder, I have my modules, themes and my settings.php file.
It's certainly not reasonably convenient now.
No it isn't that hard.
I suppose that depends on how you classify "hard" and who you're talking about. The OP had a valid point that instructions for upgrading are very "heavy" for upgrades within a major release. Your dismissal of that point doesn't change the facts behind it.
You are reading the instructions for a Drupal 5 to Drupal 6 type upgrade. Yes, for just patching Drupal you just need to upload the changed file. If the patch involves a database change (it happens rarely), you will need to visit update.php to apply that.
Where are there instructions for this? What tools are available to find the changed files? Is this something that a busy sys admin can do with little effort, or is it something that is going to be time-consuming and error-prone? "Hard" does not necessarily mean "too hard for my skill set" -- it can also mean "too hard to find time to sort out, given my already-overburdened schedule." And, as the OP pointed out, that will lead to Drupal installations being left at earlier versions with security problems. If your answer is to use platform-specific file comparison tools, without any guidance specific to Drupal, then the process to keep a Drupal installation secure definitely needs to be "easier" for those who want to use Drupal but do not have excessive amounts of time to spend on Drupal maintenance.
Maintenance is acceptable and necessary; excessive maintenance in any system or product will cause it to be abandoned by general users, leaving it a niche item for enthusiasts only.
documented and supported best practices
The detailed documented method is (I presume) the way it is to provide a very conservative process that is guaranteed to work. Each step may or may not be needed for every site, but chances are that every step is needed by at least a small percentage of sites.
I don't know why there isn't more of a documentation distinction made between full version upgrades and minor version updates. I have to admit that I haven't looked at them for a few years now, and they were much simpler back then. But I can see that they are far safer now and more thorough.
I suppose the Drupal development and documentation teams don't want the other extreme where they try and explain what is and what isn't required under every possible different circumstance, and then having some subset of less experienced users getting into trouble because they have a slightly different environment, or misread what was and wasn't necessary, or the docs didn't manage to account for every possible situation. I also suppose they don't want the hassle of maintaining that kind extensive documentation.
Personally I find that all I ever need to do is replace files, and run update.php. Even on the full version upgrades that works for me, although sometimes I need to run upgrade.php a couple of times to catch all the contrib module updates. After all a Drupal site is just some PHP files and a database. Those are the only two steps in the upgrade that actually do anything - all the others are just there to minimise the possibility of anything going wrong.
But I'm not going to recommend going against the instructions for someone who doesn't know what is going on.
This is why I have a test site, and why everyone that cares enough about their site should have one too. I can confirm whether or not my upgrade method is going to work on my environment first. As you get more experience you'll get a feel for which bits aren't needed by your site.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
And has to be easer..
jppi_Stu summed it up very well, and understood exactly what I meant in the initial post.
It's all right for someone to say 'have a test site, and try it first' but nobody under a lot of time pressure is 1) going to have a test site to match every site they might be managing and 2) have time to test each site, and then do the upgrade.
The upgrade process, within a release - ie 5.3 to 5.4 - should only consist of three steps for 99% of sites (that have not changed any of the core coding).
It should be -
1) upload the update file to the root directory of the drupral installation
2) run /do_upgrade.php
3) check that it still works OK.
That's how easily I used to upgrade a php board I use to run, and it worked every time even when I HAD modified part of the core code, as it implemented the whole upgrade as patch files.
Until drupral is that easy, it's going to be a battle to get people to keep their sites up to date. And I do know, because as as much as I want to upgrade to 5.4 for my main site, I simply haven't had time this week to follow those detailed instructions to do it, not to mention my worry about the add in modules I use. And I don't have time to write a utility to do it properly either..! Maybe next week...
Ian
updates
If you're ignoring best practices by not having a test site, then why would you feel the need to follow best practices for updates? If you don't care enough about the sites to take that risk, why not just upload the files and see what happens? It's FAR less risky than uploading a new contrib module without testing it.
If you look at this page: http://drupal.org/upgrade/tutorial-introduction, there are three similar steps listed as well:
But you are comparing apples and oranges here. That process you described has none of the safeguards etc that the detailed Drupal instructions have - it is effectively just the one or two actual action steps in the Drupal process ie uploading files and (optionally) updating the database. Those steps are basically what you can usually get away with on Drupal.
The problems I see with what your "ideal" process:
a) It requires an insecure site configuration. The webserver and PHP account on the server will need write access to your codebase to patch the files. Drupal core devs are understandably not keen on solutions like that.
b) What happens with patch conflicts? eg if you've edited some of the same lines that the update changes.
But feel free to post a feature request for it - someone might be able to implement something that overcomes those issues. But nothing will happen from a forum post.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
not quite what I meant
I'm not disagreeing that the full major version upgrade process in the latest docs is an onerous process just for regular security patches. I wasn't dismissing that point at all. My point was that with some practice and/or testing it doesn't have to be that hard, you will get a feel for which steps your site requires or not. It can be just as simple as a single step of replacing the files for a minor update.
Most of the steps aren't required for most sites (even on the full upgrades), but each step is there to prevent a potential problem that has hit someone before. The documentation understandably takes the conservative foolproof approach. You should only sidestep them once you've practiced and/or tested it a few times and know what each step is for.
I agree a different set of docs for just security updates would be preferable - although I don't know whether the people in charge of that agree. But if they were patch specific instructions would probably need to be rewritten somewhat for each release. I'm sure volunteers for that would be welcome.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
Managing Multiple Upgrades
I didn't realize this topic had been posted in General Discussion. Earlier this morning I posted a similar topic in the "Post Installation" section. I'll copy/paste what I put there:
My question is in regards to best practices and suggestions for managing multiple Drupal sites. I have found myself in a position where I have half a dozen or more drupal sites that I administer. When new updates come out, such as the recent 5.4 and 5.5 updates, I have to go through the process of putting each site into maintenance mode, backing up files and database, disabling non-core modules, reverting to default theme, copying the new files over, running update.php, re-enable custom theme, re-enable non-core modules, and finally return the site to online mode.
While this might not be much of an issue for one or two sites, it gets to be quite time-consuming and tedious as you have more sites to maintain. Am I missing out on some uber-geek method of site maintenance, or is this process an inherent requirement every time an update comes out? I have been trying to learn more about CVS and integrating it (via Eclipse) into my work-flow, but I'm not sure this even the right place to look. Can CVS be used to automatically roll out updates to all of my sites from a centralized location, or am I misunderstanding the purpose of it?
I have many questions and uncertainties when it comes to streamlining the maintenance work-flow. If CVS is not a solution to this, is there anything else that I can do to make the process easier/quicker? How necessary is it to disable non-core modules and revert to the original theme? If I left out these steps, would I open my sites up to corruption during updates? It can be quite a pain to go through your list of modules and make note of which ones you have active and which you don't.
I have been trying to learn more about Eclipse and how I can utilize it in my work-flow, but I am not really a coder, so I'm not positive I even need it.
I typically use a test site and database for developing new features, and then manually copy over the files, export the test database and then re-import it to the live database. Perhaps I am being too optimistic, but I feel like I am missing something in streamlining my work-flow.
Any suggestions/ideas/comments would be greatly appreciated.
Matthew Kivett | SpiraStudios.com
I agree
I agree with your comments, and I am going to be in the same position as you, as I've now got 3 drupral sites, it will be 4 by tomorrow, and probably 10 by the end of the month.. And I can't run common code, as they are all on different servers..
And boy am I lucky that I didn't get time to upgrade from 5.3 to 5.4, now that 5.5 is out!
Version 6.3 is sort of a tiny step in the right direction - the "available updates" screen shows -
Drupal core
Update available
Drupal 6.0-beta3
Recommended version: 6.0-beta4 (2007-Dec-06)
- Download
- Release notes
Includes: Block, Color, Comment, Contact, Database logging, Filter, Forum, Garland, Help, Menu, Node, PHP filter, Poll, Search, System, Taxonomy, Update status, User
And it allows you to check for updates on a daily/weekly basis and for everything or just security updates.
This is the right way to go, but it then only offers the option to download the whole release to your local (ie not the server) and you're back to reinstalling everything again..
Maybe it is intended that the final 6.1 release will have the rest of the functionality - does anyone know? I'll do a bit of searching and find out...
If not, I suspect I'm going to have to write a hack (ie not integrated with drupral) over xmas to do it...
Ian
update status
That Drupal 6 core feature started off as a contrib module in Drupal 5: http://drupal.org/project/update_status
That's because of the security ramifications of letting the web app overwrite itself. On a shared server that could potentially let other users overwrite your files too.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
nope
nope, you just put the update code, and new install stuff, in a password protected directory.
And?
The account the webserver runs under (ie the account that runs the PHP code on the server) will still need write permissions enabled on all your PHP files. That would mean your files need to be world writable on some commonly configured shared hosting configurations. It has nothing to do with how the PHP run be accessed from the internet.
It may not be as much of a problem on a dedicated server though. Although I'd still prefer any updates to my sites codebase to be done "out of band" as it were.
Or if you set all the write permissions beforehand, then unset them again afterwards - isn't that defeating the purpose?
Don't think that some core developers haven't been thinking through all this, and trying to come up with a secure (enough for them) way to do stuff like this.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
then how do all the other systems do it?
Then how do all the other systems do it? Or do they all have a 'security' hole?
YES
YES
If the apache process is given write permissions to your core files, then anyone else hosting a site on the same system has write access to your core files. And user data. And security configurations.
U C ?
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Nope. I can log onto a
Nope.
I can log onto a control panel - with a user id and password - and do anything to the site, include change the permissions etc.
The web page I'm doing that through is running from apache - but the system knows it is ME, not someone else, because of my username and password... Thus lets me change files that have permissions set to 644, or 755 - ie ones that only the 'user' has access to.
It's exactly the same (on my isp, which is a shared service) with running a web page from php - ie dupral. Drupral itself is running as 'me' not 'apache', and thus can do anything that I could do if I used telnet to log in. It's part of the reason you NEVER let users submit php, as it is running as you!
It has to be this way - as php needs to be able to read/write files etc, and you could never do that if you had to open up your file system to everything running under 'apache'.
So it runs as 'me' and only has access to things I could do - ie it has no special 'apache' ability to look into other people directories etc..
So an inbuilt upgrade facility would be the same (like a script to do what I did at the bottom of this post). IT would have access to my files, even if they still had 755 etc attributes.
For these reason, it would have to be well written - ie the patch file going into it would have to be checked to make sure it was ONLY changing drupral files etc. One of the ways to do this would be to put almost ALL the drupral files in a sub directory - a good idea anyway, and subject to a number of posts in this forum - accept for maybe two files - index.php and .htaccess. In fact, that is such a good idea I think we should be pushing for that independent from the patching process..
Ian
Not everyone has suid
OK, so your ISP is running your hosting under 'SUID' privileges - which is fine and good, is a slightly more privileged setting, but not all hosts choose to do that. It's just one of that many configurations possible.
In most of the commercial hosts and default Apache installs I've seen, running
returns 'www-data' or 'nobody', not 'username'.
on a drupal site shows something similar.
... because my hosts haven't chosen to use suid.
PHP needs to read files, yes, but that doesn't mean it should be able to write to all of them. We have permissions to handle that.
That's why we put all writable files in the 'files' directory and open up permissions there, while leaving the core code locked down.
Your web control panel is a special case, and probably uses a version of root-suid or cgi-wrap, or maybe even sticky-bit scripts, as many of the functions there are (as you found) privileged actions, some of which require modifying files that your handmade web server code itself (or your telnet session) shouldn't be allowed to. DNS registrations for example.
It's authentication is (probably) taken care of by the ISPs code, and although it lets you do extra things, may not actually be assuming your identity to do it, it's just acting on your behalf.
There's a chance that there is an admin control panel out there that actually tries to su at the system level like you say it does, but it sounds really dodgy.
With the distinction between 'me' and 'my webserver daemon' made at the system level, my site is protecting me from a lot of exploits, and my own bad code. Without those two identities co-operating, it's almost the equivalent of logging in as 'root' to do day-to-day work on your box. Better that you let the daemon run in a sandbox of sorts, where there's less chance it can hurt everything.
I actually like doing remote installs, I've got a fetch-cvs module that does so that I use on my dev sites, but there's no way I could put it on a shared host, or recommend it to anyone who doesn't know their security issues.
Really, The devs have considered this, and shot it down with good reason several times before now.
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
ok
Sorry about the mis-spelling, I've been doing it a bit!
OK, we can agree to disagree on that, as I think that running php as 'my webserver daemon' is more dangerous than running as 'me' - in a shared environment. In a dedicated one I agree with you totally, as then when you gave permissions to 'my webserver daemon' it would only give them to your programs, and would protect you from the code doing things with the user privilege.
However, in a shared environment I'm much more worried about what everyone else is running, and can (reasonably) control what I am. So I wouldn't to give 'my webserver daemon' permission to do much at all. Ideally you could then do the security for 'me-webserver' but given that doesn't seem to be implemented, I think 'me' is the only alternative.
I've just checked every ISP I have access to - which is a few as I support (for free) a number of not-for-profit companies - and every one of them is "hosting under 'SUID' privileges".
So 'the devs' need to consider that MANY drupal installs out there are probably already running on sites that allow drupal to modify itself, and that there is no way of stopping this (as it has the ability to change permissions as well).
As for remote installs and fetch-cvs, that comes down to (the often argued in this forum) view of who drupal is for - techies who want to use drupal as a CMS construction kit, or 'end users' who want to use it as a CMS in it's own right. IF drupal wants to support the second group (I'm sort of in both groups) then 'remote installs and fetch-cvs' aren't going to be good enough. Neither is the upgrade process that started this post.
Ian
Yup
You are quite right that the shared daemon approach also has some weaknesses - which this issue is therefore paranoid about.
The whole idea of suid daemons was brought in to provide one solution to that, so you've got some useful hosting there. I've only seen it on one commercial host, but I guess it all depends on where you shop.
I have also once-upon-a-time seen a 'me' and 'my-webserver' uid setup (two users for every account) which seems to be an incredibly robust approach to the whole issue, even though it could be a pain to administer. Certainly makes some sense.
Some folk are just plain scared of the idea of self-modifying code. OK. I actually think it's fun. Frankly, I think that with so much of the power of Drupal actually resting in the database, worrying this much about your file security is a bit over-anxious.
But it does pay to play through all the concerns and scenarios when thinking of doing something like this. If someone wants to build a contrib module with a big red warning flag on it saying "This may allow your site to be compromised ... but will make upgrading easier" ... they can go ahead for all I care.
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
I'm going to do it
I have also once-upon-a-time seen a 'me' and 'my-webserver' uid setup (two users for every account) which seems to be an incredibly robust approach to the whole issue, even though it could be a pain to administer. Certainly makes some sense.
Yep, a great idea, but due to 'externality' ie the person who has to do the work isn't the person who gets the benefit, and the person who gets the benefit can't do the work, I suspect it doesn't happen too often..
Some folk are just plain scared of the idea of self-modifying code. OK. I actually think it's fun. Frankly, I think that with so much of the power of Drupal actually resting in the database, worrying this much about your file security is a bit over-anxious.
I agree with you - and it's silly to be more worried about file security more than DB security, and passed a certain point it is silly to worry too much about either - you HAVE to assume that someone is going to hack your code, or kill your DB, at any time. Doesn't even matter if your on a machine not even connected to the internet. That's what backups are for, particularly off site backups. Which are so easy to do in these internet days!
But it does pay to play through all the concerns and scenarios when thinking of doing something like this. If someone wants to build a contrib module with a big red warning flag on it saying "This may allow your site to be compromised ... but will make upgrading easier" ... they can go ahead for all I care.
I probably will, it might be a good first contrib module for me to do, and the actual code to do it (see the end of this post) is trivial. It's the safety checks and integration with drupal that will be the work. I know, most people do a 'hello world' first in a new environment, but I'm probably going to do a system upgrading module.. :-)
cvs
CVS isn't for rolling anything out, but it can be a big help in merging updates into your codebase. For professionals like yourself I would recommend using some sort of source control to keep track of your code - eg we use CVS to get updates from drupal.org and then commit them to our own subversion repository. Then we can deploy your sites with shell scripts. I won't go too much further though, it's a big topic and there's been plenty written about it already (you should be able to search for some of it).
But you have fallen into the trap (dare I say it) of running the detailed and conservative full version upgrade procedures for simple patch updates that have no API changes (note: if anyone else feels like griping about the instructions - save it for the documentation team not me).
A lot of those steps are to protect you from the API changes in a full version upgrade. eg moving to a core theme means you can still operate the site if you old theme isn't compatible, also disabling contrib modules also stops an incompatible module breaking your site, maintenance mode is to stop users adding content etc halfway through your update.php process (which usually isn't needed for patches anyway) etc etc. And even for a full upgrade your test site should tell you whether or not your themes/modules are compatible with the new version, so you might not even need those steps then either.
Seeing as though you already have a test site, I think you should try out what happens when you just upload the new files. You should try breaking things by messing with the process to get a better idea of it. With that experience, you will instinctively be able to tell just what is needed for future updates.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
I update without problem
I followed below link instruction and update from 5.3 to 5.4 without problem.
http://drupal.org/upgrade/downloading-drupal-gui
Inside the downloaded package, the file UPGRADE.txt is giving different instruction. It is little bit harder. I am doubt why the file date is 9-Jan-07. If this is old file, why not remove it from core?
Disclaimer: I am new to
Disclaimer: I am new to Drupal too, just reporting what I have gotten as concepts so far.
You'll notice how most other software run in a "backwards compatibility" strategy aimed at making updates and compatibility to old modules the easiest possible. This at the price of carrying over old stuff along with the new core. This often results in carrying over old bugs and security holes too, and a "legacy" weight that goes on the shoulders of the developers.
Drupal clearly states they don't follow this established way but refactor code and everything for new releases without legacy remains, they provide upgrade scripts but not "backward compatibility". This has the effect of forcing people into a more "hardcore" approach but has the effect to give maximum freedom in updates (nothing has to be guarded against "breaking what worked") and technology.
Drupal is not Xoops or PHPNuke, for what I can see, Drupal is an exercise in architectural software "perfection" first, a CMS then.
yes, but..
Yes, but that approach shouldn't be WITHIN releases ie 5.3 to 5.4...
Ian
I honestly... think it is not that difficult.
I appreciate immediate security releases, even if I get one every day. All you got to do is lose your "site once" to hacker, then you'll like fast security releases even if it requires some work to apply.
There are several CMS that have server side installers. THey also create permissions problems with your folders and files that can make you cukoo.
I like to unzip the files and do manual installs for everything. This way when I FTP my stuff to server my folders and files don't have different permissions than those I used in FTP.
How I do it
First off a big red flashing disclaimer that this works for me but certainly isn't the safe way and I make no guarantees.
mysqldump -uUSERNAME -pPASSWORD DATABASE > BACKUPFILENAME
log in as uid 1
set the site offline
wget
tar -zxvf
mv drupalfolder drupalfolderbkup
mv drupalfolder
cp -R drupalfolderbkup/sites drupalfolderbkup/files drupalfolder/
run update.php
set the site back online
I don't turn off contribs and don't change my theme. I've got a backup of the database and a backup of the folder to recover from if something goes drastically wrong but, so far, nothing has. I did 5 sites today and no issues.
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
yep, that's one approach
Yep, that's one of the approaches I was thinking of - with the missing code (that the comment engine has probably stripped out!) in!
The other approach was I'd make an update directory, and put every INSTALL version under it ie a 5.3 dir, and a 5.4 dir. Then I'd generate patch files for the differences, then run the patch files against the live site. Thus if anything in the live site had been changed I wouldn't be overwriting the whole file...
It's interesting the drupal has a solid patch process for development ie see http://drupal.org/patch, but then only has a complete install as an upgrade process...
Ian
youch
That sounds like a lot of ongoing work to just reinvent a subset of CVS. see: http://drupal.org/node/93966 and http://drupal.org/node/5123
Or for a local repo you could use subversion instead, and just use CVS checkouts from drupal.org to bring in the updates to your svn working copies.
I've previously described one over engineered way to use svn repos here:
http://drupal.org/node/118936
We have since simplified the repo layout, but we still develop themes and module in separate directories and bring them in via svn:externals. But you don't need to go that far, and just start off with a simple workflow that can evolve over time.
If you are going to be managing/developing 10 or more sites, I really don't think you can ignore source control and scripted deployments for much longer.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
and looking at the problems upgrading
And looking at the problems of people upgrading ie http://drupal.org/forum/21 I think I'll be hanging off for a bit anyway. It also demonstrates the problems with the upgrade process (the issues are divided between upgrade PROCESS problems, and problems with the upgraded source itself..).
Ian
OK, I updated 5.3 to 5.5 in less than 60 seconds each..
OK, upgraded my 5.3 site to 5.5 in the last few minutes. The whole process took less than 4 minutes for 4 sites..
Only do this what I did -
1) ignored the upgrade instructions included in the 5.5 download, as they are ridiculous for this upgrade.
2) put a clean copy of 5.3 in a directory, and a clean copy of 5.5 in another
3) ran "diff -urp drupal-5.3 drupal-5.5 > patch_v5.3-v5.5"
4) had a quick look at the patch file - nothing in it looked very dramatic..
5) copied the patch file to the root directory of my drupal install
6) ran "patch -p1 -u < patch_v5.3-v5.5"
7) test site - yep, everything working fine..
8) repeat (5) - (7) for each of my sites.
And you don't even need shell access to do this, as long as your ISP isn't running php in safe mode you can simply pass the commands from php ie
I'd upload the patch file I used, but I can't see where I can upload files on this site...
Writing this post took longer than actually doing it..
Ian
It only took me 3 days..
Your original point is well taken. I have been working with Drupal for 10 days, and I spent the last 3 trying to upgrade from 5.3 to 5.5. I just got it to work on my test site on my development machine. The notice on the Drupal home page links to the detailed upgrade instruction set. You get the sense that these instructions are meant for a full version upgrade, but I haven't seen anything that hints that the process is overkill for a .x upgrade. Since I picked up on the instructions from the homepage link, I didn't even think to look for instructions in the package, or that they would be any different.
Since the process is so lengthy, and for me unfamiliar, I decided to keep notes. Going back over the notes, I find that the instructions contain some ambiguities and omissions that led me down blind alleys and took a lot of time to sort out. This is tough, because as a noob I have to rely a lot on blind faith rather than understanding. I'm thankful that the site I am working on isn't live yet and I have the time to work it through.
instead
instead of the minute or so it should have taken you if there had been a patch file and proper instructions...
And this was what was patched
patching file CHANGELOG.txt
patching file includes/bootstrap.inc
patching file includes/database.inc
patching file includes/database.mysql.inc
patching file includes/database.mysqli.inc
patching file includes/database.pgsql.inc
patching file includes/form.inc
patching file install.php
patching file modules/aggregator/aggregator.info
patching file modules/block/block.info
patching file modules/blog/blog.info
patching file modules/blogapi/blogapi.info
patching file modules/book/book.info
patching file modules/color/color.info
patching file modules/color/color.module
patching file modules/comment/comment.info
patching file modules/comment/comment.module
patching file modules/contact/contact.info
patching file modules/drupal/drupal.info
patching file modules/filter/filter.info
patching file modules/forum/forum.info
patching file modules/help/help.info
patching file modules/legacy/legacy.info
patching file modules/legacy/legacy.module
patching file modules/locale/locale.info
patching file modules/menu/menu.info
patching file modules/node/node.info
patching file modules/path/path.info
patching file modules/ping/ping.info
patching file modules/poll/poll.info
patching file modules/profile/profile.info
patching file modules/search/search.info
patching file modules/statistics/statistics.info
patching file modules/system/system.info
patching file modules/system/system.install
patching file modules/system/system.module
patching file modules/taxonomy/taxonomy.info
patching file modules/taxonomy/taxonomy.module
patching file modules/throttle/throttle.info
patching file modules/tracker/tracker.info
patching file modules/upload/upload.info
patching file modules/user/user.info
patching file modules/user/user.module
patching file modules/watchdog/watchdog.info
and now for 5.6
Looks like I'm about to do the same for 5.6... I still don't see why a patch file can't be supplied to do an update with...
Ian
It appears there may be patch files
On the update announcement page, http://drupal.org/drupal-5.6 ,
at the bottom of the "Security vulnerabilities section", some patches are referenced. I have no idea how one would make use of them, as there don't seem to be any instructions for non-programmers.
Randy
If you don't understand the implications
of patching and why you'd want to use a patch instead of just overwriting the files, I wouldn't recommend patching.
By applying the patches for the security issues, you haven't actually updated to 5.6 (5.6 also includes other bug fixes). You've forked your codebase into a custom combination of an earlier version plus some patches. The more you just apply the security patches the further you diverge from an official version and the higher the risk you have that future patches won't apply.
The patches are intended for experienced developers who are working on customised codebases and need a way to (quickly and temporarily) fix a specific security issue with the least amount of code changes which buys them some time to properly integrate their custom changes into the codebase of the official release.
But if you want the patching instructions anyway, see: http://drupal.org/patch
For those wanting a complete 5.5 to 5.6 patch and technically proficient enough to use a patch - you'd be better off using CVS to update: http://drupal.org/node/93966
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal