melbourne chapter

Interesting issue today whilst I was migrating some websites to a new host. Even after updating the DNS records with our domain name registrar we were still viewing old content, after much head scratching and blaming the internet connection we concluded there was some sort of caching going on. Didn’t make sense to me initially, but after some relaxing tunes courtesy of Linkin Park and a coffee it dawned on me. DNS caching. In a nutshell Internet hosts, even your PC use our good friend the DNS server to resolve domains to webservers. To find out where the actual stuff is

(Lame re-enactment)

PC A: where's melbournechapter.net
 
DNS A: anybody know where melbournechapter.net lives
 
DNS B: its over here... 123.45.67.89
 
DNS A: cheers bud. Hey PC I just heard its over here .. 123.45.67.89
 
PC A: Thanks.
 
PC B: where's melbournechapter.net
 
DNS A: Oh I know this one! It's over here 123.45.67.89
 
[ later that day melbournechapter.net moves to a new address]

Pretty mundane work I must say, and DNS A, our local DNS thinks so too. So rather than asking DNS B, our authorative DNS the location again it just sends PC B the address it previously got i.e. it uses its cached record. Meanwhile melbournechapter.net moved address so PC B gets the old location. Now usually this isn’t too much of a problem since a local DNS only remembers request for only a certain period known as TTL (Time To Live), so eventally DNS A will get the updated address. However, if your demonstrating something to a client you can get some rather strange results. Trust me when I say its pretty frustrating explaining you’ve updated something and all they can see through their browser is old content! Now to prevent this you can edit your registry or your clients registry for that matter but I dont recommend it! Instead just flush the DNS using ipconfig in Command Prompt (In XP Start > Run > Enter “cmd”):

C:Documents and Settingsrlee> iponfig /flushdns

And don’t forget to close and re-open the browser!

Mod Rewrite is an Apache module commonly used with PHP to create Search Engine friendly URLs. Essentially this module lets us mask ugly querystrings with much more meaningful URLs. For example take a products page in a database driven catalog:

http://www.mysite.com.au/catalog/product.php?pid=123

At the moment this URL tells us nothing about the destination page and searchbots lare deterred from indexing such URLs - Wouldn’t it be better if we included the product name?

http://www.mysite.com.au/catalog/products/t-shirt/123

Much better . Using the power of regular expressions we can extract the information from our new URL and pass this information onto the correct PHP page behind the scenes.

So how do we do it? In the case of our new URL all we need to do is extract the last part which carries the product id and pass this onto the product.php page. We can do this easily in a .htaccess file:

First we enable the Mod Rewrite engine using RewriteEngine on:

# HTACCESS
 
RewriteEngine On # enable the module

Then we set the base url we will be writing from using RewriteBase base

RewriteBase /catalog/ # base URL which in our case is 'catalog' since this is where our app is sitting

Now we do our Rewrite using the RewriteRule pattern substitution directive - pattern is our Regular Expression which we use to evaluate the incomming URL, substitute is the string which is substituted for (or replaces) the original URL for which Pattern matched.

RewriteRule ^products/[a-zA-Z0-9-_]+/([0-9]+)$ product.php?pid=$1
# End HTACCESS

The Regular Expression:

- Caret ^ and dollar $ sign characters signify the start and end of our pattern string

- Square brackets specify ranges of allowed characters, such as A to Z, 0 to 9

- Round brackets are used to “capture” parts matched in our pattern - in this case the product id - which we later reference in our substitute URL using back referencing $1
(ref numbers are indexed according to each set of round brackets i.e. if we had enclosed the product name match in rounded brackets this would be $1 and the product id would be $2)
Easy enough? This is a relatively simple rewrite and I have explained it in fairly layman terms, more complicated rewrites require some knowledge of Regular Expressions. If you haven’t played with Regular Expression I highly recommend you checkout Wikipedia, DevShed articles and the cheat sheets supplied by ILoveJackDaniels.com.

I was having a quick explore into Dashboard Widgets today, and was suprised that the interfaces were created in HTML and CSS stylising, with PNG images.

Through JavaScript you can invoke various actions on the operating systems including system calls. This virtually allows you to communicate with any style of scripts installed on the computer, such as your PHP/Mac/C scripts, or communicate with XML provided by a REST webservice (say FLICKR for example). Your application could really take advantage of the AJAX style applications, affecting the DOM presentation to the user (DHTML), invoking JavaScript and performing asynchronous calls reading XML and the like.

From what I can gather it operates the same as a Safari browser, and it reveals access to the OS through a API object called “widget” that becomes available to your HTML page. Example: widget.system(”/bin/echo ‘my clipboard contents’ | /usr/bin/pbcopy”, null);
The structure of a Widget is a folder (with the extension of .wdgt) and importantly contains the basic files:

my_widget.wdgt
- Info.plist - XML/Properties containing basic properties of your widget, such as version, security requirements, placement of close buttons etc
- Icon.png - Represents the Widget
- Default.png - Represents the operating Widget
- my_widget.html - The HTML operating Widget - needs to be specified in your Info.plist
Widgets introduce dozens of potential applications, infact just as many as you can imagine with any web application.

For more information and a tutorial, checkout:

Apple Dashboard Tutorial 

Ugly URLs…
Querystring style URLs like below are synonymous with dynamic systems

http://www.mysite.com.au/catalog.php?category=cartridges&prod_id=33

While URLs like this are completely functional, there are a few issues with URLs like this you should consider before going live:

1. The underlying technology is exposed such that script kiddies can inject their own data - such as an sql injection.
2. The URL contains ampersands which, when unescaped will affect the XHTML compliance of linking websites
3. Search engines will avoid indexing dynamic pages like this
   

So without refactoring the application how can you make more freindly URLs? A simple solution for Apache based users is to utilize the mod rewrite module.

mod rewrite to the rescue!

Note: mod_rewrite is not loaded into Apache by default, to do so open your httpd.conf file and uncomment the module load code

Apache’s mod rewrite module can rewrite requested URLs on the fly, meaning you can substitute ugly querystrings with meaningful URLs, which address security issues, compliance and SEO. So how does mod rewrite work?

Basic rewriting

Typically mod rewrite directives are added to a htaccess file in your web root. Here’s a simple example to start with:

RewriteEngine on
RewriteRule ^old_page.html$ new_page.html

This rewrite transparently redirects a request for old_page.html to new_page.html. The first line enables the engine (only required once per htaccess file):

RewriteEngine on

This next line basically tells the server if there is a request matching oldpage.html, then substitute it with new_page.html. The caret ^ and dollar $ sign signify the start and end of the string used for the match.

RewriteRule ^old_page.html$ new_page.html

If you want to actually do a more traditional redirect and show the location of the page in the status bar just add [R] to the end of the RewriteRule.

Easy enough? That was a pretty simple rewrite. The real flexibility of mod rewrite requires some knowledge of Regular Expressions, which can get quite complex. However, the functionality and flexibility Regular Expressions offer in PHP make them well worth learning. So lets take a look at some common rewrites and the expressions used to make them happen.

Unleashing mod rewrite with Regular Expressions

With the help of Regular Expressions we can create RewriteRules which match a set of URLs and redirect them to their actual pages. Consider the products pages in our fictional Shopping Cart app which only vary in category name and product id. We can identify requests for products page by specifically matching the PHP filename, something representing a category name, forward slash, then something representing a product id. And here’s how our rule looks:

RewriteRule ^catalog/([a-zA-Z0-9-])/([0-9]+)/$ /catalog.php?category=$1&prod_id=$2

The parts in square brackets are known as ‘ranges’. In this case where allowing anything in an alphanumeric range (case insensitive) for our category name, then anything in the numeric range for our product id. We’ve also encased these regular expressions in parenthesis so we can ‘back reference’ our matches to pass the values onto our PHP page. Back referencing is done via indexing each set of parenthesises, $1 for our first parenthesises, being our category name, and $2 for our second parenthesises, being our product id.

Well this is the end of my tutorial on how to use mod rewrite to create freindly URLs. If you have any questions please feel free to post a comment. Cheers!

Welcome to the final installment of our 3 part series “Setting up a PHP Development Environment”. For those of you who haven’t installed Apache or PHP please checkout Part 1: Installing Apache and Part 2: Installing PHP4 tutorials on our site.
Setting up our Database Server…

For PHP we typically use the MySQL Database. MySQL is a open-source database built primarly for the LAMP stack (Linux, Apache, MySQL, PHP / Perl / Python.) but it’s very flexible, running on more than 20 platforms including Linux, Windows, OS/X, HP-UX, AIX and Netware (source: http://www.mysql.com). In the case of this tutorial we will be setting it to run on Windows XP.

Requirements:

• PHP 4 or later

(more…)

Often an annoying thing we come across in web development is remote access to servers. Recently we have had a project delayed while working with a 3rd party setting up a web server on site for a client. For us to access the service they have only setup FTP and SSH ports, but no HTTP ports. This would usually cause problems, the obvious being “How can we tell if the client can bring up the site?”.

We could make a HTTP GET request through our shell prompt and it would give us some results, (wget, lynx, GET commands) - but not quite the same as bringing up the page.

If we were to point our browser at their IP address, it would try to access port 80 which is firewalled. So how would we load the site in our browser?

The answer?

SSH Tunneling

A crafty tool that allows us to redirect remote IP+ports to our local machine. Meaning, whatever ports and computers you could access on the remote server, are “tunneled” to your local computer, allowing you to access them from your computer - all from 1 connection through port 22 (SSH). Virtually bypassing the firewall rules in place.

Further to make this process easier, PUTTY provides a nice utility in their settings to make this process even easier. You specify which port to forward from the external network to your local computer. You then establish a PUTTY SSH connection to the box, log in and voila, you will be able to access them on your computer.

So instead of accessing their port directly, I access my localhost:80 which pipes through SSH to their box.

I searched after for a few screenshots on how to do it, look here.

Yousif has posted a good article on having IE7 (beta 3) running beside IE6 at the same time. You can view the article here.

Part 2 assumes you have a working installation of Apache 2.0 please refer to Part 1: Installing Apache if you haven’t already done so.

Requirements

• Apache 2.0.x

1. Download the PHP 4.3.x Windows Binary zip package from http://www.php.net/downloads.php .
2. Run a virus scan and an MD5 checksum to verify the integrity of the download, then unzip to the same root directory as your Apache installation. I have Apache under C:\Apache2, so I have unzipped PHP to C:\php4 .

3. Now edit your php.ini file:

Rename C:\php4\php.ini-dist it to php.ini

Open the php.ini file, locate doc_root and set it to whatever your Apache DocumentRoot is set to. Mine is doc_root = “C:\public_html”

Note: Remember that when adding path values in the Apache configuration files on Windows, all backslashes such as c:\directory\file.ext must be converted to forward slashes, as c:/directory/file.ext. A trailing slash may also be necessary for directories.

Scroll down to extension_dir = “” and set it to the location of the ext directory of your PHP installation extension_dir = “C:\php4\extensions”

Since where using windows we also have to set the session save path to an existing directory so we can use PHP’s sessions functions. I recommend using the Window’s temporary directory session.save_path = “c:/windows/temp” OR for Win2k session.save_path = “c:/WINNT/Temp”

4. Next edit your Apache Conf file (hppd.conf )

For PHP 4 add the following line and copy your php4apache2.dll file from the sapi directory into the php4 root directory:

LoadModule php4_module "c:/php/php4apache2.dll"
AddType application/x-httpd-php .php

For PHP 5 do something like this:

LoadModule php5_module "c:/php/php5apache2.dll"
AddType application/x-httpd-php .php

And for both configure the path to the php.ini file:

PHPIniDir "C:/php"

5. Now test your installation - first restarting the Apache server - by creating a simple phpinfo file: