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.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Installing SilverStripe /

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

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

Installation on public web hoster

Go to End

7 Posts   3969 Views


Community Member, 3 Posts

26 March 2010 at 11:20pm

Edited: 27/03/2010 12:03am

Hi there!

I tried to install Silverstripe on my account. I followed the installation steps described on your site, but when I accessed the first time the folder where I copied (by FTP client) the locally unpacked files I got:

Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/data/multiserv/users/237215/projects/279827/www/.htaccess/_config.php) is not within the allowed path(s): (/data/multiserv/users/237215/projects/279827:/var/tmp/multiserv/users/237215/projects/279827:/data/apache/users/ in /data/multiserv/users/237215/projects/279827/www/sapphire/core/i18n.php on line 1739

I tried to call the install.php directly and it opened the installation site. I put in the necessary data and the checks were all green, except the one advising me to give PHP more memory.. but it wasn't an error, just a warning.

So, I started the installation. I got again the above mentioned error message.

Accessing my site (, you can see that part of installation was successful, but something went wrong(?) as you can see.

Any ideas?


Community Member, 63 Posts

29 March 2010 at 9:58pm

This is happening due to the value of the open_basedir being set in the php configuration.
This may be solved by editing the php.ini file, by changing the value of open_basedir or commenting it out.


Community Member, 8 Posts

30 March 2010 at 4:49am

Edited: 30/03/2010 4:51am

At a quick glance, this is probably a bug in PHP or Silverstripe (or both, depending on your viewpoint), but not a fatal one. Your installation should be okay.

I don't know the specific internals of Silverstripe, but as it seems it tries every directory-entry of the installation's root, whether it contains a file named "_config.php". Some of this directory entries are actually files and not directories, like ".htaccess" or "UPGRADING", so they cannot really have children. Since all the mentioned files in the warning messages on your website, which are declared not to be in open_basedir, are actually in open_basedir, this might be a faulty and misleading warning message on behalf of PHP and lazy (but not necessarily wrong) procedure on behalf of Silverstripe.

Anyway, you can help yourself by deactivating the PHP warning messages. This might help you: Documentation: php.ini display-errors

Try this method first:
If it fails, try this method at the beginning of "sapphire/main.php":

If you can confirm what I am saying, you might want to enter a bug report into the Silverstripe trac system (and at


Community Member, 3 Posts

9 April 2010 at 9:22am

Edited: 09/04/2010 9:57am

First of all, sorry for my late answer.. I was on holiday. ;-)

Thanks for your replies. It is in fact the problem that Silverstripe misstakenly assumes these files would be directories. Therefore, I will follow your recommendation and report that bug.

Anyway, I tried your tips (configuring E_ALL & ~E_WARNING), but neither editing the .htaccess file, nor editing the sapphire/main.php, worked for me (see below). On a refresh of the website the warnings are still there. Maybe I put my line on the wrong position within the file.


php_value error_reporting 30717

<Files *.ss>
Order deny,allow
Deny from all
Allow from

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_URI} !(\.gif$)|(\.jpg$)|(\.png$)|(\.css$)|(\.js$)

RewriteCond %{REQUEST_URI} ^(.*)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* sapphire/main.php?url=%1&%{QUERY_STRING} [L]


ini_set('error_reporting', 30717);



Community Member, 8 Posts

9 April 2010 at 10:49pm

About the .htaccess: Your provider might not allow this.

Concerning your main.php, you did right by putting it right at the beginning. But you can try this:

print "status ini_set(): " . ini_set('display_errors',0) . '<br/>';
print "state display_errors: " . ini_get('display_errors');

You should see something like that, if everything is good:

status ini_set(): 1
state display_errors: 0

If so, just leave:


You can try similar for the 'error_reporting' variable instead of 'display_errors'.

Anyway, it is not common to run PHP in a productive environment with warnings on -- this is for development or testing. So you may be able to convince your provider to change that or help you in your particular case.

I think this is a good read in your situation: turn off error reporting on your production site.


Community Member, 3 Posts

10 April 2010 at 5:01am

Edited: 10/04/2010 5:23am

I got the following output, including also the error_reporting (the value set by the hosting):

status ini_set(): 1
state display_errors: 0
state error_reporting: 22519

I further saw that applying the .htaccess approach mentioned of you is allowed, it outputs the right value set within .htaccess:

status ini_set(): 1
state display_errors: 0
state error_reporting: 30717

So, did I perhaps calculate the integer value in a wrong way?

Refering to, I want to calculate the value representing: E_ALL & ~E_WARNING

111011111111111 E_ALL (30719)
111111111111101 ~E_WARNING (2)
111011111111101 E_ALL & ~E_WARNING (30717)


ini_set('display_errors', 0);

...withing main.php makes the warnings disappear, but I prefer seeing errors. Hmmm


Community Member, 8 Posts

11 April 2010 at 1:27am

It's good to know, that at least the directives work. Maybe what you see is not considered a warning by PHP. Which would be weird, but nonetheless, try this error_get_last(). Something like:


Almost forgot: Put it at the end of main.php. This should give you your last error message, hopefully the warning ... and what ever you find under type, should be the bit you have to mask.