Notes by David Gibson - see page footer for date.
These notes are intended for people who are migrating their BCRA sub-domains from BCA's britiac2 server to britiac3.
PHP status:
Files on this site. The files and directories initially on this site are part of a test set-up by David Gibson. You do not need them, and most of them can be deleted - but read this page first; and especially these numbered notes....
The directory .well-known is created by the server. It is part of the AutoSSL feature of cPanel that provides free SSL certificates. Im not sure what happens if you delete it; I think it just gets re-created the next time that AutoSSL runs.
The .htaccess file is not absolutely essential unless you wish to control which version of PHP you are using. A 'bare-bones' version of it is currently at bare-bones.htaccess.txt, which you can build on, and re-name to .htaccess if you wish to use it in preference to the .htaccess file I have supplied.
Ditto, the .user.ini file is not absolutely essential unless you wish to alter the system's PHP defaults. A 'bare-bones' version of it is currently at bare-bones.user.ini.txt, which you can build on, and re-name to .user.ini if you wish to use it in preference to the .user.ini file I have supplied.
Site Security. The access security on britiac3 is greater than on britiac2. If you get your FTP or Basic Auth password wrong too many times, you will be locked out (e.g. "site did not respond") for a while. SFTP (Secure FTP) is available, but please contact BCA's IT support to check the access requirements.
PHP runs differently here. Britiac3 runs PHP in CGI mode (i.e. not as an Apache module), so you cannot use php_value or php_flag commands in a .htaccess file, else an 'internal server error' message will be generated. A per-directory .user.ini file can be used for PHP directives, or they can be run from PHP using the ini_set() function. The initial content of your new site includes a demo .user.ini file.
Location of files. The location of your sub-domain files will be at /home/bcra/<your-subdomain>_htdocs, rather than /home/bcra/public_html/<your-subdomain>, as it was before. The main difference this gives rise to is that you need to maintain your own .htaccess. The initial contents of your new site will include a demonstration of this and - if you do not wish to further configure it, it will no doubt suffice.
Use of https. Your new .htaccess file includes a 'rewrite' that maps http requests to https.
Use of password protection. One side-effect of my https rewrites is that password-protected pages (what Apache calls 'Basic Auth') need to be handled with care.
There must be an Apache directive for ErrorDocument 401 in .htaccess, else "it doesnt work". (I have configured this in the demo .htaccess file).
The protected directory must be called with an https protocol. If this cannot be guaranteed (e.g. the customer arrives via a direct http link from an external site) then the rewrites should exclude the protected directory (see my demo .htaccess file). Further info at Check Installation.
Links to other parts of BCRA's site. Because the existing britiac installation of BCRA is full of outdated files at the moment, please ensure that you do not refer, in your code, to any BCRA server file unless you include its full URI. I dont expect you are doing that, as it would be quite a 'specialist' thing to do, but Im alerting you just in case. (Note to self: like cross-site PHP scripts for grabbing page footers).
A note on PHP version. The site default is currently PHP 5.6, but you can set a different version in .htaccess. It is also possible to use cPanel's MultiPHP manager which, when its settings are "applied", simply adds an "Addhandler" line (and a comment) to the end of your .htaccess file. (It does this when it cannot find the appropriate comment line already there). However, there appears to be a bug in MultiPHP manager in that it does not do this if the .htaccess file is outside the public_html tree. Also, the PHP version that MultiPHP manager "thinks" it has set is not nessarily the actual version that is set in your .htaccess file. In other words...
Always set your PHP version from your .htaccess file. MultiPHP manager might indicate that a different version of PHP is being used. That does not matter unless someone actually tries to helpfully "Apply" the MultiPHP manager settings to your sub-domain, in which case, your .htaccess file might be altered without your knowledge. So...
Admins with cpanel access should never use MultiPHP manager without verifying, afterwords, what edits it made to the relevant .htaccess file.