Minor Currently mod-rewrite mode (on/off) is ignored, when Front-End is viewed via
right frame in administrative console. This is no big deal, because all url
building methods build urls, that will work in both cases (with and without
mod-rewrite). But, with new rewrite listener approach (added in 5.0.1) we
could came across situation, when developer could create such rewrite
listener, that must be always present for customized urls to work. See
example provided below:
Example #1:
mod-rewrite off:
http://www.site.com/index.php?env=-path/to/template:m555--2--s-
mod-rewrite on:
http://www.site.com/russian/path/to/category/path/to/template.html
In example #1 such transformation to url happens:
- "
2" is language id, which is transformed to "/russian/"; - "m555" is category id, which is transformed to "/path/to/category/";
- "path/to/template" is just added to url's ending without
transformations.
In this scenario url parser/builder always could determine what url part is
transformed/parsed to what ID or any other environment variable ("env"
variable in non-mod-rewrite url) part.
Example #2:
mod-rewrite off:
http://www.site.com/index.php?env=-path/to/template:m0--1--s-
mod-rewrite on: http://www.site.com/completely/different/template.html
In example #2 only one transformation happens: real template named
"path/to/template" is replaced with nice (to create SEO urls) name
"completely/different/template", which of course doesn't exist on disk.
Using this approach only rewrite listener (which made transformation) knows
what real templates should be used for each of given virtual urls.
If mod-rewrite is turned off, then such url won't work (in case if someone
placed direct link to it). Based on my experience I could say, that, when
mod-rewrite is enabled on site, that it's never going to be disabled.
So, for large projects, when there is very complex url building/parsing
schemes it's hard to always track url compatibility between mod-rewrite and
non-mod-rewrite modes.
Based on all above I propose to use mod-rewrite urls even, when Front-End is
viewed in right frame in administrative console (see attached patch).