PHP

Testing a new version of IXR

Simon Willison — 2005-05-23T02:58:39-00:00

Almost two years to the day since the last release, I've put together a new version of IXR, my PHP XML-RPC library. I haven't published it on the site just yet as I want to make sure any bugs are ironed out first, but you can grab a copy here:

IXR version 1.7 (beta)

It's mostly a bug fix release, although it also includes some changes made by the WordPress guys who have been maintaining their own fork since January. I've filed a bug asking them to take a look at the new version and maybe roll it in to their codebase.

If you use IXR for anything it would be great if you could run this new version through its paces. Send any bug reports to the usual address.

A big thanks to everyone who sent in bug reports and patches.

PHP 5 is out!

Simon Willison — 2004-07-14T00:13:45-00:00

It's finally here! Unfortunately PHP.net, while a great site in most respects, fails miserably when it comes to permalinks for news items and/or new software releases. You can grab it from their downloads page, and read more about it in the changelog. Now all it needs is widespread adoption. Unfortunately, something tells me PHP 4 is going to stick around for a long, long time.

Simple mini-languages with PHP

Simon Willison — 2004-05-12T21:59:10-00:00

I linked to PDML the other day in my blogmarks, but beyond a cursory glance I hadn't really dug in to what makes it tick. Dumky over at Curiosity is bliss points out that it makes use of an ingenious output buffering trick. To create a PDML document, you add a single line to the top of a page that includes and executes the PDML library (written in PHP). The rest of the document is written in the custom PDML markup language. The script uses output buffering to capture the rest of the page, then executes a callback function that actually processes the page content (see ob_start() for details).

As Dumky points out, this can be used to implement mini-languages for pretty much anything - and PHP 5's excellent XML support means most of the parser work is handled for you. It could also act as a neat way of hooking in to things like server-side XSLT processors.

PHP and Apache 2.0

Simon Willison — 2004-03-31T07:43:53-00:00

For as long as Apache 2 has been stable, the PHP manual has carried this strongly worded warning:

Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows.

I've frequently wondered why they are being so slow to support the new version - after all, Apache 2 provides a bunch of improvements over the older 1.3 and is recommended by the Apache Software Foundation as the best available version.

I finally found the answer today in this comment buried on Slashdot. It seems that one of the key features of Apache 2 is the new threaded worker module which uses threads to serve more requests more efficiently than 1.3's multi-process based server. While the core Zend engine of PHP is thread-safe many of the critical libraries that PHP relies on for its advanced functionality (image processing, database connectivity and so forth) are not, and are unlikely to become so any time in the future. In a threaded environment PHP is likely to suffer from all kinds of unpredictable bugs. Apache 2 can be run in traditional 1.3-style prefork mode but doing so greatly reduces its advantages over 1.3. Combined with the lack of heavy duty testing on Apache 2 and the fact that the 1.3 series will continue to be supported for a long time to come it's clear why the PHP team are unwilling to recommend PHP and Apache 2 in a production environment.

Zend PHP 5 Goodies

Simon Willison — 2004-03-21T21:34:09-00:00

Zend have quietly released a veritable treasure trove of PHP 5 tutorials via their PHP5 InfoCenter:

XML in PHP 5 - What's New? by Christian Stocker
PHP SOAP Extension by Dmitry Stogov
SQLite Introduction by Ilia Alshanetsky
Tidying up your HTML with PHP 5 by John Coggeshall
Com_dotnet by Wez Furlong
Using ext/mysqli: Part I - Overview and Prepared Statements by Zak Greant and Georg Richter

The Tidy functions look particularly useful, especially if you are interested in maintaining clean markup within your PHP applications.

One thing that I would like to see addressed with the full release of PHP 5 is the increasing fragmentation of the PHP manual. The single online manual now covers every version of PHP from 3 upwards, making it increasingly difficult to use effectively if you are targetting older versions of PHP. The Python site maintains archived versions of previous documentation snapshots, making it easy to refer to the documentation of the version of the language you are using. With the major changes between versions 4 and 5 of PHP a similar approach could be highly beneficial.

PHP 5 Release Candidate 1

Simon Willison — 2004-03-19T01:27:51-00:00

I haven't blogged much about PHP in a while because I've been up to my nose in mod_python and loving every minute of it. This news is just too important to miss: PHP 5 Release Candidate 1 has been released, bringing the first production-ready release tantilisingly close. While I doubt PHP 5 will tempt me back it's definitely an exciting upgrade - my biggest complaint with PHP 4 is the brain-dead object model which defaults to copying whole objects rather than passing references, and this is one of the many things addressed by PHP 5. The new libxml2 powered XML features sound really powerful, and SQLite as an on-board database should be ideal for knocking out small stand-alone applications without needing to set up a mySQL database for them.

I may well throw a copy on my Mac over the weekend and try out the changes since version 4.3.

Catching up with Harry

Simon Willison — 2004-02-18T03:56:59-00:00

I'm not sure how I missed this, but Harry Fueck's new book The PHP Anthology was published by SitePoint back in December, as a hefty 2 volume epic. Harry is the guru behind PHP Patterns and really knows his stuff. While the book is at first glance a cookbook for solving web related problems, Harry also uses it as a platform for teaching sensible development practises:

Between the lines I've focused on teaching OOP by example, partly by developing classes in the book and also by taking advantage of Open Source class libraries I'm familiar with; in most cases projects from PEAR.

That's also where I'd say The PHP Anthology is unique, in it aims to get readers to avoid re-inventing wheels already done many times in PHP. Although many of the subjects have been seen before (often online), the focus here is either to use an Open Source class library or put one together, solving a problem once and for all, as opposed a hacked script that goes half way.

Sample chapters from the books are available online, including an excellent explanation of caching techniques. Harry is also one of my co-bloggers over at SitePoint where he writes about (you guessed it) PHP in Dynamically Typed.

PaWS 2004

Simon Willison — 2004-01-06T03:22:55-00:00

Here's an interesting topic for a conference: PHP and Web Standards, to be held in Manchester from February 20th to the 24th. I've devoted a lot of time and energy to combining the two for this blog - it's a shame I'll be out of the country when the conference rolls around. I should be able to make it to SXSW this year though.

XML highlights for PHP 5

Simon Willison — 2003-12-20T23:44:53-00:00

XML in PHP5: An in-depth look into advanced XML features (via Keith) does exactly what it says on the tin. Here are the bits that caught my eye:

HTML Support in ext/xml - PHP 5 can load in not well-formed HTML documents and create a DOM tree from them.
XPath support - and it works with HTML loaded via the above.
XML Validation, including support for RelaxNG! I wonder if they'll support compact syntax.
Extending DOM Classes - this is really cool, and demonstrates how much more mature PHP 5's OOP support is.

Unforuntately, my biggest criticism of PHP remains: all of the above is supported using functions built in to the default namespace! The lack of a smart namespace system (like Python's modules) really gets in the way when you start trying to write reusable code or large applications.

Hacked for Spam

Simon Willison — 2003-12-09T02:56:42-00:00

From the New York Times:

Computer security researchers have been watching the evolution of remote-access rogue programs as they have become more common and have put more machines under the control of hackers. Programs like Sinit infect target machines and surreptitiously open back doors that allow outsiders to control the PC's. The rings of infected computers have been used to send spam, to present online advertisements for pornographic Web sites or to trick people into giving up information like credit card numbers.

In fact, at least a third of all spam circulating on the Internet is now sent from or relayed by personal home computers that have been taken over, said Jesse Dougherty, director of development at Sophos, an antivirus and antispam company.

Emphasis mine. Of course, whether or not you want to believe a director from a company that directly profits from people's fear of security attacks is up to you. That said, I've seen plenty of supporting evidence in the past few months that indicates that spamming is now the number one reason that a cracker would want to take over a PC, not least this Wired article.

Continuing on the same theme, The Rise of the Spammers is a fascinating article by David Barroso Berrueta describing how one of his servers was turned in to a spam relay after being compromised through a vulnerability in a PHP script. The technical details are intriguing; the attacker downloaded and uncompressed a daemon which then communicated with another host using an extended version of the SMTP protocol, receiving spam email bodies along with lists of addresses to send the spam on to.

Let's talk about the PHP vulnerability in question: yet again, it was the classic problem where an attacker can instruct PHP to download and execute code from their own server by feeding in a query string parameter that is passed un-checked to an include() function call. While there are a number of steps that can be taken to deny this kind of attack, it unveils a fundamental problem with PHP itself - that it will execute code retrieved from a URL in the first place! This feature should be removed from PHP - it has almost no purpose in the real world aside from allowing servers to be cracked in to. The feature exists because PHP has the extremely useful ability to open remote files over HTTP. Unfortunately, this feature extends to the include() and require() functions which will execute any PHP code in the file passed to the functions. The most obvious solution to my mind would be for these functions to refuse to execute PHP in files that were opened via HTTP. I have no doubt that this would involve an ugly hack on behalf of PHP's maintainers, but I believe the number of security problems it would solve would be well worth the trade-off.

Incidentally, I know you can disable opening files over HTTP and I know you shouldnt allow the direct creation of variables from the query string in the first place. The problems here are two-fold: firstly, opening files over HTTP is actually a very useful feature, one that would be all the more useful if it didn't carry the risk of executing arbitrary code. Secondly, the problem is mainly down to third party software which often requires insecure PHP settings (such as register_globals) in order to work.

New PHP community site

Simon Willison — 2003-12-05T02:22:29-00:00

Via The Farm, Chris Shiflett is calling for assistance in setting up a new PHP community site to run along similar lines to use Perl. Chris has already secured an offer of hosting and support from O'Reilly and is now seeking offers of help from potential contributers. PHP has long needed a site of this kind (PHP Builder has lost a lot of momentum since being sold by Tim Perdue) so this could be a worth while project to get involved with if you have the time.

I wonder if Python would benefit from something like this? Python already has an excellent decentralised community centered mainly around the Python newsgroups, blogs and mailing lists, but it would be nice if Python.org provided more community oriented features.

Simpler content managment

Simon Willison — 2003-12-05T01:36:28-00:00

Perls of wisdom in a sea of site mismanagement, via the ever-excellent Column Two:

The great surprise of the past five years of content management is that, despite all the hundreds of systems, no clear winners have emerged. Instead, there's a growing dissatisfaction with the ongoing technical burden that such systems impose.

Some influential voices are starting to argue that many sites should, in effect, wait out this immature phase of website management. For the moment, they should content themselves with limited automation.

The article concludes with the idea that many sites can do perfectly well with a few simple Perl scripts and maybe a relational database on the back end, rather than investing in an expensive super-package that claims to be able to do anything you could possibly want. This is very sound advice. The simple fact of the matter is that many sites really don't need a complex content management platform with support for templating, user logins, workflow, versioning and a dozen other high end features. Most sites just need someone to be able to easily update them, when necessary. This is why Macromedia Contribute has been such a success - people want the ability to hit "Edit This Page", make a few changes and publish straight to their site.

I've worked on my fair share of content management systems (in fact I'm helping develop one at the moment) and out of all of the ones I've been involved in, the one I got the biggest kick out of took the shortest time to develop. It was based on Tavi Wiki, and consisted of a password protected Tavi install for the back end and a slightly modified separate install for the front end. Both installs pointed to the same database, but the front end was altered to disable all editing features and make the site look less like a Wiki. You can see the end result here.

All in all, the CMS took less than an hour to put together from start to finish. It made it easy enough for contributors with no previous knowledge of HTML to update the site (using Wiki markup) and provided us with full versioning on all content contained within the project. The final site gives very few clues that the underlying engine is a Wiki, and thanks to Tavi's ease of customisation the site design can be easily changed to look even less wiki-like. It's close to the simplest thing that could possibly work and it works just fine.

Of course, if you don't have a competent server-side programmer to hand your only option is to buy a pre-made solution, but with a half-decent programmer and a good set of tools a simple home built CMS customised to fit your needs could be a much better investment than some $100,000 one-size-fits all monstrosity.

IXR 2.0

Simon Willison — 2003-11-27T03:38:41-00:00

Harry Fuecks has been hacking on my XML-RPC library, and has released a new version with some significant changes. His article on phpPatterns describes the changes and provides a link to download the updated code. He's made a bunch of interesting architectural changes which take advantage of a number of useful PEAR classes, including HTTP_Request which provides support for proxies and authentication, two frequently requested features.

I don't know when I'll get a chance to look at my version of the code again, since most of my current development work involves Python rather than PHP. If you're looking for an updated version of the library you would do well to check out Harry's enhancements.

An apology

Simon Willison — 2003-11-14T23:16:43-00:00

It turns out that the Javascript on PHP.net mentioned previously was not deliberately obfuscated to protect the code from prying eyes; it was merely compressed to reduce the size of the script. See this comment for further details. I'd like to apologise to the maintainers of PHP.net for jumping the gun on this issue. Incidentally, the unobfuscated code is now available in CVS.

The good and the ugly

Simon Willison — 2003-11-13T23:33:06-00:00

PHP.net has a new feature on their search page - a really nice implementation of an auto complete text widget in Javascript. Even better, the search page is valid XHTML 1.0 Strict and uses CSS for the layout. Let's hope this is an indication of things to the come for the rest of the site, which still mostly consists of tag soup.

Here's the ugly bit: the javascript for the auto complete function is deliberately obfuscated. Now I know that this decision is completely up to the author of the script, but personally I find it exasperating. PHP is an open source project, and obfuscation in this way is the antithesis of the open source ideal. A big part about open source is that people shouldn't have to invent something twice - why waste duplicated effort when sharing code costs nothing and benefits everyone? I'm sure the author had their reasons for hiding the code in this way but to me it seems like a wasted opportunity to teach site visitors a useful new trick. A bug concerning the obfuscation has already been raised in PHP's bug tracker but was closed without a full explanation.

Obfuscation of client side code such as Javascript is a pretty futile exercise in any case. Most of the effect of the obfuscation can be easily reversed using a tool such as Jesse Ruderman's view variables bookmarklet, which displays all variables on a page (including ones that contain decoded content from obfuscated variables) and pretty-prints functions to make them more readable.

It's impossible to prevent "theft" of your Javascript, but if you really want to stop people from using it the best you can do is to place a copyright notice in the code and ask people to contact you for licensing options. If it's on the web, people can take it. Clear copyright messages are a far more ethical deterrent than ineffective tricks.

Update: It turns out the obfuscation was the result of compressing the Javascript for efficiency reasons - see my apology for further information.