I started this topic to describe my experience with upgrading from Drupal 4.5.0 to Drupal 4.6.0 (released yesterday). I hope others can comment on what they found here, so that it becomes a single reference for others trying to do the same in the future.
Let me state here that this was all on a test machine, using an exact copy of the files from my production web sites, and a copy of the database as well. This way, I will know what to expect when I upgrade my production sites, and have a set of instructions on what to do then.
As sepeck always says: "Test site! Always start with a test site!"
So here is what I did, and what I found:
Steps to upgrade
0. Make sure you are logged in to your web site using your admin user/password BEFORE you do the following.
1. Backup your production site. This involves backing up your public_html directory AND doing a dump of the database.
2. Make sure that you have done step 1. Really make sure!
3. Create a new directory and extract the Drupal 4.6 tar ball to it.
4. Create as many sites/sitename/settings.php files as you need (one per site), and aliases for www.example.com and example.com. Put in the database user name, password and database name, as well as the base_url. Add a db_prefix if you are using one database with multiple prefixes. Change the cookie_lifetime to the number of seconds you want users to stay logged in.
5. If you have modified the .htaccess, then copy the changes to the new one. Do not just overwrite the .htaccess.
6. Add a robots.txt if you have one. If you do not, then google for it and create one while you are at it.
7. If you have external directories with Drupal data in them, then move that directory to the appropriate place. For example, a files directory, a pictures directory, banners, ...etc depending on what modules you are using.
8. You can do steps 3 to 7 ahead of time, and then zip, upload and unzip to minimize downtime to your production web site(s).
9. Now point your browser to http://example.com/update.php, and follow the link there. Drupal should automatically detect from which date/version your database need to be upgraded (in my case this was "2004-10-31: first update since Drupal 4.5.0 release"). The database should be updated, with no errors on the results page. Repeat this step for every site you have. This is the third Drupal upgrade I have done, and this one went through without any errors reported.
10. If you have blocks that are only visible on certain paths (e.g. Ads that are not visible on the admin pages), then you have to add new parameters to each block. The new syntax is easier, and is well documented on the admin/block page.
11. As Dries mentioned, check which modules are enabled, and what permissions are enabled as well.
12. Check the permissions of any new directories that you created.
What works
I use the following modules, and they all seem to work fine:
- feedback
- sitemenu
- stock
- banner
- pathauto
- customerror
Issues
The only Drupal core issue I have seen so far is:
1. The workaround for blocks without titles mentioned here http://drupal.org/node/17170 does not work. This is a known issue http://drupal.org/node/11724 and I reopened it.
Some other issues with contrib modules I am using:
2. Banner module has a security error at each cron run. Here is the issue opened for this http://drupal.org/node/20608
3. HTMLArea does not work. Issue is http://drupal.org/node/20629
4. TinyMCE does not allow blockquote tag (but you can use the indent to do the same thing). Issue is http://drupal.org/node/20611 and has been closed.
Comments
thanks
good posting, esp for persons who will make their first upgrade. regarding the robots.txt see a page I wrote about SEO and drupal.
--
groets
bertb
--
groets
bert boerland
Good article
If you don't mind bert, I slightly edited it (adding pathauto and link to robotstxt.org, as well as 4.5 vs. 4.6 differences), and moved it to the Configuration section, where it seems to fit better.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Good stuff -- thanks!
'Nuff said.
Don't Get Me Wrong...
...I absolutely love Drupal - and I evangelise it to everyone I know. I have converted over 12 people and websites to use it. I use it heavily and value Drupal and what it does.
...but... I'm constantly amazed with the lack of concern to the people out there that actually use it, in regards to usability of upgrading both core and modules. I'm shocked that 4.6.0 requires essentially a "fresh start". That one has to log in with the "admin" user. That there is precious little actual documentation in the README or INSTALL files to define this "upgrade" (more like strip and rip) process.
I'm a smart guy. I've been managing *Nix systems since 1991. I've built the first USMC website in 1992. I've been building websites since. Drupal is by far the best system bar none. But it still is in it's infancy in usability from an administrators standpoint.
I wish I was a coder - because I really would love to redesign the process by wich the core code is upgraded, and by which modules and themes are managed and upgraded. I write my own modules, and almost every single upgrade forces me to rewrite things (either modules or themes). It drives me nuts.
I would like to ask if anyone out there has the skill, time, and energy - please focus on some "installer" methodology that would allow an admin like me the ability to essentially "click a button" to upgrade core/modules/themes.
I understand that the APIs change which means that themes and modules that are custom built can't be upgraded "automagically".
I spend more time futzing around with trying to upgrade things and rewrite core code that it's extremely frustrating. I have had less than happy with this process of continually forcing site admins to spend hours and hours of painful time trying to learn a dozen new intracacies of a minor point release. YES - I get that the core developers are doing "good things" for us, YES - I get that in some cases it's necessary to do this.
Like the subject says - don't get me wrong ... I love drupal, and I'm a huge supporter and have and will continue to convert many users. I won't be surprised if Dries deletes this posting.
Delete posting?
I won't be surprised if Dries deletes this posting.
Why would I delete this posting? It's on topic and offers constructive criticism.
Valid points
You raise valid points, and they have to be addressed by developers in future releases.
The install will get much easier in the future, because it will be automated. Not sure what is being planned with upgrades though. The update.php is good that it takes care of the database part.
The areas that have issues are :
1. Contributed modules.
2. Configuration files. This should now be more stable since the new format (settings.php under a directory), should not change any time soon.
3. Local modifictions. There will never be any easy solution to this, short of an automatic patch/merge thing. Unlikely.
4. File / Directory Permissions.
Did I miss anything?
Meanwhile, here is what one can do to minimize this to the least degree possible:
1. Keep a list of modules you installed
2. Keep a list of every file you modified or added (robots.txt, .htaccess, ...etc.)
3. If you change file or directory permissions, then also keep a list of what you did
4. Consult the above lists when you upgrade
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Wow - check the Gallery2 "install" mechanism...
I just installed the Gallery2 Beta 2 so I can try the new embedded Drupal gallery2.module. I'm stunned - the Gallery2 install mechanism is really nice. It's an excellent start.
I'm wondering if an installer like they built could be adapted to handle an install and *upgrade* of a Drupal system. Obviously, there are tons of g2 specific stuff in it, but it might be a great start?
I'm very impressed with what the G2 stuff is doing lately. Far and away Light Decades ...maybe... Light MIllenia beyond the image.module. No offense intended to the image.module folks - but gallery is definitely vastly far more "feature" rich.
Gallery 2 is easy to install
But it is also extremely difficult to remove. The permissions created by the installation process are very bad imho. Drupal should have an installer like that, but I urge keeping the ability to install it the old fashioned way as some of us like it that way.
---
Code Orange: Drink Your Juice
Agree
I agree. Although I haven't tried 4.6 in any real way yet, I've found the initial install process to be bad enough. The best tutorial I've found was on MacZealots.com; it was far better than any of the instructions I've seen on the Drupal site itself.
We should encourage people to set up secure sites from the start, with secured databases. I don't know what I'm doing with either MySQL or PostgreSQL, but I still want to be able to run a Drupal site. I'm comfortable with installing software via a command line, but there are those who aren't. I think it would be great if you could download Drupal, install it in the right spot, download the database software you'll use, and then connect to a Web page where you are walked through the setup process for the database and Drupal.
There should be a one-click install for upgrades. A button within the interface should allow an admin to download, install, and upgrade the new version without touching the filesystem directly. (Do we need signed upgrades? Probably.) A notice of major upgrades like 4.6 should appear on this admin page.
For small updates (4.5.x type updates), we should have the ability to do the install from within Drupal itself, perhaps even as a cron job so it happens automatically (optionally with approval by an admin). (Again, probably need to sign the updates.) Drupal should encourage people to keep the software itself up to date, as both Windows and Mac OS X now do. Automatic updates should be considered; this was a feature of Userland Manila in 1999. Granted, they were always breaking sites with it (some fringe, some wider breakages), but some forethought before releasing such updates could help cure that problem or at least reduce the chances.
If I knew enough to help out, I would, but I can provide input here on how I wish it would work.
--
Jeremy
www.jaharmi.com
Permissions kill install systems
The only thing that prevents Drupal from having a really good install system is the permissions on a standard set up. Typically, all those install wizards still require you to set file permissions on your site to 777 for a short moment while everything is installed.
This means that a completely automatic module/theme installation system inside Drupal is not going to happen soon: it would mean your site's permissions would have to be set to "insecure" all the time.
Still, we are working on an installation system which at least takes care of part of the work. But auto-downloaded modules and automatic updates aren't going to happen any time soon.
--
If you have a problem, please search before posting a question.
php in database?
Could php code be executed straight out of a mysql database? If it can be executed out of a database without a major performance hit, maybe part of drupal can just be a "bootstrap" to loading the rest of it from the database and allow for easy upgrading of it without having to make all files world-writeable.
and how would that impact
and how would that impact Drupal's use in postGRE?
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I think he is saying
I think he is saying that upgrading files is difficult, since we have to start from a fresh set, then apply whatever local modifications we did, then add modules, ....etc.
So, his proposal is to eliminate files and store the code inside the database.
Of course, there are issues with this approach. If the code is stored in the database, there would be a performance hit for sure, but it would not solve the problem he wants solved. The code in the database has to be upgraded too, and someone needs to know what changed and then delete or modify the existing ones.
We just move the same problem somewhere else.
Perhaps some sort of versioning can be the solution here. Not sure.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Fustrations
I just tried to update to 4.6 from 4.5.2, and found myself in a bit of a mess. I keep running into problems where there were new fields in the database that I need to manually insert. I don't mind doing that, but I would like to know what are all the new changes to the database and do all the changes all at once instead of having to go to different section of the website to find out what is missing. Maybe there's something I'm not doing I don't know. I used a prefix with my databases. I'm going to do a clean install on a different part of my server and play with it there.
Since I only started to play with Drupal for a few weeks, I don't have too much to loose, but I still would like to be able to do an update properly.
----------------------------
Margret Li
OxyFx Media
www.oxyfx.com
mli@oxyfx.com
Agreed -- DB upgrade for 4.6 is badly broken
I have a drupal 4.5.2 test site I tried to upgrade to the 4.6 release. I've been with drupal since 4.2, so hopefully I know the drill by now.
I disabled all third-party modules through the admin interface of 4.5.2, switched back to the pushbutton theme, moved all the 4.5.2 files out of the way, unpacked 4.6, customized sites/default/settings.php, and ran update.php (changed the userid=1 check to FALSE instead of logging in as that user).
The update.php page could not figure out which updates I needed, defaulting to "All". Why doesn't it know? I had the "legacy" module disabled previously--does that interact with it? What should I pick for upgrading from 4.5.2 to 4.6?
So I took several stabs at picking the right set of DB upgrade scripts. I picked the first 4.5.0 one, then tried 115, then 108, and others, dropping and recreating my 4.5.2 database between each attempt. Every single time, the upgrade scripts would not run cleanly, and the result was a site that throws SQL errors after nearly any clicking.
I preach drupal to lots of political groups out here, most of whom are flocking to Mambo to be honest. I don't like Mambo's default look and the code is not fun to read, but it installs simply. This continues to be drupal's Achilles heel, and I'm disappointed the upgrade to 4.6 is buggy.
I had a nearly identical
I had a nearly identical experience in upgrading my 4.5.2 site to Drupal 4.6.0. The update script did defaulted to ALL, I picked the first 4.5.0 point and executed the script. The script completed with no errors; however I have been receiving the following error message since then:
The error shows up as a user error after cron runs and after certain administrative operations such as changes to the Admin/Settings page. In each case, there are as many error messages as there are users. I posted this as a Drupal 4.6.0 issue two days ago, but have received no response to date.
I have the following modules loaded in addition to the Drupal 4.6.0 default modules:
I have tried searching for the referenced code fragment in several modules but can't find it anywhere. I am at a loss at this point regarding how to address this. I don't know if just reloading the 4.6.0 files will fix the problem, or whether this a database corruption issue that requires some other solution.
"It always seems impossible, until it is done."
- Nelson Mandela
UPDATE: Problem caused by Notify module
UPDATE: Problem was caused by Notify module. It turns out that the CVS version of the Notify module had a bug that caused the SQL errors. This is not a Drupal core bug or issue. Gerhard (Killes) will be posting an update to Notify shortly.
"It always seems impossible, until it is done."
- Nelson Mandela
Choosing update time manually and my upgrade experience
There is a table "variable" in Drupal database. There you can find update_start and associated value.
Why is update.php not working...
update.php shows me SQL error, that there is "variable" table missing. I have prefixed tables, so this may be the problem.
My own upgrade problems (4.5.2. -> 4.6. downloaded April 24. 2005):
update_start value in variable table shows me s:10:"2004-12-20";. This value was not present in update.php, so I tried to choose date after and before but both was bad. Upgrade proccess shows no errors, but I have missing tables and old table structures.
Missing tables: search_total, flood
Old structures: blocks, search_index
May be, there were more problems, but I give up upgrade and I will try it after several weeks and I hope these problems will be corrected. I really don't want to update database manually.
Update successful
Yesterday I posted msg above, that I was unable to upgrade database. Today, I finally succeeded. I choose database update from the first update of 4.5.0 and all database tables seems to be working fine.
Aggregator bundles in 4.4 interfere with upgrade
Don't know if anyone else has had this problem. I did the upgrade from 4.4.3 thru 4.5 to 4.6 following the instructions here to the letter. Everything seemed to be working fine until I added some rss feeds and new feed categories. Then, when I went to the administer section and clicked "blocks", the site crashed and I got this error message:
I could not fix it, and ended up restoring the old site with the 4.4 version using the backed up database. I upgraded again and had the same problem, when I reached 4.5 and went to the aggregator module, the site crashed.
I went back to the 4.4 version again, deleted the bundles I had set up in the aggregator; also disabled all unessential modules and blocks; and did the upgrade again. It seems to be working now.
So, take-home points: before upgrading from 4.4, disable as many modules as possible, especially any that were added on; if you have a lot of blocks running javascript and whatnot, turn them off; and delete rss bundles.
Andrew Schamess
The upgrade is too buggy
I just spend the last hour undoing the 4.5 -> 4.6 upgrade after it killed my site. Lesson to be learned -> don't jump all over a new release.
This is not helpful
It does not help much when you say that the upgrade killed your site. Please be more specific, so any bugs you encountered have a chance to get fixed in the future.
For me, the upgrade was almost flawless, and I also have 4.5, and I did it on three sites. I have problems with contrib modules, but Drupal core was a breeze.
Did you start with a clean set of files, and not copy over what is there? Did you create settings.php in advance?
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
I updated two sites
A few days ago I updated worldbeatplanet.com. The hardest part was converting to the new event module. Tonight I updated macmegasite.com. This one only took a few minutes and was easy since it doesn't use the event module.
In both cases, I tested the upgrade on my PowerBook using a dump of the original database and updated the live site only after testing it thoroughly.
--
Mike Cohen, http://www.mcdevzone.com/
What event module do you use?
I installed the RSVP module and it dies because it depends on event. rsvp is at 4.6 but event is not (or at least not posted).
Walt Daniels
I'd like to upgrade but fear the worst will happen
I'm excited at the prospect of seeing the developments made to drupal. I started using drupal about 4-5 months ago and began with 4.5.1 I found things very hard at the beginning and even posted some of those frustrations on this site. But it got easier in time and I reached a point where I was satisfied with my site powered by drupal.
However now is another turning point, I'd like to take a look at the tinymce module and the gallery2 module in 4.6 but I'm afraid I'll mess things up trying to upgrade. I think I could manage the complete reinstall of drupal from scratch but that would mean erasing all the data on my site that users have submitted as well as loosing user passwords etc.
This post is really to find out whether there are any other folk out there, on the low-skill end of things, who have already upgraded and if so how did they go about it?
Thanks.
FrancisQ
The Green Room
ARG
ARG! Read the link in my signature. Please, if you have a live web site, chances are you have a computer at home (or a friends you can borrow). A test site is EASY compared to blowing up your production site.
Remember, if your current site is working, you do NOT have to upgrade it right away. Whatever you do, test it first, it'll be good practices without important things going boom.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
private message and node privacy byrole modules
What is the status of these modules with regard to drupal 4.6?
I do not see them listed in the 4.6 module download section.
My site makes use of these two modules so I can't upgrade until these modules are available.
instead of node privacy byrole
try my nodeaccess module in my sandbox.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Node Privacy Byrole Module Available
Node Privacy Byrole Module is available. Download it from the download section. in few days i hope Private Message will also avilable.
God Admin
You should really strengthen that it is extremly useful to stay online with god admin when updating to 4.6. After loosing a database from 4.4 to 4.5 (my fault) I was wise and tested it on a backup system. I had to login into version 4.6 with the database imported from 4.5.2. A mess. I got a lot of errors but NO LOGIN. I tried to use ?q=user an managed to login and run the update. No error reported. Most things seem to work. A lot of translation were lost. I've done a restart. It's a test system. It doesn't run all day. But I couldn't even login as god admin after a reboot?!? Drupal 4.6 ends here.
Sorry, you'll may have your reasons to make those changes, but you didn't think a second about how an average admin can cope with it. I can't loose my database again. And if I have to, I'll switch to zope.
It is a minor change from 4.5 to 4.6 and that means that all my data and installation has to move without a loss. There are 2, in words TWO, lines of code to transfer from the old conf.php to the new settings.php. And you can't make it by script?
Why isn't there any import feature to get the nodes and user from old databases? You set them up. You know them. You make the changes. That would be the least point concerning "user friendly" for switching from one version to another. Just after doing it by script, without any interaction and without any loss.
You should have named it version 5.0.0 but never 4.6. I wouldn't wonder if someone will make a fork from 4.5.
Just another point of view from a user. After I get used to the new "logs" in 4.5.X (please don't call them anything even near statistics, they aren't, there isn't even a summary) this point has changed again completely and to no good.
NO! I don't upgrade my system to Drupal 4.6.0. As I said already, you may have good reasons for the changes and I really adore your work on Drupal 4.5.x. But you should start to look at and to focus on being "admin friendly". There are a lot of Drupal installations which can't restart from point zero! There has to be a way to do an upgrade without the actual problems.
Thank's for version 4.5.2.
It is not as simple as that
You should have logged on as admin BEFORE you started the upgrade. That would have saved you a lot of headaches.
No. It is not. A lot has changed under the hood.
It would move fine if you follow the steps I outlined. Perhaps some contributed modules caused the problems you are seeing. My test install went fine even thought I did not disable the contrib modules. Perhaps the ones I use are well behaved. Others have had problems with some contrib modules causing a botched upgrade.
It is not that simple. If it was, then said script would have been written a long time ago. If not by the core developers, then some power user.
Any application is a set of logic (programs) and a set of data structures (database and files). You cannot have one without the other. This is why Drupal has an update.php script that upgrades the database structure for you.
It is called update.php, and it does that. It upgrades the database in place.
You cannot import nodes from another database, let alone another version of the application. These nodes are written by users, and have comments attached to them written by other users. So, you have to import the users too. Users have roles, so this has to be imported as well. Nodes are in a hierarchy of categories, so you have to import that too. If you have url aliases, then you need those too, then there are sequences for everything (last used node id, user id, term id, ...etc.). See how it gets complicated very quickly? This is why we have update.php.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
I'll second what others have said
Best practices:
Given that hosts can go bad in a hurry, you should have automated backups of databases and files going to a local machine. And remember, it's not a backup unless you can restore it. If you can't clone a test site from your backups in less than the time it takes to load the database backup plus five minutes, you're in trouble.
Before embarking on any upgrade to a production system, always plan for having to roll back any changes made. If you have shell access and the disk space, in this case this means backing up the database and creating a directory tarball or copying the files into a backup directory.
Do not try an update on a production box for the first time. Clone your site to a test box and try it there first while taking notes. Unless your test box happens to very closely mirror your host's environment, the upgrade on the production system may still run into problems, but at the very least you can then blame anybody but youself.
Was this enough duplicated and unsolicited advice?
And I'll second what the detractors have said ...
... that you should not call it a "release" until you know it works ;)
These are all good points about backups, especially for those with the luxury to do such things, but on popular or long-lived sites on shared-hosting accounts, backups may not be completely feasible. Precarious upgrades are ok for pre-release or beta code, but IMHO (and only MHO) it's bad form to hold out code as production-ready and then post-hoc damage control by saying "you should have backed up your systems". That's a cop out, passing the buck for what was, essentially, bad QA. Let's instead take our lumps, admit that maybe we got a little tipsy on our own success and bragged a bit too much about our capabilities, and thank these trouble reporters for taking the time to complain because I'll tell you this for certain, those that complain here on Drupal.org are a minority compared to those who are out there suffering silently.
If a module does not work, it should not ship with the code. If permissions or events are problematic, they should be detected and removed or at least cause a stop in the process and a solid decision-required prompting. I've been reading this thread and the dozen or so others scattered about the help-forums here and frankly I'm embarrassed by it. My first thought is, yes, an embarrasement and guilt that I did not jump in on the 'beta' phase back when I could have made a difference pre-release, but also an embarrasement that pops to mind the phrase "jumped the shark".
With 4.6, has Drupal jumped the shark? And if so, who among us here is not to blame?
On backups and upgrades
Irrelevent but FWIW, I have been running Linux since 1992, and I have never ever done or retrospectively wished I'd done backups when upgrading the kernel, Apache, MySQL, OpenOffice, Mozilla, Sendmail, OpenSSH, DocBook or any of thousands of non-trivial emerging systems. I have been stung by Diald and pppd trashing prior config files, but the only app I use where my data is in real danger, even on a minor-number upgrade, is Drupal, and I think that's worthy of some serious attention if this thing is to join in the mainstream acceptance seen by those other apps I've cited.
Maybe what 4.6 is telling us is that 'upgrade' needs to be considered as a project module in it's own right?
Backups are your friend
No matter how good or how bad you think Drupal's upgrade procedures and scripts are, backups beforehand are essential -- even if you've tested the upgrade on a non-production environment.
Use "mysqldump" (or equivalent for other DBs) to back up your database schema and records, and use "tar" or "zip" (or equivalent) to back up the files under your HTML directory.
Then, if something goes dreadfully wrong, you can back out the upgrade and be back where you were.
Scott
Mysteries
I've run into some problems. I, too, had to guess at what version of database script to run. The upgrade script selected "all" even though this was an installation made January 30 of this year. I chose the last one before that.
Everything looks funky, as if the css files are not being read. The default bluemarine theme seems to work, but none of the others do at all. All phpTemplate-driven themes seem to be running without any theming at all.
In access control, I have received this error:
Fatal error: Unknown column 'severity' in 'field list' query: INSERT INTO watchdog (uid, type, message, severity, link, location, hostname, timestamp) VALUES (1, 'php', 'Table \'xxxxxxx.search_total\' doesn\'t exist query: SELECT t.word AS realword, i.word FROM search_total t LEFT JOIN search_index i ON t.word = i.word WHERE i.word IS NULL in /home/xxxxxx/public_html/includes/database.mysql.inc on line 66.', 2, '', '/~pingvco/admin/access', '00.00.000.000', 1114496156) in /home/xxxxxx/public_html/includes/database.mysql.inc on line 66(anonymized paths and IP)
I'm not sure what kind of field is to be inserted or I'd attempt to do it manually. Any insights?
This error also tells me that, apparently, I ran the wrong upgrade script after all. At least if there were some clue as to what the script is keying in on, we could browse our tables and find the pertinent date manually, if necessary.
As this is a rather lean site, I'm thinking of just starting afresh and loading in my theme. But I have another site running 4.5.1 with dozens of members, hundreds of nodes and increasing traffic. I'm dreading that upgrade now. And then there are the dozen or so other smaller sites. Ack!
With the guesswork involved in choosing a database upgrade script, this upgrade seems to be not quite ready for prime time, imho.
--
mediagirl.org
I discovered the problem
Unless you've run patches on your Drupal core, you should run the script for the earliest date of whatever release of Drupal you're operating.
More here: http://drupal.org/node/19095#comment-36691
--
mediagirl.org
a few more preparation guidelines
kbahey, great topic. I have put a link from the drupal handbook upgrade section (http://drupal.org/node/496) to this topic as it seems to contain the most appropriate info. It'd be good to write an 'official' help file for the handbook at some point ... :)
you might want to include the following points (which I, as a drupal thicky, learnt the hard way) in your 'guidance':
1. prepare your drupal45 installation by logging in as admin and:
- switch off all 3rd party modules in administer/modules/...
- switch your default theme to one of the standard themes such as bluemarine in adminster/themes/...
- stay logged in as admin.
2. using ftp, create a back ups of:
- your public_html directory (using ftp)
- your drupal45 folders and files (using ftp)
- your conf.php file (using ftp)(in drupal45/includes/...)
3. using mysql or phpmyadmin or shell create backup of:
- your database - both structure and data. (don't rely on the dba.module for this, as it only backs-up data, not table structure ... I think?)
ttfn
JohnG
upgrade by creating new site & importing data?
Would it be a viable option to simply create a new Drupal 4.6 site and import data from your old Drupal site? I could imagine some advantages to this.
This approach might make the most sense if you have a site with little usage and little data (as I do).
Is there a easy way to do this? Could I easily modify the DB migration code to pull data from an older database into a newer one?
Thanks!
Dave
I think that's essentially what the update is
The easy part of the update is to simply delete all the 'old' drupal php files, etc (all but your 'files' directory/repository) The hard part is updating the way your database tables are structured - which is what the update.php script does flawlessly (in theory)!
I don't know any thing about 'DB migration codes ... ?'
As far as I can see, unless you can afford to throw away all your data and rebuild the site from scratch, by re-entereing all your data by hand, you really need to run the upgrade.php script on it - and pray.
BTW it might be a headache to upgrade to 4.6, but it is worth it.
good luck
The core update never gave
The core update never gave me any grief; perhaps I'm lucky, perhaps it's just that well written. As opposed to that, I tend to run into problems with contributed modules that require changes to their database tables.
I found the module updates easy!
just goes to show you can only please some of the people some of the time!
For module installation, I cut&pasted the sql commands into the 'run script' tab in dbadim module - just to save having loads of programs logging in at the same time! It worked a treat, except one occassion when it spat out INSERT commands because it wanted {curly brackets} around the table name.
Having said that, I didn't bother running update scripts on modules, I just installed the fresh ones and added the tables as necessary. I didn't run into any 'old style table' problems, but that might just be luck. As module tables contain only 'config settings' not website 'content', the dataloss is pretty easy to repair manually if you end up overwriting old module tables - or at least in my case.
Well....
I didn't mean to imply that updating modules is usually an odious task. It just happens to be something that requires more manual intervention than the other upgrade tasks.
Convenient directory structure for updates
I structured my directory as public_http/sitename/(drupal files). This is where the site url points.
I uploaded the new drupal version into the public_http directory as public_http/drupal_4_5_0. This serves as the inactive site prior to database upgrade.
I backed up the database and saved it in a folder on my hard drive with a read me file specifying the backup date and the drupal version that was running that database.
I modified the conf.php file (in later versions, the settings.php file) to reflect the database url and http url.
When I was ready to run the upgrade script, I just renamed the "sitename" directory to "drupal_4_4_3" and renamed the "drupal_4_5_0 directory" to "sitename". This makes the new version into the active directory. Then I ran the upgrade script by pointing my browser to www.sitename/update.php.
This way I still have the directories containing the older drupal builds, until I know the new one is working (at which point they can be deleted). If something goes awry and I need to start the upgrade again from a prior version, I can just delete the database and restore the old one from my hard drive; rename the older version as the active directory ("sitename") and it's back the way it was.
Of course any data entered after the upgrade is lost - so it's best to play around and make sure the new site works before entering any data that's important.
Just a minor suggestion but I thought someone out there might find it useful.
Andrew Schamess
Module install process
I appreciate this topic. I have installed two 4.6 sites now. The first
was an upgrade and the comments listed already identify the problems
I had.
On the new clean site, I tried to get ALL of the modules and put them
into the modules directory and then turn them on.
There are several modules which are not happy with this.
Mostly the amazon* modules.
Secondly, it seems that Ihave to reduce the number of modules
before I could click on the admin->modules page
and have it work.
By moving
amazonsearch amazontools marksmarty smartypants
out, I was able to get it to stop erroring.
And by moving 24 others out.
commentcloser htmlcorrector paypal_framework smileys
currency jsdomenu paypal_subscription stock
foaf livediscussions poormanscron taxonomy_browser
folksonomy mailhandler privatemsg taxonomy_multi_edit
helpedit menu_otf recipe textile
hof nodewords simpletest trip_search
I was able to get into the admin->modules page.
It seems that a reasonable test case for drupal before releasing a
site is to load all the *.tar.gz modules and then
say: foreach i ( `cat */*.mysql ` )
mysql -u users -ppasswd database < $i
end
and all of the modules should be loaded into the site and should
marginally run.
I find that I can not do this. First 4 modules seem to need more
handholding
Secondly, there seems to be some kind of timeout problem or pause
problem that causes it not to work if there are "too many modules".
Is this something others have seen?
php memory settings.
php memory settings.
Drupal only loads the activated modules on the site normally, but when you hit the moudles page, it runs through every module and loads it into memory. You either need to increase your php memory space, or remove the core modules you are not using and do not need to run your site with.
I generally run my sites at 24MB of memory for php, but I also don't use a lot of modules that hammer the site. You will need to do your own benchmarking to see what the correct solution is for you.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Very hard to do
This approach of putting all modules that exist and then enabling them is a sure way for trouble.
Remember that these are contributed modules, and not core Drupal. The quality of some of them are hit or miss. Some are no longer maintained, some have conflict with others, some have other issues.
This is a sure way to get problems. Best approach is:
1. Install plain Drupal, create the database, then login and configure.
2. Do a few test posts, check that everything is running.
3. Add the contributed modules you think you need, a few at a time.
4. Do some test posts and make sure that everything is working.
5. Proceed with other contributed modules if needed.
This way, you can isolate problems when you see them, and know which module (or group of modules) caused them.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Vetting Drupal 4.6 modules
Is there any process or group or procedure in place to vet and
qualify drupal modules? IE, is there a way to know of the largest
set of drupal modules that will play together?
While I understand the process of adding modules one by one
in order to set up a clean and functional site. I also am starting
to do many site installs. And as I do this, I find that I wish for
a clean way to quickly get a base of services up and running.
And the base drupal is not sufficient for most of the sites.
It would be helpful if there were a Morning star style rating system
for modules, so I knew which ones played nice... The alternative
seems to crawl thru every module, during every release and
become an expert on every module that is available. And this is
more than a full time job.
Is there no regression testing mechanism for the modules as things
are changed around?
Nope. Such a rating system
Nope. Such a rating system has been discussed. You will have to dig through Drupal-devel archives to see the results. I think it's on the 'to do' list, but not high up. Contrib modules are contributed at the whim of the contributor. Their quality varies from module to module. Most will play well with each other and there are steps being taken to help encourage better play togetherness but that will evolve over time.
Once you have a base list of modules you use, then you can eliminate that testing time :). The base drupal install is enough for many many sites, but it is not meant to be for most sites. This is to help keep individual sites 'lean' and fast.
Regression testing is at the discression of the author. For core, there is a lot of testing.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
For selecting quality modules, look at bryght
While there is no vetting system (yet), you can use the modules selected by bryght - they have good quality. Bryght (based on drupal) also offers great implemention tips, most of them relevant to drupal. No, I am not affiliated with them in any way, just a happy reader..
Amnon
-
My Sites:
sakeret.com | hitech-dolphin.com | small-business-web-hosting-strategies.com
Upgraded three sites
Just in case anyone is following this thread, I successfully upgraded three live sites running off the same code base, using prefixes using the instructions on this page.
The reason for the delay was to resolve some issues with some contrib modules that I used.
It was very smooth and took about an hour to reconfigure permissions, block exclusion pages, converting from xtemplate to phptemplate (had to redo all the primary/secondary links in the theme, since the global settings are ignored), ...etc
Having a test site that you stage things on is really a necessity and a life saver.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Success except for article module
I upgraded succesfully my main site.
A secondary site has been quite a wasp nest.
I needed to manually insert a column in database (table watchdog, column severity) just to make the update process start.
After that all is right, except the behaviour of the Article module.
Now the visualization of the subcategories shows the articles too.
Before the upgrade:
http://www.semioticamente.it/versus/?q=article/numeri+della+rivista
After the upgrade:
http://www.semioticamente.it/dummy/?q=article/numeri+della+rivista
I'm wondering how to fix it.
Upgrade ok except update-image.php
Have had good luck w/ upgrade to 4.6 with one small and one large exception.
The small exception: I got the same sql error attempting to insert into watchdog that mediagirl got which is mention elsewhere in this thread. The field 'severity' was somehow missing in watchdog table. I manually added it via phpMyAdmin and all is well.
Now for the large exception. Image.module and the update are not working for me.
One problem I found was that the default setting in image is 'images/' and the trailing slash does not appear to be necessary. Looking at the table 'files' the paths all end up with TWO slashes. Not good.
But the big problem, even after fixing the slash business (drop all tables, load backup, start install from scratch) is that while the photo gallery throws up the titles, descriptions, etc., there are no images although they exist on the site.
I wrote this up fully at http://drupal.org/node/23417 (comment 8). If anyone has image and update-image.php working I'd sure like to know how you did it! Thanks in advance for any help.
- gil -
follow up for record.
As a follow up, it appears to have been a permissions issue per project bug report.
http://drupal.org/node/23417
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
project module upgrade problem
Running update-project.php (from site root) produces
Fatal error: Call to undefined function: variable_get() in /usr/sites/drupal/www/drupal/includes/common.inc on line 1892
Found the solution here:
http://drupal.org/node/17647
(added bootstrap.inc to common.inc as above)
Forums in 4.6.0?
Has anyone had difficulty getting forums in 4.6.0 to work? I tried a clean install and never could get it to work properly. I am not alone; see the topics below:
http://drupal.org/node/17379
http://drupal.org/node/21616
http://drupal.org/node/22960
http://drupal.org/node/20747
http://drupal.org/node/21994
http://drupal.org/node/21728