A symbolic link created using a PHP script is not displayed, but is it?

Question

My Symfony 2 installation is hosted on a shared host . Directory structure:

public |-- api // subdomain api.mydomain.com |-- app |-- bin |-- m // subdomain m.mydomain.com |-- src |-- vendor |-- www // symfony "web" folder | | | +-- app.php // front controller! 

The www folder is the main folder , as well as the folder in which the controller is located. It is limited to mydmain.com or www.mydomain.com . Subtrees such as m.mydomain.com or api.mydomain.com are folders inside the public one (i.e. m or api ).

I do not have SSH access, but only FTP (no SFTP). The problem is not about repeating the contents of www inside the m and api folders. If I copy all the contents from www to api (say), the front controller works , and I can work with subdomains in Symfony 2.

What I have tried so far:

Symlink Solution

Creating a symbolic api link to be placed in the www folder. I used the script file located inside the www folder:

 <?php var_dump(__DIR__); // /htdocs/public/www where script is executed $target = '/htdocs/public/www'; $link = '/htdocs/public/api'; if(file_exists($link)) { if(is_link($link)) { echo "unlinking $link..."; var_dump(unlink($link)); echo "symlinking $link to $target..."; var_dump(symlink($target, $link)); } else { exit("$link exists but not symbolic link\n"); } } echo readlink($link); // /htdocs/public/www correct! echo exec('cd .. && ls -l'); 

Output:

 /htdocs/public/www unlinking /htdocs/public/api... bool(true) symlinking /htdocs/public/api to /htdocs/public/www... bool(true) /htdocs/public/www drwxr-xr-x 7 nobody nobody 4096 Nov 25 18:57 www 

Created by Symlink, but (this is strange). I cannot see this connection via FTP or with the file manager (web) interface. The front controller does not work. Symlink is there, I get an error message if I try to create a folder with the same name as the symlink.

.htaccess solution

How can I route all requests for the api folder to the www folder (or from the api subdomain to the www subdomain)? This solution seems to me not quite right (why 301 redirection for GET /users api.mydomain.com )?

Answer 1

I have exactly the same configuration and it works! The only difference is that I map api.domain.com to www.domain.com/api instead of your site www.domain.com, so my api link points to www / api, not www.

.htaccess solution

You can use a modification of one of the scenarios described below so that you do not need a symbolic link :

/htdocs/public/.htaccess:

First enable the code to keep the HTTP / HTTPS protocol redirected (I will read this code for all my examples):

 RewriteEngine on RewriteCond %{HTTPS} =on RewriteRule ^(.*)$ - [env=proto:https] RewriteCond %{HTTPS} !=on RewriteRule ^(.*)$ - [env=proto:http] 

Redirect Code:

 RewriteCond %{HTTP_HOST} ^api\.domain\.com$ [NC] RewriteRule ^(.*)$ %{ENV:proto}://domain.com/api/$1 [L] 

This will redirect all api.domain.com/$1 requests to domain.com/api/$1 . Or you can just use http://domain.com/$1 if you want.

EDIT: if you do not want to hardcode the domain, you can use % N backlinks :

 # don't forget to use the HTTP/HTTPS handling code above RewriteCond %{HTTP_HOST} ^api\.([a-zA-Z0-9-]+\.[a-zA-Z0-9-]+)$ [NC] RewriteRule ^(.*)$ %{ENV:proto}://%1/api/$1 [L] 

Symlink Solution

I) Regarding the symbolic link, it is strange that you do not see the symbolic link via FTP. I see this in FileZilla as a directory (as if it were a hard link). Try installing FileZilla (and use explicit FTP over TLS for secure authentication).

II) Options +FollowSymLinks should be enabled, but in most hosting environments you cannot install it yourself . Depends on whether the hosting company allowed you this option on AllowOverride Options . You can easily find out:

• type Options +FollowSymLinks in /htdocs/public/.htaccess
• create a symbolic link www / foo.php pointing to www / app.php
• try to access foo.php
• alternatively, if the hosting provider gives you access to the server’s log, you can see if there was an error in the log.

If this fails, you should ask your hosting provider to either install Options +FollowSymLinks globally or allow AllowOverride Options globally.

Scenarios

I actually have 4 scenarios (you can check them online in my domain) using different methods (suppose the main directory is named / public, as in your case):

1) avif.birds.cz redirects to birds.cz/avif/(canonical) - a solution with a symbolic link

/ public / avif - a symbolic link to / public / www / avif

/public/www/avif/.htaccess:

 RewriteCond %{HTTP_HOST} ^avif\.birds\.cz$ [NC] RewriteRule ^(.*)$ %{ENV:proto}://birds.cz/avif/$1 [L] 

2) cap.birds.cz redirects to birds.cz/avif/some_url (no symbolic link required)

/public/.htaccess:

 RewriteCond %{HTTP_HOST} ^(www\.)?cap\.birds\.cz$ [NC] RewriteRule ^(.*)$ %{ENV:proto}://birds.cz/avif/cap_intro.php [L] 

3) (www.) Birds.cz/jpsp redirects to jpsp.birds.cz (canonical)

/ public / jpsp - symbolic link to / public / www / jpsp

/public/www/jpsp/.htaccess:

 RewriteCond %{HTTP_HOST} !^jpsp\.birds\.cz$ [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^(.*)$ %{ENV:proto}://jpsp.birds.cz/$1 [L] 

4) www.rorysi.cz - an alias domain served by the same tree (rorysi.cz should remain as a canonical domain)

The PHP source for this domain is different, placed under / public / www / rorysi.

/public/www/.htaccess:

 RewriteCond %{HTTP_HOST} ^(www\.)?rorysi\.cz$ [NC] RewriteCond %{REQUEST_URI} !^/rorysi/ [NC] RewriteCond %{REQUEST_URI} !=/rorysi [NC] RewriteCond %{REQUEST_URI} !^/lib/ [NC] RewriteRule ^(.*)$ %{ENV:proto}://www.rorysi.cz/rorysi/$1 [L] 

Note: the lib directory contains PHP libraries and embedded materials, so I do not want this to be redirected.

Perhaps some of these scenarios may be helpful or inspiring to you.

Answer 2

1) Make sure you have

 Options +FollowSymLinks 

in your .htaccess file.

Answer 3

This may be virtually impossible if modification rights are too limited in your web SP. You need to test the solutions one by one to make sure they work. First, check the permissions on your .htaccess files, since servers usually require very strict permissions on them, and if this is not agreed upon, the .htaccess file is ignored.

If, after checking .htaccess access, your web SP still does not allow you to change the symbolic link, for example, apoq wrote, I would check the following in the following order:

• First you need to check the rewriting, as Thomas wrote.
• Secondly, try an alias and scriptalias, since the alias will only work on static content and scripts need their own alias rule.

But since they all depend on the allowed things that need to be changed in your own .htaccess files, you are not allowed to change anything through the .htaccess files.