By lekei on
I downloaded the "upgrade" (more like an alternate program replacement) version of Drupal. I have been holding on the site release for the last month, because the new version (alegedly) has image support.
Now I look at the so-called "upgrade" process and the the word "daunting" doesn't cover it. Will I be the developer who dies at the beginning of the episode to prove that the situation is serious?
The question is: Should I upgrade the site or throw away all of my work and start again from scratch?
It looks like there is little difference.
- Is it true that none of the existing modules will work?
- Is it true that all configuration data is lost?
- Is it true that all modules and themes must be deleted?
I wanted to do this before the end of the month but now I am scared.
Comments
Is it true? Yes and no.
1. Is it true that none of the existing modules will work?
3. Is it true that all modules and themes must be deleted?
Depends on your module loadout. Generally speaking, you might get lucky with an older module or you'll have to replace the module with an upstream version. Make sure to verify the upgrade requirements and procedures for each non-core module you use. In my experience, module upgrades are very simple:
Step 1: Disable all non-core modules
Step 2: Upgrade the site by following the documented procedure
Step 3: Unpack the new module in a directory below 'modules'
Step 4: Perform any module-specific upgrade procedures. You may have to manually review and update database tables.
Step 5: Enable the module again
Step 6: Double-check the permissions
This is really tedious more anything else.
Is it true that all configuration data is lost?
Not in my experience.
well...
As you may suspect, many contributed modules will need to be updated to take full advantage of the enhancements in Drupal 4.6. See http://drupal.org/project/releases for a list of contributed modules ready for 4.6.
Not as far as I know. This was not the case with my own upgrade.
Follow the upgrade instructions in the upgrade section of INSTALL.txt. If you have any customized modules, be sure to save a local copy of them and read http://drupal.org/node/12347 for instructions on updating from 4.5 to 4.6. Nothing major.
Read http://drupal.org/node/12352 for information about updating custom themes from 4.5 to 4.6.
--
Bjorn | choirgeek.com
Block settings
No, in my case only the "menue" module create a MySQL error but works fine.
No, in my case only the block settings
- "Enabled",
- "Weight" and
- "Sidebar" (left/right) of all blocks will be lost.
So I had to set this by hand.
No.
Thanks for the insight.
So reading these comments suggests that:
The only daunting thing is setting up the database. Since there still seems to be no set-up utility. Maybe I will spend a day and try again to get the shared database set-up working. Problem is that if future "Upgrades" are as insane as this one, it would be a lot of work to rebuild all of the web sites and databases.
Hmmm... the authors of Drupal love rarely used terms like Taxanomy, maybe they should look up the term "backward-compatability".
Perhaps I should learn to Mambo...?
Perhaps you should
I love the loaded manner of your original query. It has so many nice snarky asides that it was a fun read. I am sorry that I missed the original posting.
I didn't get this from the responses, but this seems to be a random leading statement.
All upgrades contain the need for checkout. Your results will vary. Please follow the Best Practices guide in the handbook to avoid issue's on your production site, it's why I wrote it.
Drupal is a CMS. A CMS is a very complex object and putting one together well for a site deployment is not really a simple thing. If it was, everyone would be doing it. There is a learning curve. Now part of the huge barrier is that you need to spend some time familiarizing yourself with the terminology. For example, Taxonomy has a specific technical meaning (http://en.wikipedia.org/wiki/Taxonomy).
In the Handbook under configuration is this nice article on how to set a home page.... http://drupal.org/node/15364 If that is in sufficient, there is a nice module named Front Page (http://drupal.org/project/front) for download that a site search shows up along with many threaded conversations about it.
I can setup the base Drupal install with the modules I use in less than 30 minutes. Building out and configuring a site takes longer as there is all that planning and designing that gets in the way.
The upgrade process has been the same for a long time now and it works fairly well. I upgraded the CVS build on my data several times during the development to test this and am casting about for the spare time to do this on my production sites now that the event module is released.
As to backword compatibility, I am running the same core site that I originally built on Drupal 4.4, ran through the upgrade to 4.5 and now plan to move to 4.6. I have 8 sites other sites (some originated as 4.4 others 4.5) that will be going through the upgrade script process as well. I cannot wait to go to the new site shared code base to ease this fun in the future.
As to contributed modules, well, Drupal has a nice module upgrade guide if the contributor of the module declines to provide an upgrade for the one you are using and you are welcome to contribute code/improvements back.
As to 'backward compatibility' I provide this link: http://en.wikipedia.org/wiki/Cruft
At this point you seem to have two options and it is really up to you which you will persue. Discard all the time you have spent learning a fast, secure CMS that has an active development community and find something that has a setup you are more comfortable with or stay and build on you inital understanding.
That decisian has to be yours to fit your needs.
-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
uh...
Any and all CMS package has a learning curve. Speaking for myself, I'm content with a well-documented manual setup procedure and I'd rather if the developers spend time on improving the core product than add eye candy. If a web-based setup tool is so important, perhaps you would consider contributring one?
You should also disabuse yourself of the notion that upgrading a production site using a CMS with third-party modules is a walk in the park. Drupal fares no better and no worse than any other CMS I have ever used. In fact, short of package ideosyncracies, what you call an insanity is standard operating procedure.