Mod-rewrite mode is ignored, when Front-End is viewed via right frame in administrative console

1 view
Skip to first unread message

Alexander Obuhovich

unread,
Dec 15, 2009, 7:15:47 AM12/15/09
to In-Portal Bugs
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).

--
Best Regards,

http://www.in-portal.org
http://www.alex-time.com
admin_rewrite_urls.patch

Dmitry A.

unread,
Dec 16, 2009, 11:45:03 AM12/16/09
to In-Portal Bugs
Hi,


Yes, this seems to be the case - we haven't think about this before...

Did you came across this problem in one of your projects already?


File a task here:

445: Enable Mod-rewrite for Front-end in Admin

http://tracker.in-portal.org/view.php?id=445


Needs to be well tested, planned and committed.


Cheers!

DA


On Dec 15, 6:15 am, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> 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).
>
> --
> Best Regards,
>
> http://www.in-portal.orghttp://www.alex-time.com
>
>  admin_rewrite_urls.patch
> < 1KViewDownload

Alexander Obuhovich

unread,
Dec 16, 2009, 2:05:44 PM12/16/09
to In-Portal Bugs
Yes, most of the links in that project stopped working, while I was in
administrative console.

On 12/15/09, Alexander Obuhovich <aik....@gmail.com> wrote:
> 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
--
Sent from my mobile device
Reply all
Reply to author
Forward
0 new messages