Many web hosts converted or will convert to phpSUEXEC, mainly because phpSUEXEC is much more secure that the regular php being served with apache has API.

If you’re currently using the "regular php", a  few changes may be required on your website’s configuration files (.htaccess).

Every php_flag command in your .htaccess file will have to removed and moved to a new file with the name "php.ini", which you will have to create in your site’s public root folder.

For example:
.htaccess command » php_flag register_globals on
php.ini command » register_globals=on

The file php.ini will handle all the extra settings you need to set in php. It’s pretty much your own custom php configuration file.
So, basically you will have to move every command on .htaccess that starts with php_flag to the new php.ini configuration file.

Differences between phpsuexec and "regular php":
When using the common PHP installation on a webserver, php runs as "nobody" (just like apache) and it doesn’t require the execute flag to be enabled.

The problem on this is that if mod_openbasedir is not installed (every host has this nowadays), every user will be able to read your php files because everyone is virtually sharing the same username (nobody).

As most of you already know, PHP Files are not meant to be read, but parsed, and that is where the problem resides. PHP Files have to be parsed, otherwise everyone who is able to read your php file will see settings that you would probably want to keep private, such as your MySQL username and password.

PHPSUEXEC eliminates this security concern because it requires php to be run as the file owner’s username. (for example: andre)
This will also make system administors’ lives easier because they can now directly monitor the usernames running php, as such it becomes easier to track overload causes, etc.

This is not everything it does, though. phpSUEXEC is also here to fix file ownership issues; which is a common issue on a few Content Management Systems such as Joomla or even the popular blog platform: WordPress.

It will also add security to your files as you can use permissions such as 600 or 700 on them and your visitors will still be able to access them (parsed) in their browsers.

A system compiled with phpSUEXEC will also refuse to serve any pages that are at security risk, for example with 777 as permissions. (this will trigger an Internal Server Error)

Troubleshooting Internal Server Errors (Error 500):
Everytime an internal server error occurs, an entry will be added to your Error Log in cPanel. (cPanel »» Error Log).
This will usually give you a clue on where the error is coming from. In most cases it will be either a permission problem (for security’s sake) or a then invalid command in your .htaccess configuration file (remember that all commands started by php_value have to be migrated to your new php.ini configuration file).

Directories that need to be written onto will no longer require 777 as permissions and phpSUEXEC will also refuse to write or read on directories insecure with such permissions. You will have to keep their permission settings as 755.

To simplify it, just keep in mind that you shouldn’t have a file or folder with world-writeable permissions (777), because you no longer need to.

MIME Types:
If you added a Mimetype to the system in order to run parse html files as php scripts (using AddType as a .htaccess command), you will have to replace it with an ApacheHandler instead. Just replace "AddType" by "AddHandler" and you should be good to go!

QuickStart for impatient users:
Technically, phpSUEXEC will make sure your files and directories abide by the following security restrictions:

• User executing the wrapper is a valid user on the webserver.
• The command that the request tries to execute cannot contain a / (must be clean).
• The command being executed must reside under the user’s website’s document root (wwwroot or public_html depending on the system).
• The current working directory must not be world-writeable.
• The command being executed cannot be a symlink (again for security’s sake).
• The command being executed cannot be a setuid or setgid program, these will be ignored.
• The target UID and GID must be a valid user or/and group on the webserver.
• The UID and GID, must match file/directory ownership.

Protecting your php.ini file:
You can set php.ini’s permissions to 600. This will make sure no one will be able to read it through a browser, while the configuration file will still work for you.

Ok, I’m ready for tons of comments bashing this post and here’s why:
Some people just ignore how browsers behave and lost their sense of productivity/practicality.
Others just say “Heck, if W3C approves it, I’ll do it”

Well, this is not the best way to think about YOUR site.

I started to use CSS-P for a long time and I do know how to use it correctly.
However let’s face it: it’s not worth it.

I lose at least the double of time on CSS-P and its div tags compared to the time I take to design a site using tables.
I know, tables are “not supposed” to be used on design: So what?

Give me a good reason not to use them. That’s like saying that fire wasn’t made to light up cigarettes. It’s insane.
I found a great page explaining why the so-called <div> tags should not be used:

http://www.decloak.com/Dev/CSSTables/CSS_Tables_01.aspx

I will probably use them again sometime in the future: Whenever Microsoft complies. Until then I won’t spend 1 more hour on CSS based layouts. It’s just insane doing so.

Even on the site you are on, I had to start removing divs. All because of IE.
And in terms of practicality… tables are equally positioned on every browser. So don’t tell me divs are the standard. They will become a standard whenever all browsers have an equalized way to show them. PERIOD.

That’s all for today