The php.ini file can be viewed from a web browser.

To prevent people to viewing your php.ini file via a browser a few lines need to be pasted into the .htaccess file.

1) Login to the cPanel
2) Click on File Manager
3) Open the public_html folder (click on the folder icon next to public_html)
4) Click on .htaccess and then select the "Edit File" option on the right hand of the window.
5) Paste the following code into the bottom of the file and then click save:
<Files php.ini>
Order allow,deny
Deny from all
</Files>

Now your php.ini file is protected and which can help php crackers from finding exploits on your site.

How do I change my upload_max_filesize?

In a nutshell:

• Locate the php.ini file in the folder your upload script resides in. If none exists, create a new text file called php.ini
• In the php.ini file, locate the line called 'upload_max_filesize = 2M'
• Modify that entry to read 'upload_max_filesize = 10M', or whatever your script requires. (M = megabytes)
• That's it!

-------------------------------------------------------

Extended Version:
Follow this guide and place the php.ini in whatever directory the php file is being executed from.

Howto optimize your PHP installation to handle large file uploads.

Though PHP presents a very versatile and user friendly interface for handling file uploads, the default installation is not geared for working with files in excess of 2 Mega Bytes. This article is an aid to configuring PHP for handling suc h large file transfers.

php.ini

The php.ini file contains all the configuration settings for your installation. Sometimes these setting might be overridden by directives in apache .htaccess files or even with in the scripts themselves but for the moment let's just concentrate on the ini file.
This file contains the following settings that we need to modify

• file_uploads
• upload_max_filesize
• max_input_time
• memory_limit
• max_execution_time
• post_max_size

The first one is fairly obvious if you set this off, uploading is disabled for your installation. We will cover the rest of the configuration settings in detail below.

upload_max_filesize and post_max_size

Files are usually POSTed to the webserver in a format known as 'multipart/form-data'. The post_max_size sets the upper limit on the amount of data that a script can accept in this manner. Ideally this value should be larger than the value that you set for upload_max_filesize.
It's important to realize that upload_max_filesize is the sum of the sizes of all the files that you are uploading. post_max_size is the upload_max_filesize plus the sum of the lengths of all the other fields in the form plus any mime headers that the encoder might include. Since these fields are typically small you can often approximate the upload max size to the post max size.
According to the PHP documentation you can set a MAX_UPLOAD_LIMIT in your HTML form to suggest a limit to the browser. Our understanding is that browsers totally ignore this directive and the only solution that can impose such a client side restriction is Rad Upload Applet

memory_limit

When the PHP engine is handling an incoming POST it needs to keep some of the incoming data in memory. This directive has any effect only if you have used the --enable-memory-limit option at configuration time. Setting too high a value can be very dangerous because if several uploads are being handled concurrently all available memory will be used up and other unrelated scripts that consume a lot of memory might effect the whole server as well.

max_execution_time and max_input_time

These settings define the maximum life time of the script and the time that the script should spend in accepting input. If several mega bytes of data are being transfered max_input_time should be reasonably high. You can override the setting in the ini file for max_input_time by calling the set_time_limit() function in your scripts.

Special Notes

Apache Settings

The apache webserver has a LimitRequestBody configuration directive that restricts the size of all POST data regardless of the web scripting language in use. Some RPM installations sets limit request body to 512Kb. You will need to change this to a larger value or remove the entry altogether.

Other Options

If you expect to handle a large number of concurrent file transfers on your website consider using a perl or java server side component. PHP happens to be our favourite web programming language as well but perl is just slightly ahead when it comes to file handling.
Most installations of perl as an apache module can accept upto 32 megabytes out of the box. Compare this against the 2MB default for PHP. The downside is that perl coding takes just a bit more effort than PHP but it's worth it.

What is FastCGI for PHP?

FastCGI for PHP
FastCGI for PHP makes all your PHP applications run through mod_fastcgi instead of mod_phpsusexec. FastCGI applications are fast because they're persistent. There is no per-request startup and initialization overhead. This makes possible the development of applications which would otherwise be impractical within the CGI paradigm (e.g. a huge PHP script, or an application which requires a connection to one or more databases).
Benefits:

• PHP scripts will run faster. The PHP interpreter is loaded into memory rather than calling from storage for every hit, greatly improving performance of your scripted site.
• You will use less Server Resources. Since the server does not have load the PHP interpreter for each hit, you will be able to accommodate a higher traffic site without exceeding your CPU quota.
• NO modifications to your existing code are required. Everything you currently run will work with FastCGI for PHP.

Potential Problems:

• You will only have one php.ini file available for all subdirectories (/home/USERNAME/public_html/php.ini). This is necessary to help optimize the website code as much as possible. If you need multiple php.ini files to accommodate different scripting needs, you can disable FastCGI for PHP on any of your subdirectories while leaving the rest of the account enabled for performance. Please contact support if you need to do this.
• There can be a few minute delay in any updates you make to your PHP environment (ie, php.ini changes). Since your php.ini is loaded into memory for greater speed, every hit does not re-read it from storage.

A walkthrough for installing SourceGuardian ixeds into a hosting account.

SourceGuardian is usually already installed on the server your hosting account is on. To get your scripts to use SourceGuardian there are two things that must be done.

First, you need to get a template php.ini with SourceGuardian already configured in it. This can be accomplished by doing the following:
1. Login to your control panel
2. Choose "PHP Config"
3. Check the box labeled "SourceGuardian" under "Install Default php.ini"
4. Click "INSTALL PHP.INI FILE".
That will place php.ini file with the name of php.ini.default in your public_html folder.

Second, you need to rename the file from "php.ini.default" to be "php.ini" and place into whichever folder you need SourceGuardian installed.
You can do that using the file manager, ftp or ssh.


-------------------------------------------------------

The below tutorial is for users on servers not yet upgraded to apache2 and is meant for those with knowledge of extracting tools and may require SSH access to your account, but is doable over ftp.

The first step is to download the ixed package from the SourceGuardian developers website http://www.sourceguardian.com/ixeds/, the latest package at the time of this article for 64bit linux operating systems is here:

http://www.sourceguardian.com/ixeds/ixed4.lin.x86-64.tar.gz

Create a new folder in your / directory called ixed.

mkdir ixed

Upload this file to your /ixed/ directory. Then extract it.

tar -xvzf ixed4.lin.x86-64.tar.gz

Now you need to edit your php.ini file. Add one line into your php.ini with the appropriate loader name.

Examples:
(These are not the only possible variants, and are just provided as examples)

extension=/home/username/ixed/ixed.4.3.lin # for Linux, non thread safe, PHP 4.3.x
extension=/home/username/ixed/ixed.5.0.0.lin # for Linux, non thread safe, PHP 5.0.0
extension=/home/username/ixed/ixed.5.0.1.lin # for Linux, non thread safe, PHP 5.0.1
extension=/home/username/ixed/ixed.5.0.2.lin # for Linux, non thread safe, PHP 5.0.2
extension=/home/username/ixed/ixed.5.0.lin # for Linux, non thread safe, PHP 5.0.3+

extension=/home/username/ixed/ixed.5.0.0ts.lin # for Linux, thread safe, PHP 5.0.0
extension=/home/username/ixed/ixed.5.0ts.lin # for Linux, thread safe, PHP 5.0.3+

Thats it. If your script that requires SourceGuardian is used in a directory that is not in your public_html please copy the php.ini file to the directory the script is running from.

Also if you chose to use FTP method instead of SSH method you will need to extract the .gz files on your computer at home then upload the /ixed/ directory via ftp. Then edit your php.ini file in your favorite txt editor.

How do I change the PHP environment for my site with php.ini

The servers use a master php.ini file for all directories without a php.ini file in it. You will have a copy of this file in your public_html directory, and you can make any changes to this file, and they will take precedence over the master file. You will need to copy this file into all subdirectories within your site which have php files that you would like to affect.

You can also use this to have a different environment for different folders. So, if you want to run two scripts which have different requirements, you can put them in two different folders and then put different php.ini files in each of those folders.

If you have any further questions about configuring the php.ini file, there extensive descriptions within the file itself, and you can also find more help at:

http://www.php.net/docs.php

How to copy PHP.INI from public_html to all subfolders for PHP directive server overrides

Within public_html create a file with the following syntax included within it:

<pre><?php system("find . -type d|xargs -i cp --verbose php.ini {}/."); ?></pre>COMPLETE!

So, if you labeled the file "copyphpini.php" within public_html and you already have the initial PHP.INI file there, you would go to http://www.maindomain.com/copyphpini.php. This will copy the file to every folder below public_html and should there be any problems, reporting the errors verbosely.

How to optimize your PHP installation to handle large file uploads.

Follow this guide and place the php.ini in whatever directory the php file is being executed from.

Howto optimize your PHP installation to handle large file uploads.

Though PHP presents a very versatile and user friendly interface for handling file uploads, the default installation is not geared for working with files in excess of 2 Mega Bytes. This article is an aid to configuring PHP for handling suc h large file transfers.

php.ini

The php.ini file contains all the configuration settings for your installation. Sometimes these setting might be overridden by directives in apache .htaccess files or even with in the scripts themselves but for the moment let's just concentrate on the ini file.
This file contains the following settings that we need to modify

• file_uploads
• upload_max_filesize
• max_input_time
• memory_limit
• max_execution_time
• post_max_size

The first one is fairly obvious if you set this off, uploading is disabled for your installation. We will cover the rest of the configuration settings in detail below.

upload_max_filesize and post_max_size

Files are usually POSTed to the webserver in a format known as 'multipart/form-data'. The post_max_size sets the upper limit on the amount of data that a script can accept in this manner. Ideally this value should be larger than the value that you set for upload_max_filesize.
It's important to realize that upload_max_filesize is the sum of the sizes of all the files that you are uploading. post_max_size is the upload_max_filesize plus the sum of the lengths of all the other fields in the form plus any mime headers that the encoder might include. Since these fields are typically small you can often approximate the upload max size to the post max size.
According to the PHP documentation you can set a MAX_UPLOAD_LIMIT in your HTML form to suggest a limit to the browser. Our understanding is that browsers totally ignore this directive and the only solution that can impose such a client side restriction is Rad Upload Applet

memory_limit

When the PHP engine is handling an incoming POST it needs to keep some of the incoming data in memory. This directive has any effect only if you have used the --enable-memory-limit option at configuration time. Setting too high a value can be very dangerous because if several uploads are being handled concurrently all available memory will be used up and other unrelated scripts that consume a lot of memory might effect the whole server as well.

max_execution_time and max_input_time

These settings define the maximum life time of the script and the time that the script should spend in accepting input. If several mega bytes of data are being transfered max_input_time should be reasonably high. You can override the setting in the ini file for max_input_time by calling the set_time_limit() function in your scripts.

Special Notes

Apache Settings

The apache webserver has a LimitRequestBody configuration directive that restricts the size of all POST data regardless of the web scripting language in use. Some RPM installations sets limit request body to 512Kb. You will need to change this to a larger value or remove the entry altogether.

Other Options

If you expect to handle a large number of concurrent file transfers on your website consider using a perl or java server side component. PHP happens to be our favourite web programming language as well but perl is just slightly ahead when it comes to file handling.
Most installations of perl as an apache module can accept upto 32 megabytes out of the box. Compare this against the 2MB default for PHP. The downside is that perl coding takes just a bit more effort than PHP but it's worth it.

How can I execute php code as .htm or .html files

In your .htaccess file insert this line of code.

AddType application/x-httpd-php .html .htm .php
AddHandler application/x-httpd-php .html .htm .php

How do I turn the 'display_errors' flag on for php?

Add 'display_errors = on'" to your public_html/php.ini file.

The php_flag directive are not supported on many hosting companies system for security reasons. Put the php.ini file with whatever customization settings you need within the same directory that contains your .php file. If you do not already have a php.ini file, then create one with just that one line in it.

The redirection of www.yourdomain.com/default.html or index.html to http://www.yourdomain.com/index.php?act=whatever redirects it to http://www.yourdomain.com/index.php%3fact=whatever

In other words, why is "?" replaced with "%3f" (or anything else) in the address line?

this is a long one....

One of the more powerful tricks of the .htaccess hacker is the ability to rewrite URLs. This enables us to do some mighty manipulations on our links; useful stuff like transforming very long URL's into short, cute URLs, transforming dynamic ?generated=page&URL's into /friendly/flat/links, redirect missing pages, preventing hot-linking, performing automatic language translation, and much, much more.

Make no mistake, mod_rewrite is complex. this isn't the subject for a quick bite-size tech-snack, probably not even a week-end crash-course, I've seen guys pull off some real cute stuff with mod_rewrite, but with kudos-hat tipped firmly towards that bastard operator from hell, Ralf S. Engelschall, author of the magic module itself, I have to admit that a great deal of it still seems so much voodoo to me.

The way that rules can work one minute and then seem not to the next, how browser and other in-between network caches interact with rules and testing rules is often baffling, maddening. When I feel the need to bend my mind completely out of shape, I mess around with mod_rewrite!

after all this, it does work, and while I'm not planning on taking that week-end crash-course any time soon, I have picked up a few wee tricks myself, messing around with webservers and web sites, ect..

The plan here is to just drop some neat stuff, examples, things that has proven useful, stuff that works on a variety of server setups; there are apache's all over my LAN, I keep coming across old .htaccess files stuffed with past rewriting experiments that either worked; and I add them to my list, or failed dismally; and I'm surprised that more often these days, I can see exactly why!

Nothing here is my own invention. Even the bits I figured out myself were already well documented, I just hadn't understood the documents, or couldn't find them. Sometimes, just looking at the same thing from a different angle can make all the difference, so perhaps this humble stab at URL Rewriting might be of some use. I'm writing it for me, of course. but I do get some credit for this..

# time to get dynamic, see..
rewriterule ^(.*).htm $1.php



beginning rewriting..
Whenever you use mod_rewrite (the part of apache that does all this magic), you need to do..

you only need to do this once per .htaccess file:
Options +FollowSymlinks
RewriteEngine on

before any ReWrite rules. +FollowSymLinks must be enabled for any rules to work, this is a security requirement of the rewrite engine. Normally it's enabled in the root and you shouldn't have to add it, but it doesn't hurt to do so, and I'll insert it into all the examples on this page, just in case.

The next line simply switches on the rewrite engine for that folder. if this directive is in you main .htaccess file, then the ReWrite engine is theoretically enabled for your entire site, but it's wise to always add that line before you write any redirections, anywhere.

note: while some of the directives on this page may appear split onto two lines, in your .htaccess file, they must exist completely on one line.


simple rewriting
Simply put, Apache scans all incoming URL requests, checks for matches in our .htaccess file and rewrites those matching URLs to whatever we specify. something like this..

all requests to whatever.htm will be sent to whatever.php:
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*).htm $1.php [nc]

handy for anyone updating a site from static htm (you could use .html, or .htm(.*)) to dynamic php pages; requests to the old pages are automatically rewritten to our new urls. no one notices a thing, visitors and search engines can access your content either way. leave the rule in; as an added bonus, this enables us to easily split php code and its included html structures into two separate files, a nice idea; makes editing and updating a breeze. The [nc] part at the end means "No Case", or "case-insensitive", but we'll get to that.

folks can link to whatever.htm or whatever.php, but they always get whatever.php in their browser, and this works even if whatever.htm doesn't exist! but I'm straying..

as it stands, it's a bit tricky; folks will still have whatever.htm in their browser address bar, and will still keep bookmarking your old .htm URL's. Search engines, too, will keep on indexing your links as .htm, some have even argued that serving up the same content from two different places could have you penalized by the search engines. This may or not bother you, but if it does, mod_rewrite can do some more magic..

this will do a "real" http redirection:
Options +FollowSymlinks
rewriteengine on
rewriterule ^(.+).htm$ http://yourdomain.org/$1.php [r=301,nc]

this time we instruct mod_rewrite to send a proper HTTP "permanently moved" redirection, aka; "301". Now, instead of just redirecting on-the-fly, the user's browser is physically redirected to a new URL, and whatever.php appears in their browser's address bar, and search engines and other spidering entities will automatically update their links to the .php versions; everyone wins. and you can take your time with the updating, too.


not-so-simple rewriting
You may have noticed, the above examples use regular expression to match variables. what that simply means is.. match the part inside (.+) and use it to construct "$1" in the new URL. in other words, (.+) = $1 you could have multiple (.+) parts and for each, mod_rewrite automatically creates a matching $1, $2, $3, etc, in your target URL, something like..

a more complex rewrite rule:
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^files/(.+)/(.+).zip download.php?section=$1&file=$2 [nc]

would allow you to present a link as..

http://mysite/files/games/hoopy.zip

and in the background have that translated to..

http://mysite/download.php?section=games&file=hoopy

which some script could process. you see, many search engines simply don't follow our ?generated=links, so if you create generating pages, this is useful. However, it's only the dumb search engines that can't handle these kinds of links; we have to ask ourselves.. do we really want to be listed by the dumb search engines? Google will handle a good few parameters in your URL without any problems, and the (hungry hungry) yet-to-actually-have-a-search-engine msn-bot stops at nothing to get that page, sometimes again and again and again.

I personally feel it's the search engines that should strive to keep up with modern web technologies, in other words; we shouldn't have to dumb-down for them. But that's just my opinion. Many users will prefer /files/games/hoopy.zip to /download.php?section=games&file=hoopy but I don't mind either way. As someone pointed out to me recently, presenting links as/standard/paths means you're less likely to get folks doing typos in typed URL's, so something like..

an even more complex rewrite rule:
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^blog/([0-9]+)-([a-z]+) http://yourdomain.org/blog/index.php?archive=$1-$2 [nc]

would be a neat trick, enabling anyone to access my blog archives by doing..

http://yourdomain.org/blog/2003-nov

in their browser, and have it automagically transformed server-side into..

http://yourdomain.org/blog/index.php?archive=2003-nov

which yourdomainblog would understand. It's easy to see that with a little imagination, and a basic understanding of posix regular expression, you can perform some highly cool URL manipulations.


shortening URLs
One common use of mod_rewrite is to shorten URL's. shorter URL's are easier to remember and, of course, easier to type. an example..

beware the regular expression:
Options +FollowSymlinks
RewriteEngine On
RewriteRule ^grab(.*) /public/files/download/download.php$1

this rule would transform this user's URL..

http://mysite/grab?file=my.zip

server-side, into..

http://mysite/public/files/download/download.php?file=my.zip

which is a wee trick I use for my distro machine, among other things. everyone likes short URL's. and so will you; using this technique, you can move /public/files/download/ to anywhere else in your site, and all the old links still work fine. just alter your .htaccess file to reflect the new location. edit one line, done. nice. means even when stuff is way deep in your site you can have cool links like this.. http://yourdomain.org/img/hotlink.png [nc]
you may see the last line broken into two, but it's all one line (all the directives on this page are). let's have a wee look at what it does..

we begin by enabling the rewrite engine, as always.

the first RewriteCond line allows direct requests (not from other pages - an "empty referrer") to pass unmolested. The next line means; if the browser did send a referrer header, and the word "yourdomain" is not in the domain part of it, then DO rewrite this request.

the all-important final RewriteRule line instructs mod_rewrite to rewrite all matched requests (anything without "yourdomain" in its referrer) asking for gifs, jpegs, or pngs, to an alternative image. mine says "no hotlinking!". You can see it in action here. there are loads of ways you can write this rule. google for "hot-link protection" and get a whole heap. simple is best. you could send a wee message instead, or direct them to some evil script, or something.


httpd.conf
Remember, if you put these rules in the main server conf file (usually httpd.conf) rather than an .htaccess file, you'll need to use ^/... ... instead of ^... ... at the beginning of the RewriteRule line, in other words, add a slash.


inheritance..
If you are creating rules in sub-folders of your site, you need to read this.

you'll remember how rules in top folders apply to all the folders inside those folders too. we call this "inheritance". normally this just works. but if you start creating other rules inside subfolders you will, in effect, obliterate the rules already applying to that folder due to inheritance, or "decendancy", if you prefer. not all the rules, just the ones applying to that subfolder. a wee demonstration..

let's say I have a rule in my main /.htaccess which redirected requests for files ending .htm to their .php equivalent, just like the example at the top of this very page. now, if for any reason I need to add some rewrite rules to my /osx/.htaccess file, the .htm >> .php redirection will no longer work for the /osx/ subfolder, I'll need to reinsert it, but with a crucial difference..

this works fine, site-wide, in my main .htaccess file
# main (top-level) .htaccess file..
# requests to file.htm goto file.php
Options +FollowSymlinks
rewriteengine on
rewriterule ^(.*).htm$ http://yourdomain.org/$1.php [r=301,nc]


here's my updated /osx/.htaccess file, with the .htm >> .php redirection rule reinserted..

but I'll need to reinsert the rules for it to work in this sub-folder
# /osx/.htaccess file..
Options +FollowSymlinks
rewriteengine on
rewriterule some rule that I need here
rewriterule some other rule I need here
rewriterule ^(.*).htm$ http://yourdomain.org/osx/$1.php [r=301,nc]

spot the difference in the subfolder rule, highlighted in red. you must add the current path to the new rule. now it works again. if you remember this, you can go replicating rewrite rules all over the place.


conclusion

In short, mod_rewrite allows you to send browsers from anywhere to anywhere. You can create rules based not simply on the requested URL, but also on such things as IP address, browser agent (send old browsers to different pages, for instance), and even the time of day; the possibilities are practically limitless.

the ins-and outs of mod_rewrite syntax are topic for a much longer document than this, and if you fancy experimenting with more advanced rewriting rules, I urge you to check out the apache documentation. If you are running some *nix operating system, (in fact, if you have apache installed on any operating system), there will likely be a copy of the apache manual on your own machine, right here, and the excellent mod_rewriting guide, lives right here. do check out the URL Rewriting Engine notes for the juicy syntax bits.


http://www.ilovejackdaniels.com/apache/mod_rewrite-cheat-sheet/
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
http://httpd.apache.org/docs/1.3/misc/rewriteguide.html
http://forum.modrewrite.com/

How do I enable the Zend Optimizer on my account?

Zend Versions installed on most hosting servers are: 3.0.1, 3.0.2, 3.2.0, and 3.2.2.
Because Zend Optimizer has been standardized on all many hosting companies servers so that varying versions do not cause conflicting PHP.INI files, make sure your [Zend] portion appears as below in your PHP.INI:

[Zend]
zend_optimizer.optimization_level=15
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

A walk through to install IonCube into a hosting account.

IonCube is already installed on the server your hosting account is on. To get your scripts to use IonCube there are two things that must be done.

First, you need to get a template php.ini with IonCube already configured in it. This can be accomplished by doing the following:
1. Login to your control panel
2. Choose "PHP Config"
3. Check the box labeled "IonCube" under "Install Default php.ini"
4. Click "INSTALL PHP.INI FILE".
That will place php.ini file with the name of php.ini.default in your public_html folder.

Second, you need to rename the file from "php.ini.default" to be "php.ini" and place into whichever folder you need IonCube installed.
You can do that using the file manager, ftp or ssh.


-------------------------------------------------------

The below tutorial is for users on servers not yet upgraded to apache2 and is meant for those with knowledge of extracting tools and may require SSH access to your account, but is doable over ftp.

The first step is to download the ionCube package from the ionCube developer's website http://www.ioncube.com/loaders.php, the latest package at the time of this article for 32bit(box1 - 19, 21 and 27) and 64bit(all other servers) linux operating systems is here:


64-bit
http://downloads.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz

32-bit
http://downloads.ioncube.com/loader_downloads/ioncube_loaders_lin_x86.tar.gz

Upload this file to your / directory (not public_html). Then extract it.

64-bit
tar -xvzf ioncube_loaders_lin_x86-64.tar.gz This will create a directory called /ioncube/

32-bit
tar -xvzf ioncube_loaders_lin_x86.tar.gz

Now you need to edit your php.ini file and add the following line to the begining of the [zend] section

zend_extension = /home/username/ioncube/ioncube_loader_lin_5.2.so

Note: Replace "username" in the line above with your cPanel username.

That's it. If your script that requires ioncube is in a directory that is not in your public_html please copy the php.ini file to the directory the script is running from. Also, make sure that you have Ioncube loading before Zend Optimizer or you will get 500 errors.

Also if you chose to use FTP method instead of SSH method you will need to extract the .gz files on your computer at home then upload the /ioncube/ directory via ftp. Then edit your php.ini file in your favorite txt editor.

I get this with some of my php files:
Fatal error: Unable to read X bytes in /home/user/public_html/myfile.php on line Y

This means that the file was uploaded as ASCII text (plain text) instead of as a binary file (1's and 0's). Some php code requires that it is transfered as a binary file, and not as plain text. Setting your FTP client to force Binary mode, instead of allowing it to auto-detect the mode, will fix this problem 90% of the time.

Do you support mod_php?

Due to security precautions, most hosting companies currently do not have, or have plans to have, a system with mod_php.

How do I use PHP?

To use PHP within your account make a file and give it a ".php" file extension (e.g., example.php). Inside this file you can put any HTML that would normally go in a web page. Anywhere in that file, within the HTML, you can put your PHP code.

*Note: PHP code always begins with a "<?" and ends with a "?>".

You can learn more by visiting http://www.zend.com/zend/art/

How do I view the php information page?

Create a page name phpinfo.php and insert the below code into it. Pull this page up in your browser and this will show the php configuration on the server.

<?php

// Show all information, defaults to INFO_ALL
phpinfo();

// Show just the module information.
// phpinfo(8) yields identical results.
//phpinfo(INFO_MODULES);

?>

Help my php site has been exploited or hacked what can I do to make sure this does not happen again?

The programs that operate database-driven sites are vulnerable to hackers, who can (and do) exploit bugs in those programs to gain unauthorized access to your site.

1. Keep confidential information out of your PHP files.
2. Keep the PHP code to yourself. If anyone can see it they can expliot vulnerabilities. You should take care to store your PHP files and the necessary passwords to access your MySQL databases in protected files or folders. The easy way to do this is to put the database access passwords in a file with a .inc.php extension (such as config.inc.php), and then place this file in a directory which is above the server's document root (and thus not accessible to surfers of your site), and refer to the file in your PHP code with a require_once command. By doing things this way, your PHP code can read the included file easily but hackers will find it almost impossible to hack your site.

Emails are not sending out in the correct character sets. Recipients are receiving odd characters instead of the specified set.

This is a known issue with many hosting companies servers.
You can fix your immediate concerns by overriding php's mail() function, to encode the emails to a given character set. You can add the following to your php.ini, to do this:

[mbstring]
mbstring.language = Neutral
mbstring.internal_encoding = UTF-8
mbstring.http_input = UTF-8
mbstring.http_output = UTF-8
mbstring.encoding_translation = On
mbstring.detect_order = auto
mbstring.substitute_character = long;
mbstring.func_overload = 1

This is for utf8. You can take a look at php.net's mbstring page, located here: http://www.php.net/manual/en/ref.mbstring.php for specific language options.

PLEASE NOTE!!!: Unfortunately, simply adding this information to your php.ini will not resolve all of your issues. Please contact the maker of your script, and confirm what settings you may need to add as the subject and body may be encoded differently. Fortunately the majority of the makers of common and well known scripts have helpful forums and FAQ's.