Last updated November 19, 2014. Created on March 22, 2012.
Edited by Steve -cc, ssiruguri, talvi, shamio. Log in to edit this page.

For the most complete documentation for upgrading (change from D6 to D7 etc.) an existing Drupal site, see

Instructions on how to update Drupal core with a newer version of Drupal of the same category or same base version [ ie Drupal 7.1 to 7.2 etc ]

  1. Make a backup of your Drupal instance. (For ex: with MySQL)
  2. Download the latest release of your current Drupal version.
  3. Extract the [tar ball or zip] Drupal package.
  4. Set your site on maintenance mode (For ex: How on D7)
  5. Delete all the files & folders inside your original Drupal instance except for /sites folder and any custom files you added elsewhere.
  6. Copy all the folders and files except /sites from inside the extracted Drupal package [tar ball or zip package] into your original Drupal instance.
  7. If the update release includes changes to settings.php replace old settings.php in .../sites/default/ with the new one, and edit site-specific entries (eg database name, user, and password)
  8. If you have modified files such as .htaccess or robots.txt re-apply those changes to the new files.
  9. If you have a favicon.ico file that was deleted replace it too
  10. Login to your site as administrator or as user no 1
  11. Run update.php by navigating to http://...yourdrupalsitename/update.php
  12. Follow the process to update your Drupal instance
  13. Disable maintenance mode

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


axon-obriend’s picture

Just did an upgrade to 6.26 using these quick instructions and they don't mention keeping any custom themes that were installed.

AgnesCB’s picture

Custom themes should have been installed under sites/all/themes so that they get preserved in the sites folder (step 5, delete everything except the sites folder) during the upgrade.

Just like custom modules.

SQSBMedia’s picture

I think there might be some disconnect. I have loaded my modules and themes directly into the themes and modules folders as instructed by those project pages and by proxy the assumption that that is how it should be done. Could you please provide an example of how to rectify this without wreaking havoc on our site? If I just move those modules to the sites folder now will it break paths and therefore break the site? Please advise as I need to perform an upgrade but do not want to lose any information in the process.


jgrubb’s picture

This is everyone's first Drupal mistake, and this will be fixed in Drupal 8, but for Drupal 7 and below modules and themes do not belong in the /modules and /themes directories. The standard place to put modules and themes is in sites/all/modules and sites/all/themes. The reason for this is that it keeps all customizations to your Drupal site limited to the sites/ directory. This makes it a lot easier to update/upgrade Drupal core via the method above. Otherwise you have core modules and contributed modules all mixed together and it gets a lot more confusing.

If you find yourself in the same situation as the comment above, all you have to do is -

1. Disable all of your contributed modules and themes. That means everything that's not listed under the "Core" category on the module admin page.

2. Place them in the correct place - sites/all/modules and sites/all/themes. Create these directories if they don't already exist.

3. Refresh the modules admin page so that Drupal will pick up the modules in their new location.

4. Reenable the contributed modules and themes that you disabled in step 1.

5. Carry on with the rest of the Drupal core upgrade process.

In Drupal 8, this longstanding point of confusion for new Drupal users will be fixed and contributed modules and themes will go where it appears to the new user that they should - modules/ and themes/.


Castus’s picture

Hi John,

I was wondering: if you disable the modules and move the files, will your preferences/configuration of those modules remain? Or will they be reset?

Thanks in advance!

Formeo’s picture

The config will remain as it is stored in the database, not in the filesystem.

SKAUGHT’s picture

This will depend on the module itself. As per good coding standards, a module should remove any variables or tables it creates when uninstalled (some will if simply disabling..again depends on module code itself), not all modules do.. be sure to have a database backup (Backup & Migrate) before you begin. A local or other development staging environment would be best to use to test first.

josvlaar’s picture

People also might want to preserve the robots.txt from root folder if it has been customised.

mark_johnson’s picture

In addition, you may want to preserve the .htaccess file or other files that have custom code in them specific to your site/server.

sfbob’s picture

also favicon.ico if you have one and your installation is in the website root directory

rudyard55’s picture

Plain language instructions! So rare! Thank you!!!

The Slave's Dream’s picture

Lots of lovely green ticks on my admin page now - thank-you :)

The ache for home lives in all of us, the safe place where we can go as we are and not be questioned. It impels mighty ambitions and dangerous capers.

aatkinson’s picture

I need to update my drupal 7 site - both core drupal plus a number of modules.
Is there any advice on what should be performed first (core then the modules, or modules then core)?


Chasen’s picture

I'm not sure if there's a specific order (as I've done both without issue) but I usually do core first, just in case an individual module has been updated in response to a change in the core code (such as a security patch or something like that).

Generally I:

  1. enter maintenance mode
  2. do a backup
  3. update core (using the instructions above except I usually preserve code in robots.txt and also .htaccess and import them into the new files)
  4. run update.php and flush caches
  5. do another backup
  6. install the module updates (if there's more than 5 or so modules to update, I usually break them up into smaller batches doing backups in between - 95% of the time it's not needed but for a few extra seconds it has saved me huge hassles in the past
  7. run update.php and flush caches
  8. run cron and do a status check
  9. do a final backup and then take website back live
Rylos007’s picture

Flush caches? Is this something that is automated and part of that process or do I do this manually somehow?

Can you explain the Cron part to me. All new to me.


You know I know much less more than you!

Steve -cc’s picture

Thanks for the step by step process notes. Many of us might forget to do the more than one database backup.


rajmataj’s picture

While updating a Drupal site with Drush, you may see this:

NOTE: A security update for the Drupal core is available.
Drupal core will be updated after all of the non-core modules are updated.

So, that suggests you update the contrib modules first, then core.

okiaer’s picture

If I follow the instructions shown in this article the site is down when I delete the old files and upload the new.

If I don't want the site to be down but inly show the maintenance page when upgrading, what is the best practice?
(The files are gone when you upgrade, between delete and upload...)

CDU’s picture

I always add another file in the each site's root directory (where you see the Drupal index.php and update.php files, etc.). The file I add is named "index.html". Notice the extension. Drupal does not use the html extension, only php.

The server will serve up Drupal's index.php first if it is there. But if not, then it will serve up the html version. This means that you can leave the index.html file on your site at all times, and when you delete the Drupal core files (including index.php), then the server will give the html file to visitors. This way, your site does not look like it disappeared from the internet.

The index.html file just needs to display a message that the site is being worked on. It can be as fancy as you want, or can be as simple as the following example code.

<div style="margin: 50px; font-size: 20px;"><b></b> is currently undergoing an upgrade. It should be back up within an hour, or so.</div>

- Carl

peterohman’s picture

I suggest you modify the step 5 to: create a new directory in the root with the name drupal-old, and move all the files & folders inside your original Drupal instance except for /sites folder and any custom files you added elsewhere into it. Then add a step 13: When you have checked that the updated version works as expected, you can delete the directory drupal-old. Otherwise you can probably find the files you should have kept in this directory, and move them into the updated core...

augustofagioli’s picture

I don't like the idea of deleting my websites (even part of).

Once backup, download are ready, what I usually do is :

tar -zxvf drupal_LATEST.tar.gz
mv my_drupal_webiste_root   my_drupal_webiste_root_PREV
mv mv drupal_LATEST  my_drupal_webiste_root
cp -Rfv my_drupal_webiste_root_PREV/sites my_drupal_webiste_root/

Following this approach, I can quickly recover to PREV with an easy

mv my_drupal_webiste_root   my_drupal_webiste_root_BROKEN
mv my_drupal_webiste_root_PREV  my_drupal_webiste_root
vulfox’s picture

How to update Drupal core with Drush

(Drush is a command line tool for Drupal).

1. Backup everything (all files, databases, etc)

2. Put your site in maintenance mode

Either from Drupal interface or with drush:
(commands for Drupal 7)
drush vset --always-set maintenance_mode 0
drush cache-clear all

3. Save your .htaccess-file, robots.txt and favicon.ico somewhere

...If you have modified them

4. Update Drupal with drush

drush up drupal

5. Check that everything works

Go around your site and test everyhting!

6. Put your site online again

Take your site away from maintenance mode either from Drupal interface or with drush (command for Drupal 7)
drush vset --always-set maintenance_mode 0
drush cache-clear all

okcool’s picture

In step 2 the command to put the site in maintenance mode should be:

drush vset --always-set maintenance_mode 1

shouldn't it?

jgrubb’s picture

Maintenance mode is 1 for on and 0 for off.


jbarchuk’s picture

Rather than just 'asking the Q' I'm going to add a lot of details just in case they make a difference, and so it's all in the record. The drush error I receive returns *exactly* *one* hit via google, so it is obviously not common, and I'm doing something different/weird as regards setup or execution. I'm also new to drush which is the main reason debugging is not intuitively obvious.

This is all under OpenBSD 5.1 but handrolled Drupal *not* the OBSD distribution.

Trying to upgrade Drupal 7.15 to 7.19. Drush is brand new install from drush-7.x-5.8.tar.gz.

I'm not typing at the server kbd but managing via LAN and PuTTY.

I'm logged in as a vanilla user who owns /home/[user] and /var/www/htdocs/[user]

Drush resides in /home/[user]/drush, and that is EXPORTed to PATH.

The trick here is that tutorials like this often don't mention where the user needs to cd to to make things 'work.' It took only one try not being in the webroot to figure out that I need to cd to the site webroot for drush to be able to 'find' the drupal install.

Drush works fine, which is awesome, turns maintenance on and off as described above, so I know I'm in the right place for that.

'drush up drupal' first returns the version status of drupal and modules, and that core needs update. (I just did a couple of module updates manually before I decided to try drush for the core.)

But, and this is the Q :) after the core WARNING and 'Do you really want to continue' and pressing 'y' I receive 'It's not allowed to store backups inside the Drupal root directory.' So, it appears drush doesn't like me being here, or there's some other configuration item I need to set to 'store backups' elsewhere. It's that error message that (via google) appears nowhere else on the net except for the source page.

It's possible that typing at the server kbd, or logging in as root, or something else might make the error message not happen, but there ought to be another -better- fix. With this level of -critical- function, core upgrade, I'd rather ask the Q here rather than bounce around trying random things.


jim barchuk

ge’s picture

If the default location for storing backups isn't working, you can tell drush to use someplace else. The syntax should be something like this, although I haven't tried it myself, since the default happens to work for me:

drush up --backup-location="/path/to/store/backups"

For a list of drush help on a variety of topics, type:

drush topic

I found the info on command-line options for drush with:

drush topic core-global-options

Genny Engel

jbarchuk’s picture

I'm not exactly sure what fixed the problem, but it's not happening any more.

I had been using what was probably an unconventional setup. I set the 'site owner' $HOME to /var/www/htdocs/here simply because that's where I did most of my work and where it was easiest to start from. Drush is installed in $HOME/drush.

Later I decided that for security and compatibility/environment reasons I was uncomfortable with a 'user' having a $HOME set to /var/whatever and changed it to the conventional /home/username.

With that I don't see that type of error after I cd to /var/www/

jim barchuk

Tran’s picture

We have to delete existing modules from our server?
This seems like a disaster waiting to happen.

darksnow’s picture

You don't need to delete existing modules from the server, as stated above, all modules should live in sites/all/modules and as such will me preserved as the instructions say to leave the sites folder intact.

Web Developer at
Web Master of the UK Snowboarding community at

catarinavclemente’s picture

Before step 9, don't forget to upload the translation file into yoursite/profiles/default/translations.

tm541’s picture

In the update text of the drupal core file it says to, "Disable all custom and contributed modules." before updating core. In your instructions here you do not mention that part. Is it no longer necessary to do this when updating from 6.26 to 6.28?

jegger79’s picture

I just followed instructions to update from 7.14 to 7.22. Seemed to go smoothly but the update was not detected. i.e. Site still says I need to update. I tried to run update.php but says no update detected. What exactly is Drupal looking at when it checks the version?

Chasen’s picture

When you copied up the new core files, did you make sure to overwrite the existing ones? You may need to check your FTP permissions/etc to make sure the new files are overwriting the old ones. Or you can use the delete method to be sure the new files are the ONLY files that are there.

jegger79’s picture

Thanks for replying. Yes - I made sure to delete the old files from the server before adding the new ones. The only files I kept where in the sites folder.

schiavone’s picture

You've just installed Drupal. You should already have the latest version.

Daniel Schiavone

jbossbarr’s picture

Hi there,

I'm running Drupal 7.22 and *cannot* for the life of me get any of these instructions to work to update to 7.23. Permissions are set properly, I preserve the .htaccess file from the old installation, I retain the /sites directory as indicated - but I still get 500 errors when attempting to return to the site to complete the update. In Drupal 6, this seems much easier. I have yet to find any instructions as to how to beat this issue. The only fix is to move all the files back into my docroot (/var/www/drupal) and return to 7.22. Any attempt to update, no matter what I've tried, results in 500 errors.

What in G-d's name am I doing wrong? I have followed the manual update instructions without any success.
Can someone please comment?

Thanks very much!

PS, I'm just testing Drupal, but trying to get the upgrades/updates to be successful before putting any of this into production, so losing work is not a big deal.

Chasen’s picture

Hi jbossbarr,

Can you please confirm exactly the steps you're following, in order, and exactly what action you are performing/trying to perform that throws the first error?

Going forward, I'm going to assume there's no issue in the process you're following when performing the update. You've come this far so you've no-doubt read (and tried) the various update methods described in this thread.

The key thing here is the 500 internal server error you report. The 500 error is pretty much a catch all server error, but that tells us a lot: it looks like it's an issue with your hosting, not Drupal, as you're experiencing this error when other Drupal users are not (myself included - I manage about 50 D7 sites and regularly update them without any problem)

If I were you, I would start with the hosting platform:

  • What hosting platform/provider are you with?
  • Do you have any access/control over settings with the hosting platform?
  • Do you have a php.ini file, if so, what are its contents?
  • Do you know what version of PHP and MySQL your server is running?
  • If you're on cPanel, log in and check the Error Pages module and also the Error Log module, if the server is throwing an error it should be recorded in there in some way/shape/form.
  • Check the PHP Configuration, in cPanel, and take a screenshot of the settings and post here if you can.
  • What's your PHP Memory limit?

Good luck!

jesmarquezacevedo’s picture

I did step but when run update.php my site didn't respond. It was with version 7.23.

Any help?

Jesus Marquez

darksnow’s picture

What do you mean by didn't respond?

I assume you mean you got no content at all (as opposed to some error message) and just a blank white page in the browser.

The best way to diagnose this is to look at the server error logs (/var/log/apache/error.log or similar) and see what PHP is telling you. Since this is usually a code problem on your site there should be at least a clue in there.

White page errors like this can be caused by all sorts of things so it's very difficult to advise without more information. Also, I assume you didn't do this to a live site :)

Web Developer at
Web Master of the UK Snowboarding community at

j3ll3nl’s picture

What i can see is that the manual is not right.

drush pm-update project [project] -> drush pm-update projects [project]

Developer OOIP

coscap-na’s picture

I followed all the steps till 10, and when I click I get a message saying no pending updates.. anyone have any idea why?

MKorostoff’s picture

Hey guys! I threw together a video tutorial for the upgrade from 7.23 to 7.24, hope you get some use out of it

jeffrey.lewis’s picture

I'm upgrading from 7.13 to 7.24
Completed the steps outlined above.
When running update I get the following error message...

Fatal error: Call to undefined function ctools_include() in /.../.../.../.../sites/all/modules/views/views.module on line 61

Figuring I missed a step somewhere, I replaced all my files the way they were, now the upgrade screen does not appear at all, nor does the home page, admin page or any of the webpages.

On a scale of 1 to "Screwed", how hosed is this thing?

Rylos007’s picture

In following the direction it states in one are "Open settings.php..."
Where is 'Settings.php'? I am via FTP and do not see it/ can not find it.

Sorry, Jeff. Looks like I tagged this on to your posts tail. Do not see that I can move or even delete the post to repost properly. Doh!

You know I know much less more than you!

CDU’s picture

You should find it here: "sites/default/settings.php"

- Carl

jimlongo’s picture

After installing the new files
authorize.php , cron.php , index.php , update.php
and the folders includes , misc , modules , profiles , scripts , sites

Click the update button and the url redirects to install.php (which I haven't copied over)
If I do copy it over it will then want to start at the beginning as if it's a fresh install.
Happening on multiple installations of 7.25

keep SITES change THEMES.
keep SITES change THEMES.
. . .

Projekz’s picture

Has anyone updated from 7.24 to 7.26?

I have updated from Drupal 7.24 to 7.26, using the step 1-12 process above, but my reports are still flagging it up as a security risk that needs updating. I have replaced all 7.24 files with 7.26, except: the Sites and Themes folders. There were also files in 7.24, which were not in 7.26, such as Patches, and hashlist. I have left these in tact. What else do I need to do?

mcfilms’s picture

As noted above, you should replace the root "Themes" folder and just keep the "Sites" folder intact. You should NOT have any custom themes in that themes folder. Custom themes are supposed to be in sites/all/themes directory.

Secondly, sometimes the files with a leading dot do not get copied over by the FTP program. So it is worth it to be sure you updated .htaccess and .gitignore.

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

Projekz’s picture

Thanks Themes. It so happens that I had downloaded more than one 7.24 folder, so I was updating the wrong folder.

nick444’s picture

Hello everone - I have just upgraded from Drupal-7.31 to 7.32, and immediately lost my ability to log in on my home page.

I can't even make the login block reappear because as far as Block is concerned, the login block is set to the left sidebar. Not so as it is not there!

I regret upgrading to 7.32 as it has complicated everything, but ithe red message kept badgering me about upgrading.

I assume the new version is busted in some way and not properly ready for the public - anyone else had a similar problem?


darksnow’s picture

I've not had any trouble with the upgrade so far.

Try going to the login page, rather than replying on the block. It's url is just /user

I can't begin to speculate on why the block is missing but once you're logged in I'm sure you can investigate.

Good luck.

Web Developer at
Web Master of the UK Snowboarding community at

Chasen’s picture

I've upgraded nearly 60 sites all with various designs and configurations without any issues. I'm guessing you have something custom/non-standard which isn't gelling with the new version - or the new files are overwriting an existing file which had custom changes in it - such as module or template customisations?

First thing I would do is clear your cache with drush or manually emptying the cache and cache_ tables in the database and see if that works.

Did you have a CAPTCHA/RECAPTCHA configured on the login block by any chance? If you do you may want to manually edit the database tables to truncate the CATPCHA tables which will manually uninstall the module to see if that's what's causing the block to not display as I've seen this before (but mainly when migrating from test domain to live domains and the keys invalidate.)

As mentioned above by darksnow, you can try the default login page which is just (also try and see if you can get in that way?

sama93536’s picture

You think they would come up with an easier way to update? Seems really dumb they don't have an automated updater

Chasen’s picture

As far as I know, the main reason is because the updated files would potentially overwrite files you've edited, such as the robots.txt or .htaccess files. These files come with each Drupal install but there are valid reason why you would manually make changes to them, so automatically updating them would mean you'd lose your edits within those documents.

aaronaverill’s picture

As far as I know, the main reason is because the updated files would potentially overwrite files you've edited, such as the robots.txt or .htaccess files.

So basically, because the team hasn't done the work required, because it's not important to them.

Look, there are tools and tech to solve this issue. It's not rocket science doing a diff of a filesystem and resolving the conflicts. Source control? Hello?

It's a pity we make excuses.

mcfilms’s picture

It always makes me smile when someone raises expectations from "the team". In community-driven, free and open-source software, WE are all "the team" and the team is us. So if it appears to be a trivial task to create a difference to patch the Drupal core and you think that would be helpful, do it. If you think Drupal core should be under source control, get involved and advocate for it.

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

Steven_Bradford’s picture

I agree, after all these years, it's still a pain to update, which is why I rarely do. When I decide to finally catch up on updates, I look up the instructions ( a search that's difficult using this website's "search" function, much faster to just google it to get to here) and find it's as confusing as it's always been. Vague instructions (Drupal instance folder?) that assume that someone who isn't a drupal developer is going to be comfortable willy nilly deleting files.
So my website will stay at 7.10 before I risk disabling it completely.

Steven Bradford
frustrated drupal admin

Chasen’s picture

I agree it's not "one-click" WordPress style, but it's not meant to be, primarily for security reasons. If you control your site correctly, updates to Drupal core take mere minutes with very high chances of success.

In a standard Drupal environment, you should be able to overwrite the entire Drupal code base without overwriting your custom site files. This is because your custom theme for your site should either exist in sites/all/themes/* or sites/* (for multi-site installations) - the Drupal base installation files contains nothing in these locations, meaning you can overwrite the base Drupal instance without impacting any of your custom files.

The reason the official instructions recommend deleting the base instance before installing the new is because a) there could be a permissions conflict where a new file doesn't correctly overwrite an old file, or b) there could be malicious/additional files which should be removed when upgrading (unless they're files you've actually added yourself) - the only way to guarantee that your Drupal update contains only the new files is to delete it, but realistically if you actively manage your site you probably don't need to, you can just overwrite the base install and then run updates.php (always taking pre- and post-update backups).

Furthermore, you shouldn't really ever edit the base Drupal install, if you need to modify base functionality, you should write a new or use a contributed module which would exist in sites/all/modules/* or sites/* - again folders that will not be overwritten or modified by updating Drupal.

As mentioned previously in another post, the only files that may need to be backed up are things like your .htaccess or robots.txt files - but if you're editing those you know enough to backup your work anyway.

There's been a lot of very serious security patches released between 7.10 and the current core, so I would very strongly recommend updating. You could even update to a sub-domain (if your install is standard, you only need to update settings.php with the new test database details) to check if anything breaks first - which is what I'd do in your case.

anicasmith’s picture

Thanks for instruction, how about drupal security risk?Have the drupal team taken all neccesary steps to overcome it.
Fortune Innovations, based in Birmingham offers web design in Joomla, WordPress, Drupal, and Ecommerce Magento, Mobile app development for Android, iPhone and GDS Reservation system with SEO features.

MarkGoldfain’s picture

This guide is pretty clear and straightforward.
Except I find step 7 to be vague:
" If the update release includes changes to settings.php replace old
settings.php in .../sites/default/ with the new one, and edit site-specific
entries (eg database name, user, and password) "
It would be nice to have a description of precisely how to determine if the
update release includes changes to settings.php.


Chasen’s picture

If you view the release notes for the new Drupal version as they are released there is a statement about whether the .htaccess, robots.txt, settings.php, etc. files have been changed.

For example, see here: for the statement "No changes have been made to the .htaccess, web.config, robots.txt or default settings.php files in this release, so upgrading custom versions of those files is not necessary."

EDIT: For anyone wondering, you can view the release notes from the download page of any module/etc (eg by clicking the Notes link to the right of the download links. It's good practice to do this for all major (and potentially minor) updates as developers often put messages there about upgrade paths, major changes, potential issues, etc.

Vincent Verheyen’s picture

I updated to Drupal 7.34, following the exact steps described above.

However, my Drupal installation doesn't recognizes this update, and still states that 7.24 is installed instead.

Further more, before the update, I was advised to change a .htaccess file inside a (previous unexisting) directory called tmp in the root folder. I changed this file according to a prescription on this DrupalSecurityReport-site (where my Drupal hyperlinked to). Unsure about where to look, on this site, for the lines to be changed in the .htaccess; I changed the lines as prescribed by "For Drupal 7", a section of another security notice "SA-CORE-2013-003 - Drupal core - Multiple vulnerabilities"

After the update, this last advise to change such a .htaccess dissapeared, but Drupal still encourages me to update to 7.34 most of the time.

My file modules/system/<b></b> also reads version = "7.24", unfortunately.

Chasen’s picture

The easy question first - have you run update.php?

Uploading the files (i.e. the 7.34 files) is just the first step - to actually update Drupal's backend database you need to run update.php (DO BACKUPS FIRST)

If you have run update.php and it's saying there's no updates, I'm guessing your upload didn't work which is very likely a file permissions issue. Try doing the upload again but just upload one file and see if it actually uploads like you expect - some FTP applications make it look like it's uploading all the files but if you look at the logs each individual file is being denied access and the GUI doesn't necessarily make this obvious - but it still goes through the process for every file, making you think that it's working.

Do you have access to clone your existing site into a test environment (such as on your own PC) so you can try the whole process locally, removing the environmental factor of whatever web host you're currently using?

bribread22’s picture

Running update.php is one way updating your database. There's also a drush equivalent. The command is drush updb. This command and update.php will both invoke all hooks implementing hook_update_N(). For documentation on this, see:

You can also set configure automated/manual backups using the Backup and Migrate module.

Vincent Verheyen’s picture

Thank you very much for your comments. After repeating the normal update procedure, all went well. Sorry for the caused extra brain activity related to my complaint. :)

@Chasen - I wasn't using a hosting procedure to upload the new Drupal.

Natyer’s picture

using 7.34, on a local sever, also using mamp, well basically i have everything done i just cant seem to get the views to put out my content in grid format any ideas what this could be?

Chasen’s picture

This isn't a question you should be asking here, if the issue is specific to Views (i.e. data output or formatting for that module) ask on the Views Issue queue but I recommend you read their documentation first.

bribread22’s picture

An easier way to update Drupal core would be to open your command line application (i.e. Terminal or iTerm) and from your Drupal's site directory, enter cd sites/default.

Once you're in that directory, enter drush pm-update or drush up. That's all you really need to do to get your codebase updated quickly and hopefully without error.

Vincent Verheyen’s picture


GalaxyWeb’s picture

Problem with this method is once you delete all the files and folders...except for /sites folder as per step no 5, you website is broken until you add the new Drupal core. Not good if you get thousands of visitors on a daily basis.

I'd like to get feedback on this but I would say someone should create a custom maintenance page (built in HTML) called index.php and after putting the website into maintenance mode (as per step 4), overwrite the Drupal core index.php with the custom index.php. Then in step 5, delete all the files and folders... except the custom index.php and sites folder. In step 6, paste the new drupal core except the new index.php and sites folder. Once this is done, simply copy and paste the new drupal core index.php to overwrite the custom index.php. Then continue with step 7.

Does it make sens to anybody ?

mcfilms’s picture

@GalaxyWeb: The behavior you are looking for is built-in (in a way).

The Drupal .htaccess file includes the following lines:

# Set the default handler.
DirectoryIndex index.php index.html index.htm

This means, if the default index.php page is missing, the web server will fall back to index.html. So you could create a static HTML page that explains the site is undergoing maintenance and will be back in a moment.

If you really needed a PHP page, you could have the index.html page redirect to the php page.

You would just need to remember to not delete your static page when you delete all the other files.

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

GalaxyWeb’s picture

@mcfilms Thanks a lot. Just tested and of course it works like a charm. Definitely THE WAY to do it. Thanks again !!!

Chasen’s picture

Never noticed that myself (or considered that scenario) - good pickup

drupalnewie’s picture

Hi guys,

The steps went well for my site.

5. I didn't delete all the files & folders.
6. Instead i copy all the files, except the robot.txt htaccess and sites, and paste/replaced them into my site.
11. Instead i use drush to update the site #drush updb
12. I didn't understand the relevance.

14. I run another update command using drush to update only the security drush up --security-only.

So everything went well finally.

Thanks for the steps.


Android Tips’s picture

The problem is why there is no automatic update so we can only perform several clicks within dashboard and then viola we are using the latest version?

A 27 years old man living in the very comfortable zone on earth.

Chasen’s picture

See my earlier reply to a similar question here: