Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Installing SilverStripe /

Getting SilverStripe up and running on your computer and on your web server.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Friendly URLs No Longer Working - After Domain Change - (SS 3.0)


Go to End
Reply


13 Posts   1979 Views

Avatar
martimiz

Forum Moderator, 1105 Posts

7 August 2013 at 3:06am

Yes, I guess I would definitely ask my hosting provider if they see something funny going on...

As for baseURL(), you could simply, in your page controllers init() function, do something supersimple like:

public function init() {
   parent::init();
   ...
   echo "*** ". Director::baseURL() . " ***";
}

But apart from that - I don't really know. You could maybe mail(!) me a link to your site so I can see it happening...

Avatar
akuma6099

Community Member, 1 Post

9 August 2013 at 3:28am

Helloo, I just ran into this within the last few days. I was running SS 2.4.5 with no problems for a year. GoDaddy just updated Apache on my hosting server. I only have an Economy account with shared server space. Since then, Silverstripe has gone haywire and started adding /index.php/ to all my URLs. The first thing I did was backup everything and do an in place upgrade to 3.0.5. After running the dev/build?flush=1 the database rebuilt successfully. I still had the same problem. Browsing to www.sitename.com/ redirected me to www.sitename.com/index.php/welcome. This produced the generic page not found error. I setup a subdomain called testingsite and extracted a new copy of SS 3.0.5. Made a new database and performed the install. During the install I received a warning saying to have your web admin check the apache config and enable mod_rewrite..... I verified mod_rewrite is working correctly by adding "RewriteRule .* http://www.silverstripe.org [R=301,NC,L]" to my .htaccess. this redirect worked correctly. So I came to the conclusion that SS mod_rewrite autodetection needs a little patching to support the latest apache release. I will get version numbers later. The simplist fix is to make the adjustment in your .htaccess file. Here is what I modified mine too. Thanks go out to stanis.net for the fix.

### SILVERSTRIPE START ###
<Files *.ss>
   Order deny,allow
   Deny from all
   Allow from 127.0.0.1
</Files>

<Files web.config>
   Order deny,allow
   Deny from all
</Files>

ErrorDocument 404 /assets/error-404.html
ErrorDocument 500 /assets/error-500.html

<IfModule mod_alias.c>
   RedirectMatch 403 /silverstripe-cache(/|$)
   RedirectMatch 403 /vendor(/|$)
   RedirectMatch 403 /composer\.(json|lock)
</IfModule>

<IfModule mod_rewrite.c>
   SetEnv HTTP_MOD_REWRITE On
   RewriteEngine On
RewriteBase /
RewriteRule ^index\.php/(.*)$ /$1 [R=301,L]
RewriteRule index\.php / [R=301,L]

# RewriteRule .* http://www.silverstripe.org [R=301,NC,L]
   RewriteCond %{REQUEST_URI} ^(.*)$
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_URI} !\.php$
RewriteRule .* framework/main.php?url=%1 [QSA]

RewriteCond %{REQUEST_URI} ^(.*)/framework/main.php$
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule . %1/install.php? [R,L]

</IfModule>
### SILVERSTRIPE END ###

By adding the following:
RewriteRule ^index\.php/(.*)$ /$1 [R=301,L]
RewriteRule index\.php / [R=301,L]

you can force the removal of index.php. This is working perfectly for me now. All pages load correctly. Hopefully in the future SS autodetection will be working correctly. Hope this helps.

Avatar
martimiz

Forum Moderator, 1105 Posts

9 August 2013 at 4:47am

Yes, nice, I saw the other threads concerning the GoDaddy situation, that's why I asked. Not sure this is on GoDaddy though...

Avatar
ocean

Community Member, 37 Posts

13 August 2013 at 3:09am

Ok, I checked with the server guy and it is Bluehost.

I ended up fixing it by dropping the subfolder 'webroot' and putting everything into 'public_html' root with the SS .htaccess file and all is well : )

Luckily there is nothing else has to live in there so I had that option.

Just need to figure out now why 'Requirements::combine_files' is not working any longer since the move of domains. The 'combined.css' file is getting written into the correct folder so it looks as though permissions are ok, so for some reason it ain't getting picked up as part of template rendering?!?!? Next job :)

Thanks for the help and suggestions Martimiz!

Avatar
ocean

Community Member, 37 Posts

13 August 2013 at 3:13am

Hyper-duh!

As per last issue of 'combined files' -> I failed to put the _config.php back into 'live' mode.

Go to Top