Many designers know how to create rounded corners using CSS, HTML, and a bunch of images, but these techniques cause a lot of HTML/CSS clutter.

Below is an example of some cluttered HTML used to create rounded corners.

<div>
  <div>
  <div></div>
</div>
<div>
  <div>
    <div>
      <-- main content goes here -->
    </div>
  </div>
</div>
<div>
  <div></div>
</div>
</div>

That’s quite a lot of code for one rounded box. Most designers know that it can be difficult to sift though HTML code like this, especially when trying to alter a page that use several rounded corners.

A solution to our problem is simple though – instead of writing all of the extra HTML divs each time we need a new rounded box, we can simply have jQuery do all the work for us (by way of DOM manipulation).

This useful technique is from Day 13 of the 15 Days of jQuery site. For a full tutorial or more detail on how it works, head on over there.

By utilizing the script below, we can automatically add the extra divs where needed.

<script type="text/javascript">
$(document).ready(function(){
    $("div.roundbox").wrap('
      <div>'+
      ' <div>'+
      '   <div>'+
      '     <div>'+
      '     </div>'+
      '  </div>'+
      ' </div>'+
      '</div>');
});
</script>

The use of div.roundbox in the snippet above is key. Now, instead of writing out all of those divs every time we need to create a new rounded box, all we have to do is use the class roundbox; jQuery will traverse the DOM to find all elements that has that class value and will automatically wrap it around div’s.

Here’s a sample div HTML structure:

<div>
  <-- main content goes here -->
</div>

Of course, you’ll still have to use some CSS to get the rounded corner images to work, and Jack Born of 15 Days of jQuery provides you with a downloadable package that includes the auxiliary source files you’ll need.

The factory pattern:

Many of the design patterns in the original Design Patterns book encourage loose coupling. To understand this concept, it’s easiest to talk about a struggle that many developers go through in large systems. The problem occurs when you change one piece of code and watch as a cascade of breakage happens in other parts of the system — parts you thought were completely unrelated.

The problem is tight coupling. Functions and classes in one part of the system rely too heavily on behaviors and structures in other functions and classes in other parts of the system. You need a set of patterns that lets these classes talk with each other, but you don’t want to tie them together so heavily that they become interlocked.

In large systems, lots of code relies on a few key classes. Difficulties can arise when you need to change those classes. For example, suppose you have a User class that reads from a file. You want to change it to a different class that reads from the database, but all the code references the original class that reads from a file. This is where the factory pattern comes in handy.

The factory pattern is a class that has some methods that create objects for you. Instead of using new directly, you use the factory class to create objects. That way, if you want to change the types of objects created, you can change just the factory. All the code that uses the factory changes automatically.

Listing 1 shows an example of a factory class. The server side of the equation comes in two pieces: the database, and a set of PHP pages that let you add feeds, request the list of feeds, and get the article associated with a particular feed.
Listing 1. Factory1.php

<?php
interface IUser
{
  function getName();
}

class User implements IUser
{
  public function __construct( $id ) { }

  public function getName()
  {
    return "Jack";
  }
}

class UserFactory
{
  public static function Create( $id )
  {
    return new User( $id );
  }
}

$uo = UserFactory::Create( 1 );
echo( $uo->getName()."\n" );
?>

An interface called IUser defines what a user object should do. The implementation of IUser is called User, and a factory class called UserFactory creates IUser objects. This relationship is shown as UML in Figure 1.
Figure 1. The factory class and its related IUser interface and user class

If you run this code on the command line using the php interpreter, you get this result:

% php factory1.php
Jack
%

The test code asks the factory for a User object and prints the result of the getName method.

A variation of the factory pattern uses factory methods. These public static methods in the class construct objects of that type. This approach is useful when creating an object of this type is nontrivial. For example, suppose you need to first create the object and then set many attributes. This version of the factory pattern encapsulates that process in a single location so that the complex initialization code isn’t copied and pasted all over the code base.

Listing 2 shows an example of using factory methods.
Listing 2. Factory2.php

<?php
interface IUser
{
  function getName();
}

class User implements IUser
{
  public static function Load( $id )
  {
        return new User( $id );
  }

  public static function Create( )
  {
        return new User( null );
  }

  public function __construct( $id ) { }

  public function getName()
  {
    return "Jack";
  }
}

$uo = User::Load( 1 );
echo( $uo->getName()."\n" );
?>

This code is much simpler. It has only one interface, IUser, and one class called User that implements the interface. The User class has two static methods that create the object. This relationship is shown in UML in Figure 2.
Figure 2. The IUser interface and the user class with factory methods

Running the script on the command line yields the same result as the code in Listing 1, as shown here:

% php factory2.php
Jack
%

As stated, sometimes such patterns can seem like overkill in small situations. Nevertheless, it’s still good to learn solid coding forms like these for use in any size of project.

The singleton pattern:

Some application resources are exclusive in that there is one and only one of this type of resource. For example, the connection to a database through the database handle is exclusive. You want to share the database handle in an application because it’s an overhead to keep opening and closing connections, particularly during a single page fetch.

The singleton pattern covers this need. An object is a singleton if the application can include one and only one of that object at a time. The code in Listing 3 shows a database connection singleton in PHP V5.
Listing 3. Singleton.php

<?php
require_once("DB.php");

class DatabaseConnection
{
  public static function get()
  {
    static $db = null;
    if ( $db == null )
      $db = new DatabaseConnection();
    return $db;
  }

  private $_handle = null;

  private function __construct()
  {
    $dsn = 'mysql://root:password@localhost/photos';
    $this->_handle =& DB::Connect( $dsn, array() );
  }

  public function handle()
  {
    return $this->_handle;
  }
}

print( "Handle = ".DatabaseConnection::get()->handle()."\n" );
print( "Handle = ".DatabaseConnection::get()->handle()."\n" );
?>

This code shows a single class called DatabaseConnection. You can’t create your own DatabaseConnection because the constructor is private. But you can get the one and only one DatabaseConnection object using the static get method. The UML for this code is shown in Figure 3.
Figure 3. The database connection singleton

The proof in the pudding is that the database handle returned by the handle method is the same between two calls. You can see this by running the code on the command line.

% php singleton.php
Handle = Object id #3
Handle = Object id #3
%

The two handles returned are the same object. If you use the database connection singleton across the application, you reuse the same handle everywhere.

You could use a global variable to store the database handle, but that approach only works for small applications. In larger applications, avoid globals, and go with objects and methods to get access to resources.

The observer pattern:

The observer pattern gives you another way to avoid tight coupling between components. This pattern is simple: One object makes itself observable by adding a method that allows another object, the observer, to register itself. When the observable object changes, it sends a message to the registered observers. What those observers do with that information isn’t relevant or important to the observable object. The result is a way for objects to talk with each other without necessarily understanding why.

A simple example is a list of users in a system. The code in Listing 4 shows a user list that sends out a message when users are added. This list is watched by a logging observer that puts out a message when a user is added.
Listing 4. Observer.php

<?php
interface IObserver
{
  function onChanged( $sender, $args );
}

interface IObservable
{
  function addObserver( $observer );
}

class UserList implements IObservable
{
  private $_observers = array();

  public function addCustomer( $name )
  {
    foreach( $this->_observers as $obs )
      $obs->onChanged( $this, $name );
  }

  public function addObserver( $observer )
  {
    $this->_observers []= $observer;
  }
}

class UserListLogger implements IObserver
{
  public function onChanged( $sender, $args )
  {
    echo( "'$args' added to user list\n" );
  }
}

$ul = new UserList();
$ul->addObserver( new UserListLogger() );
$ul->addCustomer( "Jack" );
?>

This code defines four elements: two interfaces and two classes. The IObservable interface defines an object that can be observed, and the UserList implements that interface to register itself as observable. The IObserver list defines what it takes to be an observer, and the UserListLogger implements that IObserver interface. This is shown in the UML in Figure 4.
Figure 4. The observable user list and the user list event logger

If you run this on the command line, you see this output:

% php observer.php
'Jack' added to user list
%

The test code creates a UserList and adds the UserListLogger observer to it. Then the code adds a customer, and the UserListLogger is notified of that change.

It’s critical to realize that the UserList doesn’t know what the logger is going to do. There could be one or more listeners that do other things. For example, you may have an observer that sends a message to the new user, welcoming him to the system. The value of this approach is that the UserList is ignorant of all the objects depending on it; it focuses on its job of maintaining the user list and sending out messages when the list changes.

This pattern isn’t limited to objects in memory. It’s the underpinning of the database-driven message queuing systems used in larger applications.

The chain-of-command pattern:

Building on the loose-coupling theme, the chain-of-command pattern routes a message, command, request, or whatever you like through a set of handlers. Each handler decides for itself whether it can handle the request. If it can, the request is handled, and the process stops. You can add or remove handlers from the system without influencing other handlers. Listing 5 shows an example of this pattern.
Listing 5. Chain.php

<?php
interface ICommand
{
  function onCommand( $name, $args );
}

class CommandChain
{
  private $_commands = array();

  public function addCommand( $cmd )
  {
    $this->_commands []= $cmd;
  }

  public function runCommand( $name, $args )
  {
    foreach( $this->_commands as $cmd )
    {
      if ( $cmd->onCommand( $name, $args ) )
        return;
    }
  }
}

class UserCommand implements ICommand
{
  public function onCommand( $name, $args )
  {
    if ( $name != 'addUser' ) return false;
    echo( "UserCommand handling 'addUser'\n" );
    return true;
  }
}

class MailCommand implements ICommand
{
  public function onCommand( $name, $args )
  {
    if ( $name != 'mail' ) return false;
    echo( "MailCommand handling 'mail'\n" );
    return true;
  }
}

$cc = new CommandChain();
$cc->addCommand( new UserCommand() );
$cc->addCommand( new MailCommand() );
$cc->runCommand( 'addUser', null );
$cc->runCommand( 'mail', null );
?>

This code defines a CommandChain class that maintains a list of ICommand objects. Two classes implement the ICommand interface — one that responds to requests for mail and another that responds to adding users. The UML is shows in Figure 5.
Figure 5. The command chain and its related commands

If you run the script, which contains some test code, you see the following output:

% php chain.php
UserCommand handling 'addUser'
MailCommand handling 'mail'
%

The code first creates a CommandChain object and adds instances of the two command objects to it. It then runs two commands to see who responds to those commands. If the name of the command matches either UserCommand or MailCommand, the code falls through and nothing happens.

The chain-of-command pattern can be valuable in creating an extensible architecture for processing requests, which can be applied to many problems.

The strategy pattern:

The last design pattern we will cover is the strategy pattern. In this pattern, algorithms are extracted from complex classes so they can be replaced easily. For example, the strategy pattern is an option if you want to change the way pages are ranked in a search engine. Think about a search engine in several parts — one that iterates through the pages, one that ranks each page, and another that orders the results based on the rank. In a complex example, all those parts would be in the same class. Using the strategy pattern, you take the ranking portion and put it into another class so you can change how pages are ranked without interfering with the rest of the search engine code.

As a simpler example, Listing 6 shows a user list class that provides a method for finding a set of users based on a plug-and-play set of strategies.
Listing 6. Strategy.php

<?php
interface IStrategy
{
  function filter( $record );
}

class FindAfterStrategy implements IStrategy
{
  private $_name;

  public function __construct( $name )
  {
    $this->_name = $name;
  }

  public function filter( $record )
  {
    return strcmp( $this->_name, $record ) <= 0;
  }
}

class RandomStrategy implements IStrategy
{
  public function filter( $record )
  {
    return rand( 0, 1 ) >= 0.5;
  }
}

class UserList
{
  private $_list = array();

  public function __construct( $names )
  {
    if ( $names != null )
    {
      foreach( $names as $name )
      {
        $this->_list []= $name;
      }
    }
  }

  public function add( $name )
  {
    $this->_list []= $name;
  }

  public function find( $filter )
  {
    $recs = array();
    foreach( $this->_list as $user )
    {
      if ( $filter->filter( $user ) )
        $recs []= $user;
    }
    return $recs;
  }
}

$ul = new UserList( array( "Andy", "Jack", "Lori", "Megan" ) );
$f1 = $ul->find( new FindAfterStrategy( "J" ) );
print_r( $f1 );

$f2 = $ul->find( new RandomStrategy() );
print_r( $f2 );
?>

The UML for this code is shown in Figure 6.
Figure 6. The user list and the strategies for selecting users

The UserList class is a wrapper around an array of names. It implements a find method that takes one of several strategies for selecting a subset of those names. Those strategies are defined by the IStrategy interface, which has two implementations: One chooses users randomly and the other chooses all the names after a specified name. When you run the test code, you get the following output:

% php strategy.php
Array
(
    [0] => Jack
    [1] => Lori
    [2] => Megan
)
Array
(
    [0] => Andy
    [1] => Megan
)
%

The test code runs the same user lists against two strategies and shows the results. In the first case, the strategy looks for any name that sorts after J, so you get Jack, Lori, and Megan. The second strategy picks names randomly and yields different results every time. In this case, the results are Andy and Megan.

The strategy pattern is great for complex data-management systems or data-processing systems that need a lot of flexibility in how data is filtered, searched, or processed.

#1. Net Panel

The Net Panel can be used for measuring the performance of your webpage. It shows very useful informations about how long your webpage takes to load, the size and loading time of each and every files (i.e: image files, css, js file and so on.) of your webpage. if you are looking for the way to improve the performance of your webpage, you just need to check the NET panel after loading your page and see which files took so long to load.

1.1. What is Net panel showing?

Let’s take a lot what kinda information NET panel shows for you. There are four columns in NET panel.

1. Name of files : The first column at the left-side shows the name of each and every files that are included in your webpage.
2. Base URL : The second column shows the base URL of each file. If you are using some files from other sites (eg: linking image from other site, putting ads in your blog ) then the different URL(s) will be shown in this column.
3. Size : The third column shows the size of each file.
4. Loading Time : The last column shows the loading time of each file and whether those files are loaded from cache or not. It also show the status of each file in different colors as below. ( Thanks to Jack Sleight for the explanation of color and its

1. description )
   1. Green : Loading the file from server.
   2. Dark Grey : Request sent to server, file loaded from server
   3. Light Grey: Request sent to server, “Not Modified” received, file loaded from the cache.
   4. No bar for the file: No request sent to server, file loaded from cache

You should also note that the list of files showing in the Net panel are sorted based on the order of how Firefox loaded those files.

1.2. HTTP Headers

The Net panel shows the HTTP headers of every request/response messages so you can easily find out the interesting information like the parameters that are passed to server, the type of webserver, cookies and etc.

1.3. Filter the requests by type

If there are a lot of requests shown in Net panel, you can filter all of those requests based on the type of requests. For example, If you like to check the requests for image only then you can click the button called “Images” on toolbar to filter the requests for images.

1.4. Full path of files and Image Preview

If you move your cursor on the name of file (at the first column of Net panel), it will show you the full path of the file as a clickable link. If it is an image file then the actual image will be shown as a preview in Net panel. (Please check-out the pic below.)

Summary about Net panel

• It shows the headers for request/response messages for all kind of requests
• It can be used for XMLHttpRequest monitoring ( The Console panel does this too. You may check “Tracing XmlHttpRequest object” in this tutorial. )
• It sorts the files based on how Firefox loaded those files.
• It shows the loading time, the size of each and every files.
• It shows a particular file is loaded from server or cache.
• Net panel is a packet sniffer. ( not like YSlow which is a DOM crawler.)

Well. that’s all about Net panel. What do you think? Please leave a comment if you have any suggestion or comment.

#2. CSS Panel

The CSS panel allows you to view/edit the stylesheet of your page. It is just very simple panel and doesn’t have so much feature in it.

2.1. List of CSS files

To see all CSS files of your page, just click the button (”michaelsync.net” for my case) beside “Edit” button. Then, the content menu will be shown and all CSS files will be listed on that menu. So, you can simply click any CSS file that you wanna view.

2.2 Normal Mode Vs Editable Mode of CSS Panel

Like HTML tab, it has normal mode and editable mode. If you click “Edit” button on the toolbar of CSS panel, it will become the editable mode.

Normal Mode

• Advantages
  • It shows the highlighted CSS syntax so looks nice.
  • It allows you to edit the attribute of CSS class.
  • It autocompletes as you type against the list of possible values for the property you are editing
  • It allows you to disable a particular style on the fly.
• Disadvantages
  • You can’t create new CSS class in this view.
  • It is difficult to remove one or more CSS class(es) from the file

Editable Mode

• Advantages
  • You got the full control of your CSS file so that you can edit/remove the CSS class as many as you want. You will feel like writing in notepad.
• Disadvantages
  • You will lost all syntaxhighlighting or autocomplete feature of CSS panel.

#3. DOM panel

It shows all default DOM properties, functions, constants, the user-defined properties and user-defined function.This panel is not very helpful (at least for me) except one thing. If you wanna find out how many function or properties included your scripts, you may probably want to use this panel to find out about that.

Let’s write one short script as below in plain HTML file.

And then, save it as htm file. Open it in Firefox and then check the DOM tab. You will see the result as the picture below. “Car()” is a function that you just wrote in JS, isn’t it?

Okay. That’s all about DOM tab. This is the feature what DOM tab has so far….

My tutorials for Firebug is ended here. I hope that you all do enjoy reading all of my tutorials. Actually, I’m not teaching you about Firebug. I’m just sharing the way I understand about Firebug and I believe that you found it useful. Any feedback are welcome as usual. Feel free to let me know if you have any suggestion or comment.

One more thing is that Yahoo is releasing the Firefox addon called YSlow integreated with Firebug. This tool is also a performance measuring tool like Net panel. YSlow used to determine the performance of webpage based on 13 rules

on behalf of -> http://michaelsync.net/category/firebug

Novelist Evan Hunter based his screenplay upon the 1952 collection of short stories of the same name by Daphne du Maurier – Hitchcock’s third major film based on the author’s works (after Jamaica Inn (1939) and Rebecca (1940)). In du Maurier’s story, the birds were attacking in the English countryside, rather than in a small town north of San Francisco. The film’s technical wizardry is extraordinary, especially in the film’s closing scene (a complex, trick composite shot) – the special visual effects of Ub Iwerks were nominated for an Academy Award (the film’s sole nomination), but the Oscar was lost to Cleopatra. Hundreds of birds (gulls, ravens, and crows) were trained for use in some of the scenes, while mechanical birds and animations were employed for others.

The film’s non-existent musical score is replaced by an electronic soundtrack (including simulated bird cries and wing-flaps), with Hitchcock’s favorite composer Bernard Herrmann serving as a sound consultant. It was shot on location in the port town of Bodega Bay (north of San Francisco) and in San Francisco itself. Hitchcock introduced a ‘fascinating new personality’ for the film – his successor to Grace Kelly – a cool, blonde professional model named ‘Tippi’ Hedren, in her film debut in a leading role. [Hedren reprised her character in a minor supporting role, in an inferior made-for-TV sequel, The Birds II: Land's End (1994), set in the New England fishing town of Land's End. The director was Rick Rosenthal, although the standard generic pseudonym 'Alan Smithee' is found in the credits. Leads Rod Taylor and Tippi Hedren are replaced by Brad Johnson and Chelsea Field.]

Initially, critics were baffled when they attempted to interpret the film on a literal level and measure it against other typical disaster/horror films of its kind. The typical Hitchcock MacGuffin is the question: Why do the strange attacks occur? But the film cannot solely be interpreted that way, because as the actors in the film discover in the long discussion scene in the Tides Restaurant, there is no solid, rational reason why the birds are attacking. They are not seeking revenge for nature’s mistreatment, or foreshadowing doomsday, and they don’t represent God’s punishment for humankind’s evil.

When this is understood, the symbolic film’s complex fabric makes more sense, especially if interpreted in Freudian terms. It is about three needy women (literally ‘birds’) – and a fourth from a younger generation – each flocking around and vying for varying degrees of affection and attention from the sole, emotionally-cold male lead, and the fragile tensions, anxieties and unpredictable relations between them. The attacks are mysteriously related to the mother and son relationship in the film – anger (and fears of abandonment or being left lonely) of the jealous, initially hostile mother surface when her bachelor son brings home an attractive young woman. Curiously, the first attack has symbolic phallic undertones – it occurs when the man and woman approach toward each other outside the restaurant in the coastal town.

On an allegorical level, the birds in the film are the physical embodiment and exteriorization of unleashed, disturbing, shattering forces that threaten all of humanity (those threatened in the film include schoolchildren, a defenseless farmer, bystanders, a schoolteacher, etc.) when relationships have become insubstantial, unsupportive, or hurtful. In a broader, more universal sense, the stability of the home and natural world environment, symbolized by broken teacups at the domestic level, is in jeopardy and becoming disordered when people cannot ‘see’ the dangers gathering nearby, and cannot adequately protect themselves from violence behind transparent windows, telephone booths, eyeglasses, or facades. Numerous allusions to blindness are sprinkled throughout the film (the farmer’s eyes are pecked out, the children play blindman’s bluff at the birthday party, the broken glasses of the fleeing schoolchild, etc.), giving the hint that the camera’s voyeuristic lens (and its screen-viewing audience) is also being subjected to assault.

Prerequisites

You will need a working Joomla! install, though using the latest available release of Joomla! 1.0 is always the best option. It is suggested that if you are using 1.0.13 you install Rob Schley’s patch for admin sessions. As with everything you should take a full backup of everything before you start just in case something does go wrong. We advise that you do not destroy your 1.0.x install until you have completely finished migrating to 1.5 and are happy that things are working properly. Ideally you should complete migration using a testing system first before attempting it on your production system (e.g. either by using sites restored from backups or other replicas) and when deploying, separate your 1.0.x install from 1.5 (e.g. different database or at the least a different prefix).

If you’re using a UTF-8 database please make sure that you have followed David Gal’s Joomla! UTF-8 guide before you export from your Joomla! 1.0 site – this will make your dump file in UTF-8 format so when you come to the relevant part of the Joomla! 1.5 installation your encoding will be UTF-8.

If you aren’t creating UTF-8 dump files then you are going to need to either have iconv installed on your server where you’re installing 1.5 so it can automatically convert your dump file or convert it from what ever encoding it is presently into UTF-8 prior to migration. You can check if you have iconv by looking at the output of phpinfo for ‘iconv’, available in the help system of Joomla! (System -> System Info -> PHP Info under Joomla! 1.0 and Help -> System Info -> PHP Information under Joomla! 1.5). iconv is a relatively common extension that should be available in most situations, refer to either the PHP documentation or your hosting provider on how you can enable iconv.

Step 1: Downloading the Migrator component and installing it into your 1.0 instance

The latest version of the migrator component exists at the Pasamio Project’s FRS site. At the time of writing the latest release is Migrator 1.5. Download the Migrator component to your system and then install it into the 1.0 install. This is done like any normal component install. There will be a Migrator entry in the Component menu option where you can access the Migrator.

Step 2: Installing Third Party Migrator plugins

The Migration system only handles the core system in its migration which means that if you want to include third party extension data from other tables you will have to install migrator plugins to handle the migration of this data. There are two types of plugins that are used: an “SQL” plugin which is a plain text SQL file and an “ETL” Plugin which is a bit of PHP that tells the migrator how to handle the data stored in tables (or in configuration files). This is done by selecting “Add Third Party Migrators”, and then locating the plugin you wish to install and uploading the file. SQL files will be prepended to the output automatically and ETL plugins will be executed automatically. You can view a list of ETL plugins by clicking “List Plugins” in the main screen. You can also upload ETL plugins to the “plugins” directory in the “/administrator/components/com_migrator” directory in your Joomla! site.

The JED lists third party migrator ETL plugins.

Step 3: Creating the Migration SQL File

Once you have installed any third party migrator plugins, you can select the “Create Migration SQL file” to begin the creation process. The system is designed to build an SQL file without causing a timeout on the server, so you may notice that the page automatically refreshes and displays status information. Eventually it will display a notification that the process has been completed and the SQL file will be available for download. Part of the SQL file generation involves the alteration of various fields to make them compatible with changes made in Joomla! 1.5, including the rewriting of mosimage tags.

Step 4: Installing Joomla! 1.5

Note: Create your new Joomla! 1.5 install in a separate directory and database to your existing install (or different prefix if you cannot create a new database). You cannot extract over the top of your 1.0 install, you have to create a new Joomla! 1.5 site. Alternatively, move your 1.0 install to a safe location and install into the empty directory 1.0 will have created. It is not a very good idea to install a new Joomla! 1.5 site over the top of your existing 1.0 site, it is better to test things in a seperate directory and progress from there.

If you can’t install Joomla!, or Joomla! has already been installed, you can use the Migration Assistant in your 1.5 site. Note that beyond itself it will wipe out the 1.5 site’s database back to a clean install and then do the migration. Any information that is in the 1.5 sites database will be deleted. The migration assistant is available at the same place as the Migrator, the latest version is Migration Assistant 1.5.2. There may be a later version, so check Pasamio Project’s FRS site for any updates.

If you haven’t done so already, take a full back up of your 1.0 site, including all of the filesystem and the database. Do not proceed without a backup.

The last phase of the migration is the installation of a new Joomla! 1.5 site. You need to install ’1.5 into a completely new directory, you should keep this separate to your 1.0 directory. If you just unzip over the top of your existing 1.0 site, you will have issues with it finding an invalid copy of the configuration.php” file, so either move your original install or create a new directory. Complete the initial steps of the installation as per a normal installation. In the final step where you are prompted for the site name you are given the opportunity to initiate the migration process. Migration requires the generated SQL file to complete its operation, which might need to be uploaded to your new 1.5 site, there are two options for doing this:

• HTTP Upload
• FTP/SCP Upload

The first method, HTTP upload, is best for smaller SQL files that will fit within the upload limits of PHP. The alternative is to upload a file using either FTP, SCP or some other method of file transfer that your hosting provider offers. This is useful for larger SQL files that would normally not be permitted by PHP. To use the HTTP method, simply select the file like a normal component installation. To use the alternative upload method, upload the files into the installation/sql/migration folder and rename the file to be called “migrate.sql”. If for some reason the migration fails you will need to reupload the SQL file for both methods, HTTP and FTP/SCP, as the file is altered through the migration process. The prefix for all migration dumps is “jos_”, this should be placed into the provided text box. Once migration has been completed, enter in a site name (the site name cannot be migrated for technical reasons) and finish the installation.

Using either method the “/installation/sql/migration” folder and your temporary files folder (e.g. “/tmp”) need to be writeable by the web user (e.g. “wwwrun”, “www-data” or “apache”). The migrator will write data back to these locations as it updates the dump files.

Please note you also need to tick the “This script is a Joomla! 1.0 migration script” box as well before you migrate otherwise you will have issues with importing data.