Allow vhost rewrite rules

I think it makes sense but I would recommend to change in the comment. Saying "Use custom rewrite rules defined elsewhere." might freak people about security issue but what it actually does is :

"This forces the current configuration to inherit the configuration of the parent. In per-virtual-server context, this means that the maps, conditions and rules of the main server are inherited. In per-directory context this means that conditions and rules of the parent directory's .htaccess configuration are inherited." Apache docs

So a comment like. "Use custom rewrite rules defined in vhost settings. Those rules are applied after rules defined in this file."

The handbook suggests http://drupal.org/node/138889 putting Inherit in your vhost config directly. It seems there's nothing to do here.

Instead of a blog post you need to write an issue summary. The documentation on this option is entirely unclear:

This forces the current configuration to inherit the configuration of the parent. In per-virtual-server context, this means that the maps, conditions and rules of the main server are inherited. In per-directory context this means that conditions and rules of the parent directory's .htaccess configuration are inherited.

I simply supposed that slapping RewriteOptions Inherit into your vhost configuration applies to the whole vhost. Hardly an unreasonable thing to suppose... What you are saying is that this is not so? Then say just that and be done. We have a core issue queue for these things. Slamming me for this on twitter and a blog post is absolutely the wrong thing to do.

Maybe commented out? Because if you add an option that is not recognized by Apache it freaks out.

I wholeheartedly second this patch. Currently, we have a use case that requires an additional rewrite rule to be placed in .htaccess for it to work. This is obviously a terrible idea as 1) it's hacking core, 2) every time core is updated we have to remember to re-apply the rules.

I could settle for using this patch but again...ever core update I'd have to remember to re-apply. Any ideas???

From http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriteoptions:
Inherit

Rules inherited from the parent scope are applied after rules specified in the child scope.

InheritBefore

Like Inherit above, but the rules from the parent scope are applied before rules specified in the child scope. Available in Apache HTTP Server 2.3.10 and later.

If we add InheritBefore, one can make additions to the rules in the .htaccess file with your vhost file.
If we add Inherit, one can make additions and changes to the rules in the .htaccess file with your vhost file. (As the vhost file rules are now applied after .htaccess, one can override what the .htaccess file says)

I would argue that Inherit is a better option. Among the limited advanced users that will have a vhost file, what reason is there to limit their ability to potentially overwrite changes in the .htaccess file?

While I agree that it's a useful feature, I believe this is the wrong approach to take to solve the type of issues in #8. There is a far more generic solution to that in a make-file for example.

I can't see how this is a bug though, so I'm setting to feature request.

I haven't done Apache inherit rules myself. I thought about it in terms of programming inheritance, but actually, "inherit" doesn't inherit, it prepends (inherit) or appends (inheritbefore) rules, which is quite different.

My comments in #9 with regard to Inherit vs InheritBefore should be ignored. Patch in #7 looks good.

Is this something we can write tests for? Do we have the capability with the test bots to setup different vhost files?

Just as an aside, using Drupal 7 I was able to use hook_url_inbound_alter() and preg_match() to simulate a rewrite rule. Not as optimal as a true rewrite but it did satisfy my immediate need.

Is it still an option to do this? With composer being used, I suspect it might for some use cases be needed more now than before.

Just to confirm: Patch from #7 still applies to 8.5.x-dev.

The patch still applies

The .htaccess file is a file where we expect user modifications. I think the correct thing here is to add a commented out section like

  # If you want to inherit rewrite rules from a parent context uncomment the
  # following line: (Requires an apache version >= 2.3.10)
  # RewriteOptions InheritBefore

I run my dev set up in a virtual document root which means I have to change .htaccess and have to manage incorporating any changes to .htaccess that come from HEAD.

Also, could suddenly enabling this option on existing sites have unexpected repercussions?

Changes to .htaccess can be annoying and cumbersome. E.g. we have a build server that assembles our code, so we have to just use the .htaccess from drupal core as is. Same for a lot of people that use shared hosting.
This change has NO impact for existing users, none whatsoever. Unless you've already put rewrite rules in a htaccess file higher up, which would be a very strange scenario ... :)
This allows you to put rewrite rules in another .htaccess file in a folder higher in the folder hierarchy of the server, which is otherwise impossible. ALL other htaccess items can already be put in such a htaccess file and just work. Also, the rewrite rules in the "other" htaccess file are applied before the rules in the drupal htaccess file, so the drupal access rules are still the "master".

Unless you've already put rewrite rules in a htaccess file higher up, which would be a very strange scenario ...

When you are dealing thousands or sites there is pretty much a case of every strange scenario. As pointed out in #22 .htaccess is meant to be customised and there is no way we can provide something that just works for everyone. But we should not change it to something that might break an existing site. For me we should improve the documentation in the .htaccess file and move on. If we want to do this otherwise we need to wait till Drupal 9 as there is no need to make a potential breaking change till then.

If you have a build server it could easily assemble your htaccess file for you.

I don't agree at all that this would break anything. And assembling a htaccess file on a build server is not something that can be done extremely easily. But fine, I haven't seen every user's setup.
One question though: how can we make sure this issue will actually be picked up for drupal 9 and not lie around for another 6 years. It'd be a shame to let a change like this lying around because it doesn't get picked up. And do we need additional documentation then on drupal.org in the handbook for this?

And thanks for responding. If i seem pissed off, it most likely is because I am, because we struggled with this for quite a while, and this would have been so helpful.

The way to move this issue forward would have been to implement the feedback from #22. That could still happen so marking needs work for that.

Composer scaffolding makes it a lot easier to manage .htaccess in git.

https://www.drupal.org/docs/develop/using-composer/using-drupals-compose...