I have today received an email from my host informing me of some upcoming changes that I don't think will cause a problem but would be interested to hear confirmation, the email says:
Point 1: We currently have the acatalog folder set to 777 which I have seen recommended but a couple threads also suggest 755 is fine, so I think this should be OK
Point 2: We use htaccess for:
301 redirects
Rewriting non-www to www using RewriteCond
The DEFLATE command for gzip compression
and setting the cache expiry, eg.
As I don't think these would be classed as changing PHP option I assume we would not be effected.
This announcement is related to our upcoming work on all shared/reseller servers to enable suphp as previously discussed in our forum.
We will be carrying out this change on chad.clook.net on the evening of 11th March 2010. After this server is complete we will be leaving a period of time to check all is okay before continuing with the rest of the shared servers which will be announced separately 1-2 weeks later.
---
This is quite a large scale change but we'd first like to reassure all clients that in the vast majority of cases there will be no difference and the work will be un-noticable. In fact, we have been running suphp on our newest shared hosting servers for some months now with ZERO problems or issues. This announcement is aimed at highlighting some of the slight differences when PHP is running in a suphp environment.
1. Permissions
With suphp it will not be possible to make insecure permission settings to scripts such as 777 world writable. Any PHP files should be set to 644 (or less) with directories set to 755 (or less). This is a much more secure hosting environment and any changes to permissions or ownership required on existing scripts will be handled by us as part of the work.
2. .htaccess php rules
At the moment it is possible to change some php options by using a line in a .htaccess file such as "php_value option x" or "php_flag option x". This will no longer be possible after the suphp install and any php options will need to be configured in a file called php.ini using the syntax 'option_name = "value"'. Once again, we will take care of converting lines of .htaccess files to php.ini files at the time of the work.
3. Account quotas
To date, any files created using a PHP script have been under Apache ownership and not counted towards the user account quota. This will change and all quotas will be much more accurate after the work which is a major benefit for account accuracy and when clients with to modify files created using scripts via FTP which will be possible without issue with suphp.
We will be carrying out this change on chad.clook.net on the evening of 11th March 2010. After this server is complete we will be leaving a period of time to check all is okay before continuing with the rest of the shared servers which will be announced separately 1-2 weeks later.
---
This is quite a large scale change but we'd first like to reassure all clients that in the vast majority of cases there will be no difference and the work will be un-noticable. In fact, we have been running suphp on our newest shared hosting servers for some months now with ZERO problems or issues. This announcement is aimed at highlighting some of the slight differences when PHP is running in a suphp environment.
1. Permissions
With suphp it will not be possible to make insecure permission settings to scripts such as 777 world writable. Any PHP files should be set to 644 (or less) with directories set to 755 (or less). This is a much more secure hosting environment and any changes to permissions or ownership required on existing scripts will be handled by us as part of the work.
2. .htaccess php rules
At the moment it is possible to change some php options by using a line in a .htaccess file such as "php_value option x" or "php_flag option x". This will no longer be possible after the suphp install and any php options will need to be configured in a file called php.ini using the syntax 'option_name = "value"'. Once again, we will take care of converting lines of .htaccess files to php.ini files at the time of the work.
3. Account quotas
To date, any files created using a PHP script have been under Apache ownership and not counted towards the user account quota. This will change and all quotas will be much more accurate after the work which is a major benefit for account accuracy and when clients with to modify files created using scripts via FTP which will be possible without issue with suphp.
Point 2: We use htaccess for:
301 redirects
Rewriting non-www to www using RewriteCond
The DEFLATE command for gzip compression
and setting the cache expiry, eg.
ExpiresActive On
ExpiresByType image/jpeg "access plus 12 hours"
</IfModule>
ExpiresByType image/jpeg "access plus 12 hours"
</IfModule>
Comment