The following Kohana libraries are loaded automatically by the framework and should always be available to you:

• URI
• Input

Other libraries can be loaded automatically by Kohana when they are used. For example, to load and use the Profiler library, you can just add the following line to your controller's constructor:

  $this->profiler = new Profiler;

For more information, see the page on Loading.

When creating your own libraries, these are the conventions that are required:

• Library files put into application/libraries (or if you're creating a module, in modules/libraries)
• Library files named the same as the library class (but without any ”_Core” suffix).
• Library class names and file names begin with a capitalized letter (eg., “Contact”)
• For a new library, the class name can have ”_Core” appended to the end to enable you to extend it in the same way you can with Kohana's built-in libraries.

For example, lets suppose that you wanted to create a new “book” library. You might create the following file:

File: application/libraries/Book.php

<?php defined('SYSPATH') or die('No direct script access.');
 
class Book_Core {
 
	// add constructor/methods/properties here
 
}
 
?>

Kohana also allows you to extend its built-in libraries so that you can add your own functionality to them, or change the way they work. You should never change the files in system/libraries. Instead you can create a new library that extends a built-in library.

You can also extend your own libraries, so long as you have added ”_Core” to the end of their class names.

When extending a library, the conventions are the same as for when you are creating a new library, with a couple of exceptions:

• The filename must be prefixed with ”MY_”. This prefix is configurable; see the configuration page.
• The class name must be the same as the class name you are extending and must not have ”_Core” appended to it.

Lets say, for example, that you want to extend Kohana's controller class. You might do the following:

File: application/libraries/MY_Controller.php

<?php defined('SYSPATH') or die('No direct script access.');
 
class Controller extends Controller_Core {
 
	public function __construct()
	{
		// don't for get to call the parent constructor!
		parent::__construct();
	}
 
}
 
?>

Extending the core classes is not only allowed in Kohana, but is expected. If you wish to implement behaviour that should apply to a kohana class, such as site-wide behaviour, this is the preferred way to achieve it.

Here are some examples of why you might want to extend Kohana's Controller class in particular:

• You may wish to implement site-wide page caching.
• You may wish to implement an authentication mechanism.
• You might want to provide layout, or templating methods to a controller. These could be implemented in your extended controller and would be accessible to every controller in the application.

You may wish to autoload models and libraries, this can be achieved by extending the core Controller class and loading any libraries and models from the constructor.

It is also possible (although probably less often required) to replacing one of Kohana's built-in libraries entirely. The conventions are the same as when you are adding your own library, with one exception:

• Appending ”_Core” to the class name is not optional - you must do it!

If, for example, you want to replace the Profiler library, you might create the following file:

File: application/libraries/Profiler.php

<?php defined('SYSPATH') or die('No direct script access.');
 
class Profiler_Core {
 
	// define your own profiler here
 
}
 
?>

If you should require 3rd-party libraries (such as Simplepie, Zend Framework, or Pear libraries) you can place these in the application/vendor directory. Loading them from Kohana is simple. You might do the following:

  include Kohana::find_file('vendor','some_class')

For more information, see the Kohana class page.

Note that some 3rd party libraries can be adjusted to be Kohana libraries without much effort, sometimes renaming the file and the class name is all that is necessary.

Zend Framework's files may struggle to load it's dependencies which will be loaded incorrectly without further configuration. If the zend folder is in applications/vendor/zend the following code can be used.

// make sure you put this somewhere before loading a Zend Framework component
ini_set('include_path', ini_get('include_path').PATH_SEPARATOR.APPPATH.'vendor/zend/library/');

To include a Zend Framework component, you might do the following:

// example
require_once 'Zend/Service/Flickr.php';
 
// or another example
require_once 'Zend/Acl.php';
$acl = new Zend_Acl();

You can also delegate file loading to the Zend autoloader. The advantage of doing it this way is that the autoloader will take care of requiring all the file dependancies. Take a look at the following example:

// assumes you have put the Zend framework in your vendor folder
if ($path = Kohana::find_file('vendor', 'Zend/Loader'))
{
    ini_set('include_path', ini_get('include_path').PATH_SEPARATOR.dirname(dirname($path)));
    require_once 'Zend/Loader/Autoloader.php';
    Zend_Loader_Autoloader::getInstance();
}
 
// example
$acl = new Zend_Acl();

Note that it also can be placed in the SYSPATH folder but it then might be overwritten by a new version of Kohana. Module folders will do as well. In this case use

ini_set('include_path',ini_get('include_path').PATH_SEPARATOR.SYSPATH.'vendor/zend/library/');