I'm a freelance Drupal developer who loves enabling organizations switch to free and open source software.
Working at the VRT I've had the pleasure of upgrading Toyinima from Drupal 4.6, 16plus.be from Drupal 4.7 and Studio Brussel from 5.1 to the newest Drupal 5.3. These were core-altered installations with a lot of custom and contribute-altered modules. I started of by dividing the non-core modules between those still in their original state to a "contrib" directory and those that were either completely custom or altered in a "custom" directory, to get the following tree structure:
/sites/all/modules/contrib
/sites/all/modules/customI must admit updating the custom modules went a lot faster than I imagined. Drupal 4.6 took by far the longest time with upgrading the forms to the FormAPI as well as updating the theme. What took the most time for all three sites was identifying the alterations done to core, what they were doing and how this could be moved to the modules and templates. The developers did a fine job documenting their changes to core, which made things a lot easier. Some of these changes were patches offered in the d.o issue queue (not necessarily by the module maintainers) as quick bug/security fixes, like this issue for the event module.
Two things to remember:
Upgrading Drupal is not a scary task. People refrain from upgrading because they fear it might fail and break their site. Keep your head cool and make an index of changes that need to happen: divide your modules in altered and non-altered versions, identify any changes made to core and take it one step at a time. There's plenty of good documentation to help you and people in the forum and on #drupal-support are waiting to help you on your way.
Once again, please don't alter core, don't even suggest altering core as a quick fix. The time you win by "fixing" the issue in this manner is lost twice when upgrading later.
Tweet
Comments
Location of custom modules
Instead of putting your custom modules in
sites/all/modules/custom, you might as well put them insites/yoursite.com/modules. Then you have an even cleaner separation.The problem you now face is that this won't work on your dev server, since that server obviously isn't hosted at yoursite.com. The solution is super easy: just symlink
sites/defaulttosites/yoursite.com(you can even do this in SVN), and then this will be picked up automatically. It's Steve McKenzie from Eighty Elements who taught me this :)Cool that you share this !
Cool that you share this !
I hope you also fixed this
I hope you also fixed this one http://drupal.org/node/157320 again while updating stubru.be. :-)
sites/*/modules/custom
Thanks for the tip. The important factor is creating a separation between non-altered and altered modules of course.
:)
Hey Luc,
With stubru.be already being Drupal 5.1 and Location Views being a contributed module, I didn't have to change/update it. Your fix is still in there ;)
Thanks
I just upgraded Drupal to 5.10 and I am getting this error on user profile pages:
user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 query: SELECT uid,name,picture FROM users WHERE status != 0 and uid != 0 and picture <> '' ORDER BY in /Volumes/MyQCA-Data/Webfolder/includes/database.mysql.inc on line 172.
Please help.
Check drupal.org support
It's best that you check the official support channels, you can find a list on http://drupal.org/support. Your best options are probably the drupal.org forum and irc.
Post new comment