Finally we figure out the basics of Yii. While working on basic of Yii, I want to rewrite the url to SEO friendly. So I started to search on google, forum got useful information here http://www.yiiframework.com/doc/guide/1.1/en/topics.url To hide the index.php from url I did changes in config/main.php [...] and I created new .htaccess file in the same directory as my index.php file.

The changes are pretty simple - it's mostly a change to the "urlManager" setting to provide some rules for mapping controller and actions to the right place. The .htaccess file uses Apache's mod_rewrite functionality to grab the requested URL and remap it back to lay on top of the "index.php" front controller for the request.

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)

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).

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.

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.

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.

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.

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.

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.

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.