Last updated June 18, 2015. Created on July 19, 2011.
Edited by NewSites, elsatch, merrymuze, pfrenssen. Log in to edit this page.

This post contains the information of upgrade.txt that is relevant to a minor Drupal core update. To see the full upgrade.txt that was formerly posted here, go here:


This document describes how to update your Drupal site from one minor 7.x version to another minor 7.x version; for example, from 7.8 to 7.9, or from 7.6 to 7.10.

First steps and definitions:

  • If you are updating to Drupal version x.y, then x is known as the major version number, and y is known as the minor version number. The download file will be named drupal-x.y.tar.gz (or
  • All directories mentioned in this document are relative to the directory of your Drupal installation.
  • Make a full backup of all files, directories, and your database(s) before starting, and save it outside your Drupal installation directory. Instructions may be found at
  • Always try an update or upgrade on a test copy of your site before applying it to your live site. Even minor updates can cause your site's behavior to change.
  • If you used an install profile make sure to keep it when performing step 3 (remove all old core files). If you remove your install profile your site will begin throwing "undefined index" errors. (

Update problems

If you encounter errors during this process:

  • Note any error messages you see.
  • Restore your site to its previous state, using the file and database backups you created before you started the update process. Do not attempt to do further updates on a site that had update problems.
  • Consult one of the support options listed on
  • Also consider consulting the #drupal channel on IRC
  • Updating your Drupal Core files using drush may also result in "undefined index" errors.

More in-depth information on upversioning can be found at


To update from one minor 7.x version of Drupal to any later 7.x version, after
following the instructions in the First steps and definitions section at the top of this file. A simplified version of these instructions is given in the Installation Guide. You may find it helpful to refer to those instructions and be sure that you understand their equivalence in order to ensure that you understand what you are doing.

  1. Log in as a user with the permission "Administer software updates".
  2. If you are updating a live, production site, go to Administration > Configuration > Development > Maintenance mode. Enable the "Put site into maintenance mode" checkbox and save the configuration.
  3. Remove all old core files and directories, except for the 'sites' directory, the original install profile in the 'profiles' directory and any custom files you added elsewhere.
    • To be more specific, in your Drupal root folder, delete all files and the following folders: includes, misc, modules, scripts, and themes. If you used a normal installation, then also delete the profiles folder, but if you used a custom profile, then in the profiles folder, delete the subfolders minimal, standard, and testing.
    • If you made modifications to files like .htaccess or robots.txt, you will need to re-apply them from your backup, after the new files are in place.
    • Sometimes an update includes changes to settings.php (this will be noted in the release announcement). If that's the case, replace your old settings.php with the new "default.settings.php", and copy the site-specific entries (especially the lines giving the database name, user, and password) from the old settings.php to the new settings.php.
    • If you had added any custom templates or other custom files outside the "sites" folder, then you will need to restore them from your backup because they have been deleted. One example of this would be if you use Views with a core theme. For this reason, it is best that if you use Views with a core theme, not to do so directly, but only through a subtheme. By doing that, your template files will be stored within the "sites" folder and will not be deleted in this procedure.
  4. Download the latest Drupal 7.x release from to a directory outside of your web root. Extract the archive and copy the files into your Drupal directory.
    • On a typical Unix/Linux command line, use the following commands to download and extract:
      tar -zxvf drupal-x.y.tar.gz
    • This creates a new directory drupal-x.y/ containing all Drupal files and directories. Copy the files into your Drupal installation directory:
      cp -R drupal-x.y/* drupal-x.y/.htaccess /path/to/your/installation
    • If you do not have command line access to your server, download the archive from using your web browser, extract it, and then use an FTP client to upload the files to your web root.

    This will (a) install fresh copies of the files and subfolders deleted in step 3, (b) overwrite any files in the "sites" folder that are part of core, e.g., "sites/all/README.txt" and "sites/default/default.settings.php", and (c) leave alone any file in the "sites" folder whose path and name is different from any file in core. As an alternative, you could (a) copy all the files and folders except "sites" from the new core you downloaded into your Drupal root, (b) if the release notes indicate there have been changes to "settings.php", then replace your "default.settings.php" with the new version in your download, replace your current "settings.php" with a copy of the new "default.settings.php", and insert any site-specific content from current "settings.php" into the new one, and (c) repeat step (b) for all additional sites in a multi-site installation.

  5. Re-apply any modifications to files such as .htaccess or robots.txt and restore any deleted templates or other custom files you had in core folders.
  6. Run update.php by visiting (replace with your domain name). This will update the core database tables.

    If you are unable to access update.php do the following:

    • Open settings.php with a text editor.
    • Find the line that says:
      $update_free_access = FALSE;
    • Change it into:
      $update_free_access = TRUE;
    • Try again to run update.php.
    • Once the update is done, $update_free_access must be reverted to FALSE.

    In a multi-site installation, run update.php again for each site.

  7. Go to Administration > Reports > Status report. Verify that everything is working as expected.
  8. Ensure that $update_free_access is FALSE in settings.php.
  9. Go to Administration > Configuration > Development > Maintenance mode. Disable the "Put site into maintenance mode" checkbox and save the configuration.

Looking for support? Visit the forums, or join #drupal-support in IRC.


ahmedhanyfawzy’s picture

I think there are some missing steps , I sorted it out and listed it on this blog post: drupal core upgrade steps i think it is practical and may be easier too.

pfrenssen’s picture

The blog post above promotes bad security practices which would expose your entire sites/default/files/ folder to anyone with an account on the server.

lesthomas’s picture

I both like and hate Drupal at the same time. I'm not a developer, but am in charge of my Drupal site. All instructions are written by developers for developers, which I am not. I would like to run an update to my Drupal 7.9 site but am certain I would screw it up with such nebulous directions as:

"3. Remove all old core files and directories, except for the 'sites' directory, the original install profile in the 'profiles' directory and any custom files you added elsewhere."

As an average shmoe, how am I supposed to know what to remove and what not? What's considered a "core" file? Where is the original install profile? If I've done many updates I don't want to lose how do I know what to save? I'm not even going to try with directions like these.

In the future perhaps have 2 sets of directions: One for developers and one for simpletons like me.

guyiac’s picture

I hate to admit it, but I have to agree with you. For those of us who are technical but don't live and breathe this stuff, more concrete instructions would help. A second set of instructions is a great idea.

Then again, considering this is open source, the only way it's likely going to get done is if someone volunteers to write that second set of instructions. The problem with that is that the people who can do that don't need that second set of instructions, and so probably see little value in doing it. Kind of a catch 22.

suffering drupal’s picture

Your observation is absolutely right. And not only aplicable here, but all over Drupal (community). If your skills are not above a certain level, the odds are high you will never reach it. It's like kind of reserved to a certain elite, something like Isla de Muerta: It's an island that cannot be found except by those who already know where it is.

I started with Drupal in 2007 and then my life got stuck...

pfrenssen’s picture

I think the instructions are pretty clear but I'll break it down:

Remove all old core files and directories [...]

These are all the files that are included with Drupal core by default. If you doubt which files these are you can simply download a fresh copy of Drupal core and see which files are included in the archive. To easily find which files match you can use a file comparison program.

[...] except for the 'sites' directory [...]

This directory contains all your site files, such as modules, themes, client uploaded files etc. Deleting this would be rather disastrous. This 'sites' folder is found in the root folder of Drupal.

[...] the original install profile in the 'profiles' directory [...]

If you used a custom install profile then make sure you have a backup of this and that you don't accidentally delete it. As the instructions say these are placed in the 'profiles' folder which is in the root of the Drupal installation.

[...] and any custom files you added elsewhere.

If you added files to the site yourself which you would like to keep then make sure you don't delete them. This is mainly intended as a warning for people that have installed additional software or other files and folders in their Drupal website.

josefg’s picture

To print it out:

With Drupal 7.x, delete the following:

Natural Foods from the Wild Perennial Crops of the Sahel

paulbuk’s picture

Thank you. I'm sure most of us could have spent time many hours working out the above, but a simple list like the above goes a long way to help those who 'fret' about such upgrades. I'm running on a pure Ubuntu 11.10 LAMP box and once one gets under that bonnet it can be baffling to say the least. Bravo! on seeing to a 'simplistic' approach to help others learn the basics.

zakmck’s picture

f you don't have sufficient proficiency in Unix and its command line, PHP, Apache, MySQL and probably more, then I'm afraid Drupal is not for you. If you were told something different, I'm afraid they were unrealistic.

shirleyborrett’s picture

I'm not from a software development background and have only a rudimentary understanding of the things you list. I've never used 'command line'. Despite all these disadvantages I have managed to successfully create and maintain six sites using drupal over the last couple of years. One of them is a membership site in it's third iteration and now including civiCRM (although I've had some helpful coaching for that). I think it's a great shame to put off non-developers from using drupal by listing a whole load of competencies they don't necessarily need.

I've learnt that although drupal is powerful, that doesn't mean it's simple. There always seem to be multiple ways of doing things and making the right choices can be a headache. I've bought several books and studied them, I've read the online documentation and browsed the forums for inspiration when I'm stuck. I've recently even become brave enough to ask questions on the forums, and found that generally people here are helpful and don't make me feel like an idiot because I make some silly mistake or don't understand code.

For small not-for-profits like the one I run, and for individuals starting web businesses, open source and DIY is often the only way to go because there's no money to pay for 'professional' developers. I accept that may not work if your website requirements are complicated or unusual, but for most functionality I've found that someone else has needed it and there's a contributed module that comes close to what I want. Sometimes that means compromise and I freely admit that on occasion I've spent days struggling with some problems.

I think drupal is great and if you're prepared for a steep learning curve you end up with a much better website than just using the web creation tool available from your hosting provider. Let's encourage 'unqualified' people to try it out and if they're prepared to put in the effort to learn, they'll be successful and spread the word about open source/drupal. I'm in my sixties and, unlike my grandchildren, I didn't grow up with computers - they weren't even around for two thirds of my life. If I can get to grips with drupal then I feel most people can.


Heathery’s picture

I couldn't agree more. I am in a position where I volunteer for a small non-profit without funds for a real web developer. I have found Drupal and the members of Drupal community to be one of the more welcoming for those in mine and similar situations. To cut off an entire segment of people and state pre-requisites is putting up unnecessary hurdles. Yes, sometimes the language is confusing for many of us non-programmers non-php- non-whatevers, but as you can see someone from the community steps up and helps out us luddites. That is one of the greatest draws of Drupal, the community.

highflyer’s picture

That is one of the greatest draws of Drupal, the community.

I agree with these words.

Nora McDougall’s picture

All of those skills are handy, but then there are folks who started programming in C (like me), and then there are folks who started programming in machine code. Maybe we should all go back there? Even in modern Computer Science classes they are starting to expect that students learn how to communicate with humans.

So, to those of you who have given humanly understandable instructions to the new folks, I applaud you.

Goofy2k’s picture

After executing step 6, I can not proceed to step 7. I get the response that my site is in maintenance mode !

How do I get in the management section when I can't login? Or is there some way to login?

I tried to go to the administration pages right after running update.php (there is a link on the results page), but also there I get te maintenance message.

stimpygato’s picture

Go to
...or the drupal directory name /user

"I take great pride in my humility" - me

knutselsmurf’s picture

I think I shouldn't have logged out. Now my cookie is gone and I can never get back in.
Just have to redo the installation, I guess.
I'm used to wordpress, I write modules for it. Working with Drupal is very frustrating. It could be great software. When it's finished. In 2020.

programmer from Amsterdam NL.

owen.watson’s picture

It would be great if there was a module for core updating to make it a bit easier. Is it even possible?

nicoz’s picture

onewomanbiz’s picture

I just wanted to say thanks for sharing this short guide. It got me on the right track and i was able to upgrade from 7.8 to 7.12 without a snag.
For anybody wondering, here's how it went. First, I unpacked the new version outside the root folder as indicated above. After that, I went into


and created the


file as a copy of the default.settings.php file already there. I then pasted the database array settings from my original site's settings.php to the new one. Since I had made no other modifications, this worked for me. After that I deleted the


folder in the new version so i could paste the /all folder from my original site in it's place. Finally, I pasted my original


folder into the new


folder. Once this file and folder stuff was in place, I opened my web browser to the new site url and logged in. I went to Reports where a message directed me to do a database update, which I did.

Finally, I returned to the status report. All systems green! Upgrade successful!

Almost forgot...
Maybe or not self-evident, but the final step is of course to rename the old site mysite_old,(you can remove it later when all is done) and the new installation to mysite to make it live and bring the old version offline.


paulbuk’s picture

Thank you much appreciated for your sharing of this process.
Good Karma to you guy! (-:

fuzzbuzz’s picture

Even though this comment is old, this worked flawlessly for me. Thank you!

sfcf’s picture

yes please
Making the American Dream Reality for South Florida

eventfarm’s picture

I am a fairly technical person, however Drupal is a beast and unless you immerse yourself in it for a few hours, just following basic instructions can be a challenge.

So I immersed myself in it and came up with this basic plan for updating. I had a basic installation, and all changes I've made have been through modules. I haven't edited any individual files to customize them.

1. Backup your DB (I used the Backup and Migrate module - follow instructions for that)
2. Using any file manager (I used my FTP client), change your /sites folder name to /Save
3. Unpackage the update file on your local PC into a folder called 7.12
4. Use an FTP client (such as Filezilla) and copy everything from the 7.12 local folder into the folder you have drupal installed in (ie, you should see /sites, /modules, /themes, etc to know you're in the right folder)
5. Use the overwrite function on your file copy - this will overwrite everything
6. Delete the new /sites folder
7. Rename the /Save folder to /sites
8. Go to and follow the instructions.

Worked well for me. I did it this way since I saw several references to NOT needing to delete all core files when doing a minor update (ie, 7.xx to 7.xx). I felt safer doing it this way.

chergett’s picture

This is exactly what I needed. No jumping through hoops for me! I wonder if this method can be used for upgrading to a new major version?

Casey Hergett

eduuser’s picture

Boy, did this ever get me out of the seemingly endless loop of upgrade failure!

The trouble, as everyone who doesn't eat, sleep and breath Drupal everyday, is that the update instructions are really vague. Furthermore, if you don't run Drupal on a Linux or Unix server, many of the "instructions" are just pointless.

The basic issue, I think, is that if you're in charge of a site written by someone who's long gone, it's a bit of a job to try and figure out WHAT he/she may have ADDED in the way of custom files - and where that person might have stuck them. Not fun.

Your technique works perfectly, is very simple to do, and, of course, doesn't require any puzzling over what should or should not be deleted. All that's left is to change the permissions on the update.php file so that you can change line 207 in the file settings.php from "FALSE" to "TRUE" and back again when you're done updating.

Thanks again for making Drupal administration less frustrating!

MBR’s picture

The basic issue, I think, is that if you're in charge of a site written by someone who's long gone, it's a bit of a job to try and figure out WHAT he/she may have ADDED in the way of custom files - and where that person might have stuck them. Not fun.

There's a fairly easy way to find these sorts of changes, but it does require typing commands to a Unix/Linux shell prompt. The basic idea is quite simple. Just use the diff command to find all files that differ from the base Drupal installation. Here are the steps:

  1. Find the version number of your currently installed Drupal core. To do that, look in includes/ for a define() statement that defines the symbol 'VERSION'. For example, if the file contains the line: define('VERSION', '7.12');, the version number is 7.12.
  2. Browse to
  3. Navigate to "Download & Extend"
  4. Click the "Drupal core" tab
  5. Scroll down to "Downloads" and click "View all releases"
  6. Find the release corresponding to the version number of your currently installed Drupal core.
  7. Download the .tar.gz version of this release to your server, somewhere outside of your website's DOCUMENT_ROOT directory. On most Linux installations the DOCUMENT_ROOT directory is public_html.
  8. Unpack the file with the command tar xvzf filename. E.G. - if you downloaded the .tar.gz file for Drupal Core 7.12, the name of the tarfile will be drupal-7.12.tar.gz, and it will unpack into a directory named drupal-7.12. The tar command would be tar xvzf drupal-7.12.tar.gz
  9. Now you can compare the official release and your installed version. Assuming the official release is in drupal-7.12 and your installed version is in public_html, the command would be diff -r -q drupal-7.12 public_html. Diff will list all files under each directory whose contents differ from the other directory, as well as all files and subdirectories that exist in one directory but not the other. Anything in public_html that's not in drupal-7.12 was added by the now long-gone site developer. There shouldn't be anything missing from public_html that's present in drupal-7.12, but if there is, the site developer deleted some of Drupal core's files.
  10. To see which lines have changed in those files that differ, run the same command without the "-q" argument: diff -r drupal-7.12 public_html.

Major differences in the sites directories are to be expected, since it conatins all your added modules, your theme files, and files uploaded by end-users (e.g. images, documents, etc.). You may also find differences in the .htaccess and robots.txt files. But differences elsewhere probably mean that somebody modified core.

watman’s picture

Its still a good idea to backup your core files somehow before overwriting them, just in case something goes wrong and you need to restore the site. in your example, this would be all the files on the remote server except the sites folder (which youve renamed to Save).

binarycorners’s picture

hi :)...i did everything what you did...but some files didn't overwrite well..i have try more than once, but it doesn't works...:(...and now i can't go to my admin...what should i do ?...any suggest for this ?


shirleyborrett’s picture

Thanks for this step-by-step guide it seems to work fine. I'd just add that if you rename the sites directory then visitors don't see your 'site in maintenance' page because drupal doesn't recognise that there's a site there and puts up the install.php page. It seems to me that the way around this is to copy the sites directory and rename one copy 'save'. Then the 'sites' one will get overwritten, but I'll still have the original as 'save' and the maintenance page will still appear - unless I'm missing something here.

davidprush’s picture

Before proceeding with the following commands, make sure you have downloaded the newest Drupal core named drupal-X.xx and expanded that file to your home directory. If you have done this correctly, you will have a directory in your home directory titled drupal-X.xx. The original instructions show you how to do this... use whatever method you're familiar with. Hashmarks '#' denote comments if you are unfamiliar with *NIX scripting.

#make a copy of your sites directory

cp -vr sites sites-save

#get your present working directory


#copy all files, directories, and subdirectories from drupal-X.xx to current directory

yes | cp -vr /home/yourhomedirectory/drupal-7.16/* /var/www/html/

#reverse the save on sites

cp -vr sites_save sites

After you run the above code you can run and you should be good to go!

D.P. Rush

Using Drupal Everyday!

suffering drupal’s picture

What just worked for me on a local site:
1 - delete all - except /sites folder
2 - copy new version of all - except /sites folder
3 - run update

I started with Drupal in 2007 and then my life got stuck...

credible58’s picture

I've installed Drupal 7 on Fedora 14. I initially did the install using the Fedora Add / Remove Software utility and it installed Drupal 7.9. Once I completed the install I checked for updates and discovered that a security notice recommended upgrading the Drupal Core modules to 7.14.

I am using the instructions on this page but when I come to copy the un-tar'd files over the existing files with:

cp -R drupal-7.14/* drupal-7.14/.htaccess /usr/share/drupal7

I get:

cp: cannot overwrite non-directory `/usr/share/drupal7/sites' with directory `drupal-7.14/sites'

This is because in Drupal 7.9, /usr/share/drupal/sites is a symbolic link to /etc/drupal7. Is the recommended cp command wrong or has there been a change in the directory structure between 7.9 and 7.14?


pfrenssen’s picture

Paul, I would ask this in the Fedora forums. There are no symlinks in a standard Drupal install.

mwm’s picture

The version of Drupal that comes from Fedora uses symlinks for the purpose of keeping site-specific settings and data separate from Drupal core. This allows Fedora's packaging system (RPM) to update Drupal without you having to move files around or do any of the extra steps on this page. Just run the graphical software update application, or run "yum update" as the root user from a command prompt. I'm pretty sure that automatically runs Drupal's update.php too, but it wouldn't hurt to run it anyway just in case.

merrymuze’s picture

I needed to update my implementation, so using the comments here I came up with this procedure, which worked for me:


My Requirement: Update from 7.12 to 7.14
(get latest drupal version from; for me that's
My Website: mysite (
Drupal Core Folder: public_html
My Situation: I've made changes directly to files (or added files)
I have the 'Backup and Migrate' module installed


0. Make a note of all files you've added or modified in 'public_html'. The best appoach to this is probably to keep a running record of all added / modified files (ie as and when you add or modify a file). If you haven't been doing this:
a) Download drupal core 7.12 to a folder (say coreOrig712) on your PC
b) FTP your current site's core files - public_html on - to a folder (say coreMysite712) on your PC
c) Use a tool such as KDiff3 or WinMerge to compare 'coreOrig712' and 'coreMysite712' and mark the files found to be different or new

Note that in general 3 cases exist:
i) Files that have been added
ii) Files you've modified that haven't changed from Vers 7.12 to 7.14
iii) Files you've modified that have changed from Vers 7.12 to 7.14
The treatment for each is covered in Step 11 below.

1. Local PC: Check the update release announcement (Notes on page) on whether update 7.14 includes changes to 'sites/default/default.settings.php'. In this case, there appears to be some changes to the comments, so I'm taking the answer as 'Yes'

2. Local PC: Unzip '' into a folder called 'coreOrig714'

3. Local PC: Since the answer in Step 1 was 'Yes', create a new 'settings.php' file as a copy of the 'default.settings.php' file in the folder 'coreOrig714/sites/default'. Re-apply to this new file the database-specific changes made to the 7.12 version of the 'settings.php' file

4. Log in as an administrator on

5. Click on 'Configuration > Maintenance mode', select 'Put site into maintenance mode', and click on the 'Save configuration' button.

6. Website Host: Backup DB. I used the Backup and Migrate module ('Configuration > Backup and Migrate') - follow the instructions provided in that module

7. Website Host: Backup 'public_html' (I use my FTP client to download these files to my PC). Strictly speaking, you need backups only of files you've directly changed (outside drupal) or added, but better safe than sorry!

8. Website Host: Rename 'sites' folder to 'sitesMysite' (I use my FTP client to do this)

9. Local PC: FTP all the files in 'coreOrig714' to 'public_html' on my Website Host. Select 'overwrite' for the transfer

10. Website Host: Delete the 'sites' folder, and rename the 'sitesMysite' folder to 'sites'

11. Website Host: Now re-make all the changes you had made in Ver 7.12 ('sites' folder clearly excluded):
i) Files you added in Ver 7.12
Add these files again in Ver 7.14, ie copy these files from your 'coreMysite712' backup to your Website Host
ii) Files you modified in Ver 7.12 which haven't changed in Ver 7.14
Copy these files from your 'coreMysite712' backup to your Website Host. Ensure you overwrite the existing files
iii) Files you modified in Ver 7.12 which have changed in Ver 7.14
I understand this case typically includes files such as '.htaccess', 'robots.txt', etc
Re-apply all the earlier modifications (made in Ver 7.12) to the new files in Ver 7.14

12. Go to - this will run update.php. This will update the core database tables


Caveat emptor: This is the first time I've done this, so there may well be mistakes or unnecessary steps. Corrections are welcome!


Gerimou’s picture

You got to be kidding !!!
I have just installed my first Drupal platform and wanted to upgrade from 7.10 to 7.14.
Is this really how you update ??? !!! and people say Joomla is technical ...
I may be a developer, but no coder or programmer.

Not happy :|

Please someone reply, that there is a button for automatic update, no IT diploma needed.

zakmck’s picture

this comment was put here, but actually it should have been a reply to another comment above. Please someone delete it.

ReasonableGuy’s picture

This upgrade procedure is far too difficult! How can people be expected to keep Drupal secure if the upgrade process is more involved than the installation!

WordPress get's it right - one click upgrade.

F.E.M’s picture

One click upgrade that could take down a whole site... In one click. Also if you want one click upgrades go with Pantheon.

nigelw’s picture

For those of you that are complaining about the update process of Drupal. Stop whining and start helping to work on #606592: Allow upgrading core with the update manager for Drupal 8

Furthermore, updating Drupal is not that complicated. The steps above are meant for the total newbie and cover each step in depth just to make sure you don't blow up your site.

To update your site:

1. Put site in Maintenance Mode
2. Backup your site (Files and DB)
3. Delete Core files (Everything except the 'sites" folder)
4. Replace core files with latest version (less the 'sites' folder)
5. Run Update.php

Simple. :)

abracad’s picture

Can I assume that for multisite upgrades the core files are replaced as described above and update.php must be executed for each of the sites individually?

nicoz’s picture

That is correct. In most multisite setups each site has its own db. Therefore you must update each db in the install separately.

averykaolin’s picture

No actually its not that simple.. However, your list is brilliant. That is the type of list that is needed. Short, simple and confident.


artfulrobot’s picture

I usually do this stuff using the Git repos, but read this article as I'm thinking of going back to the old way.

I'm pretty sure in the diffs I sometimes see that files have been deleted or renamed (esp. tests). In the procedure above, these files will end up as cruft in the the newly upgraded site directory. I suppose it's more likely that these are just messy/confusing for devs looking in there than causing a problem for Drupal, but it does seem a possibility.

Is there a policy or something to protect sites from this situation? (e.g. "the only files to be deleted will be READMEs etc.") or is it just something I should not worry about?


F.E.M’s picture

This rarely happens, and you could consider adding core files to git ignore if this is really bothering you. I have never had this be an issue

Denko’s picture

First of all, if you are on a shared host with cpanel and softaculous and installed drupal through that, then softaculous will upgrade it for you with one click.

I would advice to back up site and DB - just in case (I never had any problems though). In cpanel filemanager you can compress the web root (public_html) and download that, and from phpmyadmin you can export (download) your drupal database. You can also use the cpanel backups to download home directory and databases - maybe even simpler!

If your drupal install is not through softaculous, then (take backups and) merely upload (overwrite) the new unpacked version via FTP (filezilla). Then go to status report and see what else you need to do (often database updates).

nicoz’s picture

First of all, if you are on a shared host with cpanel and softaculous and installed drupal through that, then softaculous will upgrade it for you with one click.

I would personally never trust a third party like softaculous or fantastico to update my Drupal site. These parties tend to be one or two versions behind and can never guarantee a clean update. DO it manually and you will save yourself a headache.

If your drupal install is not through softaculous, then (take backups and) merely upload (overwrite) the new unpacked version via FTP (filezilla). Then go to status report and see what else you need to do (often database updates).

This is dangerous, You will overwrite the "sites" folder which contains your site specific stuff. Bad move. Also you should delete the core module (or contrib if that what you are updating) rather than overwrite. Files and folders change. This is messy if you just overwrite.

averykaolin’s picture

Well after nearly 6 months of trying to build a drupal site (in my off time, I work full-time, kids etc.) I am about to throw in the towel. I am pretty tech savy, I can follow directions but I am not a coder. This is the third install of Drupal I have had to try, each one with its unique failure. I researched the community postings but haven't found any info to help.. My latest error is: Parse error: syntax error, unexpected ',' in /hermes/waloraweb050/b474 after trying to do a core update and running update php. Thanks for any help

stanb’s picture

What version of Drupal are you trying to install? Are you trying to install it on a remote shared server or are you trying to install it locally? If on a remote server, who is the host?

Have you tried following this procedure?

Stan B

charles ross’s picture

Oh, wait...

But that Gist is the best way to get the clue seed started. Thanks!

F.E.M’s picture

All the latest updates no matter how small get pushed from upstream directly into my install.