This is a continuation of Session_start fails to read session when /action1/action2 rather than ?action1=&action2= is used. The short form of this question is that I need the server's instance of Apache to point to Plesk's version of Apache. This would be trivial if Plesk's version of PHP7 came with the libphp7.so file. It does not. Therefore, is there...
A) A work-around that allows my server Apache to point to Plesk's PHP installation. Or...
B) A way to get Plesk's Apache installation to be the only web server on my server?
To give you the short version of the previous question. I prefer to use URI paths (e.g., example.com/action1/action2) to direct my programs. This is done by using the .htaccess file to allow a file, action1 to be interpreted as a PHP file.
RewriteEngine On
RewriteBase /
Action application/x-httpd-php modules/libphp7.so
AddHandler application/x-httpd-php .php
<Files action1>
SetHandler application/x-httpd-php
</Files>
What appears to be happening is any normal PHP file (e.g., index.php) is executed using Plesk's version of PHP. However, when .htaccess gets involved (executing action1, despite the fact that it's symbolically linked to index.php), suddenly it's the server's installation of PHP that's being used.
I've thought about trying to reconfigure my server's Apache server using Plesk's configuration, but just dragging the configuration out of Plesk is proving to be a daunting process.
I appreciate your input.
Problem solved, at least insofar as I'm willing to solve it. In the Virtual Host Apache configuration file we have...
<Files ~ (\.php$)>
SetHandler proxy:unix:///var/www/vhosts/system/wwphelps.com/php-fpm.sock|fcgi://127.0.0.1:9000
</Files>
This is how Plesk is specifically attaching one version of PHP over another by domain name. And anything that doesn't fall into this rule is interpreted by Apache's global rules, which for me are looking at a different install of PHP. (Why Plesk doesn't have a global override to point at their own PHP installs is a bit of a wonder, but I suspect this is a bug they've never encountered before.) So, logically, we'd need only add for each file we want to process without the .php suffix...
<Files action1>
SetHandler proxy:unix:///var/www/vhosts/system/wwphelps.com/php-fpm.sock|fcgi://127.0.0.1:9000
</Files>
It is true that you need to do this, but for me it didn't work as advertised. My web page simply said "Access Denied" and my error files pointed me to FPM's security.limit_extensions paramter. In other words, despite specifically identifying a file I wanted to use without a suffix, FPM rejected it anyway. Here's where I got lazy. I reset the variable to nothing. In Plesk that's done by creating or modifying a php.ini file inside the domain's conf directory and adding (including the header if it's not already there)...
[php-fpm-pool-settings]
security.limit_extensions =
Restart Apache and Bob's your uncle.
According to a really rapid Google search, the ability to directly modify FPM parameters from inside Plesk is still up for debate.
Now, this comes with a price. From the perspective of the FPM socket, suddenly any file in you're web root "could" be executed as a PHP file, including images customers upload and you blindly put in your [ROOT]/images directory. You're partially saved by the fact that unless you've told Apache otherwise, just any old file won't be interpreted as a PHP file. However, you'd be better protected if all files you upload through your site are (a) thoroughly vetted to be sure they are what they claim to be and (b) are either saved outside the web root or in a DB so that nobody can "execute" them by referring to them directly.
Finally, there ought to be a way to override in a config file those files that I want to intentionally violate security.limit_extensions. Unfortunately, FPM and Apache don't appear to talk to each other, otherwise the use of the block would completely override security.limit_extensions. For all I know there's a way to do it. I'd be curious to know, but I have a working solution, so I'm back to work.