Sharon Levy has a new post to her blog showing a trick she's come up with to show the PHP version information (usually found in the phpinfo) even when it's disabled.

Sometimes the most crucial, basic piece of information can seem so hard to find. For example, suppose you wanted to find out what version of PHP your remote webhost provides to shared hosting users? What would you do? [...] For development purposes it can be helpful having phpinfo() available, but on a live shared host, you may discover as I did recently that it is no longer available; your host may have disabled it.

She includes three other ways you can use to get the version of PHP you're working with:

• If you have command line access, running "php -v"
• Using the phpversion function (or PHP_VERSION constant)
• Appending a certain value to the URL (only works in some cases)

On his blog today Sameer Borate has a new post with a handy bit of code you can use to find the keywords from a search engine referral to help with tracking how visitors have come to your site.

A couple of weeks back I had to write a solution for a client to track the referrer search engine from where the user came to his sites contact page, without using Google Analytics. If a user was to fill the contact form on the website, the referring search engine name and the keyword for which it was refereed was to be emailed along with the contact information. The following is a solution for the same.

The code itself is pretty simple - it checks the $_SERVER['HTTP_REFERER'] and, based on an array of search engine types, looks for a certain "query" keyname in the URL and matches what follows (with a regular expression). This can be useful for not only determining what sort of audience is visiting your site, but could also be used to present a custom message to visitors from certain search engines (or, more complicated, to show different content based on search terms).

Lars Tesmer has a suggestion for all of the unit testers out there (you do unit test your code, right?) when needing to test a piece of code that makes a call to something on the file system or a remote resource. Their examples come from tests written against the Assetic codebase.

For our most recent After Work Hacking my co-workers and me decided to write unit tests for the open source project Assetic. That turned out to be a better decision than our last one, yet we still ran into an interesting challenge.

In testing the HttpAsset class from the tool, they came across the problem - a call to a remote/file resource that could not be tested because of a file_get_contents call that depends on an external source. They came up with a few options to try to test this example, some better than others:

• Give it a real URL to test with
• Wrap the file_get_contents inside of a new class (ex. a "ContentFetcher")
• Use vfsStream to mock out the file system in the unit test

In their case, vfsStream couldn't be used due to how the fetch call was made, but the tool can be very handy if you need to mock out an external file system resource.

Lorna Mitchell has a quick post to her blog today showing how you can use a simple curl call from PHP to shorten urls with bit.ly and pull back the result.

I've been looking around for a really simple API that would be a nice place to get started using web services from PHP - and I realised that bit.ly actually fits the bill really well. They have straightforward api docs on google code, and it's also a pretty simple function!

Her code is about three lines consisting of a curl_init call to the bit.ly server with the URL, a curl_setopt to tell it to return the information and a curl_exec to execute. The result is a JSON string easily decoded with a "url" parameter containing the newly minted short URL. She also briefly mentions some of the other features of the bit.ly API including reverse translation and bundling of links.

In a a new tutorial posted on his blog Martin Sik shows you how to "steal" the "did you mean..." functionality that Google's sites currently offer. His example uses cURL to get the current Google request URLs and fetch the associated results.

I really like Google and the classic "did you mean" feature is really great, unfortunately when I wanted to implement it into my project a realized that it's not provided by any of Google's APIs. [...] I believe for most developers [having a large dictionary and extend the dictionary when new terms are available] are unachievable. And so it's for me. So I was thinking if I can bypass these drawbacks and let Google do all the job for me.

The source code is included with the post showing two methods - fetching a "did you mean" block to parse or how a term is attached to a Google URL and the results are returned in JSON and parsed for display. Obviously, this is an external dependency you could consider if you put it into your application, but it can be quite a powerful tool in the right situations.

In a quick post to her blog today, Lorna Mitchell talks about an issue with pecl_outh tat came up during her development of a new API. A strange fatal error message was breaking her connection.

I'd gone through all the handshaking steps, got the acces token and was ready to start talking to the service itself. However when I tried to call OAuth::fetch, I got an error message: Fatal error: Uncaught exception 'OAuthException' with message 'Invalid protected resource url, unable to generate signature base string'

As it turns out, the issue was obscure - the address she was connecting to was missing a training slash (http://api.localhost versus http://api.localhost/) and it was causing the OAuth fetch to fail (apparently undocumented). If you're interested in some of the other things that have come up in her work with OAuth on the project, see here.

From the HashBangCode.com site today there's a new post that revisits filtering with the filter_var function included with the language. The focus in this article is specifically in validating URLs with the FILTER_VALIDATE_URL flag.

Quite a while ago I looked at using the filter_var() function to validate URL's using the FILTER_VALIDATE_URL flag and someone pointed out recently that this function has not only changed since the initial release, but that a number of flags can be added to change the way that this function works.

He lists some of the other flags that are now available that can be used in conjunction with FILTER_VALIDATE_URL to get more fine-grained in your filtering - checks on things like a required scheme, hostname and query string. He includes some code with a set of URLs to run through some tests and output as a table with the pass/fail rank of each URL value. You can see the resulting output here.

Derick Rethans has shared a method he's created for making short, descriptive URLs with the help of his translit PHP extension that translates non-latin characters into latin ones.

The URLs for my articles are automatically generated from the title. There is a little function that uses translit's transliterate() function to ASCII-ify the titles. [...] However, [this] is hardly a short URL. What we want is something short and descriptive. First of all, I thought it would work to generate short URLs automatically.

In hindsight, though, he decided it would just be better to come up with his own short URLs but he still wanted a way to use them. Registering a short domain helped and, along with some <link> tags, made it easier for the right information to be automatically found.

On his blog Brandon Beasley has a new tutorial for CodeIgniter users out there on how to create "vanity URLs" that are correctly handled by the framework's routing system.

Recently I worked on a CodeIgniter project that needed the ability to use vanity URLs and display stats about the user represented by the URL. For instance, suppose you want to pull all public data on a user from Twitter and display it within your web application on a customized URL such as http://mytwitterapp.com/brandonbeasley . The difficulty arose when the AUTO setting for URI protocols seemingly failed to handle the PATH_INFO protocol needed for Twitter callbacks and the REQUEST_URI protocol needed for vanity URLs.

His solution combines custom routing on the framework side and a bit of a change to the .htaccess to make the APP_PATH functionality work correctly. Then a simple controller can be created (in his case "User") and the username can be pulled in via the URI helper's segment() function. There's other ways to make this happen with the custom routing CodeIgniter offers, but this method allows for a more fine-grained approach.

On the SitePoint PHP blog today there's a new post showing you how to create a 404 page that will redirect people back to the page they're looking for (that used to be there).

It's often necessary to reorganize your site and change the URL structure but, assuming you have similar content, users should rarely encounter a "page not found" error. Producing unnecessary 404 pages is one of my top 10 development mistakes. In this article, we'll create an automated PHP redirection system that converts old URLs to a new address. It's not production code, but it will illustrate the basics so that you can adapt it for your own website.

They walk you through the creation of a 404 error handling PHP page, configuring your server to use it and making the mapping of new URL to old URL. There's even a bit to include if there's not a mapping for a requested page - returning a 301 HTTP header.