Unless you’re creating very simple applications, you will soon require one or more PHP extensions. Extensions are code libraries which extend the core functionality of the language.

Loading an Extension

For the purposes of this article, we’ll assume you need to create or manipulate images and require PHP’s GD library. To load the GD library on your system:

• For Windows, you need to include/uncomment the line extension=php_gd2.dll in your php.ini configuration file.
• For Linux/Unix, you should use the PHP configure option --with-gd.
• For Mac OS X … er, you best Google it. Apologies for not providing specific details, but there appear to be multiple ways of configuring GD support. It depends on your version of OS X and whether you’re using the built-in web server or a custom installation of Apache.

But what happens when you want to move your web application to another host or platform where a different set of extensions are configured?

Checking an Extension is Loaded

PHP provides an extension_loaded(name) function which returns true when the named library is available, e.g.

<?php
if (extension_loaded('gd')) {
        echo 'GD extension is loaded and everything is fine!';
}
else {
        echo 'Where is the GD library?';
        exit();
}
?>

Alternatively, you can check for the existence of specific library function using function_exists(), e.g.

<?php
if (function_exists('gd_info')) {
        echo 'gd_info() is available so the GD library is probably available.';
}
else {
        echo 'gd_info() cannot be found?';
        exit();
}
?>

However, function_exists() is more risky — another developer could write their own function named ‘gd_info’.

I’d recommend using function_exists() in situations when a function has been introduced in a later version of PHP. For example, if your application runs in both PHP4 and PHP5, you could check for the existance of imagefilter() (a PHP5-only GD function) before attempting to modify an image.

Handling Unloaded Extensions

PHP provides a dl() function for dynamically loading extensions at runtime. Unfortunately:

• it may be disabled on your system
• extensions must be loaded by referencing the filename; these are different across platforms
• it’s a little flaky…
• so it’s has been deprecated in PHP 5.3
• and will be removed from PHP6.

I’d recommend avoiding dl(). That leaves us with three options:

1. Ensure the extension is enabled on all your target platforms before coding begins!
2. Alert the administrator when an essential extension is not available during installation. For example, your application should stop gracefully and provide further instructions if it won’t run without the PDO database interface.
3. Provide a downgraded experience. For example, your application could disable image manipulation if the GD library is not available. You could alert the administrator during installation but still let the application run.

Do you have any other tips for handling missing PHP extensions?

Related Posts

1. Introduction to PHP 5 PDO
2. Mozilla Jetpack: Firefox Extensions with Added Thrust
3. Chrome Extensions Likely by May

Being the verbose kind, I guess I will put in a summary at the top leaving the original post below for everyone to read all the little details. Essentially the summary is that I (and many other core developers) agree that HEAD/trunk in its current form was stalling future development on PHP. Jani indirectly jump started the discussion of moving this stumbling block out of the way by essentially doing two commits that violate the most fundamental rules of PHP development (and common sense courtesy) we have. I am worried that this will lead to confusion in the user base and other seem to think that the "ends justify the means". I also think that we need clearer processes to make it easier for new developers to have a clear path to follow in order to get things done in PHP.

Full story:
So this all requires a bit of background. I still remember my first contact with a PHP core developer. I do not quite remember the year, but it was quite some time ago. Anyway Jani was great, we filed a bug report on the imap extension. He fixed the bug in no time. IIRC we also ended up sharing a room at the second IPC in Frankfurt I attended. I think only a few years later I realized that Jani is the same guy a lot of people were complaining as being rude. But I guess few of these people realize how much time Jani has spend on verifying bug reports and what a tedious job this is, especially since most bug reports are quite low on the actual relevant details and come with a "fix my code for me, now!" attitude. In other words, I get along fine with Jani and I have great respect for his contributions to PHP.

Next piece of background. I am also one in the long list of people that has made a fool of himself by predicting a release of PHP6 in about 18 to 24 months (quite a few people have given this prediction over the past 3-4 years I guess). I have also been one of the people that has tried to motivated people at various times to finish those last 2% that seem to be missing to complete PHP6 in terms of functionality. As such I have opposed a PHP 5.4 because I felt its time to focus on finish up PHP 6 which we have promised people for so long. After releasing 5.3.0 I was hoping things would happen. But last weekend I came to the realization that we have waited long enough. That even if PHP 6 would be unicode bliss (at least in terms of features, probably not in terms of performance), the fact of the matter is that in all of the many years nobody put in the time to finish it. This imho is an indirect proof that the approach taken apparently does not hold enough merit to the world in general. Furthermore looking at internals since last summer it has been more dead than ever: PHP 6 aka HEAD aka trunk had become such a motivation killer that nothing was happening.

At the same time I knew that suggesting to move trunk to a branch and copying 5_3 to trunk would cause a lot of confusion. Not only among those reading internals, but also that this would quickly make it to the news sites of the world. Call it politics, marketing or just an unwillingness to cause thousands (millions?) of PHP developers distress and uncertainty, but I figured it would be better to propose this with a semi solid plan and giving a number of PHP core developers the heads up that I will bring this to the list, so that they also could prepare themselves. So I started talking to people offlist, either in person, via phone, via IRC/skype or via email with the full intention of going to the list no later than the end of this month, ideally sooner rather than later. I should also note, I do not code C, I also do not consider myself a unicode expert. So if I wanted to present a plan, I obviously needed to talk to people to get my facts straight.

Anyways, this week Jani decided to commit a patch. I guess I didn't mention one more piece of background. Jani had asked to get this patch into PHP 5.3 during the pre alpha stage, but at the time Johannes and I (I was co-RM back then) felt that the patch hadn't been tested enough in HEAD and that while we knew the patch fixes several bugs, we felt the risk of introducing new bugs was too high, especially since Michael who wrote the original patch for HEAD was not always around to fix things. Johannes had tried to get the patch into 5.3 six months earlier, but at the time nobody had time to do the work. So we decided to stick with the known bugs, instead of fixing them and risking new bugs in a very core component of PHP close to going alpha. So basically Jani committed a huge patch into a stable branch, without talking to anyone about this, despite knewing full well that the RM had specifically vetoed this patch in principle. Furthermore the patch from my understanding even breaks the ABI which makes the patch even more a no go.

No

Truncated by Planet PHP, read more at the original (another 6351 bytes)

Here is a list of various articles about PHP-GTK2, recently updated:

• 2009-11-02 : Deploying a PHP-GTK application with NSIS, by Matthew Casperson
• 2009-07-07 : Beginning PHP-GTK: Signals, on Codecall.net
• 2009-06-29 : Beginning PHP-GTK: Creating a Simple Interface, on Codecall.net
• 2009-04-25 : Building PHP-GTK with Cairo Support on Ubuntu Jaunty, on IShouldBeCoding.com
• 2009-03-28 : Distributing PHP-GTK applications on Windows (not a reference to Gnope or Scott's chapter on the subject)
• 2009-01-25 : building PHP-GTK 2 with PHP 6. A set of patches and an explanation
• 2008-03-05 : a fresh intro to PHP-GTK by Bob Majdak
• http://www.developertutorials.com/tutorials/php/building-desktop-applica...

read more

Voici quelques articles sélectionnés à propos de PHP-GTK2&nbsp:

• 2009-11-02 : Déployer une application PHP-GTK avec NSIS, par Matthew Casperson
• 2009-01-25 : comment compiler PHP-GTK 2 pour PHP 6. Un jeu de correctifs et une explication
• 2008-03-05 : une introduction à PHP-GTK 2 par Bob Majdak
• http://www.developertutorials.com/tutorials/php/building-desktop-applications-in-php-8-02-01/page4.html

en lire plus

So, every once in a while I find myself in need of trying out newer, maybe, not-yet-released features in PHP. For example, recently, I wanted to test RoundCube PHP6 — this is how I did it.

On a side note, the same setup would also work for testing code with previous versions of PHP.

Toolbox

I used nginx and the PHP source with a little bit of ./configure and make — for kicks!

My O.S. of choice is FreeBSD and therefor the installation steps covered are tailored to it. With a small amount of Linux/Unix-fu, anyone should make it work on another distribution regardless.

Install nginx

First off, install nginx. On FreeBSD, this should be all:

• cd /usr/ports/www/nginx-devel && make install distclean

On other systems, this maybe a:

• apt-get install nginx
• emerg nginx
• rpm -shoot-myself nginx

The next step includes the infamous spawn-fcgi which many people use to control the php-cgi processes. A lot of tutorials on the net suggest to install lighttpd because it's a part of it, but on FreeBSD, you may skip that and do the following instead:

• cd /usr/ports/www/spawn-cgi && make install distclean

Pretty cool, huh?

So once this is done, the usual tasks need to be completed — in no particular order:

• edit the nginx config and enable fastcgi in nginx (/usr/local/etc/nginx/nginx.conf)
• enable nginx itself in /etc/rc.conf (nginx_enable="YES")
• get another nifty start script (see Shell Script) to wrap spawn-cgi

... and done!

After my colleague Cal reviewed DPC's tutorial day, it's now my turn to look back at the first real conference day of 2009's Dutch PHP Conference.

The day started with a nice movie made by Almer and Norman after which Cal officially opened the Dutch PHP Conference and introduced Andrei Zmievski to do the opening keynote. Andrei gave an outline of developments in PHP including the changes we are going to see in future versions. Closures, namespaces, better garbage collection and a few more things are coming to PHP5.3, but I think this isn't new to most people. I haven't really read a lot on PHP6 yet other than Unicode, so the addition of traits, C# style getters and setters and scalar/return value type hinting were new to me. I think this was a nice talk to be the opening keynote, because other than just being infomrative the talk also had the right amount of humor with some examples of frustrated people reporting "bugs" and a setting for y2k compliance. I wasn't active in PHP 10 years ago, but it made me laugh when I heard that the y2k_compliance setting basically did nothing other than stop people asking about it.


Continue reading "DPC 2009 Day 1"

After my colleague Cal reviewed DPC's tutorial day, it's now my turn to look back at the first real conference day of 2009's Dutch PHP Conference.

The day started with a nice movie made by Almer and Norman after which Cal officially opened the Dutch PHP Conference and introduced Andrei Zmievski to do the opening keynote. Andrei gave an outline of developments in PHP including the changes we are going to see in future versions. Closures, namespaces, better garbage collection and a few more things are coming to PHP5.3, but I think this isn't new to most people. I haven't really read a lot on PHP6 yet other than Unicode, so the addition of traits, C# style getters and setters and scalar/return value type hinting were new to me. I think this was a nice talk to be the opening keynote, because other than just being infomrative the talk also had the right amount of humor with some examples of frustrated people reporting "bugs" and a setting for y2k compliance. I wasn't active in PHP 10 years ago, but it made me laugh when I heard that the y2k_compliance setting basically did nothing other than stop people asking about it.


Continue reading "DPC 2009 Day 1"

I am such a torment. Cancelled negotiations with a publisher over disagreements on a book format? Check. Said no to taking down a free book startup and enter a publishing contract? Check. Lambasted multiple publishers for releasing PHP 6 books which do not teach anything PHP 6 specific? Check. Next month I expose which publishing companies are secretly building weapons of mass destruction in their basements. Reverse that, I can't afford a libel suit...

In "The Art Of Deception Or Publishing PHP6 Books" I aired my unflattering opinions about publishers who have been selling "PHP 6" books. PHP 6, last I checked, was a bit like Leprechauns (Hey, I'm Irish! The use is legal!). You love them, you have lots of ideas about what to expect from them - but has anyone every really seen one (other than my great uncle)? PHP 6 exists in CVS - it's never had a release other than the usual CVS snapshots. It's certainly not complete and stable, and its future feature list remains a bit flexible. You could see PHP 5.4 in 2011 before PHP 6 is finished...guessing here. As its developers would say - it'll be ready when it's ready. One day. Maybe.

In response to the blog post, Wrox Press picked up on the problem on Twitter via Davey Shafik (@dshafik). Everyone knows Davey. If you don't, you must have been living under a rock, or a ruby, for a really long time. I have to say, Wrox responded in a wholly unpredicted way I have to admire. It's not everyday you find yourself hiding in a cave in Antrim (it's nice...a little damp though) after seeing something you wrote persuade a publisher to pull back a book destined for the printers, and work on fixing it so it deserves its title.

Here's the full text of the comment posted to "The Art Of Deception..." earlier today by Jim Minatel (Associate Publisher - Wrox). Jim is mostly the person sitting behind @wrox over on Twitter where he's been quite proactive in getting to the bottom of my PHP 6 Book complaints.

Pádraic:

Thanks for taking the time to discuss this with me on Twitter last night. I’m the Associate Publisher for Wrox, I’m the person usually behind @wrox on twitter.

After meeting with the editor who ran the PHP list for us, you’re right. The titles of these PHP6 books, some of the references to PHP6 in the books, what isn’t covered in the books, all prove we made a mistake, something went wrong. But how, why?

Elizabeth (and thanks for her measured response) is correct in part of her assessment that books take a long time to write and publish. I’m sure that when the editor and authors started these books in Spring 2008, they’re thinking was that 6.0 would indeed be a stable release by early 2009 (if not sooner) and they were aiming for that. But clearly along the way we dropped the ball on checking references to things like the non-existent “6.0.0 stable.”

In the Beginning PHP6, MySQL, Apache book, I can actually understand the rationale not to cover Unicode there. Given that Unicode is primarily valuable to someone internationalizing a site or localizing it for multiple languages – topics that I wouldn’t consider “Beginning” level – I can see why it wasn’t covered. (Before becoming associate publisher, I was actually our ASP.NET editor for most of the last 5 years and we don’t for example cover internationalization/localization in our Beginning ASP.NET 3.5.) So we want to have a book that Beginning level customers understand will work with PHP6 if that’s the version they’re using, but we didn’t communicate right what that meant in this context where there weren’t major new v6 features at the level we thought a beginner would need.

The professional book stumps me more. It’s hard for me to understand how that book doesn’t have a chapter on Unicode. It looks like an oversight by everyone involved in the book.

So where do we go from here and get better than this to eventually prove we’re worthy of better than when @bicatu says “That reminds me why I've never bought a Wrox book?”

First, I’ve asked the team involved with Beginning PHP6 scheduled to ship to the printer this week to pull that book back, to read your post and the subsequent twitter discussion and to make sure we aren’t making the same mistake a third time. I want the author and editors to provide a level of confidence that the PHP6 features that should be covered are, that the discussion of the current state of PHP6 is accurate, and the that the title, subtitle, and marketing copy on the book and online accurately reflects what is and isn’t covered.

Second, publishing the ri

Truncated by Planet PHP, read more at the original (another 1839 bytes)

I was strolling around a bookstore today, Easons on O'Connell Street here in Dublin, when I found myself staring at a bookshelf in near shock. Kid, I thought, you've been out of the loop for only two months and somehow those crazy people have managed to release PHP 6 right under your nose! I took several deep breaths not quite sure how to react. I moved closer and pulled out the shiny red book published by Wrox titled "Professional PHP 6" and prepared to kick myself silly for the next week learning PHP6 (not from the book, which while shiny is of little use to someone using PHP so often it's hardwired into your brain).

The more I stared at the three youthful faces grinning at me from the cover, the more I convinced myself this was a publishing error. No way was PHP6 going to be released without me noticing. Google Reader would have been on fire with that news. So what the hell was I looking at?

I was apparently looking at a big fat lie.

PHP6 has been the long standing grail for PHP developers who whisper in corners about its major feature: Unicode! Unicode makes the planet revolve, well its literary parts anyhow... Out on the edges were numerous other features, but most of those have been rolled into PHP 5.3 - which should be released next Tuesday. PHP 5.3...next Tuesday. And here we have books titled PHP6...what a joke. PHP6 won't see so much as an alpha release for months...could even be years for all I know. It will be ready when it's ready.

My biggest question of course was how can publishers escape punishment for such obvious silliness? Maybe someone can explain it in the comments because I'm at a loss. I figured there was some justification in that PHP6 would undoubtedly support some backwards compatibility with PHP 5, and therefore you could learn a great deal of PHP 6, simply by learning PHP 5. After all, both are PHP. Or perhaps it's all the disclaimers technical books can include to escape responsibility if the information in the book is wrong. This might be sufficient to get around the laws of any number of countries, like Ireland, but I don't consider it honesty. In my opinion it's blatantly obvious that the PHP6 references used in book titles are little more than an attempt to differentiate these books from their competitors and earlier editions. Enough to fool a lot of consumers that buying the PHP6 book must be better than buying the perfectly up to date PHP5 book sitting in the bargain bin or available secondhand from Amazon. We are in a recession afterall and who banked on PHP 5.3 dropping a bombshell on plans for PHP6 books to spark a buying spree from developers?

Now, even I admit my outrage can be exaggerated. So I did go and pick up a few sample books using PHP6 in their title out of curiousity. Flicking through the pages I quickly noted how many of them avoided the PHP6 topic like the plague by omitting obvious things you'd expect to see. Unfortunately I also found a few notable slips which had me in stitches. Installation instructions and version listings are the most telling

The Wrox Programmer To Programmer series includes the far fetched title "Beginning PHP6, Apache, MySQL Web Development" (Timothy Boronczyk, Elizabeth Naramore, Jason Gerner, Yann Le Scouarnec, Jeremy Stolz, Michael K. Glass). The installation instructions for Linux state:

6. Extract the tarball, and change to the directory it creates:
tar -vxzf php-6.0.0.tar.gz
cd php-6.0.0

Number 3 earlier on the same list states:

3. Scroll down to the Complete Source Code section, and click on the appropriate link to download
the latest tar.gz package.

Perhaps someone didn't notice that the download here (as of today) according to php.net is PHP 5.2.10? Not PHP 6.0.0.

Earlier the same book states:

The most recent stable versions that were in effect at the time of this book's writing were:

PHP: Version 6.0.0
Apache: Version 2.2.9
MySQL: Version 5.0.67

Future editions of this book will address changes and improvements in these programs as they become
available.

Again, the non-existent PHP 6.0.0 makes an appearance clearly noted as being a "stable version". Of course, this is complete bollocks. The rest of the book seems pretty clearcut. It doesn't mention PHP 6 anywhere else except in two Chapter titles according to its index. PHP 5.3 is mentioned once in a brief description of namespaces. Everything else is PHP...drumroll...5. This book teaches you PHP5 and only PHP5. Look on the bright side - the Wrox website and Amazon page suggests the title should have included MySQL 6... All they needed was the equally mystical appearance of Apache 6 to get the conspiracy theorists worked up into a fever pouring through the Book Of Rev

Truncated by Planet PHP, read more at the original (another 1324 bytes)

PHP 5.3 is just around the corner with a lot of great new features. However, even if I'm really excited about this new release, I won't make yet another PHP 5.3 feature list; I will rather look at the future of PHP. PHP core developers met at php|tek and discussed the future of PHP. And it is really great to see that they plan lots of wonderful features; let's set aside the Unicode stuff.

They published some notes from the meeting, and here is my personal list for things I find really interesting:

• Add __cast() magic method that will be called for all casts. If the __toString() method is there it will get used for string types first.

• Consider making a "callable" type.

• Make ArrayObject and ArrayAccess accepted everywhere regular arrays are.

• Add traits support.

• Add type hinted return values, scalar type hints.

• Make function call chaining possible (f()() if f() returns a function), and array dereferencing (f()[0]).

• C#-style properties with getters/setters:

  class Foo
  {
     public $bar
         getter { return $this->bar; }
         setter { $this->bar = strtolower($value); }
     ;
  }