Blogged thoughts, is our web blog. Expect views, opinion, rants and tirades about everything and anything 

The environment variables are usually made available to your scripts via $_ENV, just like $_POST, $_GET etc. are. It seems however that the registration by PHP of these kind of variables for use in your scripts is governed by a configuration option called variables_order in the php.ini file. By default many of the latest installs (and associated php.ini’s) of PHP will have this option set to ‘GPCS’, which stands for Get, Post, Cookie and Built-in variables respectively.

Therefore if you find your php_info() function call returning a bucket load of environment related information but yet a print_r($_ENV) returns an empty array () check the aforementioned setting and be sure to add E in there somewhere so as to instruct PHP to make environment variables available to you and your scripts.

While I’m not 100% certain I believe the ordering of the letters is only important when you have the register_globals option set to on. If register_globals is set to on (off by default since 4.2 and ditched in 6.0) then PHP will make all the variable kinds (Post, Get etc.) specified in variables_order available as global variables in the order you specified in that directive. Imagine for instance that you have ‘EGP’ specified in variables_order and register_globals set to on, if you have a variable called ‘Path’ in both the $_ENV and $_POST arrays, the value from the post array will overwrite the value from the environment array and thus the global variable $Path will hold information from $_POST and not $_ENV. If register_globals was turned to off, you would simply access all array indexes by their full name such as $_ENV[”Path”] and $_POST[”Path”] and thus they will be considered as 100% different variables.

As pear (pun intended) usual if I have what I believe is a useful solution to something I’ve spent an eternity trying to fix in my code I will try put it up on the old blog for the benefit of others. The problem I was having for a large part of yesterday and earlier on this morning (Tuesday the 12th) related to the use of a PEAR based Database Abstraction Layer (DAL) module called DB. For those that don’t know a DAL allows a developer to call generic database access code, which then in turn calls DB provider specific code. The advantage of this is that the developer can change the underlying database system by changing a single line of code in a connection string as opposed to all DB access logic in his or her code.

The Database Abstraction Layer I was using: DB is actually depreciated but I was using it for legacy purposes as most of our existing PHP apps use it. The thing to remember with DALs is that ‘under the hood’ they will eventually call DB provider specific code so problems with DB, any other PEAR DAL or indeed any DAL in general may not be caused by the DAL itself but in fact caused by the underlying DB provider specific code.

My problem in this case was that I just seemed to keep getting connection errors when I called the ‘connect’ function in DB. The code I used was similar to:

require_once(’DB.php’); //makes the DB extension available to my code

//connection string for SQL Server database
$db = DB::connect(”mssql://username:PaSsWoRd@dbhost/dbname”);

if(DB::iserror($db))
{
       die($db->getMessage());
}

and the error I got was DB Error: connect failed. As you can see my underlying database is SQL Server as indicated by ‘mssql’ in the above code.
I’m not too sure about the more recent releases of DB (I was using one from 2003) but it seemed DB was not very useful from an error debugging point of view as it didn’t ‘bubble up’ all error messages and only spit out something very generic and very useless.

The thought struck me that perhaps the underlying PHP MS SQL function library was not enabled in the PHP configuration file. This turned out to be the case. Enabling it was as simple as adding a line or two into the PHP.ini file:

[PHP_MSSQL]
extension=php_mssql.dll

If you had of called

$db = mssql_connect(”dbhost”,”username”,”PaSsWoRd”);

directly in your code, which the above PEAR DB code eventually did you would have got a much more helpful error like the following:

PHP Fatal error: Call to undefined function mssql_connect() in…

which you would (hopefully) immediately diagnose as being related to the availability of the PHP mssql library itself and not DAL related.

After enabling the extension, I was still getting the DB Error: connect failed generic error from PEAR DB so I decided to work directly with the mssql_connect function to see if again it was a SQL Server issue. When I called mssql_connect I still couldn’t get a connection and got the error below so it was obviously not PEAR DB playing up.

PHP Warning: mssql_connect() [function.mssql-connect]: Unable to connect to server: servername

It turns out that my connection string was 100% correct however the version of the ntwdblib.dll file on my PHP box was not compatibile with certain recent versions of SQL Server. According to the PHP website ntwdblib.dll is required for the PHP MSSQL extension to work:

The extension requires the MS SQL Client Tools to be installed on the system where PHP is installed. The Client Tools can be installed from the MS SQL Server CD or by copying ntwdblib.dll from \winnt\system32 on the server to \winnt\system32 on the PHP box. Copying ntwdblib.dll will only provide access through named pipes. Configuration of the client will require installation of all the tools.

It seems that for whatever reason the very latest installs of PHP include a version of ntwdblib.dll that will not work with SQL Server 2003, SQL Server 2005 and as far as I’m aware SQL Server Express. The version of ntwdblib installed is likely to be 2000.2.8.0 when what you need to have to talk to recent versions of SQL Server is 2000.80.194.0. This file can actually be present in locations other than winnt\system32 depending on your platform and installation setup so I suggest you do a search for it, check the version and if it doesn’t end it 80.194.0 download the latest version from the UserScape.com site and use it to overwrite the existing version. In my case I installed PHP as a CGI on Windows Server 2003 so the file was present directly in the PHP folder. When I updated it and tried my code again everything worked fine, including the original PHP DAL DB:connect call.

In the end it turned out my problems were nothing to do with the PEAR DB module but were related to PHPs SQL Server functions. If your still having problems connecting to SQL Server from PHP I suggest you visit the relevant PHP page located at http://ie2.php.net/function.mssql-connect which contains a lot of user contributed information about ntwdblib.dll and other issues which may be causing your problems and associated pain.

You may have noticed that I’ve recently been making use of this blogs XML feed to a) display links/descriptions to my three most recent posts on the akamarketing.com homepage and b) display links to my ten most recent posts in the left navigation bar of most of my sites pages. This was done to try and funnel more site visitors to the blog because that’s where I’m doing most of my updates and although it’s early days it seems to be working.

It’s actually quite easy to do, I basically just parsed the standard Wordpress XML feed with DOMXML and then outputted the specific information I needed. The code for generating links to my last ten posts I used on the left nav bar is available at: http://www.akamarketing.com/wordpress-links.php.txt with the running version at http://www.akamarketing.com/wordpress-links.php

By examining the structure of a Wordpress feed (mine is located at http://www.akamarketing.com/blog/feed) you’ll see that the details of each post is stored in the item element. By getting and looping through all the item elements it is possible to access specific information such as post link, title and description. In this case I’ve used the description information for the title attribute of the link meaning that when someone mouses over a certain link a snippet from the corresponding post will appear on screen.  

Feel free to use my code, check if you have DOMXML support first of course.

Despite the fact that PHP 5 is still not yet supported by all of the webs main hosting companies, the show must go on and this means the ongoing development of PHP 6. The minutes of all the PHP developers meetings are available on the www.php.net website and provide us with a fairly reliable look at what we can expect from PHP 6. The exact location of the minutes is http://www.php.net/~derick/meeting-notes.html. This document is over 83 KB and your most likely not going to read it all, I however have gone through it intermittently over the last few days and although there are a tonne of proposed changes, only three of these proposed changes are likely to be seen as major and having an effect on the general PHP developer population. The three major changes are that register globals, magic quotes and safe mode are all to be ditched.

Register Globals is a PHP directive that when turned on automatically sets all EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables. This means that to use a post form variable you need only reference it by its name and not by its full location within the post array. For example to access the value of a form (submitted by the ‘POST’ method) textfield called firstname with register globals on one would simply use $firstname, however with the register globals directive switched off one would have to use $_POST[’firstname’].

Enabling register globals appears then to be more convenient but it is also more of a risk as writing insecure code becomes a lot easier. The reason for this is that with register globals on a developers script can be injected with all sorts of variables including HTML form values and URL get values (which can easily be manipulated by a hacker). With EGPCS variables and internal variables that are defined in the script itself so easily available the programmer can mistakenly open a ‘door’ or a ‘hole’ to a hacker by simply getting confused. A great example of a potential security risk created by bad coding with register globals on is available on http://ie.php.net/manual/en/security.globals.php (see example 29-1 near the top). Although register globals was turned off by default as off PHP 4.2, many webhosts use earlier versions of PHP and others simply manually set the directive to on. To eliminate any risks associated with having register globals on then the development team of PHP 6 decided to get rid of the directive altogether. This means that any scripts which made use of the register globals directive must be rewritten before being ported to PHP 6 as they will not work otherwise.

Next there’s magic quotes, this directive when switched on automagically escapes incoming data (such as POST form values) to any PHP script. This means that you will not have to run addslashes() to prevent MySQL (and others which escape characters with a slash) returning a syntax error when a user enters in a ‘ (for example) in a form textfield. Magic quotes (when switched on) helps beginners code more safely and it’s more convenient as addslashes gets run by PHP without any explicit calls by the coder. The magic quotes directive can however be set to on or off without any influence from within the script itself as input parameters are escaped before the script starts, this means that developers have the cumbersome task of having to first check if it is on and then having to run or not run addslashes() accordingly. Unexperienced programmers could simply assume it is either on or off and code accordingly which will of course effect the portability of an application as obviously some servers will have it switched on and some will have it switched off. In an effort to clean up the code and remove any ambiguity the developers of PHP 6 have decided to remove magic quotes functionality altogether, this is fairly significant and will require code rewriting for those applications and scripts that relied on the magic quotes directive being on (without checking) before these same applications and scripts will work on PHP 6.

Safe mode too is on the way out. PHP safe mode is an attempt to solve the shared-server security problem (according to PHP.net anyhow). When PHP safe mode is on lots of functionality is turned off and other functionality needs a higher degree of authorization (such as UID checks) to run, not only does this frustrate many developers whose hosts have safe mode on but it also gives off the impression that PHP is completely safe with safe mode on, even the most inexperienced PHP coders know this is not the case. The particular section of the developers meeting minutes corresponding to safe mode is found at http://www.php.net/~derick/meeting-notes.html#safe-mode. I don’t believe that the removal of safe mode will require major code changes for applications and scripts to work on PHP 6, please tell me though if I’m wrong on this one (it has been known to happen…)

Although the minutes of the meeting are not final it’s looking like PHP 6, if developed according to them is likely to go through an even longer ‘probationary’ period with webhosts than PHP 5 did (and is still doing) as an awful lot of scripts stand to be broken with any rushed migration to version 6 of this very popular web programming language.