This is a very strange topic: even though a cursory google search using the words “multiple php versions apache” spits out a considerable amount of informative howtos and blog entries, when I recently mentioned in a mailing list that it is in fact quite easy to have multiple php installs running in parallel using Apache virtual hosts, I immediately received a private request for my configuration.
Well, here it is, along with a few details on how to set up the complete environment.
The desired goal is having “alot” of php installations running in parallel, so that php scripts can be quickly tested against as many versions of php as possible. It is very useful f.e. when
- you are migrating an existing app from php 4 to version 5
- you are deploying your applications on a large base of servers where different versions of php are installed, but develop all the different apps on the same workstation
- you develop a popular open source php library or shrink wrapped application, and want to make sure that it runs smoothly in every possible user setup
- you want to test an application against different sets of php.ini configurations, to check for possible problems in areas such as output buffering, opcode caches etc…
- you are into integration testing
There are many different setups that can be used to achieve this result (a big list is available on Gentoo docs, courtesy of Andreas Korthaus).
My preferred setup is: use a single apache instance, with a single php version installed as module, and many versions installed as cgi applications. Advantages:
- no need to rename any php file to run it with different php versions
- no need to restart the webserver or run any kind of script to switch php version
- uses less memory than multiple apache installs
The main disadvantages are:
- only 1 php version can run as an apache module, the others must limit themselves to cgi
- a very misbehaved php application can in rare cases hog or crash the webserver, and it will have to be reset before testing with other php versions
The instructions below are geared to a windows environment with Apache 2, but converting them to linux is left as trivial exercise for the sysadmin.
A simple question: why is the word “docbook” always followed by “toolchain” instead of “editor”? Why can’t I just write my documentation in xml as easily as I do with Ms Word and be happy with the results?
The answer is unfortunately not so simple. The core of the problem lies in the flexibility provided by the docbook format. After all, it is an xml dialect, which can be used to write (almost) any kind of technical documentation and produce (almost) any kind of output. Existing graphical editing and conversion tools either cater only to a specific category of documents or suffer from a generic interface that does not introduce significant productivity gains.
What I needed to document my php project was:
- A free (at least as in beer) docbook editor with a decent wysiwyg interface that would not force me to learn the intricacies of every single docbook tag
- some way to automatically convert the docbook file to a nicely formatted XHTML version
- some way to automatically convert the docbook file to a similarly formatted PDFversion
- nice-to-have but not required: php syntax highlighting in the final output, generation of (parts of) the docbook manual from javadoc embedded in the php source code, conversion of docbook to OpenOffice format, etc…
After struggling with a couple of buggy/incomplete editing and conversion tools, being somewhat of a coder myself, I decided to roll my own solution.
Here’s how I set up my toolchain:
As everybody in the php world is bound to know, PHP4 is still the dominant platform on the net, despite its age and many shortcomings. Notwhistanding many improvements in speed, security and functionality, PHP 5 has seen so far a less-than-stellar adoption rate.
There have been a lot of discussions in the blogosphere about this “problem”, with the most basic explanation being:
- web hosters do not upgrade because some very successful web apps (blogs, cms, bulletins, etc…) still need php 4 to run
- php coders have to code for php 4 because otherwise they loose the opportunity of getting deployed on shared hosting
- since the apps run on php 4 anyway, why upgrade? (a classic case of dog-eats-tail)
Other people refer to PHP as victim-of-its-own-success: PHP 4 was good enough for everybody, so a lot of people do not feel compelled to upgrade.
While I am generally in favour of extreme ABInex and API stability (I have servers running php 4.0.4, pl1 mind you…), I have to admit that the current situation imposes a heavy burden on the developers of php libraries and applications: the coder has to cater to the quirks and bugs of every possible php version, and either avoid any enhancement that has seen the light roughly in the last 5 years (since the release of php 4.2) or resort to provide alternative code paths for the less-fortunate (the php-compat package on Pear is a great help if you’re into defensive coding).
The best proposal I have seen so far to this situation comes from the Drupal mailing list:
PICK A DATE FOR PHP 4 DESUPPORT AND ANNOUNCE IT TO THE WORLD WITH ENOUGH ADVANCE.
The chosen date has to be agreed upon by most major php application teams (this is the hard part), but most of them, have been planning the upgrade to php5 anyway.
- The hosters and sysadmins at private companies will be given enough time to test the deployment of the new php version
- The developers will feel the need to make sure that their app runs fine on php 5 before the cutover date
- Everybody will be happy (except Stefan Esser, he never is…)
One last question remains open: WHAT SHALL WE CALL THE DAY THAT PHP4 IS PUT TO REST?
Suggestions are welcome…
I have updated the article comparing the different php libraries that allow encoding/decoding of JSON data.
Besides testing the latest version of all the libraries involved and briefly summarizing the evolution since the november test, he new page has benchmark results for php 4.4.
Here it is.
Tales from the trenches.
Two companies develop a communication protocol to exchange information between their respective systems. SOAP is picked up, presumably because of all its enterprise-trendiness.
One company builds a J2EE application, the other one a single C++ builder win32 exe. Both sides can receive and send messages.
The applications get tested by the developers while at their respective office, and declared ready to go….
…but fail to exchange a single message when deployed in the production environment, which includes quite a few extra devices:
- https encryption over the internet part
- your run-of-the-mill layer 3 firewall
- an application-layer firewall terminating the https connections and applying layer 7 http filtering
- another application-layer firewall applying antivirus scanning
The developers have no clue as to what might be causing the problem, and are prone to point fingers against the “bad firewalls”.
- the java guys are helpless in locating errors, because they never look at the http layer which should supposedly be carrying the xml messages. All they know are the java objects that the framework builds for them. If any error occurs in handling the http connection, xml (de)serialization or https handshake they do not know – all they get is an empty pointer (note: presumably the informative, verbose exception that would help in debugging is being catched too early inside the framework itself, and the coders do not dare split it open)
- the c++ guys are helpless in locating errors, because their app in fact knows nothing about xml and much less about http. It reads strings from sockets and writes strings to sockets. The received strings are parsed, presumably by regexps, while the outgoing messages are built from .txt template files with very basic token substitution
There is really something interesting in comparing the two approaches to development: on one side the communication protocol is completely abstracted away, so much in fact that it cannot be examined at all; on the other side the protocol is not handled at all, and old-school quick-n-dirty pragmatic coding has produced the bare minimum necessary to fake understanding the language, while in reality not being able to speak it at all.
One of the little quirks the php framework developer has to face when confronted with the daunting task of writing real portable code is figuring out which global variables will be available in every single conceivable user setup (and in most of the unthinkable ones), and what kind of values they will assume.
Although the online manual does a pretty good job in describing where the environment variables are supposed to come from, and their supposed usage, it sports no single, comprehensive list of all the junk that might – or not – be filling up the “Environment” section of the global namespace.
Having wrestled with php deployments ranging from SCO Openserver (brr…) to windows to solaris 32 and 64 bits, I set up to publish my own findings.
The list can be found here: http://gggeek.altervista.org/sw/env_vars_comparison_chart.xhtml. People on slow links please note it weights in at 300k.
In its present incarnation it is based exclusively on windows installs. I plan to add some more unix goodiness later on, but any contribution is welcome (a printout of your phpinfo will do, or, in case you value privacy and security, a plain list of the values in the ‘env’ and ‘server’ sections).
The colors, more or less, indicate:
- red: value or variable name changes from server to server (eg. some values change casing, such as PATH vs. Path, COMSPEC, )
- yellow: variable is in the cgi spec, but the server omits it…
- gray: variable is present in all setups tested: it can be used reliably
- blue: variable should not be present in CLI versions, it can be thus safely used to test if app is called via web or not
Also note that “script name” in some settings will point to php executable, not php script.
In no particular order, things that should be done before the table is considered reliable include: add a column with exaple values, testing all php setups without a php.ini file active, test with IIS in isapi mode, apache 1 in mod_apache mode, apache in ssl mode, cgi mode when run from command line, version 4 cli, linux / solaris installs, separate clearly variables from the windows environment from the more “general” ones, add some insight on usage of REGISTER_GLOBALS, variables_order, and other assorted ini settings that might influence the php environment.
A similar table, with better formatting, can be found here, while a discussion on this topic a little while ago was here
On the JSmin webpage, a php version is available for download, but it did not fit my needs really well (in fact, the js version did, but, being a php-head, I got that one first), so I patched it a bit:
- made all the code work with PHP 4 (removed usage of splfileiterator, exceptions are replaced by triggering errors, class constants are turned into global constants, etc…)
- constant VERSION changed to JSMIN_VERSION to avoid name clashes
- added a new function to class JSMin to cleanly separate writing to output stream from parsing
- make sure that newline chars passed inside the comments parameter do not break output
- the file can now be included in a php app (whether cli or web hosted) and used as library (just define JSMIN_AS_LIB before including jsmin.php)
- when used as library, the class can operate on php strings instead of files
- i could not resist the urge to remove excess whitespace here and there in the php source, too (phpmin-syndrome???)
The new code is available here. Take a look at the comments inside for more info.
There is some other (php) work done on jsmin from a guy named Ed Eliot there
If the result of such perilous journeys has been something of interest, I let the readers judge.
For now, the visible part is a graphical editor of xmlrpc / json values, added to the online xmlrpc debugger available here: http://gggeek.damacom.it/debugger/ (to see it, click on ‘Execute method’ then on the ‘Edit’ link).
The recent release of php 5.2.0, which includes by default an extension for converting php values from and to the JSON format, is a good occasion for comparing the different existing php libraries which aim to provide the same capabilities.
Here you can find a detailed analysis of the features, performances and encoding/decoding capabilities of 4 of the main implementations: 3 “pure php” libraries and the native extension.
I have to warn readers: I personally maintain one of the four libs in exam.
Any correction, criticism or feedback is welcome.
Edit 2007/04/25 – an update version of the comparison has been posted here
Most personall firewall application fail in a very basic (and essential) aspect of their operation: giving the user a clear and concise way of identifying the software that is trying to access the network.
Even though this is widely known and has been discussed to death, it never really struck me until I installed the ADSL modem I recently got for free, courtesy of my telephonephone line operator.
The windows 2000 version of the modem driver starts up and greets me with this nice dialog box as soon as I log in into my computer:
Allowing “rundll32.exe” to always connect to the web is to be considered a safe practice or not?
How many users, when pestered with this annoying dialog popping up every day, are savvy enough not to dismiss it once and forever?
Please note that the standard version of the dialog message gives even less details about the outgoing connection than the screenshot pasted here, and only identifies the offending executable by filename: no path information, no version information, no nothing.
How many will take the time to properly configure the firewall to only let the offending driver connect to the local subnet?
Now, this is arguably a bad design decision on the part of the writers of the modem driver, but there is a much simpler and cleaner way for wannabe virus writers to bypass any security measure that personal firewalls provide blocking outgoing connections: simply use the web browser to connect to the web. Both IE and firefox are powerful enough to provide support for a variety of web protocols, as well as easy scripting interfaces, and one of those two has been durely flagged as “connect to the net without asking consent”, most likely both.