By eceleste on

OK, as a newbie to the Drupal world, I follow instructions to upgrade my Drupal installation. This installation was created by someone else, so I am not familiar with all the modules it uses, but I can follow instructions. What follows are my frustrations with the process of upgrading Drupal. These are meant to be constructive critiques, not knocks on the great tool that Drupal is.

I am useing UPGRADE.txt in v.6.9 as my instructions. The step numbers correspond to this document.

1. Easy enough, though why isn't there a "button" for this in admin? Isn't this part of good site mgmt practice. Also note, as a user of a host without SSH access (DreamHost), this step is non-trivial. I had to write my own PHP script to tar.z the whole ball of wax. I'd feel much better if backup were part of the core. I was truly surprised to find not even db backup in the core. I added the "Backup and Migrate" module, which at least handles db backup. But really, its like you are asking people to run a shoddy site if there is no facility for backup in the core system.

2. What's this UID #1 stuff? Why is a given uid number privileged? If there really is a special and elevated privilege, then declare that in roles and let us give anyone that role. This is silly as it is.

3. Good idea, poorly executed. Since it does not effectively warn admins of the fact that they are editing an "off-line" site, it is not very effective. I bet lots of Drupal sites have lots of core staff at the admin level. They should at least get a good yelling at by the system if they try to edit something off-line. I'd prefer that the super-user from #2 be the only one allowed to edit while off-line. Another reason to make that a role in #2.

4. Huh? Even theme's are bad news during an upgrade. This really makes the whole system feel a bit shaky. What if we use a core theme for admin, then can we leave our custom theme up for the main site? I assume so.

5. Easier said than done. Which ones are "custom and contributed". I assume the ones not in "module/"? But there is no indication of which ones those are on the module listing. I actually added four lines of code (one in common.inc and three in module.inc) to force a designation of "core" to appear in the list. Six of the "core" modules were not in the "Core" grouping (maybe because someone had accidently placed non-core modules in the "modules/" directory along the way?). Next problem: the inability to uncheck all these at once. Not only did I have to uncheck modules individually, but I had to do so FOUR times (layers of dependency made it impossible to do this in one, two, or even three rounds). This is beyond silly. There should be a way to at least uncheck all non-core at once. Even better, a way to memorize the "set" of modules selected so that they can be re-checked after update in a single click. To boot, is this even really necessary? I note that WP upgrades don't require disabling plugins. It has the feel, like #4, of Drupal being a bit shaky.

6. Really? Why not just all the Drupal files? I've got a few other local directories in here. And "sites/" and "files/" will just have to be put back. Isn't "files/" inside "sites/" anyway? Why mention "files/" at all? This is ripe for a bit of scripting, just remove the files that are part of Drupal, or is that really such a mystery that you don't know what is part of the package?

7. Simple enough, but eminently scriptable.

8. Again, why not just leave "sites/" and "files/" in place during an upgrade? Again, difficult for those without SSH access to files.

9. Uh, say what? To a newbie that's like saying "look around and see if you are in the right place" to someone who has never been somewhere before. More specificity might help. Are we looking for version numbers? You can't mean content since we are still running without custom modules or themes at this stage.

10. Reasonable, except for the uid #1 bit. It would also be better if Drupal recognized a mismatch between filesystem and db itself and defaulted to putting this upgrade request at the dashboard.

11. Won't this almost always never be the case? If I upgrade to 6.9, how many modules will say "6.9" on them. Should be clearer that a "6.x" designation would also be OK.

12. See #5.

13. See #4.

14. Reasonable.

A 14 step process made even longer by repeating #5 over and over again? This is a process only someone comfortable with a command-line could love. Steps 1, 3, 4, 5, 6, 7, 8, 10, 12, 13, and 14 could all be part of an autoupdate script. Is anyone working on that? If not, where do I submit it as a priority for the team? How can I help?

As I say, I'm a newbie. I'm sure a few months with Drupal will make the above process seem like no big deal. But it is a big deal for those who are new to Drupal. I just wanted to capture these frustrations for you before the edges wore off. Drupal is a wonderful system, bravo! I hope this critique can help make it a bit more accessible to new users out there.

⋅ Categories: Drupal 6.x

Comments

nicksanta’s picture

nicksanta commented

I'm not sure why there isnt any core backup / upgrade utilities, but i do agree that it is definately worth a discussion to include something like that in the future.

User 1 is the user that is created on installation. Take a look at user_access to understand why user 1 is special.

function user_access($string, $account = NULL, $reset = FALSE) {
  global $user;
  static $perm = array();

  if ($reset) {
    $perm = array();
  }

  if (is_null($account)) {
    $account = $user;
  }

  // User #1 has all privileges:
  if ($account->uid == 1) {
    return TRUE;
  }

  // To reduce the number of SQL queries, we cache the user's permissions
  // in a static variable.
  if (!isset($perm[$account->uid])) {
    $result = db_query("SELECT p.perm FROM {role} r INNER JOIN {permission} p ON p.rid = r.rid WHERE r.rid IN (". db_placeholders($account->roles) .")", array_keys($account->roles));

    $perms = array();
    while ($row = db_fetch_object($result)) {
      $perms += array_flip(explode(', ', $row->perm));
    }
    $perm[$account->uid] = $perms;
  }

  return isset($perm[$account->uid][$string]);
}

I'm assuming the core team doesnt think that in most drupal deployments there would need to be more than one user who has complete access to the whole site.

Basically (arguably), this is how you should set up a drupal file structure:
/modules
-- Core modules
/sites
-- /all
---- Contributed modules that are packaged with your install profile
-- /default
---- Custom and contributed modules that are added

----------------------
Nick Santamaria

eceleste’s picture

eceleste commented

Does this start sounding a bit circular and silly to anyone else? Anyway, with regard to #5 and #12, I just discovered the http://drupal.org/project/contrib_toggle module which claims to help with the disabling and re-enabling of contributed modules. I guess others are also frustrated with this task!

styro’s picture

styro commented

and also scary for newbies without any sysadmin or developer background. I totally agree with that.

But those instructions are also applicable to full version upgrades to new releases where the APIs for themes and modules have changed and you can break your site with the wrong theme or module, and there are DB schema changes in the upgrade process.

They are also overly conservative (especially for minor updates) and written for the lowest common denominator in terms of hosting environment or sysadmin skills - eg no assumptions made about what automation will or will not work for you.

On the contrary, I don't regard the somewhat pedantic safeguards as signs of a "shakey" system - more like signs of someone with a good solid engineering background (paranoid and thorough). Each step is there to prevent some (possibly rare) corner case that has bitten someone in the past - not listing them doesn't make the system more solid.

There are developers working on secure methods for updates, but they are also treading carefully and cautiously to avoid the myriad potential security holes that can opened up by webapps being able to update themselves.

I suggest doing a bunch of practice updates and upgrades on local instances to get a better feel for what you can leave out on your site (each site is different). And once you have the offical copies of the site files kept locally, you don't need to worry about backups etc - you just copy everything up. And it can be version controlled etc. There is plenty of scope to tailor the whole process to the way you prefer to do things.

I leave out most of the steps myself and it never causes any problems for MY site, but there's no way I'd guarantee it wouldn't hurt YOUR site.

My site has been though many minor and major upgrades from versions 4.4.x, 4.5.x, 4.6.x, 4.7.x, 5.x, and I'm working on a upgrade to 6.x (with major redesign to boot) at the moment. And upgrades are much easier these days :)

Note: The uid=1 thing is like the root user on unix, and making an admin role is like configuring sudo. There is a contrib module (called admin_role or something) floating around that automatically gives a certain role all the permissions if that is something you'd want.

tsvenson’s picture

tsvenson commented

I agree with most of the things you are writing. As I have just done my first updates to Drupal I got annoyed with the disabling and enabling of non core modules.

I started a discussion, http://groups.drupal.org/node/19560, in the upgrade group about having a Core Update/Upgrade mode in the Site Maintenance configuration that would take care of both disabling/re-enabling non core modules and change theme. I think that is the best place to discuss this.

I have added a link to this discussion as well as the http://drupal.org/project/contrib_toggle module. I haven't tried that module yet, but will next time a new release is available.

--
@tsvenson

stevenpatz’s picture

stevenpatz
he/him
commented

patches are welcome.