Problem with installation on shared host

nginx
Tags: #<Tag:0x00007f10c92ea000>

#1

Silverstripe Version: 4.3.3

Question:

Hi,
I try to install SS on shared hosted server.
I got fail on Webserver Configuration
“URL rewriting support”

I red many post about it. Unfortunately any of then is no working for me :frowning:
Mod_rewrite is working - i checked this manualy.
.htaccess and index.php have 0664 permission

I can’t do this (link: SilverStripe | NGINX ) because I can’t configure server (shared)

I install via composer, but it has the same effect if I try to install from downloaded files from the page.

Please help…

// Include any relevant code. If you have a lot of code, link to a gist instead.

#2

Hi @suriq ,
Do you have composer on your server? If so you can install SilverStripe via composer https://docs.silverstripe.org/en/4/getting_started/composer/

I had a similar issue with my install, in the end I manually edited the .env file with the correct information and ran a dev/build, bypassing the install script all together.

An example .env file can be found in the root directory of your site (.env.example), mine looks like this;

SS_BASE_URL="-- BASE WEBSITE URL --"
SS_DATABASE_CLASS="MySQLPDODatabase"
SS_DATABASE_NAME="-- DATABASE NAME --"
SS_DATABASE_PASSWORD="-- YOUR DATABASE PASSWORD --"
SS_DATABASE_SERVER="localhost"
SS_DATABASE_USERNAME="-- YOUR DATABASE USERNAME --"
# SS_ENVIRONMENT_TYPE="dev"
SS_ERROR_LOG="silverstripe.log"

#3

Are you on nginx or on apache? Because the question is tagged nginx but from what I can see you are talking about apache.

  1. nginx does not have mod_rewrite (it has a rewrite feature but it is not needed anyway).
  2. nginx does not use .htaccess.
  3. nginx needs to be configured, so your ISP must provide a way to include some configuration snippet or you are not using nginx.

If you are under apache (and I bet you are) you should at least copy&paste your .htaccess and your index.php to limit the guesswork needed. The exact error line you get on the webserver logs would also help a lot.


#4

Thank You for Your answers.

@FrankenBunt ,
Yes, I tried to install using composer, got same problem.

@ntd
This is shared server and my hosting provider wrote “The Web server in MyDevil drives the efficient NGiNX. Additional modules enable using the “standard” .htaccess available so far only in inefficient Apache. It is possible to easily edit rewrite rules or autoindex templates”. Unfortunately my kung-fu is not strong enough and I don’t know exactly how to check it .

My clear installation is located on http://ssproblem.suriq.usermd.net/, feel free to check it.

‘Webserver configuration’ section says:
Webserver is not Apache 1.x -> OK (Apache/N-G-I-N-X-htaccess-support)
If nginx does not use .htaccess like you said I don’t have any idea that I have or have not nginx :confused:

I created a simple .htaccess file that redirects to another web address and worked, so I assume that mod_rewrite is supported correctly.

(all files were generated automatically - I did not make any changes to them)
.htaccess in public_html
RewriteEngine On
RewriteRule ^(.*)$ public/$1

.htaccess in /public
### SILVERSTRIPE START ###

Deny access to templates (but allow from localhost)

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

Deny access to IIS configuration

Order deny,allow Deny from all

Deny access to YAML configuration files which might include sensitive information

<Files ~ “.ya?ml$”>
Order allow,deny
Deny from all

Route errors to static pages automatically generated by SilverStripe

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

# Turn off index.php handling requests to the homepage fixes issue in apache >=2.4
<IfModule mod_dir.c>
    DirectoryIndex disabled
    DirectorySlash On
</IfModule>

SetEnv HTTP_MOD_REWRITE On
RewriteEngine On

# Enable HTTP Basic authentication workaround for PHP running in CGI mode
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# Deny access to potentially sensitive files and folders
RewriteRule ^vendor(/|$) - [F,L,NC]
RewriteRule ^\.env - [F,L,NC]
RewriteRule silverstripe-cache(/|$) - [F,L,NC]
RewriteRule composer\.(json|lock) - [F,L,NC]
RewriteRule (error|silverstripe|debug)\.log - [F,L,NC]

# Process through SilverStripe if no file with the requested name exists.
# Pass through the original path as a query parameter, and retain the existing parameters.
# Try finding framework in the vendor folder first
RewriteCond %{REQUEST_URI} ^(.*)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* index.php
### SILVERSTRIPE END ###

index.php in /public
<?php

use SilverStripe\Control\HTTPApplication;
use SilverStripe\Control\HTTPRequestBuilder;
use SilverStripe\Core\CoreKernel;
use SilverStripe\Core\Startup\ErrorControlChainMiddleware;

// Find autoload.php
if (file_exists(__DIR__ . '/../vendor/autoload.php')) {
    require __DIR__ . '/../vendor/autoload.php';
} elseif (file_exists(__DIR__ . '/vendor/autoload.php')) {
    require __DIR__ . '/vendor/autoload.php';
} else {
    header('HTTP/1.1 500 Internal Server Error');
    echo "autoload.php not found";
    exit(1);
}

// Build request and detect flush
$request = HTTPRequestBuilder::createFromEnvironment();

// Default application
$kernel = new CoreKernel(BASE_PATH);
$app = new HTTPApplication($kernel);
$app->addMiddleware(new ErrorControlChainMiddleware($app));
$response = $app->handle($request);
$response->output();

#5

:cry: One of the reasons NGiNX is so efficient is it does not use .htaccess. That would destroy performances: I would rather use apache itself instead, that at least provides standard (without quotes!) .htaccess support.

If you are using the public folder just ensure to follow the instructions for proper public support (it seems you already done that). Other than that I did not see anything wrong.

At the end the problem is not rewrite related or it is triggered by the “standard” (AKA custom) .htaccess support. From what I can see by accessing the URL you provided, it seems the rewriting is working properly but there is another error (request timeout? missing support for a feature? who knows…). In any case you’ll need to dive into the nginx logs to fetch more information.