Resolved PHP sessions don't work because Plesk's PHP is used for one script, the server PHP for another.

[JBH]

I'm a fan of using URI paths to control websites. It's neat and clean, but after upgrading to Plesk 12.5 with PHP 7 it stopped working. So, rather than using example.com?action1=&action2=, I use example.com/action1/action2.

What happens is this. Any normal PHP files (e.g., example.com/index.php) are interpreted by Plesk's installation of PHP (specifically 7.0.19). This starts a session, stores some $_SESSION variables, and off we go. But as soon as I use my beloved URI commands, despite (e.g.) action1 being symbolically linked to index.php, it's processed by the server's installation of PHP. I eventually got that to PHP 7.0.20, but there are apparently enough differences between the two installations that one can't/won't read the other's session file. Some code:

ln -s index.php action1

index.php contains:

<?php
session_start();
if(TRUE) $_SESSION['test'] = 'successful';
print_r($_SESSION);
echo "<P>".session_id();
echo "<P>".phpinfo();

.htaccess contains

RewriteEngine On
RewriteBase /
AddHandler application/x-httpd-php .php
<Files action1>
SetHandler application/x-httpd-php
</Files>

Set TRUE and visit example.com/index.php. The $_SESSION variable is set. The session file is populated. Set to FALSE and we see the session file is read. My server's phpinfo() in this instance reports 7.0.19 (Plesk's).

Now visit example.com/action1. The variable disappears, but the session ID is the same. phpinfo() now reports the server's PHP 7.0.20.

Is there any way to ...

(A) force the server to use Plesk's install of PHP? This would have been easy but for an absolutely inexplicable reason Plesk 12.5 does not ship with libphp7.so for its PHP installation. Honestly, that's unbelievable. Or...

(B) force all HTTP calls to go through Plesk? That means after the .htaccess voodoo it's Plesk's Apache that's tapped and not the server's Apache. Or...

(C) Some other cool juju I haven't thought of.

It's taken me four days to get to this point and while walking away from my beloved URI paths is (an increasingly likely) option, I'm hoping it isn't necessary. Can anyone point out a way for .htaccess-modified URIs to use Plesk's Apache rather than the server's default?

THANKS!

 

[Bitpalast]

Nor has this anything to do with different PHP versions or Plesk versions, neither with a symbolic link in the file system or different PHP versions on the same domain processing the website data. Instead, it most likely is a result by a rewrite of your search engine friendly URL and two different domains (with two different PHP settings) involved. For web server requests, the web server always uses the PHP version that is configured for that specific domain. It is not possible that the web server is using a more than a single PHP version in the same virtual host. If you still see a different PHP version on different requests, this means that you are communicating with two different domains. That is most likely the case when the base URL changes amid requests.

PHP 7 and 7.1 have session managements just as 5.6. A session is stable as long as the base URL path remains the same. The session is re-initialized when the base URL changes, for example
from non-www to www version
from non-SSL to SSL version
from www version to non-www version
from SSL version to non-SSL version
If your URL rewriting is properly configured, the base URL stays the same, hence the session is detected correctly. However, if your base URL changes, the script that is executed cannot access the session of the other URL's processes, because from PHP's perspective, it is a totally different application that is running.

Further, there is not difference between "Plesk's Apache" and "server's Apache" as you are suggesting. There is only one Apache. But, yes, there is a difference between each virtual host in that Apache server, because each virtual host can have its own PHP setting. The same virtual host cannot have two different PHP settings.

Finally, in the unlikely case that you are indeed using "symbolic links" in the file system to create your search engine friendly URLs instead of using URL rewrite techniques, I suggest to change the strategy and use URL rewriting.

 

[JBH]

There's nothing like being patronized by an expert without an answer. I'm not calling different domains, or subdomains, or switching between SSL/non-SSL, or anything at all like what you suggested. Had you taken the time to run the test, you'd have seen that for yourself (assuming, of course, that the version of PHP you run from command line when you SSH into your server is different than the version that comes with Plesk). This once popular coding style worked like a charm for 20 years before my hosting company forced me to change to Plesk. Now it doesn't work. You're welcome to see the results for yourself (I'm making this as easy as I can for you):

phpinfo()
phpinfo()

"test" is a symbolic link to test2.php created as follows: "ln -s test2.php test". I strongly recommend you should trust me that I'm using a symbolic link. Also, the base URL path is the same because the two executions are receiving the same SID. Finally, the only thing(s) in my .htaccess are as shown in my original post. The ONLY thing happening is filenames not ending in .php are identified as executable PHP files.

Gratefully, and I'm sure unintentionally, you did provide one insight. I'm going to review the virtual host settings for this domain to see if there's anything that would get in the way of SetHandled files.

 

[Bitpalast]

Ok, I see. You may have found a way to run different PHP version's in the same virtualhost, and this could possibly be done by the handler definition, but not sure yet. I'll check into it later tonight. That is a very interesting feature if it works.

 

[Bitpalast]

You have indeed found a way to run different PHP versions in the same virtual host.

According to your PHP info page you are using PHP FPM. In that case the handler you have set is false, because it refers to another PHP instance. A possible solution for the handler construction you are using are these three steps:

1) Create or edit /var/www/vhosts/system/<domain>/conf/php.ini with at least this entry:
(Instead of "<domain>" enter your domain name, e.g. wwphelps.com.)

[php-fpm-pool-settings]
security.limit_extensions =

It is correct that there is only a single empty space after security.limit_extensions and no further characters. This needs to be set, because otherwise PHP FPM security settings will prohibit code execution of a file with an extension different from .php. When you call your symbolic link it does not have an extension, so we must unlimit the extension blocker first.

2) Reconfigure PHP-FPM, so that the settings from (1) apply. For example open the PHP configuration settings and simply click "apply" without any changes. It will re-generate the PHP FPM configuration file and apply the additional setting from step (1).

3) Modify your .htaccess file as follows:

Options +FollowSymLinks -SymLinksIfOwnerMatch
RewriteEngine On
RewriteBase /
<Files test>
SetHandler proxy:unix:///var/www/vhosts/system/<domain>/php-fpm.sock|fcgi://127.0.0.1:9000
</Files>

Instead of "<domain>" enter your domain name, e.g. wwphelps.com. The "Options" line should be added, because else in some environments the symbolic links will not be followed at all.

Now the symbolic link and the hard link, will use the same PHP version to run. I have tested this on my test server, and it does work on there. If this does not work on your system, look into /var/www/vhosts/system/<domain>/conf/httpd.conf and find the "<IfModule mod_proxy_fcgi.c>" block. It contains the correct handler definition for the PHP instance that the virtual host is using.

 

[JBH]

Yup, I just arrived to post this very same response. Cheers.