For the past couple of weeks, I have worked on creating a PHP library to create ICO files. This has been difficult as all the documentation for the ICO format is either sparse or not completely documented.

I’m doing this since I have yet to find a way of creating a valid favicon file using just PHP and PHP’s GD library. Sure, I can create a PNG file and change the extension to “.ico”, but that doesn’t work in all browsers, on all operating systems (such as Windows XP), and is more of a hack than a valid method for creating favicon files.

So, it is time to make one. I have a placeholder github repository named php-ico.

The primary goal is to make a robust, reliable library that creates valid ICO files that can be properly rendered on Windows XP+ and all the major browsers. Thus, my initial goal is not to support every format that exists nor is it to support parsing the ICO files. If the project gets enough attention, I’ll look at expanding the scope.

Here are the resources that I’ve found helpful as I’ve worked on this project:

• ICO (file format) – Wikipedia article about the ICO file format. This has a very comprehensive description of the ICO header. It is sparse on details about the format of the image data.
• BMP file format – Wikipedia article about the BMP file format. This helped me understand the headers and pixel data format for the BMP image data.
• Portable Network Graphics – Wikipedia article about the PNG file format. This gave me what I needed to know to identify PNG image data.
• Windows Bitmap File Format – Very good article that delves into more details about the BMP file format. The extra details about the different types of headers, compression methods, compression encoding, and examples were very helpful.
• Icons – A Microsoft Developer Network article from 1995 that provides the original ICO file format spec. While this is the most authoritative, I really didn’t find this to be as much help as other sources.
• Replacing ICON resources in EXE and DLL files – Article from The Code Project that has a breakdown of the format similar to what is found in the MSDN article. Example C code is provided.
• Support Vista-style ICO files – Mozilla Bugzilla filed bug. The discussion has some great information about methods used to reliably parse varying ICO formats and structures. It also has some good test ICO files to try.
• Convert HBITMAP to .ICO file – This Chironex Software blog post provided the last piece I needed: how to structure the opacity mask data. Where he found this information (since I didn’t find it in any of the above articles) I haven’t a clue.

If this post gets some traction and interest, I’ll consider putting together a post detailing all the different pieces I’ve found here. I’m not a spec writer, but I’d try my best. Let me know if you’d like to have me work on this.

I’m working on building an ideal server setup that allows for both PHP 4 and PHP 5 on Apache with suPHP (I’ll blog about this later). While testing my PHP 4 build, I got the following error:

Warning: mysql_connect() [function.mysql-connect]: Client does not support authentication protocol requested by server; consider upgrading MySQL client in /var/www/test-php.php on line 3
Couldn’t authenticate with MySQL

The code I used to test this is quite simple:

<?php

if ( false === ( $db = mysql_connect( 'localhost', 'username', 'password' ) ) )
    die( "Couldn't authenticate with MySQL" );

if ( false === mysql_select_db( 'database' ) )
    die( "Couldn't connect to database" );

echo "Yay!";

?>

After digging around for a bit, I found that mixing PHP 4 with a MySQL version greater than or equal to 4.1 causes this problem. MySQL 4.1 introduced a new password caching scheme that PHP 4 can’t work with.

The solution is to update the database user’s password using the OLD_PASSWORD function of MySQL. For example:

[chris@office ~]$ mysql -u root -p mysql
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 267
Server version: 5.1.41-3ubuntu12.1 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> update user set Password=OLD_PASSWORD('password') WHERE User='username';
Query OK, 0 rows affected (0.02 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql>

Note the underlined areas. That is where you’ll want to provide your own username and password.

Once you’ve followed these steps, both PHP 4 and PHP 5 will be able to communite with the database.

Thanks to digitalpeer for providing the answer to my issue.

PEAR is PHP’s equivalent of Perl’s CPAN. It offers hundreds of ready-to-use code modules that can make projects go much more quickly than having to hand code everything. However, it never seems like PEAR is easy to get running.

Installing the Needed Software

In Ubuntu, installing the following packages will quickly get you started with PEAR: php5-cli, php5-dev, and php-pear.

Make sure that you read the next section about problems with using PEAR to install PEAR packages if you are running 9.10, Karmic Kaola.

Here’s an example of how to quickly install those packages from the terminal.

[chris@rommie ~]$ sudo apt-get install php5-cli php5-dev php-pear
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
autoconf autoconf2.13 automake automake1.4 autotools-dev libltdl-dev libssl-dev libtool m4 php5-common shtool zlib1g-dev
Suggested packages:
autobook autoconf-archive gnu-standards autoconf-doc gettext libtool-doc automaken gfortran fortran95-compiler gcj php5-suhosin
The following NEW packages will be installed:
autoconf autoconf2.13 automake automake1.4 autotools-dev libltdl-dev libssl-dev libtool m4 php-pear php5-cli php5-common php5-dev shtool zlib1g-dev
0 upgraded, 15 newly installed, 0 to remove and 5 not upgraded.
Need to get 0B/8,690kB of archives.
After this operation, 27.7MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Selecting previously deselected package m4.
(Reading database ... 127272 files and directories currently installed.)
Unpacking m4 (from .../archives/m4_1.4.13-2_i386.deb) ...
...

With these packages, you are ready to roll with PHP and PEAR in Ubuntu.

Problem with Ubuntu 9.10 Karmic Kaola

A great thing about PEAR is that you can quickly install packages with a simple command. For example, “sudo pear install PHP_Parser-0.2.1″ will install the PHP_Parser package. However, this doesn’t work properly in Ubuntu 9.10, Karmic Kaola.

Output of the standard PEAR install command can be seen below:

[chris@rommie ~]$ sudo pear install PHP_Parser-0.2.1
downloading PHP_Parser-0.2.1.tgz ...
Starting to download PHP_Parser-0.2.1.tgz (70,782 bytes)
.................done: 70,782 bytes

While this doesn’t look wrong, it has actually failed. Rather than installing the package, it has simply downloaded the archive, encountered an unchecked error, and crashed. A successful installation has a message saying that the installation is successful.

This problem can be easily fixed by giving the install command the “-Z” option. For example:

[chris@rommie ~]$ sudo pear install -Z PHP_Parser-0.2.1
downloading PHP_Parser-0.2.1.tar ...
Starting to download PHP_Parser-0.2.1.tar (Unknown size)
.............................................................................done: 533,504 bytes
install ok: channel://pear.php.net/PHP_Parser-0.2.1

Notice the “install ok: …” portion of the message. That’s what you should see at the end of a successful installation.

For more details on this bug, please check out Bug #451314 on the Ubuntu bug tracker.

Sorry about the late post everyone. I had a long week and went to bed before making sure a post was queued. Hopefully you’ll forgive me.

I’m working on a project where I needed to generate a MIME type given a file name. Not only did I need to create a solution that worked, I also needed the solution to be compatible with PHP 4/5 and not require any additional software to be installed on the host. I thought this would be a simple matter of finding a PHP function that does this. Unfortunately, things were not as simple as this.

Problems with finfo_open

I found a very helpful PHP, Mime Types and Fileinfo post on Jelly and Custard. The “Mime Types in PHP 4.x” seemed to be exactly what I wanted. I quickly tried it out on my server, and it failed instantly with the following error:

Since I have PHP 5.2.6 running on my dev server, I was very confused since the post said that this was a “PHP 4.x” solution. I pulled up the PHP doc on the finfo_open function and was very surprised to see that the function is a PHP 5.3.0+ function. Fortunately, my version of PHP was just before this so that I could actually catch the error.

Turns out that the Jelly and Custard post points to another post, Installing PECL Modules, where instructions are given for installing the Fileinfo PECL Package. Installing this package allows versions prior to 5.3.0 to use the finfo_* functions via PECL.

This is not what I want. I’m working toward a solution that doesn’t require the installation of any additional software, and so far I’ve only seen solutions that require this. There has to be a better way.

Problems with mime_content_type

I then found the mime_content_type function. This looks better. However, PHP has marked this function as deprecated due to the PECL Fileinfo package. Relying on a deprecated function has numerous problems: it may throw warnings if used on versions of PHP that know the function is deprecated, most likely won’t receive any updates in the future, and could possibly be removed from future versions of PHP.

In addition to the deprecated issue, the mime_content_type function is laced with problems. In order to use the function the PHP on your system must have been built with the “--with-mime-magic” option. The function also relies upon the “mime_magic.magicfile” ini configuration to tell it where to find the magic file used to detect the MIME type of the file. This magic file may or may not exist/may or may not be readable.

Initial Testing

These problems led to interesting results when I tested it on my CentOS dedicated and Hostgator servers.

On my CentOS 5.2 dedicated server, I have PHP 5.2.6. The PHP build on this server was not built with the “--with-mime-magic” option, so it doesn’t have access to the mime_content_type function at all. In addition to this, since the version is just before 5.3 and I haven’t installed the Fileinfo PECL package, my dedicated server does not have access to either of the official PHP solutions without installing additional software.

On my Hostgator shared server, I have access to PHP 5.2.8. Unlike my dedicated server, this server’s PHP build was built with the “--with-mime-magic” option. “This is great,” I thought. I ran a test, and the mime_content_type function did indeed exist. Like my CentOS server, my Hostgator server does not have the Fileinfo PECL package and does not have PHP 5.3, so the finfo_* functions are no go.

I did some more testing on my Hostgator server and was disappointed to find that the mime_content_type function exists yet is completely worthless. I tested file after file ranging from simple text files, to HTML documents, to a variety of image types. Every single test failed to produce a MIME type. When I say “failed”, I don’t mean that the program crashed with an error. The failure was worse than this, it simply returned an empty string to every single request.

I found that my Hostgator server’s PHP is set up to use the “/usr/local/apache/conf/magic” file to do it’s MIME magic. However, this file is not able to be read by my user. This means that the version of PHP might as well not have been built with the “--with-mime-magic” option at all.

It seems clear to me by now that there will not be an easy solution to this problem.

Final Solution

What I need is a solution that will first try to use the Fileinfo functions since they are the current standard. It will then fall back to using the mime_content_type function if and only if the function exists. Since the function is deprecated and PHP versions don’t actually package the replacement functions natively until 5.3.0, I need to also protect the code against conditions where neither Fileinfo nor mime_content_type are available. The final fallback will be manually generating the MIME type based upon an array match.

Using the fallback is not desirable since I probably won’t be updating the MIME types in the array very often, if at all. However, having it is better than having the code completely fail for common, present day MIME types. Hopefully, the conditions necessary to rely upon this fallback will become more and more rare as time goes on.

In addition to checking for the existence of the functions I’ll try to use, I need to make sure that the methods tried actually produce results. If a method fails to produce a non-empty value, I’ll move on to the next method.

The Code

I got the original idea for this code from a comment by svogal on the PHP doc site. I modified it to match my desired final solution.

The code is far to large to post here. You can download it here.

The array that I built for the mime types is quite large. Since I have a /etc/mime.types file (which is standard in most distros and provided by the mailcap package), I simply used it to generate my array. I quickly built a Perl script that parses through the mime.types file and outputs a file containing the PHP code to create the array. This script makes it easy for me to update the array any time the mime.types file is updated.

You can download my Perl script here. Simply run “perl generateMimeTypes” from the command line to build the array. The array code is put in a file called mime_type_var.code.

Examples

Simple Use

The code is fairly simple to use. Simply include or require the code in your own script and then call the get_file_mime_type function by passing the file’s path as the parameter.

This produces the following output:

Note that PHP’s more advanced functions have the ability to dig into the content of the file to identify the MIME type, so if your system can make use of those functions and the file is not a JPEG image, the results could vary.

Using the debug Parameter

I’ve also provided a debug parameter that allows you to also get information on what method was used to get the MIME type. This may be helpful if you need to determine how sure you are that the detected MIME type is accurate. When the debug parameter is used, an associative array will be returned with a mime_type key and a method key.

This produces the following output:

The possible methods are: fileinfo, mime_content_type, from_array, and last_resort. The first two should be self-explanitory. from_array means that the resulting MIME type was pulled from the array built into the function. last_resort means that the type could not be identified which results in a generic MIME type of “application/octet-stream” being used.

Conclusion

Frankly, I’m disappointed in the solutions provided by PHP to detect MIME types. I have access to a very stable, highly-regarded shared host and an extremely powerful, up-to-date dedicated host, neither of which have the ability to use either of the PHP solutions to detect MIME types without adding additional software.

I don’t remember which version of PHP my dedicated box started with, but I did upgrade to 5.1.6 using the standard repository back in October. I was only able to update to 5.2.6 by using the Utter Ramblings repository by Jason Litka. True, I could compile and install 5.3 or the PECL package myself, but I produce software for people who don’t have a clue what a compiler is, let alone what repositories or PECL extensions are.

It’s things like this that make development a pain. I could always just be a jerk of a developer, have the line “requires PHP 5.3+”, and tell all people that can’t run the software to check the requirements. However, I think that my job is to make the end-user’s life easier, not more complicated.

Hopefully others that have had woes dealing with this situation can make use of my code, and we can all just wait a few years until the majority of hosts have a PHP version that supports these calls natively.

Yesterday, I talked about how to get the most out of running regular expressions in PHP. The reason that I needed to dig in deep on regular expression syntax with PHP is because I needed to write some regular expressions that deal with Unicode characters.

After much reading, I believed that I knew everything that I needed. I started writing some regex strings and testing the code. Unfortunately, every time I ran a test with a string that contained Unicode characters, the match failed. When I removed the Unicode characters from the string and tested again, it would work. I was baffled.

Finding the Problem

I had the regex testing characters (‘\X’, ‘\pL’, etc) inside of a character class, such as ‘[\X-]‘, since I was creating a regex to test for domains. I wrote a really simple rule by simply looking for ‘/^\X$/’ and testing the regex with a single Unicode character. Amazingly, having the ‘\X’ outside of the square brackets changed everything as I now received the following very concerning warning:

Since PHP uses the PCRE engine to run regular expressions, I started to dig into it. I found out that I could query PCRE directly. I ended up with something very similar:

It looked like the error was coming from PCRE itself. I searched around for a while thinking that I could simply install a new package using yum. I hoped to find something like pcre-utf8, pcre-unicode, php-pcre-unicode, or something to make it simple and quick to add this support since I much prefer using package management tools rather than compiling and installing from source.

Unfortunately, no such package exists. This support is something that must be an option that PCRE is compiled with, and my CentOS repository only has packages that don’t include that support. After much digging around, I found that this isn’t necessarily CentOS’s fault as this package has carried over from the RHEL (Red Hat Enterprice Linux) side of things.

A great way of checking to see if this is an issue on your system is by running the following:

$ pcretest -C
PCRE version 6.6 06-Feb-2006
Compiled with
  UTF-8 support
  No Unicode properties support
  Newline character is LF
  Internal link size = 2
  POSIX malloc threshold = 10
  Default match limit = 10000000
  Default recursion depth limit = 10000000
  Match recursion uses stack

This is the output that I received. Notice the “UTF-8 support” and the “No Unicode properties support” lines. This means that PRCE was compiled with the “–enable-utf8″ configure option which allows PCRE to recognize and work with UTF-8 encoded strings. However, it wasn’t compiled with the “–enable-unicode-properties” configure option which works in conjunction with the enable-utf8 option to add support for the ‘\p’, ‘\P’, and ‘\X’ character classes.

This seems to have been an oversight when the rpm file was first put together. Fortunately, there is a way to fix it.

Fixing the Problem

Since I’m sure that many of you are like me and would rather not manually compile and install software outside of the package management system, the solution is to update the rpm to have the option that it needs and install it.

I had never done this before. Fortunately, I found a very helpful guide that details this process out very nicely: How to patch and rebuild an RPM package.

I have provided the new rpm file that I have built at the bottom of this post. If you don’t care about all this jibber-jabber, you can skip down there and grab the file. However, if you would like to learn how to address this issue yourself or have a system that my file will not support, please read on to see how I rebuilt the rpm with the new option.

Rebuilding the rpm

1. The first thing I did is set up my ~/.rpmmacros file and src/rpm folder structure as detailed in the Setup section of the guide that I’m following. I’ll simply refer you over there as it doesn’t need repeating here.
2. I needed to grab the source rpm for the current version of PCRE on my platform. I’m on CentOS 5.2 with version 6.6 of PCRE. I found the matching source rpm file (pcre-6.6-2.el5_1.7.src.rpm) here.
3. I then installed the source rpm in order to gain access to its files:

   $ rpm -ivh pcre-6.6-2.el5_1.7.src.rpm

   This put the necessary files into my ~/src/rpm/SOURCES and ~/src/rpm/SPECS folders.

4. I opened up the ~/src/rpm/SPECS/pcre.spec file and found the following line:

   %configure --enable-utf8

   I changed it to include the Unicode properties option:

   %configure --enable-utf8 --enable-unicode-properties

   I then saved and closed the file.

5. This is the only change that I needed to make. So, now it is time to build the new rpm file. I simply ran the following to build it:

   $ rpmbuild -ba ~/src/rpm/SPECS/pcre.spec

   Toward the end of the large amount of output, I received the following:

   Wrote: ~/src/rpm/SRPMS/pcre-6.6-2.7.src.rpm
   Wrote: ~/src/rpm/RPMS/x86_64/pcre-6.6-2.7.x86_64.rpm
   Wrote: ~/src/rpm/RPMS/x86_64/pcre-devel-6.6-2.7.x86_64.rpm
   Wrote: ~/src/rpm/RPMS/x86_64/pcre-debuginfo-6.6-2.7.x86_64.rpm

   This tells me exactly where I can find my new source rpm and rpm files.

Updated rpm File for CentOS 5.2 64-bit

If you are running a 64-bit version of CentOS 5.2, the following file should work for you. If you have a different architecture, Linux distro, or encounter any errors when trying to install this file, then you should follow the instructions above to build an rpm that is suitable for your distribution.

pcre-6.6-2.7.x86_64.rpm – PCRE 6.6 for CentOS 5.2 64-bit

Installing New rpm

Now that I have my new rpm file, I just need to install it. Since I already have a pcre package installed, I need to tell the rpm command to update rather than install. The following command does this for me:

# rpm -Uvh ~/src/rpm/RPMS/x86_64/pcre-6.6-2.7.x86_64.rpm

Notice that I need to be root to run this command.

Finally, to verify that everything worked, I ran the pcrecheck program again:

$ pcretest -C
PCRE version 6.6 06-Feb-2006
Compiled with
  UTF-8 support
  Unicode properties support
  Newline character is LF
  Internal link size = 2
  POSIX malloc threshold = 10
  Default match limit = 10000000
  Default recursion depth limit = 10000000
  Match recursion uses stack

Looks good.

Finally, time to move on with life.

Since beginning work on my DNS Yogi site, I’ve had to do numerous regular expressions to matching all sorts of string bits. I quickly ran into problems when I realized that I need to add support for Unicode characters since certain TLD registrars support registrations with non-Latin characters.

The main issue is that there are multiple regular expression engines. PHP uses a flavor of the PCRE (Perl Compatible Regular Expression) engine. Each engine and varient of an engine has a slightly different way of handling regular expression syntax. I needed to find out exactly how the PHP regular expression engine worked, and finding that information was not easy.

I’d have to say that there isn’t a single resource that will provide everything needed, and I certainly don’t believe that I can produce and maintain a better one. So, this post will act as a compilation of resources that together provide a robust overview of how PHP handles regular expressions.

• Your first stop should be the PHP Manual‘s page on the preg_match function. This page will get you started on how to run regular expressions using PHP. In addition, you should look at the preg_match_all, preg_replace, and preg_split function references so you get a good overview of what each function can do.
• Next, stop by Regular-Expressions.info and read through their page on PHP to get an outsider view of how PHP handles regular expressions. If you aren’t familiar with regular expressions, you will gain an amazing amount of knowledge about how to build and use them by reading through their Regex Tutorial.
• Now it’s time to really dig in and get dirty on the internals of the PCRE engine that PHP uses. The PCRE Regular Expression Pattern Syntax Reference (PHP preg*) document is an extremely in-depth reference that details the finer points of how the regular expression engine in PHP really works. If you want to know how to build advanced regex patterns in PHP, this is the document for you.

FFmpeg is an amazing collection of open-source tools that can record and stream video and audio. However, it can also transcode video and audio (convert the files to different formats), and that is what has me so excited. There’s also a great PHP package called ffmpeg-php that allows for easy use of FFmpeg from inside PHP scripts. Today, I’m going to see if I can’t help you get both of these set up on your system.

Admittedly, it’s been a while since I’ve tried to install FFmpeg, about two years. I recently thought up some ideas on how I’d like to use FFmpeg, so I thought it was time to give it a try yet again. Today, I’m proud to say that installing FFmpeg is so much easier to install compared to the past, that I dare say it’s simple.

Here is my experience with installing FFmpeg on my server and how to fix the pitfalls that I encountered.

Preface

Note that I did all the following steps on a CentOS server. The specific version is CentOS x64 5.2.

These instructions can work for other distros with little or no modifications, but some distros will be completely different. For example, the DAG RPM Repository that I’m using (more info below) has support for the following distros: Red Hat Enterprise Linux, Fedora Core, Yellow Dog Linux, Aurora Linux, CentOS, Scientific Linux (they really need to get a verified SSL cert), TaoLinux, WhiteBox Linux, Lineox, and BLAG. Other distros will need to use a different repository.

If you successfully get FFmpeg running on another distro, please comment your changes here and I’ll update the post (and make sure you get credit of course).

Also note that I experienced some bumps in the road while installing everything. While many of you may not experience these issues, I found it important to document these problems and how I fixed them in case you encounter them.

Preparing

The first thing that you need to do is set up the DAG repository. This repository is an actively-maintained repository that provides a staggering number of packages with current or near current builds. Adding this repository is a great way to run the latest offerings of many packages.

Adding the DAG repository is simple. I’m using yum, so I did the following to add the repository:

1. Create and open a new file called /etc/yum.repos.d/dag.repo. I ran “vi /etc/yum.repos.d/dag.repo“.
2. Add the following text to the file:
   [dag]
name=DAG RPM Repository
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1
3. Finally, save and close the file.

In order to successfully use the DAG repository with tools such as yum, you need to add DAG’s GPG key. Failure to do so will result in an error like the following:

In order to add the GPG key for DAG, run the following:

The DAG: Frequently Asked Questions page has additional instructions on how to get the repository loaded and working on your distro.

Now that DAG is setup, it’s a good idea to update all your packages.

Depending on the packages you currently have installed, this could potentially upgrade, install, or replace numerous packages that may or may not be very important to you. Make sure you carefully look through that list and do any necessary preparations before telling yum that it can go ahead.

For example, yum told me that it was going to replace my current MySQL interface library for Perl with a new one. I added to my check list a note to verify that my Perl code functioned correctly after the install.

I ran into another hitch when I told yum to go ahead with the update. It informed me that my current version of Subversion conflicted with the new version it wanted to install. When this happens, you need to remove the old package before proceeding. This time, I made backups of all of my repositories and my /etc/sysconfig/svnserve file before proceeding just in case. I then removed Subversion “yum remove subversion“, ran the update process “yum update“, and installed Subversion again “yum install subversion“.

Installing – FFmpeg

Now you are ready to install FFmpeg with yum. I wanted to install all the available FFmpeg packages, so I first asked yum what was available.

Searching through the results, I found that three packages need to be installed: ffmpeg, ffmpeg-devel, and ffmpeg-libpostproc.

Note: If you install ffmpeg-libpostproc, the entire FFmpeg software library changes from the LGPL license to the GPL license.

After a couple of minutes, the packages and the packages that they depend on were installed.

I simply ran “ffmpeg” from the command line, and I took the lack of threatening error or warning messages as a good sign that things were working.

Preparing for ffmpeg-php

I often work with programs through command line calls in code, but I wanted something more robust this time, so I looked around and found ffmpeg-php. Based on the API, it looks to be a great tool to interface PHP and FFmpeg.

There are four things that are required to successfully install and run ffmpeg-php; they are:

• ffmpeg-0.4.9_pre1 or higher
• php-4.3.0 or higher
• gd-2.0 or higher
• php-devel

PHP and FFmpeg should be good to go since at the time of this writing, DAG has PHP version 5.1.6 and FFmpeg version 0.4.9. GD and php-devel can be easily installed by running the following yum command:

In case you are wondering what php-devel is for, it installs the phpize program which is used to install ffmpeg-php.

Installing ffmpeg-php

Now we are ready to install ffmpeg-php. This can be done in six easy steps:

1. Download the latest ffmpeg-php release
2. Extract the archive:
   tar -xjf ffmpeg-php-X.x.x.tbz2
3. cd ffmpeg-php-X.x.x/
4. phpize
5. ./configure && make
6. sudo make install

Finishing Thoughts

This may seem like a lot of work when I earlier described this process as “simple,” but trust me that this is a thousand times easier than when I first tried installing FFmpeg. I think I spent three hours working on installing FFmpeg just to find out that it didn’t work the first time I tried.

Time and time again, package management has proven to be an extremely powerful tool. While I know the value of manually configuring and compiling code, the ease of simply using a package manager can reduce the time needed to install and manage software from hours or days to minutes.

I’m glad to see that FFmpeg has benefited from the use of these package managers and great repositories like the DAG RPM Repository.

I’m working on a project where I needed to convert an XML doc into an associative array in PHP easily. I hadn’t done any work with XML in PHP yet, so I started digging around the usual places.

Soon, it looked like my best option would be to create a completely-custom XML parsing engine out of PHP’s built-in XML Parser. I started working on a set of code based off of the External Entity Example since that is the only example that actually incorporates the ability to retrieve data and not just attributes. My results were slow and very error prone. Why is this so tough? XML isn’t exactly new, and it is very widespread. Similarly, PHP is an extremely popular language. So, why is it so hard to combine the two and work with them easily? I shouldn’t have to create a custom syntax parser just to be able to read a standard format document into a PHP data structure.

I started to look around again. That’s when I found PEAR’s XML_Parser. Great! This looks to be just what I want. It deals with all the junk, and tries its best to just let me traverse the document. I started using the examples and quickly realized something, XML_Parser may work great for a document definition that never changes, but I want something that isn’t rigidly tied down to a very legalistic expectation of data. Is it really so much to ask for just a function that can take the structure and throw it into an associative array so that I don’t have to recode the parser every time the data format changes?

So, my search began anew. This time, I found something that was perfect: two functions that could either take an associative array and dump out an XML string or take an XML string and dump out an associative array. I was amazed since it was exactly what I was looking for. My pain relief came from XML @=@ Associative Array.

Frankly, it looks like ignored code. It’s been around for nearly seven years on that site, yet it hasn’t even had 8000 views? What is wrong with people? IMHO, this type of functionality should be directly built into the core of PHP. Now I admit that this code isn’t everyone’s cup-o-tea, but it should work for about 95% of people that just want to use the data in an XML file quickly and easily into their code.

The code itself isn’t perfect, it doesn’t do enough checking, so it throws massive amounts of warnings. I also found the naming schemes a bit lacking and some of the formatting not quite to my liking. So, I cleaned it up and modified some of the naming conventions. While I was at it, I added the ability to load XML from a file or URL rather than just from a string. Apparently, this was intended based on the given examples but was never implemented. The code is a bit long to post here, so click the download link below to get the file.

Download zipped xmlLib.php

Enjoy.

2009-02-11 Update

WordPress autosave fails me again. I had expanded this post by more than 100% with examples and details of the parameter options for each classes’ methods. Unfortunately, Flash crashed my browser. When I loaded back up, all my changes were nowhere to be found.

I guess that the autosave doesn’t work when you are updating a post. This really should be a feature where modifying a post that has already been published causes new revisions to be saved but not made active. This way I could recover data in the event of a browser crash.

Anyways. I updated the download above. The xmlLib.php file has been updated (check the file for update notes) and I’ve included a test file that will show you a quick example of how to use the two classes.

I had to configure Sendmail in order for Ubersmith to be able to receive support requests via email. Basically, you configure an alias (/etc/aliases) like so:

This all seemed to be very straightforward. I didn’t even think to test it until hours later. When I finally did test out the support request by email function, I received this very abrupt rebuke from Sendmail in the form of a bounceback:

 ----- The following addresses had permanent fatal errors -----
"|php -q -f /home/html/cron/gateway.php domain.com 1"
(reason: Service unavailable)
(expanded from: )

----- Transcript of session follows -----
smrsh: "php" not available for sendmail programs (stat failed)
554 5.0.0 Service unavailable

Not exactly a friendly response.

I dug around a bit and found out that Sendmail places severe limitations on what it has access to. This is actually a good thing since it ensures that you open up possible security holes only if you know what you are doing (or at least think you do).

The solution is to explicitly give permission for Sendmail to not only use PHP but also the gateway.php script. That is done by creating a couple of symbolic links in a special Sendmail folder, /etc/smrsh.

I executed the following code to add these symbolic links:

Notice that I had to create one for PHP itself and one for the script that I wanted to run. If you are setting this up for a script of your own, make sure that you adjust the paths for your own specific setup. PHP may be located in another path on your server. You can find the location by running “which php“.

After I got this setup, the support emails came in like a charm.

Today I’m installing Ubersmith, a billing system solution, on a server to test it out. I have to say that Ubersmith has a more complex installation process than I’m used to these days. I guess that I’ve been spoiled.

Here’s a quick word about what I’m running. My test server is a dedicated system running CentOS 5.2 64-bit. The software setup is nothing special as most of the packages are straight from the repository.

I loaded the release files on the server, untarred them, and proceeded to read the instructions. Everything looked to be straight-forward. I quickly got down to the part about installing Ioncube. That’s when the trouble started.

I followed the instructions for getting Ioncube loaded, quickly modified my php.ini file, and restarted Apache. I then tried to access the site and got nothing. I looked at the logs and found that Ioncube wasn’t loading while reporting the following error:

Frankly, I had no idea what that meant. A bit of searching later, I find that I apparently have the wrong Ioncube loader. That didn’t make any sense since I loaded the exact loader that the ioncube-loader-helper.php program told me to use. I had a hunch that I knew what the problem was and decided to check it out. Yup, Ioncube Loader has 32-bit and 64-bit versions, the problem has to be that the Ubersmith code came with the 32-bit code. I downloaded a Linux (x86-64) archive from the Ioncube Loader packages page, loaded it up, restarted Apache again, and got Ioncube to load properly.

Ioncube was now loaded, but the page still didn’t render. Looking at the logs, I found this wonderful gem:

My first thought was, “great, the software is broken.” A quick google later, I found that mb_internal_encoding is part of PHP, but it is not a defaultly included option. I looked around at how to activate or add it, and everyone was going on about needing to recompile PHP. I’ve compiled everything from simple command-line tools to Apache2, but I always prefer using repository releases as it makes maintenance that much easier, so I was very upset to see that I needed to compile PHP with a new set of options just to run this software.

I was about to give up on Ubersmith altogether when I remembered how many amazing things package management can do. I ran “yum search mbstring” and found that there was a package called php-mbstring ready and waiting for me to install it. I ran “yum install mbstring“, restarted Apache, and finally the Ubersmith setup wizard was ready for me.

So, there are a few key pieces of wisdom that I have learned from my experience with installing Ubersmith:

1. Don’t trust that the installation documents/tools give you all the information you need. Ubersmith made a bad assumption that all systems will only require the 32-bit Ioncube while not making any notes that people on 64-bit platforms need to download new software. Ioncube’s installation helper neglected to check to see if the Ioncube files I had were built to work on my platform, and just like Ubersmith, the helper made no attempt to notify me that I may require different files depending on whether my platform is 32-bit or 64-bit.
2. Never trust that the third-party software packaged with another piece of software is the correct software for your system. If something breaks, first replace that packaged software with software freshly downloaded from the developer’s site.
3. When references say to compile your own software to get something to work, always remember to try using the package management tools first.

As I continued on the setup path, this wisdom had immediate use. The setup wizard indicated that two PHP extensions were missing: Mcrypt and XML-RPC. I immediately ran “yum search mcrypt” and “yum search xmlrpc” which returned positive results. I then ran “yum install php-mcrypt” and “yum install php-xmlrpc” and was golden. Just think if I had decided on compiling my own version of PHP earlier, I would have finally finished, gotten it working, and then had to do it all over again when I ran the setup and hit this snag. Thank you yum.

One thing that I have a gripe about is Ioncube’s navigation structure. I went to their site looking for download links for Ioncube Loader, and could not find them anywhere. I ended asking Google where I could find Ioncube Loader, and like a good little Google, it was right on the first try. I then tried again to find that page in the nav and found it under Products > Free Loaders for Encoded Files. I’m probably just daft, but I skipped right over that stuff because I was skimming the left side of the nav looking for something that started with “Ioncube …” not “Free …” At the very least, put links on the encoder pages that point to the loader page and say, “Looking for Ioncube Loader? Click here.”</rant>