We seriously see a ton of customers coming in with the type of databases that are a nightmare to move over. When you’re dealing with special characters in a database, you have to make sure that the charset and collation are dumped *with* the database, so that when you move it to another server the tables and data create properly. The biggest annoyance so far is converting tables back to UTF-8, as when this is done through the MySQL shell or phpmyadmin is had to be done table-by-table. So, I wrote this simple PHP script to do it all at once:

<?php
// Database info

$dbhost = 'localhost';
$dbuser = 'db_user';
$dbpass = 'password';
$dbname = 'db_name';


//---------------

header('Content-type: text/plain');

$dbconn = mysql_connect($dbhost, $dbuser, $dbpass) or die( mysql_error() );
$db = mysql_select_db($dbname) or die( mysql_error() );

$sql = 'SHOW TABLES';
$result = mysql_query($sql) or die( mysql_error() );

while ( $row = mysql_fetch_row($result) )
{
$table = mysql_real_escape_string($row[0]);
$sql = "ALTER TABLE $table DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci";
mysql_query($sql) or die( mysql_error() );
print "$table changed to UTF-8.\n";
}

mysql_close($dbconn);
?>

If course, you can adjust the ALTER TABLE statement to any character set and collation that you need.

We recently started installing suPHP on a few of our servers, which is an implementation of phpsuexec, only a ton faster and with less overhead. Yesterday I posted a tutorial on how to install suPHP on a PHP5/Apache server outside of EasyApache, but today I shall go over how to enable PHP directives in your .htaccess instead of using the php.ini.

First of all, if you’d rather use the .htaccess than the php.ini capabilities of a phpsuexec environment, then shame on you. But, we have some customers who are terrified of php.ini and would rather use the .htaccess. So what? Ok, well there is a workaround. Mr. Joye released a newer version of htscanner that now works with suPHP, and allows you to use php directives in your .htaccess just like you did when PHP was installed as and Apache module. All you have to do is download the tarball and install like any other PHP module:

wget http://pecl.php.net/get/htscanner-0.8.1.tgz

tar -xvzf htscanner-0.8.1.tgz

cd .htscanner-0.8.1

./configure && make && make install

Then add a loader for the resulting binary to your php.ini:

extension=”/htscanner.so”

From here, you can add your php_value and php_flag statements to your .htaccess as usual within <ifmodule> tags. I should note that the reason why you normally would not be able to overwrite php.ini values in your .htaccess is because .htaccess is an Apache file. Under phpsuexec/suPHP, PHP runs as a CGI module so Apache does not understand what those mean, so it will either ignore them all together or return a nasty 500 error.

Whether you compiled manually or with EasyApache, running a PHP upgrade from a previous version is super easy but also one of the most common questions I get. There are 3 likely assumptions about your current environment (specific to Linux servers, sorry Windows users):

1. You are running a cPanel server and have PHP compiled by EasyApache

2. You compiled PHP manually from source

3. You used Yum, Aptitude, or another package manager

EasyApache

Perhaps the easiest (but least efficient time-wise), simply log into WebHost Manager > Apache Update and select “Previously Saved Config” option and “Start Customizing Based on Profile“. The next screen should take you to the Apache version, which you can keep the same or upgrade as well. Then you’ll be taken to select either PHP 4 or PHP 5, proceeded by the actual version you wish to run and then the options for both Apache and PHP on the next two steps (Advanced Configuration). You usually do not need to change the options if your target is just a simple upgrade within the same version family, but if you changed the Apache version, updated cPanel recently, or are upgrading to a different PHP version family (like 4.4.7 to 5.2.x), then you’ll want to double-check the Apache/PHP build options to make sure they are what they need to be before selecting “Save and Build.” If you are running older versions of EasyApache (usually with cPanel 10 or early versions of cPanel 11 STABLE) then all you have to do is select ‘Load Previous Config‘, pick your PHP version, and ‘Build‘.

Source

If you’ve compiled PHP from source (./configure && make && make install method), you can use your previous configure arguments to compile against a different version. Refer to your server’s phpinfo file (if you don’t have one just create a PHP script with <?php phpinfo(); ?>) and copy the entire ./configure statement into notepad and remove the single quotes. Once you’ve done this, download the source tarball of the new PHP version, untar, and then enter the installation directory. From there, all you have to do is paste the configure statement from notepad. For instance, for PHP 5.2.5:

wget http://www.php.net/get/php-5.2.5.tar.gz/from/this/mirror

tar -xvzf php-5.2.5.tar.gz

cd php 5.2.5

./configure –options-from-your-phpinfo

After the configuration is complete, the script may indicate at the end of its output that you’ve specified configuration options that do not exist. This usually will not affect your build, but you’ll want to review them and consult the PHP documentation on the correct syntax or alternatives to the invalid build options, as these can change depending on which version of PHP you are installing. Doing a ./configure –help will also display the valid options you can use.

Once you have a good configuration, you can go ahead with the make and make install to install the new version of PHP. If you have PHP integrated with Apache (usually you would unless you compiled as CGI) then the installation should have already updated the PHP binary for Apache and module loader in httpd.conf. However, you may need to manually comment out old module loaders if there are conflicts. You’re looking for something like this:

LoadModule php5_module        modules/libphp5.so

Package Installation

Some people have PHP installed via package manager, like Yum or Aptitude. Since the package software usually handles all aspects of the configuration and installation (outside of modules you may have installed via PEAR or Pecl), then you can use its update function to take care of the upgrade as well. Most have a specific option for upgrades, for instance Yum uses:

yum update php

For more information, see NixCraft’s article on PHP installations with Yum.

I decided to stop being lazy and get around to those upgrades I needed for my site and server:

- Upgrade PHP to 5.2.5 and Apache 2.2.6

- Upgrade Gallery2 and the WPG2 plugin for WordPress

- Upgrade WordPress to 2.3.1

First, I should admit that I do use the EasyApache installer from WHM, as it has vastly improved to the point where I don’t have to troubleshoot its builds afterwards, nor do I have to go back and reinstall eAccelerator and Suhosin – The current release of cPanel now includes those options and I must say that they have become rather flawless. In other words, it saves me the time of compiling shit by hand when all I have to do is click a few buttons and it’s all done.

Second, I was avoiding the Gallery2/WPG2 upgrade because I remember that the first time I set it up it was hell, and since it was so long ago I didn’t want to go through that again.

Third, since my last WordPress upgrade I had numerous problems with plugins and as a result I had to tweak most of them because their developers hadn’t released an upgrade yet. I finally decided to just suck it in and upgrade, though it wasn’t as bad as I thought it would be. There are a few things to point out:

- Ultimate Tag Warrior has been discontinued due to WordPress 2.3.1′s native support for tagging. If you’re a UTW user like me, you can still keep your sexy tag cloud by follow these steps:

1. In your admin section, go to Manager > Import and use the UTW import tool to convert your UTW tags to WordPress tags. Then go to Manage > Categories and convert your categories to tags too, if they were linked to UTW before.
2. In your theme code where you normally would display your categories, change the code to <?php the_tags(”); ?> instead of <?php the_categories(”); ?> or whatever it was before.
3. Since your tag cloud is now gone, remove the UTW code and replace it with <?php wp_tag_cloud(”); ?>. You can read more about configuring the tag cloud here.

Since removing UTW and upgrading my plugins and WP, I noticed that my site loads a ton faster though, so I’m overall glad that I finally got around to doing this stuff. If you’re lazy like me and still haven’t upgraded to WP 2.3.1, below is a helpful guide on how to do so:

http://polymathprogrammer.com/2007/10/29/upgrade-wordpress-2pt2-to-2pt3/

Hosting companies have all kinds of tactics to keep spam away from their customers, but one very common complaint I get is the amount of spam coming in through contact forms. Even though we don’t allow ‘nobody’ mail through the php mail() function and we provide the best server-side spam filters available, local mail cannot be filtered or limited. In other words, no spam filter in the world is going to save you from your shitty contact form.

I started recommending to our customers to implement MX checks in their forms as spam bots nowadays can easily get past things like captcha and textual confirmations. Spammers rarely send email from valid mail hosts so it’s very easy to filter these out with just a few lines of code:

<?php
list($user, $domain) = split(“@”, $email);
if (checkdnsrr($domain, “MX”)) {
} else {
}

?>

To explain the code a little bit, you’re basically taking your stored email address variable ($email) and using the split() function to single out the domain name into one variable, $domain. When you pass the domain through the checkdnsrr() function, PHP will return either a ’1′ or ’0′ result, which is interpreted as either true or false. The above is just the basic code, but you can have it spit out errors as well:

if (checkdnsrr($domain, “MX”)) {
} else {

echo "Invalid email";
}

The checkdnsrr() function can also be used to check for other records as well, like A, CNAME, NS, etc.

If you were ever looking for a quick and sexy way to save bandwidth on your PHP-based porn high traffic site, all you have to do is add these two lines to the beginning of your PHP scripts:

<?php
@ini_set('zlib.output_compression_level', 1);
@ob_start('ob_gzhandler');
?>

This will automatically tell the server to compress the PHP page before sending it to the browser. However, sometimes this can causes excess load and a decrease in the speed of your website, but it’s hardly noticable.

This is a common request we get for Ioncube to be installed. It’s generally not an issue, but when you factor in other optimization plugins like Zend and eAccelerator, a common misconception is that the three don’t get along. It’s very easy to install Ioncube into a PHP installation that already has Zend and eAccelerator.

This tutorial is specific to cPanel, assuming that you are using php 5.2.x with Zend 3.x.x.

If you need help installing eAccelerator, you can see this tutorial. For help with installing Zend, you can go here. The versions in both these tutorials are outdated, so you’ll probably want to apply the instructions to the newest versions available.
Go to http://www.ioncube.com/loader_download.php and pick your download. This example assumes that you are using php 5.2.

cd /usr/src
wget http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86.tar.gz
tar -xvzf ioncube_loaders_lin_x86.tar.gz
cd ioncube

Copy the loader config to the user’s public_html or another location where you can access it from a browser.

cp ioncube-loader-helper.php /home/username/public_html

Now in your browser go to the loader file that you just copied. This file will tell you exactly which extension you need to use. Choose the ‘php.ini Installation Instructions’ link, and you should see something like this after the php config output:

zend_extension = /<path>/ioncube_loader_lin_5.2.so

Move the ioncube directory to a more permanent location:

mv /usr/src/ioncube /usr/local
chown -Rf root:root /usr/local/ioncube

Edit the php.ini and add look for this section (may not be exact):

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

Above this section, add this line:

zend_extension=/usr/local/ioncube/ioncube_loader_lin_5.2.so

Of course, make sure that the .so file is the one that the loader helper told you to use! After that is added, STOP and then START Apache to make sure that it’s loading. You should now see IonCube in your phpinfo file.

If you’re using eAccelerator, you shouldn’t need to change the location of the plugin loader in your php.ini.

Note that if Apache doesn’t start, it’s probably because of the order in which you have Zend and ioncube loading.  The lines for Ioncube should be above those for Zend optimizer.

Lastly, you should test your IonCube installation to make sure that it can decode its own files. In the original ‘ioncube’ directory that you moved, there’s a test ‘ioncube-encoded-file.php’ file that you can load through a browser to make sure that it works.

Working with a webhosting company I get asked all the time — which programming language is better? It’s obvious that I’m more bias towards PHP, but there are other great languages out there that may be more suitable for certain people creating certain sites. I’ve decided to write a nutshell comparison on the most common languages, so you can decide for yourself.

PHP

My preferred language, PHP, is the most popular and widely-used dynamic programming language on the Internet. As a result, it’s increasingly become easy to learn (I have 4 brain cells and even I could do it) and can be run on virtually any operating system. It’s popularity has resulted in the availability of thundreds of contributions, modules, and addons for PHP to increase its functionality and integration with other software. It’s also free to download and easy to install (for most people), and is the most common in CMS’s and prebundled website software.

The major downside to PHP is that it’s so popular that security holes are being found all the time. Its very nature requires some configuration changes and restrictions in order to boost security.

Perl

Perl is one of the oldest and most successful languages to date. With thousands of modules that can be added, it can pretty much do anything. While it’s currently not as popular as PHP, it’s more efficient for server management in its double use as a shell scripting language. It’s also open-source and compatible for most all OS’s. The only real downside is that it’s not as quick and easy to learn, and even the simplest tasks can take more programming and lines of code to accomplish. Also, the camel logo is fugly.

ASP/VBScript

I’ll try to be nice about this one. Really, I’m not an ASP fan mainly because it’s proprietary to Windows and IIS. That being said, I’m sure you can figure how secure and reliable it is. It’s not as actively maintained by its developers (Microsoft) so major bugs have been known to linger for months — unacceptable for busy webmasters trying to manage professional websites. While ASP, .net, and VBScript (aka the ASP family) are all “free”, if you want any of the fancy addons or modules for them you’ll be owing Microsoft a nice little licensing fee. On a positive note, Chilisoft has made is possible to port ASP over to Linux, so it’s no longer 100% platform dependent.

JSP

Java Server Pages (developed by Sun) is more similar to the ASP framework, but targeted towards Java fanatics. Out of all the programming languages I’ve studied in school, JSP is probably my least favorite. Not only is it hard to learn, but there’s no such thing as simplicity with it. However, it’s very powerful software and is platform-independent, as long as you have a Java Environment for it to run in. Tomcat (an Apache Project) is the most common servlet container for JSP. But, Java takes up a lot of memory and JSP servers are very difficult to maintain and administer for non-experts.

Ruby

Ruby is one of the newer programming language to hit the web developer market, and it’s actually quite close in concept to PHP except that it’s 100% object-oriented, and very clean because you don’t need as much punctuation. It’s also very beginner-friendly, and is growing in popularity. The main disadvantage to Ruby is that it’s difficult to troubleshoot runtime errors because its reluctance to declare variables before their use. And being that it’s a newer language, there are definitely less resources available and not as many applications currently employing Ruby as a framework. However, it is cross-platform compatible, easy to install, and even easier to learn.

Python

I really don’t know a whole lot about Python other than that expert programmers claim that it’s such a strong language. I personally think it’s crap…my one shot at Python and I find out that it’s very whitespace/tab sensitive, so one extra space can ruin your program. Coming from PHP I don’t find that very appealing…I personally think it’s a mistake, and that its developers just call it a ‘programming guideline’ since they can’t figure out how to fix it. Really, there’s no huge benefit in using Python other than for your Google sitemaps, so all I’m going to say is steer clear.

HTML

I put this at the bottom of the list because I don’t really consider it a programming language, but it is the more predominate and widely used language that all the others revolve around. I do think it’s important that every programmer become an expert in HTML before going dynamic with their coding. While other languages rely on HTML for output, it’s very common for sites to be purely HTML and nothing else. However, HTML is a static language with no dynamic capabilities in itself whatsoever, so it’s somewhat boring on its own

Client-side

In a category all its own, there are several client-side languages that augment the others. Client side languages no require any server-side software to be installed, just a browser capable of interpreting them. CSS (Cascading Style Sheets) is a language primarily used in formatting and creating a uniform and repetitive style for use across multiple pages. JavaScript is a mini-java language used to create mild effects for a website, like popup windows and form validation. I also consider it to be very insecure, so it should be used sparingly. AJAX is a newer JavaScript framework that is more appealing to the eye and lets you create those special effects that you see on many web 2.0 sites…things like refresh-less page loading.

Earlier I showed some examples of commands you can use to pull software versions into a simple PHP script. In the next example I’ll show how to do the distro and kernel versions. I’m sure that there’s a much simpler way to do this (i.e. a simple cat command on the /proc/version file), but I figured I’d use a more advanced example in the form of a function. I did the distro as a variable to show how easy this is:


<?php
function kernelinfo () {
$buf = exec( 'cat /proc/version');
if ( $buf == "ERROR" ) {
$result = "N.A.";
} else {
if (preg_match('/version (.*?) /', $buf, $ar_buf)) {
$result = $ar_buf[1];

if (preg_match('/SMP/', $buf)) {
$result .= ' (SMP)';
}
}
}
return $result;
}

$distro = exec('cat /etc/redhat-release');

$kernel = kernelinfo();

echo $distro;

echo "<html><br></html>";

echo $kernel;

?>


This will show a result of the following, obviously various depending on your platform:

CentOS release 4.5 (Final)
2.6.9-023stab033.9-enterprise (SMP)

Keep in mind that this script (as the last) requires the ability to pass shell commands through PHP. So, you would need to be able to the exec function, or replace it with system, passthru, escapeshellcmd, or shell_exec if those are allowed in your php.ini configuration. Also, if you run PHP as an Apache module, this will not work if you have open_basedir protection enabled.

I’ve been working on this application for work that does some simple server reporting, part of which involves displaying the versions of major software running on the machines. The importance of this to me personally is that since we have over 30 shared servers hosting multiple customers, we are continually moving websites between servers. Some of our older generation servers are still running MySQL 4.0 and PHP 4.3, so I need to be aware of this to make sure that customers are being moved to servers with compatible versions. It’s also good in tracking and planning upgrades.

I find it best to use the exec() function since it’s not blocked by most hosts. However, if you are on a shared host it’s very likely that certain PHP functions are disallowed in the php.ini. In that case you may be able to subsitute exec with system, passthru, escapeshellcmd, or shell_exec…unless those are blocked too. Then I guess you’re out of luck.

Start by creating some variables to store ordinary shell commands. If you wanted to find the php version from command line, you would usually type:

php -v

This will give a huge chunk of crap that you really don’t need if you’re making a simple version display script. In this case, you can use grep, awk, sed, and cut to trim down the output into a one-liner:

php -v |grep built |awk {‘print $2′}

The awk command prints out columns, so in the above example I’m printing out the second column of the line that contains the word ‘built’. Once the desired output is figured out, you simply assign it to a variable passed through exec() or a similar function:

$phpver = exec("php -v |grep built |awk {'print $2'}");

Then you can call the variable $phpver anywhere in your script:

echo "PHP Version: $phpver";

You can probably go through and figure out the commands to show other software versions on your server. In my script I’m showing the perl, php, mysql, apache, python, cpanel, and ruby versions. Here are the commands I used:

<?php

$perlver = exec("perl -v |grep linux |awk {'print $4'}|sed -e 's/v//'");
$phpver = exec("php -v |grep built |awk {'print $2'}");
$mysqlver = exec("mysql -V |awk {'print $5'} | sed -e 's/,//'");
$apachever = exec("apachectl -v |grep version |awk {'print $3 $4'}|sed -e 's/Apache\///'");
$pythonver = exec("python -V 2>&1 | sed -e 's/Python //'");
$cpanelver = exec("cat /usr/local/cpanel/version");
$rubyver = exec("ruby -v |awk {'print $2'}"); ?>

Then I just echoed out all the variables to display my version numbers:

See here .