Hi, http://drupal.org/upgrade/ speaks about updates that *exclude* any contribs or custiom modules and themes. A general consensus is to upgrade without your custom code. Makes sense. Made sense, its getting hairy. With the new .install files and with the menu-a-primary links upgrades (requires to read the the prim/sec links, see http://drupal.org/node/49501) we have a problem, Houston. If I upgrade my site without my custom modules and themes: the proper code (par example the proper theme settings) are not read. Resulting in dataloss (redoing seven primary links is not /that/ much work, but still). If I upgrade my site with my custom modules and themes enabled and installed: the update will most probably fail because of PHP issues (like function not found: some_removed_core_function) If I cannot upgrade my site, I cannot upgrade my modules, because my (development) site needs to be upgraded before it can be a test-bed for my upgraded module. So, what to do? How to properly document this *before* the 4.7 release? I think this is purely a docs issue, its too late to fix this with code. My shot would be to say in the manuals: * For Developers and maintainers of modules: please use a clean database, and use the generate modules to create data to update and test your module with/for 4.7 * For Joe Schmoe: move all your stuff to a backup. Then put a new 4.7 in place. Then put the released 4.7 modules you had in 4.6 in your /modules. Then do the same for themes. Then run the upgrade. * For Consultants and hosts: find some fancy way with symlinks, secondary IPS, database hotcopies, and dev/test subdomains. If you cannot, you shouldn't be running such a host :) Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]