Optionally exclude htaccess from minor core upgrades

I'm thinking this should be "won't fix". It could be a security issue to skip modifications to htaccess. There should be a better way to notify about and include additions to htaccess on upgrades.

@jonhattan and moshe: Do you agree?

Seems unnecessary. If .htaccess is modified, I would think those modifications are best maintained in a patch applied post upgrade. Also, this only applies to those who don't have access to their vhost conf as modifications are best done there anyhow.

One can use a vcs or restore .htacess from backup after update. Also it can be programatically restored by implementing hook_pm_post_update() in a custom command.

We already warn about the update of .htaccess and robots.txt and I think it's up to the user to take this into account.

OK, right now, a new .htaccess gets copied in over the old file. Would you entertain a patch that handles .htaccess updates via diff/patch (if available on the user's system) rather than cp? Not sure if this is possible, but it may be.

You say 'if .htaccess is modified...'. Every site owner who cares about SEO (so the vast majority of sites) wants at least a www redirect to avoid what Google considers duplicate content. Simply automating the reapplying of any www redirect in .htaccess would be very useful, as it is the norm and important to have one of these redirects uncommented, but easy to forget to reapply it after an update. But maybe this should be a separate issue?

I think that the right solution here would be a post-updatecode hook in the examples folder that allowed the user to specify content (stored in a separate file) to append (or maybe append + prepend + regex) .htaccess or robots.txt after a minor update of Drupal. The example should be careful to avoid running unless Drupal was updated, lest the same info be appended twice.

I don't think that diff/patch is a good idea, as it is too fragile. If you want to automatically patch after every updatecode, please see #392762: Kitten-o-matic.

As an alternative, here is one workflow that could easily be implemented in a script to restore your customizations. (This is a longer version of reply #3 above.)

Preconditions:

1. Check Drupal root (or, as I prefer, directory above Drupal root) into git on master branch.
2. Create a new branch 'production'
3. Apply all core modifications (e.g. .htaccess edits); commit to 'production' branch

To update core:

git checkout master
drush pm-updatecode drupal
git add .
git commit -m "update to Drupal version ..."
git checkout production
git rebase master

(n.b. above command sequence untested, but that should be about right.)

This works sort of like kitten-o-matic, except if you have a merge conflict, you have your git working tree and all of your usual git-based merge and restore tricks available for modified file tracking goodness.

Leaving drupal htaccess as default and placing modifications in vhost conf is an awesome idea... why didn't I ever think of or hear of that before?

@John_B: I agree, having the option of redirecting to with or without www in front of a domain is important. As mentioned above, you can do redirects in the VirtualHost configuration, as an alternative to in the .htaccess file. I prefer to do it in the already existing sites-available file, which I already have anyway, for example /etc/apache2/sites-available/example.com:

<VirtualHost *:80>
    ServerAdmin info@example.com
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /srv/www/example.com/public_html/
    ErrorLog /srv/www/example.com/logs/error.log
    CustomLog /srv/www/example.com/logs/access.log combined

    RewriteEngine On
    # To redirect all users to access the site WITHOUT the 'www.' prefix,
    # (http://www.example.com/... will be redirected to http://example.com/...)
    # uncomment the following:
    RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
    RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301]

    Redirect /favicon.ico http://example.com/sites/all/themes/exampletheme/favicon.ico
</VirtualHost>

I found a better solution at Pantheon, where the redirect is done in the settings.php file:
http://helpdesk.getpantheon.com/customer/portal/articles/368354

This is a modified version, without the Pantheon specific stuff, just put it in your settings.php. It will also work for sub-pages, like www.example.com/about:

// Remove WWW
if ($_SERVER['HTTP_HOST'] == 'www.example.com') {
  header('HTTP/1.0 301 Moved Permanently'); 
  header('Location: http://example.com'. $_SERVER['REQUEST_URI']); 
  exit();
}

Perhaps this, along with the opposite option (non-www to www) could be moved from .htaccess into settings.php, and you just uncomment the one you want?

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.

@see https://github.com/drush-ops/drush/issues/614

The simple solution is to write all of your .htaccess customizations into a .htaccess_custom file in the site's webroot. After the core update, cat the .htaccess_custom to .htaccess

i.e.

cat .htaccess_custom >> .htaccess