Joomla! Documentation - User contributions [en]

J1.5:Developing a MVC Component/Introduction

2012-08-15T23:58:25Z

Ian: /* Joomla! MVC Implementation */

{{Chunk:Developing a Model-View-Controller (MVC) Component for Joomla!1.5 - Contents}}
== Introduction ==
A software framework is the base of an application that can be used by a developer. The framework in Joomla! 1.5 unleashes a great deal of power for them. The Joomla! code has been designed for extensibility. This tutorial will guide you through the process of developing a component using the framework.

The scope of this project will be to develop a simple Hello World! component. In future tutorials, this simple framework will be built upon to show the full power and versatility of the MVC design pattern in Joomla!

== Requirements ==
You need Joomla! 1.5 for this tutorial.

== Introduction to Model-View-Controller ==
{|
| colspan=2|While the idea behind a component may seem extremely simple, code can quickly become very complex as additional features are added or the interface is customized.
|-
|Model-View-Controller (herein referred to as MVC) is a software design pattern that can be used to organize code in such a way that the business logic and data presentation are separate. The premise behind this approach is that if the business logic is grouped into one section, then the interface and user interaction that surrounds the data can be revised and customized without having to reprogram the business logic. MVC was originally developed to map the traditional input, processing, output roles into a logical GUI architecture.
|[[Image:MVC basics.png|180px|right]]
|-
| colspan=2|These three main roles are the basis for the Joomla MVC. They are described here in brief, but for a more thorough explanation, please refer to the links provided at the end of this tutorial.
|}
=== Model ===
The model is the part of the component that encapsulates the application's data. It will often provide routines to manage and manipulate this data in a meaningful way in addition to routines that retrieve the data from the model. In our case, the model will contain methods to add, remove and update information about the greetings in the database. It will also contain methods to retrieve the list of greetings from the database. In general, the underlying data access technique should be encapsulated in the model. In this way, if an application is to be moved from a system that utilizes a flat file to store its information to a system that uses a database, the model is the only element that needs to be changed, not the view or the controller.

=== View ===
The view is the part of the component that is used to render the data from the model in a manner that is suitable for interaction. For a web-based application, the view would generally be an HTML page that is returned to the user. The view pulls data from the model (which is passed to it from the controller) and feeds the data into a template which is populated and presented to the user. The view does not cause the data to be modified in any way, it only displays data retrieved from the model.

=== Controller ===
The controller is responsible for responding to user actions. In the case of a web application, a user action is (generally) a page request. The controller will determine what request is being made by the user and respond appropriately by triggering the model to manipulate the data appropriately and passing the model into the view. The controller does not display the data in the model, it only triggers methods in the model which modify the data, and then pass the model into the view which displays the data.

=== MVC connection ===
[[image:MVC joomla.png|frameless|right]]The simplified picture on the right depicts the basic components being used within Joomla. Besides the Model, the View and the Controller, an Entry Point has been added that is depicted as a small circle. Attached to the viewer (view) a Template has been added. With these five components you should be able to understand this tutorial about making a basic Joomla! MVC component.

Part 1 of the tutorial only focuses on the Controller and the View (with the use of the Template); these are marked with the blue colour in the picture. Part 2 adds and Part 3 extends the model functionality for the data manipulation abstraction; marked with the green colour in the picture.

Keep in mind that this simplified picture only applies for the site section (i.e the front-end). An identical picture is applicable for the admin section (i.e. the back-end). The administrative section is taken care of in Parts 4 through 6 of this component development tutorial. Both the site and the admin section are maintained and configured in an XML based installation file (typically termed a manifest file).

== Joomla! MVC Implementation ==
In Joomla!, the MVC pattern is implemented using three classes: [http://api.joomla.org/1.5/Joomla-Framework/Application/JModel.html JModel], [http://api.joomla.org/1.5/Joomla-Framework/Application/JView.html JView] and [http://api.joomla.org/1.5/Joomla-Framework/Application/JController.html JController]. For more detailed information about these classes, please refer to the API reference documentation (WIP).

For learning purposes and debugging, adding a run-time debugger to your Joomla! site might be a good extension especially during development of your (tutorial) component. A good example is the community project [http://extensions.joomla.org/extensions/miscellaneous/development/1509/details J!Dump] that has the advantage of being a pop-up which leaves the view output unchanged. The J!Dump system allows you to view not only your development properties but also the methods.

== Creating a Component ==
For our basic component, we only require five files:

* site/hello.php - this is the entry point to our component
* site/controller.php - this file contains our base controller
* site/views/hello/view.html.php - this file retrieves the necessary data and pushes it into the template
* site/views/hello/tmpl/default.php - this is the template for our output
* hello.xml - this is an XML (manifest) file that tells Joomla! how to install our component.

Remember that the filename for the entry point must have the same name of the component. For example, if you call your component "Very Intricate Name Component", at install time (see below in the hello.xml section) Joomla! will create the folder com_veryintricatenamecomponent and the entry point php file must be named veryintricatenamecomponent.php otherwise it will not work. Be aware that use of some special characters, notibly the underscore '_', may have special meaning in Joomla and should be avoided in component names or files.

The site directory here is for the parts of the component which are installed in the front end site.

=== Naming conventions ===

Main article: [[Naming conventions]]

At this point it is important to say that some words are reserved for using in component or its class names, and violating some of that will produce a hard for debugging error. One of them is "view" (in any character case) for view class (subclass of JView) and controller class (subclass of JController), because view class need to have first part of name the same as controller class name, and component name (although violating of last one won't produce an error, it's just a useful convention).

All filenames and foldernames for models, views and controllers must be lower-case in order to operate well on Unix/Linux-systems.

=== Creating the Entry Point ===
{{review}}
Joomla! is always accessed through a single point of entry: index.php for the Site Application or administrator/index.php for the Administrator Application. The application will then load the required component, based on the value of 'option' in the URL or in the POST data. For our component, the URL would be:

<source lang="php">index.php?option=com_hello&view=hello</source>

This will load our main file, which can be seen as the single point of entry for our component: components/com_hello/hello.php.

The code for this file is fairly typical across components.

site/hello.php:
<source lang="php"><?php
/**
* @package Joomla.Tutorials
* @subpackage Components
* components/com_hello/hello.php
* @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
* @license GNU/GPL
*/

// No direct access
defined( '_JEXEC' ) or die( 'Restricted access' );

// Require the base controller

require_once( JPATH_COMPONENT.DS.'controller.php' );

// Require specific controller if requested
if($controller = JRequest::getWord('controller')) {
$path = JPATH_COMPONENT.DS.'controllers'.DS.$controller.'.php';
if (file_exists($path)) {
require_once $path;
} else {
$controller = '';
}
}

// Create the controller
$classname = 'HelloController'.$controller;
$controller = new $classname( );

// Perform the Request task
$controller->execute( JRequest::getWord( 'task' ) );

// Redirect if set by the controller
$controller->redirect();</source>

The first statement is a security check.

JPATH_COMPONENT is the absolute path to the current component, in our case components/com_hello. If you specifically need either the Site component or the Administrator component, you can use JPATH_COMPONENT_SITE or JPATH_COMPONENT_ADMINISTRATOR.

DS is the directory separator of your system: either '/' or '\'. This is automatically set by the framework so the developer doesn't have to worry about developing different versions for different server OSs. The 'DS' constant should always be used when referring to files on the local server.

After loading the base controller, we check if a specific controller is needed. In this component, the base controller is the only controller, but we will leave this conditional check "in place" for future use.

JRequest::getWord() finds a word variable in the URL or the POST data. So if our URL is index.php?option=com_hello&controller=controller_name, then we can retrieve our controller name in our component using: echo JRequest::getWord('controller');

Now we have our base controller 'HelloController' in com_hello/controller.php, and, if needed, additional controllers like 'HelloControllerController1' in com_hello/controllers/controller1.php. Using this standard naming scheme will make things easy later on: '{Componentname}{Controller}{Controllername}'

After the controller is created, we instruct the controller to execute the task, as defined in the URL: index.php?option=com_hello&task=sometask. If no task is set, the default task 'display' will be assumed. When display is used, the 'view' variable will decide what will be displayed. Other common tasks are save, edit, new...

The controller might decide to redirect the page, usually after a task like 'save' has been completed. This last statement takes care of the actual redirection.

The main entry point (hello.php) essentially passes control to the controller, which handles performing the task that was specified in the request.

Note that we don't use a closing php tag in this file: ?>. The reason for this is that we will not have any unwanted whitespace in the output code. This is default practice since Joomla! 1.5, and will be used for all php-only files.

=== Creating the Controller ===
Our component only has one task - greet the world. Therefore, the controller will be very simple. No data manipulation is required. All that needs to be done is the appropriate view loaded. We will have only one method in our controller: display(). Most of the required functionality is built into the JController class, so all that we need to do is invoke the JController::display() method.

The code for the base controller site/controller.php is:
<source lang="php"><?php
/**
* @package Joomla.Tutorials
* @subpackage Components
* @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
* @license GNU/GPL
*/

// No direct access

defined( '_JEXEC' ) or die( 'Restricted access' );

jimport('joomla.application.component.controller');

/**
* Hello World Component Controller
*
* @package Joomla.Tutorials
* @subpackage Components
*/
class HelloController extends JController
{
/**
* Method to display the view
*
* @access public
*/
function display()
{
parent::display();
}

}</source>

The JController constructor will always register a display() task and unless otherwise specified (using the registerDefaultTask() method), it will set it as the default task.

This barebones display() method isn't really even necessary since all it does is invoke the parent constructor. However, it is a good visual clue to indicate what is happening in the controller.

The JController::display() method will determine the name of the view and layout from the request and load that view and set the layout. When you create a menu item for your component, the menu manager will allow the administrator to select the view that they would like the menu link to display and to specify the layout. A view usually refers to a view of a certain set of data (i.e. a list of cars, a list of events, a single car, a single event). A layout is a way that that view is organized.

In our component, we will have a single view called hello, and a single layout (default).

=== Creating the View ===
The task of the view is very simple: It retrieves the data to be displayed and pushes it into the template. Data is pushed into the template using the JView::assignRef method.
<small>(Note: The key (the first argument) passed to the assignRef method cannot be preceded by an underscore i.e. $this->assignRef('_greeting',$greeting). Doing so will cause the assignRef method to return false and your variable will not be pushed into the template.)</small>

The code for the view at site/views/hello/view.html.php:

<source lang="php"><?php
/**
* @package Joomla.Tutorials
* @subpackage Components
* @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
* @license GNU/GPL
*/

// no direct access

defined( '_JEXEC' ) or die( 'Restricted access' );

jimport( 'joomla.application.component.view');

/**
* HTML View class for the HelloWorld Component
*
* @package HelloWorld
*/

class HelloViewHello extends JView
{
function display($tpl = null)
{
$greeting = "Hello World!";
$this->assignRef( 'greeting', $greeting );

parent::display($tpl);
}
}</source>

==== Creating the Template ====

Joomla! templates/layouts are regular PHP files that are used to layout the data from the view in a particular manner. The variables assigned by the JView::assignRef method can be accessed from the template using $this->{propertyname} (see the template code below for an example).

Our template is very simple: we only want to display the greeting that was passed in from the view - this file is:<br>site/views/hello/tmpl/default.php:

<source lang="php"><?php

// No direct access

defined('_JEXEC') or die('Restricted access'); ?>
<h1><?php echo $this->greeting; ?></h1></source>

=== Wrapping It All Up - Creating the hello.xml File ===
It is possible to install a component manually by copying the files using an FTP client and modifying the database tables. It is more efficient to create a package file that will allow the Joomla! Installer to do this for you. This package file contains a variety of information:

* basic descriptive details about your component (i.e. name), and optionally, a description, copyright and license information.
* a list of files that need to be copied.
* optionally, a PHP file that performs additional install and uninstall operations.
* optionally, an SQL file which contains database queries that should be executed upon install/uninstall

The format of the XML file at hello.xml is as follows:

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<install type="component" version="1.5.0">
<name>Hello</name>

<creationDate>2007-02-22</creationDate>
<author>John Doe</author>
<authorEmail>john.doe@example.org</authorEmail>
<authorUrl>http://www.example.org</authorUrl>
<copyright>Copyright Info</copyright>
<license>License Info</license>

<version>1.01</version>

<description>Description of the component ...</description>



<files folder="site">
<filename>controller.php</filename>
<filename>hello.php</filename>
<filename>index.html</filename>
<filename>views/index.html</filename>
<filename>views/hello/index.html</filename>
<filename>views/hello/view.html.php</filename>
<filename>views/hello/tmpl/default.php</filename>
<filename>views/hello/tmpl/index.html</filename>
</files>

<administration>

<menu>Hello World!</menu>


<files folder="admin">
<filename>hello.php</filename>
<filename>index.html</filename>
</files>

</administration>
</install></source>

{{notice|
Put this xml file, also called manifest, in the root of your package (because the installer will take its path as the root path for all other files).{{1}}Don't include itself under <files>...}}

You may have noticed the manifest source above mentioned files we have not discussed. These are the index.html files and the admin files. An index.html file is placed in each directory to prevent prying users from getting a directory listing. If there is no index.html file, some web servers will list the directory contents. This is often undesirable. These files have the simple line:

<source lang="php"><html><body bgcolor="#FFFFFF"></body></html></source>

It will simply display a blank page.

The hello.php file in the admin folder is the entry point for the our component's admin section. Since our component has no administrator needs (yet), this file will have the same content as the index.html files for now.

If you've followed along, you can visit URL index.php?option=com_hello to see your work. To do this, zip up the main folder and install via the extensions manager. If it still does not work, download the package at the bottom of this page and install for a working example.

== Contributors ==
* mjaz
* staalanden
* dannystaple
* Stilgar
* presto

== Download ==
The component can be downloaded at: [http://joomlacode.org/gf/download/frsrelease/8108/29433/com_hello1_01.zip com_hello1_01]

[[Category:Tutorials]]
[[Category:Component Development]]

J1.5:Developing a MVC Component/Introduction

2012-08-15T23:55:40Z

Ian: /* Requirements */

{{Chunk:Developing a Model-View-Controller (MVC) Component for Joomla!1.5 - Contents}}
== Introduction ==
A software framework is the base of an application that can be used by a developer. The framework in Joomla! 1.5 unleashes a great deal of power for them. The Joomla! code has been designed for extensibility. This tutorial will guide you through the process of developing a component using the framework.

The scope of this project will be to develop a simple Hello World! component. In future tutorials, this simple framework will be built upon to show the full power and versatility of the MVC design pattern in Joomla!

== Requirements ==
You need Joomla! 1.5 for this tutorial.

== Introduction to Model-View-Controller ==
{|
| colspan=2|While the idea behind a component may seem extremely simple, code can quickly become very complex as additional features are added or the interface is customized.
|-
|Model-View-Controller (herein referred to as MVC) is a software design pattern that can be used to organize code in such a way that the business logic and data presentation are separate. The premise behind this approach is that if the business logic is grouped into one section, then the interface and user interaction that surrounds the data can be revised and customized without having to reprogram the business logic. MVC was originally developed to map the traditional input, processing, output roles into a logical GUI architecture.
|[[Image:MVC basics.png|180px|right]]
|-
| colspan=2|These three main roles are the basis for the Joomla MVC. They are described here in brief, but for a more thorough explanation, please refer to the links provided at the end of this tutorial.
|}
=== Model ===
The model is the part of the component that encapsulates the application's data. It will often provide routines to manage and manipulate this data in a meaningful way in addition to routines that retrieve the data from the model. In our case, the model will contain methods to add, remove and update information about the greetings in the database. It will also contain methods to retrieve the list of greetings from the database. In general, the underlying data access technique should be encapsulated in the model. In this way, if an application is to be moved from a system that utilizes a flat file to store its information to a system that uses a database, the model is the only element that needs to be changed, not the view or the controller.

=== View ===
The view is the part of the component that is used to render the data from the model in a manner that is suitable for interaction. For a web-based application, the view would generally be an HTML page that is returned to the user. The view pulls data from the model (which is passed to it from the controller) and feeds the data into a template which is populated and presented to the user. The view does not cause the data to be modified in any way, it only displays data retrieved from the model.

=== Controller ===
The controller is responsible for responding to user actions. In the case of a web application, a user action is (generally) a page request. The controller will determine what request is being made by the user and respond appropriately by triggering the model to manipulate the data appropriately and passing the model into the view. The controller does not display the data in the model, it only triggers methods in the model which modify the data, and then pass the model into the view which displays the data.

=== MVC connection ===
[[image:MVC joomla.png|frameless|right]]The simplified picture on the right depicts the basic components being used within Joomla. Besides the Model, the View and the Controller, an Entry Point has been added that is depicted as a small circle. Attached to the viewer (view) a Template has been added. With these five components you should be able to understand this tutorial about making a basic Joomla! MVC component.

Part 1 of the tutorial only focuses on the Controller and the View (with the use of the Template); these are marked with the blue colour in the picture. Part 2 adds and Part 3 extends the model functionality for the data manipulation abstraction; marked with the green colour in the picture.

Keep in mind that this simplified picture only applies for the site section (i.e the front-end). An identical picture is applicable for the admin section (i.e. the back-end). The administrative section is taken care of in Parts 4 through 6 of this component development tutorial. Both the site and the admin section are maintained and configured in an XML based installation file (typically termed a manifest file).

== Joomla! MVC Implementation ==
In Joomla!, the MVC pattern is implemented using three classes: [http://api.joomla.org/Joomla-Framework/Application/JModel.html JModel], [http://api.joomla.org/Joomla-Framework/Application/JView.html JView] and [http://api.joomla.org/Joomla-Framework/Application/JController.html JController]. For more detailed information about these classes, please refer to the API reference documentation (WIP).

For learning purposes and debugging, adding a run-time debugger to your Joomla! site might be a good extension especially during development of your (tutorial) component. A good example is the community project [http://extensions.joomla.org/extensions/miscellaneous/development/1509/details J!Dump] that has the advantage of being a pop-up which leaves the view output unchanged. The J!Dump system allows you to view not only your development properties but also the methods.

== Creating a Component ==
For our basic component, we only require five files:

* site/hello.php - this is the entry point to our component
* site/controller.php - this file contains our base controller
* site/views/hello/view.html.php - this file retrieves the necessary data and pushes it into the template
* site/views/hello/tmpl/default.php - this is the template for our output
* hello.xml - this is an XML (manifest) file that tells Joomla! how to install our component.

Remember that the filename for the entry point must have the same name of the component. For example, if you call your component "Very Intricate Name Component", at install time (see below in the hello.xml section) Joomla! will create the folder com_veryintricatenamecomponent and the entry point php file must be named veryintricatenamecomponent.php otherwise it will not work. Be aware that use of some special characters, notibly the underscore '_', may have special meaning in Joomla and should be avoided in component names or files.

The site directory here is for the parts of the component which are installed in the front end site.

=== Naming conventions ===

Main article: [[Naming conventions]]

At this point it is important to say that some words are reserved for using in component or its class names, and violating some of that will produce a hard for debugging error. One of them is "view" (in any character case) for view class (subclass of JView) and controller class (subclass of JController), because view class need to have first part of name the same as controller class name, and component name (although violating of last one won't produce an error, it's just a useful convention).

All filenames and foldernames for models, views and controllers must be lower-case in order to operate well on Unix/Linux-systems.

=== Creating the Entry Point ===
{{review}}
Joomla! is always accessed through a single point of entry: index.php for the Site Application or administrator/index.php for the Administrator Application. The application will then load the required component, based on the value of 'option' in the URL or in the POST data. For our component, the URL would be:

<source lang="php">index.php?option=com_hello&view=hello</source>

This will load our main file, which can be seen as the single point of entry for our component: components/com_hello/hello.php.

The code for this file is fairly typical across components.

site/hello.php:
<source lang="php"><?php
/**
* @package Joomla.Tutorials
* @subpackage Components
* components/com_hello/hello.php
* @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
* @license GNU/GPL
*/

// No direct access
defined( '_JEXEC' ) or die( 'Restricted access' );

// Require the base controller

require_once( JPATH_COMPONENT.DS.'controller.php' );

// Require specific controller if requested
if($controller = JRequest::getWord('controller')) {
$path = JPATH_COMPONENT.DS.'controllers'.DS.$controller.'.php';
if (file_exists($path)) {
require_once $path;
} else {
$controller = '';
}
}

// Create the controller
$classname = 'HelloController'.$controller;
$controller = new $classname( );

// Perform the Request task
$controller->execute( JRequest::getWord( 'task' ) );

// Redirect if set by the controller
$controller->redirect();</source>

The first statement is a security check.

JPATH_COMPONENT is the absolute path to the current component, in our case components/com_hello. If you specifically need either the Site component or the Administrator component, you can use JPATH_COMPONENT_SITE or JPATH_COMPONENT_ADMINISTRATOR.

DS is the directory separator of your system: either '/' or '\'. This is automatically set by the framework so the developer doesn't have to worry about developing different versions for different server OSs. The 'DS' constant should always be used when referring to files on the local server.

After loading the base controller, we check if a specific controller is needed. In this component, the base controller is the only controller, but we will leave this conditional check "in place" for future use.

JRequest::getWord() finds a word variable in the URL or the POST data. So if our URL is index.php?option=com_hello&controller=controller_name, then we can retrieve our controller name in our component using: echo JRequest::getWord('controller');

Now we have our base controller 'HelloController' in com_hello/controller.php, and, if needed, additional controllers like 'HelloControllerController1' in com_hello/controllers/controller1.php. Using this standard naming scheme will make things easy later on: '{Componentname}{Controller}{Controllername}'

After the controller is created, we instruct the controller to execute the task, as defined in the URL: index.php?option=com_hello&task=sometask. If no task is set, the default task 'display' will be assumed. When display is used, the 'view' variable will decide what will be displayed. Other common tasks are save, edit, new...

The controller might decide to redirect the page, usually after a task like 'save' has been completed. This last statement takes care of the actual redirection.

The main entry point (hello.php) essentially passes control to the controller, which handles performing the task that was specified in the request.

Note that we don't use a closing php tag in this file: ?>. The reason for this is that we will not have any unwanted whitespace in the output code. This is default practice since Joomla! 1.5, and will be used for all php-only files.

=== Creating the Controller ===
Our component only has one task - greet the world. Therefore, the controller will be very simple. No data manipulation is required. All that needs to be done is the appropriate view loaded. We will have only one method in our controller: display(). Most of the required functionality is built into the JController class, so all that we need to do is invoke the JController::display() method.

The code for the base controller site/controller.php is:
<source lang="php"><?php
/**
* @package Joomla.Tutorials
* @subpackage Components
* @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
* @license GNU/GPL
*/

// No direct access

defined( '_JEXEC' ) or die( 'Restricted access' );

jimport('joomla.application.component.controller');

/**
* Hello World Component Controller
*
* @package Joomla.Tutorials
* @subpackage Components
*/
class HelloController extends JController
{
/**
* Method to display the view
*
* @access public
*/
function display()
{
parent::display();
}

}</source>

The JController constructor will always register a display() task and unless otherwise specified (using the registerDefaultTask() method), it will set it as the default task.

This barebones display() method isn't really even necessary since all it does is invoke the parent constructor. However, it is a good visual clue to indicate what is happening in the controller.

The JController::display() method will determine the name of the view and layout from the request and load that view and set the layout. When you create a menu item for your component, the menu manager will allow the administrator to select the view that they would like the menu link to display and to specify the layout. A view usually refers to a view of a certain set of data (i.e. a list of cars, a list of events, a single car, a single event). A layout is a way that that view is organized.

In our component, we will have a single view called hello, and a single layout (default).

=== Creating the View ===
The task of the view is very simple: It retrieves the data to be displayed and pushes it into the template. Data is pushed into the template using the JView::assignRef method.
<small>(Note: The key (the first argument) passed to the assignRef method cannot be preceded by an underscore i.e. $this->assignRef('_greeting',$greeting). Doing so will cause the assignRef method to return false and your variable will not be pushed into the template.)</small>

The code for the view at site/views/hello/view.html.php:

<source lang="php"><?php
/**
* @package Joomla.Tutorials
* @subpackage Components
* @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
* @license GNU/GPL
*/

// no direct access

defined( '_JEXEC' ) or die( 'Restricted access' );

jimport( 'joomla.application.component.view');

/**
* HTML View class for the HelloWorld Component
*
* @package HelloWorld
*/

class HelloViewHello extends JView
{
function display($tpl = null)
{
$greeting = "Hello World!";
$this->assignRef( 'greeting', $greeting );

parent::display($tpl);
}
}</source>

==== Creating the Template ====

Joomla! templates/layouts are regular PHP files that are used to layout the data from the view in a particular manner. The variables assigned by the JView::assignRef method can be accessed from the template using $this->{propertyname} (see the template code below for an example).

Our template is very simple: we only want to display the greeting that was passed in from the view - this file is:<br>site/views/hello/tmpl/default.php:

<source lang="php"><?php

// No direct access

defined('_JEXEC') or die('Restricted access'); ?>
<h1><?php echo $this->greeting; ?></h1></source>

=== Wrapping It All Up - Creating the hello.xml File ===
It is possible to install a component manually by copying the files using an FTP client and modifying the database tables. It is more efficient to create a package file that will allow the Joomla! Installer to do this for you. This package file contains a variety of information:

* basic descriptive details about your component (i.e. name), and optionally, a description, copyright and license information.
* a list of files that need to be copied.
* optionally, a PHP file that performs additional install and uninstall operations.
* optionally, an SQL file which contains database queries that should be executed upon install/uninstall

The format of the XML file at hello.xml is as follows:

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<install type="component" version="1.5.0">
<name>Hello</name>

<creationDate>2007-02-22</creationDate>
<author>John Doe</author>
<authorEmail>john.doe@example.org</authorEmail>
<authorUrl>http://www.example.org</authorUrl>
<copyright>Copyright Info</copyright>
<license>License Info</license>

<version>1.01</version>

<description>Description of the component ...</description>



<files folder="site">
<filename>controller.php</filename>
<filename>hello.php</filename>
<filename>index.html</filename>
<filename>views/index.html</filename>
<filename>views/hello/index.html</filename>
<filename>views/hello/view.html.php</filename>
<filename>views/hello/tmpl/default.php</filename>
<filename>views/hello/tmpl/index.html</filename>
</files>

<administration>

<menu>Hello World!</menu>


<files folder="admin">
<filename>hello.php</filename>
<filename>index.html</filename>
</files>

</administration>
</install></source>

{{notice|
Put this xml file, also called manifest, in the root of your package (because the installer will take its path as the root path for all other files).{{1}}Don't include itself under <files>...}}

You may have noticed the manifest source above mentioned files we have not discussed. These are the index.html files and the admin files. An index.html file is placed in each directory to prevent prying users from getting a directory listing. If there is no index.html file, some web servers will list the directory contents. This is often undesirable. These files have the simple line:

<source lang="php"><html><body bgcolor="#FFFFFF"></body></html></source>

It will simply display a blank page.

The hello.php file in the admin folder is the entry point for the our component's admin section. Since our component has no administrator needs (yet), this file will have the same content as the index.html files for now.

If you've followed along, you can visit URL index.php?option=com_hello to see your work. To do this, zip up the main folder and install via the extensions manager. If it still does not work, download the package at the bottom of this page and install for a working example.

== Contributors ==
* mjaz
* staalanden
* dannystaple
* Stilgar
* presto

== Download ==
The component can be downloaded at: [http://joomlacode.org/gf/download/frsrelease/8108/29433/com_hello1_01.zip com_hello1_01]

[[Category:Tutorials]]
[[Category:Component Development]]

Accessing the database using JDatabase

2012-07-20T14:53:41Z

Ian:

Retrieving request data using JInput

2012-07-15T01:24:08Z

Ian: /* Getting Multiple Values */

Retrieving request data using JInput

2012-07-15T01:22:40Z

Ian: /* Setting values */

Retrieving request data using JInput

2012-07-15T00:43:09Z

Ian: /* Getting values */

{{JVer|11.1}} {{JVer|1.7}}

==Requirements==
To be able to use JInput as described here, you must be using Joomla 1.7.1 or above.

==Starting JInput==
To use JInput you must first create the object by using this code:

<source lang="php">$jinput = JFactory::getApplication()->input;</source>

===Getting values===
To get a value from JInput you can use:

<source lang="php">$foo = $jinput->get('varname', 'default_value', 'filter');</source>

The filter defaults to cmd

Available filters are:

*INT
*INTEGER
*UINT
*FLOAT
*DOUBLE
*BOOL
*BOOLEAN
*WORD
*ALNUM
*CMD
*BASE64
*STRING
*HTML
*ARRAY
*PATH
*USERNAME

===Getting Multiple Values===

To retrieve a number of values you can use the getArray() method like:

<source lang="php">
$fooarray = array();
$fooarray[] = 'var1';
$fooarray[] = 'var2';
$fooarray[] = 'var3';
$foovalues = $jinput->getArray($fooarray);</source>

The $foovalues will be an array that consists of the same keys as used in $fooarray.

You can also get specify a more complex hierarchy of values to retrieve:

<source lang="php>
$fooValues = $jinput->getArray(
'var1' => 'int',
'var2' => 'float',
'var3' => 'word'
);
</source>

You can also nest arrays to get more complicated hierarchies of values:

<source lang="php">
$fooValues = $jinput->getArray(
'jform' => array(
'title' => 'string',
'quantity' => 'int',
'state' => 'int'
)
);
</source>

===Getting Values from a Specific Super Global===

<source lang="php">$foo = $jinput->get->get('varname', 'default_value', 'filter');</source>
<source lang="php">$foo = $jinput->post->get('varname', 'default_value', 'filter');</source>
<source lang="php">$foo = $jinput->server->get('varname', 'default_value', 'filter');</source>

To retrieve an object you can use:
<source lang="php">$foo = $jinput->get('varname', null, null);</source>

===Setting values===
To set a value via JInput you can use:

<source lang="php">$jinput->set('varname', $foo);</source>

This is based on an email discussion: [https://groups.google.com/d/msg/joomla-dev-framework/LbALkK1ifMo/5waSiIlb21gJ Framework List 23 July 2011]

The idea behind JInput is to abstract out the input source to allow code to be reused in different applications and in different contexts. What I mean by this is that you could have a controller that grabs data from an input source. Instead of always getting it from the request (i.e. get and post variables), you get it from JInput. So say for instance you have a MVC triad in your component that is meant to get data from the browser as a client (a typical web application). Now suppose you want to reuse that same code but interface with it using JSON. Instead of rewriting your triad, you just extend JInput and have it grab it data from a parsed json object and perform any translation that you need to perform.

The plan is to have JApplication instantiate JInput in its constructor. Then in your code you get the input object from the application and get your input from there. It will be a public property in Japplication so that it can be swapped out of that is appropriate.

We get the added benefit that we get rid of the static JRequest which makes a whole bunch the code a whole lot easier to test because you can inject mock inputs directly instead of trying to fudge with hackish dependencies.

The end result will be that your code will get the input object from the application (we will probably add something to JController at some point to make it more convenient to use there as well).

Once you have your JInput object, you use it fairly in a fairly similar manner to how JRequest is used:
$input->get('varname', 'default_value', 'filter');

Where filter is a filter that is supported by JFilterInput. JInput::clean proxies to JFilter. We'll have to tweak JFilter a little bit so that it is more extensible. It defaults to cmd so that developers have to be intentional about things if they want to have more lenient filtering.

There is also a getArray method that allows you to specify an array of key and filter pairs so that you can get a whole array of filtered input.

If you want to get data from a specific super global array, you can do $input->get->get(...) or $input->post->get(...).

So that's the basic idea. Feel free to post more questions if you have any.

We'll be adding input as a public property to JApplication in the near future. It might be an idea if the CMS folks so chose to release a 1.7.1 that included this so developers can use it now. Otherwise, at this point in time, it is best to still use JRequest.

[[Category:Development]]

Archived:Vulnerable Extensions List

2011-02-24T14:10:25Z

Ian:

{{RightTOC}}
'''List prior to January 2010 ([[Archived vel|now archived]])''' Please check here also.

Please also check the [[Investigation of exploits|Extension Investigation List]].

== Check and Report. ==
'''Please check with the extension publisher in case of any questions over the security of their product.'''
Report Vulnerable extensions either in the [[jforum:432|security forum]] or the [[jforum:470|extensions forum]] clearly marked with the first word in the title being ''Vulnerable'' where the security moderators or JSST team will respond.
This list is change protected,''' for additions or updates email''' ''vel @ joomla.org'' [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 Mandville] or [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=87230 lafrance] are the main editors
*If you are seeing this page on any site other than [http://docs.joomla.org/Vulnerable_Extensions_List the Offical Joomla Documentation] you may be seeing an out of date version or experiencing [http://en.wikipedia.org/wiki/Plagiarism plagiary] and the links may not work properly

== How to use this list ==
'''Items will be removed after a suitable period and not on resolution'''
All known vulnerable extensions are the listed in the first column. Any in <span style="background:red; color:white">a red box </span>are high where we have not been given a fix for. Alert Advisory details in the centre column .
The link to the advisory notice.
Finally a link to the notice about any <span style="background:#cef2e0; color:black">update with link</span> or <span style="background:red; color:white">'''Not Known''' </span> where none is known.

'''This list is compiled from found information and may not be an up to date accurate list''' ''We do '''NOT''' promise to test or validate these reports. We do '''NOT''' guarantee the quality or effectiveness of any updates reported to us or listed here.''
To sign up for the feed please [http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions follow this link]
* We do not list BETA products, or extensions for J1.0.x

== Developers - How to get yourself removed from the VEL ==

Resolved items will be removed after a suitable period and not on resolution

Please solve the issues and:

* '''If JED listed'''

To have your extension republished, please follow these steps:

1- Solve the issues.

2- Attach the new zip file at your actual JED listing.

3- Change the extension version at JED listing.

4- Make sure to include a notice in the JED description to the fact that the new release is a "Security Release" and those who use the extension should upgrade immediately.

5- Email to the JED with a notice and ask that your listing be republished.

6- Email the VEL team with a notice of resolution, and a link to the security release statement on your website

VEL email can be found above and the JED email is in your notice of "unpublication"

* '''If not JED listed.'''
Inform us by '''email''' of the link to your resolution notice on your website.

== New format Feed Starts Here ==
Please do not change your [http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions feed url], only the feed format has changed.
'''Please check with the extension publisher in case of any questions over the security of their product.'''
Report Vulnerable extensions either in the [[jforum:432]] security topic or the [http://forum.joomla.org/viewforum.php?f=470 extensions] topic clearly marked with the first word in the title being ''Vulnerable'' where the security moderators or JSST team will respond.
''This list is change protected, for updates or editing requests [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 Mandville] or [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=87230 lafrance]
''

[http://docs.joomla.org/Vulnerable_Extensions_List Back To Top]

== February 2010 and onwards Reported Vulnerable Extensions ==
<startFeed />

'''Please check with the extension publisher in case of any questions over the security of their product.'''
Report Vulnerable extensions either in the [[jforum:432]] security topic clearly marked with the first word in the title being ''Vulnerable Report'' where the security moderators or JSST team will respond. For a guide to the [http://docs.joomla.org/Vulnerable_Extensions_List_0210#Codes_used codes]

[http://docs.joomla.org/Vulnerable_Extensions_List Previous Reports]

{| class="wikitable sortable" border="1"
|-
! '''Extension'''
! class="unsortable"| '''Details'''
! '''Date Added'''
! class="unsortable" |'''Extension Update Link & Date'''
|-
|style="background:red; color:white" |

== smartformer ==
|RFI
|230211 (repeat of 041110)
|
|-
|style="background:red; color:white" |

== xmap 1.2.10 ==
|Malicious payload in zip
|230211
|
|-
|

== Frontend-User-Access 3.4.1 ==
|Frontend-User-Access 3.4.1 from http://www.pages-and-items.com LFI
|030211
|update to [http://extensions.joomla.org/extensions/access-a-security/frontend-access-control/6874 Frontend-User-Access 3.4.2]
|-
|style="background:red; color:white" |
== com properties 7134 ==
| http://com-property.com/ malicious files in script
|
|

|-
|style="background:red; color:white" |

== B2 Portfolio ==
|B2 portfolio 1.0 SQLi pulseextensions.com
|250111
|
|-
|style="background:#cef2e0; color:black" |

== allcinevid ==
|SQLI http://extensions.joomla.org/extensions/multimedia/multimedia-players/video-players-a-gallery/15367
|220111
|[http://www.joomtraders.com/our-blog/allcinevid-1.0-sql-injection.html Developers resolution notice]
|-
|style="background:red; color:white" |

== People Component ==
|People component http://www.ptt-solution.com/vmchk/people-component.html sqli
|150111
|
|-
|style="background:#cef2e0; color:black" |

== J!Dump v1.1.2 ==
| LFI in J!Dump v1.1.2 and before
|060111
|The extension is fixed in
[http://joomlacode.org/gf/project/jdump/frs version 1.1.3] 070111
|-
|style="background:#cef2e0; color:black" |

== xmovie 1.0 ==
|xmovie 1.0 LFi
|010111
|[http://www.optikool.com/news/xmovie-news/45-xmovie-11-udpate v1.1 is a security release.]
|-
|style="background:#cef2e0; color:black" |

== Easy File Uploader ==
|LFI - http://extensions.joomla.org/extensions/core-enhancements/file-management/11909
|090111
| Fixed MIME type tamper vulnerability http://michaelgilkes.info/joomla-plugin-easy-file-uploader 2011-01-10
|-
|style="background:#cef2e0; color:black" |

== akeebabackup admin tools ==
|xss
|181210
|http://www.akeebabackup.com/home/item/929-security-release-admin-tools-1-1.html devs update statement
|-

|-
|style="background:#cef2e0; color:black" |

== aicontactsafe ==
|XSS for versions 2.0.13 and below
|161210
|[http://www.algisinfo.com/joomla/aicontactsafe-change-log.html dev release 2.0.14]
|-
|style="background:#cef2e0; color:black" |

== JRadio ==
|JRadio LFI/SID
|161210
|http://www.fxwebdesign.nl/index.php?option=com_content&view=article&id=20&Itemid=56 developer fix statement
|-
|style="background:#cef2e0; color:black" |

== JE Auto ==
|JE Auto 1.0 SQL I
|091210
|[http://www.joomlaextensions.co.in/extensions/components/je-auto.html developers bug fix statement]
|-
|

== jxtended comments ==
|xss
|081210
|[http://jxtended.com/blog/releases/375-jxtended-comments-131-stable-released.html dev notice] update to 1.3.1
|-
|style="background:#cef2e0; color:black" |

== sh404SEF ==
|sqlI
|301110
|[http://dev.anything-digital.com/Blog/sh404SEF/Urgent-security-releases-now-available-for-all-version-of-sh404SEF.html dev post of resolution]
|-
|style="background:#cef2e0; color:black" |

== JE Ajax Event Calendar ==
|SQL I (relist)
|251110
|[http://joomlaextensions.co.in/extensions/components/je-ajax-event-calender.html Dev states resolved,]
|-
|style="background:red; color:white" |

== Jimtawl ==
|Jimtawl LFI
|251110
|
|-
|style="background:#cef2e0; color:black" |

== mosets tree ==
|mosets tree various
|181110
|dev release 2.1.8 http://forum.mosets.com/showthread.php?t=17064
|-
|style="background:red; color:white" |

== Maian Media SILVER ==
|Maian Media SQLi
|151110
|Developer states unproven in free edition, paid/SILVER version is being upgraded. [http://www.aretimes.com/index.php?option=com_content&view=category&layout=blog&id=40&Itemid=113 dev article]
|-
|style="background:red; color:white" |

== alfurqan ==
|alfurqan 1.5 sqli
|151110
|
|-
|style="background:red; color:white" |

== ccboard ==
|[http://extensions.joomla.org/extensions/communication/forum/6823 ccboard XSS and SQLi]
|131110
|

|-
|style="background:red; color:white" |

== ProDesk v 1.5 ==
|LFI
|091110
|
|-
|style="background:#cef2e0; color:black" |

== JQuarks 4 survey 1.0.0 ==
|SQLi
|091110
| [http://www.iptechinside.com/labs/projects/list_files/jquarks-for-surveys developer statement updated to version 1.0.1] 101110
|-
|style="background:#cef2e0; color:black" |

== RSform! 1.0.5 ==
|Multiple vulnerabilities - LFI, SQLi
|061110
| [http://www.rsjoomla.com/customer-support/documentations/12-general-overview-of-the-component/46-rsform-changelog.html developer announcement of security release]to 1.0.6 091110
|-
|style="background:#cef2e0; color:black" |

== ccinvoices ==
|SQLi for [http://www.chillcreations.com/ ccinvoices]
|051110
|Developer Upgrade release to ccInvoices_110RC3 061110
|-
|style="background:red; color:white" |

== sponsorwall ==
|SQL injection pulseextensions.com
|011110
|
|-
|style="background:red; color:white" |

== Flip wall ==
|SQL injection pulseextensions.com
|011110
|
|-
|style="background:#cef2e0; color:black" |

== K2 joomlaworks ==
| http://getk2.org/ k2 xss
|
|[http://getk2.org/ version 2.4.1]
|-
|style="background:#cef2e0; color:black" |

== Mosets Tree 2.1.5 ==
|Mosets Tree http://www.mosets.com/tree/ 2.1.5 LFI
|
|[http://forum.mosets.com/forumdisplay.php?f=2 developer relase statement and change log]
|-
|style="background:red; color:white" |

== Freestyle FAQ 1.5.6 ==
|http://freestyle-joomla.com/fssdownloads/viewcategory/2 Freestyle FAQ 1.5.6 ‎SQL Injection
|
|
|-
|style="background:#cef2e0; color:black"|

== JE FAQ Pro ==
|[http://www.jextn.com/ Je faq pro] various reports
|090910
|[http://www.jextn.com/joomla-faq-component-extensions-downloads Developer update notice]
|-
|style="background:red; color:white" |

== iJoomla Magazine 3.0.1 ==
|iJoomla Magazine 3.0.1 RFI
|090910
|
|-
|style="background:red; color:white" |

== Clantools ==
|
|http://www.joomla-clantools.de/downloads/doc_download/7-clantools-123.html clantool sqli
|090910
|
|-
|style="background:red; color:white" |

== jphone ==
|jphone LFI
|090910
|
|-
|style="background:#cef2e0; color:black"|

== Gantry Framework ==
|SQli injection
|050910
|[http://www.gantry-framework.org/news Update to 3.0.11]
|-
|style="background:red; color:white" |

== PicSell ==
|[http://vm.xmlswf.com/index.php?option=com_content&view=article&id=104&Itemid=131Picsell LFD, 777]
|020910
|
|-
|style="background:#cef2e0; color:black"|

== JE FAQ Pro ==
|[http://www.jextn.com/joomla-faq-component-extensions-downloads/ SID]
|020910
|[http://www.jextn.com/joomla-faq-component-extensions-downloads Developer update notice]
|-
|style="background:red; color:white" |

== Zoom Portfolio ==
|SID
|020910
|
|-
|style="background:red; color:white" |

== zina ==
|[http://www.pancake.org/zina/ SQL Injection]
|020910
|
|-
|style="background:red; color:white" |

== Team's ==
|[http://www.joomlamo.com Teams extension] SQL Injection
|120810
|
|-
|style="background:red; color:white" |

== Amblog ==
|[http://robitbt.hu/jm/index.php?option=com_amdownloader&task=showfiles&pathid=8 Amblog] SQLi
|120810
|
|-
|style="background:red; color:white" |

== ==
|
|
|
|-
|style="background:#cef2e0; color:black"|

== Graffiti Wall ==
|[http://extensions.joomla.org/extensions/extension-specific/jomsocial-extensions/13263 Graffiti Wall] for [http://www.joomplace.com/forum/jomsocial-plugins/jomsocial-plugins/graffiti-wall-permissions-777.html jomsocial silent 777]
|310710
|[http://extensions.joomla.org/extensions/extension-specific/jomsocial-extensions/13263 Dev statement 1.1 - is security release]. Folder permission was set by default as 777 that is unsecure.
|-
|style="background:#cef2e0; color:black"|

== Spielothek ==
|http://extensions.joomla.org/extensions/sports-a-games/games/11017 http://www.spielban.de/ silent 0777, unknown folder creation
|290710
|Dev states version 1.7.1 resolves issues 020810
|-
|style="background:#cef2e0; color:black"|

== Aardvertiser ==
|http://extensions.joomla.org/extensions/ads-a-affiliates/classified-ads/9454 silent 0777
|290710
|[http://sourceforge.net/projects/aardvertiser/forums/forum/989030/topic/3788365 dev announces silent 0777 fixed in Version 2.1 290710]
|-
|style="background:#cef2e0; color:black"|

== FW Real Estate Light ==
|http://extensions.joomla.org/extensions/vertical-markets/real-estate/13376 http://www.fastw3b.net/fw-real-estate-light.html silent 777
|290710
|[http://www.fastw3b.net/fw-real-estate-light.html version 1.1 reported as fixed 777 issue]
|-
|

== ==
|
|
|
|-
|style="background:#cef2e0; color:black"|

== jDownloads ==
|http://www.jdownloads.com/ and http://extensions.joomla.org/extensions/directory-a-documentation/downloads/2849 silent 0777 setting
|2807110
|1.7.4 RC3 Build 771 update on Jul 29 to remove 0777
|-
|style="background:#cef2e0; color:black"|

== TTVideo ==
|[http://www.toughtomato.com TTVideo 1.0 Joomla] SQL Injection Vulnerability
|270710
|[http://www.toughtomato.com/resources/downloads/joomla-1.5/components/ttvideo/ dev updated the component to prevent this]. 280710
Users are no longer able to download the previous version.
|-
|style="background:#cef2e0; color:black"|

== frei-chat2.0 ==
|http://code.google.com/p/frei-chat/downloads/list xss vulnerability
|230710
|[http://code.google.com/p/frei-chat/downloads/list Dev announcement to fix] 2.1.2 for FreiChat [Those having CB installed]AND 1.2.2 for FreiChatPure [Extension Independent] 240710

|-
|style="background:#cef2e0; color:black"|

== QContacts ==
|http://extensions.joomla.org/extensions/contacts-and-feedback/contact-details/4811 '''Version: 1.0.4 reported, current version 1.0.6'''
|220710
|Devleoper states [http://www.latenight-coding.com/news/joomla/supposed-vulnerability-qcontacts-104.html unproven report and no POC]
|-
|style="background:red; color:white" |

== Jomtube ==
|http://www.jomtube.com/ SID
|220710
|
|-
|style="background:#cef2e0; color:black"|

== mysms ==
|http://www.willcodejoomlaforfood.de/ Upload Vulnerability
|july 10,2010
|290710 [http://www.willcodejoomlaforfood.de/ released the version 1.5.12.]
|-
|style="background:red; color:white" |

== Rapid Recipe ==
|http://www.rapid-source.com Persistent XSS Vulnerability last known fix version 1.7.2
|july 10,2010
|
|-
|style="background:red; color:white" |

== Health & Fitness Stats ==
|http://joomla-extensions.instantiate.co.uk/jcomponents/healthstats Persistent XSS Vulnerability july 10,2010
|
|
|-
|style="background:red; color:white" |

== staticxt ==
|http://extensions.joomla.org/extensions/edition/custom-code-in-content/2184 no version number provided
|
|
|-
|style="background:#cef2e0; color:black"|
== EasyBlog ==
|http://stackideas.com/products/easyblog.html xss (new report) july 10,2010
|
|[http://extensions.joomla.org/extensions/news-production/blog/12630 developer reported fix available on site ]
|-
|style="background:#cef2e0; color:black"|

== redshop light ==
|http://redcomponent.com/redshop http://extensions.joomla.org/extensions/e-commerce/shopping-cart/13184 silent 777 and sqli
|110710
|[http://redcomponent.com/forum/72-redshop-light/11261-redshop-light-rc2-released-security-release Developer reported fix and upgrade to RC2]
|-
|style="background:red; color:white" |

== quickfaq ==
|http://www.schlu.net sqli
|090710
|
|-
|style="background:red; color:white" |

== Minify4Joomla ==
|http://waltercedric.com/ LFI and xss
|090710
|No longer available to download
|-
|style="background:red; color:white" |

== IXXO Cart ==
|http://www.php-shop-system.com/ SQLi LFI XSS Vulnerability
|
|
|-
|style="background:#cef2e0; color:black"|

== Music Manager ==
|LFI [http://danieljamesscott.org/software/4-joomla-extensions/4-music-manager.html music manager]
|090710
|[http://danieljamesscott.org/software/4-joomla-extensions/4-music-manager.html Version 0.13 released]
|-
|style="background:red; color:white" |

== PaymentsPlus ==
|http://paymentsplus.com.au/ 2.1.5 Blind SQL Injection Vulnerability
|090710
|current version 2.20, 2.1.5 not listed on dev site
|-
|style="background:red; color:white" |

== ArtForms ==
|http://joomlacode.org/gf/project/jartforms/ ArtForms 2.1b7.2 RC2 Multiple Remote Vulnerabilities
|090710
| Old beta extension
|-
|style="background:#cef2e0; color:black"|

== NeoRecruit ==
|neojoomla.com SQL Injection
| neorecruit vers 1.4 060710
|[http://www.neojoomla.com/index.php?lang=en dev statement of fix in 1.4.1 and safe 2.0.5]
|-
|style="background:red; color:white" |

== autartimonial ==
|autartica.be Sqli Vulnerability
|060710
|
|-
|style="background:#cef2e0; color:black"|

== Jobs Pro ==
|instantphp.com/ Sqli
|060710
|[http://www.instantphp.com/news/40-new-releases/153-jobs-133-is-published.html devs] announcement of fix 130710
|-
|

== JPodium ==
|http://www.jpodium.de/ SQL Injection
|060710
|[http://www.jpodium.de/index.php?option=com_content&view=article&id=135:jpodium-not-vulnerable-to-sql-injection&catid=2:newsrotator Devs statement as to not proven]
|-
|style="background:red; color:white" |

== Front-End Article Manager System ==
|http://b-elektro.no/ Upload Vulnerability
|040710
|
|-
|style="background:red; color:white" |

== addressbook ==
|http://b-elektro.no/ Upload Vulnerability
|040710
|
|-
|

== NijnaMonials ==
|http://ninjaforge.com/ Sqli Vulnerability
|040710
|070410 Discovered to be malicious/false report see [http://nekkidninjas.com/index.php/2010/07/05/there-is-no-sql-injection-vulnerability- devs notice]
|-
|style="background:#cef2e0; color:black"|

== Phoca Gallery ==
|SQL I (wrong download location in report)
|040710
|style="background:#cef2e0; color:black"| deemed malicious report
|-
|style="background:#cef2e0; color:black"|

== socialads ==
|techjoomla.com/ Xss Vulnerability
|040710
|[http://techjoomla.com/joomla-extension-news/socialads-v101-security-update-to-fix-xss-vulnerability-out.html Developers resolved statement]
|-
|style="background:red; color:white" |

== eventcal 1.6.4 ==
|http://joomlacode.org/gf/project/eventcal/frs/ SQL I last update 2006-12-31 on joomlacode
|040710
|
|-
|style="background:#cef2e0; color:black"|

== myblog controller ==
|LFI
http://www.azrul.com/
|010710
|[http://www.azrul.com/ MyBlog 3.0.332]
|-
|style="background:red; color:white" |

== joomanager ==
|SQli Vulnerability
http://www.joomanager.com
|010710
|
|-
|style="background:#cef2e0; color:black"|

== gamesbox ==
|SQL Injection Vulnerability
http://www.jooforge.com/en/download/commercial/extensions/39-gamesbox
|010710
|upgrade to 1.0.10
|-
|style="background:red; color:white" |

== wmtpic ==
|www.webmaster-tips.net various
|010710
|
|-
|style="background:red; color:white" |

== date converter ==
|http://sourceforge.net/projects/date-converter/ sqli
|010710
|
|-
|

== Remository ==
|http://remository.com/ LFI (proc)
|010710
|Developer states not proven and possibly malicious. Unable to reproduce without proc/environ security. 260710
|-
|style="background:#cef2e0; color:black"|

== RokBridge 1.0rc12 ==
|http://extensions.joomla.org/extensions/communication/forum-bridges/9012 SDI
|090810
|[http://www.rockettheme.com/extensions-updates/834-rokbridge-10rc13-released RokBridge has been updated to version 1.0rc13.] 120810
|-
|style="background:red; color:white" |

== real estate ==
|http://www.opensourcetechnologies.com/demos/real-estate.html RFI
|210610
|
|-
|style="background:#cef2e0; color:black"|

== jomsocial ==
|Version: 1.6.288 Multiple XSS
|210610
|[http://www.jomsocial.com/blog/security-patch-for-jomsocial-16x.html 1.6.291 released] 220610

|-
|style="background:#cef2e0; color:black"|

== DOCman ==
|DOCman 1.5.7 DOCman 1.4.0 none specific exploit
|210610
|[http://blog.joomlatools.eu/2010/06/docman-security-announcement.html developer announcement]
|-
|style="background:#cef2e0; color:black"|

== eportfolio ==
|http://www.joomplace.com/e-portfolio/e-portfolio-description.html Upload Vulnerability
|200610
|Developer [http://www.joomplace.com/e-portfolio/e-portfolio-description.html announcement ] 270810

|-
|style="background:red; color:white" |

== cinema ==
|SQL injection
|190610
|
|-
|style="background:red; color:white" |

== Jreservation ==
|http://jforjoomla.com/ SQLi Vulnerability
|190610
|
|-
|style="background:#cef2e0; color:black"|

== Super Messenger ==
|axxis.gr xss
|190610
|[http://axxis.gr/forum/viewtopic.php?f=6&t=641 developer release statement 1.4.6]
|-
|style="background:red; color:white" |

== joomdocs ==
|http://joomclan.com/index.php/JoomDocs/ xss vulnerability
|190610
|
|-
|style="background:#cef2e0; color:black"|

== RSComments 1.0.0 ==
|Persistent XSS NOTE: ONLY executes in backend!
|190610
|[http://www.rsjoomla.com/customer-support/documentations/96--general-overview-of-the-component/393-changelog.html Developer update announcement] 210610
|-
|style="background:red; color:white" |

== Live Chat ==
|http://www.joompolitan.com/livechat.html Multiple Remote Vulnerabilities
|190610
|
|-
|style="background:red; color:white" |

== Turtushout 0.11 ==
| http://www.turtus.org.ua/files?func=fileinfo&id=13 SQL Injection (again)
|190610
|
|-
|style="background:red; color:white" |

== BF Survey Pro Free ==
|BF Survey Pro Free SQL Injection Exploit
|190610
|
|-
|style="background:red; color:white" |

== MisterEstate ==
|http://www.misterestate.com/ Blind SQL Injection Exploit
|190610
|
|-
|style="background:red; color:white" |

== RSMonials ==
|http://www.rswebsols.com/downloads/category/14-download-rsmonials-all?download=23%3Adownload-rsmonials-component XSS Exploit
|190610
|Believed to be 1.5.1 version

|-
|style="background:#cef2e0; color:black"|

== RSComments 1.0.0 ==
|RS Comments 1.0.0 Multiple XSS Vulnerabilities http://www.rsjoomla.com (relisted)
|180610
|[http://www.rsjoomla.com/customer-support/documentations/96--general-overview-of-the-component/393-changelog.html Developer update announcement] 210610
|-
|style="background:red; color:white" |

== Answers v2.3beta ==
|Multiple Vulnerabilities http://extensions.joomla.org/extensions/communication/forum/12652
|180610
|
|-
|style="background:red; color:white" |

== Gallery XML 1.1 ==
|Multiple Vulnerabilities
http://extensions.joomla.org/extensions/photos-a-images/photo-gallery/12504
|180610
|
|-
|style="background:red; color:white" |

== JFaq 1.2 ==
|JFaq 1.2 Multiple Vulnerabilities
|180610
|
|-
|style="background:red; color:white" |

== Listbingo 1.3 ==
|Multiple Vulnerabilities
http://extensions.joomla.org/extensions/ads-a-affiliates/classified-ads/12062
|180610
|
|-
|style="background:#cef2e0; color:black"|

== PowerMail Pro ==
| PowerMail Pro Local File Inclusion Vulnerability
|
|[http://powermail4joomla.com/forum/showthread.php?tid=163 Dev upadte statement] 151010
|-
|style="background:red; color:white" |

== Alpha User Points ==
|www.alphaplug.com LFI
|180610
|
|-
|style="background:#cef2e0; color:black"|

== Magic Updater ==
|http://software.realtyna.com/ RFI
|170610
|[http://software.realtyna.com/component/content/article/64-security-patch-for-magic-updater-and-translator.html] developer update statement
|-
|style="background:red; color:white" |

== recruitmentmanager ==
|http://recruitment.focusdev.co.uk Upload Vulnerability
|130610
|
|-
|style="background:red; color:white" |

== Info Line (MT_ILine) ==
|http://extensions.joomla.org/extensions/news-display/news-tickers-a-scrollers/8425 reports of shell scripts in download file
|120610
|
|-
|style="background:#cef2e0; color:black"|

== Search Log ==
|http://www.kanich.net/radio/site/searchlog/searchlog-download SQLi
|080610
|[http://www.kanich.net/radio/site/searchlog/searchlog-download Developer cited update to version 3.1.1 100710]

|-
|

== iJoobi ==
|jtickets, jsubscription SQL Injection Vulnerability,
jstore SQL Injection Vulnerability, jnewsletter SQL Injection, jmarket SQL Injection Vulnerability, jcommunity SQL Injection, jsubscription SQL Injection,
|090610
|developer states unproven

|-
|style="background:red; color:white" |

== Ads manager Annonce ==
|http://joomla.clubnautiquemarine.fr/
Upload Vulnerability
| 05/06/10
|
|-
|style="background:red; color:white" |

== lead article ==
|http://www.leadya.co.il/ SQLi
|050610
|
|-
|style="background:red; color:white" |

== djartgallery ==
|http://www.design-joomla.eu Multiple Vul
|05/06/10
|
|-
|style="background:red; color:white" |

== Gallery 2 Bridge ==
|[http://trac.4theweb.nl/g2bridge g2bridge] LFI vulnerability
|

|-
|style="background:red; color:white" |

== jsjobs ==
|[http://www.joomsky.com jsjobs] SQL Injection Vulnerability
|
|
|-
|

== ==
|
|
|
|-
|style="background:red; color:white" |

== JE Poll ==
|http://slideshow.joomlaextensions.co.in/ SQL Injection Vulnerability
|
|
|-
|style="background:#cef2e0; color:black"|

== MyCar ==
|http://www.unisoft.me/extensions/ sqli ID
|
|[http://www.unisoft.me/mycar/index.php?option=com_smallchat&Itemid=5 Dev announcement update to 1.1]
|-
|style="background:red; color:white" |

== MediQnA ==
|MediQnA LFI vulnerability version : v1.1
|
|
|-
|style="background:red; color:white" |

== JE Job ==
|http://joomlaextensions.co.in/ LFI SQLi
|
|
|-
|style="background:#cef2e0; color:black"|

== BF Quiz ==
|SQL Injection Exploit Version(s) = 1.3.0
|
|[http://www.tamlyncreative.com.au/software/forum/index.php?topic=729.0 Developer update to BF Quiz v1.3.1]
|-
|

== ==
|
|
|
|-
|style="background:#cef2e0; color:black"|

== Ozio Gallery 2 ==
|DT and open email relay
|280510
|[http://oziogallery.joomla.it/index.php?option=com_content&view=article&id=65:rilasciata-la-versione-ozio-gallery-25&catid=2:notizie&Itemid=13&lang=en Developer update and security release] 010610
|-
|style="background:red; color:white" |

== SectionEx ==
|Stack Ideas section Ex LFI
|
|
|-
|style="background:red; color:white" |

== ActiveHelper LiveHelp ==
|XSS in [http://extensions.joomla.org/extensions/communication/chat/12492 LiveHelp]
|200510
|
|-
|style="background:#cef2e0; color:black"|
== RS Comments ==
|XSS Vulnerability
|
|[http://www.rsjoomla.com/customer-support/documentations/96--general-overview-of-the-component/393-changelog.html - fix posted 210510]
|-
|

== BCA RSS Feed ==
|LFI and other vulnerabilities
|
|Upgrade to [http://ninjaforge.com/index.php?option=com_ninjacentral&page=show_package&id=74&Itemid=236 Ninja RSS Syndicator 1.0.9 or later]
|-
|

== SimpleDownload ==
|http://extensions.joomla.org/extensions/directory-a-documentation/downloads/10717 various exploits
|160510
|updated version (version 0.9.6)
|-
|style="background:red; color:white" |
== JE Quotation Form ==
|http://joomlaextensions.co.in/free-download/doc_download/11-je-quotation-form.html LFI
|
|
|-
|style="background:red; color:white" |

== konsultasi ==
|SQL Injection Vulnerability
|
|
|-
|style="background:#cef2e0; color:black"|

== Aardvertiser ==
|Local File Inclusion Vulnerability
http://extensions.joomla.org/extensions/ads-a-affiliates/classified-ads/9454
|
|see [http://docs.joomla.org/Vulnerable_Extensions_List#Aardvertiser resolved notice 040810]
|-
|style="background:red; color:white" |

== Seber Cart ==
|Local File Disclosure Vulnerability
|
|[http://www.sebercart.com/index.php?option=com_content&view=article&id=158 Developer Update 140510]
|-
| style="background:#cef2e0; color:black"|

== FDione Form Wizard ==
|lfi vulnerability
|140510 200510
|[http://dionesoft.com Update to Dione Form Wizard (v. 1.0.4)].
|-
| style="background:#cef2e0; color:black"|

== Custom PHP Pages ==
|http://extensions.joomla.org/extensions/edition/custom-code-in-content/5057 LFI Vulnerability
|
|[http://fijiwebdesign.com Developer declares not vulnerable 140510]
|-
|style="background:red; color:white" |

== Camp26 Visitor ==
|RFI www.camp26.biz
|
|
|-
|style="background:#cef2e0; color:black"|

== iJoomla News Portal ==
|RFI SID
|
|[http://www.ijoomla.com/forum/index.php/topic,4480.0.html Update to 1.5.10]
|-
|
== article Factory Manager ==
|RFI & Input Validation Error http://www.thefactory.ro/shop/joomla-components/article-manager.html
|may 2010
|can not reproduce and unproven, http://www.thefactory.ro
|-
|style="background:#cef2e0; color:black"|

== Table JX Component ==
|http://www.toolsjx.com/ Table JX Component XSS
|060510 - update 130510
|Version: 1.5.5 considered unsafe, [http://www.toolsjx.com update to 1.5.7]
|-
|style="background:red; color:white" |

== JE Property ==
|JE Property Finder Upload Vulnerability
|
|
|-
|style="background:red; color:white" |

== Noticeboard ==
|Noticeboard for Joomla "controller" Local File Inclusion Vulnerability
|
|
|-
|style="background:red; color:white" |

==SmartSite ==
|SmartSite com_smartsite Local File Inclusion Vulnerability
|
|
|-
|style="background:#cef2e0; color:black" |

== ABC ==
|ABC SQL Injection Vulnerability
|
|reported as updated to JED 290410
|-
|style="background:red; color:white" |

== htmlcoderhelper graphics ==
|htmlcoderhelper graphics v1.0.6 LFI Vulnerability
|
|
|-
|style="background:red; color:white" |

== Ultimate Portfolio ==
|Ultimate Portfolio Local File Inclusion Vulnerability
|
|
|-
|style="background:#cef2e0; color:black" |

== huruhelpdesk ==
|http://www.huruhelpdesk.net sqli injection
|
|[http://www.huruhelpdesk.net/forums/8-announcements/392--sql-injection-reveals-user-md5-password-hash Reported fix]
|-
|style="background:red; color:white" |

== Archery Scores ==
| [http://lispeltuut.org/ Archery Scores (com_archeryscores) v1.0.6 LFI Vulnerability]

|210410
|
|-
|style="background:red; color:white" |

== ZiMB Manager ==
|Joomla Component ZiMB Manager Local File Inclusion Vulnerability
|210410
|
|-
|style="background:red; color:white" |

== Matamko ==
|Matamko Local File Inclusion Vulnerability
|210410
|
|-
|style="background:red; color:white" |

== Multiple Root ==
|Multiple Root Local File Inclusion Vulnerability http://joomlacomponent.inetlanka.com/
|
|
|-
|style="background:red; color:white" |

== Multiple Map ==
|Multiple Map Local File Inclusion Vulnerability joomlacomponent.inetlanka.com
|
|
|-
|style="background:red; color:white" |

== Contact Us Draw Root Map ==
|Draw Root Map Local File Inclusion Vulnerability joomlacomponent.inetlanka.com
|
|
|-
|style="background:red; color:white" |

== iF surfALERT ==
|[http://www.inertialfate.za.net/ iF surfALERT] Local File Inclusion Vulnerability
|
|
|-
|style="background:red; color:white" |

== GBU FACEBOOK ==
|GBU FACEBOOK SQL injection vulnerability http://www.gbugrafici.nl/gbufacebook/
|
|
|-
|style="background:red; color:white" |

== jnewspaper ==
|jnewspaper (cid) SQL Injection Vulnerability
|
|
|-
|style="background:#cef2e0; color:black"|

== JTM Reseller ==
|TM Reseller SQL injection vulnerability
|
|[http://jtmreseller.com/ Developer Update]
|-
|style="background:#cef2e0; color:black" |

== media Mall Factory ==
|SQLi
|200410
| [http://www.thefactory.ro/contact-us/product-update-request.html Solution: update to 1.0.5]

|-
|style="background:#cef2e0; color:black"|

== Gadget Factory ==
|LFi
|200410
|[http://www.thefactory.ro/contact-us/product-update-request.html Solution: update to 1.5.1]
|-
|style="background:#cef2e0; color:black"|

== Deluxe Blog Factory ==
|SQLi
|200410
|[http://www.thefactory.ro/contact-us/product-update-request.html update to 1.1.2]
|-
|

== ==
|
|
|
|-
|style="background:red; color:white" |
== MT Fire Eagle ==

|LFI http://joomlacode.org/gf/project/jfireeagle/frs/ http://www.moto-treks.com
| 190410
| product considered retired and to be replaced by dev
|-
|
== com properties ==
| http://com-property.com/ SQL I
|
|[http://www.com-property.com/images/fbfiles/files/properties-20100413.txt developer announced fix]
|-
|style="background:red; color:white"|

== Sweetykeeper ==
|Sweetykeeper Local File Inclusion Vulnerability http://www.joomlacorner.com/
|120410
|
|-
|style="background:red; color:white"|

== jvehicles ==
|SQL Injection http://jvehicles.com
|120410
|
|-
|style="background:red; color:white"|

== worldrates ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== cvmaker ==
|http://dev.pucit.edu.pk/
|
|
|-
|style="background:red; color:white"|

== advertising ==
|http://dev.pucit.edu.pk/
|
|
|-
|style="background:red; color:white"|

== horoscope ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== webtv ==
|http://dev.pucit.edu.pk/
|120410
|-
|style="background:red; color:white"|

== diary ==
|http://dev.pucit.edu.pk/
|120410
|-
|style="background:#cef2e0; color:black"|

== Multi-Venue Restaurant Menu Manager (MVRMM) ==
|http://www.focusdev.co.uk/
|120410
||[http://extensions.joomla.org/extensions/vertical-markets/food-a-beverage/10015 Version 1.5.2 Stable Update 4]
|-
|style="background:red; color:white"|

== Memory Book ==
|http://dev.pucit.edu.pk/
|120410
|-
|style="background:red; color:white"|

== TRAVELbook ==
| http://www.demo-page.de/
|120410
|-
|style="background:#cef2e0; color:black"|

== AlphaUserPoints ==
|
|[http://www.alphaplug.com/index.php/downloads.html?func=fileinfo&id=31 developer upgrade]

|-
|style="background:red; color:white"|

== JprojectMan ==
|LFI http://extensions.joomla.org/extensions/communities-a-groupware/project-a-task-management/5676
|110410
|-
|style="background:#cef2e0; color:black"|

== CKForms ==
|1.3.4 release - Important LFI security fix [http://joomlacode.org/gf/project/ckforms/news/?action=NewsThreadView&id=2814 ]
|07-04-10
|[http://ckforms.cookex.eu/download/download.php upgrade]
|-
|style="background:red; color:white"|

== econtentsite ==
|LFI
|040410
|-
|style="background:red; color:white"|

== Jvehicles ==
|ID
|040410
|-
|

== ==
|
|
|-
|style="background:#cef2e0; color:black"|

== smestorage ==
|[http://www.smestorage.com SMEStorage] LFI

|Updated 29 March 10
|[http://gelembjuk.com/index.php?option=com_content&view=section&layout=blog&id=1&Itemid=55 developer fix] to 1.1
|-
|style="background:#cef2e0; color:black"|

== JE Tooltip ==
|[http://joomlaextensions.co.in/formcreator/ JE Tooltip] LFI
|Updated 23 March
|-
|style="background:#cef2e0; color:black"|

== Gift Exchange Beta ==
|[http://extensions.joomla.org/extensions/communities-a-groupware/membership/11680 Gift exchange] SQLi
|Updated 23 March
|[http://socialables.com/28-Jomsocial/Gift-Exchange/flypage.tpl.html upgrade beta 1.0.1]

|-
|style="background:#cef2e0; color:black"|

== RokDownloads ==
|[[http://extensions.joomla.org/extensions/directory-a-documentation/downloads/7967 LFI]]
|15 march 2010
||upgrade to [http://www.rockettheme.com/extensions-updates/638-rokdownloads-10-released version 1.0]
|-
|style="background:red; color:white"|

== gigcalender ==

|SQLi [http://extensions.joomla.org/extensions/calendars-a-events/events/97)http://extensions.joomla.org/extensions/calendars-a-events/events/97 gigcalender]
|13 march 2010
|
|-
|style="background:red; color:white"|

== heza content ==
|SQLi [http://extensions.joomla.org/extensions/structure-a-navigation/sections-a-categories/10427)http://extensions.joomla.org/extensions/structure-a-navigation/sections-a-categories/10427 heza content]
|13 march 2010
|
|-
|style="background:#cef2e0; color:black" |

== juliaportfolio ==
|LFI [http://extensions.joomla.org/extensions/directory-&-documentation/portfolio/8519/details juliaportfolio]
|13 march 2010
|[http://www.treidorinte.ro/joomla-extensions/19-joomla-components/467-juliaportfolio-security-upgrade-required withdrawal and update notice]
|-

|style="background:#cef2e0; color:black" |

== Flash Magazine Deluxe ==
|SQL Injection Vulnerability.
|Feb 25
|'''[http://www.joomplace.com/flash-magazine-deluxe/flash-magazine-deluxe-description.html Developer Update Version 2.0.11 09/03/10]'''
|-
|style="background:red; color:white" |

== SqlReport ==
|Sqlreport has a sql/RFI exploit. awaiting confirmation on exact developer.
|Feb 20
|'''Not Known'''
|-
|style="background:#cef2e0; color:black" |

== Scriptegrator ==
|Core Design [http://www.greatjoomla.com/extensions/plugins/core-design-scriptegrator-plugin.html Scriptegrator] RFI exploit
|Feb 20
|[http://www.greatjoomla.com/extensions/plugins/core-design-scriptegrator-plugin.html Dev Upgrade announcement]
|-
|style="background:#cef2e0; color:black" |

== AllVideos 3.1 ==
|
A vulnerability discovered in versions 3.0. and 3.1 of the plugin can be exploited by malicious people to disclose potentially sensitive information. For security reasons we will not be providing further details to safeguard users of affected versions. http://www.joomlaworks.gr/content/view/77/34/]|
|17 Feb
| [http://joomlaworks.googlecode.com/files/plg_jw_allvideos-v3.3_j1.5.zip Version 3.3 release 18th]
|-
|style="background:#cef2e0; color:black" |

== RW Cards ==
| [http://extensions.joomla.org/extensions/3430/details RW Card] LFI and ID exploit [http://www.weberr.de/ Dev Site]
|180210
|style="background:#cef2e0; color:black" |''' [http://www.weberr.de/index.php/forum.html?func=view&catid=5&id=1939&limit=6 developer update]'''
|-
|style="background:red; color:white" |

== Yelp ==
| SQLi - Unable to locate developer. Possibly a custom extension.
|Feb 01
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" |

== '''Autartitarot''' ==
|Directory Traversal. Back end access required
| Feb 05
|style="background:#cef2e0; color:black" | ''' Please upgrade to [http://www.autartica.be/en/autartitarot version 1.0.4]'''
|-
|style="background:#cef2e0; color:black" |

== communitypolls ==
|LFI - [http://www.corejoomla.com/ community polls]
|Feb 17
||upgrade to [http://www.corejoomla.com/ version 1.5.3]
|-
|

== ==
|
|
|
|}
<endFeed />

''This list is change protected, for updates or additions [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 Mandville] or [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=87230 lafrance]
''

== Codes used ==
SQLi - SQL injection [http://en.wikipedia.org/wiki/Code_injection#SQL_injection wikipedia]

LFI - Local File Inclusion [http://www.scribd.com/doc/6498408/Remote-and-Local-File-Inclusion-Explained scribd]

RFI - Remote file inclusion [http://en.wikipedia.org/wiki/Remote_File_Inclusion wikipedia]

DT - Directory Traversal [http://en.wikipedia.org/wiki/Directory_traversal wikipedia]

ID = Information Disclosure: account information or sensitive information publicly viewable

== Future Actions & WIP ==

[http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions RSS feed] completed

to feed VEL direct to twitter

== Notes ==
The RSS feed is currently fed by item entry order and not by date fixed.
List as discussed in [[jtopic:455746]] by [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=67439 PhilD] editing by [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 Mandville]

----
[[Category:Security]]
[[Category:Security_FAQ]]
[[Category:Component Management]]
----

Moving sensitive files outside the web root j16

2010-12-16T03:35:23Z

Ian:

== Overriding defines.php ==

Starting with version 1.6, it is possible to provide a localized version of the files that reside in includes/defines.php (i.e. includes/defines.php and administrator/includes/defines.php). This makes it possible to move a variety of files outside of document root.

The actual process is quite simple, but it is advisable that you make sure you know what you're doing before proceeding.

To start, copy the file {ROOT}/includes/defines.php to {ROOT}/defines.php and the file {ROOT}/administrator/includes/defines.php to {ROOT}/administrator/defines.php.

Once you have copied the files, it is necessary to edit both new files and add the lines:

define('_JDEFINES', 1);

define('JPATH_BASE', dirname(__FILE__));

underneath the defined('_JEXEC') or die; line.

== Setting the path to configuration.php ==

Now that you have created override files, you can edit them and provide new locations for various directories. The directory we're interested in is JPATH_CONFIGURATION. The default value is defined as:
define('JPATH_CONFIGURATION', JPATH_ROOT);

To put the configuration file in another location, move the file to its new home and
specify the new path. As an example, if your files were in /home/exampleuser/public_html and you wanted to put configuration.php in /home/exampleuser/configuration.php, you would change the JPATH_CONFIGURATION define line to:

define('JPATH_CONFIGURATION', '/home/exampleuser');

Make this change in both files, move the configuration.php file and you're done.

== Other Possibilities ==

The configuration.php file isn't the only thing you can move. I have done some amount of testing and was able to successfully move the JPATH_LIBRARIES directory, the JPATH_PLUGINS directory, the JPATH_MANIFESTS directory (which holds the XML manifests for some extensions and for core updates).

Moving sensitive files outside the web root j16

2010-12-15T02:51:46Z

Ian: New page: == Overriding defines.php == Starting with version 1.6, it is possible to provide a localized version of the files that reside in includes/defines.php (i.e. includes/defines.php and admin...

== Overriding defines.php ==

Starting with version 1.6, it is possible to provide a localized version of the files that reside in includes/defines.php (i.e. includes/defines.php and administrator/includes/defines.php). This makes it possible to move a variety of files outside of document root.

The actual process is quite simple, but it is advisable that you make sure you know what you're doing before proceeding.

To start, copy the file {ROOT}/includes/defines.php to {ROOT}/defines.php and the file {ROOT}/administrator/includes/defines.php to {ROOT}/administrator/defines.php.

Once you have copied the files, it is necessary to edit both new files and add the lines:

define('_JDEFINES', 1);
define('JPATH_BASE', dirname(__FILE__));

underneath the defined('_JEXEC') or die; line.

== Setting the path to configuration.php ==

Now that you have created override files, you can edit them and provide new locations for various directories. The directory we're interested in is JPATH_CONFIGURATION. The default value is defined as:
define('JPATH_CONFIGURATION', JPATH_ROOT);

To put the configuration file in another location, move the file to its new home and
specify the new path. As an example, if your files were in /home/exampleuser/public_html and you wanted to put configuration.php in /home/exampleuser/configuration.php, you would change the JPATH_CONFIGURATION define line to:

define('JPATH_CONFIGURATION', '/home/exampleuser');

Make this change in both files, move the configuration.php file and you're done.

== Other Possibilities ==

The configuration.php file isn't the only thing you can move. I have done some amount of testing and was able to successfully move the JPATH_LIBRARIES directory, the JPATH_PLUGINS directory, the JPATH_MANIFESTS directory (which holds the XML manifests for some extensions and for core updates).

Mootools Testing Plan

2010-11-20T03:27:21Z

Ian: /* Keepalive */

This page will begin to define test procedures that can be used to ensure that all of the Mootools Behaviours are functioning properly.

== Captions ==
Create an image and insert it in an article. Set the title attribute to your caption.
Verify that the caption is inserted below the image.

== Form Validation ==
Browse to a form in the backend and ensure that validation is working correctly.

== Switcher ==
Ensure the switcher works in the Global Configuration and System Information

== Combo Box ==
This is not used in core and should be deprecated.

== Tooltip ==
Create an element with a class 'hasTip'. Add an attribute title with the tooltip. The tooltip should popup when you mouseover the element.

== Modal ==
Make sure the modals still work.

== Uploader ==
Test the uploader in the Media Manager, the Image Popup in the Article Manager and the frontend Image Popup.

== Tree ==
Ensure the tree works in the media manager.

== Calendar ==
Calendar doesn't use Mootools, but test by selecting a date and ensuring that the proper date is inserted into the text field.

== Keepalive ==
Ensure that a request is made to the server one minute before timeout. You can verify using the Apache logs.

== No Frames ==

Mootools Testing Plan

2010-11-20T03:26:46Z

Ian: /* Calendar */

Mootools Testing Plan

2010-11-20T03:24:19Z

Ian: /* Tree */

Mootools Testing Plan

2010-11-20T03:23:57Z

Ian: /* Uploader */

Mootools Testing Plan

2010-11-20T03:23:10Z

Ian: /* Modal */

Mootools Testing Plan

2010-11-20T03:22:56Z

Ian: /* Tooltip */

Mootools Testing Plan

2010-11-20T03:20:31Z

Ian: /* Combo Box */

Mootools Testing Plan

2010-11-20T03:12:29Z

Ian: /* Switcher */

Mootools Testing Plan

2010-11-20T03:11:27Z

Ian: /* Form Validation */

Mootools Testing Plan

2010-11-20T02:41:10Z

Ian: /* Captions */

Mootools Testing Plan

2010-11-20T02:34:51Z

Ian: New page: This page will begin to define test procedures that can be used to ensure that all of the Mootools Behaviours are functioning properly. == Captions == == Form Validation == == Switch...

This page will begin to define test procedures that can be used to ensure that all of the Mootools Behaviours are functioning properly.

== Captions ==

== Form Validation ==

== Switcher ==

== Combo Box ==

== Tooltip ==

== Modal ==

== Uploader ==

== Tree ==

== Calendar ==

== Keepalive ==

== No Frames ==

Category:Version 1.5.22 FAQ

2010-11-05T05:17:34Z

Ian: New page: These FAQs are specific to the Joomla 1.5.22 release. Only issues that are specific to this release will be listed here, together with suggested resolutions. Please add information to this...

These FAQs are specific to the Joomla 1.5.22 release. Only issues that are specific to this release will be listed here, together with suggested resolutions. Please add information to this resource. The Joomla Bug Squad will watch over this page to ensure any new bugs are added to the tracker and resolved. Continue to use the Joomla forums for support requests as this is not a substitute for posting there, but rather a common location for the community to gather release issues.

Help16:Content Article Manager

2010-11-01T16:37:10Z

Ian:

==How to access==
Click the Article Manager icon in the [[Help16:Site_Control_Panel|Control Panel]], or click 'Article Manager' in the 'Content' menu in the back-end of your Joomla! installation.

==Description==
The Article Manager is the place in the back-end where you can add and manage all of the articles for your web site.

==Screenshot==
[[Image:Help16-content-article_manager-screen.png]]

==Column Headers==
Click on the column heading to sort the list by that column's value.
{{colheader|Checkbox}}
{{colheader|Title}}
* '''Published''' ''(needs new 1.6 version)''
* '''Featured''' ''(needs new 1.6 version)''
* '''Category''' ''(needs new 1.6 version)''
* '''Ordering''' ''(needs new 1.6 version)''
* '''Access''' ''(needs new 1.6 version)''
* '''Created by''' ''(needs new 1.6 version)''
* '''Date''' ''(needs new 1.6 version)''
* '''Hits''' ''(needs new 1.6 version)''
{{colheader|Id}}
* '''Display #''' ''(needs new 1.6 version)''

==Toolbar==
At the top right you will see the following toolbar:
[[Image:Help16-content-article_manager-toolbar.png]]

The functions are:
{{toolbaricon|New}}
{{toolbaricon|Edit}}
{{toolbaricon|Publish}}
{{toolbaricon|Unpublish}}
{{toolbaricon|Archive}}
* '''Check in''' ''(needs new 1.6 version)''
{{toolbaricon|Trash}}
*'''Options''' Click this button to open the Global Configuration window. This window allows you to set default parameters for Articles. This default parameter will take effect if the corresponding Menu Item parameter and Article parameter are both set to 'Use Global'. See [[#Global Configuration|Global Configuration]] below.
{{toolbaricon|Help}}

==List Filters==
'''Filter by Partial Title'''

You can filter the list of items either by entering in part of the title or the ID number. Or you can select a combination of Section, Category, Author, and Published State.
{{colheader|List Filter}}

'''Filter by Section, Category, Author, Published State'''
In the upper right area, above the column headings, are 4 drop-down list boxes as shown below:[[Image:article_manager_filter2.png|center]] The selections may be combined. Only items matching all selections will display in the list.
{{colheader|Select Section}}
{{colheader|Select Category}}
{{colheader|Select Author}}
{{colheader|Select State}}

==Global Configuration==
This pop-up screen is shown when the User clicks the 'Parameters' button on the Toolbar.

===Screenshot===
[[Image:articles_global1.png|center]]
[[Image:articles_global2.png|center]]

===Column Headers===

{{colheader|Global Show Unauthorized Links}}
{{colheader|Global Show Article Title}}
{{colheader|Global Title Linkable}}
{{colheader|Global Show Intro Text}}
{{colheader|Global Section Name}}
{{colheader|Global Section Title Linkable}}
{{colheader|Global Category Title}}
{{colheader|Global Category Title Linkable}}
{{colheader|Global Author Name}}
{{colheader|Global Created Date and Time}}
{{colheader|Global Modified Date and Time}}
{{colheader|Global Show Navigation}}
{{colheader|Global Read more... Link}}
{{colheader|Global Article Rating/Voting}}
{{colheader|Global Icons}}
{{colheader|Global PDF Icon}}
{{colheader|Global Print Icon}}
{{colheader|Global E-mail Icon}}
{{colheader|Hits}}
{{colheader|Global For each feed item show}}

===Filtering Options (HTML)===

Web sites can be attacked by users entering in special HTML code. Filtering is a way to protect your Joomla! web site. Joomla! 1.6 brings new filtering options to give you more control over the HTML that your content providers are allowed to submit. You can be as strict or as liberal as you desire, depending on your site's needs.

It is important to understand that filtering occurs at the time an article is saved, ''after'' it has been written or edited. Depending on your editor and filter settings, it is possible for a user to add HTML to an article during the edit session only to have that HTML removed from the article when it is saved. This can sometimes cause confusion or frustration. If you have filtering set up on your site, make sure your users understand what types of HTML are allowed.

The default setting, as of Joomla! version 1.6, is that all users will have "black list" filtering on by default. This is designed to protect against markup commonly associated with web site attacks. So, if you do not set any filtering options, all users will have "black list" filtering done using the default list of filtered items. If you create a filter here, this overrides the default, and the default filter is no longer in effect.

To access the filtering settings, click on Options and select 'Text filters'

For each user group on your site you can specify what type of filtering is applied to their edits.

====Filter Types====
There are four types of filters: Black List, White List, No HTML and No Filtering.

=====Black List Filters=====
The default filter method in Joomla! is 'Black List'. The default 'Black List' contains the following tags to exclude:

:'applet', 'body', 'bgsound', 'base', 'basefont', 'embed', 'frame', 'frameset', 'head', 'html', 'id', 'iframe', 'ilayer', 'layer', 'link', 'meta', 'name', 'object', 'script', 'style', 'title', 'xml'

The default 'Black List' contains the following attributes to exclude:

:'action', 'background', 'codebase', 'dynsrc', 'lowsrc'

You can 'Black List' (disallow) additional tags and attributes by adding to the Filter tags and Filter attributes fields, separating each tag or attribute name with a space or comma. If you select a Filter Type of "Black List", this list will always be used, plus any additional tags and attributes you add.

=====White List Filters=====
White list filters allow you to specify that a given group can only use a specific list of HTML tags and attributes. You can 'White List' (allow) tags and attributes by adding to the Filter tags and Filter attributes fields for the desired group, separating each tag or attribute name with a space or comma.

=====No HTML Filters=====
No HTML filters are the strictest set of filters you can apply. Groups that are set to No HTML will not have permission to use any HTML.

=====No Filtering=====
No filtering is the most permissive set of filters you can apply. Groups that are set to No Filtering will have permission to use any and all tags and attributes, including the default blacklisted tags and attributes.

====Combining Filters====
If a user belongs to two different groups that have different filter settings, filters will combine in a permissive way. That is, the set of tags the user will be permitted to use will the combination of the tags that each group allows the user to use. So if the user is a member of one group that white lists a specific set of tags and another group that white lists a different set of tags, the user will be able to use both sets of white listed tags. White lists override blacklists, so if a user belongs to one group that black lists a tag and another group that white lists a tag, the user will be able to use that tag. A user that belongs to a group that has no filtering will be able to use any HTML regardless of filtering settings for other groups the user belongs to.

====Filter Application====

Please note that these settings work regardless of the editor that you are using. Even if you are using a WYSIWYG editor, the filtering settings may strip additional tags and attributes prior to saving information in the database.

====Filter Examples====

'''Example One:'''
To allow people in a group to only submit content with basic HTML tags, use the following settings:
* Select White List as the Filter type
* Set the Filter tags to: p, b, i, em, br, a, ul, ol, li, img
* Set the Filter attributes to: href, target, src

'''Example Two:'''
To apply the default black-list filtering to a group, use the following settings:
* Select Black List as the Filter type.
* Leave the Filter Tags and Filter attributes fields empty.

[[Image:Text_filters.png]]

====Developers Notes====

The filtering parameters in config.xml have the new parameter menu="hide". This hides the filters from the Menu Item's Component pane as you do not want cascading overrides to occur at the menu item level.

==Quick Tips==
*In Joomla! versions prior to 1.5, there were separate processes for creating a Static Content Item and normal Content Items. Both processes are now done just by adding Articles. Normal Content Items are now just called Articles, and Static Content Items are now called Uncategorized Articles.

*To create a static content item, create a new Article in the same way as for normal content and assign it to the 'Uncategorized' Section and Category. You can then use the Menu Item Type called Article Layout to show the Article in a page.

*Joomla! 1.5 changes the method you must use to create the 'Read more...' link. When you are adding or editing an article, just press the 'Read more...' button located at the bottom of the screen, next to Image and Pagebreak buttons. This inserts a 'Read more...' break in the Article. The text before the break will display as the Intro Text, and the text after the break will display when the 'Read more...' link is pressed.

==Related Information==
* To add or edit Articles: [[screen.content.edit.15|Article Manager - New/Edit]]
* To manage Categories: [[screen.categories.15|Category Manager]]
* To manage Sections: [[screen.sections.15|Section Manager]]
* To manage Users: [[screen.users.15|User Manager]]

<noinclude>{{cathelp|1.6|Article Manager|Content}}</noinclude>

File:Text filters.png

2010-11-01T16:35:38Z

Ian: Screenshot of the text filters screen.

== Summary ==
Screenshot of the text filters screen.
== Licensing: ==
{{JEDL}}

Help16:Content Article Manager

2010-11-01T16:34:21Z

Ian: /* Filtering Options (HTML) */

==How to access==
Click the Article Manager icon in the [[Help16:Site_Control_Panel|Control Panel]], or click 'Article Manager' in the 'Content' menu in the back-end of your Joomla! installation.

==Description==
The Article Manager is the place in the back-end where you can add and manage all of the articles for your web site.

==Screenshot==
[[Image:Help16-content-article_manager-screen.png]]

==Column Headers==
Click on the column heading to sort the list by that column's value.
{{colheader|Checkbox}}
{{colheader|Title}}
* '''Published''' ''(needs new 1.6 version)''
* '''Featured''' ''(needs new 1.6 version)''
* '''Category''' ''(needs new 1.6 version)''
* '''Ordering''' ''(needs new 1.6 version)''
* '''Access''' ''(needs new 1.6 version)''
* '''Created by''' ''(needs new 1.6 version)''
* '''Date''' ''(needs new 1.6 version)''
* '''Hits''' ''(needs new 1.6 version)''
{{colheader|Id}}
* '''Display #''' ''(needs new 1.6 version)''

==Toolbar==
At the top right you will see the following toolbar:
[[Image:Help16-content-article_manager-toolbar.png]]

The functions are:
{{toolbaricon|New}}
{{toolbaricon|Edit}}
{{toolbaricon|Publish}}
{{toolbaricon|Unpublish}}
{{toolbaricon|Archive}}
* '''Check in''' ''(needs new 1.6 version)''
{{toolbaricon|Trash}}
*'''Options''' Click this button to open the Global Configuration window. This window allows you to set default parameters for Articles. This default parameter will take effect if the corresponding Menu Item parameter and Article parameter are both set to 'Use Global'. See [[#Global Configuration|Global Configuration]] below.
{{toolbaricon|Help}}

==List Filters==
'''Filter by Partial Title'''

You can filter the list of items either by entering in part of the title or the ID number. Or you can select a combination of Section, Category, Author, and Published State.
{{colheader|List Filter}}

'''Filter by Section, Category, Author, Published State'''
In the upper right area, above the column headings, are 4 drop-down list boxes as shown below:[[Image:article_manager_filter2.png|center]] The selections may be combined. Only items matching all selections will display in the list.
{{colheader|Select Section}}
{{colheader|Select Category}}
{{colheader|Select Author}}
{{colheader|Select State}}

==Global Configuration==
This pop-up screen is shown when the User clicks the 'Parameters' button on the Toolbar.

===Screenshot===
[[Image:articles_global1.png|center]]
[[Image:articles_global2.png|center]]

===Column Headers===

{{colheader|Global Show Unauthorized Links}}
{{colheader|Global Show Article Title}}
{{colheader|Global Title Linkable}}
{{colheader|Global Show Intro Text}}
{{colheader|Global Section Name}}
{{colheader|Global Section Title Linkable}}
{{colheader|Global Category Title}}
{{colheader|Global Category Title Linkable}}
{{colheader|Global Author Name}}
{{colheader|Global Created Date and Time}}
{{colheader|Global Modified Date and Time}}
{{colheader|Global Show Navigation}}
{{colheader|Global Read more... Link}}
{{colheader|Global Article Rating/Voting}}
{{colheader|Global Icons}}
{{colheader|Global PDF Icon}}
{{colheader|Global Print Icon}}
{{colheader|Global E-mail Icon}}
{{colheader|Hits}}
{{colheader|Global For each feed item show}}

===Filtering Options (HTML)===

Web sites can be attacked by users entering in special HTML code. Filtering is a way to protect your Joomla! web site. Joomla! 1.6 brings new filtering options to give you more control over the HTML that your content providers are allowed to submit. You can be as strict or as liberal as you desire, depending on your site's needs.

It is important to understand that filtering occurs at the time an article is saved, ''after'' it has been written or edited. Depending on your editor and filter settings, it is possible for a user to add HTML to an article during the edit session only to have that HTML removed from the article when it is saved. This can sometimes cause confusion or frustration. If you have filtering set up on your site, make sure your users understand what types of HTML are allowed.

The default setting, as of Joomla! version 1.6, is that all users will have "black list" filtering on by default. This is designed to protect against markup commonly associated with web site attacks. So, if you do not set any filtering options, all users will have "black list" filtering done using the default list of filtered items. If you create a filter here, this overrides the default, and the default filter is no longer in effect.

To access the filtering settings, click on Options and select 'Text filters'

For each user group on your site you can specify what type of filtering is applied to their edits.

====Filter Types====
There are four types of filters: Black List, White List, No HTML and No Filtering.

=====Black List Filters=====
The default filter method in Joomla! is 'Black List'. The default 'Black List' contains the following tags to exclude:

:'applet', 'body', 'bgsound', 'base', 'basefont', 'embed', 'frame', 'frameset', 'head', 'html', 'id', 'iframe', 'ilayer', 'layer', 'link', 'meta', 'name', 'object', 'script', 'style', 'title', 'xml'

The default 'Black List' contains the following attributes to exclude:

:'action', 'background', 'codebase', 'dynsrc', 'lowsrc'

You can 'Black List' (disallow) additional tags and attributes by adding to the Filter tags and Filter attributes fields, separating each tag or attribute name with a space or comma. If you select a Filter Type of "Black List", this list will always be used, plus any additional tags and attributes you add.

=====White List Filters=====
White list filters allow you to specify that a given group can only use a specific list of HTML tags and attributes. You can 'White List' (allow) tags and attributes by adding to the Filter tags and Filter attributes fields for the desired group, separating each tag or attribute name with a space or comma.

=====No HTML Filters=====
No HTML filters are the strictest set of filters you can apply. Groups that are set to No HTML will not have permission to use any HTML.

=====No Filtering=====
No filtering is the most permissive set of filters you can apply. Groups that are set to No Filtering will have permission to use any and all tags and attributes, including the default blacklisted tags and attributes.

====Combining Filters====
If a user belongs to two different groups that have different filter settings, filters will combine in a permissive way. That is, the set of tags the user will be permitted to use will the combination of the tags that each group allows the user to use. So if the user is a member of one group that white lists a specific set of tags and another group that white lists a different set of tags, the user will be able to use both sets of white listed tags. White lists override blacklists, so if a user belongs to one group that black lists a tag and another group that white lists a tag, the user will be able to use that tag. A user that belongs to a group that has no filtering will be able to use any HTML regardless of filtering settings for other groups the user belongs to.

====Filter Application====

Please note that these settings work regardless of the editor that you are using. Even if you are using a WYSIWYG editor, the filtering settings may strip additional tags and attributes prior to saving information in the database.

====Filter Examples====

'''Example One:'''
To allow people in a group to only submit content with basic HTML tags, use the following settings:
* Select White List as the Filter type
* Set the Filter tags to: p, b, i, em, br, a, ul, ol, li, img
* Set the Filter attributes to: href, target, src

'''Example Two:'''
To apply the default black-list filtering to a group, use the following settings:
* Select Black List as the Filter type.
* Leave the Filter Tags and Filter attributes fields empty.

====Developers Notes====

The filtering parameters in config.xml have the new parameter menu="hide". This hides the filters from the Menu Item's Component pane as you do not want cascading overrides to occur at the menu item level.

==Quick Tips==
*In Joomla! versions prior to 1.5, there were separate processes for creating a Static Content Item and normal Content Items. Both processes are now done just by adding Articles. Normal Content Items are now just called Articles, and Static Content Items are now called Uncategorized Articles.

*To create a static content item, create a new Article in the same way as for normal content and assign it to the 'Uncategorized' Section and Category. You can then use the Menu Item Type called Article Layout to show the Article in a page.

*Joomla! 1.5 changes the method you must use to create the 'Read more...' link. When you are adding or editing an article, just press the 'Read more...' button located at the bottom of the screen, next to Image and Pagebreak buttons. This inserts a 'Read more...' break in the Article. The text before the break will display as the Intro Text, and the text after the break will display when the 'Read more...' link is pressed.

==Related Information==
* To add or edit Articles: [[screen.content.edit.15|Article Manager - New/Edit]]
* To manage Categories: [[screen.categories.15|Category Manager]]
* To manage Sections: [[screen.sections.15|Section Manager]]
* To manage Users: [[screen.users.15|User Manager]]

<noinclude>{{cathelp|1.6|Article Manager|Content}}</noinclude>

Joomla 1.5 version history

2010-09-23T15:50:40Z

Ian:

== Joomla! 1.5.20 ==
* 1.5.20 is the [http://www.joomla.org/announcements/release-news/5284-joomla-1520-released.html newest release]
* Senu takaa
* 18 July 2010
* [http://www.joomla.org/announcements/release-news/5284-joomla-1520-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=5325 Packages and MD5s]

== Joomla! 1.5.19 ==
* Wojmamni ama batani
* 15 July 2010
* [http://www.joomla.org/announcements/release-news/5283-joomla-1519-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=5316 Packages and MD5s]

== Joomla! 1.5.18 ==
* Wojmamni ama wojnaiki
* 28 May 2010
* [http://www.joomla.org/announcements/release-news/5276-joomla-1518-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=5241 Packages and MD5s]

== Joomla! 1.5.17 ==
* Wojmamni ama woobusani
* 23 April 2010
* [http://www.joomla.org/announcements/release-news/5268-joomla-1517-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=5194 Packages and MD5s]

== Joomla! 1.5.16 ==
* Wojmamni ama busani
* 23 April 2010
* [http://www.joomla.org/announcements/release-news/5259-joomla-1516-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=5184 Packages and MD5s]

== Joomla! 1.5.15 ==
* Wojmamni ama mamni
* 4 November 2009
* [http://www.joomla.org/announcements/release-news/5249-joomla-1515-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=4947 Packages and MD5s]

== Joomla! 1.5.14 ==
* Wojmamni ama naiki
* 30 July 2009
* [http://www.joomla.org/announcements/release-news/5244-joomla-1514-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=4734 Packages and MD5s]

== Joomla! 1.5.13 ==
* Wojmamni ama baji
* 22 July 2009
* [http://www.joomla.org/announcements/release-news/5243-joomla-1513-security-release-now-available.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=4712 Packages and MD5s]

== Joomla! 1.5.12 ==
* Wohmamni Ama Woi
* 1 July 2009
* [http://www.joomla.org/announcements/release-news/5242-joomla-1512-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=4665 Packages and MD5s]

== Joomla! 1.5.11 ==
* Vea
* 3 June 2009
* [http://www.joomla.org/announcements/release-news/5235-joomla-1511-security-release-now-available.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=4556 Packages and MD5s]

== Joomla! 1.5.10 ==
* Wohmamni
* 28 March 2009
* [http://www.joomla.org/announcements/release-news/5231-joomla-1510-security-release-now-available.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=4460 Packages and MD5s]

== Joomla! 1.5.9 ==
* Vatani
* 10 January 2009
* [http://www.joomla.org/announcements/release-news/5226-joomla-159-security-release-now-available.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=4288 Packages and MD5s]

== Joomla! 1.5.8 ==
* Wohnaiki
* 10 November 2008
* [http://www.joomla.org/announcements/release-news/5219-joomla-158-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=4136 Packages and MD5s]

== Joomla! 1.5.7 ==
* Wovusani
* 9 September 2008
* [http://www.joomla.org/announcements/release-news/5212-joomla-157-security-release-now-available.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=3947 Packages and MD5s]

== Joomla! 1.5.6 ==
* Vusani
* 12 August 2008
* [http://www.joomla.org/announcements/release-news/5199-joomla-156-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=3883 Packages and MD5s]

== Joomla! 1.5.5 ==
* Mamni
* 28 July 2008
* [http://www.joomla.org/content/view/5216/1/ Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=3846 Packages and MD5s]

== Joomla! 1.5.4 ==
* Naiki
* 08 July 2008
* [http://www.joomla.org/content/view/5180/74/ Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=3786 Packages and MD5s]

== Joomla! 1.5.3 ==
* Vahi
* 24 April 2008
* [http://www.joomla.org/content/view/4852/74/ Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=3587 Packages and MD5s]

== Joomla! 1.5.2 ==
* Woi
* 23 March 2008
* [http://www.joomla.org/content/view/4720/74/ Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=3466 Packages and MD5s]

== Joomla! 1.5.1 ==
* Seenu
* 08 February 2008
* [http://www.joomla.org/content/view/4560/74/ Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=3322 Packages and MD5s]

== Joomla! 1.5 ==
* Khepri
* 22 January 2008
* [http://www.joomla.org/content/view/4488/74/ Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseView&release_id=5078 Package and MD5s]

== Joomla! 1.5.x Change Log ==
For any Joomla! 1.5 release, use this [http://joomlacode.org/gf/project/joomla/scmsvn/?action=browse&path=/development/releases/1.5/administrator/&view=log Change Log]

== To locate the MD5 Hash ==
# Click the link for '''Packages and MD5s''' above for the version desired.
# Click the word '''Files''' in the blue bar to expand the list of patch packages available.
# Locate the row that matches your current installation version.
# On that row, select the patch package (zip, tar.gz and tar.bz2) that is most convenient for you.
# Verify the download using the MD5 hash listed in the right column on the same line as the package you selected.

[[Category:Joomla! 1.5]]

Coding style and standards

2010-06-22T20:06:27Z

Ian:

{{review}}
{{RightTOC}}
remark: The following information has been copied from the old WIKI archive has not yet been reviewed.
See: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,/id,standards:coding/

Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having coding standards helps ensure that the code is of high quality, has fewer bugs, and is easily maintained.

First rule, if in doubt, ask.

== File Format ==
All files contributed to Joomla must:

* Be stored as ASCII text
* Use UTF-8 character encoding
* Be Unix formatted
** Lines must end only with a line feed (LF). Line feeds are represented as ordinal 10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh computers do or the carriage return/line feed combination (CRLF) like Windows computers do.

New files will normally be added to the code base using Subversion (SVN). All SVN files should have the SVN property set "eol-style=LF". Also, most Joomla! files will have "$Id" tags in the "@version" line of the Doc block. These require the SVN property "keywords=Id". See [[Subversion File Properties]] for more information about how to set SVN properties.

== Coding Standards ==

=== Spelling ===

Spelling of class, function, variable and constant names should generally be in accordance with British English rules (en_GB). However, some exceptions are permitted, for example where common programming names are used that align with the PHP API such as <code>$color</code>.

=== E_STRICT-compatible code ===

As of version 1.6, all new code that is suggested for inclusion into Joomla must be E_STRICT-compatible. This means that it must not produce any warnings or errors when PHP's error reporting level is set to E_ALL | E_STRICT.

=== Indenting and Line Length ===

Use tabs to indent, not spaces. Make sure that the tab-stops are set to only 4 spaces in length.

There is no set limit for line length. Use your judgment based on the nature of the line and readability.

=== Control Structures ===

These include if, for, while, switch, etc. Here is an example of an if statement, as it is the most complicated of the control structures:

<source lang="php">
<?php
if ((condition1) || (condition2)) {
action1();
} else if ((condition3) && (condition4)) {
action2();
} else
{
// Use one true brace in control structures
// when the block is longer than one line
defaultAction();
anotherAction();
}

// optional formatting if it improves readability
if ((condition1) || (condition2)) {
action1();
}
else if ((condition3) && (condition4)) {
action2();
}
else {
defaultAction();
anotherAction();
}
</source>

Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.

In '''layouts''', the alternative named notation should be used:

<source lang="php">
<?php
if ((condition1) OR (condition2)) :
action1();
elseif ((condition3) AND (condition4)) :
action2();
else :
defaultAction();
anotherAction();
endif;

foreach ($array as $element) :
echo $element;
endforeach;
</source>

Logical operators in condition statements should use uppercase words (<code>AND</code>, <code>OR</code>, etc) rather than programmatic notation (<code>&&</code>, <code>||</code>, etc).

With the exception of <code>case</code> statements, curly braces must always be included even though they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

For switch statements:

<source lang="php">
<?php
switch (condition)
{
case 1:
doAction1();
break;

case 2:
doAction2();
break;

default:
doDefaultAction();
break;
}
</source>

Use indenting and line-breaks rather than curly braces in the <code>case</code> statements to increase readability. There should be no space between the condition and the colon in the <code>case</code> statement.

=== Function Calls ===

Functions should be called with no spaces between the function name and the opening parenthesis, and no space between this and the first parameter; a space after the comma between each parameter (if they are present), and no space between the last parameter and the closing parenthesis, and the semicolon. Here's an example:

<source lang="php">
<?php
$var = foo($bar, $baz, $quux);
</source>

As displayed above, there should be space before and one space after the equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, tabs (not spaces) may be inserted to promote readability:

<source lang="php">
<?php
$short = foo($bar);
$long_variable = foo($baz);
</source>

=== Function Definitions ===

Class and function declarations follow the "one true brace" convention:

<source lang="php">
<?php
function fooFunction($arg1, $arg2 = '')
{
if (condition) {
statement;
}
return $val;
}

class fooClass
{
function fooMethod($arg1)
{
if ($arg) {
$result = true;
} else {
$result = false;
}
return $result;
}
}
</source>

Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate. Here is a slightly longer example:

<source lang="php">
<?php
function connect(&$dsn, $persistent = false)
{
if (is_array($dsn)) {
$dsninfo = &$dsn;
} else {
$dsninfo = DB::parseDSN($dsn);
}

if (!$dsninfo OR !$dsninfo['phptype']) {
return $this->raiseError();
}

return true;
}
</source>

=== Comments ===

Inline documentation for classes should follow the PHPDoc convention, similar to Javadoc. More information about PHPDoc can be found here: http://www.phpdoc.org/

See also [[Adding phpDocumentor comments]]

Non-documentation comments are strongly encouraged. A general rule of thumb is that if you look at a section of code and think "Wow, I don't want to try and describe that", you need to comment it before you forget how it works.

C style comments (<tt>/* */</tt>) and standard C++ comments (<tt>//</tt>) are both satisfactory. Use of Perl/shell style comments (<tt>#</tt>) is not permitted.

Please note - commented code is not to be committed to trunk or release repositories.

=== Including Code ===

Anywhere you are unconditionally including a class file, use <code>require_once</code>. Anywhere you are conditionally including a class file (for example, factory methods), use <code>include_once</code>. Either of these will ensure that class files are included only once. They share the same file list, so you don't need to worry about mixing them -- a file included with <code>require_once</code> will not be included again by </code>include_once</code>.

;Note: [[php:include_once|include_once]] and [[php:require_once|require_once]] are PHP ''language statements'', not functions. You don't need parentheses around the filename to be included.

=== PHP Code Tags ===

Always use <tt><?php ?></tt> to delimit PHP code, not the <tt><? ?></tt> shorthand. This is the most portable way to include PHP code on differing operating systems and setups.

For files that contain only PHP code, the closing tag (<tt>?></tt>) is never permitted. It is not required by PHP. Not including it prevents trailing white space from being accidentally injected into the output (see PHP manual on [http://au.php.net/basic-syntax.instruction-separation instruction separation]).

=== SQL Queries ===

SQL keywords are to be written in uppercase, while all other identifiers (which the exception of quoted text obviously) is to be in lowercase. Carriage returns should not be used as [[JDatabase]]::getQuery provides for formatted output. However, indenting with spaces to improve readability is desireable.

Queries should be wrapped in single quotes (as these text blocks are parsed faster by php).

All quoted strings must use the ''Quote'' method to facilitate future compatibility with other database engines.

All table names should use the '''<tt>#_</tt>''' prefix rather than <tt>jos_</tt> to access Joomla! contents and allow for the [[screen.config.15#Database_Settings|user defined database prefix]] to be applied.

All expected integer or floating-point variable must be [http://php.net/manual/language.types.type-juggling.php cast] with <tt>(int)</tt>, <tt>(float)</tt> or <tt>(double)</tt> as appropriate.

<source lang="php">
$state = 1;
$name = 'bill';
$db = &JFactory::getDBO();
$query = 'SELECT COUNT( c.id ) AS num_articles, u.id, u.username'.
' FROM #__content AS c'.
' LEFT JOIN #__users AS u ON u.id = c.created_by'.
' WHERE c.state = '.(int) $state
' AND u.id IS NOT NULL'.
' AND u.username <> '.$db->Quote( $name ).
' GROUP BY u.id'.
' HAVING COUNT( c.id ) > 0';
$db->setQuery();
// Output formated query if joomla debug is active:
if (JDEBUG) {
echo $db->getQuery();
}
$stats = $db->loadObjectList();
</source>

=== Doc Blocks ===

All source code files in the core Joomla distribution must contain the following comment block as the header:

<source lang="php">
<?php
/**
* @version $Id$
* @package Joomla
* @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.
* @license GNU/GPL, see LICENSE.php
*/
</source>

The <code>@package</code> in the header is not required for class-only files.

Classes, functions, constants, class properties and class methods should all be supplied with appropriate DocBlocks.

<source lang="php">
/**
* Short description for class
*
* Long description for class (if any)...
*
* @package PackageName
* @subpackage SubPackageName
* @link http://pear.php.net/package/PackageName
* @see NetOther, Net_Sample::Net_Sample()
* @since Class available since Release 1.2.0
* @deprecated Class deprecated in Release 2.0.0
*/
class JFooBar
{
/**
* @var int $id Primary key
*/
public $id = null;
}
</source>

The following package names are to be used in the core stack:

* Joomla.Administrator - all files that belong only to the administrator or backend application
* Joomla.Installation - all files that belong to the installation application
* Joomla.Plugin - all plugin files
* Joomla.Site - all files that pertain only to the site or frontend application
* Joomla.XML-RPC - all files that belong to the XML-RPC server application

The sub-package name will vary according to the extension type:

* Components - the component folder, eg <code>com_content</code>
* Modules - the module folder, eg <code>mod_latest_news</code>
* Plugins - the folder.element, eg <code>content.pagebreak</code>
* Templates - the template folder, eg <code>rhuk_milkyway</code>
* Framework - nothing for top level files (such as <code>factory.php</code>), the first level folder or the first.second level folders as appropriate, eg <code>utilities</code> for <code>joomla/utilities/date.php</code>, <code>html.html</code> for <code>joomla/html/html/email.php</code>

Please note that code contributed to the Joomla stack that will become the copyright of the project is not allowed to include <code>@author</code> tags. You should update the contribution log in <tt>CREDITS.php</tt>. Joomla's philosophy is that the code is written "all together" and there is no notion of any one person 'owning' any section of code.

Files included from third party sources must leave DocBlocks intact. Layout files use the same DocBlocks as other PHP files.

Note that the "@version $Id" line uses the SVN "keywords=Id" property. See [[Subversion File Properties]] for information about setting this property.

== Naming Conventions ==

=== Classes ===

Classes should be given descriptive names. Avoid using abbreviations where possible. Class names should always begin with an uppercase letter and be written in CamelCase even if using traditionally uppercase acronyms (such as XML, HTML). One exception is for Joomla framework classes which must begin with an uppercase 'J' with the next letter also being uppercase. For example:

* JHtmlHelper
* JXmlParser
* JModel

Third-party developers are advised to namespace their functions with a unique prefix.

=== Functions and Methods ===

Functions and methods should be named using the "studly caps" style (also referred to as "bumpy case" or "camel caps"). The initial letter of the name is lowercase, and each letter that starts a new "word" is capitalized. Function in the Joomla framework must begin with a lowercase 'j'. Some examples:

<source lang="php">
connect();
getData();
buildSomeWidget();
jImport();
jDoSomething();
</source>

Private class members (meaning class members that are intended to be used only from within the same class in which they are declared; are preceded by a single underscore. Properties are to be written in underscore format (that is, logical words separated by underscores) and should be all lowercase. For example:

<source lang="php">
class JFooBar
{
// Joomla 1.5 and earlier format
var $_status = null;

function _sort()
{
}

// Joomla 1.6 format
private $_status = null;

protected $field_name = null;

protected function _sort()
{
}
}
</source>

=== Constants ===

Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercase name of the class/package they are used in. For example, the constants used by the [[JError]] class all begin with "JERROR_".

=== Global Variables ===

If your package needs to define global variables, their name should start with a single underscore followed by the uppercase class/package name and another underscore. For example, the JError class uses a global variable called $_JERROR_LEVELS.

With PHP5 and later you may use static class properties or constants instead of globals.
<source lang="php">
<?php
class JWhatever
{
public static $instance = null;
const SUCCESS = 1;
const FAILURE = 0;
// Methods...
}
</source>

=== Regular and Class Variables ===

Regular variables, follow the same conventions as function.

Class variables should be set to null or some other appropriate default value. Lining up the default values with tabs should only be used if particularly warranted for readability.

=== References ===

When using references, there should be a space before the reference operator and no space between it and the function or variable name. For example:

<source lang="php">
<?php
$ref1 = &$this->_sql;
$db = &JFactory::getDBO();
</source>

=== Language Keys ===

NOTE: This part has to be rewritten for 1.6 (JM)

Except for the most common of words, such as "Yes", "No", "Show", "Hide" all language keys should be namespaced to reflect the type of string they represent. Always consider that if two extensions use the same key, the one loaded last will be the one that displays. Namespacing should generally relate to the extension displaying the text. For example:

<source lang="php"><?php
echo JText::_('Weblink Link');
echo JText::_('Weblink Title');
echo JText::_('Weblink Description');

echo JText::_('Exception An error occurred while saving');
?></source>

TODO: Link to page with "common" strings that can be used for typical actions in components, such a "Save"

Where the same English word is used in two different locations, two different language keys should be used to allow for cases where the translation results in different words or phrases.

<source lang="php">
// A table column title
<th><?php echo JText::_('Weblink Column Title');?></th>
<th><?php echo JText::_('Weblink Column Link');?></th>

// In the form
<?php echo JText::_('Weblink Title');?><input name="title" />
<?php echo JText::_('Weblink Link');?><input name="link" />
</source>

Toolbar and Linkbar text should be prefixed Toolbar and Linkbar respectively.

The language keys should be written as naturally as possible with spaces, not underscores separating words. Long phrases can be condensed to reduce keys to a sensible length. For example, tooltips for an edit field can be written like this:

<source lang="php">
<?php echo JText::_('Weblink Title');?><input name="title" title="<?php echo JText::_('Weblink Title Desc');?>" />
</source>

The convention used should be governed by common sense, but must be consistent. In general consider how the language file will look with all keys sorted alphabetically. Prefixes should be used to group text within a common context (such as column headings). Suffixes should be used to group elements that logically go together (such as a field name and its description).

Phrases must never be assembled by string concatenation. Each phrase must be represented by a single language key, using sprintf as appropriate to replace dynamic words in the phrase. Where replacements are made, the word used should be as descriptive as possible and all-uppercase. This assists the translators to determine the context of the replacement.

<source lang="php"><?php
// Not permitted
echo JText::_('Deleted ').$n.JText::_(' items');

// Permitted
echo JText::sprintf('Message Deleted NUMBER items', $n);
?></source>

The reference in the language file would look like this:

<source lang="php">MESSAGE DELETED NUMBER ITEMS=Deleted %d Item(s)</source>

If more than one dynamic string is used in a phrase, the printf markers should employ order placement as other languages might change the position of the strings. This is done via %[number]$[printf_type] as follows:

Left to right language:

<source lang="php">PAGE X OF Y=Page %1$d of %2$d</source>

Right to left language:

<source lang="php">PAGE X OF Y=%2$d of %1$d egaP</source>

=== Controllers ===

For single controller components, the naming convention is ''[Name]Controller''.

<source lang="php">
<?php
/**
* Content Controller
* @package Joomla
*/
class ContentController extends JController
{
// Methods
}
</source>
The file name will generally be ''controller.php'' and is located in the component folder.
<source lang="text">
com_content
/ controller.php
</source>

For a multi-controller components, such as the Banners in the Administrator, the convention is ''[Component]Controller[Name]''.

<source lang="php">
<?php
/**
* Banner Client Controller
* @package Joomla
*/
class BannerControllerClient extends JController
{
// Methods
}
</source>

The files will be located in a <tt>/controllers/</tt> folder under the component folder. The file names will reflect the name of the controller.
<source lang="text">
com_banner
/controllers/
/ banner.php
/ client.php
</source>

=== Models===

The naming convention is ''[Component]Model[Name]''.

<source lang="php">
<?php
/**
* Banner Client Model
* @package Joomla
*/
class BannerModelClient extends JModel
{
// Methods
}
</source>

The files will be located in a <tt>/models/</tt> folder under the component folder. The file names will reflect the name of the model.

<source lang="text">
com_banner
/models/
/ banner.php
/ client.php
</source>

=== Views ===
The naming convention is ''[Component]View[Name]''.
<source lang="php">
<?php
/**
* Contact Category View
* @package Joomla
*/
class ContactViewCategory extends JView
{
// Methods
}
</source>
The files will be located in a <tt>/view/</tt> folder under the component folder. The subfolder names will reflect the name of a View.

com_contact
/views/
/''view name 1''/
/ view.html.php
/''view name 2''/
/ view.html.php

Multi-view components such as com_content may provide an optional "master" view class the specialised views extend from. It is located in the component folder and typically called ''view.php''. The naming convention is ''[Component]View''.

com_content
/views/
<span style="color:#999">/archive/</span>
/ view.html.php
<span style="color:#999">/article/</span>
/ view.php

<source lang="php">
view.php
<?php
/**
* Content View
* @package Joomla
*/
class ContentView extends JView
{
// Helper Methods
}

views/archive/view.html.php
<?php
/**
* Content Archive View
* @package Joomla
*/
class ContactViewArchive extends ContentView
{
// Methods
}

</source>

=== Plugins ===

The naming convention is ''plg[Folder][Element]'' as pointed out in [[How to create a content plugin|the relative HowTo page]].

<source lang="php">
class plgContentPagebreak extends JPlugin
{
// Methods
}
</source>

=== Layouts ===
Components may support different Layouts to render the data supplied by a [[#Views|View]] and its [[#Models|Models]]. A Layout file usually contains markup and some PHP code for ''display logic only'': no functions, no classes.

A Layout consists of at least one .php file and an equally named [[Creating a basic layout.xml file|.xml manifest file]] located in the <tt>/tmpl/</tt> folder of a View, both reflect the internal name of the Layout. The standard Layout is called ''default''.

<span style="color:#999">com_content
/views/
/article/</span><span style="color:#000">
/tmpl/
/ default.php
/ default.xml
/ form.php
/ form.xml
/ pagebreak.php
/ pagebreak.xml </span>

The Layout may use supplemental .php files to provide more granule control in order to render individual parts or repetitive items of the data.

Users may customize the Layout output via [[#Template Layout Overrides|Template Layout Overrides]].

=== Templates ===

=== Template Layout Overrides ===

Coding style and standards

2010-06-22T19:29:30Z

Ian: /* Controllers */

{{review}}
{{RightTOC}}
remark: The following information has been copied from the old WIKI archive has not yet been reviewed.
See: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,/id,standards:coding/

Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having coding standards helps ensure that the code is of high quality, has fewer bugs, and is easily maintained.

First rule, if in doubt, ask.

== File Format ==
All files contributed to Joomla must:

* Be stored as ASCII text
* Use UTF-8 character encoding
* Be Unix formatted
** Lines must end only with a line feed (LF). Line feeds are represented as ordinal 10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh computers do or the carriage return/line feed combination (CRLF) like Windows computers do.

New files will normally be added to the code base using Subversion (SVN). All SVN files should have the SVN property set "eol-style=LF". Also, most Joomla! files will have "$Id" tags in the "@version" line of the Doc block. These require the SVN property "keywords=Id". See [[Subversion File Properties]] for more information about how to set SVN properties.

== Coding Standards ==

=== Spelling ===

Spelling of class, function, variable and constant names should generally be in accordance with British English rules (en_GB). However, some exceptions are permitted, for example where common programming names are used that align with the PHP API such as <code>$color</code>.

=== E_STRICT-compatible code ===

As of version 1.6, all new code that is suggested for inclusion into Joomla must be E_STRICT-compatible. This means that it must not produce any warnings or errors when PHP's error reporting level is set to E_ALL | E_STRICT.

=== Indenting and Line Length ===

Use tabs to indent, not spaces. Make sure that the tab-stops are set to only 4 spaces in length.

There is no set limit for line length. Use your judgment based on the nature of the line and readability.

=== Control Structures ===

These include if, for, while, switch, etc. Here is an example of an if statement, as it is the most complicated of the control structures:

<source lang="php">
<?php
if ((condition1) || (condition2)) {
action1();
} else if ((condition3) && (condition4)) {
action2();
} else
{
// Use one true brace in control structures
// when the block is longer than one line
defaultAction();
anotherAction();
}

// optional formatting if it improves readability
if ((condition1) || (condition2)) {
action1();
}
else if ((condition3) && (condition4)) {
action2();
}
else {
defaultAction();
anotherAction();
}
</source>

Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.

In '''layouts''', the alternative named notation should be used:

<source lang="php">
<?php
if ((condition1) OR (condition2)) :
action1();
elseif ((condition3) AND (condition4)) :
action2();
else :
defaultAction();
anotherAction();
endif;

foreach ($array as $element) :
echo $element;
endforeach;
</source>

Logical operators in condition statements should use uppercase words (<code>AND</code>, <code>OR</code>, etc) rather than programmatic notation (<code>&&</code>, <code>||</code>, etc).

With the exception of <code>case</code> statements, curly braces must always be included even though they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

For switch statements:

<source lang="php">
<?php
switch (condition)
{
case 1:
doAction1();
break;

case 2:
doAction2();
break;

default:
doDefaultAction();
break;
}
</source>

Use indenting and line-breaks rather than curly braces in the <code>case</code> statements to increase readability. There should be no space between the condition and the colon in the <code>case</code> statement.

=== Function Calls ===

Functions should be called with no spaces between the function name and the opening parenthesis, and no space between this and the first parameter; a space after the comma between each parameter (if they are present), and no space between the last parameter and the closing parenthesis, and the semicolon. Here's an example:

<source lang="php">
<?php
$var = foo($bar, $baz, $quux);
</source>

As displayed above, there should be space before and one space after the equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, tabs (not spaces) may be inserted to promote readability:

<source lang="php">
<?php
$short = foo($bar);
$long_variable = foo($baz);
</source>

=== Function Definitions ===

Class and function declarations follow the "one true brace" convention:

<source lang="php">
<?php
function fooFunction($arg1, $arg2 = '')
{
if (condition) {
statement;
}
return $val;
}

class fooClass
{
function fooMethod($arg1)
{
if ($arg) {
$result = true;
} else {
$result = false;
}
return $result;
}
}
</source>

Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate. Here is a slightly longer example:

<source lang="php">
<?php
function connect(&$dsn, $persistent = false)
{
if (is_array($dsn)) {
$dsninfo = &$dsn;
} else {
$dsninfo = DB::parseDSN($dsn);
}

if (!$dsninfo OR !$dsninfo['phptype']) {
return $this->raiseError();
}

return true;
}
</source>

=== Comments ===

Inline documentation for classes should follow the PHPDoc convention, similar to Javadoc. More information about PHPDoc can be found here: http://www.phpdoc.org/

See also [[Adding phpDocumentor comments]]

Non-documentation comments are strongly encouraged. A general rule of thumb is that if you look at a section of code and think "Wow, I don't want to try and describe that", you need to comment it before you forget how it works.

C style comments (<tt>/* */</tt>) and standard C++ comments (<tt>//</tt>) are both satisfactory. Use of Perl/shell style comments (<tt>#</tt>) is not permitted.

Please note - commented code is not to be committed to trunk or release repositories.

=== Including Code ===

Anywhere you are unconditionally including a class file, use <code>require_once</code>. Anywhere you are conditionally including a class file (for example, factory methods), use <code>include_once</code>. Either of these will ensure that class files are included only once. They share the same file list, so you don't need to worry about mixing them -- a file included with <code>require_once</code> will not be included again by </code>include_once</code>.

;Note: [[php:include_once|include_once]] and [[php:require_once|require_once]] are PHP ''language statements'', not functions. You don't need parentheses around the filename to be included.

=== PHP Code Tags ===

Always use <tt><?php ?></tt> to delimit PHP code, not the <tt><? ?></tt> shorthand. This is the most portable way to include PHP code on differing operating systems and setups.

For files that contain only PHP code, the closing tag (<tt>?></tt>) is never permitted. It is not required by PHP. Not including it prevents trailing white space from being accidentally injected into the output (see PHP manual on [http://au.php.net/basic-syntax.instruction-separation instruction separation]).

=== SQL Queries ===

SQL keywords are to be written in uppercase, while all other identifiers (which the exception of quoted text obviously) is to be in lowercase. Carriage returns should not be used as [[JDatabase]]::getQuery provides for formatted output. However, indenting with spaces to improve readability is desireable.

Queries should be wrapped in single quotes (as these text blocks are parsed faster by php).

All quoted strings must use the ''Quote'' method to facilitate future compatibility with other database engines.

All table names should use the '''<tt>#_</tt>''' prefix rather than <tt>jos_</tt> to access Joomla! contents and allow for the [[screen.config.15#Database_Settings|user defined database prefix]] to be applied.

All expected integer or floating-point variable must be [http://php.net/manual/language.types.type-juggling.php cast] with <tt>(int)</tt>, <tt>(float)</tt> or <tt>(double)</tt> as appropriate.

<source lang="php">
$state = 1;
$name = 'bill';
$db = &JFactory::getDBO();
$query = 'SELECT COUNT( c.id ) AS num_articles, u.id, u.username'.
' FROM #__content AS c'.
' LEFT JOIN #__users AS u ON u.id = c.created_by'.
' WHERE c.state = '.(int) $state
' AND u.id IS NOT NULL'.
' AND u.username <> '.$db->Quote( $name ).
' GROUP BY u.id'.
' HAVING COUNT( c.id ) > 0';
$db->setQuery();
// Output formated query if joomla debug is active:
if (JDEBUG) {
echo $db->getQuery();
}
$stats = $db->loadObjectList();
</source>

=== Doc Blocks ===

All source code files in the core Joomla distribution must contain the following comment block as the header:

<source lang="php">
<?php
/**
* @version $Id$
* @package Joomla
* @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.
* @license GNU/GPL, see LICENSE.php
*/
</source>

The <code>@package</code> in the header is not required for class-only files.

Classes, functions, constants, class properties and class methods should all be supplied with appropriate DocBlocks.

<source lang="php">
/**
* Short description for class
*
* Long description for class (if any)...
*
* @package PackageName
* @subpackage SubPackageName
* @link http://pear.php.net/package/PackageName
* @see NetOther, Net_Sample::Net_Sample()
* @since Class available since Release 1.2.0
* @deprecated Class deprecated in Release 2.0.0
*/
class JFooBar
{
/**
* @var int $id Primary key
*/
public $id = null;
}
</source>

The following package names are to be used in the core stack:

* Joomla.Administrator - all files that belong only to the administrator or backend application
* Joomla.Installation - all files that belong to the installation application
* Joomla.Plugin - all plugin files
* Joomla.Site - all files that pertain only to the site or frontend application
* Joomla.XML-RPC - all files that belong to the XML-RPC server application

The sub-package name will vary according to the extension type:

* Components - the component folder, eg <code>com_content</code>
* Modules - the module folder, eg <code>mod_latest_news</code>
* Plugins - the folder.element, eg <code>content.pagebreak</code>
* Templates - the template folder, eg <code>rhuk_milkyway</code>
* Framework - nothing for top level files (such as <code>factory.php</code>), the first level folder or the first.second level folders as appropriate, eg <code>utilities</code> for <code>joomla/utilities/date.php</code>, <code>html.html</code> for <code>joomla/html/html/email.php</code>

Please note that code contributed to the Joomla stack that will become the copyright of the project is not allowed to include <code>@author</code> tags. You should update the contribution log in <tt>CREDITS.php</tt>. Joomla's philosophy is that the code is written "all together" and there is no notion of any one person 'owning' any section of code.

Files included from third party sources must leave DocBlocks intact. Layout files use the same DocBlocks as other PHP files.

Note that the "@version $Id" line uses the SVN "keywords=Id" property. See [[Subversion File Properties]] for information about setting this property.

== Naming Conventions ==

=== Classes ===

Classes should be given descriptive names. Avoid using abbreviations where possible. Class names should always begin with an uppercase letter and be written in CamelCase even if using traditionally uppercase acronyms (such as XML, HTML). One exception is for Joomla framework classes which must begin with an uppercase 'J' with the next letter also being uppercase. For example:

* JHtmlHelper
* JXmlParser
* JModel

Third-party developers are advised to namespace their functions with a unique prefix.

=== Functions and Methods ===

Functions and methods should be named using the "studly caps" style (also referred to as "bumpy case" or "camel caps"). The initial letter of the name is lowercase, and each letter that starts a new "word" is capitalized. Function in the Joomla framework must begin with a lowercase 'j'. Some examples:

<source lang="php">
connect();
getData();
buildSomeWidget();
jImport();
jDoSomething();
</source>

Private class members (meaning class members that are intended to be used only from within the same class in which they are declared; are preceded by a single underscore. Properties are to be written in underscore format (that is, logical words separated by underscores) and should be all lowercase. For example:

<source lang="php">
class JFooBar
{
// Joomla 1.5 and earlier format
var $_status = null;

function _sort()
{
}

// Joomla 1.6 format
private $_status = null;

protected $field_name = null;

protected function _sort()
{
}
}
</source>

=== Constants ===

Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercase name of the class/package they are used in. For example, the constants used by the [[JError]] class all begin with "JERROR_".

=== Global Variables ===

If your package needs to define global variables, their name should start with a single underscore followed by the uppercase class/package name and another underscore. For example, the JError class uses a global variable called $_JERROR_LEVELS.

With PHP5 and later you may use static class properties or constants instead of globals.
<source lang="php">
<?php
class JWhatever
{
public static $instance = null;
const SUCCESS = 1;
const FAILURE = 0;
// Methods...
}
</source>

=== Regular and Class Variables ===

Regular variables, follow the same conventions as function.

Class variables should be set to null or some other appropriate default value. Lining up the default values with tabs should only be used if particularly warranted for readability.

=== References ===

When using references, there should be a space before the reference operator and no space between it and the function or variable name. For example:

<source lang="php">
<?php
$ref1 = &$this->_sql;
$db = &JFactory::getDBO();
</source>

=== Language Keys ===

NOTE: This part has to be rewritten for 1.6 (JM)

Except for the most common of words, such as "Yes", "No", "Show", "Hide" all language keys should be namespaced to reflect the type of string they represent. Always consider that if two extensions use the same key, the one loaded last will be the one that displays. Namespacing should generally relate to the extension displaying the text. For example:

<source lang="php"><?php
echo JText::_('Weblink Link');
echo JText::_('Weblink Title');
echo JText::_('Weblink Description');

echo JText::_('Exception An error occurred while saving');
?></source>

TODO: Link to page with "common" strings that can be used for typical actions in components, such a "Save"

Where the same English word is used in two different locations, two different language keys should be used to allow for cases where the translation results in different words or phrases.

<source lang="php">
// A table column title
<th><?php echo JText::_('Weblink Column Title');?></th>
<th><?php echo JText::_('Weblink Column Link');?></th>

// In the form
<?php echo JText::_('Weblink Title');?><input name="title" />
<?php echo JText::_('Weblink Link');?><input name="link" />
</source>

Toolbar and Linkbar text should be prefixed Toolbar and Linkbar respectively.

The language keys should be written as naturally as possible with spaces, not underscores separating words. Long phrases can be condensed to reduce keys to a sensible length. For example, tooltips for an edit field can be written like this:

<source lang="php">
<?php echo JText::_('Weblink Title');?><input name="title" title="<?php echo JText::_('Weblink Title Desc');?>" />
</source>

The convention used should be governed by common sense, but must be consistent. In general consider how the language file will look with all keys sorted alphabetically. Prefixes should be used to group text within a common context (such as column headings). Suffixes should be used to group elements that logically go together (such as a field name and its description).

Phrases must never be assembled by string concatenation. Each phrase must be represented by a single language key, using sprintf as appropriate to replace dynamic words in the phrase. Where replacements are made, the word used should be as descriptive as possible and all-uppercase. This assists the translators to determine the context of the replacement.

<source lang="php"><?php
// Not permitted
echo JText::_('Deleted ').$n.JText::_(' items');

// Permitted
echo JText::sprintf('Message Deleted NUMBER items', $n);
?></source>

The reference in the language file would look like this:

<source lang="php">MESSAGE DELETED NUMBER ITEMS=Deleted %d Item(s)</source>

If more than one dynamic string is used in a phrase, the printf markers should employ order placement as other languages might change the position of the strings. This is done via %[number]$[printf_type] as follows:

Left to right language:

<source lang="php">PAGE X OF Y=Page %1$d of %2$d</source>

Right to left language:

<source lang="php">PAGE X OF Y=%2$d of %1$d egaP</source>

=== Controllers ===

For single controller components, the naming convention is ''[Name]Controller''.

<source lang="php">
<?php
/**
* Content Controller
* @package Joomla
*/
class ContentController extends JController
{
// Methods
}
</source>
The file name will generally be ''controller.php'' and is located in the component folder.
<source lang="text">
com_content
/ controller.php
</source>

For a multi-controller components, such as the Banners in the Administrator, the convention is ''[Component]Controller[Name]''.

<source lang="php">
<?php
/**
* Banner Client Controller
* @package Joomla
*/
class BannerControllerClient extends JController
{
// Methods
}
</source>

The files will be located in a <tt>/controllers/</tt> folder under the component folder. The file names will reflect the name of the controller.
<source lang="text">
com_banner
/controllers/
/ banner.php
/ client.php
</source>

=== Models===

The naming convention is ''[Component]Model[Name]''.

<source lang="php">
<?php
/**
* Banner Client Model
* @package Joomla
*/
class BannerModelClient extends JModel
{
// Methods
}
?>
</source>

The files will be located in a <tt>/models/</tt> folder under the component folder. The file names will reflect the name of the model.

<source lang="text">
com_banner
/models/
/ banner.php
/ client.php
</source>

=== Views ===
The naming convention is ''[Component]View[Name]''.
<source lang="php">
<?php
/**
* Contact Category View
* @package Joomla
*/
class ContactViewCategory extends JView
{
// Methods
}
?>
</source>
The files will be located in a <tt>/view/</tt> folder under the component folder. The subfolder names will reflect the name of a View.

com_contact
/views/
/''view name 1''/
/ view.html.php
/''view name 2''/
/ view.html.php

Multi-view components such as com_content may provide an optional "master" view class the specialised views extend from. It is located in the component folder and typically called ''view.php''. The naming convention is ''[Component]View''.

com_content
/views/
<span style="color:#999">/archive/</span>
/ view.html.php
<span style="color:#999">/article/</span>
/ view.php

<source lang="php">
view.php
<?php
/**
* Content View
* @package Joomla
*/
class ContentView extends JView
{
// Helper Methods
}
?>

views/archive/view.html.php
<?php
/**
* Content Archive View
* @package Joomla
*/
class ContactViewArchive extends ContentView
{
// Methods
}
?>
</source>

=== Plugins ===

The naming convention is ''plg[Folder][Element]'' as pointed out in [[How to create a content plugin|the relative HowTo page]].

<source lang="php">
class plgContentPagebreak extends JPlugin
{
// Methods
}
?>
</source>

=== Layouts ===
Components may support different Layouts to render the data supplied by a [[#Views|View]] and its [[#Models|Models]]. A Layout file usually contains markup and some PHP code for ''display logic only'': no functions, no classes.

A Layout consists of at least one .php file and an equally named [[Creating a basic layout.xml file|.xml manifest file]] located in the <tt>/tmpl/</tt> folder of a View, both reflect the internal name of the Layout. The standard Layout is called ''default''.

<span style="color:#999">com_content
/views/
/article/</span><span style="color:#000">
/tmpl/
/ default.php
/ default.xml
/ form.php
/ form.xml
/ pagebreak.php
/ pagebreak.xml </span>

The Layout may use supplemental .php files to provide more granule control in order to render individual parts or repetitive items of the data.

Users may customize the Layout output via [[#Template Layout Overrides|Template Layout Overrides]].

=== Templates ===

=== Template Layout Overrides ===

Unit Test Tutorial 2

2010-04-20T03:12:42Z

Ian: /* Looking at the Unit Test Class */

== Looking at the Unit Test Class ==

In our first unit test, we create a single test. This test was a part of a presumed preexisting test class. Although an individual test can be contained in a single method, these methods have to be a part of a test class.

Unit Test classes generally inherit from the class 'PHPUnit_Framework_TestCase'.

You can see a basic test class below:
<source lang="php">
<?php
/**
* @version $Id$
* @copyright Copyright (C) 2005 - 2010 Open Source Matters. All rights reserved.
* @license GNU General Public License version 2 or later; see LICENSE.txt
*/

require_once JPATH_BASE.'/libraries/joomla/utilities/arrayhelper.php';

/**
* Test class for JArrayHelper.
*/
class JArrayHelperTest extends PHPUnit_Framework_TestCase {

/**
* Sets up the fixture, for example, opens a network connection.
* This method is called before a test is executed.
*
* @access protected
*/
protected function setUp() {

}

/**
* Tears down the fixture, for example, closes a network connection.
* This method is called after a test is executed.
*
* @access protected
*/
protected function tearDown() {

}

/**
* Simple Test for getColumn method.
*/
public function testGetColumn()
{
$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
),
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);

$result_array = JArrayHelper::getColumn($test_array, 'country');

$this->assertThat(
$result_array,
$this->equalTo(
array('United States', 'Germany', 'Canada')
),
'We did not get the proper column data back'
);
}
}
</source>

Okay, so some notes:

* As noted, the class extends from PHPUnit_Framework_TestCase
* Outside of our class, we do a require for the class that we want to test
* Our class name starts with the name of the class we want to test and has 'Test' appended to the end. i.e. we are testing JArrayHelper, so our test class is JArrayHelperTest.
* We have two methods that are not part of our tests: setUp() and tearDown(). As noted in the comments for these methods, setUp() is called before each test and tearDown() is called after each test. To clarify, if there are 10 tests in a class, they are each called ten times. There are two other methods available that you can supply: setUpBeforeClass() and tearDownAfterClass(). As the names imply, these are each called before and after all the tests from the class are performed, thus getting executed once each.
* Test methods start with the word test and generally end with the name of the method that is under test. We are testing the getColumn() method, therefore, our method is called testGetColumn(). As methods get more complicated, more than one method is required for testing. In this situation, method names that describe the general purpose of the method should be used.

Unit Test Tutorial 2

2010-04-19T04:08:35Z

Ian: New page: == Looking at the Unit Test Class == In our first unit test, we create a single test. This test was a part of a presumed preexisting test class. Although an individual test can be conta...

Running Unit Tests

2010-04-19T02:56:36Z

Ian: New page: == Running the Entire Test Suite == The entire test suite can be run by simply entering the test directory and typing phpunit: <pre> cd /path/to/joomla/tests/unit phpunit </pre> == Sp...

== Running the Entire Test Suite ==

The entire test suite can be run by simply entering the test directory and typing phpunit:

<pre>
cd /path/to/joomla/tests/unit
phpunit
</pre>

== Specifying a Directory of Tests to Run ==

You can run a subset of tests by specifying the directory path of the tests that you want to run.

<pre>phpunit suite/libraries/joomla/utilities</pre>

Will run all of the tests in the specified directory and any subdirectory.

== Using the --filter Parameter to Run Certain Tests ==

The --filter parameter allows you to run a specific subset of the entire test suite. The --filter parameter takes a regular expression that can be used to filter out tests.

<pre>phpunit --filter JForm</pre>

Will scan through the suite directory and run tests that contain JForm in the class name or in the method name.

Unit Test Tutorial 1

2010-04-19T02:44:24Z

Ian: /* Running Tests */

= Unit Testing and Joomla! =

As we move forward with Joomla! Development one element that is going to be playing a larger and larger role is unit testing. My hope with this short series is to provide some basic background on unit testing, to demonstrate how essential unit tests are to stable software and to give practical instruction and examples that illustrate how to write unit tests.

As co-maintainer of the Joomla! Bug Squad, there is a question that repeatedly pops up: 'What is this change going to break?'. There are certain elements of the code base that can be rather fragile and this makes it very difficult to know what things are safe to touch and what things aren't. The component routers are a good example of this. We are very very hesitant to touch this because many people are very particular about their URLs, and past experience has shown that small changes can cause significant, unforeseen problems.

Good unit tests take a great deal of the anxiety out of such changes because you can be confident that the change you are introducing is not going to have nasty, unforeseen consequences.

== What is Unit Testing? ==

In its purest form, unit tests are tests that are designed to ensure that small units of code behave as they are intended. Pure unit testing means that each method is tested in isolation from all other methods. That is to say, for example, that if we are writing a test for JApplication, and JApplication happens to use the JDatabase class, we want to try and design our tests such that a bug in the JDatabase class won't affect our test written for the JApplication class.

In practice, this can be difficult because sometimes class references are hardcoded. Static methods are very difficult in this regard because you can't redefine classes and all tests in PHPUnit are executed in the same process.

On the other end of the scale is system testing. System tests are tests that are written to test a system as a whole. In these tests, the goal isn't to isolate particular units of code. Rather, it is to ensure that all the parts work together in the way they were intended. For web applications, these tests are often developed using a product called Selenium which allows you to control a web browser in order to simulate a user actually using your web application.

== Installing PHPUnit ==

We are slowing building up an extensive suite of unit tests for the Joomla! Framework. The tests are built on a unit testing framework called PHPUnit. In order to run the tests, you need to obtain PHPUnit.
To get PHPUnit, head over to [http://www.phpunit.de/manual/current/en/installation.html PHPUnit Installation] and follow the instructions to install PHPUnit.

== Running Tests ==

Unit tests are typically run from the command line. While this may be daunting for some, once you get the hang of things it is actually quite easy.
Once you have PHPUnit installed and your path setup correctly, it is as simple as changing to the unit test directory and typing 'phpunit':
cd /path/to/joomla/tests/unit
phpunit
After you run this command, you should see output that looks something like:

<pre>PHPUnit 3.4.11 by Sebastian Bergmann.

IIIIIIIIIIIIIIIIIIIII...III..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 60 / 2207
III...SIIIIII.IIIIIIIIIIIIII....................F.IIIIIIIIII 120 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 180 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 240 / 2207
IIIIIIIIIIIIIII.......................I.I...FFFFFEEEEEEEEEE. 300 / 2207
....FFFFF.EEEIIIIIIIII...IIIFFFFF.....SSSSFSSSSSSFSSSSSSSSSS 360 / 2207
SSSSSFSS......IIF.SFFFFFFF.......I........I................. 420 / 2207
.........III.II.IIII.IIII.I.........I.IIIII.IIII..........II 480 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 540 / 2207
IIIIIIIIIIIIIIIII.IIIIIIIIIIIIIII........................... 600 / 2207
...IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 660 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIII.................................. 720 / 2207
....................................................FFFF.... 780 / 2207
............................................................ 840 / 2207
............................................................ 900 / 2207
............................................................ 960 / 2207
............................................IIIIIIIIIIIIIIII 1020 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1080 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1140 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1200 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1260 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1320 / 2207
IIIIIIIIIIIIIIIIIIII...I.....II.IIIIIIIIIIIIIIIIIIIIIIIIIIII 1380 / 2207
IIIIIIIIIIIIII.IIIIIIIIIII.........IIIIII.IIIIIIIIIIIIIIIIII 1440 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..II.............. 1500 / 2207
.........F.F...........F..FFF................II....I...F..II 1560 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1620 / 2207
IIIIIIIIIIIIIIIIIII...F........IIIIIIIIIIIIIIIIIIIIIIIIIIIII 1680 / 2207
IIIIIIIIIIIIII..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII........... 1740 / 2207
...F........................................................ 1800 / 2207
............................................................ 1860 / 2207
............................................................ 1920 / 2207
............................................................ 1980 / 2207
............................................................ 2040 / 2207
.........................F.................................. 2100 / 2207
............................F............................... 2160 / 2207
...............................F..I............

Time: 14 seconds, Memory: 89.50Mb

There were 13 errors:

1) JCacheTest::testSetCaching with data set "simple" ('output', array())
Undefined property: JCacheControllerOutput::$_options

2) JCacheTest::testSetCaching with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerOutput::$_options

3) JCacheTest::testSetCaching with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerPage::$_options

...

--

There were 43 failures:

1) JControllerFormTest::testConstructor
_asset_name has not been defined for structure
Failed asserting that an array has the key <string:_asset_name>.

2) JCacheTest::testGetInstance with data set "simple" ('output', array(), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

3) JCacheTest::testGetInstance with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

4) JCacheTest::testGetInstance with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCachePage')
Failed asserting that <JCacheControllerPage> is an instance of class "JCachePage".

...

FAILURES!
Tests: 2207, Assertions: 1751, Failures: 43, Errors: 13, Incomplete: 1063, Skipped: 29.
</pre>

There are many situations where you may not want to run the whole test suite. See the [[Running Unit Tests]] page for details on how to be selective with the tests that you run.

== Anatomy of a Test ==

Unit tests are merely small chunks of PHP code that:
# Setup certain preconditions for the code to be tested (inputs).
# Execute the code to be tested.
# Tests assertions about the results (outputs).

We will see these basic elements in each of the example tests that are provided below.

== Writing Our First Test ==

The easiest and most simple type of unit test to write is a test for code that is stateless. That is, a test for which the return value of the method depends solely on the inputs to the method. Most of the basic PHP functions are examples of stateless functions. The strtoupper function, for example, takes one parameter – a string – and returns a string value. You can easily create a set of inputs and corresponding outputs and write a test.
Examples in the Joomla! Framework include much of the JArrayHelper class. Most of these methods are static methods and don't depend on anything except the data passed to the method. For this example, we will use the JArrayHelper::getColumn method. This method takes two parameters and returns an array.
So, following the three steps outlined above, we break things down into three elements:

=== 1. Setup Preconditions ===

In this case, there are no preconditions because our method does not depend on anything other than the parameters that are passed to it. Our only preconditions are the parameters that we pass to the method.

=== 2. Execute the code to be tested ===

So, our method in question will take an array of associative arrays or objects and will return an array of the values of the specified index.
So, to test our method, we first need to create an array of associative arrays:

<source lang="php">$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
).
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);</source>

Now we execute the method and retrieve the results:

<source lang="php">$result_array = JArrayHelper::getColumn($test_array, 'country');</source>

We have now executed the method we want to test. We can now examine the results.

=== 3. Tests assertions about the results (outputs) ===

Since this method is fairly simple, testing the results is also simple. What we need to do is figure out what we expect to get back from the method. In this case, we expect to get an array containing an array of the countries.

<source lang="php">$this->assertThat(
$result_array,
$this->equalTo(array('United States', 'Germany', 'Canada')),
'We did not get the proper column data back'
);</source>

Our final test looks like:
<source lang="php">
public function testGetColumnTutorial()
{
$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
),
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);

$result_array = JArrayHelper::getColumn($test_array, 'country');

$this->assertThat(
$result_array,
$this->equalTo(
array('United States', 'Germany', 'Canada')
),
'We did not get the proper column data back'
);
}
</source>

Unit Test Tutorial 1

2010-04-19T02:43:44Z

Ian: /* Running Tests */

= Unit Testing and Joomla! =

As we move forward with Joomla! Development one element that is going to be playing a larger and larger role is unit testing. My hope with this short series is to provide some basic background on unit testing, to demonstrate how essential unit tests are to stable software and to give practical instruction and examples that illustrate how to write unit tests.

As co-maintainer of the Joomla! Bug Squad, there is a question that repeatedly pops up: 'What is this change going to break?'. There are certain elements of the code base that can be rather fragile and this makes it very difficult to know what things are safe to touch and what things aren't. The component routers are a good example of this. We are very very hesitant to touch this because many people are very particular about their URLs, and past experience has shown that small changes can cause significant, unforeseen problems.

Good unit tests take a great deal of the anxiety out of such changes because you can be confident that the change you are introducing is not going to have nasty, unforeseen consequences.

== What is Unit Testing? ==

In its purest form, unit tests are tests that are designed to ensure that small units of code behave as they are intended. Pure unit testing means that each method is tested in isolation from all other methods. That is to say, for example, that if we are writing a test for JApplication, and JApplication happens to use the JDatabase class, we want to try and design our tests such that a bug in the JDatabase class won't affect our test written for the JApplication class.

In practice, this can be difficult because sometimes class references are hardcoded. Static methods are very difficult in this regard because you can't redefine classes and all tests in PHPUnit are executed in the same process.

On the other end of the scale is system testing. System tests are tests that are written to test a system as a whole. In these tests, the goal isn't to isolate particular units of code. Rather, it is to ensure that all the parts work together in the way they were intended. For web applications, these tests are often developed using a product called Selenium which allows you to control a web browser in order to simulate a user actually using your web application.

== Installing PHPUnit ==

We are slowing building up an extensive suite of unit tests for the Joomla! Framework. The tests are built on a unit testing framework called PHPUnit. In order to run the tests, you need to obtain PHPUnit.
To get PHPUnit, head over to [http://www.phpunit.de/manual/current/en/installation.html PHPUnit Installation] and follow the instructions to install PHPUnit.

== Running Tests ==

Unit tests are typically run from the command line. While this may be daunting for some, once you get the hang of things it is actually quite easy.
Once you have PHPUnit installed and your path setup correctly, it is as simple as changing to the unit test directory and typing 'phpunit':
cd /path/to/joomla/tests/unit
phpunit
After you run this command, you should see output that looks something like:

<pre>PHPUnit 3.4.11 by Sebastian Bergmann.

IIIIIIIIIIIIIIIIIIIII...III..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 60 / 2207
III...SIIIIII.IIIIIIIIIIIIII....................F.IIIIIIIIII 120 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 180 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 240 / 2207
IIIIIIIIIIIIIII.......................I.I...FFFFFEEEEEEEEEE. 300 / 2207
....FFFFF.EEEIIIIIIIII...IIIFFFFF.....SSSSFSSSSSSFSSSSSSSSSS 360 / 2207
SSSSSFSS......IIF.SFFFFFFF.......I........I................. 420 / 2207
.........III.II.IIII.IIII.I.........I.IIIII.IIII..........II 480 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 540 / 2207
IIIIIIIIIIIIIIIII.IIIIIIIIIIIIIII........................... 600 / 2207
...IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 660 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIII.................................. 720 / 2207
....................................................FFFF.... 780 / 2207
............................................................ 840 / 2207
............................................................ 900 / 2207
............................................................ 960 / 2207
............................................IIIIIIIIIIIIIIII 1020 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1080 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1140 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1200 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1260 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1320 / 2207
IIIIIIIIIIIIIIIIIIII...I.....II.IIIIIIIIIIIIIIIIIIIIIIIIIIII 1380 / 2207
IIIIIIIIIIIIII.IIIIIIIIIII.........IIIIII.IIIIIIIIIIIIIIIIII 1440 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..II.............. 1500 / 2207
.........F.F...........F..FFF................II....I...F..II 1560 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1620 / 2207
IIIIIIIIIIIIIIIIIII...F........IIIIIIIIIIIIIIIIIIIIIIIIIIIII 1680 / 2207
IIIIIIIIIIIIII..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII........... 1740 / 2207
...F........................................................ 1800 / 2207
............................................................ 1860 / 2207
............................................................ 1920 / 2207
............................................................ 1980 / 2207
............................................................ 2040 / 2207
.........................F.................................. 2100 / 2207
............................F............................... 2160 / 2207
...............................F..I............

Time: 14 seconds, Memory: 89.50Mb

There were 13 errors:

1) JCacheTest::testSetCaching with data set "simple" ('output', array())
Undefined property: JCacheControllerOutput::$_options

2) JCacheTest::testSetCaching with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerOutput::$_options

3) JCacheTest::testSetCaching with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerPage::$_options

...

--

There were 43 failures:

1) JControllerFormTest::testConstructor
_asset_name has not been defined for structure
Failed asserting that an array has the key <string:_asset_name>.

2) JCacheTest::testGetInstance with data set "simple" ('output', array(), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

3) JCacheTest::testGetInstance with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

4) JCacheTest::testGetInstance with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCachePage')
Failed asserting that <JCacheControllerPage> is an instance of class "JCachePage".

...

FAILURES!
Tests: 2207, Assertions: 1751, Failures: 43, Errors: 13, Incomplete: 1063, Skipped: 29.
</pre>

There are many situations where you may not want to run the whole test suite. See the [Running Unit Tests] page for details on how to be selective with the tests that you run.

== Anatomy of a Test ==

Unit tests are merely small chunks of PHP code that:
# Setup certain preconditions for the code to be tested (inputs).
# Execute the code to be tested.
# Tests assertions about the results (outputs).

We will see these basic elements in each of the example tests that are provided below.

== Writing Our First Test ==

The easiest and most simple type of unit test to write is a test for code that is stateless. That is, a test for which the return value of the method depends solely on the inputs to the method. Most of the basic PHP functions are examples of stateless functions. The strtoupper function, for example, takes one parameter – a string – and returns a string value. You can easily create a set of inputs and corresponding outputs and write a test.
Examples in the Joomla! Framework include much of the JArrayHelper class. Most of these methods are static methods and don't depend on anything except the data passed to the method. For this example, we will use the JArrayHelper::getColumn method. This method takes two parameters and returns an array.
So, following the three steps outlined above, we break things down into three elements:

=== 1. Setup Preconditions ===

In this case, there are no preconditions because our method does not depend on anything other than the parameters that are passed to it. Our only preconditions are the parameters that we pass to the method.

=== 2. Execute the code to be tested ===

So, our method in question will take an array of associative arrays or objects and will return an array of the values of the specified index.
So, to test our method, we first need to create an array of associative arrays:

<source lang="php">$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
).
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);</source>

Now we execute the method and retrieve the results:

<source lang="php">$result_array = JArrayHelper::getColumn($test_array, 'country');</source>

We have now executed the method we want to test. We can now examine the results.

=== 3. Tests assertions about the results (outputs) ===

Since this method is fairly simple, testing the results is also simple. What we need to do is figure out what we expect to get back from the method. In this case, we expect to get an array containing an array of the countries.

<source lang="php">$this->assertThat(
$result_array,
$this->equalTo(array('United States', 'Germany', 'Canada')),
'We did not get the proper column data back'
);</source>

Our final test looks like:
<source lang="php">
public function testGetColumnTutorial()
{
$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
),
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);

$result_array = JArrayHelper::getColumn($test_array, 'country');

$this->assertThat(
$result_array,
$this->equalTo(
array('United States', 'Germany', 'Canada')
),
'We did not get the proper column data back'
);
}
</source>

Unit Test Tutorial 1

2010-04-19T02:40:15Z

Ian: /* 3. Tests assertions about the results (outputs) */

= Unit Testing and Joomla! =

As we move forward with Joomla! Development one element that is going to be playing a larger and larger role is unit testing. My hope with this short series is to provide some basic background on unit testing, to demonstrate how essential unit tests are to stable software and to give practical instruction and examples that illustrate how to write unit tests.

As co-maintainer of the Joomla! Bug Squad, there is a question that repeatedly pops up: 'What is this change going to break?'. There are certain elements of the code base that can be rather fragile and this makes it very difficult to know what things are safe to touch and what things aren't. The component routers are a good example of this. We are very very hesitant to touch this because many people are very particular about their URLs, and past experience has shown that small changes can cause significant, unforeseen problems.

Good unit tests take a great deal of the anxiety out of such changes because you can be confident that the change you are introducing is not going to have nasty, unforeseen consequences.

== What is Unit Testing? ==

In its purest form, unit tests are tests that are designed to ensure that small units of code behave as they are intended. Pure unit testing means that each method is tested in isolation from all other methods. That is to say, for example, that if we are writing a test for JApplication, and JApplication happens to use the JDatabase class, we want to try and design our tests such that a bug in the JDatabase class won't affect our test written for the JApplication class.

In practice, this can be difficult because sometimes class references are hardcoded. Static methods are very difficult in this regard because you can't redefine classes and all tests in PHPUnit are executed in the same process.

On the other end of the scale is system testing. System tests are tests that are written to test a system as a whole. In these tests, the goal isn't to isolate particular units of code. Rather, it is to ensure that all the parts work together in the way they were intended. For web applications, these tests are often developed using a product called Selenium which allows you to control a web browser in order to simulate a user actually using your web application.

== Installing PHPUnit ==

We are slowing building up an extensive suite of unit tests for the Joomla! Framework. The tests are built on a unit testing framework called PHPUnit. In order to run the tests, you need to obtain PHPUnit.
To get PHPUnit, head over to [http://www.phpunit.de/manual/current/en/installation.html PHPUnit Installation] and follow the instructions to install PHPUnit.

== Running Tests ==

Unit tests are typically run from the command line. While this may be daunting for some, once you get the hang of things it is actually quite easy.
Once you have PHPUnit installed and your path setup correctly, it is as simple as changing to the unit test directory and typing 'phpunit':
cd /path/to/joomla/tests/unit
phpunit
After you run this command, you should see output that looks something like:

<pre>PHPUnit 3.4.11 by Sebastian Bergmann.

IIIIIIIIIIIIIIIIIIIII...III..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 60 / 2207
III...SIIIIII.IIIIIIIIIIIIII....................F.IIIIIIIIII 120 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 180 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 240 / 2207
IIIIIIIIIIIIIII.......................I.I...FFFFFEEEEEEEEEE. 300 / 2207
....FFFFF.EEEIIIIIIIII...IIIFFFFF.....SSSSFSSSSSSFSSSSSSSSSS 360 / 2207
SSSSSFSS......IIF.SFFFFFFF.......I........I................. 420 / 2207
.........III.II.IIII.IIII.I.........I.IIIII.IIII..........II 480 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 540 / 2207
IIIIIIIIIIIIIIIII.IIIIIIIIIIIIIII........................... 600 / 2207
...IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 660 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIII.................................. 720 / 2207
....................................................FFFF.... 780 / 2207
............................................................ 840 / 2207
............................................................ 900 / 2207
............................................................ 960 / 2207
............................................IIIIIIIIIIIIIIII 1020 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1080 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1140 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1200 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1260 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1320 / 2207
IIIIIIIIIIIIIIIIIIII...I.....II.IIIIIIIIIIIIIIIIIIIIIIIIIIII 1380 / 2207
IIIIIIIIIIIIII.IIIIIIIIIII.........IIIIII.IIIIIIIIIIIIIIIIII 1440 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..II.............. 1500 / 2207
.........F.F...........F..FFF................II....I...F..II 1560 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1620 / 2207
IIIIIIIIIIIIIIIIIII...F........IIIIIIIIIIIIIIIIIIIIIIIIIIIII 1680 / 2207
IIIIIIIIIIIIII..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII........... 1740 / 2207
...F........................................................ 1800 / 2207
............................................................ 1860 / 2207
............................................................ 1920 / 2207
............................................................ 1980 / 2207
............................................................ 2040 / 2207
.........................F.................................. 2100 / 2207
............................F............................... 2160 / 2207
...............................F..I............

Time: 14 seconds, Memory: 89.50Mb

There were 13 errors:

1) JCacheTest::testSetCaching with data set "simple" ('output', array())
Undefined property: JCacheControllerOutput::$_options

2) JCacheTest::testSetCaching with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerOutput::$_options

3) JCacheTest::testSetCaching with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerPage::$_options

...

--

There were 43 failures:

1) JControllerFormTest::testConstructor
_asset_name has not been defined for structure
Failed asserting that an array has the key <string:_asset_name>.

2) JCacheTest::testGetInstance with data set "simple" ('output', array(), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

3) JCacheTest::testGetInstance with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

4) JCacheTest::testGetInstance with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCachePage')
Failed asserting that <JCacheControllerPage> is an instance of class "JCachePage".

...

FAILURES!
Tests: 2207, Assertions: 1751, Failures: 43, Errors: 13, Incomplete: 1063, Skipped: 29.
</pre>

== Anatomy of a Test ==

Unit tests are merely small chunks of PHP code that:
# Setup certain preconditions for the code to be tested (inputs).
# Execute the code to be tested.
# Tests assertions about the results (outputs).

We will see these basic elements in each of the example tests that are provided below.

== Writing Our First Test ==

The easiest and most simple type of unit test to write is a test for code that is stateless. That is, a test for which the return value of the method depends solely on the inputs to the method. Most of the basic PHP functions are examples of stateless functions. The strtoupper function, for example, takes one parameter – a string – and returns a string value. You can easily create a set of inputs and corresponding outputs and write a test.
Examples in the Joomla! Framework include much of the JArrayHelper class. Most of these methods are static methods and don't depend on anything except the data passed to the method. For this example, we will use the JArrayHelper::getColumn method. This method takes two parameters and returns an array.
So, following the three steps outlined above, we break things down into three elements:

=== 1. Setup Preconditions ===

In this case, there are no preconditions because our method does not depend on anything other than the parameters that are passed to it. Our only preconditions are the parameters that we pass to the method.

=== 2. Execute the code to be tested ===

So, our method in question will take an array of associative arrays or objects and will return an array of the values of the specified index.
So, to test our method, we first need to create an array of associative arrays:

<source lang="php">$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
).
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);</source>

Now we execute the method and retrieve the results:

<source lang="php">$result_array = JArrayHelper::getColumn($test_array, 'country');</source>

We have now executed the method we want to test. We can now examine the results.

=== 3. Tests assertions about the results (outputs) ===

Since this method is fairly simple, testing the results is also simple. What we need to do is figure out what we expect to get back from the method. In this case, we expect to get an array containing an array of the countries.

<source lang="php">$this->assertThat(
$result_array,
$this->equalTo(array('United States', 'Germany', 'Canada')),
'We did not get the proper column data back'
);</source>

Our final test looks like:
<source lang="php">
public function testGetColumnTutorial()
{
$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
),
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);

$result_array = JArrayHelper::getColumn($test_array, 'country');

$this->assertThat(
$result_array,
$this->equalTo(
array('United States', 'Germany', 'Canada')
),
'We did not get the proper column data back'
);
}
</source>

Unit Test Tutorial 1

2010-04-19T02:39:02Z

Ian: /* 3. Tests assertions about the results (outputs) */

= Unit Testing and Joomla! =

As we move forward with Joomla! Development one element that is going to be playing a larger and larger role is unit testing. My hope with this short series is to provide some basic background on unit testing, to demonstrate how essential unit tests are to stable software and to give practical instruction and examples that illustrate how to write unit tests.

As co-maintainer of the Joomla! Bug Squad, there is a question that repeatedly pops up: 'What is this change going to break?'. There are certain elements of the code base that can be rather fragile and this makes it very difficult to know what things are safe to touch and what things aren't. The component routers are a good example of this. We are very very hesitant to touch this because many people are very particular about their URLs, and past experience has shown that small changes can cause significant, unforeseen problems.

Good unit tests take a great deal of the anxiety out of such changes because you can be confident that the change you are introducing is not going to have nasty, unforeseen consequences.

== What is Unit Testing? ==

In its purest form, unit tests are tests that are designed to ensure that small units of code behave as they are intended. Pure unit testing means that each method is tested in isolation from all other methods. That is to say, for example, that if we are writing a test for JApplication, and JApplication happens to use the JDatabase class, we want to try and design our tests such that a bug in the JDatabase class won't affect our test written for the JApplication class.

In practice, this can be difficult because sometimes class references are hardcoded. Static methods are very difficult in this regard because you can't redefine classes and all tests in PHPUnit are executed in the same process.

On the other end of the scale is system testing. System tests are tests that are written to test a system as a whole. In these tests, the goal isn't to isolate particular units of code. Rather, it is to ensure that all the parts work together in the way they were intended. For web applications, these tests are often developed using a product called Selenium which allows you to control a web browser in order to simulate a user actually using your web application.

== Installing PHPUnit ==

We are slowing building up an extensive suite of unit tests for the Joomla! Framework. The tests are built on a unit testing framework called PHPUnit. In order to run the tests, you need to obtain PHPUnit.
To get PHPUnit, head over to [http://www.phpunit.de/manual/current/en/installation.html PHPUnit Installation] and follow the instructions to install PHPUnit.

== Running Tests ==

Unit tests are typically run from the command line. While this may be daunting for some, once you get the hang of things it is actually quite easy.
Once you have PHPUnit installed and your path setup correctly, it is as simple as changing to the unit test directory and typing 'phpunit':
cd /path/to/joomla/tests/unit
phpunit
After you run this command, you should see output that looks something like:

<pre>PHPUnit 3.4.11 by Sebastian Bergmann.

IIIIIIIIIIIIIIIIIIIII...III..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 60 / 2207
III...SIIIIII.IIIIIIIIIIIIII....................F.IIIIIIIIII 120 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 180 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 240 / 2207
IIIIIIIIIIIIIII.......................I.I...FFFFFEEEEEEEEEE. 300 / 2207
....FFFFF.EEEIIIIIIIII...IIIFFFFF.....SSSSFSSSSSSFSSSSSSSSSS 360 / 2207
SSSSSFSS......IIF.SFFFFFFF.......I........I................. 420 / 2207
.........III.II.IIII.IIII.I.........I.IIIII.IIII..........II 480 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 540 / 2207
IIIIIIIIIIIIIIIII.IIIIIIIIIIIIIII........................... 600 / 2207
...IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 660 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIII.................................. 720 / 2207
....................................................FFFF.... 780 / 2207
............................................................ 840 / 2207
............................................................ 900 / 2207
............................................................ 960 / 2207
............................................IIIIIIIIIIIIIIII 1020 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1080 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1140 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1200 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1260 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1320 / 2207
IIIIIIIIIIIIIIIIIIII...I.....II.IIIIIIIIIIIIIIIIIIIIIIIIIIII 1380 / 2207
IIIIIIIIIIIIII.IIIIIIIIIII.........IIIIII.IIIIIIIIIIIIIIIIII 1440 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..II.............. 1500 / 2207
.........F.F...........F..FFF................II....I...F..II 1560 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1620 / 2207
IIIIIIIIIIIIIIIIIII...F........IIIIIIIIIIIIIIIIIIIIIIIIIIIII 1680 / 2207
IIIIIIIIIIIIII..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII........... 1740 / 2207
...F........................................................ 1800 / 2207
............................................................ 1860 / 2207
............................................................ 1920 / 2207
............................................................ 1980 / 2207
............................................................ 2040 / 2207
.........................F.................................. 2100 / 2207
............................F............................... 2160 / 2207
...............................F..I............

Time: 14 seconds, Memory: 89.50Mb

There were 13 errors:

1) JCacheTest::testSetCaching with data set "simple" ('output', array())
Undefined property: JCacheControllerOutput::$_options

2) JCacheTest::testSetCaching with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerOutput::$_options

3) JCacheTest::testSetCaching with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerPage::$_options

...

--

There were 43 failures:

1) JControllerFormTest::testConstructor
_asset_name has not been defined for structure
Failed asserting that an array has the key <string:_asset_name>.

2) JCacheTest::testGetInstance with data set "simple" ('output', array(), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

3) JCacheTest::testGetInstance with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

4) JCacheTest::testGetInstance with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCachePage')
Failed asserting that <JCacheControllerPage> is an instance of class "JCachePage".

...

FAILURES!
Tests: 2207, Assertions: 1751, Failures: 43, Errors: 13, Incomplete: 1063, Skipped: 29.
</pre>

== Anatomy of a Test ==

Unit tests are merely small chunks of PHP code that:
# Setup certain preconditions for the code to be tested (inputs).
# Execute the code to be tested.
# Tests assertions about the results (outputs).

We will see these basic elements in each of the example tests that are provided below.

== Writing Our First Test ==

The easiest and most simple type of unit test to write is a test for code that is stateless. That is, a test for which the return value of the method depends solely on the inputs to the method. Most of the basic PHP functions are examples of stateless functions. The strtoupper function, for example, takes one parameter – a string – and returns a string value. You can easily create a set of inputs and corresponding outputs and write a test.
Examples in the Joomla! Framework include much of the JArrayHelper class. Most of these methods are static methods and don't depend on anything except the data passed to the method. For this example, we will use the JArrayHelper::getColumn method. This method takes two parameters and returns an array.
So, following the three steps outlined above, we break things down into three elements:

=== 1. Setup Preconditions ===

In this case, there are no preconditions because our method does not depend on anything other than the parameters that are passed to it. Our only preconditions are the parameters that we pass to the method.

=== 2. Execute the code to be tested ===

So, our method in question will take an array of associative arrays or objects and will return an array of the values of the specified index.
So, to test our method, we first need to create an array of associative arrays:

<source lang="php">$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
).
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);</source>

Now we execute the method and retrieve the results:

<source lang="php">$result_array = JArrayHelper::getColumn($test_array, 'country');</source>

We have now executed the method we want to test. We can now examine the results.

=== 3. Tests assertions about the results (outputs) ===

Since this method is fairly simple, testing the results is also simple. What we need to do is figure out what we expect to get back from the method. In this case, we expect to get an array containing an array of the countries.

<source lang="php">$this->assertThat(
$result_array,
$this->equalTo(array('United States', 'Germany', 'Canada')),
'We did not get the proper column data back'
);</source>

Our final test looks like:
<source lang="php">
public function testGetColumnTutorial()
{
$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
),
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);
$result_array = JArrayHelper::getColumn($test_array, 'country');
$this->assertThat(
$result_array,
$this->equalTo(
array('United States', 'Germany', 'Canada')
),
'We did not get the proper column data back'
);
}
</source>

Unit Test Tutorial 1

2010-04-19T02:38:27Z

Ian: /* 3. Tests assertions about the results (outputs) */

= Unit Testing and Joomla! =

As we move forward with Joomla! Development one element that is going to be playing a larger and larger role is unit testing. My hope with this short series is to provide some basic background on unit testing, to demonstrate how essential unit tests are to stable software and to give practical instruction and examples that illustrate how to write unit tests.

As co-maintainer of the Joomla! Bug Squad, there is a question that repeatedly pops up: 'What is this change going to break?'. There are certain elements of the code base that can be rather fragile and this makes it very difficult to know what things are safe to touch and what things aren't. The component routers are a good example of this. We are very very hesitant to touch this because many people are very particular about their URLs, and past experience has shown that small changes can cause significant, unforeseen problems.

Good unit tests take a great deal of the anxiety out of such changes because you can be confident that the change you are introducing is not going to have nasty, unforeseen consequences.

== What is Unit Testing? ==

In its purest form, unit tests are tests that are designed to ensure that small units of code behave as they are intended. Pure unit testing means that each method is tested in isolation from all other methods. That is to say, for example, that if we are writing a test for JApplication, and JApplication happens to use the JDatabase class, we want to try and design our tests such that a bug in the JDatabase class won't affect our test written for the JApplication class.

In practice, this can be difficult because sometimes class references are hardcoded. Static methods are very difficult in this regard because you can't redefine classes and all tests in PHPUnit are executed in the same process.

On the other end of the scale is system testing. System tests are tests that are written to test a system as a whole. In these tests, the goal isn't to isolate particular units of code. Rather, it is to ensure that all the parts work together in the way they were intended. For web applications, these tests are often developed using a product called Selenium which allows you to control a web browser in order to simulate a user actually using your web application.

== Installing PHPUnit ==

We are slowing building up an extensive suite of unit tests for the Joomla! Framework. The tests are built on a unit testing framework called PHPUnit. In order to run the tests, you need to obtain PHPUnit.
To get PHPUnit, head over to [http://www.phpunit.de/manual/current/en/installation.html PHPUnit Installation] and follow the instructions to install PHPUnit.

== Running Tests ==

Unit tests are typically run from the command line. While this may be daunting for some, once you get the hang of things it is actually quite easy.
Once you have PHPUnit installed and your path setup correctly, it is as simple as changing to the unit test directory and typing 'phpunit':
cd /path/to/joomla/tests/unit
phpunit
After you run this command, you should see output that looks something like:

<pre>PHPUnit 3.4.11 by Sebastian Bergmann.

IIIIIIIIIIIIIIIIIIIII...III..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 60 / 2207
III...SIIIIII.IIIIIIIIIIIIII....................F.IIIIIIIIII 120 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 180 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 240 / 2207
IIIIIIIIIIIIIII.......................I.I...FFFFFEEEEEEEEEE. 300 / 2207
....FFFFF.EEEIIIIIIIII...IIIFFFFF.....SSSSFSSSSSSFSSSSSSSSSS 360 / 2207
SSSSSFSS......IIF.SFFFFFFF.......I........I................. 420 / 2207
.........III.II.IIII.IIII.I.........I.IIIII.IIII..........II 480 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 540 / 2207
IIIIIIIIIIIIIIIII.IIIIIIIIIIIIIII........................... 600 / 2207
...IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 660 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIII.................................. 720 / 2207
....................................................FFFF.... 780 / 2207
............................................................ 840 / 2207
............................................................ 900 / 2207
............................................................ 960 / 2207
............................................IIIIIIIIIIIIIIII 1020 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1080 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1140 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1200 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1260 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1320 / 2207
IIIIIIIIIIIIIIIIIIII...I.....II.IIIIIIIIIIIIIIIIIIIIIIIIIIII 1380 / 2207
IIIIIIIIIIIIII.IIIIIIIIIII.........IIIIII.IIIIIIIIIIIIIIIIII 1440 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..II.............. 1500 / 2207
.........F.F...........F..FFF................II....I...F..II 1560 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1620 / 2207
IIIIIIIIIIIIIIIIIII...F........IIIIIIIIIIIIIIIIIIIIIIIIIIIII 1680 / 2207
IIIIIIIIIIIIII..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII........... 1740 / 2207
...F........................................................ 1800 / 2207
............................................................ 1860 / 2207
............................................................ 1920 / 2207
............................................................ 1980 / 2207
............................................................ 2040 / 2207
.........................F.................................. 2100 / 2207
............................F............................... 2160 / 2207
...............................F..I............

Time: 14 seconds, Memory: 89.50Mb

There were 13 errors:

1) JCacheTest::testSetCaching with data set "simple" ('output', array())
Undefined property: JCacheControllerOutput::$_options

2) JCacheTest::testSetCaching with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerOutput::$_options

3) JCacheTest::testSetCaching with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerPage::$_options

...

--

There were 43 failures:

1) JControllerFormTest::testConstructor
_asset_name has not been defined for structure
Failed asserting that an array has the key <string:_asset_name>.

2) JCacheTest::testGetInstance with data set "simple" ('output', array(), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

3) JCacheTest::testGetInstance with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

4) JCacheTest::testGetInstance with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCachePage')
Failed asserting that <JCacheControllerPage> is an instance of class "JCachePage".

...

FAILURES!
Tests: 2207, Assertions: 1751, Failures: 43, Errors: 13, Incomplete: 1063, Skipped: 29.
</pre>

== Anatomy of a Test ==

Unit tests are merely small chunks of PHP code that:
# Setup certain preconditions for the code to be tested (inputs).
# Execute the code to be tested.
# Tests assertions about the results (outputs).

We will see these basic elements in each of the example tests that are provided below.

== Writing Our First Test ==

The easiest and most simple type of unit test to write is a test for code that is stateless. That is, a test for which the return value of the method depends solely on the inputs to the method. Most of the basic PHP functions are examples of stateless functions. The strtoupper function, for example, takes one parameter – a string – and returns a string value. You can easily create a set of inputs and corresponding outputs and write a test.
Examples in the Joomla! Framework include much of the JArrayHelper class. Most of these methods are static methods and don't depend on anything except the data passed to the method. For this example, we will use the JArrayHelper::getColumn method. This method takes two parameters and returns an array.
So, following the three steps outlined above, we break things down into three elements:

=== 1. Setup Preconditions ===

In this case, there are no preconditions because our method does not depend on anything other than the parameters that are passed to it. Our only preconditions are the parameters that we pass to the method.

=== 2. Execute the code to be tested ===

So, our method in question will take an array of associative arrays or objects and will return an array of the values of the specified index.
So, to test our method, we first need to create an array of associative arrays:

<source lang="php">$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
).
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);</source>

Now we execute the method and retrieve the results:

<source lang="php">$result_array = JArrayHelper::getColumn($test_array, 'country');</source>

We have now executed the method we want to test. We can now examine the results.

=== 3. Tests assertions about the results (outputs) ===

Since this method is fairly simple, testing the results is also simple. What we need to do is figure out what we expect to get back from the method. In this case, we expect to get an array containing an array of the countries.

<source lang="php">$this->assertThat(
$result_array,
$this->equalTo(array('United States', 'Germany', 'Canada')),
'We did not get the proper column data back'
);</source>

Our final test looks like:
<source lang="php">
public function testGetColumnTutorial()
{
$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
),
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);
$result_array = JArrayHelper::getColumn($test_array, 'country');
$this->assertThat(
$result_array,
$this->equalTo(
array('United States', 'Germany', 'Canada')
),
'We did not get the proper column data back'
);

}
</source>

Unit Test Tutorial 1

2010-04-19T02:33:56Z

Ian: /* 1. Setup Preconditions */

= Unit Testing and Joomla! =

As we move forward with Joomla! Development one element that is going to be playing a larger and larger role is unit testing. My hope with this short series is to provide some basic background on unit testing, to demonstrate how essential unit tests are to stable software and to give practical instruction and examples that illustrate how to write unit tests.

As co-maintainer of the Joomla! Bug Squad, there is a question that repeatedly pops up: 'What is this change going to break?'. There are certain elements of the code base that can be rather fragile and this makes it very difficult to know what things are safe to touch and what things aren't. The component routers are a good example of this. We are very very hesitant to touch this because many people are very particular about their URLs, and past experience has shown that small changes can cause significant, unforeseen problems.

Good unit tests take a great deal of the anxiety out of such changes because you can be confident that the change you are introducing is not going to have nasty, unforeseen consequences.

== What is Unit Testing? ==

In its purest form, unit tests are tests that are designed to ensure that small units of code behave as they are intended. Pure unit testing means that each method is tested in isolation from all other methods. That is to say, for example, that if we are writing a test for JApplication, and JApplication happens to use the JDatabase class, we want to try and design our tests such that a bug in the JDatabase class won't affect our test written for the JApplication class.

In practice, this can be difficult because sometimes class references are hardcoded. Static methods are very difficult in this regard because you can't redefine classes and all tests in PHPUnit are executed in the same process.

On the other end of the scale is system testing. System tests are tests that are written to test a system as a whole. In these tests, the goal isn't to isolate particular units of code. Rather, it is to ensure that all the parts work together in the way they were intended. For web applications, these tests are often developed using a product called Selenium which allows you to control a web browser in order to simulate a user actually using your web application.

== Installing PHPUnit ==

We are slowing building up an extensive suite of unit tests for the Joomla! Framework. The tests are built on a unit testing framework called PHPUnit. In order to run the tests, you need to obtain PHPUnit.
To get PHPUnit, head over to [http://www.phpunit.de/manual/current/en/installation.html PHPUnit Installation] and follow the instructions to install PHPUnit.

== Running Tests ==

Unit tests are typically run from the command line. While this may be daunting for some, once you get the hang of things it is actually quite easy.
Once you have PHPUnit installed and your path setup correctly, it is as simple as changing to the unit test directory and typing 'phpunit':
cd /path/to/joomla/tests/unit
phpunit
After you run this command, you should see output that looks something like:

<pre>PHPUnit 3.4.11 by Sebastian Bergmann.

IIIIIIIIIIIIIIIIIIIII...III..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 60 / 2207
III...SIIIIII.IIIIIIIIIIIIII....................F.IIIIIIIIII 120 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 180 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 240 / 2207
IIIIIIIIIIIIIII.......................I.I...FFFFFEEEEEEEEEE. 300 / 2207
....FFFFF.EEEIIIIIIIII...IIIFFFFF.....SSSSFSSSSSSFSSSSSSSSSS 360 / 2207
SSSSSFSS......IIF.SFFFFFFF.......I........I................. 420 / 2207
.........III.II.IIII.IIII.I.........I.IIIII.IIII..........II 480 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 540 / 2207
IIIIIIIIIIIIIIIII.IIIIIIIIIIIIIII........................... 600 / 2207
...IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 660 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIII.................................. 720 / 2207
....................................................FFFF.... 780 / 2207
............................................................ 840 / 2207
............................................................ 900 / 2207
............................................................ 960 / 2207
............................................IIIIIIIIIIIIIIII 1020 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1080 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1140 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1200 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1260 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1320 / 2207
IIIIIIIIIIIIIIIIIIII...I.....II.IIIIIIIIIIIIIIIIIIIIIIIIIIII 1380 / 2207
IIIIIIIIIIIIII.IIIIIIIIIII.........IIIIII.IIIIIIIIIIIIIIIIII 1440 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..II.............. 1500 / 2207
.........F.F...........F..FFF................II....I...F..II 1560 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1620 / 2207
IIIIIIIIIIIIIIIIIII...F........IIIIIIIIIIIIIIIIIIIIIIIIIIIII 1680 / 2207
IIIIIIIIIIIIII..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII........... 1740 / 2207
...F........................................................ 1800 / 2207
............................................................ 1860 / 2207
............................................................ 1920 / 2207
............................................................ 1980 / 2207
............................................................ 2040 / 2207
.........................F.................................. 2100 / 2207
............................F............................... 2160 / 2207
...............................F..I............

Time: 14 seconds, Memory: 89.50Mb

There were 13 errors:

1) JCacheTest::testSetCaching with data set "simple" ('output', array())
Undefined property: JCacheControllerOutput::$_options

2) JCacheTest::testSetCaching with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerOutput::$_options

3) JCacheTest::testSetCaching with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerPage::$_options

...

--

There were 43 failures:

1) JControllerFormTest::testConstructor
_asset_name has not been defined for structure
Failed asserting that an array has the key <string:_asset_name>.

2) JCacheTest::testGetInstance with data set "simple" ('output', array(), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

3) JCacheTest::testGetInstance with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

4) JCacheTest::testGetInstance with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCachePage')
Failed asserting that <JCacheControllerPage> is an instance of class "JCachePage".

...

FAILURES!
Tests: 2207, Assertions: 1751, Failures: 43, Errors: 13, Incomplete: 1063, Skipped: 29.
</pre>

== Anatomy of a Test ==

Unit tests are merely small chunks of PHP code that:
# Setup certain preconditions for the code to be tested (inputs).
# Execute the code to be tested.
# Tests assertions about the results (outputs).

We will see these basic elements in each of the example tests that are provided below.

== Writing Our First Test ==

The easiest and most simple type of unit test to write is a test for code that is stateless. That is, a test for which the return value of the method depends solely on the inputs to the method. Most of the basic PHP functions are examples of stateless functions. The strtoupper function, for example, takes one parameter – a string – and returns a string value. You can easily create a set of inputs and corresponding outputs and write a test.
Examples in the Joomla! Framework include much of the JArrayHelper class. Most of these methods are static methods and don't depend on anything except the data passed to the method. For this example, we will use the JArrayHelper::getColumn method. This method takes two parameters and returns an array.
So, following the three steps outlined above, we break things down into three elements:

=== 1. Setup Preconditions ===

In this case, there are no preconditions because our method does not depend on anything other than the parameters that are passed to it. Our only preconditions are the parameters that we pass to the method.

=== 2. Execute the code to be tested ===

So, our method in question will take an array of associative arrays or objects and will return an array of the values of the specified index.
So, to test our method, we first need to create an array of associative arrays:

<source lang="php">$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
).
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);</source>

Now we execute the method and retrieve the results:

<source lang="php">$result_array = JArrayHelper::getColumn($test_array, 'country');</source>

We have now executed the method we want to test. We can now examine the results.

=== 3. Tests assertions about the results (outputs) ===

Since this method is fairly simple, testing the results is also simple. What we need to do is figure out what we expect to get back from the method. In this case, we expect to get an array containing an array of the countries.

<source lang="php">$this->assertThat(
$result_array,
$this->equalTo(array('United States', 'Germany', 'Canada')),
'We did not get the proper column data back'
);</source>

Unit Test Tutorial 1

2010-04-19T02:33:04Z

Ian: New page: = Unit Testing and Joomla! = As we move forward with Joomla! Development one element that is going to be playing a larger and larger role is unit testing. My hope with this short series...

= Unit Testing and Joomla! =

As we move forward with Joomla! Development one element that is going to be playing a larger and larger role is unit testing. My hope with this short series is to provide some basic background on unit testing, to demonstrate how essential unit tests are to stable software and to give practical instruction and examples that illustrate how to write unit tests.

As co-maintainer of the Joomla! Bug Squad, there is a question that repeatedly pops up: 'What is this change going to break?'. There are certain elements of the code base that can be rather fragile and this makes it very difficult to know what things are safe to touch and what things aren't. The component routers are a good example of this. We are very very hesitant to touch this because many people are very particular about their URLs, and past experience has shown that small changes can cause significant, unforeseen problems.

Good unit tests take a great deal of the anxiety out of such changes because you can be confident that the change you are introducing is not going to have nasty, unforeseen consequences.

== What is Unit Testing? ==

In its purest form, unit tests are tests that are designed to ensure that small units of code behave as they are intended. Pure unit testing means that each method is tested in isolation from all other methods. That is to say, for example, that if we are writing a test for JApplication, and JApplication happens to use the JDatabase class, we want to try and design our tests such that a bug in the JDatabase class won't affect our test written for the JApplication class.

In practice, this can be difficult because sometimes class references are hardcoded. Static methods are very difficult in this regard because you can't redefine classes and all tests in PHPUnit are executed in the same process.

On the other end of the scale is system testing. System tests are tests that are written to test a system as a whole. In these tests, the goal isn't to isolate particular units of code. Rather, it is to ensure that all the parts work together in the way they were intended. For web applications, these tests are often developed using a product called Selenium which allows you to control a web browser in order to simulate a user actually using your web application.

== Installing PHPUnit ==

We are slowing building up an extensive suite of unit tests for the Joomla! Framework. The tests are built on a unit testing framework called PHPUnit. In order to run the tests, you need to obtain PHPUnit.
To get PHPUnit, head over to [http://www.phpunit.de/manual/current/en/installation.html PHPUnit Installation] and follow the instructions to install PHPUnit.

== Running Tests ==

Unit tests are typically run from the command line. While this may be daunting for some, once you get the hang of things it is actually quite easy.
Once you have PHPUnit installed and your path setup correctly, it is as simple as changing to the unit test directory and typing 'phpunit':
cd /path/to/joomla/tests/unit
phpunit
After you run this command, you should see output that looks something like:

<pre>PHPUnit 3.4.11 by Sebastian Bergmann.

IIIIIIIIIIIIIIIIIIIII...III..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 60 / 2207
III...SIIIIII.IIIIIIIIIIIIII....................F.IIIIIIIIII 120 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 180 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 240 / 2207
IIIIIIIIIIIIIII.......................I.I...FFFFFEEEEEEEEEE. 300 / 2207
....FFFFF.EEEIIIIIIIII...IIIFFFFF.....SSSSFSSSSSSFSSSSSSSSSS 360 / 2207
SSSSSFSS......IIF.SFFFFFFF.......I........I................. 420 / 2207
.........III.II.IIII.IIII.I.........I.IIIII.IIII..........II 480 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 540 / 2207
IIIIIIIIIIIIIIIII.IIIIIIIIIIIIIII........................... 600 / 2207
...IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 660 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIII.................................. 720 / 2207
....................................................FFFF.... 780 / 2207
............................................................ 840 / 2207
............................................................ 900 / 2207
............................................................ 960 / 2207
............................................IIIIIIIIIIIIIIII 1020 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1080 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1140 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1200 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1260 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1320 / 2207
IIIIIIIIIIIIIIIIIIII...I.....II.IIIIIIIIIIIIIIIIIIIIIIIIIIII 1380 / 2207
IIIIIIIIIIIIII.IIIIIIIIIII.........IIIIII.IIIIIIIIIIIIIIIIII 1440 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..II.............. 1500 / 2207
.........F.F...........F..FFF................II....I...F..II 1560 / 2207
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 1620 / 2207
IIIIIIIIIIIIIIIIIII...F........IIIIIIIIIIIIIIIIIIIIIIIIIIIII 1680 / 2207
IIIIIIIIIIIIII..IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII........... 1740 / 2207
...F........................................................ 1800 / 2207
............................................................ 1860 / 2207
............................................................ 1920 / 2207
............................................................ 1980 / 2207
............................................................ 2040 / 2207
.........................F.................................. 2100 / 2207
............................F............................... 2160 / 2207
...............................F..I............

Time: 14 seconds, Memory: 89.50Mb

There were 13 errors:

1) JCacheTest::testSetCaching with data set "simple" ('output', array())
Undefined property: JCacheControllerOutput::$_options

2) JCacheTest::testSetCaching with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerOutput::$_options

3) JCacheTest::testSetCaching with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/unittest/cache', 900, 'file'))
Undefined property: JCacheControllerPage::$_options

...

--

There were 43 failures:

1) JControllerFormTest::testConstructor
_asset_name has not been defined for structure
Failed asserting that an array has the key <string:_asset_name>.

2) JCacheTest::testGetInstance with data set "simple" ('output', array(), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

3) JCacheTest::testGetInstance with data set "complexOutput" ('output', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCacheOutput')
Failed asserting that <JCacheControllerOutput> is an instance of class "JCacheOutput".

4) JCacheTest::testGetInstance with data set "complexPage" ('page', array('', '/home/ian/www/ut_work/tests/unit/cache', 900, 'file'), 'JCachePage')
Failed asserting that <JCacheControllerPage> is an instance of class "JCachePage".

...

FAILURES!
Tests: 2207, Assertions: 1751, Failures: 43, Errors: 13, Incomplete: 1063, Skipped: 29.
</pre>

== Anatomy of a Test ==

Unit tests are merely small chunks of PHP code that:
# Setup certain preconditions for the code to be tested (inputs).
# Execute the code to be tested.
# Tests assertions about the results (outputs).

We will see these basic elements in each of the example tests that are provided below.

== Writing Our First Test ==

The easiest and most simple type of unit test to write is a test for code that is stateless. That is, a test for which the return value of the method depends solely on the inputs to the method. Most of the basic PHP functions are examples of stateless functions. The strtoupper function, for example, takes one parameter – a string – and returns a string value. You can easily create a set of inputs and corresponding outputs and write a test.
Examples in the Joomla! Framework include much of the JArrayHelper class. Most of these methods are static methods and don't depend on anything except the data passed to the method. For this example, we will use the JArrayHelper::getColumn method. This method takes two parameters and returns an array.
So, following the three steps outlined above, we break things down into three elements:

=== 1. Setup Preconditions ===

In this case, there are no preconditions because our method does not depend on anything other than the parameters that are passed to it. Our only preconditions are the parameters that we pass to the method.

=== 2. Execute the code to be tested

So, our method in question will take an array of associative arrays or objects and will return an array of the values of the specified index.
So, to test our method, we first need to create an array of associative arrays:

<source lang="php">$test_array = array(
array(
'sport' => 'football',
'teams' => '16',
'country' => 'United States'
).
array(
'sport' => 'badminton',
'teams' => '12',
'country' => 'Germany'
),
array(
'sport' => 'basketball',
'teams' => '20',
'country' => 'Canada'
)
);</source>

Now we execute the method and retrieve the results:

<source lang="php">$result_array = JArrayHelper::getColumn($test_array, 'country');</source>

We have now executed the method we want to test. We can now examine the results.

=== 3. Tests assertions about the results (outputs) ===

Since this method is fairly simple, testing the results is also simple. What we need to do is figure out what we expect to get back from the method. In this case, we expect to get an array containing an array of the countries.

<source lang="php">$this->assertThat(
$result_array,
$this->equalTo(array('United States', 'Germany', 'Canada')),
'We did not get the proper column data back'
);</source>

Portal:Administrators

2010-03-10T17:43:10Z

Ian: Reverted edits by Louisakusnandar (Talk) to last version by E-builds

{{RightTOC}}
{{Administrator profile}}

==Joomla! Administrator's Manual==
Note from the Doc Team: At the present time we are assembling an outline "content plan" for this document. What you see is not complete and is subject to change as we re-organise stuff and develop our thinking of what should be included and where it should be placed. The intention is that the list of topics you see below should be goal-orientated and not a "feature list" for the Administrator back-end. The items should address real and common activities that an Administrator will need to perform from time to time. Please feel free to help us by adding items you think should be included or amending items already present if you think they can be improved.

===Managing the Website===
* [[taking the website temporarily offline]]
* [[changing the appearance of your site]]
* [[giving the Front Page a different style from other pages]]
* [[changing the style according to article section or category]]
* [[logging in or out of the Administrator back-end]]
* [[making your site Search Engine Friendly]]
* [[entering search engine meta-data]]
* [[moving the site among directories/sub-directories]]

===Managing Users===
* [[setting user registration policy]]
** [[changing user registration settings]]
** [[disabling user registration]]
** [[allowing only manual user registration]]
** [[allowing user registration]]
** [[restricting user access to resources]]
* [[customising the Login Form module]]
** [[changing the Login Form module settings]]
** [[enabling the Login Form module]]
** [[assigning the Login Form module to selected web pages]]
** [[customising the information shown in the Login Form module]]
* [[adding a new user]]
* [[changing user groups]]
* [[resetting a user password]]
* [[listing a user on a contacts page]]
* [[dealing with a problem user]]
* [[sending an email to a user]]
* [[sending an email to a group of users]]
* [[sending a private message to a user]]
* [[reading a private message from a user]]

===Access Control===
* [[ACL Tutorial for Joomla 1.6]] {{JVer|1.6}}

===Managing Content===
* [[understanding sections, categories and articles]]
* [[creating a section and category hierarchy]]
* [[scheduling an Article to be available only between certain dates]]
* [[restricting access to an Article]]
* [[restricting access to "read more"]]
* [[restricting access to a Section]]
* [[restricting access to a Category]]
* [[removing email, print or PDF icons from all Articles]]
* [[removing author name, creation date or update date from all Articles]]
* [[moving an Article to the archive]]
* [[deleting an Article]]

===Managing Articles===
* [[adding a new article]]
* [[adding an image to an article]]
* [[adding a menu item which points to an Article]]
* [[managing the front page]]

===Editing an Article===
* [[inserting a heading into an Article]]
* [[inserting a list into an Article]]
* [[inserting a table into an Article]]
* [[modifying a table in an Article]]
* [[inserting a link to another Article or content page into an Article]]
* [[inserting a link to another website into an Article]]
* [[removing a link from an Article]]
* [[splitting an Article into an introduction with a link to read more]]
* [[removing email, print or PDF icons from an Article]]
* [[removing author name, creation date or update date from an Article]]
* [[previewing an Article]]
* [[splitting a long Article into multiple linked pages]]

===Managing Menus===
* [[adding a new menu]]
* [[adding a new menu item]]
* [[changing the order of items in a menu]]
* [[moving a menu to a different position]]
* [[restricting access to a Menu]]
* [[restricting access to a Menu Item]]
* [[Tutorial: Creating a submenu | creating a submenu]]

===Managing Contacts===
* [[restricting access to a Contact]]
* [[restricting access to a Contact Category]]

===Managing Newsfeeds===
* [[restricting access to a Newsfeed Category]]

===Managing Polls===
* [[adding a new Poll]]

===Managing Web Links===
* [[restricting access to a Web Links Category]]

===Managing Extensions===
* [[finding an extension]]
* [[installing an extension]]
* [[uninstalling an extension]]
* reinstalling deleted core extensions for [[Reinstalling deleted Joomla 1.5 core extensions|Joomla 1.5]] and [[Reinstalling deleted Joomla 1.0 core extensions|Joomla 1.0]]
* [[restricting access to a Module]]
* [[restricting access to a Plugin]]

===Tips, tricks and performance===
* Speed up your site with caching: [[Cache]]

==Joomla Security Guide==
Administrators should also be aware of security issues.
{{Security Guide}}

Start here

2010-03-10T17:42:21Z

Ian: Reverted edits by Louisakusnandar (Talk) to last version by Dextercowley

To make it easy to find the information you need, read the profiles below and choose the one that most accurately describes your current role. This will take you to an area where the documentation is organised according to the goals that you are most likely to require help with. There is a lot of overlap in the documentation for each of these roles; they are not mutually exclusive; so just choose one that seems to be nearest to your own role even if the fit is not exact. To make these user profiles more concrete and so help writers to target the material more accurately, we are looking at creating [[personas]] for each of the profiles.
;[[Beginners]]
:{{Beginner profile}}
;[[Evaluators]]
:{{Evaluators}}
;[[Content creators]]
:{{Content creator profile}}
;[[Editors]]
:{{Editor profile}}
;[[Publishers]]
:{{Publisher profile}}
;[[Administrators]]
:{{Administrator profile}}
;[[Web designers]]
:{{Web designer profile}}
;[[Web developers]]
:{{Web developer profile}}
;[[Developers]]
:{{Developer profile}}
;[[Testers]]
:{{Tester profile}}
;[[Translators]]
:{{Translator profile}}
;[[Trainers]]
:{{Trainer profile}}
;[[Documentors]]
:{{Documentor profile}}

System Testing

2010-02-11T14:47:25Z

Ian: /* Joomla Core Selenium testcases */

== News and Updates ==
2009 07 27 Document created.

== Functional Testing ==
Functional (or system) testing is an essential part of a good Quality Control program.
For a good general discussion of functional testing, visit the [http://en.wikipedia.org/wiki/Functional_Testing Wikipedia article].

=== Functional Testing in Open Source ===
Web applications have been notoriously difficult to do functional testing with. It has traditionally required a great deal of time and effort. This can be a special challenge for open source projects because testing is often not very popular and designing tests that can be executed in a systematic way even less so. For a complicated application like Joomla!, this means that although we might do testing, we very seldom are able to perform extensive testing on each release that covers even a fraction of the elements in the CMS.

Relatively recently, a project called Selenium has arrived on the scene. This project makes performing automated functional testing of web applications possible. This means that it is possible to devise a test and have it performed in an automated way without the requirement of somebody sitting in front of a browser and being a click monkey.

The benefits of functional testing are:
* Functional tests help highlight cases where changes in one element of the system might cause breakage in other, unexpected areas.
* Functional tests help clearly specify how the application should behave.

=== Functional Testing versus Unit Testing ===
In order to fully test an application, both functional and unit testing are essential. Each approach has their benefits and weaknesses. Unit testing is very good for isolating small chunks of code and ensuring that they are behaving as expected. Functional testing, on the other hand, is geared towards looking at the system as a whole and ensuring that the units are behaving together in a way that achieves the desired effect.

The advantages of functional testing is that functional tests are easier to understand and conceptualize by people who are unfamiliar with the underlying code. With Selenium, tests can be designed by people who are not overly familiar with PHP - they only need to understand the application and what results should be expected.

The downside of functional testing is that it will only tell you that something broke. It isn't as obvious with functional testing exactly what went wrong or where the problem is.

==== Test Objects ====
If the purpose of unit tests is to isolate a module of code, then the purpose of functional tests is to evaluate the entire system. This is much easier for those unfamiliar with what happens under the hood of Joomla! because one is not required to understand what happens during a Joomla! page request. A functional test might evaluate, for example, if unpublishing an article works properly. Therefore, to design the test, it is only necessary to figure out how to change an article from Published to Unpublished, and how to verify that the article was actually unpublished.

=== Functional Testing in Joomla! ===
I have recently been building a functional testing architecture that will make it possible to write tests once, and to execute those tests on a variety of platforms and clients. I currently have infrastructure in place that makes it possible to run one command and execute functional tests in one browser on one host system. I have designed the host system in such a way that it will run on 6 different PHP versions (stock Ubuntu PHP 5 and self-compiled PHP 4.3, 4.4, 5.0, 5.1 and 5.2) and 2 different web servers (Apache and Lighttpd). These are all currently serving from the same database.

The future steps will be to make it possible to run on multiple host systems (the requirement for this is to generalize the code that resets the database state after the tests are run) and to make it possible to use different clients (i.e. different systems with different web browsers). These steps should be fairly trivial, but I have not yet had time to focus on them.

This will eventually make it possible to run the designed tests on every major browser and on multiple server platforms (various PHP versions, various configurations, various operating systems and various web servers).

==== Writing Functional Tests ====
Selenium IDE makes it fairly easy to write functional tests. It is a Firefox extension that operates as an Integrated Development Environment for creating functional tests. In essence, it records your clicks as you navigate in your browser and encodes them into a series of commands that can control the browser.

===== Getting Selenium IDE =====
At the time of writing, the latest version of Selenium IDE is 1.0.2. You can get it at http://seleniumhq.org/download/. Click on the download link and install like you would any Firefox plugin.

===== Preparing your Environment =====
To get started, create a vanilla install of Joomla! with the standard sample data.

===== Creating a Basic Test =====
To start, open Firefox and browse to the home page of your Joomla! install. I setup my install on my localhost, and so the URL is http://127.0.0.1/selsampledata.

Then, click on Tools -> Selenium IDE. You will notice that on the right of the window that appears near the top, that there is a red circle that is highlighted. This is the start/stop recording button. When you start Selenium IDE, recording starts right away.

For our first test, all we will do is load up the home page and check to make sure that all the items in the Main Menu are present.

The commands that we use to check that items are present are called assertions. Basically, you perform your actions and make assertions about the results.

In our case, we are going to use the command assertText. This command will read the text of a specified element and ensure it matches a particular value.

So, first ensure that the Base URL displayed in the Selenium IDE window is the home page of your Joomla! install.

Then, switch to the window that has your Joomla install open.

In that window, right click on each menu item and select 'Assert Text'.

Then, switch to your Selenium IDE window and click the Red Button to stop recording.

You should see two tabs in your Selenium IDE window - one labeled Table, and one labeled Source. You don't really need to look at the Source window.

So, now our first test is done.

To run your test, you use the icons on the bar between the Base URL address bar and the Table and Source tabs. The two important buttons are the buttons with the Green Triangle with Three Solid rectangles and the one with the Green Triangle and One Solid Rectangle. The first one will execute the entire test suite and the second one will run the currently selected test case. Since we currently have only one test case, both of these currently do the same thing.

To run your test, press one of these buttons.

As you watch the Selenium IDE, you will see a yellow bar move down your list of steps. Once a step is completed, a successfully executed action (i.e. a button was successfully located and clicked) should show up in light green and a successful assertion should show up in darker green. Failed actions show up in light red and failed assertions show up in darker red.

Click on the Window Expander on the left to unhide the Test Case browser.

If your test completed successfully, you should see Runs: 1, Failures: 0 at the bottom of the Test Case browser.

==== Running Functional Tests ====

=== Joomla Core Selenium testcases ===
The testing repository for the Selenium test suite for version 1.5 can be found here:

* [http://joomlacode.org/svn/joomla/development/releases/1.5/tests/system/ http://joomlacode.org/svn/joomla/development/releases/1.5/tests/system/]

As of February 2010, the unit and functional tests for version1.6 have been incorporated into the SVN trunk under a folder called "tests". More information about running the version 1.6 tests is available in the article [[Running Automated Tests for Version 1.6]].

Note: If a login mask comes up, use </br>
:User: anonymous </br>
:Password: <empty>

== How to Get it Running ==

== Troubleshooting ==

== Frequently Asked Questions ==

==See also==
For writing a more advanced Selenium testcase see [http://docs.joomla.org/Intermediate_Selenium_Example here].

[http://seleniumhq.org/docs/ Selenium documentation].

[[Category:Development]]
[[Category:Testing]]
[[Category:Bug Squad]]

Functional Testing

2010-02-11T14:44:51Z

Ian: Functional Testing moved to System Testing

#REDIRECT [[System Testing]]

System Testing

2010-02-11T14:44:51Z

Ian: Functional Testing moved to System Testing

== News and Updates ==
2009 07 27 Document created.

== Functional Testing ==
Functional (or system) testing is an essential part of a good Quality Control program.
For a good general discussion of functional testing, visit the [http://en.wikipedia.org/wiki/Functional_Testing Wikipedia article].

=== Functional Testing in Open Source ===
Web applications have been notoriously difficult to do functional testing with. It has traditionally required a great deal of time and effort. This can be a special challenge for open source projects because testing is often not very popular and designing tests that can be executed in a systematic way even less so. For a complicated application like Joomla!, this means that although we might do testing, we very seldom are able to perform extensive testing on each release that covers even a fraction of the elements in the CMS.

Relatively recently, a project called Selenium has arrived on the scene. This project makes performing automated functional testing of web applications possible. This means that it is possible to devise a test and have it performed in an automated way without the requirement of somebody sitting in front of a browser and being a click monkey.

The benefits of functional testing are:
* Functional tests help highlight cases where changes in one element of the system might cause breakage in other, unexpected areas.
* Functional tests help clearly specify how the application should behave.

=== Functional Testing versus Unit Testing ===
In order to fully test an application, both functional and unit testing are essential. Each approach has their benefits and weaknesses. Unit testing is very good for isolating small chunks of code and ensuring that they are behaving as expected. Functional testing, on the other hand, is geared towards looking at the system as a whole and ensuring that the units are behaving together in a way that achieves the desired effect.

The advantages of functional testing is that functional tests are easier to understand and conceptualize by people who are unfamiliar with the underlying code. With Selenium, tests can be designed by people who are not overly familiar with PHP - they only need to understand the application and what results should be expected.

The downside of functional testing is that it will only tell you that something broke. It isn't as obvious with functional testing exactly what went wrong or where the problem is.

==== Test Objects ====
If the purpose of unit tests is to isolate a module of code, then the purpose of functional tests is to evaluate the entire system. This is much easier for those unfamiliar with what happens under the hood of Joomla! because one is not required to understand what happens during a Joomla! page request. A functional test might evaluate, for example, if unpublishing an article works properly. Therefore, to design the test, it is only necessary to figure out how to change an article from Published to Unpublished, and how to verify that the article was actually unpublished.

=== Functional Testing in Joomla! ===
I have recently been building a functional testing architecture that will make it possible to write tests once, and to execute those tests on a variety of platforms and clients. I currently have infrastructure in place that makes it possible to run one command and execute functional tests in one browser on one host system. I have designed the host system in such a way that it will run on 6 different PHP versions (stock Ubuntu PHP 5 and self-compiled PHP 4.3, 4.4, 5.0, 5.1 and 5.2) and 2 different web servers (Apache and Lighttpd). These are all currently serving from the same database.

The future steps will be to make it possible to run on multiple host systems (the requirement for this is to generalize the code that resets the database state after the tests are run) and to make it possible to use different clients (i.e. different systems with different web browsers). These steps should be fairly trivial, but I have not yet had time to focus on them.

This will eventually make it possible to run the designed tests on every major browser and on multiple server platforms (various PHP versions, various configurations, various operating systems and various web servers).

==== Writing Functional Tests ====
Selenium IDE makes it fairly easy to write functional tests. It is a Firefox extension that operates as an Integrated Development Environment for creating functional tests. In essence, it records your clicks as you navigate in your browser and encodes them into a series of commands that can control the browser.

===== Getting Selenium IDE =====
At the time of writing, the latest version of Selenium IDE is 1.0.2. You can get it at http://seleniumhq.org/download/. Click on the download link and install like you would any Firefox plugin.

===== Preparing your Environment =====
To get started, create a vanilla install of Joomla! with the standard sample data.

===== Creating a Basic Test =====
To start, open Firefox and browse to the home page of your Joomla! install. I setup my install on my localhost, and so the URL is http://127.0.0.1/selsampledata.

Then, click on Tools -> Selenium IDE. You will notice that on the right of the window that appears near the top, that there is a red circle that is highlighted. This is the start/stop recording button. When you start Selenium IDE, recording starts right away.

For our first test, all we will do is load up the home page and check to make sure that all the items in the Main Menu are present.

The commands that we use to check that items are present are called assertions. Basically, you perform your actions and make assertions about the results.

In our case, we are going to use the command assertText. This command will read the text of a specified element and ensure it matches a particular value.

So, first ensure that the Base URL displayed in the Selenium IDE window is the home page of your Joomla! install.

Then, switch to the window that has your Joomla install open.

In that window, right click on each menu item and select 'Assert Text'.

Then, switch to your Selenium IDE window and click the Red Button to stop recording.

You should see two tabs in your Selenium IDE window - one labeled Table, and one labeled Source. You don't really need to look at the Source window.

So, now our first test is done.

To run your test, you use the icons on the bar between the Base URL address bar and the Table and Source tabs. The two important buttons are the buttons with the Green Triangle with Three Solid rectangles and the one with the Green Triangle and One Solid Rectangle. The first one will execute the entire test suite and the second one will run the currently selected test case. Since we currently have only one test case, both of these currently do the same thing.

To run your test, press one of these buttons.

As you watch the Selenium IDE, you will see a yellow bar move down your list of steps. Once a step is completed, a successfully executed action (i.e. a button was successfully located and clicked) should show up in light green and a successful assertion should show up in darker green. Failed actions show up in light red and failed assertions show up in darker red.

Click on the Window Expander on the left to unhide the Test Case browser.

If your test completed successfully, you should see Runs: 1, Failures: 0 at the bottom of the Test Case browser.

==== Running Functional Tests ====

=== Joomla Core Selenium testcases ===
The testing repository for the Selenium test suite for version 1.5 can be found here:

* [http://joomlacode.org/svn/joomla/testing/trunk/1.5/functionaltest/selenium/ http://joomlacode.org/svn/joomla/testing/trunk/1.5/functionaltest/selenium/]

As of February 2010, the unit and functional tests for version 1.6 have been incorporated into the SVN trunk under a folder called "tests". More information about running the version 1.6 tests is available in the article [[Running Automated Tests for Version 1.6]].

Note: If a login mask comes up, use </br>
:User: anonymous </br>
:Password: <empty>

== How to Get it Running ==

== Troubleshooting ==

== Frequently Asked Questions ==

==See also==
For writing a more advanced Selenium testcase see [http://docs.joomla.org/Intermediate_Selenium_Example here].

[http://seleniumhq.org/docs/ Selenium documentation].

[[Category:Development]]
[[Category:Testing]]
[[Category:Bug Squad]]

Writing Functional Tests for Version 1.6

2010-02-11T14:43:38Z

Ian: Writing Functional Tests for Version 1.6 moved to Writing System Tests for Version 1.6: Adjusting to use new nomenclature.

#REDIRECT [[Writing System Tests for Version 1.6]]

Writing System Tests for Joomla! - Part 1

2010-02-11T14:43:01Z

Ian: Writing Functional Tests for Version 1.6 moved to Writing System Tests for Version 1.6: Adjusting to use new nomenclature.

{{stub}}

== Introduction ==

As documented at [[Running_Automated_Tests_for_Version_1.6]], Joomla! version 1.6 now includes a library of system tests. This document details the steps necessary to create system tests using Selenium IDE. You will also need to run Firefox and install the Selenium IDE add-on to Firefox. Instructions for this can be found in the [[Functional Testing]] article.

NOTE: This article assumes that you have read the aforementioned article and have PHPUnit and Selenium set up and working properly.

== Overview ==
Writing a system test essentially entails converting a Selenium IDE test to a format that we can easily integrate into the Joomla! test suite.
See [[Functional_Testing]] for a good primer on system tests as well as [[Intermediate_Selenium_Example]] for a great example of creating an Intermediate Selenium test.

== Creating a basic system test ==
A few items to note:
* It's recommended to update your local copy of 1.6 to the latest build before writing any tests.
* The test are written in PHP and we are using Selenium RC to execute them later. You will need to select the PHP Selenium RC Format in Slenium IDE. Go to Options -> Format -> PHP Selenium RC
* More information about writing test can be found at [http://www.phpunit.de/manual/current/en/writing-tests-for-phpunit.html http://www.phpunit.de/manual/current/en/writing-tests-for-phpunit.html]

In this test, we are going to execute the test described at [[Intermediate_Selenium_Example]] and integrate it into the system tests suite in 1.6.

1. Open 1.6 in FireFox and navigate to the home page.

2. Open Selenium IDE by going to the Tools menu and select Selenium IDE. Selenium will start recording automatically and the record button will appear highlighted.

3. Verify that the Base URL displayed in Selenium is that of your test site.

4. Perform the test by following the instructions described above (note: there are some slight variations between the test described above and the one we performed. This is due to variation of 1.6 during the development process).

5. When you have completed your test, click the the red record button (see image below) to stop recording.

[[Image:Selenium-screen.png]]

6. Once recording has stopped, create a new PHP file in Eclipse (or your favorite code editor) and copy / paste the code from Selenium IDE to there. The contents of the example test is:
<pre><?php

require_once 'PHPUnit/Extensions/SeleniumTestCase.php';

class Example extends PHPUnit_Extensions_SeleniumTestCase
{
function setUp()
{
$this->setBrowser("*chrome");
$this->setBrowserUrl("http://change-this-to-the-site-you-are-testing/");
}

function testMyTestCase()
{
$this->open("/workspace/joomla-1-6-source/administrator/index.php?option=com_login");
$this->type("mod-login-username", "admin");
$this->click("link=Log in");
$this->waitForPageToLoad("30000");
$this->click("link=User Manager");
$this->waitForPageToLoad("30000");
$this->click("//li[@id='toolbar-new']/a/span");
$this->waitForPageToLoad("30000");
$this->type("jform_name", "My Test User");
$this->type("jform_username", "TestUser");
$this->type("jform_password", "password");
$this->type("jform_password2", "password");
$this->type("jform_email", "test@example.com");
$this->click("1group_2");
$this->click("link=Save & Close");
$this->waitForPageToLoad("30000");
try {
$this->assertTrue($this->isTextPresent("Item successfully saved."));
} catch (PHPUnit_Framework_AssertionFailedError $e) {
array_push($this->verificationErrors, $e->toString());
}
$this->type("search", "TestUser");
$this->click("//button[@type='submit']");
$this->waitForPageToLoad("30000");
try {
$this->assertTrue($this->isTextPresent("TestUser"));
} catch (PHPUnit_Framework_AssertionFailedError $e) {
array_push($this->verificationErrors, $e->toString());
}
$this->click("link=Log out");
$this->waitForPageToLoad("30000");
$this->click("link=Go to site home page.");
$this->waitForPageToLoad("30000");
$this->type("modlgn_username", "TestUser");
$this->type("modlgn_passwd", "password");
$this->click("Submit");
$this->waitForPageToLoad("30000");
try {
$this->assertTrue($this->isTextPresent("My Test User"));
} catch (PHPUnit_Framework_AssertionFailedError $e) {
array_push($this->verificationErrors, $e->toString());
}
$this->click("link=Logout");
$this->waitForPageToLoad("30000");
$this->click("//button[@type='submit']");
$this->waitForPageToLoad("30000");
$this->click("link=Site Administrator");
$this->waitForPageToLoad("30000");
$this->type("mod-login-username", "admin");
$this->click("link=Log in");
$this->waitForPageToLoad("30000");
$this->click("//img[@alt='User Manager']");
$this->waitForPageToLoad("30000");
$this->click("cb0");
$this->click("link=Delete");
$this->waitForPageToLoad("30000");
try {
$this->assertTrue($this->isTextPresent("1 item(s) successfully deleted."));
} catch (PHPUnit_Framework_AssertionFailedError $e) {
array_push($this->verificationErrors, $e->toString());
}
$this->click("link=Log out");
$this->waitForPageToLoad("30000");
}
}
?></pre>

As noted in [[Intermediate_Selenium_Example]] Selenium does not record passwords that are entered. Additionally, we can utilize [[Selenium_Test_Case_Methods]] to prevent coding path or login information in the test:

1. The first step in integrating this test into <code>tests/suite</code> is to call <code>SeleniumJoomlaTestCase.php</code> so that we can utilize the Selenium Test Case Methods. To do this, we will replace the first portion of our code:
<pre><?php
require_once 'PHPUnit/Extensions/SeleniumTestCase.php';
</pre>

with the following code

<pre><?php
require_once 'SeleniumJoomlaTestCase.php';</pre>

* We can now start utilizing the Selenium Test Case Methods.

2. We will now extend a class into our SeleniumJoomlaTestCase to implement the client/server protocol to talk to Selenium RC as well as specialized assertion methods for web testing.

This is done by replacing:
<pre>class Example extends PHPUnit_Extensions_SeleniumTestCase
{</pre>

with

<pre>class MyTestCase extends SeleniumJoomlaTestCase
{</pre>

[[Category:Bug Squad]] [[Category:Development]] [[Category:Testing]]

Why can't you upload files using the flash uploader?

2009-12-17T14:31:42Z

Ian:

Sometimes the flash uploader does not work.

There are known issues with the Flash Uploader and Flash 10. At this time it is recommended to deactivate the Flash Uploader in the Main Configuration Settings and use the traditional and safe form uploader.

<noinclude>
[[Category:FAQ]]
[[Category:Joomla! 1.5]]
</noinclude>

Unit Testing

2009-10-17T15:25:23Z

Ian: /* News and Updates */

{{cookiejar}}
== News and Updates ==
2009 10 06: Tests now depend on the SVN version of PHPUnit 3.4.1.

2008 06 24: Update to reflect move of PHPUnit code from branch to trunk (former trunk now in /branches/old_simpletest).

2008 06 22: Add information on limiting tests by version.

2008 06 21: Added --class-exclude, --sequence-exclude, and --test-exclude options.

2008 06 21: PHPUnit has been updated to version 3.2.21 with SVN rev 10436. Please update.

== Unit Testing ==
Unit testing is an essential part of a good Quality Control program.
For a good general discussion of unit testing, visit the [http://en.wikipedia.org/wiki/Unit_test Wikipedia article].

=== Unit Testing in Open Source ===
Open source projects, with multiple developers working in parallel around the world, can greatly benefit from unit testing. The main benefits are:
* Unit tests help highlight cases where seemingly minor changes cause unexpected breakage.
* Unit tests help clearly specify how a class should behave.
* Unit tests can expose design flaws very early in development.
* Unit tests make great examples. They are a great place for developers to learn how to use the code.

=== The Testing Hierarchy: Unit, Subsystem, Integrated ===
Software testing systems usually run through a spectrum from "pure" unit tests through to fully integrated systems tests. We've described low level unit tests above. Integrated testing typically involves some sort of script that simulates user actions and then verifies that the result matches what's expected. This sort of "end to end" test verifies that all parts of the system are working correctly.

It's unfortunate that there is no clear nomenclature to describe all the intermediate stages of testing. The next stage beyond testing a single unit of code is subsystem testing. A subsystem test verifies that two or more units of code are interacting correctly to produce the desired result. In the simplest case, a subsystem test can be created simply by replacing mock objects with real objects and running unit tests on the top level module. In practise, this tends to not work as well as expected, because the original unit test data wasn't designed for a subsystem test, or because the nature of the test cases needs to be changed in order to fully test the subsystem. After all there is little point in simply repeating the unit test cases; the objective of a subsystem test should be to test boundary conditions and special cases that would be difficult to duplicate in unit tests.

Once a subsystem has been tested, it can be integrated into a larger system, which is still a subset of the whole product. Tests can be written for larger and larger subsystems, but at each stage the complexity of the tests increases. At some point, the effort required to hand craft tests exceeds the benefits of running them. This is where integrated testing comes in.

Integrated testing involves recording a user's interaction with the system into a script that can be replayed. The testing framework then compares the system's response with the expected response and passes or fails the test. The PHPUnit testing framework that we use has the ability to work with Selenium, a browser based test automation tool.

==== Test Objects ====
The purpose of unit tests is to isolate a module of code. A test that tests only one thing provides better information than a test that involves several object interactions. But how do we isolate an object from its dependencies? By writing stub classes. [http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html xUnit Patterns] defines a the hierarchy of dummy classes, ranging from simple to complex:
* Dummy - Defines attributes and methods of a dummy class (not particularly useful in PHP).
* Fake - Provides canned responses to method calls and fixed attribute values. Good for speed.
* Stub - Allows the test to define responses to method calls (return values, exceptions) to simulate the dependent object.
* Spy - A Fake or Stub that records method calls and parameters for later analysis.
* Mock - A Fake or Stub with a set of expectations -- method calls and parameters -- that are automatically verified for correctness.

=== Unit Testing in Joomla! ===
Unit testing capabilities in Joomla are still at an early stage. The intention is to define more standards for developing tests, and then to expand the scope of available tests.

For an overview of unit testing status in Joomla visit the [[Unit_Testing_Status]] page.

The SVN repository contains code under the /testing path. /testing/trunk used to contain code based on the SimpleTest framework. In early December 2007, the development team elected to move to the [http://www.phpunit.de PHPUnit] framework.

The PHPUnit tests are available from '''/testing/trunk'''. Some new tests have been added, any remaining tests from the SimpleTest days are completely broken. See /testing/branches/old-simpletest if you need to run something from that suite.

The unit tests are located in two places:
* /testing/trunk/1.5/unittest - these are tests for Joomla! 1.5 (/development/releases/1.5)
* /testing/trunk/1.6/unittest - there are tests for Joomla! 1.6 (/development/trunk)

At this point, PHPUnit based tests only run in a command line environment.

==== The Unit Test Team ====
If you can commit to the Joomla code base, then you should consider yourself part of the unit test team!

Writing tests concurrently with code (or even before) is a good way to not only save development time, but a great tool for defending against regressions. Writing tests early in the development cycle also helps identify and resolve design issues sooner, which reduces refactoring.

If you want to get started on unit testing, get in touch with Alan Langford (instance) or Ray Tsai (mihu). Either of us will be happy to help out.

==== Current Work ====
* There is no longer any need to patch the main code to enable unit tests.
* Basic techniques for mock objects are defined.
* Strategies for dealing with local configuration is not yet complete, but there is a plan.
* Files of the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php use PHPUnit.
* The JDate tests present a good example of a data-driven test, but they won't run on the current 1.5 code base (there are some proposed API changes as a result of unit test development).
* Previously functional tests, such as JFTP, haven't been moved to the PHPUnit environment yet.
* The custom test runner is no longer needed. The current tests will run with the latest SVN version of PHPUnit 3.4. This code will eventually become PHPUnit 3.4.1. Thanks to Sebastian Bergmann for his excellent work on an excellent project!

==== Writing Unit Tests ====
At risk of stating the obvious, in the "purest" case the purpose of a unit test is to ''isolate a unit of code from its environment and to test the operation of that code''.

This isolation is usually achieved by writing dummy classes that emulate the code unit's environment. These dummy objects can be passive, by simply simulating the environment, or they can be more active, keeping track of how they are being used by the test unit and reporting any variations from the expected behaviour. See [[Unit_Testing_Mock_Objects|Mock Objects in Joomla]] for a detailed example.

An interesting aspect of writing tests is that they become ''de facto'' detailed technical specifications of the interfaces between units of code. The fact that these specifications can be verified in an automated way makes them a superb resource when refactoring code.

The test code has a few templates designed to kick-start a test. They are:

/unittest/sample-datatest-php.txt
/unittest/sample-simpletest.php.txt

Here are some example tests: [[Unit_Testing_--_a_Simple_Example|Simple Example]], [[Unit_Testing_--_Data_Driven_Example|Data Driven Example]], [[Unit_Testing_--_Plugin_Example|Plugin Example]], [[Unit_Testing_--_UI_Example|UI Example]].

==== Running Unit Tests ====
Test files follow the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php. For tests that are not class based, the first element refers to the object being tested. An example of this is the e-mail cloaking plugin test, which is called emailcloak-0000-mode1-Test.php.

Joomla unit tests use the standard PHPUnit test runner. See http://www.phpunit.de for documentation.

== How to Get it Running ==

Before you start make sure you have installed PHPUnit and of course PHP (5!) properly...

To get the unit tests to run on your Joomla! installation, perform the following steps:
* Create an instance of your Joomla! installation
* In the root checkout (or export) the latest version of the unit test code from SVN ''"/testing/trunk/1.5/unittest"'' or ''"/testing/trunk/1.6/unittest"'' to your installation base. This will create a ''"/unittest"'' sub-folder under your joomla installation.
* Change to the unittest directory.
* Run the unit test from the command prompt using the following command:
phpunit tests

The unit test will the run, and the results are rendered.

See http://www.phpunit.de/manual/current/en/textui.html for help using the --filter switch to run only certain tests. There are also many other command line switches you can use to get results in various formats.

== Troubleshooting ==

The provided configurations should work out of the box. We have seen problems with it (currently the cause is unknown). If you get an error like below, the solution is pretty easy.

file=/var/www/unittest/runtests.php
posn=17
base=runtests.php
/var/www
JPATH_BASE does not point to a valid Joomla! installation:
JPATH_BASE = /var/www
Please modify your copy of "TestConfiguration.php"

Modify the ''"TestConfiguration.php"'' file and change the definition of the JPATH_BASE so it points to the path of you Joomla! installation, in the example below the Joomla! installation is installed at "''/var/www/update''".

define('JPATH_BASE', '/var/www/update');

== Frequently Asked Questions ==
'''Why can't I use "phpunit ''testname.php''" to run my tests?'''

The test facility has to do some work to be able to load the "Joomla!" framework and to be able to inject mock classes. It's difficult to do this from the PHPUnit test runner, so we built our own. Also, the Joomla test runner has specific options designed to make it easy to select specific tests. Over time we will add more functionality to the test runner so it has many of the capabilities of the phpunit command.

==See also==
[http://www.phpunit.de/manual/current/en/ PHPUnit Manual]

[[Category:Development]]

Unit Testing

2009-10-06T14:24:00Z

Ian: /* News and Updates */

{{cookiejar}}
== News and Updates ==
2009 10 06: Tests now depend on the SVN version of PHPUnit 3.4. Hopefully they release soon.

2008 06 24: Update to reflect move of PHPUnit code from branch to trunk (former trunk now in /branches/old_simpletest).

2008 06 22: Add information on limiting tests by version.

2008 06 21: Added --class-exclude, --sequence-exclude, and --test-exclude options.

2008 06 21: PHPUnit has been updated to version 3.2.21 with SVN rev 10436. Please update.

== Unit Testing ==
Unit testing is an essential part of a good Quality Control program.
For a good general discussion of unit testing, visit the [http://en.wikipedia.org/wiki/Unit_test Wikipedia article].

=== Unit Testing in Open Source ===
Open source projects, with multiple developers working in parallel around the world, can greatly benefit from unit testing. The main benefits are:
* Unit tests help highlight cases where seemingly minor changes cause unexpected breakage.
* Unit tests help clearly specify how a class should behave.
* Unit tests can expose design flaws very early in development.
* Unit tests make great examples. They are a great place for developers to learn how to use the code.

=== The Testing Hierarchy: Unit, Subsystem, Integrated ===
Software testing systems usually run through a spectrum from "pure" unit tests through to fully integrated systems tests. We've described low level unit tests above. Integrated testing typically involves some sort of script that simulates user actions and then verifies that the result matches what's expected. This sort of "end to end" test verifies that all parts of the system are working correctly.

It's unfortunate that there is no clear nomenclature to describe all the intermediate stages of testing. The next stage beyond testing a single unit of code is subsystem testing. A subsystem test verifies that two or more units of code are interacting correctly to produce the desired result. In the simplest case, a subsystem test can be created simply by replacing mock objects with real objects and running unit tests on the top level module. In practise, this tends to not work as well as expected, because the original unit test data wasn't designed for a subsystem test, or because the nature of the test cases needs to be changed in order to fully test the subsystem. After all there is little point in simply repeating the unit test cases; the objective of a subsystem test should be to test boundary conditions and special cases that would be difficult to duplicate in unit tests.

Once a subsystem has been tested, it can be integrated into a larger system, which is still a subset of the whole product. Tests can be written for larger and larger subsystems, but at each stage the complexity of the tests increases. At some point, the effort required to hand craft tests exceeds the benefits of running them. This is where integrated testing comes in.

Integrated testing involves recording a user's interaction with the system into a script that can be replayed. The testing framework then compares the system's response with the expected response and passes or fails the test. The PHPUnit testing framework that we use has the ability to work with Selenium, a browser based test automation tool.

==== Test Objects ====
The purpose of unit tests is to isolate a module of code. A test that tests only one thing provides better information than a test that involves several object interactions. But how do we isolate an object from its dependencies? By writing stub classes. [http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html xUnit Patterns] defines a the hierarchy of dummy classes, ranging from simple to complex:
* Dummy - Defines attributes and methods of a dummy class (not particularly useful in PHP).
* Fake - Provides canned responses to method calls and fixed attribute values. Good for speed.
* Stub - Allows the test to define responses to method calls (return values, exceptions) to simulate the dependent object.
* Spy - A Fake or Stub that records method calls and parameters for later analysis.
* Mock - A Fake or Stub with a set of expectations -- method calls and parameters -- that are automatically verified for correctness.

=== Unit Testing in Joomla! ===
Unit testing capabilities in Joomla are still at an early stage. The intention is to define more standards for developing tests, and then to expand the scope of available tests.

For an overview of unit testing status in Joomla visit the [[Unit_Testing_Status]] page.

The SVN repository contains code under the /testing path. /testing/trunk used to contain code based on the SimpleTest framework. In early December 2007, the development team elected to move to the [http://www.phpunit.de PHPUnit] framework.

The PHPUnit tests are available from '''/testing/trunk'''. Some new tests have been added, any remaining tests from the SimpleTest days are completely broken. See /testing/branches/old-simpletest if you need to run something from that suite.

The unit tests are located in two places:
* /testing/trunk/1.5/unittest - these are tests for Joomla! 1.5 (/development/releases/1.5)
* /testing/trunk/1.6/unittest - there are tests for Joomla! 1.6 (/development/trunk)

At this point, PHPUnit based tests only run in a command line environment.

==== The Unit Test Team ====
If you can commit to the Joomla code base, then you should consider yourself part of the unit test team!

Writing tests concurrently with code (or even before) is a good way to not only save development time, but a great tool for defending against regressions. Writing tests early in the development cycle also helps identify and resolve design issues sooner, which reduces refactoring.

If you want to get started on unit testing, get in touch with Alan Langford (instance) or Ray Tsai (mihu). Either of us will be happy to help out.

==== Current Work ====
* There is no longer any need to patch the main code to enable unit tests.
* Basic techniques for mock objects are defined.
* Strategies for dealing with local configuration is not yet complete, but there is a plan.
* Files of the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php use PHPUnit.
* The JDate tests present a good example of a data-driven test, but they won't run on the current 1.5 code base (there are some proposed API changes as a result of unit test development).
* Previously functional tests, such as JFTP, haven't been moved to the PHPUnit environment yet.
* The custom test runner is no longer needed. The current tests will run with the latest SVN version of PHPUnit 3.4. This code will eventually become PHPUnit 3.4.1. Thanks to Sebastian Bergmann for his excellent work on an excellent project!

==== Writing Unit Tests ====
At risk of stating the obvious, in the "purest" case the purpose of a unit test is to ''isolate a unit of code from its environment and to test the operation of that code''.

This isolation is usually achieved by writing dummy classes that emulate the code unit's environment. These dummy objects can be passive, by simply simulating the environment, or they can be more active, keeping track of how they are being used by the test unit and reporting any variations from the expected behaviour. See [[Unit_Testing_Mock_Objects|Mock Objects in Joomla]] for a detailed example.

An interesting aspect of writing tests is that they become ''de facto'' detailed technical specifications of the interfaces between units of code. The fact that these specifications can be verified in an automated way makes them a superb resource when refactoring code.

The test code has a few templates designed to kick-start a test. They are:

/unittest/sample-datatest-php.txt
/unittest/sample-simpletest.php.txt

Here are some example tests: [[Unit_Testing_--_a_Simple_Example|Simple Example]], [[Unit_Testing_--_Data_Driven_Example|Data Driven Example]], [[Unit_Testing_--_Plugin_Example|Plugin Example]], [[Unit_Testing_--_UI_Example|UI Example]].

==== Running Unit Tests ====
Test files follow the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php. For tests that are not class based, the first element refers to the object being tested. An example of this is the e-mail cloaking plugin test, which is called emailcloak-0000-mode1-Test.php.

Joomla unit tests use the standard PHPUnit test runner. See http://www.phpunit.de for documentation.

== How to Get it Running ==

Before you start make sure you have installed PHPUnit and of course PHP (5!) properly...

To get the unit tests to run on your Joomla! installation, perform the following steps:
* Create an instance of your Joomla! installation
* In the root checkout (or export) the latest version of the unit test code from SVN ''"/testing/trunk/1.5/unittest"'' or ''"/testing/trunk/1.6/unittest"'' to your installation base. This will create a ''"/unittest"'' sub-folder under your joomla installation.
* Change to the unittest directory.
* Run the unit test from the command prompt using the following command:
phpunit tests

The unit test will the run, and the results are rendered.

See http://www.phpunit.de/manual/current/en/textui.html for help using the --filter switch to run only certain tests. There are also many other command line switches you can use to get results in various formats.

== Troubleshooting ==

The provided configurations should work out of the box. We have seen problems with it (currently the cause is unknown). If you get an error like below, the solution is pretty easy.

file=/var/www/unittest/runtests.php
posn=17
base=runtests.php
/var/www
JPATH_BASE does not point to a valid Joomla! installation:
JPATH_BASE = /var/www
Please modify your copy of "TestConfiguration.php"

Modify the ''"TestConfiguration.php"'' file and change the definition of the JPATH_BASE so it points to the path of you Joomla! installation, in the example below the Joomla! installation is installed at "''/var/www/update''".

define('JPATH_BASE', '/var/www/update');

== Frequently Asked Questions ==
'''Why can't I use "phpunit ''testname.php''" to run my tests?'''

The test facility has to do some work to be able to load the "Joomla!" framework and to be able to inject mock classes. It's difficult to do this from the PHPUnit test runner, so we built our own. Also, the Joomla test runner has specific options designed to make it easy to select specific tests. Over time we will add more functionality to the test runner so it has many of the capabilities of the phpunit command.

==See also==
[http://www.phpunit.de/manual/current/en/ PHPUnit Manual]

[[Category:Development]]

Unit Testing

2009-10-06T14:22:25Z

Ian: /* How to Get it Running */

{{cookiejar}}
== News and Updates ==
2008 06 24: Update to reflect move of PHPUnit code from branch to trunk (former trunk now in /branches/old_simpletest).

2008 06 22: Add information on limiting tests by version.

2008 06 21: Added --class-exclude, --sequence-exclude, and --test-exclude options.

2008 06 21: PHPUnit has been updated to version 3.2.21 with SVN rev 10436. Please update.

== Unit Testing ==
Unit testing is an essential part of a good Quality Control program.
For a good general discussion of unit testing, visit the [http://en.wikipedia.org/wiki/Unit_test Wikipedia article].

=== Unit Testing in Open Source ===
Open source projects, with multiple developers working in parallel around the world, can greatly benefit from unit testing. The main benefits are:
* Unit tests help highlight cases where seemingly minor changes cause unexpected breakage.
* Unit tests help clearly specify how a class should behave.
* Unit tests can expose design flaws very early in development.
* Unit tests make great examples. They are a great place for developers to learn how to use the code.

=== The Testing Hierarchy: Unit, Subsystem, Integrated ===
Software testing systems usually run through a spectrum from "pure" unit tests through to fully integrated systems tests. We've described low level unit tests above. Integrated testing typically involves some sort of script that simulates user actions and then verifies that the result matches what's expected. This sort of "end to end" test verifies that all parts of the system are working correctly.

It's unfortunate that there is no clear nomenclature to describe all the intermediate stages of testing. The next stage beyond testing a single unit of code is subsystem testing. A subsystem test verifies that two or more units of code are interacting correctly to produce the desired result. In the simplest case, a subsystem test can be created simply by replacing mock objects with real objects and running unit tests on the top level module. In practise, this tends to not work as well as expected, because the original unit test data wasn't designed for a subsystem test, or because the nature of the test cases needs to be changed in order to fully test the subsystem. After all there is little point in simply repeating the unit test cases; the objective of a subsystem test should be to test boundary conditions and special cases that would be difficult to duplicate in unit tests.

Once a subsystem has been tested, it can be integrated into a larger system, which is still a subset of the whole product. Tests can be written for larger and larger subsystems, but at each stage the complexity of the tests increases. At some point, the effort required to hand craft tests exceeds the benefits of running them. This is where integrated testing comes in.

Integrated testing involves recording a user's interaction with the system into a script that can be replayed. The testing framework then compares the system's response with the expected response and passes or fails the test. The PHPUnit testing framework that we use has the ability to work with Selenium, a browser based test automation tool.

==== Test Objects ====
The purpose of unit tests is to isolate a module of code. A test that tests only one thing provides better information than a test that involves several object interactions. But how do we isolate an object from its dependencies? By writing stub classes. [http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html xUnit Patterns] defines a the hierarchy of dummy classes, ranging from simple to complex:
* Dummy - Defines attributes and methods of a dummy class (not particularly useful in PHP).
* Fake - Provides canned responses to method calls and fixed attribute values. Good for speed.
* Stub - Allows the test to define responses to method calls (return values, exceptions) to simulate the dependent object.
* Spy - A Fake or Stub that records method calls and parameters for later analysis.
* Mock - A Fake or Stub with a set of expectations -- method calls and parameters -- that are automatically verified for correctness.

=== Unit Testing in Joomla! ===
Unit testing capabilities in Joomla are still at an early stage. The intention is to define more standards for developing tests, and then to expand the scope of available tests.

For an overview of unit testing status in Joomla visit the [[Unit_Testing_Status]] page.

The SVN repository contains code under the /testing path. /testing/trunk used to contain code based on the SimpleTest framework. In early December 2007, the development team elected to move to the [http://www.phpunit.de PHPUnit] framework.

The PHPUnit tests are available from '''/testing/trunk'''. Some new tests have been added, any remaining tests from the SimpleTest days are completely broken. See /testing/branches/old-simpletest if you need to run something from that suite.

The unit tests are located in two places:
* /testing/trunk/1.5/unittest - these are tests for Joomla! 1.5 (/development/releases/1.5)
* /testing/trunk/1.6/unittest - there are tests for Joomla! 1.6 (/development/trunk)

At this point, PHPUnit based tests only run in a command line environment.

==== The Unit Test Team ====
If you can commit to the Joomla code base, then you should consider yourself part of the unit test team!

Writing tests concurrently with code (or even before) is a good way to not only save development time, but a great tool for defending against regressions. Writing tests early in the development cycle also helps identify and resolve design issues sooner, which reduces refactoring.

If you want to get started on unit testing, get in touch with Alan Langford (instance) or Ray Tsai (mihu). Either of us will be happy to help out.

==== Current Work ====
* There is no longer any need to patch the main code to enable unit tests.
* Basic techniques for mock objects are defined.
* Strategies for dealing with local configuration is not yet complete, but there is a plan.
* Files of the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php use PHPUnit.
* The JDate tests present a good example of a data-driven test, but they won't run on the current 1.5 code base (there are some proposed API changes as a result of unit test development).
* Previously functional tests, such as JFTP, haven't been moved to the PHPUnit environment yet.
* The custom test runner is no longer needed. The current tests will run with the latest SVN version of PHPUnit 3.4. This code will eventually become PHPUnit 3.4.1. Thanks to Sebastian Bergmann for his excellent work on an excellent project!

==== Writing Unit Tests ====
At risk of stating the obvious, in the "purest" case the purpose of a unit test is to ''isolate a unit of code from its environment and to test the operation of that code''.

This isolation is usually achieved by writing dummy classes that emulate the code unit's environment. These dummy objects can be passive, by simply simulating the environment, or they can be more active, keeping track of how they are being used by the test unit and reporting any variations from the expected behaviour. See [[Unit_Testing_Mock_Objects|Mock Objects in Joomla]] for a detailed example.

An interesting aspect of writing tests is that they become ''de facto'' detailed technical specifications of the interfaces between units of code. The fact that these specifications can be verified in an automated way makes them a superb resource when refactoring code.

The test code has a few templates designed to kick-start a test. They are:

/unittest/sample-datatest-php.txt
/unittest/sample-simpletest.php.txt

Here are some example tests: [[Unit_Testing_--_a_Simple_Example|Simple Example]], [[Unit_Testing_--_Data_Driven_Example|Data Driven Example]], [[Unit_Testing_--_Plugin_Example|Plugin Example]], [[Unit_Testing_--_UI_Example|UI Example]].

==== Running Unit Tests ====
Test files follow the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php. For tests that are not class based, the first element refers to the object being tested. An example of this is the e-mail cloaking plugin test, which is called emailcloak-0000-mode1-Test.php.

Joomla unit tests use the standard PHPUnit test runner. See http://www.phpunit.de for documentation.

== How to Get it Running ==

Before you start make sure you have installed PHPUnit and of course PHP (5!) properly...

To get the unit tests to run on your Joomla! installation, perform the following steps:
* Create an instance of your Joomla! installation
* In the root checkout (or export) the latest version of the unit test code from SVN ''"/testing/trunk/1.5/unittest"'' or ''"/testing/trunk/1.6/unittest"'' to your installation base. This will create a ''"/unittest"'' sub-folder under your joomla installation.
* Change to the unittest directory.
* Run the unit test from the command prompt using the following command:
phpunit tests

The unit test will the run, and the results are rendered.

See http://www.phpunit.de/manual/current/en/textui.html for help using the --filter switch to run only certain tests. There are also many other command line switches you can use to get results in various formats.

== Troubleshooting ==

The provided configurations should work out of the box. We have seen problems with it (currently the cause is unknown). If you get an error like below, the solution is pretty easy.

file=/var/www/unittest/runtests.php
posn=17
base=runtests.php
/var/www
JPATH_BASE does not point to a valid Joomla! installation:
JPATH_BASE = /var/www
Please modify your copy of "TestConfiguration.php"

Modify the ''"TestConfiguration.php"'' file and change the definition of the JPATH_BASE so it points to the path of you Joomla! installation, in the example below the Joomla! installation is installed at "''/var/www/update''".

define('JPATH_BASE', '/var/www/update');

== Frequently Asked Questions ==
'''Why can't I use "phpunit ''testname.php''" to run my tests?'''

The test facility has to do some work to be able to load the "Joomla!" framework and to be able to inject mock classes. It's difficult to do this from the PHPUnit test runner, so we built our own. Also, the Joomla test runner has specific options designed to make it easy to select specific tests. Over time we will add more functionality to the test runner so it has many of the capabilities of the phpunit command.

==See also==
[http://www.phpunit.de/manual/current/en/ PHPUnit Manual]

[[Category:Development]]

Unit Testing

2009-10-06T14:18:22Z

Ian: /* Running Unit Tests */

{{cookiejar}}
== News and Updates ==
2008 06 24: Update to reflect move of PHPUnit code from branch to trunk (former trunk now in /branches/old_simpletest).

2008 06 22: Add information on limiting tests by version.

2008 06 21: Added --class-exclude, --sequence-exclude, and --test-exclude options.

2008 06 21: PHPUnit has been updated to version 3.2.21 with SVN rev 10436. Please update.

== Unit Testing ==
Unit testing is an essential part of a good Quality Control program.
For a good general discussion of unit testing, visit the [http://en.wikipedia.org/wiki/Unit_test Wikipedia article].

=== Unit Testing in Open Source ===
Open source projects, with multiple developers working in parallel around the world, can greatly benefit from unit testing. The main benefits are:
* Unit tests help highlight cases where seemingly minor changes cause unexpected breakage.
* Unit tests help clearly specify how a class should behave.
* Unit tests can expose design flaws very early in development.
* Unit tests make great examples. They are a great place for developers to learn how to use the code.

=== The Testing Hierarchy: Unit, Subsystem, Integrated ===
Software testing systems usually run through a spectrum from "pure" unit tests through to fully integrated systems tests. We've described low level unit tests above. Integrated testing typically involves some sort of script that simulates user actions and then verifies that the result matches what's expected. This sort of "end to end" test verifies that all parts of the system are working correctly.

It's unfortunate that there is no clear nomenclature to describe all the intermediate stages of testing. The next stage beyond testing a single unit of code is subsystem testing. A subsystem test verifies that two or more units of code are interacting correctly to produce the desired result. In the simplest case, a subsystem test can be created simply by replacing mock objects with real objects and running unit tests on the top level module. In practise, this tends to not work as well as expected, because the original unit test data wasn't designed for a subsystem test, or because the nature of the test cases needs to be changed in order to fully test the subsystem. After all there is little point in simply repeating the unit test cases; the objective of a subsystem test should be to test boundary conditions and special cases that would be difficult to duplicate in unit tests.

Once a subsystem has been tested, it can be integrated into a larger system, which is still a subset of the whole product. Tests can be written for larger and larger subsystems, but at each stage the complexity of the tests increases. At some point, the effort required to hand craft tests exceeds the benefits of running them. This is where integrated testing comes in.

Integrated testing involves recording a user's interaction with the system into a script that can be replayed. The testing framework then compares the system's response with the expected response and passes or fails the test. The PHPUnit testing framework that we use has the ability to work with Selenium, a browser based test automation tool.

==== Test Objects ====
The purpose of unit tests is to isolate a module of code. A test that tests only one thing provides better information than a test that involves several object interactions. But how do we isolate an object from its dependencies? By writing stub classes. [http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html xUnit Patterns] defines a the hierarchy of dummy classes, ranging from simple to complex:
* Dummy - Defines attributes and methods of a dummy class (not particularly useful in PHP).
* Fake - Provides canned responses to method calls and fixed attribute values. Good for speed.
* Stub - Allows the test to define responses to method calls (return values, exceptions) to simulate the dependent object.
* Spy - A Fake or Stub that records method calls and parameters for later analysis.
* Mock - A Fake or Stub with a set of expectations -- method calls and parameters -- that are automatically verified for correctness.

=== Unit Testing in Joomla! ===
Unit testing capabilities in Joomla are still at an early stage. The intention is to define more standards for developing tests, and then to expand the scope of available tests.

For an overview of unit testing status in Joomla visit the [[Unit_Testing_Status]] page.

The SVN repository contains code under the /testing path. /testing/trunk used to contain code based on the SimpleTest framework. In early December 2007, the development team elected to move to the [http://www.phpunit.de PHPUnit] framework.

The PHPUnit tests are available from '''/testing/trunk'''. Some new tests have been added, any remaining tests from the SimpleTest days are completely broken. See /testing/branches/old-simpletest if you need to run something from that suite.

The unit tests are located in two places:
* /testing/trunk/1.5/unittest - these are tests for Joomla! 1.5 (/development/releases/1.5)
* /testing/trunk/1.6/unittest - there are tests for Joomla! 1.6 (/development/trunk)

At this point, PHPUnit based tests only run in a command line environment.

==== The Unit Test Team ====
If you can commit to the Joomla code base, then you should consider yourself part of the unit test team!

Writing tests concurrently with code (or even before) is a good way to not only save development time, but a great tool for defending against regressions. Writing tests early in the development cycle also helps identify and resolve design issues sooner, which reduces refactoring.

If you want to get started on unit testing, get in touch with Alan Langford (instance) or Ray Tsai (mihu). Either of us will be happy to help out.

==== Current Work ====
* There is no longer any need to patch the main code to enable unit tests.
* Basic techniques for mock objects are defined.
* Strategies for dealing with local configuration is not yet complete, but there is a plan.
* Files of the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php use PHPUnit.
* The JDate tests present a good example of a data-driven test, but they won't run on the current 1.5 code base (there are some proposed API changes as a result of unit test development).
* Previously functional tests, such as JFTP, haven't been moved to the PHPUnit environment yet.
* The custom test runner is no longer needed. The current tests will run with the latest SVN version of PHPUnit 3.4. This code will eventually become PHPUnit 3.4.1. Thanks to Sebastian Bergmann for his excellent work on an excellent project!

==== Writing Unit Tests ====
At risk of stating the obvious, in the "purest" case the purpose of a unit test is to ''isolate a unit of code from its environment and to test the operation of that code''.

This isolation is usually achieved by writing dummy classes that emulate the code unit's environment. These dummy objects can be passive, by simply simulating the environment, or they can be more active, keeping track of how they are being used by the test unit and reporting any variations from the expected behaviour. See [[Unit_Testing_Mock_Objects|Mock Objects in Joomla]] for a detailed example.

An interesting aspect of writing tests is that they become ''de facto'' detailed technical specifications of the interfaces between units of code. The fact that these specifications can be verified in an automated way makes them a superb resource when refactoring code.

The test code has a few templates designed to kick-start a test. They are:

/unittest/sample-datatest-php.txt
/unittest/sample-simpletest.php.txt

Here are some example tests: [[Unit_Testing_--_a_Simple_Example|Simple Example]], [[Unit_Testing_--_Data_Driven_Example|Data Driven Example]], [[Unit_Testing_--_Plugin_Example|Plugin Example]], [[Unit_Testing_--_UI_Example|UI Example]].

==== Running Unit Tests ====
Test files follow the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php. For tests that are not class based, the first element refers to the object being tested. An example of this is the e-mail cloaking plugin test, which is called emailcloak-0000-mode1-Test.php.

Joomla unit tests use the standard PHPUnit test runner. See http://www.phpunit.de for documentation.

== How to Get it Running ==

Before you start make sure you have installed PHPUnit and of course PHP (5!) properly...

To get the unit tests to run on your Joomla! installation, perform the following steps:
* Create an instance of your Joomla! installation
* In the root checkout (or export) the latest version of the unit test code from SVN ''"/testing/trunk"'' to your installation base. This will create a ''"/unittest"'' sub-folder under your joomla installation.
* Create a ''"TestConfiguration.php"'' file. You can copy a the file from ''"TestConfiguration-dist.php"'' that is part of the package you just have checked out.
* If you want to run a subset of the commands, change to the directory that contains those tests.
* Run the unit test from the command using the following command:

php runtests.php

The unit test will the run, and the results are rendered.

== Troubleshooting ==

The provided configurations should work out of the box. We have seen problems with it (currently the cause is unknown). If you get an error like below, the solution is pretty easy.

file=/var/www/unittest/runtests.php
posn=17
base=runtests.php
/var/www
JPATH_BASE does not point to a valid Joomla! installation:
JPATH_BASE = /var/www
Please modify your copy of "TestConfiguration.php"

Modify the ''"TestConfiguration.php"'' file and change the definition of the JPATH_BASE so it points to the path of you Joomla! installation, in the example below the Joomla! installation is installed at "''/var/www/update''".

define('JPATH_BASE', '/var/www/update');

== Frequently Asked Questions ==
'''Why can't I use "phpunit ''testname.php''" to run my tests?'''

The test facility has to do some work to be able to load the "Joomla!" framework and to be able to inject mock classes. It's difficult to do this from the PHPUnit test runner, so we built our own. Also, the Joomla test runner has specific options designed to make it easy to select specific tests. Over time we will add more functionality to the test runner so it has many of the capabilities of the phpunit command.

==See also==
[http://www.phpunit.de/manual/current/en/ PHPUnit Manual]

[[Category:Development]]

Unit Testing

2009-10-06T14:17:59Z

Ian: /* Running Unit Tests */

{{cookiejar}}
== News and Updates ==
2008 06 24: Update to reflect move of PHPUnit code from branch to trunk (former trunk now in /branches/old_simpletest).

2008 06 22: Add information on limiting tests by version.

2008 06 21: Added --class-exclude, --sequence-exclude, and --test-exclude options.

2008 06 21: PHPUnit has been updated to version 3.2.21 with SVN rev 10436. Please update.

== Unit Testing ==
Unit testing is an essential part of a good Quality Control program.
For a good general discussion of unit testing, visit the [http://en.wikipedia.org/wiki/Unit_test Wikipedia article].

=== Unit Testing in Open Source ===
Open source projects, with multiple developers working in parallel around the world, can greatly benefit from unit testing. The main benefits are:
* Unit tests help highlight cases where seemingly minor changes cause unexpected breakage.
* Unit tests help clearly specify how a class should behave.
* Unit tests can expose design flaws very early in development.
* Unit tests make great examples. They are a great place for developers to learn how to use the code.

=== The Testing Hierarchy: Unit, Subsystem, Integrated ===
Software testing systems usually run through a spectrum from "pure" unit tests through to fully integrated systems tests. We've described low level unit tests above. Integrated testing typically involves some sort of script that simulates user actions and then verifies that the result matches what's expected. This sort of "end to end" test verifies that all parts of the system are working correctly.

It's unfortunate that there is no clear nomenclature to describe all the intermediate stages of testing. The next stage beyond testing a single unit of code is subsystem testing. A subsystem test verifies that two or more units of code are interacting correctly to produce the desired result. In the simplest case, a subsystem test can be created simply by replacing mock objects with real objects and running unit tests on the top level module. In practise, this tends to not work as well as expected, because the original unit test data wasn't designed for a subsystem test, or because the nature of the test cases needs to be changed in order to fully test the subsystem. After all there is little point in simply repeating the unit test cases; the objective of a subsystem test should be to test boundary conditions and special cases that would be difficult to duplicate in unit tests.

Once a subsystem has been tested, it can be integrated into a larger system, which is still a subset of the whole product. Tests can be written for larger and larger subsystems, but at each stage the complexity of the tests increases. At some point, the effort required to hand craft tests exceeds the benefits of running them. This is where integrated testing comes in.

Integrated testing involves recording a user's interaction with the system into a script that can be replayed. The testing framework then compares the system's response with the expected response and passes or fails the test. The PHPUnit testing framework that we use has the ability to work with Selenium, a browser based test automation tool.

==== Test Objects ====
The purpose of unit tests is to isolate a module of code. A test that tests only one thing provides better information than a test that involves several object interactions. But how do we isolate an object from its dependencies? By writing stub classes. [http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html xUnit Patterns] defines a the hierarchy of dummy classes, ranging from simple to complex:
* Dummy - Defines attributes and methods of a dummy class (not particularly useful in PHP).
* Fake - Provides canned responses to method calls and fixed attribute values. Good for speed.
* Stub - Allows the test to define responses to method calls (return values, exceptions) to simulate the dependent object.
* Spy - A Fake or Stub that records method calls and parameters for later analysis.
* Mock - A Fake or Stub with a set of expectations -- method calls and parameters -- that are automatically verified for correctness.

=== Unit Testing in Joomla! ===
Unit testing capabilities in Joomla are still at an early stage. The intention is to define more standards for developing tests, and then to expand the scope of available tests.

For an overview of unit testing status in Joomla visit the [[Unit_Testing_Status]] page.

The SVN repository contains code under the /testing path. /testing/trunk used to contain code based on the SimpleTest framework. In early December 2007, the development team elected to move to the [http://www.phpunit.de PHPUnit] framework.

The PHPUnit tests are available from '''/testing/trunk'''. Some new tests have been added, any remaining tests from the SimpleTest days are completely broken. See /testing/branches/old-simpletest if you need to run something from that suite.

The unit tests are located in two places:
* /testing/trunk/1.5/unittest - these are tests for Joomla! 1.5 (/development/releases/1.5)
* /testing/trunk/1.6/unittest - there are tests for Joomla! 1.6 (/development/trunk)

At this point, PHPUnit based tests only run in a command line environment.

==== The Unit Test Team ====
If you can commit to the Joomla code base, then you should consider yourself part of the unit test team!

Writing tests concurrently with code (or even before) is a good way to not only save development time, but a great tool for defending against regressions. Writing tests early in the development cycle also helps identify and resolve design issues sooner, which reduces refactoring.

If you want to get started on unit testing, get in touch with Alan Langford (instance) or Ray Tsai (mihu). Either of us will be happy to help out.

==== Current Work ====
* There is no longer any need to patch the main code to enable unit tests.
* Basic techniques for mock objects are defined.
* Strategies for dealing with local configuration is not yet complete, but there is a plan.
* Files of the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php use PHPUnit.
* The JDate tests present a good example of a data-driven test, but they won't run on the current 1.5 code base (there are some proposed API changes as a result of unit test development).
* Previously functional tests, such as JFTP, haven't been moved to the PHPUnit environment yet.
* The custom test runner is no longer needed. The current tests will run with the latest SVN version of PHPUnit 3.4. This code will eventually become PHPUnit 3.4.1. Thanks to Sebastian Bergmann for his excellent work on an excellent project!

==== Writing Unit Tests ====
At risk of stating the obvious, in the "purest" case the purpose of a unit test is to ''isolate a unit of code from its environment and to test the operation of that code''.

This isolation is usually achieved by writing dummy classes that emulate the code unit's environment. These dummy objects can be passive, by simply simulating the environment, or they can be more active, keeping track of how they are being used by the test unit and reporting any variations from the expected behaviour. See [[Unit_Testing_Mock_Objects|Mock Objects in Joomla]] for a detailed example.

An interesting aspect of writing tests is that they become ''de facto'' detailed technical specifications of the interfaces between units of code. The fact that these specifications can be verified in an automated way makes them a superb resource when refactoring code.

The test code has a few templates designed to kick-start a test. They are:

/unittest/sample-datatest-php.txt
/unittest/sample-simpletest.php.txt

Here are some example tests: [[Unit_Testing_--_a_Simple_Example|Simple Example]], [[Unit_Testing_--_Data_Driven_Example|Data Driven Example]], [[Unit_Testing_--_Plugin_Example|Plugin Example]], [[Unit_Testing_--_UI_Example|UI Example]].

==== Running Unit Tests ====
Test files follow the form class-sequence-type-Test.php, for example JObject-0000-class-Test.php. For tests that are not class based, the first element refers to the object being tested. An example of this is the e-mail cloaking plugin test, which is called emailcloak-0000-mode1-Test.php.

Joomla unit tests use the standard PHPUnit test runner. See www.phpunit.de for documentation.

== How to Get it Running ==

Before you start make sure you have installed PHPUnit and of course PHP (5!) properly...

To get the unit tests to run on your Joomla! installation, perform the following steps:
* Create an instance of your Joomla! installation
* In the root checkout (or export) the latest version of the unit test code from SVN ''"/testing/trunk"'' to your installation base. This will create a ''"/unittest"'' sub-folder under your joomla installation.
* Create a ''"TestConfiguration.php"'' file. You can copy a the file from ''"TestConfiguration-dist.php"'' that is part of the package you just have checked out.
* If you want to run a subset of the commands, change to the directory that contains those tests.
* Run the unit test from the command using the following command:

php runtests.php

The unit test will the run, and the results are rendered.

== Troubleshooting ==

The provided configurations should work out of the box. We have seen problems with it (currently the cause is unknown). If you get an error like below, the solution is pretty easy.

file=/var/www/unittest/runtests.php
posn=17
base=runtests.php
/var/www
JPATH_BASE does not point to a valid Joomla! installation:
JPATH_BASE = /var/www
Please modify your copy of "TestConfiguration.php"

Modify the ''"TestConfiguration.php"'' file and change the definition of the JPATH_BASE so it points to the path of you Joomla! installation, in the example below the Joomla! installation is installed at "''/var/www/update''".

define('JPATH_BASE', '/var/www/update');

== Frequently Asked Questions ==
'''Why can't I use "phpunit ''testname.php''" to run my tests?'''

The test facility has to do some work to be able to load the "Joomla!" framework and to be able to inject mock classes. It's difficult to do this from the PHPUnit test runner, so we built our own. Also, the Joomla test runner has specific options designed to make it easy to select specific tests. Over time we will add more functionality to the test runner so it has many of the capabilities of the phpunit command.

==See also==
[http://www.phpunit.de/manual/current/en/ PHPUnit Manual]

[[Category:Development]]