branches/2.3 now optionally functions without mod_rewrite
54 views
Skip to first unread message
Sam Minnee
Mar 5, 2009, 4:17:07 PM3/5/09
to SilverStripe Development
Hi guys,
As part of a battle of getting SilverStripe to run on IIS6, I've
managed to get SilverStripe working without the use of rewrite rules.
Under such a scheme, the homepage of your site would still be
http://www.example.org/, but the about-us page would be at
http://www.example.org/index.php/about-us/
Here's how it works:
* phpinstaller/index.php is the file that control this. It replaces
index.html. If rewriting works, then index.php is never actually
accessed; instead control is passed to sapphire/main.php by the
standard rewriting rules.
* This means that if index.php is accessed, we know that rewriting is
broken and can act accordingly.
* As such, index.php sets a define (BASE_SCRIPT_URL) that changes the
Director::baseURL() value, and therefore the <base /> tag to something
like http://localhost/site/index.php/. It then mucks with the server
variables and includes sapphire/main.php, to get everything running as
normal. Mucking with $_SERVER variable is, generally speaking, a
little ugly, but sapphire/core/Core.php unfortunately assumes that the
executed script is in a subdirectory of the site root.
* This new base tag means that when there's a link like <a
href="about-us/">About us</a>, it will actually go to to
http://localhost/site/index.php/about-us/
* index.php can then extract the URL by comparing SCRIPT_NAME and
REQUEST_URI. It updates $_GET['url'] and $_REQUEST['url'] with the
calculated value. Again, this is a little ugly, but the goal was to
minimise the changes to core at this stage.
* The final issue is that *all* URLs would be accessed via index.php,
not just dynamic assets. So, index.php will throw a 301 redirection
if a file with the given URL exists. We use a redirection rather than
extracting and returning the content because I didn't want to
accidentally expose files that had been protected with a .htaccess
file.
The relevant changesets are here:
http://open.silverstripe.com/changeset/72495/
http://open.silverstripe.com/changeset/72496/
This is the most significant change for 2.3.1; I would like to get
some people other than me testing it ASAP. Fortunately, for
installations that are already using rewrite rules, the code changes
are very minimal. The bigger risk is that something doesn't work
correctly when using the new, rewriteless mode.
Testing would involve checking out http://svn.silverstripe.com/open/phpinstaller/branches/2.3
via svn, and commenting out the rewrite rules in the .htaccess.
Given that rewrite rules seem to be a common cause of frustration for
new users, I believe that this will help get users started with
SilverStripe more quickly, as well as enabling deployment to server
environments where the no rewriting system exists.
I look forward to your feedback!
As part of a battle of getting SilverStripe to run on IIS6, I've
managed to get SilverStripe working without the use of rewrite rules.
Under such a scheme, the homepage of your site would still be
http://www.example.org/, but the about-us page would be at
http://www.example.org/index.php/about-us/
Here's how it works:
* phpinstaller/index.php is the file that control this. It replaces
index.html. If rewriting works, then index.php is never actually
accessed; instead control is passed to sapphire/main.php by the
standard rewriting rules.
* This means that if index.php is accessed, we know that rewriting is
broken and can act accordingly.
* As such, index.php sets a define (BASE_SCRIPT_URL) that changes the
Director::baseURL() value, and therefore the <base /> tag to something
like http://localhost/site/index.php/. It then mucks with the server
variables and includes sapphire/main.php, to get everything running as
normal. Mucking with $_SERVER variable is, generally speaking, a
little ugly, but sapphire/core/Core.php unfortunately assumes that the
executed script is in a subdirectory of the site root.
* This new base tag means that when there's a link like <a
href="about-us/">About us</a>, it will actually go to to
http://localhost/site/index.php/about-us/
* index.php can then extract the URL by comparing SCRIPT_NAME and
REQUEST_URI. It updates $_GET['url'] and $_REQUEST['url'] with the
calculated value. Again, this is a little ugly, but the goal was to
minimise the changes to core at this stage.
* The final issue is that *all* URLs would be accessed via index.php,
not just dynamic assets. So, index.php will throw a 301 redirection
if a file with the given URL exists. We use a redirection rather than
extracting and returning the content because I didn't want to
accidentally expose files that had been protected with a .htaccess
file.
The relevant changesets are here:
http://open.silverstripe.com/changeset/72495/
http://open.silverstripe.com/changeset/72496/
This is the most significant change for 2.3.1; I would like to get
some people other than me testing it ASAP. Fortunately, for
installations that are already using rewrite rules, the code changes
are very minimal. The bigger risk is that something doesn't work
correctly when using the new, rewriteless mode.
Testing would involve checking out http://svn.silverstripe.com/open/phpinstaller/branches/2.3
via svn, and commenting out the rewrite rules in the .htaccess.
Given that rewrite rules seem to be a common cause of frustration for
new users, I believe that this will help get users started with
SilverStripe more quickly, as well as enabling deployment to server
environments where the no rewriting system exists.
I look forward to your feedback!
Sigurd Magnusson
Mar 5, 2009, 4:36:01 PM3/5/09
to silverst...@googlegroups.com
Great, Sam :)
(There's also a ticket, without much info, at http://open.silverstripe.com/ticket/3668
, in case we need to re-open it with a bug...)
In addition to Apache, IIS 6/7; if someone is able to test this on
lighttpd and zeus, that'd be great -- they are often raised as
problematic in our forums.
Sig
Normann
Mar 5, 2009, 11:30:12 PM3/5/09
to SilverStripe Development
Dose it potentially effect those hard coded sources in css files like
this " background-image: url(../../images/ImageEditor/clickBox.png);
"? though I am pretty sure it wont if the css file is not in the site
root folder which is mostly true.
On Mar 6, 10:17 am, Sam Minnee <sam.min...@gmail.com> wrote:
> Hi guys,
>
> As part of a battle of getting SilverStripe to run on IIS6, I've
> managed to get SilverStripe working without the use of rewrite rules.
> Under such a scheme, the homepage of your site would still behttp://www.example.org/, but the about-us page would be athttp://www.example.org/index.php/about-us/
this " background-image: url(../../images/ImageEditor/clickBox.png);
"? though I am pretty sure it wont if the css file is not in the site
root folder which is mostly true.
On Mar 6, 10:17 am, Sam Minnee <sam.min...@gmail.com> wrote:
> Hi guys,
>
> As part of a battle of getting SilverStripe to run on IIS6, I've
> managed to get SilverStripe working without the use of rewrite rules.
>
> Here's how it works:
>
> * phpinstaller/index.php is the file that control this. It replaces
> index.html. If rewriting works, then index.php is never actually
> accessed; instead control is passed to sapphire/main.php by the
> standard rewriting rules.
> * This means that if index.php is accessed, we know that rewriting is
> broken and can act accordingly.
> * As such, index.php sets a define (BASE_SCRIPT_URL) that changes the
> Director::baseURL() value, and therefore the <base /> tag to something
> likehttp://localhost/site/index.php/. It then mucks with the server
> Here's how it works:
>
> * phpinstaller/index.php is the file that control this. It replaces
> index.html. If rewriting works, then index.php is never actually
> accessed; instead control is passed to sapphire/main.php by the
> standard rewriting rules.
> * This means that if index.php is accessed, we know that rewriting is
> broken and can act accordingly.
> * As such, index.php sets a define (BASE_SCRIPT_URL) that changes the
> Director::baseURL() value, and therefore the <base /> tag to something
> variables and includes sapphire/main.php, to get everything running as
> normal. Mucking with $_SERVER variable is, generally speaking, a
> little ugly, but sapphire/core/Core.php unfortunately assumes that the
> executed script is in a subdirectory of the site root.
> * This new base tag means that when there's a link like <a
> href="about-us/">About us</a>, it will actually go to tohttp://localhost/site/index.php/about-us/
> normal. Mucking with $_SERVER variable is, generally speaking, a
> little ugly, but sapphire/core/Core.php unfortunately assumes that the
> executed script is in a subdirectory of the site root.
> * This new base tag means that when there's a link like <a
> * index.php can then extract the URL by comparing SCRIPT_NAME and
> REQUEST_URI. It updates $_GET['url'] and $_REQUEST['url'] with the
> calculated value. Again, this is a little ugly, but the goal was to
> minimise the changes to core at this stage.
> * The final issue is that *all* URLs would be accessed via index.php,
> not just dynamic assets. So, index.php will throw a 301 redirection
> if a file with the given URL exists. We use a redirection rather than
> extracting and returning the content because I didn't want to
> accidentally expose files that had been protected with a .htaccess
> file.
>
> The relevant changesets are here:http://open.silverstripe.com/changeset/72495/http://open.silverstripe.com/changeset/72496/
> REQUEST_URI. It updates $_GET['url'] and $_REQUEST['url'] with the
> calculated value. Again, this is a little ugly, but the goal was to
> minimise the changes to core at this stage.
> * The final issue is that *all* URLs would be accessed via index.php,
> not just dynamic assets. So, index.php will throw a 301 redirection
> if a file with the given URL exists. We use a redirection rather than
> extracting and returning the content because I didn't want to
> accidentally expose files that had been protected with a .htaccess
> file.
>
>
> This is the most significant change for 2.3.1; I would like to get
> some people other than me testing it ASAP. Fortunately, for
> installations that are already using rewrite rules, the code changes
> are very minimal. The bigger risk is that something doesn't work
> correctly when using the new, rewriteless mode.
>
> Testing would involve checking outhttp://svn.silverstripe.com/open/phpinstaller/branches/2.3
> This is the most significant change for 2.3.1; I would like to get
> some people other than me testing it ASAP. Fortunately, for
> installations that are already using rewrite rules, the code changes
> are very minimal. The bigger risk is that something doesn't work
> correctly when using the new, rewriteless mode.
>
Sam Minnee
Mar 5, 2009, 11:35:21 PM3/5/09
to SilverStripe Development
It should be okay, but it's worth testing explicitly.
Sigurd Magnusson
Mar 9, 2009, 4:37:01 AM3/9/09
to SilverStripe Development
Did anyone find issues with this? Please speak up... :) We're hoping
to have smooth sailing with this change...
to have smooth sailing with this change...
Hamish Campbell
Apr 2, 2009, 3:38:27 PM4/2/09
to SilverStripe Development
Just wanted to mention that I started using this yesterday and it has
made things considerably easier.
We still want the rewriting for live sites, but getting testing & dev
sites set up in a corporate environment was always a pain. This allows
us to just bang it up and start work, while the server guys sort out
the apache config.
Thanks!
made things considerably easier.
We still want the rewriting for live sites, but getting testing & dev
sites set up in a corporate environment was always a pain. This allows
us to just bang it up and start work, while the server guys sort out
the apache config.
Thanks!
Reply all
Reply to author
Forward
0 new messages