[documentation] [Documentation bug] Error in upgrade instructions with respect to copying over .htaccess

Gary Feldman drupal-docs at drupal.org
Thu Jan 4 03:36:20 UTC 2007


Issue status update for 
http://drupal.org/node/106735
Post a follow up: 
http://drupal.org/project/comments/add/106735

 Project:      Documentation
 Version:      <none>
 Component:    Installation
 Category:     bug reports
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  Gary Feldman
 Updated by:   Gary Feldman
 Status:       active

On http://drupal.org/upgrade/downloading-drupal-command-line, it says to
copy .htaccess from the backup of the old site into your new site.  The
problem with this is that the newer version of Drupal may have
introduced additional items in .htaccess that are also required.  For
example, 4.7 added tpl.php to the list of file types that are blocked
(see http://drupal.org/node/58647).  If you copy over the old .htaccess,
you'll lose this bug fix.


Unfortunately, I don't think there's a simple way of dealing with this.
 The most reliable approach would be to compare your backup .htaccess to
a pristine copy for the same version.  If there are no differences, then
just use the new version, and don't copy the one from the backup.  If
there are differences, then edit those differences into the new version.
 This approach assumes some expertise in .htaccess configuration.


A simpler approach might be to just copy the  section from the old into
the new, replacing the corresponding section in the new one.  This
assumes that the index.php?q syntax is here to stay, so that there won't
be any changes to this part of .htaccess on the Drupal side of things. 
It also assumes there are no local changes to the rest of the file. 
This is based on the idea that commonly the only thing changed locally
in .htaccess is the RewriteBase line, and that anyone who has changed
any other part of the file knows what they're doing.


Perhaps someone can come up with a better solution, though I suspect
.htaccess will be a pain forever.




Gary Feldman



More information about the documentation mailing list