I set up my Drupal site on 1/23/09, so when I started getting dire warnings about an urgent security upgrade a month later, I was both annoyed and concerned. Annoyed at having to do what seemed like a total re-install when I'd just gotten my new site customized the way I wanted it, and concerned about the potential to totally screw up my site in the upgrade process.

Most of the info I found here about how to streamline the process requires the site admin to write scripts or run them, and this won't work for me since I don't know anything about Linux commands and don't have easy access to run scripts against my server anyway.

Furthermore, while I've always been a stickler for maintaining a separate development environment when building or maintaining programs or web applications, with Drupal it seems like more trouble than it's worth since the 'bones' of the site don't tend to change much once you're done installing and customizing your site. All the content of the site (i.e., articles, forum posts, member profile data, etc.) is stored in the site database, and I don't feel I need a 'development' copy of the database because its structure rarely changes, too. I backup regularly, but that's about it.

Well, I found a way we Linux/php-illiterate, no-developer-sandbox people can complete the 6.9 - 6.10 upgrade with minimal site impact and no need to do the complete uninstall/re-install described in the upgrade.txt instruction file. If you're like me---no Linux or php background, dreading the prospect of uninstalling and reinstalling your entire site, no local 'development sandbox'---I think you'll find my procedure will make your upgrade much easier and less nerve-wracking.

I've documented my process in an article on my drupal site, here.

Comments

dnewkerk’s picture

Hi April -

Could you be specific regarding the parts of the upgrade guide that were frightening to you, or that you felt required knowledge/understanding of Linux or PHP?
If anything it sounds (correct me if I'm mistaken) as if you were nervous about removing Drupal's core files and directories and replacing them with the new copy... however (as you mentioned you did follow best practices, backing up before any upgrade, not hacking core, and keeping all your data - files, modules, and themes - within the confines of the /sites directory) doing this is completely safe and completely normal. If you've followed best practices, then you can do this without any consideration... besides your own /sites directory (and the .htaccess and robots.txt files if you happened to edit them), a copy of Drupal core is completely separate and can be freely replaced with another copy, upgraded copy, etc.

You mentioned that it took you about a half hour to upgrade, though if you follow the upgrade.txt, I think it ought to only take 5 minutes or less (less if you use fancier tools such as shell or even the cPanel file manager... 5 minutes or more if you use just FTP, since it just takes longer for FTP to upload files). Personally it takes me about 1-2 minutes to upgrade a site.

Supposing the use of just FTP, here's a workflow I'd suggest:

  1. Ensure you are logged in as User 1, and put your site offline.
  2. Backup everything (files and database).
  3. I personally never do this, but "technically" you should disable contrib modules. In 2 1/2 years this has never been required in my experience.
  4. Make a temporary folder (e.g. "backup") and drag and drop 100% of everything into it.
  5. Upload the new copy of Drupal in place of the old one.
  6. Replace the default /sites directory with your backed up copy, and if you have modified .htaccess or robots.txt put your copies back in place as well.
  7. Run update.php.
  8. After testing to make sure it worked, delete the extra temporary backup copy (which now contains nothing but the previous copy of Drupal core files).
  9. Put your site back into online mode.

The time "offline" with the above is only limited to the speed of your upload of Drupal's core files. If you instead used cPanel file manager to extract the tar.gz file in place, you could save several minutes (or if you're comfortable with copy/pasting a basic shell command to extract a file, that's a fast way too... as not everyone has cPanel of course). If the time FTP takes is ok with you though, then that's perfectly fine, no need for more fancy methods.

I just had a look, and this appears to be a good guide too http://drupal.org/upgrade/downloading-drupal-gui

I'll tell you one thing I believe is part of the confusion/problem though... I think the upgrade documentation does not clearly separate 2 completely different upgrade scenarios: 1) A minor version upgrade and 2) A major version upgrade (e.g. 5.x to 6.x). I will take a closer look myself as soon as possible and see if I can bring some clarity to the docs in this regard.

publetariat’s picture

Keyz -
You're exactly right, the upgrade instructions do not distinguish between a minor upgrade and a major one.

I tried searching for streamlined approaches to the 6.9 - 6.10 migration here and elsewhere online, but they all seemed to involve creating and/or running scripts or patches. Not all of us have the expertise, software or server rights to write or run the necessary scripts.

Also, I saw numerous posts from people who followed upgrade.txt to a tee and still ended up having problems. Granted, in most cases those problems were probably the result of prior mods those users made to their core install, but since I'm new to drupal I couldn't tell by reading the messages what the root problems might be. As a Linux/php virgin (I'm a VB, ASP, Javascript, HTML type), I know I don't have the debugging skills I'd need if changes introduced by the upgrade "broke" my site.

Given the upgrade.txt instructions, it looked like the only recommended upgrade path for people like me (no Linux/php scripting skills or rights) was a complete uninstall of 6.9, followed by a completely new install of 6.10, followed by having to re-configure everything I'd set up in my 6.9 install. That kind of brute force approach to upgrading always makes me nervous, especially when I don't feel competent to address any post-install issues. I wanted to take a minimally invasive, low-risk approach to the upgrade.

The thought of totally stripping my server of 6.9, a stable install with which I'd had no problems or complaints following my initial configuration, and replacing it with the great unknown of 6.10 in its entirety, just gave me the software engineer heebie-jeebies.

Let me ask you this: given that every upgrade only affects *some* of the core installation files, why not release a minimal upgrade package that only contains the changed files, a txt listing of the files in the package, and instructions to back up current versions of the affected files + db and then unpack and ftp the minimal upgrade package (answering 'yes' when prompted to replace current versions)? That would essentially duplicate and automate the process I followed.

If 6.10 didn't contain critical security updates, I wouldn't have gone through with the upgrade at all. If you've already got a stable install that meets your needs and the upgrade path appears hassle-filled and risky, it's hard to justify going through with it.

dnewkerk’s picture

On my phone so can't reply in full detail yet. From what you wrote it sounds like you were assuming that you would have to uninstall Drupal... this would never be the case in any circumstance - all that makes Drupal "your site" is 1) in your database and 2) in your /sites directory. The rest of Drupal is a generic copy of the core files. Given a copy of your database and your sites directory, any copy of Drupal core (same or newer version as of the time of the database backup) is all you need.

mcfilms’s picture

I'm with publetariat on this.

I do not enjoy seeing a dramatic security warning every time I administer my Drupal site. But I am also concerned about what problems the security upgrade may bring. I don't have the Linux/php skills even though I do have Cpanel access. I don't want to see any modules that are working suddenly go south. So I sit on the sidelines and wait for the time when I have a couple day's worth of cushion to troubleshoot things if they go south.

Basically my modules and my custom tpl.php files work in 6.9 and I'm not 100% certain they will in 6.10

[bauk-bauk-bauk]

A list of some of the Drupal sites I have designed and/or developed can be viewed at motioncity.com

dnewkerk’s picture

Still on phone. In my 2.5 years with Drupal, never even once has upgrading a minor core version broken or even had the slightest effect on any of my installed contrib modules or themes. It's extremely unlikely. Upgrades to the contrib modules themselves are more likely to cause issues (nothing though compared to the issues you may have if you ignore a security update).

publetariat’s picture

Keyz -
YOU may know, based on a great deal of experience, how rare it is for something to go wrong following a core upgrade, but people who are new to drupal and looking at all the messages here saying this or that on their site is "broken" or inaccessible following an upgrade are leery.

Also, you say it's never necessary to uninstall during an upgrade, but that's exactly what the instructions in upgrade.txt tell us to do: take your site offline, backup everything, make a note of your contributed module settings, disable contributed modules, uninstall current version by deleting all core install files, install the new core, re-enable your contributed modules, test, and finally, put the site back online.

I know the content of my site is stored in my db, and the db is not uninstalled and reinstalled as part of the upgrade process. However, I also know there are hooks and calls to the db in the core software. So whether the db content itself is going to change or not, the way the core software accesses that content has the potential to change if we're forced to uninstall our current (working and stable) install of the core and replace it with a completely new install. Having been a relational db admin for 15+ years in my former career, I know all too well that when db data in an app is incorrect or inaccessible it's almost always due to a coding/call problem in the software.

Since I didn't write the software myself and don't have the expertise to understand the code by reading through it, upgrade.txt requires me to take drupal's word for it that nothing in 6.10 will break or alter my site. Given that I'm new to drupal, that 6.9 turned out to have a serious security problem, that there are numerous posts here and elsewhere from people who have had problems with the upgrade, and NO software is ever totally bug-free (it's just a question of how serious or noticeable the bugs are), I'm not willing to be that trusting. I mean, if my site breaks it's ME who's on the hook for it as far as my audience is concerned, not drupal.

Given the circumstances, I opted to go with a much more controlled, low-impact upgrade path. And judging by how many hits my article about my upgrade process has received since I posted it yesterday, I think an awful lot of other drupal users want and need the same thing.

Don't get me wrong, by and large I'm very, very happy with drupal. I recommend it in my book, From Concept to Community (obligatory plug - now available at Amazon in trade paperback and Kindle editions, and Kindle edition currently 45% off!), in which I explain how using drupal allowed me to go from a concept for a site to a working beta site in a matter of days. My site went viral within a week of is launch, and in the book I also talk about how the community features in my CMS were critical to retaining site visitors and keeping that early momentum going. As I said before, I have many years of programmer/db admin/web developer experience, and I can honestly say drupal is a fantastic software suite. I was willing to pay for a quality CMS, but after doing my requirements analysis and software comparison, I chose drupal over ExpressionEngine and other pay-to-play options.

So, Keyz and other drupal developers - don't take this constructive criticism of the upgrade process as a criticism of the software itself. I wrote up my process and posted it online in an effort to do my teeny tiny part to give something back to the drupal developer and user community, it wasn't intended as a slam against drupal or its developers.

VM’s picture

Deleting core files while not necesssary is a best practice. to ensure that all the new files are indeed uploaded.

Drupal release notes also tend to describe exactly what has changed.

Lastly for the really leery, you can do a compare on all the files and copy and paste the changes if one wanted. Matter of fact, I thnk the relase notes also give ability to simply patch the install.

I tend to separate minor updates versus major upgrades.

updates = one minor version to one minor version in the same major ie: Drupal 6.9 to Drupal 6.10
upgrade = one major to one major ie: Durpal 5.x to Drupal 6.x which is what the upgrade.txt file is centered around with regards to its writing. As going from one major to one major contrib modules should be shut off because they will need to be upgraded as well to the next major.

publetariat’s picture

RE: patch vs. upgrade, I absolutely would've preferred to run a patch than do a full upgrade. But as I stated in my original post, I don't have the Linux/php scripting knowledge or shell access needed to run patches, and I assume many other drupal users are in the same boat.

The compare, copy + paste method is essentially what I did, though with a few more preparatory steps (i.e., backups, screen prints of my file directories, etc.).

You and others here say you 'tend to separate minor updates versus major upgrades,' but upgrade.txt does not provide any kind of simplified instructions for a minor update. It gives one, total-uninstall-followed-by-total-reinstall set of instructions for all upgrades, regardless of current version. I realize it would be unreasonable to expect a custom set of instructions for upgrading every prior version of drupal that ever existed, but a simplified update process for those going from 6.9 - 6.10 would be nice to have. That's all I'm sayin'... ;' )

VM’s picture

feel free to write one up and file it as an issue against core. If it's accepted it can be adopted and put into the next release.

you don't need an overabundance of linux or scripting knowledge to work with patches: http://drupal.org/patch/apply

FYI: sandboxes can be set up on your localmachine rather than your server which is a benefit as well. I t end to set up a subdomain on my server to play with upgrades or updates or just to test modules and such. dev.mydomain.com there I can work on a copy of my prouction site to know how something new being introduced will effect the production environment.

publetariat’s picture

You may not need lots of experience or knowledge to run scripts, but you do need shell access, and in both my original post in this thread and the one to which you're responding I said that I don't have shell access.

RE: "write one up", what do you mean? Write what up? I've already written up my own procedure and posted a link here, so I don't think that's what you're talking about. As to asking for simplified instructions for minor upgrades to be included in upgrade.txt, I think Keyz said he's already looking into that.

VM’s picture

hmmm must be a communication breakdown here. I understand you don't have shell access to your production site. That's fine. read on ...

You DON'T need shell access directly to the live server to patch core or modules or themes or any file.
You can ALSO patch on a local machine (ie: your own computer) from a command line. An example of a program that allows you to do this on your local machine is cygwin on windows. if you have a mac there are tools to use on your local machine as well.

This is the reason I posted the link.

Stating that you or anyone can only patch if you have shell access is misinformation. If you don't want to be bothered with learning to patch thats a different story.

For those who want to learn how to patch:
cygwin for windows videocast = http://www.lullabot.com/videocast/install-cygwin-windows-xp

The above walks you through how to set up and install cygwin on your local machine as well as how to patch files on your local machine by providing the necessary command line.

publetariat’s picture

It ISN'T that I'm not willing to learn how to patch, sheesh! ='/

The 6.10 upgrade was far too time-sensitive for me to spend a few months boning up on Linux/Apache/php before upgrading. Every day that my site remained on 6.9 was a day my site was vulnerable to malware.

Your post is the first I've heard of any alternative to patching via a shell command, and this is part of the problem for noobs like me. We can search all through the online drupal documentation, the forum and so on, but still be unable to get a solution to our problem because there seems to be an underlying assumption in the documentation and most forum posts that readers a) have a development sandbox and b) are knowledgeable in Linux/php. Most of the posts I looked at contained snippets of code I could not understand, with commentary going back and forth on possible revisions to that code.

I spent hours and hours poring over this site and the entire web looking for an easier 6.9 - 6.10 upgrade path and didn't happen upon the solution you suggest, but that's no reflection on my willingness to learn. While I understand that it's unreasonable for me to expect everyone here to dumb everything down for the most ignorant person in the group (me, in this case), I also think it's unfair to subject people who are not Linux/Apache/php -literate to posts implying that the root of our problem is an unwillingness to learn. How are we supposed to learn from your experience if we don't feel welcome to ask questions?

Also, in my experience so far, every place where the online documentation or a forum poster indicates that the solution is to add this or that snippet of code to a specific file, the reader isn't told precisely where the snippet should be added to the file. Should I paste it in at the top of the file? At the end? Or in some other specific location? In VB and other coding languages with which I'm familiar the location of code blocks matters. Maybe if I knew Linux/Apache/php the answer would be obvious, but since I don't, it's not.

VM’s picture

by all means, ask your questions but when given a link to documentation it's best to read it before you comment on it.

You made your statements regarding shell. I tried to correct you. You stuck to your statments. I guided you back to my original response where I linked to the appropriate documentation that was either read or not read.

as far as code snippets and such, thats a totally different animal and has nothing to do with patching files.
PHP can be researched on php.net.
Drupal's api's can be researched on api.drupal.org and of course questions are always welcome on the forums.

a small overview:
Where snippets go depends on how one chooses to use it.
However all of this is moot without you pointing out a specific snippet and saying, HEY, how the hell do I use this? Where does it go? a forum link to the snippet is always a benefit so those who support drupal by way of the forums can go read, test and play with the snippet in question to better help THE ENTIRE COMMUNITY understand.

publetariat’s picture

You said:
"by all means, ask your questions but when given a link to documentation it's best to read it before you comment on it."

I DID read it, why would you assume otherwise? Misunderstanding it is a different issue, and all I've been saying here is that it's not always easy to find the info you want, and if you're new to drupal, Linux, Apache and php, to understand the documentation once you've found it.

VM’s picture

For the record, I know just enough to be dangerous with regrads to Linux, Apache or PHP.

I passed on the exact document that helped me understand how to set up cygwin and patch files. Within that document is a link to the video I passed on to you. THAT's learning from my experience, the same documentation I read, the same video I watched and worked with is being passed on to you. I did that willing to answer any and all questions you may have, as I have total OCD with keeping my tracker cleared of updates.

It's a 50/50 shot when it comes to how someone else will interpret help when it arrives. 1/2 will bitch that they get talked to like a 5 year old and the other 1/2 bitch that supporters are talking over their head. Just goes to prove one can't make everybody happy all the time. : )

Anyway, your thread now lives on and shows others that there is more than one way to skin a cat. There always is. Living beings tend to take the path of least resistance. It's natural. However everyones tolerance level is different when it comes to things they resist.

For you and for those that are having a hard time getting past "apprehension" when it comes to updating or upgrading a site:
My junior high football coach passed on a nugget of wisdom many years ago. He said, Kenn ... If you don't want to get over your fears get a dog or quit. I wanted to get over my fears so I practiced, learned and played on. On the flip side ... I now own three dogs too. ( It's possible one of them is from computers/scripts/drupal in some way : ) )

I understand anyones apprehension when it comes to updating anything. I agree that the upgrade.txt could in some way split the two processes but!... the first time something gets through where "stringent & tedious" best steps aren't followed there will unrest in drupaldom too. The conversation will shift from why are all these steps listed in upgrade.txt to why doesn't upgrade.txt say to disable this or that or do this or that. Double Edged sword from where I sit.

For, everyone of us who've been involved with computer technology in any way .... (we all are someone, or know someone, or are/am that someone we know), when there came a time when we threw caution to the wind and skipped steps in process/best practice etc. .... Ah, how I remember the days of saying, pfffft backups? who needs backups! I don't need no stinkin' backups. So I wouldn't back up. Because things went great the first time, I chose to be a non-backerupper. Then came that day ... that not all of hell broke loose, but just that part of hell that justifies that apprehension that you feel when one reads the update.txt file. From that day foward we usually, finally, adopt the best practice of backing up before we make changes to a database or an environment.

dnewkerk’s picture

April, from a quick look in your web host's knowledge base I see that Host Gator does offer SSH access (your domain nameservers are Host Gator, so I'm assuming it is your host). You just have to request it to be switched on: http://support.hostgator.com/articles/From-Search/18/do-you-offer-telnet...

This is also the case on "any" reputable hosting provider. Though I personally have a dedicated server, with all the various shared hosts I've worked on for friends, family, and clients, every one of them would enable shell access by request. If by chance I ever came across a host that refused that, I would suggest immediately leaving that host.

Whether Host Gator gives access to commands like diff, patch, etc I can't say for sure, however it would be worth getting access and finding out (if you are interested in trying this approach, that is). The time it would take to learn though will pay for itself before your next otherwise-30-minute painstaking Drupal upgrade (which it really doesn't have to be). Or just follow my guide via FTP which I posted in my first message. Or go with this guide (which suggests simply overwriting Drupal core instead of replacing it... though some people encourage a full swap of the files, it's almost certain to be fine either way in minor version updates... the only reason really is "if" there were a stray file it could "maybe" lead to some unknown security hole if left on your system... major versions though, 5.x to 6.x for instance, you must remove the whole thing and re-upload the new one). If however you decide to go for one of the fancier (geekier) methods, given your technical experience, I'm confident that it should be no sweat for you once you give it a shot... heck I'm a designer not a developer ;) I can barely write a functional line of PHP half the time (and even then it's only because Komodo Edit corrects my syntax errors for me haha... btw highly recommended - Komodo Edit... x-platform and free).

Also, though you mentioned feeling it was not worth the time to do, I do encourage you to install a copy of Drupal on your local environment (even if it's not a copy of your site). Having a free-for-all Drupal sandbox to just throw random modules and code at just to see what happens is a great way to learn... and also you can use it to do a quick test on upgrades of modules or core, to give you a warning if something goes wrong (before you try it on your live site). WAMP, XAMPP, MAMP, etc... all point and click easy.

If you do decide to stick with this upgrade method you've detailed, I suggest at the least next time simply using a file/folder comparison application, which will instantly tell you which files are different between the old and new version of Drupal. Definitely don't need to manually compare timestamps.

You mentioned reading a lot about people having issues upgrading to 6.10... can you provide some links from your bookmarks or history for me to check? I searched and found a few relevant posts, but the only real problems I found were when someone didn't follow the instructions.

Please consider adding a note and link back to this discussion from the top of your site's article, so those reading on your site have the opportunity to read about the options mentioned here.

- David

publetariat’s picture

Keyz -
I appreciate all you're doing to try and make this easier, not just for me but for others like me. Just wanted to say that first. =')

IMO, there's little point in setting up and running a local, development sandbox partition if a) you are not knowledgeable enough to configure and debug the server setup so that it's an exact match to your production environment, b) you don't know enough about the setup to understand the meaning or impact of a server anomaly when you see one, and c) the resulting development sandbox does not duplicate the production environment EXACTLY. My Linux/Apache cluelessness takes care of (a) and (b), and the fact that the best I could do is set up a Linux/Apache partition on my WinVista machine pretty much covers (c).

That's why I don't have a development sandbox. If I set one up in the future, it will be on a dedicated Linux machine.

VM’s picture

you can run WAMP right in vista don't even need a partition. It's actually not hard at all. A Simple matter of download, install, play. WAMP comes preconfigured for the most part and questions you have are quickly answered by the community here or other IT communities.

Your local machine doesn' not have to be a complete duplicate. If your server is PHP5 with MySQL5 and Apache2 than you are golden with WAMP as it already has those versions within it. Pre packaged server environments are usually ahead of the game with their packages not behind.

you seem to have quite a few pre concieved notions that is holding you back from experimenting and learning. I find I learn far more from something I break than I do something that works properly.

The 6.10 upgrade was far too time-sensitive for me to spend a few months boning up on Linux/Apache/php before upgrading.

For the record. 6.9 - 6.10 security update only affected those on windows servers from what I understand of the release notes. You also don't need to know everything about Linux, Apache, PHP. It is over exaggeration to state that you would have had to spend months reading/leaning/boning up on any of the technologies. You simply have to take the advice others have given you. Forget me, use key's advice. Realistically there is no different, unless you are counting tone of words. ; )

publetariat’s picture

My "preconceived notions" come from over 15 yrs experience as a db admin, software engineer, and later, a web app developer in a commercial setting. Best practices in the area of live vs. development are stringent, and it's not just me who thinks the only worthwhile dev server is a dev server that completely duplicates the production environment.

And my comment about spending months boning up on code WASN'T in reference to doing the upgrade, it was in reference to setting up a development server.

I can understand how a community-developed software package could encourage a more experimental, less rigid approach than the one in which I'm schooled and experienced, but that doesn't mean that I shouldn't continue to hold to my own best practices to the extent possible when using that software. I'm not saying I will *never* set up a development copy of my site, I'm just saying that the prospect is daunting to someone who's new to drupal, Linux, Apache and php (all at the same time).

If I seem to be making things out to be harder than you think they are, maybe instead of jumping to the conclusions that I don't read anything here thoroughly before commenting on it, that I have 'preconceived notions' that are false, and that I do not want to learn, you should consider the possibility that my views and experiences are representative of ANYONE who comes here with no prior experience in drupal, Linux, Apache and php.

Given how many hits my article has had in the past 24 hours, I can tell I am not alone in my confusion about the various upgrade options. Also, given how many emails I've received from people who wanted to let me know they agreed with me 100% that the procedure in upgrade.txt is a gut-level scary undertaking, I know I'm not alone in that, either.

Bottom line: I wasn't comfortable with the upgrade.txt procedure and didn't see how I could run the patch instead, so I came up with my own solution. It's tedious and inelegant, but it worked and it was risk-free. I posted my solution here for the benefit of the many others who share my confusion and concerns, and many of them seem to appreciate that I did. Can we just let it go now?

VM’s picture

I think it equally important to help clear up misinformation (fog) that consistently gets passed along ... based on experience in my fields. ; )

Surely it can be let go now that others who will read this thread know:

A) One doesn't need shell access to work with patches
B) Setting up a sandbox site on a local machine isn't difficulty nor time consuming
C) One does not need to be a Linux, Apache, PHP or Drupal guru to set up a server environment on a local machine

given how many times I've asnwered how to update within minor versions on drupal.org, I'm surprise a search did not reveal those topics.

I freely admit that sometimes it is difficult to see the forest through the trees.

dnewkerk’s picture

Hi April...

You're welcome, we're just trying to help :)

Take our advice: do setup a local sandbox (it literally takes only a few minutes, and has nothing to do with partitioning your system - it is a self-contained working version of Linux server apps that work on other platforms)... so long as the major versions of PHP, MySQL, and Apache match (and you should have PHP 5.2+ on both), as VM said, there's no "necessity" for a perfect match to the online environment. Even if you "did" setup a matching environment, unless you have a VPS or dedicated server, there's no way you can be sure your shared host won't change the versions on their server at any given moment. If there's any real wiggle room for problems it would be if your-versus-their setup had different Apache modules available, or things like that (and if so, you can usually rectify this pretty easily with a quick look in the forum of your local server software where any common module or setting is likely already discussed. I work on sites locally "constantly" then send those sites to a wide variety of online servers/hosts when complete, and have never had issues. If by chance I ever do have issues... I have backups in case of that. Local upgrade of core or a module in question will lead you to "near" certainty that it will go fine online... then you Backup the live site completely and restore in the unlikely event of an emergency.

As I believe VM mentioned the other day, if you "really" want an (as close to perfect as possible) test copy of your own site, then just set up a copy on a sub-domain or 2nd domain (which you can do on Host Gator). Use cPanel's File Manager to copy your whole live site into the folder of the test site, and import a database backup of the live site into the test site's database. Edit your settings.php on the test site to point to the test database copy. Add a password access to the test site (again, using cPanel) so that search engines and/or visitors can't index or visit the cloned copy. Now you have your identical-environment sandbox to test upgrades on, if you feel it's necessary to do so this way. It's no harder than how you installed Drupal in the first place, so it's really not anything new to learn to to do this. Even going this route (or a dedicated linux test server as you mentioned) won't lead you to a 100% guaranteed panacea with zero possibly of problems. An elusive permissions issue, human error, etc can all lead to your perfect test server working or not working, independent of the live site. Your only fail-safe guarantee is to Backup and in the unlikely event of an issue (after testing showed it should go fine), you should be ready to restore the backup.

Before doing "any" upgrade, it's very important that you read any available release notes to understand even an overview of what it is for. I don't install updates on my Windows, Mac, and Linux systems without doing the same... so the same applies with Drupal. It also isn't a bad idea to have a peek at the Issue queue for the module in question (or the Installation forum is also good in the case of core) to see if others are hitting major issues before you take the dive yourself (or if you have a test site online or off, throw the upgrade at it right away and see what happens). As VM mentioned, the release notes of 6.10 do mention that it is a Windows-only vulnerability in this case. http://drupal.org/drupal-6.10 ... also, they do provide a ready to go patch file (just covering the security issues) if you want to get the security fix with minimal adjustment to the rest of core (no bug fixes). From Applying patches: patch -p0 < path/file.patch ... not bad at all :D If you look inside the .patch file, you'd see that it literally only modifies a few brief lines in 1 file of core (other security patches could involve more depending on the nature of the issue). In this case, (still not recommended since you might make a mistake by accident) you could even just copy and paste the lines into the file manually if you want (replacing the old lines). You could run this patch locally (as VM mentioned) and upload the changed file... or you could run it online if your host permits the needed "patch" command.

Again, I really encourage you to link back to this discussion from your site's article. People reading your article would definitely benefit and learn from the responses here.

- David

publetariat’s picture

I've added the link, as you requested.

dnewkerk’s picture

Thanks. I had to look really really hard to find it... would you consider putting it at the top of the article, so people can have it in mind to read as well while they read your article? You might say something like "I posted about this article on drupal.org and received a variety of feedback which you may additionally find helpful" or something to that effect. People can come here and continue the discussion and feedback if they'd like as well, since it seems there is no public commenting on your site. I ask only for the benefit of other Drupal users, I'm sure you're aware :)

In my earlier post I asked you for some references to where you were reading about people having so many problems with 6.9 to 6.10... would you please add some of these links? As I mentioned, I have not found many such posts, and those that I did find pretty much always ended up being a mistake of the original poster.

Also you did not yet comment about this documentation I pointed out: HowTo: Updating Drupal 6.x to newer minor version

- David

publetariat’s picture

There is public posting of comments on my site, I just disabled it for that particular article because I didn't want to get any drupal upgrade discussions going on my site when really they ought to be going on here.

I put the link at the end on purpose. First of all, most hits on the article originate from this thread, so most people reading it have already been reading this thread. Secondly, editorial standards dictate that 'more information' -type references belong at the end of an article.

RE: links to posts where people have had problems, hate to leave you hanging on this but to be honest, I don't really want to spend the time repeating that search I went through a few weeks back and posting all the links here. I was sick with a chest cold all weekend and I've got a lot of catching up to do on my site and other things now. I can tell you that I see some threads right here in this forum that seem to be coming from people who are struggling with drupal upgrades, and I can also tell you that a Google search on '6.9 to 6.10', 'problems upgrading drupal', and 'drupal upgrade problems' will give you an awful lot to chew on.

Of course, my original search was on '6.9 - 6.10', I didn't start out with a preconceived idea that it was going to be difficult; sticking the word 'problem' in there is just Boolean search common sense.

Sunshiney’s picture

Thanks for this discussion. I have several security update warnings on my Drupal 6x -- and it's on a development box -- and I, likewise, have not updated. I am so busy trying to learn how to get Drupal to do what I want/need, that I just don't have the time to deal with any downtime/additional stress that would come from updating core. And yes, I agree that reading the forum posts that say "site broke after security update" or similar, causes me to put the update up on the shelf for a day when I'm more relaxed and can deal with any hiccups.

Interesting read. Thanks for it.

Back to the search box...