Joomla! Documentation - User contributions [en]

J3.x:Updating Joomla (Install Method)

2016-06-11T20:12:52Z

Sovainfo: try to conform to STE

<noinclude><languages /></noinclude>
<br />{{note|<translate>

'''Please note!'''
</translate>
<translate>

As of J3.5 you can no longer use this to update Joomla, use component Joomla! Update instead.<br />
Your webserver requires access to internet. As of J3.6 you can also update with a downloaded patch.</translate>|type=serious}}
<translate>
In some cases it may not be possible to use the Extension Manager: Update method to update your site. One reason for this might be that you are using a non-standard distribution (for example, a distribution with a different default language installed). Another reason might be that you don't have a reliable Internet connection to support automatic installation.</translate>

<translate>
In this case, you can still do an easy installation using the Extension Manager: Install screen. Like the Update screen, this method will do the database updates automatically and will completely update your system without any further steps.</translate>

<translate>
==Step 1: Make sure you have a current backup of your site== 
</translate>
<translate>
In many cases, your host will make periodic site backups.</translate>

<translate>
==Step 2: Locate the update file== 
</translate>
<translate>
Locate the required archive file (for example, .zip, .tag.gz, or tar.bz2 archive) for your version. If you are updating to an x.x.0 release (for example, from 1.7.3 to 2.5.0), this will normally be a file like Joomla_2.5.0-Stable-Update_Package.zip. If you are updating within the same release series (for example, 2.5.0 to 2.5.1), then the file will be named something like Joomla_2.5.0_to_2.5.1-Stable-Patch_Package.zip.</translate>

<translate>
At this point, you have three options:</translate>
<translate>
# Install from URL</translate>
<translate>
# Install from Directory</translate>
<translate>
# Upload Package File</translate>

<translate>
Install from URL is the easiest to do. With this option, the upgrade archive is loaded directly by the server, so it works well even if your local computer has a slow or unreliable Internet connection.</translate>

<translate>
Install from Directory is the safest method if the server itself has a slow Internet connection. With this method, you use FTP to load the unpacked update files into a temporary folder on the server. Then you point to that directory on the server for the installation.</translate>

<translate>
Upload Package File is fairly simple, but it requires that you have a good connection between your local computer and the server.</translate>

The screen below shows the Extension Manager: Install screen with the three options labeled.
[[Image:Update-screenshot-20120124-03-<translate>
en</translate>.png|frame|center]]

<translate>
===Install from URL=== 
</translate>
<translate>
This option is the easiest if the archive file is available on a Website.</translate>
<translate>
# In the Extension Manager: Install screen, enter the URL for the archive file in the Install URL field.</translate>
<translate>
# Press the Install button.</translate>
<translate>
The system will work for a period of time - up to two minutes or more for a full version update. Then a message indicating a successful installation will display.</translate>

<translate>
===Install from Directory=== 
</translate>
<translate>
This option requires that you unpack the archive file in a directory on your server. This is the best method if you have a slow Internet connection or you are experiencing timeouts during the update process.</translate>
<translate>
# Unpack the archive file in a temporary directory on your local machine.</translate>
<translate>
# Upload all the files in this directory (for example, using FTP) to a temporary directory that is visible to the Web server. For example, you can create a sub-directory under the tmp directory in your Joomla root. For this example, let's say the directory on the server is <code>/home/myuser/myjoomla/tmp/upgrade250</code>).</translate>
<translate>
# In the Extension Manager: Install screen, enter the full path of the temporary directory (on the server) from step 2 (for example, <code>/home/myuser/myjoomla/tmp/upgrade250</code>).</translate>
<translate>
# Press the Install button.</translate>
<translate>
The system will work for a short time (perhaps a minute or less, depending on your server). Then a message indicating a successful installation will display.</translate>

<translate>
===Upload a Package File=== 
</translate>
<translate>
This option requires that you first download the archive file to your local machine.</translate>
<translate>
# Download the file to your local computer.</translate>
<translate>
# In the Extension Manager: Install screen, click the Browse button next to the Package File field and browse to the archive file.</translate>
<translate>
# Press the Install button.</translate>
<translate>
The system will work for a period of time - up to two minutes or more for a full version update. Then a message indicating a successful installation will display.</translate>

<translate>
# Congratulations! At this point, your site is updated.</translate>
<translate>
'''Important:''' Clear your browser cache and check that your site is working correctly. See below Checking Your Site.</translate>

<noinclude>
<translate>

[[Category:Installation]]
[[Category:Joomla! 3.x]]
[[Category:Joomla! 3.5]]
[[Category:Joomla! 3.6]]
[[Category:Upgrading]]
[[Category:Update]]
[[Category:FAQ]]
</translate>
</noinclude>

J3.x:Updating Joomla (Install Method)

2016-06-11T09:44:59Z

Sovainfo: No longer supported since j3.5

<noinclude><languages /></noinclude>
<br />{{note|<translate>
'''Please note!'''
</translate>
<translate>
As of Joomla 3.5 the update distribution no longer contains the joomla.xml identifying it as a file extension.<br />
The consequence is that you can no longer apply the update with Extensions->Manage->Install, you need to use the component Joomla! Update.
Which means your webserver needs access to internet. As of J3.6 the component Joomla! Update also allows you to update with a downloaded patch.
Be aware that it is not possible to validate the patch, you need to point to a valid Joomla update package.</translate>|type=serious}}
In some cases it may not be possible to use the Extension Manager: Update method to update your site. One reason for this might be that you are using a non-standard distribution (for example, a distribution with a different default language installed). Another reason might be that you don't have a reliable Internet connection to support automatic installation.

In this case, you can still do an easy installation using the Extension Manager: Install screen. Like the Update screen, this method will do the database updates automatically and will completely update your system without any further steps.

==Step 1: Make sure you have a current backup of your site==
In many cases, your host will make periodic site backups.

==Step 2: Locate the update file==
Locate the required archive file (for example, .zip, .tag.gz, or tar.bz2 archive) for your version. If you are updating to an x.x.0 release (for example, from 1.7.3 to 2.5.0), this will normally be a file like Joomla_2.5.0-Stable-Update_Package.zip. If you are updating within the same release series (for example, 2.5.0 to 2.5.1), then the file will be named something like Joomla_2.5.0_to_2.5.1-Stable-Patch_Package.zip.

At this point, you have three options:
# Install from URL
# Install from Directory
# Upload Package File

Install from URL is the easiest to do. With this option, the upgrade archive is loaded directly by the server, so it works well even if your local computer has a slow or unreliable Internet connection.

Install from Directory is the safest method if the server itself has a slow Internet connection. With this method, you use FTP to load the unpacked update files into a temporary folder on the server. Then you point to that directory on the server for the installation.

Upload Package File is fairly simple, but it requires that you have a good connection between your local computer and the server.

The screen below shows the Extension Manager: Install screen with the three options labeled.
[[Image:Update-screenshot-20120124-03.png|frame|center]]

===Install from URL===
This option is the easiest if the archive file is available on a Website.
# In the Extension Manager: Install screen, enter the URL for the archive file in the Install URL field.
# Press the Install button.
The system will work for a period of time - up to two minutes or more for a full version update. Then a message indicating a successful installation will display.

===Install from Directory===
This option requires that you unpack the archive file in a directory on your server. This is the best method if you have a slow Internet connection or you are experiencing timeouts during the update process.
# Unpack the archive file in a temporary directory on your local machine.
# Upload all the files in this directory (for example, using FTP) to a temporary directory that is visible to the Web server. For example, you can create a sub-directory under the tmp directory in your Joomla root. For this example, let's say the directory on the server is <code>/home/myuser/myjoomla/tmp/upgrade250</code>).
# In the Extension Manager: Install screen, enter the full path of the temporary directory (on the server) from step 2 (for example, <code>/home/myuser/myjoomla/tmp/upgrade250</code>).
# Press the Install button.
The system will work for a short time (perhaps a minute or less, depending on your server). Then a message indicating a successful installation will display.

===Upload a Package File===
This option requires that you first download the archive file to your local machine.
# Download the file to your local computer.
# In the Extension Manager: Install screen, click the Browse button next to the Package File field and browse to the archive file.
# Press the Install button.
The system will work for a period of time - up to two minutes or more for a full version update. Then a message indicating a successful installation will display.

# Congratulations! At this point, your site is updated.
'''Important:''' Clear your browser cache and check that your site is working correctly. See below Checking Your Site

<noinclude>

</noinclude>

Help310:Users User Manager

2016-05-13T09:53:10Z

Sovainfo: /* How to access */ adjusted instructions to J3.5

User management interface.
==Description==
In this screen you have the ability to look at a list of your users and sort them in different ways. You can also edit and create users, groups and access levels.

==How to access==
You can access the User Manager by clicking on the '''Users''' listed on the left in the Control Panel. Alternatively, use top menu bar, {{rarr|Users,Manage}}.

==Screenshot==
[[Image:Help-3x-users-user-manager-users.png|670px]]

==Column Headers==
In the table containing the users from your Joomla! site, you will see different columns. Here you can read what they mean and what is displayed in that column.

{{Chunk30:colheader|Checkbox/en}}
*'''Name'''. The full name of the user.
*'''User Name'''. The name the user will log in as.
*'''Enabled'''. Whether or not the user is enabled.
*'''Activated'''. Whether or not the user is activated. Normally when a user registers from the front end, some type of activation is required. This is controlled by the New User Account Activation parameter in the Users Configuration → Component screen. See [[Help31:Components_Users_Configuration|Users Options - Component Settings]] for more information.
*'''User Groups'''. The list of groups that the user belongs to. Note that a user may belong to more than one group.
{{colheader|E-mail}}
{{colheader|Lastvisit}}
* '''Registration Date'''. The date the user was registered.
{{Chunk30:colheader|Id/en}}

==Toolbar==
At the top left you will see the toolbar:

[[Image:Help30-New-Edit-Activate-Block-Unblock-Delete-Options-Help-toolbar.png]]

The functions are:
{{Chunk30:Help_screen_toolbar_icon_New/en|user}}
{{Chunk30:Help_screen_toolbar_icon_Edit/en|user}}
{{Chunk30:Help_screen_toolbar_icon_Activate/en|users}}
{{Chunk30:Help_screen_toolbar_icon_Block/en|users}}
{{Chunk30:Help_screen_toolbar_icon_Unblock/en|users}}
{{Chunk30:Help_screen_toolbar_icon_Delete/en|users}}
{{Chunk30:Help_screen_toolbar_icon_Options/en}}
{{Chunk30:Help_screen_toolbar_icon_Help/en}}

==List Filters==
'''Filter by Partial User Name'''
*'''Search Users'''. In the upper left is a Search field and two buttons, as shown below.

[[Image:Help30-Users-User-Manager-search-filter-subscreen.png]]

Enter part of the user's name and press the Search to find matching names. Press Reset to clear the search field and restore the list of users.

'''Filter by User State, Active, Group, or Registration'''

Sidebar on left bottom, are four drop-down list boxes as shown below.

[[Image:Help30-Users-User-Manager-other-filter-subscreen.png]]

*'''State'''. Select the desired state (Enabled or Disabled) to limit the list based on state. Select "- State -" to list Enabled and Disabled users.
*'''Active'''. Select "Activated" to list only users that have been Activated. Select "Unactivated" to select only users who have not yet been activated. Select "- Active -" to select both type of users.
*'''Group'''. Select a group from the list box to list only users who are members of that group. Select "- Group -" to select users regardless of group.
*'''Registration Date'''. Select time frame from a list to show only users who registered in a selected time frame. Select "-Registration Date-" to select users regardless of registration date.

==Quick Tips==
*Click on the name of a user to edit the user's properties.
*Click on the icon in the Enabled column to toggle between Enabled and Disabled status.
*Click on the Column Headers to sort the users by that column, ascending or descending.
*To understand user and group permissions, read: [[Access Control List/1.6-2.5/Tutorial|ACL Tutorial for Joomla 1.6, 1.7 and 2.5]]

==Related information==
{{relatedhelp|Users}}

<noinclude>{{cathelp|3.0,3.1,3.2,3.3,3.4,3.5|User Manager Help Screens}}</noinclude>

Talk:How to restore a Joomla 2.5 site if you accidentally migrate to Joomla 3.x.x

2015-09-05T00:04:33Z

Sovainfo: Created page with "== Propose to remove this document == Suggest to remove this document. The part of reverting the database is not correct! Which means you have J2.5 scripts running against J3..."

== Propose to remove this document ==
Suggest to remove this document. The part of reverting the database is not correct! Which means you have J2.5 scripts running against J3 structure of database. By now I guess everybody knows Extension manager->Database->Fix is very inappropriately named. Can't think of a situation where it actually fixes anything. It certainly can't be used to repair a failed update. Nor can it be used to revert a J3 to J2.5 structure. It only applies structural changes when the structure is older than the scripts. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 19:04, 4 September 2015 (CDT)

Using nested sets

2015-06-08T12:12:35Z

Sovainfo: /* Deleting a node */ remove jrequest

Starting with version 11.1 the Joomla Platform now includes native support for storing and retrieving hierarchical information in the form of "nested sets" in database tables. This support is used in the implementation of menus and categories in the core Joomla CMS from version 1.6 onwards, but can of course be used in your own extensions too. This document assumes that you are already familiar with using the [[:Category:JTable|JTable]], [[:Category:JDatabase|JDatabase]] and JDatabaseQuery classes to interact with a database, either the Joomla database itself, or some external database.

==Introduction==
In the nested sets model each data item is stored as a row in the database table in the normal manner. However, additional columns are present in the table to express the hierarchical relationship between the data items. Each data item is referred to as a node and the collection of nodes can be thought of as forming a tree. Nodes can have zero, one or many child nodes. A node that has no children is referred to as a leaf node. A child node can itself have children and this nesting can carry on to arbitrary depth. The table is assumed to hold a single tree with a single node being allocated as the root node. If you need to be able to store multiple trees then simply make the root node of each such tree a child node under the single root node and adjust your code to take this into account.

As each node contains columns labelled "lft" and "rgt" for "left" and "right" respectively, it is tempting to think that the data structure is a binary tree. However, these columns do not store node ids as they are not links to other nodes in the tree, but instead store sequence information. More information can be found on the theory behind nested sets here<ref>[[wikipedia:Nested set model]].</ref> The term "nested sets" is a little inaccurate as a set is, stricly speaking, an unordered collection of objects. In the Joomla implementation the order of nodes under a parent node is preserved and API calls are available to manipulate the order. A better term would perhaps be "nested ordered sets".

It should be noted that certain operations, such as inserting a new node, can be expensive in terms of disk access when dealing with a large tree and applications should be designed with this in mind.

==Getting Started==
The essential class is JTableNested, which extends the base JTable class, so instead of extending JTable you should extend your table class from JTableNested instead.

Your table must include a number of standard columns that are required for JTableNested to maintain the tree structure successfully. These are:-

* id (primary key)
* parent_id
* lft
* rgt
* level
* title
* alias
* access
* path

The primary key does not need to be called "id", but it is required. Other columns must have the names listed above.

For example, a suitable MySQL command to create a basic table compatible with JTableNested would be
<source lang="sql">
CREATE TABLE IF NOT EXISTS `#__nestedsets` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`parent_id` int(10) unsigned NOT NULL DEFAULT '0',
`lft` int(11) NOT NULL DEFAULT '0',
`rgt` int(11) NOT NULL DEFAULT '0',
`level` int(10) unsigned NOT NULL DEFAULT '0',
`title` varchar(255) NOT NULL,
`alias` varchar(255) NOT NULL DEFAULT '',
`access` tinyint(3) unsigned NOT NULL DEFAULT '0',
`path` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `idx_left_right` (`lft`,`rgt`)
) DEFAULT CHARSET=utf8;
</source>
You will, of course, need to add further columns for your specific data requirements. For the purposes of this documentation a column called "payload" will be used to indicate this custom data.

==Instantiating the table object==
You instantiate the nested sets table object in exactly the same way as you would for a regular table object. For example, if your table class file is located in a <tt>/tables</tt> directory in your component area, you could use code like this:
<source lang="php">
JTable::addIncludePath(JPATH_COMPONENT . '/tables');
$table = JTable::getInstance('nestedsets', 'Table');
</source>
This will instantiate your table class called 'TableNestedSets' in the file 'nestedsets.php'. Remember to extend from JTableNested instead of JTable:
<source lang="php">
class TableNestedSets extends JTableNested
{
// Your properties and methods go here.
}
</source>

==Adding a root node==
The quickest way to add a root node to an otherwise empty table is to use code like this, which can be added to your table class:
<source lang="php">
/**
* Add the root node to an empty table.
*
* @return mixed The id of the new root node or false on error.
*/
public function addRoot()
{
$db = JFactory::getDbo();

$query = $db->getQuery(true)
->insert('#__profiles')
->set('parent_id = 0')
->set('lft = 0')
->set('rgt = 1')
->set('level = 0')
->set('title = ' . $db->quote('root'))
->set('alias = ' . $db->quote('root'))
->set('access = 1')
->set('path = ' . $db->quote(''));
$db->setQuery($query);

if(!$db->execute())
{
return false;
}

return $db->insertid();
}
</source>

It is perfectly reasonable to store payload data in the root node. For example, you might like to store component configuration data in the payload column of the root node.

==Getting the root node id==
To determine the id of the root node use the <tt>getRootId</tt> method. For example, in this example if the root node is not found, it is created.
<source lang="php">
$rootId = $table->getRootId();

if ($rootId === false)
{
$rootId = $table->addRoot();
}
</source>

==Updating a node==
Updating the payload data in a node is done in exactly the same way as you would update a record in a regular database table using the JTable class. Given an array of data fields, this code binds it to the table object, checks its validity then stores it in the database table.
<source lang="php">
$table->bind($data_array);
$table->check();
$table->store();
</source>
Updating a node in such a way that it alters the structure of the tree, for example, by moving a node from one location to another, is a little more involved and is described below. There are also some convenience methods for publishing/unpublished a node and these are also described in more detail below.

==Adding a new node==
Adding a new node to the table is done in a similar way to adding a row to a normal Joomla table. Data is bound to the Joomla table object using the bind method, followed by calls to check and store. These methods have been overridden in the JTableNested class to provide the additional functionality required for storing nested sets.

However, in order to determine where in the tree the new node is to be inserted, you need to make a call to the <tt>setLocation</tt> method. The setLocation method takes two arguments, the first is the id of a "reference" node in the tree. The new node will be inserted relative to this node with the relationship being specified by the second argument. Possible values for this relationship are:
* '''before''' - the new node will be inserted before the reference node but at the same level.
* '''after''' - the new node will be inserted after the reference node but at the same level.
* '''first-child''' - the new node will be inserted as the first child node of the reference node.
* '''last-child''' - the new node will be inserted as the last child node of the reference node.

In this example a new node is inserted as the first child of the reference node.
<source lang="php">
// Given an array of data fields in $data_array and a reference node id in $reference_id,
// this code will add the new node as the first child of the reference node.

// Get the table object.
// Note that in a model you can replace this with $table = $this->getTable();
$table = JTable::getInstance('yourtable');

// Specify where to insert the new node.
$table->setLocation($reference_id, 'first-child');

// Bind data to the table object.
$table->bind($data_array);

// Force a new node to be created.
$table->id = 0;

// Check that the node data is valid.
$table->check();

// Store the node in the database table.
$table->store();
</source>
In order to maintain the integrity of the data structure, the table is locked during a node insertion operation. Bear in mind that adding a new node to a large table is an expensive operation so the table could potentially be locked for a considerable period. You may need to take this into account when designing your application.

==Retrieving a single node by id==
If you know the id of a node then retrieving it can be done in the same way that you would retrieve a row in a regular Joomla table. For example,
<source lang="php">
// Get the node id from the request.
$id = JRequest::getInt('id');

// Get the node from the table.
$table->load($id);
</source>

==Is it a leaf node?==
A leaf node is one that has no child nodes beneath it. To determine if a node is a leaf node you can use code like the following:
<source lang="php">
// If $id is the id of a node, determine if it is a leaf node.
if ($table->isLeaf($id))
{
echo 'This is a leaf node';
}
else
{
echo 'This is NOT a leaf node';
}
</source>

==Retrieving a subtree==
To retrieve an entire subtree given the id of the base node of the subtree, you can use code like the following
<source lang="php">
// If $id is the id of a node, retrieve the subtree with this node as its root.
$subtree = $table->getTree($id);
print_r($subtree);
</source>
This will retrieve an array of all the nodes in the subtree. The array is one-dimensional and lists the nodes in preorder traversal order<ref>[[wikipedia:Tree traversal]]</ref>. Note that if your table is large calling getTree() from the root node will retrieve the entire table and very likely run you out of memory, so use it with caution.

==Retrieving a path==
To retrieve all the nodes along the path leading to a specified node, you can use code like this:
<source lang="php">
$pathNodes = $table->getPath($id);
print_r($pathNodes);
</source>
This will retrieve a one-dimensional array of all the nodes from the root node along the path leading to the specified node.

==Publish or unpublish a node or an entire branch==
Supporting the publish/unpublish feature is a little more involved than with a regular flat database table as the state of parent and child nodes must also be taken into account. Fortunately, the overridden publish and unpublish methods provided by JTableNested make the management of publish/unpublish almost transparent.

To publish or unpublish one or more nodes use code like the following:
<source lang="php">
// $ids can be a single node id, or an array of node ids.
// 0 = unpublish, 1 = publish
$state = 1;
$userId = JFactory::getUser()->id;

if ($table->publish($id, $state, $userId))
{
echo 'State changed successfully';
}
else
{
echo 'State not changed';
}
</source>
The publish method respects rows checked out by other users and will attempt to checkin rows that it can after adjustments are made. The method will not allow you to set a publishing state higher than any ancestor node and will not allow you to set a publishing state on a node with a checked out child.

TODO: Using publish/unpublish with checkin/out requires some additional columns in the table. The documentation should be updated to reflect that.

==Changing the order of nodes in a branch==
There are a number of different ways of moving a node to a new location in the tree.

To move a node one position before or after its current position, but keeping it at the same level, you can use the orderUp or orderDown methods using code like the following:
<source lang="php">
if ($table->orderUp($id))
{
echo 'Success';
}
else
{
echo 'Failed to move node';
}
</source>

More generally, you can move a node by more than one position at a time using the <tt>move</tt> method. For example, the following code moves the node 2 positions before its current position, at the same level.
<source lang="php">
// Get the node id to be moved from the request.
$key = $this->_tbl_key;
$this->$key = JRequest::getInt('id');

// Set the direction and magnitude of the move.
// Negative indicates "before", positive "after"
$delta = -2;

// Do the move.
// Notice that the node id is not passed as an argument to
// move; it must already be set in the table object.
if ($table->move($delta))
{
echo 'Success';
}
else
{
echo 'Failed to move node';
}
</source>

In the most general case, a node can be moved to an arbitrary position in the tree using the <tt>moveByReference</tt> method. This is very similar to adding a completely new node to the tree in that you need to specify the location to move the node to by reference to some other node.

In this example a new node is inserted as the last child of the reference node.
<source lang="php">
// Determine the reference node id.
$reference_id = JRequest::getInt('reference');

// Determine the relationship with the reference node. Possible values are:-
// before - the new node will be inserted before the reference node but at the same level.
// after - the new node will be inserted after the reference node but at the same level.
// first-child - the new node will be inserted as the first child node of the reference node.
// last-child - the new node will be inserted as the last child node of the reference node.
$relation = 'last-child';

// Determine the node to be moved.
$node_id = JRequest::getInt('id');

// Do the move.
if ($table->moveByReference($reference_id, $relation, $node_id))
{
echo 'Success';
}
else
{
echo 'Failed to move node';
}
</source>

==Deleting a node==
Deleting a node given its node id is very simple as the following example illustrates:
<source lang="php">
// Determine the node id from the request.
$node_id = JFactory::getApplication()->input->get('id');

// Delete the node.
if ($table->delete($node_id))
{
echo 'Node deleted';
}
else
{
echo 'Failed to delete node';
}
</source>
Note that this operation will also delete all child nodes of the node being deleted, if any are present.

==References==
<references/>
<noinclude>[[Category:Platform 11.1]][[Category:Development Tips and Tricks]]</noinclude>

J1.5:Using the JTable class

2015-06-08T11:34:10Z

Sovainfo: /* Using a JTable class extension */ remove &

This tutorial is for {{JVer|1.5}} In Joomla! 1.5.

== Writing an extension of JTable ==

The [http://api.joomla.org/1.5/Joomla-Framework/Table/JTable.html JTable] class is an implementation of the [http://en.wikipedia.org/wiki/Active_record_pattern Active Record] design pattern. It is used throughout Joomla! for [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete creating, reading, updating, and deleting] records in the database table.

To use JTable, create an extension of the class. In this example, we have a database table containing recipes.

<source lang="php">
<?php

defined('_JEXEC') or die();

class TableRecipes extends JTable
{
var $id = null;
var $ingredients = null;
var $instructions = null;
var $serves = null;
var $difficulty = null;
var $prep_time = null;
var $cook_time = null;
var $published = 0;

function __construct(&$db)
{
parent::__construct( '#__recipes', 'id', $db );
}
}
</source>

When naming your class extension, the convention is to prefix it with 'Table', then follow with a [http://en.wikipedia.org/wiki/CamelCase CamelCased] version of the table's name. All of the member variables of your class should match the column names in the database. The default values should be valid according to the table schema For instance, if you have columns that are NOT NULL, you must use a value other than 'null' as the default.

An important thing to note here, is that the file containing your table class, has to be named the same as the class minus prefix in lowercase. So for this example, you would have to name your table class file 'recipes.php'.

Finally, create a constructor for the class that accepts a reference to the current database instance. This will call the parent constructor which needs the name of the table, the name of the primary key column, and the database instance. The name of the table uses #__ instead of jos_, as the administrator can pick any table prefix desired during Joomla! installation.

If you were using this class as a part of a component called 'Recipes', you would place this code in the file /administrator/components/com_recipes/tables/recipes.php.

You can use this functionallity just as well outside components, i.e. in plugins and modules. As a general rule you should avoid writing to the database from a module, and use plugins/components for this. Remember to use the built-in [[constants]] when linking to a custom path (outside the 'adminstrator/{com_yourcomponent}/tables' folder).

== Using a JTable class extension ==

Once the table class is in place, you can use it in any Joomla! extension. To include the file, place this line in your extension's source code (use com_nameofyourcomponent in place of com_recipes):

<source lang="php">
JTable::addIncludePath(JPATH_ADMINISTRATOR . '/components/com_recipes/tables');
</source>

To get an instance of the object, use this code:

<source lang="php">
$row = JTable::getInstance('recipes', 'Table');
</source>

If doesn't work use:
<source lang="php">
$row = JTable::getInstance('recipes', 'NAMEOFCOMPONENTTable');
</source>
(Where NAMEOFCOMPONENT is the name of the component that contais the table).

Notice that the lowercase version of the suffix of your class name is used as the first parameter, with the prefix 'Table' as the second. Also, the getInstance() member function of JTable returns the object by reference instead of value; use =& to enforce this.

In a model class (extends JModel) you can also use:

<source lang="php">
$row = $this->getTable('recipes');
</source>

Notice that if you have not used the standard naming convention, you can supply the class prefix as the optional second parameter.

=== Checkout/Checkin ===
Common scenario is when multiple users are editing identical item (e.g article, category, user and etc) simultaneously, which in turn, may results in arbitrary data when saved by the users (depends on who last saved the item). Joomla! solves such cases of unknown modification ownership using Checkouts and Checkins in order to provide access only to one user at a time. For example, if one user began editing an article, then it is said that the article was '''checked out''' by the user, when finished working with the article (usually by closing it using a button), the article is '''checked in''' by the user. At the time the user was editing the article, no other user could edit the same article, unless manually specified by a user with the right permissions. You can find further explanation [http://help.joomla.org/content/view/202/153/ here].
The following examples demonstrate how Checkout/Checkin may be implemented.

'''Checkout'''
<source lang="php">
// retrieve item identifier from request
$itemId = JRequest::getInt('itemId');
// the user to test checkout with, could be any other user you want
$user = JFactory::getUser();

// load the item's data so we'll know with what item were dealing with
if (!$row->load($itemId)) {
return JError::raiseWarning( 500, $row->getError() );
}

// check out the item
if ($row->checkout($user->id)) {
echo 'Item was checked out by the user.';
} else {
return JError::raiseWarning( 500, $row->getError() );
}
</source>
'''checkout()''' will signal the item was checked out by the user whom ID we provided as an argument to the method.

'''Checkin'''
<source lang="php">
// retrieve item identifier from request
$itemId = JRequest::getInt('itemId');
// the user to test checkout with, could be any other user you want
$user = JFactory::getUser();

// load the item's data so we'll know with what item were dealing with
if (!$row->load($itemId)) {
return JError::raiseWarning( 500, $row->getError() );
}

// check if the item was checked out, and if it does - whether or not it was checked out by the user
if($row->isCheckedOut($user->id)) {
// check in the item
if ($row->checkin()) {
echo 'The item was checked in, and can now be edited by other users.';
} else {
return JError::raiseWarning( 500, $row->getError() );
}
}
</source>
We use '''isCheckedOut()''' to find out whether the item was checked out, it returns TRUE in the following cases:
<ul>
<li>Item is empty (i.e no data was loaded to the item).</li>
<li>The item does not support checkout, which can be as a result of database design.</li>
<li>The supplied user ID does not match the ID of the user who checked out the item, meaning the item is probably being edited by another user already, or the user who last checked out the item did not properly checked in the item. '''This is probably the most common scenario''' when dealing with items in the backend.</li>
</ul>
'''isCheckedOut()''' returns FALSE in the following cases:
<ul>
<li>The item was not checked out by any user.</li>
<li>The item was checked out, but by the same user who checked it out (i.e the user with the ID we passed to isCheckedOut()).
</ul>

'''checkin()''' will purge any checkout state that was applied to the item.

=== Create/Update ===
In a typical situation, you will have an HTML form submitted by the user which will PHP will interpret for you as an associative array. The JRequest class in Joomla! has functions ready to assist with retrieving this data safely. Use JRequest::get('post') to retrieve all of the elements in the HTTP POST request as a sanitized array.

Once you have this array, you can pass it into the bind() method of JTable. Doing this will match the associated items of the array with member variables of the class. In the following example, the array is retrieved from JRequest::get('post') and immediately passed into bind().

<source lang="php">
if (!$row->bind( JRequest::get( 'post' ) )) {
return JError::raiseWarning( 500, $row->getError() );
}
</source>

If bind() fails, you want to stop the application and explain the failure before your extension attempts to send the data. The raiseWarning() function of JError allows you to stop Joomla!, while the getError() function returns the error message stored in the JTable object.

When binding succeeds and your object is ready, call the store() function. Again, if something goes wrong, stop the application and explain why.

<source lang="php">
if (!$row->store()) {
JError::raiseError(500, $row->getError() );
}
</source>

Notes:
* If any member variables of your JTable object are null when store() is called, they are ignored by default. This allows you to update specific columns of your table, while leaving the others untouched. If you wish to override this behavior to ensure that all columns have a value, pass true into store().
* The JTable::bind() and JRequest::get() functions do not enforce data types. If you need a column to be a specific type (for instance, integer), you need to add this logic to your code before calling store().

=== Read ===
To load a specific row of the database with JTable, pass the key into the load() member function.

<source lang="php">
$row->load( $id );
</source>

This relies on the key column you specified in the second parameter of parent::__construct() when you extended JTable.

=== Delete ===
Like read(), delete() allows you to destroy a specific row in the table based on the key specified earlier.

<source lang="php">
$row->delete( $id );
</source>

If you want to delete multiple rows at once, you will need to write the query manually.

== Member Functions ==
{{jfr summary|class=JTable|methods=yes}}

== Summary ==
When properly extended, JTable gives you all of the basic functions you need for managing and retrieving records in a database table. Member functions take care of the rest when you add member variables, the table name, and the key column.

[[Category:Archived version Joomla! 1.5]]

J1.5:Using the JTable class

2015-06-08T11:33:26Z

Sovainfo: /* Using a JTable class extension */ remove &

This tutorial is for {{JVer|1.5}} In Joomla! 1.5.

== Writing an extension of JTable ==

The [http://api.joomla.org/1.5/Joomla-Framework/Table/JTable.html JTable] class is an implementation of the [http://en.wikipedia.org/wiki/Active_record_pattern Active Record] design pattern. It is used throughout Joomla! for [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete creating, reading, updating, and deleting] records in the database table.

To use JTable, create an extension of the class. In this example, we have a database table containing recipes.

<source lang="php">
<?php

defined('_JEXEC') or die();

class TableRecipes extends JTable
{
var $id = null;
var $ingredients = null;
var $instructions = null;
var $serves = null;
var $difficulty = null;
var $prep_time = null;
var $cook_time = null;
var $published = 0;

function __construct(&$db)
{
parent::__construct( '#__recipes', 'id', $db );
}
}
</source>

When naming your class extension, the convention is to prefix it with 'Table', then follow with a [http://en.wikipedia.org/wiki/CamelCase CamelCased] version of the table's name. All of the member variables of your class should match the column names in the database. The default values should be valid according to the table schema For instance, if you have columns that are NOT NULL, you must use a value other than 'null' as the default.

An important thing to note here, is that the file containing your table class, has to be named the same as the class minus prefix in lowercase. So for this example, you would have to name your table class file 'recipes.php'.

Finally, create a constructor for the class that accepts a reference to the current database instance. This will call the parent constructor which needs the name of the table, the name of the primary key column, and the database instance. The name of the table uses #__ instead of jos_, as the administrator can pick any table prefix desired during Joomla! installation.

If you were using this class as a part of a component called 'Recipes', you would place this code in the file /administrator/components/com_recipes/tables/recipes.php.

You can use this functionallity just as well outside components, i.e. in plugins and modules. As a general rule you should avoid writing to the database from a module, and use plugins/components for this. Remember to use the built-in [[constants]] when linking to a custom path (outside the 'adminstrator/{com_yourcomponent}/tables' folder).

== Using a JTable class extension ==

Once the table class is in place, you can use it in any Joomla! extension. To include the file, place this line in your extension's source code (use com_nameofyourcomponent in place of com_recipes):

<source lang="php">
JTable::addIncludePath(JPATH_ADMINISTRATOR . '/components/com_recipes/tables');
</source>

To get an instance of the object, use this code:

<source lang="php">
$row = JTable::getInstance('recipes', 'Table');
</source>

If doesn't work use:
<source lang="php">
$row = JTable::getInstance('recipes', 'NAMEOFCOMPONENTTable');
</source>
(Where NAMEOFCOMPONENT is the name of the component that contais the table).

Notice that the lowercase version of the suffix of your class name is used as the first parameter, with the prefix 'Table' as the second. Also, the getInstance() member function of JTable returns the object by reference instead of value; use =& to enforce this.

In a model class (extends JModel) you can also use:

<source lang="php">
$row =& $this->getTable('recipes');
</source>

Notice that if you have not used the standard naming convention, you can supply the class prefix as the optional second parameter.

=== Checkout/Checkin ===
Common scenario is when multiple users are editing identical item (e.g article, category, user and etc) simultaneously, which in turn, may results in arbitrary data when saved by the users (depends on who last saved the item). Joomla! solves such cases of unknown modification ownership using Checkouts and Checkins in order to provide access only to one user at a time. For example, if one user began editing an article, then it is said that the article was '''checked out''' by the user, when finished working with the article (usually by closing it using a button), the article is '''checked in''' by the user. At the time the user was editing the article, no other user could edit the same article, unless manually specified by a user with the right permissions. You can find further explanation [http://help.joomla.org/content/view/202/153/ here].
The following examples demonstrate how Checkout/Checkin may be implemented.

'''Checkout'''
<source lang="php">
// retrieve item identifier from request
$itemId = JRequest::getInt('itemId');
// the user to test checkout with, could be any other user you want
$user = JFactory::getUser();

// load the item's data so we'll know with what item were dealing with
if (!$row->load($itemId)) {
return JError::raiseWarning( 500, $row->getError() );
}

// check out the item
if ($row->checkout($user->id)) {
echo 'Item was checked out by the user.';
} else {
return JError::raiseWarning( 500, $row->getError() );
}
</source>
'''checkout()''' will signal the item was checked out by the user whom ID we provided as an argument to the method.

'''Checkin'''
<source lang="php">
// retrieve item identifier from request
$itemId = JRequest::getInt('itemId');
// the user to test checkout with, could be any other user you want
$user = JFactory::getUser();

// load the item's data so we'll know with what item were dealing with
if (!$row->load($itemId)) {
return JError::raiseWarning( 500, $row->getError() );
}

// check if the item was checked out, and if it does - whether or not it was checked out by the user
if($row->isCheckedOut($user->id)) {
// check in the item
if ($row->checkin()) {
echo 'The item was checked in, and can now be edited by other users.';
} else {
return JError::raiseWarning( 500, $row->getError() );
}
}
</source>
We use '''isCheckedOut()''' to find out whether the item was checked out, it returns TRUE in the following cases:
<ul>
<li>Item is empty (i.e no data was loaded to the item).</li>
<li>The item does not support checkout, which can be as a result of database design.</li>
<li>The supplied user ID does not match the ID of the user who checked out the item, meaning the item is probably being edited by another user already, or the user who last checked out the item did not properly checked in the item. '''This is probably the most common scenario''' when dealing with items in the backend.</li>
</ul>
'''isCheckedOut()''' returns FALSE in the following cases:
<ul>
<li>The item was not checked out by any user.</li>
<li>The item was checked out, but by the same user who checked it out (i.e the user with the ID we passed to isCheckedOut()).
</ul>

'''checkin()''' will purge any checkout state that was applied to the item.

=== Create/Update ===
In a typical situation, you will have an HTML form submitted by the user which will PHP will interpret for you as an associative array. The JRequest class in Joomla! has functions ready to assist with retrieving this data safely. Use JRequest::get('post') to retrieve all of the elements in the HTTP POST request as a sanitized array.

Once you have this array, you can pass it into the bind() method of JTable. Doing this will match the associated items of the array with member variables of the class. In the following example, the array is retrieved from JRequest::get('post') and immediately passed into bind().

<source lang="php">
if (!$row->bind( JRequest::get( 'post' ) )) {
return JError::raiseWarning( 500, $row->getError() );
}
</source>

If bind() fails, you want to stop the application and explain the failure before your extension attempts to send the data. The raiseWarning() function of JError allows you to stop Joomla!, while the getError() function returns the error message stored in the JTable object.

When binding succeeds and your object is ready, call the store() function. Again, if something goes wrong, stop the application and explain why.

<source lang="php">
if (!$row->store()) {
JError::raiseError(500, $row->getError() );
}
</source>

Notes:
* If any member variables of your JTable object are null when store() is called, they are ignored by default. This allows you to update specific columns of your table, while leaving the others untouched. If you wish to override this behavior to ensure that all columns have a value, pass true into store().
* The JTable::bind() and JRequest::get() functions do not enforce data types. If you need a column to be a specific type (for instance, integer), you need to add this logic to your code before calling store().

=== Read ===
To load a specific row of the database with JTable, pass the key into the load() member function.

<source lang="php">
$row->load( $id );
</source>

This relies on the key column you specified in the second parameter of parent::__construct() when you extended JTable.

=== Delete ===
Like read(), delete() allows you to destroy a specific row in the table based on the key specified earlier.

<source lang="php">
$row->delete( $id );
</source>

If you want to delete multiple rows at once, you will need to write the query manually.

== Member Functions ==
{{jfr summary|class=JTable|methods=yes}}

== Summary ==
When properly extended, JTable gives you all of the basic functions you need for managing and retrieving records in a database table. Member functions take care of the rest when you add member variables, the table name, and the key column.

[[Category:Archived version Joomla! 1.5]]

J1.5:Using the JTable class

2015-06-08T11:29:40Z

Sovainfo: /* Using a JTable class extension */

This tutorial is for {{JVer|1.5}} In Joomla! 1.5.

== Writing an extension of JTable ==

The [http://api.joomla.org/1.5/Joomla-Framework/Table/JTable.html JTable] class is an implementation of the [http://en.wikipedia.org/wiki/Active_record_pattern Active Record] design pattern. It is used throughout Joomla! for [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete creating, reading, updating, and deleting] records in the database table.

To use JTable, create an extension of the class. In this example, we have a database table containing recipes.

<source lang="php">
<?php

defined('_JEXEC') or die();

class TableRecipes extends JTable
{
var $id = null;
var $ingredients = null;
var $instructions = null;
var $serves = null;
var $difficulty = null;
var $prep_time = null;
var $cook_time = null;
var $published = 0;

function __construct(&$db)
{
parent::__construct( '#__recipes', 'id', $db );
}
}
</source>

When naming your class extension, the convention is to prefix it with 'Table', then follow with a [http://en.wikipedia.org/wiki/CamelCase CamelCased] version of the table's name. All of the member variables of your class should match the column names in the database. The default values should be valid according to the table schema For instance, if you have columns that are NOT NULL, you must use a value other than 'null' as the default.

An important thing to note here, is that the file containing your table class, has to be named the same as the class minus prefix in lowercase. So for this example, you would have to name your table class file 'recipes.php'.

Finally, create a constructor for the class that accepts a reference to the current database instance. This will call the parent constructor which needs the name of the table, the name of the primary key column, and the database instance. The name of the table uses #__ instead of jos_, as the administrator can pick any table prefix desired during Joomla! installation.

If you were using this class as a part of a component called 'Recipes', you would place this code in the file /administrator/components/com_recipes/tables/recipes.php.

You can use this functionallity just as well outside components, i.e. in plugins and modules. As a general rule you should avoid writing to the database from a module, and use plugins/components for this. Remember to use the built-in [[constants]] when linking to a custom path (outside the 'adminstrator/{com_yourcomponent}/tables' folder).

== Using a JTable class extension ==

Once the table class is in place, you can use it in any Joomla! extension. To include the file, place this line in your extension's source code (use com_nameofyourcomponent in place of com_recipes):

<source lang="php">
JTable::addIncludePath(JPATH_ADMINISTRATOR . '/components/com_recipes/tables');
</source>

To get an instance of the object, use this code:

<source lang="php">
$row =& JTable::getInstance('recipes', 'Table');
</source>

If doesn't work use:
<source lang="php">
$row =& JTable::getInstance('recipes', 'NAMEOFCOMPONENTTable');
</source>
(Where NAMEOFCOMPONENT is the name of the component that contais the table).

Notice that the lowercase version of the suffix of your class name is used as the first parameter, with the prefix 'Table' as the second. Also, the getInstance() member function of JTable returns the object by reference instead of value; use =& to enforce this.

In a model class (extends JModel) you can also use:

<source lang="php">
$row =& $this->getTable('recipes');
</source>

Notice that if you have not used the standard naming convention, you can supply the class prefix as the optional second parameter.

=== Checkout/Checkin ===
Common scenario is when multiple users are editing identical item (e.g article, category, user and etc) simultaneously, which in turn, may results in arbitrary data when saved by the users (depends on who last saved the item). Joomla! solves such cases of unknown modification ownership using Checkouts and Checkins in order to provide access only to one user at a time. For example, if one user began editing an article, then it is said that the article was '''checked out''' by the user, when finished working with the article (usually by closing it using a button), the article is '''checked in''' by the user. At the time the user was editing the article, no other user could edit the same article, unless manually specified by a user with the right permissions. You can find further explanation [http://help.joomla.org/content/view/202/153/ here].
The following examples demonstrate how Checkout/Checkin may be implemented.

'''Checkout'''
<source lang="php">
// retrieve item identifier from request
$itemId = JRequest::getInt('itemId');
// the user to test checkout with, could be any other user you want
$user = JFactory::getUser();

// load the item's data so we'll know with what item were dealing with
if (!$row->load($itemId)) {
return JError::raiseWarning( 500, $row->getError() );
}

// check out the item
if ($row->checkout($user->id)) {
echo 'Item was checked out by the user.';
} else {
return JError::raiseWarning( 500, $row->getError() );
}
</source>
'''checkout()''' will signal the item was checked out by the user whom ID we provided as an argument to the method.

'''Checkin'''
<source lang="php">
// retrieve item identifier from request
$itemId = JRequest::getInt('itemId');
// the user to test checkout with, could be any other user you want
$user = JFactory::getUser();

// load the item's data so we'll know with what item were dealing with
if (!$row->load($itemId)) {
return JError::raiseWarning( 500, $row->getError() );
}

// check if the item was checked out, and if it does - whether or not it was checked out by the user
if($row->isCheckedOut($user->id)) {
// check in the item
if ($row->checkin()) {
echo 'The item was checked in, and can now be edited by other users.';
} else {
return JError::raiseWarning( 500, $row->getError() );
}
}
</source>
We use '''isCheckedOut()''' to find out whether the item was checked out, it returns TRUE in the following cases:
<ul>
<li>Item is empty (i.e no data was loaded to the item).</li>
<li>The item does not support checkout, which can be as a result of database design.</li>
<li>The supplied user ID does not match the ID of the user who checked out the item, meaning the item is probably being edited by another user already, or the user who last checked out the item did not properly checked in the item. '''This is probably the most common scenario''' when dealing with items in the backend.</li>
</ul>
'''isCheckedOut()''' returns FALSE in the following cases:
<ul>
<li>The item was not checked out by any user.</li>
<li>The item was checked out, but by the same user who checked it out (i.e the user with the ID we passed to isCheckedOut()).
</ul>

'''checkin()''' will purge any checkout state that was applied to the item.

=== Create/Update ===
In a typical situation, you will have an HTML form submitted by the user which will PHP will interpret for you as an associative array. The JRequest class in Joomla! has functions ready to assist with retrieving this data safely. Use JRequest::get('post') to retrieve all of the elements in the HTTP POST request as a sanitized array.

Once you have this array, you can pass it into the bind() method of JTable. Doing this will match the associated items of the array with member variables of the class. In the following example, the array is retrieved from JRequest::get('post') and immediately passed into bind().

<source lang="php">
if (!$row->bind( JRequest::get( 'post' ) )) {
return JError::raiseWarning( 500, $row->getError() );
}
</source>

If bind() fails, you want to stop the application and explain the failure before your extension attempts to send the data. The raiseWarning() function of JError allows you to stop Joomla!, while the getError() function returns the error message stored in the JTable object.

When binding succeeds and your object is ready, call the store() function. Again, if something goes wrong, stop the application and explain why.

<source lang="php">
if (!$row->store()) {
JError::raiseError(500, $row->getError() );
}
</source>

Notes:
* If any member variables of your JTable object are null when store() is called, they are ignored by default. This allows you to update specific columns of your table, while leaving the others untouched. If you wish to override this behavior to ensure that all columns have a value, pass true into store().
* The JTable::bind() and JRequest::get() functions do not enforce data types. If you need a column to be a specific type (for instance, integer), you need to add this logic to your code before calling store().

=== Read ===
To load a specific row of the database with JTable, pass the key into the load() member function.

<source lang="php">
$row->load( $id );
</source>

This relies on the key column you specified in the second parameter of parent::__construct() when you extended JTable.

=== Delete ===
Like read(), delete() allows you to destroy a specific row in the table based on the key specified earlier.

<source lang="php">
$row->delete( $id );
</source>

If you want to delete multiple rows at once, you will need to write the query manually.

== Member Functions ==
{{jfr summary|class=JTable|methods=yes}}

== Summary ==
When properly extended, JTable gives you all of the basic functions you need for managing and retrieving records in a database table. Member functions take care of the rest when you add member variables, the table name, and the key column.

[[Category:Archived version Joomla! 1.5]]

J3.x:Creating a Plugin for Joomla

2015-05-15T16:30:13Z

Sovainfo: remove text from die

<noinclude><languages /></noinclude>
<noinclude>{{Joomla version|version=3.x|comment=<translate>
series</translate>}}</noinclude>
<translate>

The plugin structure for Joomla! 1.5 was very flexible and powerful. Not only can plugins be used to handle events triggered by the core application and extensions, but plugins can also be used to make third party extensions extensible and powerful. The main change from Joomla! 1.5 to the 2.5/3.x series was the change in the names of events.
</translate>

<translate>

This How-To should provide you with the basics of what you need to know to develop your own plugin. Most plugins consist of just a single code file but to correctly install the plugin code it must be packaged into an installation file which can be processed by the Joomla! installer.
</translate>

<translate>
=== Creating the Installation File === 
As with all extensions in Joomla, plugins are easily installed as a .zip file (.tar.gz is also supported) but a correctly formatted XML file must be included. As an example, here is the XML installation file for the categories search plugin.
</translate>

<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<extension version="3.1" type="plugin" group="search">
<name>plg_search_categories</name>
<author>Joomla! Project</author>
<creationDate>November 2005</creationDate>
<copyright>Copyright (C) 2005 - 2013 Open Source Matters. All rights reserved.</copyright>
<license>GNU General Public License version 2 or later; see LICENSE.txt</license>
<authorEmail>admin@joomla.org</authorEmail>
<authorUrl>www.joomla.org</authorUrl>
<version>3.1.0</version>
<description>PLG_SEARCH_CATEGORIES_XML_DESCRIPTION</description>
<files>
<filename plugin="categories">categories.php</filename>
<filename>index.html</filename>
</files>
<languages>
<language tag="en-GB">en-GB.plg_search_categories.ini</language>
<language tag="en-GB">en-GB.plg_search_categories.sys.ini</language>
</languages>
<config>
<fields name="params">

<fieldset name="basic">
<field name="search_limit" type="text"
default="50"
description="JFIELD_PLG_SEARCH_SEARCHLIMIT_DESC"
label="JFIELD_PLG_SEARCH_SEARCHLIMIT_LABEL"
size="5"
/>

<field name="search_content" type="radio"
default="0"
description="JFIELD_PLG_SEARCH_ALL_DESC"
label="JFIELD_PLG_SEARCH_ALL_LABEL"
>
<option value="0">JOFF</option>
<option value="1">JON</option>
</field>

<field name="search_archived" type="radio"
default="0"
description="JFIELD_PLG_SEARCH_ARCHIVED_DESC"
label="JFIELD_PLG_SEARCH_ARCHIVED_LABEL"
>
<option value="0">JOFF</option>
<option value="1">JON</option>
</field>
</fieldset>

</fields>
</config>
</extension>
</source>

<translate>

As you can see, the system is similar to other Joomla! XML installation files. You only have to look out for the <code>group="xxx"</code> entry in the <code><extension></code> tag and the extended information in the <code><filename></code> tag. This information tells Joomla! into which folder to copy the file and to which group the plugin should be added.
</translate>

<translate>

If you are creating a plugin that responds to existing core events, the <code>group="xxx"</code> attribute would be changed to reflect the name of existing plugin folder for the event type you wish to augment. e.g. <code>group="authentication"</code> or <code>group="user"</code>. See [[S:MyLanguage/Plugin/Events|Plugin/Events]] for a complete list of existing core event categories. In creating a new plugin to respond to core events it is important that your plugin's name is unique and does not conflict with any of the other plugins that may also be responding to the core event you wish to service as well.
</translate>

<translate>

If you are creating a plugin to respond to non-core system events your choice for the <code>group="xxx"</code> tag should be different than any of the existing core categories.
</translate>

<translate>

'''Tip''' If you add the attribute <code>method="upgrade"</code> to the tag <code>extension</code>, this plugin can be installed without uninstalling an earlier version. All existing files will be overwritten, but old files will not be deleted.
</translate>

<translate>
=== Creating the Plugin === 
The object-oriented way of writing plugins involves writing a subclass of [http://api.joomla.org/Joomla-Platform/Plugin/JPlugin.html JPlugin], a base class that implements the basic properties of plugins. In your methods, the following properties are available:
</translate>

<translate>

* <code>$this->params</code>: the [[S:MyLanguage/Parameter|parameters]] set for this plugin by the administrator
* <code>$this->_name</code>: the name of the plugin
* <code>$this->_type</code>: the group (type) of the plugin
* <code>$this->db</code>: the db object (since {{JVer|3.1}})
* <code>$this->app</code>: the application object (since {{JVer|3.1}})
</translate>

<translate>

In the following code example, <code><PluginGroup></code> represents the group (type) of the plugin, and <code><PluginName></code> represents its name. Note that class and function names in PHP are case-insensitive.
</translate>

<source lang="php">
<?php
// no direct access
defined( '_JEXEC' ) or die;

class plg<PluginGroup><PluginName> extends JPlugin
{
/**
* Load the language file on instantiation. Note this is only available in Joomla 3.1 and higher.
* If you want to support 3.0 series you must override the constructor
*
* @var boolean
* @since 3.1
*/
protected $autoloadLanguage = true;

/**
* Plugin method with the same name as the event will be called automatically.
*/
function <EventName>()
{
/*
* Plugin code goes here.
* You can access database and application objects and parameters via $this->db,
* $this->app and $this->params respectively
*/
return true;
}
}
?>
</source>

<translate>
=== Using Plugins in Your Code === 
Now that you've created your plugin, you will probably want to call it in your code. You might not: the Joomla! core has a number of built-in events that you might want your plugin code to be registered to. In that case you don't need to do the following.
</translate>

<translate>

If you want to trigger an event then you use code like this:
</translate>

<source lang="php">
$dispatcher = JDispatcher::getInstance();
$results = $dispatcher->trigger( '<EventName>', <ParameterArray> );
</source>

<translate>

It is important to note that the parameters have to be in an array. The plugin function itself will get the parameters as single values. The return value will consist of an array of return values from the different plugins (so it can also contain multilevel arrays).
</translate>

<translate>

If you are creating a plugin for a new, non-core event, remember to activate your plugin after you install it. Precede any reference to your new plugin with the <code>JPluginHelper::importPlugin()</code> command.
</translate>

<noinclude>
<translate>

[[Category:Tutorials]]
[[Category:Plugin Development]]
</translate>
</noinclude>

Migrating a Template from Joomla 1.5 to 3.x

2015-05-07T17:15:13Z

Sovainfo: Changed to die;

<noinclude><languages /></noinclude>

<translate>

When considering a manual update to your 1.5 template there are a few considerations you need to think about.
</translate>

<translate>

First, what skills do you need? To make template changes, minimally you need to be familiar with the basics of PHP, HTML, XML, CSS and possibly some Javascript. If you don’t have a basic grasp of these skills a lot of what you’ll be looking at will look foreign so either brush up on those skills or hire a professional.
</translate>

<translate>

Second, the extent that your template needs to change must be measured in terms of the new enhancements or design changes that have developed in planning your migration. Is the change going to take advantage of new Bootstrap framework styling that is available in Joomla 3? Or is it a strict move that mirrors the current site. While some of the changes that are new to Joomla 3 are mandatory ( meaning your template will not load ) others are enhancements and your template will load but might not look the way you want it to.
</translate>

<translate>

For purposes of this document we will be assuming the simplest example and suggest a mirror image of the current 1.5 template. For more complex templates or for major enhancements you may need to do some research or hire someone who has more experience with templates.
</translate>

<translate>
== Review the Basics of Templates == 
</translate>

<translate>

Some things haven't changed. You still need to be familiar with the basics of a JoomlaTemplate: The folder directory structure is one of those things. Minimally at the root level you need 2 files: “index.php” and "templateDetails.xml" ( notice the case! ). Most templates include at least 2 folders: an images folder to hold all the graphics that your template uses and a folder for your css styling. More advanced templates might contain folders with names like these for example: “html” for component and module customization, a “language” folder for custom language overrides, “javascript” to hold custom javascript routines.
</translate>

<translate>

Just be sure if the folder is listed in the XML file it exists in the template you upload to Joomla. If you declare a file in the xml then it must exist or your template will not load.
</translate>

<translate>

One example of an improvement in versions greater than 1.5, is the dropping of the requirement that all the subfolder filenames be listed. For templates in Joomla 3, you simply list the folder name.
</translate>

<translate>

For more information on the basics of a template see this link: [[S:MyLanguage/Creating a basic Joomla! template|Creating a basic Joomla! template]]
</translate>

<translate>
=== XML File Changes === 
What needs to change in the templateDetails.xml file ( Template Manifest File )
</translate>

<translate>

The template manifest file provides the information Joomla needs to install your template. The XML manifest file has been almost completely modified since 1.5 so make sure you study up and are familiar with the basics and the modifications. Your template will not load if this file is not exactly right.
</translate>

<translate>
==== Document Reference Type Tag & the Install/Extension Tag ==== 
The XML Install tag is now an “extension” tag. Additionally, any reference in the DOCTYPE Tag or version numbers now needs to refer to 3.0.
</translate>

<translate>

The old lines are something like this:
</translate>

<source lang="xml">
<!DOCTYPE install PUBLIC "-//Joomla! 1.5//DTD template 1.0//EN" "http://dev.joomla.org/xml/1.5/template-install.dtd">
<install version="1.5" type="template">
</source>

<translate>

This now needs to look like this:
</translate>

<source lang="xml">
<!DOCTYPE install PUBLIC "-//Joomla! 2.5//DTD template 1.0//EN" "http://www.joomla.org/xml/dtd/2.5/template-install.dtd">
<extension version="3.1" type="template" client="site">
</source>

<translate>
==== Folder and File tags ==== 
This rule has always been true and still is: If you list the Filename or Folder in the XML it must exist in the uploaded template. This has not changed in Joomla 3. What did change is the 1.5 requirement that all the filenames in a folder be listed. Now you can refer to just the folder name. For example, previously in 1.5 your xml filenames were listed individually as follows:
</translate>

<source lang="xml">
<images>
<filename>images/arrow.png</filename>
<filename>images/arrow2.png</filename>
<filename>images/arrow3.png</filename>
<filename>images/author.gif</filename>
</images>
</source>

<translate>

For a Joomla 3 template this statement suffices:
</translate>
<source lang="xml">
<folder>images</folder></source>

<translate>
==== Module Tags ==== 
For 1.5, module positions were defined in the template. This has not changed. They still need to be listed.
</translate>

<translate>
==== Parameters ==== 
Parameters are an optional feature of templates that allow the template author to offer options for styling of the template in the Joomla Administrator. In Joomla 1.5 templates the parameters were listed in a "parameters.ini" file at the root level. This file has been eliminated and the parameters are now tags in the XML file.
</translate>

<translate>

Here is an example of the contents of a parameters.ini file:
</translate>

<source lang="xml">
colorVariation=blue
backgroundVariation=blue</source>

<translate>

To define the parameters in Joomla 3 you must add these lines to the XML file:
</translate>
<source lang="xml">
<config>
<fields name="params">
<fieldset name="advanced">
<field name="colorVariation" class="" type="color" default="#08C"
label="TPL PROTOSTAR COLOR LABEL"
description="TPL PROTOSTAR COLOR DESC" />
<field name="backgroundVariation" class="" type="color" default="#F4F6F7"
label="TPL PROTOSTAR BACKGROUND COLOR LABEL"
description="TPL PROTOSTAR BACKGROUND COLOR DESC" />
</fieldset>
</fields>
</config>
</source>

<translate>

For more complex parameter XML tags you may have to refer to more complex documentation. Also note that the index.php that reference the parameter variables will also need to be changed.
</translate>

<translate>

See these links for more information about:
*[[S:MyLanguage/Standard form field and parameter types|Standard form field and parameter types]]
*[[S:MyLanguage/Creating a basic templateDetails.xml file|Creating a basic templateDetails.xml file]]
</translate>

<translate>
=== index.php file === 


What needs to change in the index.php file?
</translate>

<translate>

<tt>Index.php</tt> files are as widely varied as there are designers and programmers that write them. The index.php in a template for Joomla 3 is the compilation of the many versions that came before including 1.5, 1.6, 1.7,2.5, etc. This template file is the "bloodstream" providing life to your skin, and it has access to every piece of Joomla's framework available and can use these pieces to manipulate what your site is going to look like to your users. This has always been true and still is. Template designers and programmers have taken advantage of this fact in previous versions and will continue to, so this file needs the most careful research and planning.
</translate>

<translate>

Changes that were made to the framework for Joomla 3 may cause problems to some older templates and when rendered could produce errors. Other templates may not have referenced the same piece of framework at all and work fine with almost no changes. For example, a 1.5 template that accesses the variable value "frontpage" to determine if they are on the home page or not. This doesn't work in Joomla 3. (See table below for code ) If a template referenced a changed piece or not will be the determining factor of how many issues you will have when trying to implement your updated template.
</translate>

<translate>

Be prepared to make some changes based on “best practices”. Although your index.php may function, it needs to be secure and execute efficiently. Consider that every page served to your audience uses the index.php file so make sure you are familiar with the recommended methods for the Joomla framework and building blocks for a template. A thorough study of the index.php file in both the Protostar Template and the Beez Template that is included with the Joomla 3 installation package can provide examples and best practices for more complex templates.
</translate>

<translate>
==== Guidelines ==== 
Here are some guidelines for your Joomla 3 template index.php file:


1. Again, some things haven't changed: all index.php templates need to start with this statement:
</translate>

<source lang="php">
<?php defined( '_JEXEC' ) or die;?></source>

<translate>

True for Joomla 1.5 and still true for Joomla 3.


2. For Joomla 3 the recommended DOCTYPE ( Document Type Declaration ) should be HTML5 as this is used throughout Joomla 3. Here is an example:
</translate>

<source lang="php">
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr"></source>

<translate>

3. To make use of Joomla 3's application framework:
</translate>

<translate>

In 1.5 access to the framework was done through the $mainframe variable. You might see something like this:
</translate>

<source lang="php">
<?php require_once (‘includes/../framework.php' );
$mainframe =& JFactory::getApplication('site'); ?></source>

<translate>
:replace it with this:</translate>

<source lang="php">
<?php $app = Jfactory::getApplication();?>
</source>

<translate>

4. To retrieve the Heading code use this statement directly beneath your heading tag and follow it with your stylesheets. This has not changed with the Joomla 3 but always bears repeating:
</translate>

<source lang="php">
<jdoc:include type="head" /></source>

<translate>

5. To retrieve the sitename in 1.5 you might see this:
</translate>

<source lang="php">
<?php echo $mainframe->getCfg('sitename');?></source>

<translate>

For Joomla 3 use this code:
</translate>

<source lang="php">
<?php $app->getCfg('sitename');?></source>

<translate>

6. Error Codes and Messages:


A better methodology for retrieving error codes is in place for Joomla 3. You might see this in your 1.5 template:
</translate>

<source lang="php">
<?php $this->error->code; ?></source>

<translate>
:replace it with this Joomla 3 convention:</translate>

<source lang="php">
<?php $this->error->getCode(); ?></source>

<translate>

For error messages, this is a typical 1.5 statement:
</translate>

<source lang="php">
<?php $this->error->message; ?></source>

<translate>

:Replace it with this statement for Joomla 3
</translate>

<source lang="php">
<?php $this->error->getMessage(); ?></source>

<translate>

7. To access the template parameters in replace code that looks like this:
</translate>

<source lang="php">
<?php $color = $this->params->get('colorVariation'); ?></source>

<translate>

:with this recommended methodology:
</translate>

<source lang="php">
<?php $app = Jfactory::getApplication();
$template = $app->getTemplate(true);
$params = $template->params;
$color = $params->get('colorVariation'); ?></source>

<translate>

This will work equally well as an example:
</translate>

<source lang="php">
<?php $app = Jfactory::getApplication();
$params = $app->getParams();
$color = $params->get('colorVariation'); ?></source>

<translate>

8. Access to the Global Document Object classes in the index.php template file is typically coded this way:
</translate>

<source lang="php">
<?php $doc = Jfactory::getDocument(); ?>
</source>

<translate>

This statement is the same in Joomla 3. However, it is valid to note that this statement is not necessary to access the page classes so it might be there or it might not depending on the original programmer.
For example: given the code:
</translate>

<source lang="php">
<?php $doc =& JFactory::getDocument();
echo 'Current title is: ' . $doc->getTitle(); ?>
</source>

<translate>

is equivalent to this code:
</translate>

<source lang="php">
<?php echo 'Current title is: ' . $this->getTitle(); ?>
</source>

<translate>

==== In Summary ==== 
</translate>

{{:Template_Code_Comparison_of_J1.5_and_J3.x/<translate>
en</translate>}}

<translate>
== Bootstrap Styling and Joomla 3 == 
</translate>

<translate>

To incorporate the new Bootstrap Styling ( 2.3.2 ) into your updated template, use these three lines at the very top of your index.php, replacing the one line php block.
</translate>

<source lang="php">
<?php defined( '_JEXEC' ) or die;
JHtml::_('bootstrap.framework');
JHtml::_('bootstrap.loadCss', true, $this->direction); ?>
</source>

<translate>

After these statements, you can add Bootstrap (2.3.2 ) classes wherever you need to and take advantage of the Bootstrap Framework offered in Joomla 3.
</translate>

<translate>

== This bears repeating... == 
</translate>

<translate>

There are many variations of coding practices and your success with translating a 1.5 template into a template fit for Joomla 3 depends on the complexity of the old and new design, and the original coding. Your template might have been previously converted from Joomla 1.0! Your best strategy is to research the documentation available and become familiar with the Protostar and Beez templates in Joomla 3. Techniques for coding and structuring in these 2 templates have undergone the scrutiny of the Joomla community and volunteer developers – the true experts on how to best make your template secure and function reliably.
</translate>

<translate>
== References == 
</translate>

<translate>

*[[S:MyLanguage/Creating a basic Joomla! template|Creating a basic Joomla! template]]
*[[S:MyLanguage/Creating a basic index file|Creating a basic index file]]
*[[S:MyLanguage/Creating a basic templateDetails.xml file|Creating a basic templateDetails.xml file]]
*[[S:MyLanguage/Understanding Joomla! templates|Understanding Joomla! templates]]
*[[S:MyLanguage/Standard form field and parameter types|Standard form field and parameter types]]
*[[S:MyLanguage/Talk:Creating a basic Joomla! template|Talk:Creating a basic Joomla! template]]
</translate>

<noinclude>
<translate>

[[Category:Migration|Migration]]
[[Category:Template Development|Template Development]]
[[Category:Tutorials|Tutorials]]
</translate>
</noinclude>

Migrating a Template from Joomla 1.5 to 3.x

2015-05-07T17:08:25Z

Sovainfo: $this->params is different from $params

<noinclude><languages /></noinclude>

<translate>

When considering a manual update to your 1.5 template there are a few considerations you need to think about.
</translate>

<translate>

First, what skills do you need? To make template changes, minimally you need to be familiar with the basics of PHP, HTML, XML, CSS and possibly some Javascript. If you don’t have a basic grasp of these skills a lot of what you’ll be looking at will look foreign so either brush up on those skills or hire a professional.
</translate>

<translate>

Second, the extent that your template needs to change must be measured in terms of the new enhancements or design changes that have developed in planning your migration. Is the change going to take advantage of new Bootstrap framework styling that is available in Joomla 3? Or is it a strict move that mirrors the current site. While some of the changes that are new to Joomla 3 are mandatory ( meaning your template will not load ) others are enhancements and your template will load but might not look the way you want it to.
</translate>

<translate>

For purposes of this document we will be assuming the simplest example and suggest a mirror image of the current 1.5 template. For more complex templates or for major enhancements you may need to do some research or hire someone who has more experience with templates.
</translate>

<translate>
== Review the Basics of Templates == 
</translate>

<translate>

Some things haven't changed. You still need to be familiar with the basics of a JoomlaTemplate: The folder directory structure is one of those things. Minimally at the root level you need 2 files: “index.php” and "templateDetails.xml" ( notice the case! ). Most templates include at least 2 folders: an images folder to hold all the graphics that your template uses and a folder for your css styling. More advanced templates might contain folders with names like these for example: “html” for component and module customization, a “language” folder for custom language overrides, “javascript” to hold custom javascript routines.
</translate>

<translate>

Just be sure if the folder is listed in the XML file it exists in the template you upload to Joomla. If you declare a file in the xml then it must exist or your template will not load.
</translate>

<translate>

One example of an improvement in versions greater than 1.5, is the dropping of the requirement that all the subfolder filenames be listed. For templates in Joomla 3, you simply list the folder name.
</translate>

<translate>

For more information on the basics of a template see this link: [[S:MyLanguage/Creating a basic Joomla! template|Creating a basic Joomla! template]]
</translate>

<translate>
=== XML File Changes === 
What needs to change in the templateDetails.xml file ( Template Manifest File )
</translate>

<translate>

The template manifest file provides the information Joomla needs to install your template. The XML manifest file has been almost completely modified since 1.5 so make sure you study up and are familiar with the basics and the modifications. Your template will not load if this file is not exactly right.
</translate>

<translate>
==== Document Reference Type Tag & the Install/Extension Tag ==== 
The XML Install tag is now an “extension” tag. Additionally, any reference in the DOCTYPE Tag or version numbers now needs to refer to 3.0.
</translate>

<translate>

The old lines are something like this:
</translate>

<source lang="xml">
<!DOCTYPE install PUBLIC "-//Joomla! 1.5//DTD template 1.0//EN" "http://dev.joomla.org/xml/1.5/template-install.dtd">
<install version="1.5" type="template">
</source>

<translate>

This now needs to look like this:
</translate>

<source lang="xml">
<!DOCTYPE install PUBLIC "-//Joomla! 2.5//DTD template 1.0//EN" "http://www.joomla.org/xml/dtd/2.5/template-install.dtd">
<extension version="3.1" type="template" client="site">
</source>

<translate>
==== Folder and File tags ==== 
This rule has always been true and still is: If you list the Filename or Folder in the XML it must exist in the uploaded template. This has not changed in Joomla 3. What did change is the 1.5 requirement that all the filenames in a folder be listed. Now you can refer to just the folder name. For example, previously in 1.5 your xml filenames were listed individually as follows:
</translate>

<source lang="xml">
<images>
<filename>images/arrow.png</filename>
<filename>images/arrow2.png</filename>
<filename>images/arrow3.png</filename>
<filename>images/author.gif</filename>
</images>
</source>

<translate>

For a Joomla 3 template this statement suffices:
</translate>
<source lang="xml">
<folder>images</folder></source>

<translate>
==== Module Tags ==== 
For 1.5, module positions were defined in the template. This has not changed. They still need to be listed.
</translate>

<translate>
==== Parameters ==== 
Parameters are an optional feature of templates that allow the template author to offer options for styling of the template in the Joomla Administrator. In Joomla 1.5 templates the parameters were listed in a "parameters.ini" file at the root level. This file has been eliminated and the parameters are now tags in the XML file.
</translate>

<translate>

Here is an example of the contents of a parameters.ini file:
</translate>

<source lang="xml">
colorVariation=blue
backgroundVariation=blue</source>

<translate>

To define the parameters in Joomla 3 you must add these lines to the XML file:
</translate>
<source lang="xml">
<config>
<fields name="params">
<fieldset name="advanced">
<field name="colorVariation" class="" type="color" default="#08C"
label="TPL PROTOSTAR COLOR LABEL"
description="TPL PROTOSTAR COLOR DESC" />
<field name="backgroundVariation" class="" type="color" default="#F4F6F7"
label="TPL PROTOSTAR BACKGROUND COLOR LABEL"
description="TPL PROTOSTAR BACKGROUND COLOR DESC" />
</fieldset>
</fields>
</config>
</source>

<translate>

For more complex parameter XML tags you may have to refer to more complex documentation. Also note that the index.php that reference the parameter variables will also need to be changed.
</translate>

<translate>

See these links for more information about:
*[[S:MyLanguage/Standard form field and parameter types|Standard form field and parameter types]]
*[[S:MyLanguage/Creating a basic templateDetails.xml file|Creating a basic templateDetails.xml file]]
</translate>

<translate>
=== index.php file === 


What needs to change in the index.php file?
</translate>

<translate>

<tt>Index.php</tt> files are as widely varied as there are designers and programmers that write them. The index.php in a template for Joomla 3 is the compilation of the many versions that came before including 1.5, 1.6, 1.7,2.5, etc. This template file is the "bloodstream" providing life to your skin, and it has access to every piece of Joomla's framework available and can use these pieces to manipulate what your site is going to look like to your users. This has always been true and still is. Template designers and programmers have taken advantage of this fact in previous versions and will continue to, so this file needs the most careful research and planning.
</translate>

<translate>

Changes that were made to the framework for Joomla 3 may cause problems to some older templates and when rendered could produce errors. Other templates may not have referenced the same piece of framework at all and work fine with almost no changes. For example, a 1.5 template that accesses the variable value "frontpage" to determine if they are on the home page or not. This doesn't work in Joomla 3. (See table below for code ) If a template referenced a changed piece or not will be the determining factor of how many issues you will have when trying to implement your updated template.
</translate>

<translate>

Be prepared to make some changes based on “best practices”. Although your index.php may function, it needs to be secure and execute efficiently. Consider that every page served to your audience uses the index.php file so make sure you are familiar with the recommended methods for the Joomla framework and building blocks for a template. A thorough study of the index.php file in both the Protostar Template and the Beez Template that is included with the Joomla 3 installation package can provide examples and best practices for more complex templates.
</translate>

<translate>
==== Guidelines ==== 
Here are some guidelines for your Joomla 3 template index.php file:


1. Again, some things haven't changed: all index.php templates need to start with this statement:
</translate>

<source lang="php">
<?php defined( '_JEXEC' ) or die;?></source>

<translate>

True for Joomla 1.5 and still true for Joomla 3.


2. For Joomla 3 the recommended DOCTYPE ( Document Type Declaration ) should be HTML5 as this is used throughout Joomla 3. Here is an example:
</translate>

<source lang="php">
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr"></source>

<translate>

3. To make use of Joomla 3's application framework:
</translate>

<translate>

In 1.5 access to the framework was done through the $mainframe variable. You might see something like this:
</translate>

<source lang="php">
<?php require_once (‘includes/../framework.php' );
$mainframe =& JFactory::getApplication('site'); ?></source>

<translate>
:replace it with this:</translate>

<source lang="php">
<?php $app = Jfactory::getApplication();?>
</source>

<translate>

4. To retrieve the Heading code use this statement directly beneath your heading tag and follow it with your stylesheets. This has not changed with the Joomla 3 but always bears repeating:
</translate>

<source lang="php">
<jdoc:include type="head" /></source>

<translate>

5. To retrieve the sitename in 1.5 you might see this:
</translate>

<source lang="php">
<?php echo $mainframe->getCfg('sitename');?></source>

<translate>

For Joomla 3 use this code:
</translate>

<source lang="php">
<?php $app->getCfg('sitename');?></source>

<translate>

6. Error Codes and Messages:


A better methodology for retrieving error codes is in place for Joomla 3. You might see this in your 1.5 template:
</translate>

<source lang="php">
<?php $this->error->code; ?></source>

<translate>
:replace it with this Joomla 3 convention:</translate>

<source lang="php">
<?php $this->error->getCode(); ?></source>

<translate>

For error messages, this is a typical 1.5 statement:
</translate>

<source lang="php">
<?php $this->error->message; ?></source>

<translate>

:Replace it with this statement for Joomla 3
</translate>

<source lang="php">
<?php $this->error->getMessage(); ?></source>

<translate>

7. To access the template parameters in replace code that looks like this:
</translate>

<source lang="php">
<?php $color = $this->params->get('colorVariation'); ?></source>

<translate>

:with this recommended methodology:
</translate>

<source lang="php">
<?php $app = Jfactory::getApplication();
$template = $app->getTemplate(true);
$params = $template->params;
$color = $params->get('colorVariation'); ?></source>

<translate>

This will work equally well as an example:
</translate>

<source lang="php">
<?php $app = Jfactory::getApplication();
$params = $app->getParams();
$color = $params->get('colorVariation'); ?></source>

<translate>

8. Access to the Global Document Object classes in the index.php template file is typically coded this way:
</translate>

<source lang="php">
<?php $doc = Jfactory::getDocument(); ?>
</source>

<translate>

This statement is the same in Joomla 3. However, it is valid to note that this statement is not necessary to access the page classes so it might be there or it might not depending on the original programmer.
For example: given the code:
</translate>

<source lang="php">
<?php $doc =& JFactory::getDocument();
echo 'Current title is: ' . $doc->getTitle(); ?>
</source>

<translate>

is equivalent to this code:
</translate>

<source lang="php">
<?php echo 'Current title is: ' . $this->getTitle(); ?>
</source>

<translate>

==== In Summary ==== 
</translate>

{{:Template_Code_Comparison_of_J1.5_and_J3.x/<translate>
en</translate>}}

<translate>
== Bootstrap Styling and Joomla 3 == 
</translate>

<translate>

To incorporate the new Bootstrap Styling ( 2.3.2 ) into your updated template, use these three lines at the very top of your index.php, replacing the one line php block.
</translate>

<source lang="php">
<?php defined( '_JEXEC' ) or die('Restricted access');
JHtml::_('bootstrap.framework');
JHtml::_('bootstrap.loadCss', true, $this->direction); ?>
</source>

<translate>

After these statements, you can add Bootstrap (2.3.2 ) classes wherever you need to and take advantage of the Bootstrap Framework offered in Joomla 3.
</translate>

<translate>

== This bears repeating... == 
</translate>

<translate>

There are many variations of coding practices and your success with translating a 1.5 template into a template fit for Joomla 3 depends on the complexity of the old and new design, and the original coding. Your template might have been previously converted from Joomla 1.0! Your best strategy is to research the documentation available and become familiar with the Protostar and Beez templates in Joomla 3. Techniques for coding and structuring in these 2 templates have undergone the scrutiny of the Joomla community and volunteer developers – the true experts on how to best make your template secure and function reliably.
</translate>

<translate>
== References == 
</translate>

<translate>

*[[S:MyLanguage/Creating a basic Joomla! template|Creating a basic Joomla! template]]
*[[S:MyLanguage/Creating a basic index file|Creating a basic index file]]
*[[S:MyLanguage/Creating a basic templateDetails.xml file|Creating a basic templateDetails.xml file]]
*[[S:MyLanguage/Understanding Joomla! templates|Understanding Joomla! templates]]
*[[S:MyLanguage/Standard form field and parameter types|Standard form field and parameter types]]
*[[S:MyLanguage/Talk:Creating a basic Joomla! template|Talk:Creating a basic Joomla! template]]
</translate>

<noinclude>
<translate>

[[Category:Migration|Migration]]
[[Category:Template Development|Template Development]]
[[Category:Tutorials|Tutorials]]
</translate>
</noinclude>

Migrating a Template from Joomla 1.5 to 3.x

2015-05-07T16:56:13Z

Sovainfo: Changed to die;

<noinclude><languages /></noinclude>

<translate>

When considering a manual update to your 1.5 template there are a few considerations you need to think about.
</translate>

<translate>

First, what skills do you need? To make template changes, minimally you need to be familiar with the basics of PHP, HTML, XML, CSS and possibly some Javascript. If you don’t have a basic grasp of these skills a lot of what you’ll be looking at will look foreign so either brush up on those skills or hire a professional.
</translate>

<translate>

Second, the extent that your template needs to change must be measured in terms of the new enhancements or design changes that have developed in planning your migration. Is the change going to take advantage of new Bootstrap framework styling that is available in Joomla 3? Or is it a strict move that mirrors the current site. While some of the changes that are new to Joomla 3 are mandatory ( meaning your template will not load ) others are enhancements and your template will load but might not look the way you want it to.
</translate>

<translate>

For purposes of this document we will be assuming the simplest example and suggest a mirror image of the current 1.5 template. For more complex templates or for major enhancements you may need to do some research or hire someone who has more experience with templates.
</translate>

<translate>
== Review the Basics of Templates == 
</translate>

<translate>

Some things haven't changed. You still need to be familiar with the basics of a JoomlaTemplate: The folder directory structure is one of those things. Minimally at the root level you need 2 files: “index.php” and "templateDetails.xml" ( notice the case! ). Most templates include at least 2 folders: an images folder to hold all the graphics that your template uses and a folder for your css styling. More advanced templates might contain folders with names like these for example: “html” for component and module customization, a “language” folder for custom language overrides, “javascript” to hold custom javascript routines.
</translate>

<translate>

Just be sure if the folder is listed in the XML file it exists in the template you upload to Joomla. If you declare a file in the xml then it must exist or your template will not load.
</translate>

<translate>

One example of an improvement in versions greater than 1.5, is the dropping of the requirement that all the subfolder filenames be listed. For templates in Joomla 3, you simply list the folder name.
</translate>

<translate>

For more information on the basics of a template see this link: [[S:MyLanguage/Creating a basic Joomla! template|Creating a basic Joomla! template]]
</translate>

<translate>
=== XML File Changes === 
What needs to change in the templateDetails.xml file ( Template Manifest File )
</translate>

<translate>

The template manifest file provides the information Joomla needs to install your template. The XML manifest file has been almost completely modified since 1.5 so make sure you study up and are familiar with the basics and the modifications. Your template will not load if this file is not exactly right.
</translate>

<translate>
==== Document Reference Type Tag & the Install/Extension Tag ==== 
The XML Install tag is now an “extension” tag. Additionally, any reference in the DOCTYPE Tag or version numbers now needs to refer to 3.0.
</translate>

<translate>

The old lines are something like this:
</translate>

<source lang="xml">
<!DOCTYPE install PUBLIC "-//Joomla! 1.5//DTD template 1.0//EN" "http://dev.joomla.org/xml/1.5/template-install.dtd">
<install version="1.5" type="template">
</source>

<translate>

This now needs to look like this:
</translate>

<source lang="xml">
<!DOCTYPE install PUBLIC "-//Joomla! 2.5//DTD template 1.0//EN" "http://www.joomla.org/xml/dtd/2.5/template-install.dtd">
<extension version="3.1" type="template" client="site">
</source>

<translate>
==== Folder and File tags ==== 
This rule has always been true and still is: If you list the Filename or Folder in the XML it must exist in the uploaded template. This has not changed in Joomla 3. What did change is the 1.5 requirement that all the filenames in a folder be listed. Now you can refer to just the folder name. For example, previously in 1.5 your xml filenames were listed individually as follows:
</translate>

<source lang="xml">
<images>
<filename>images/arrow.png</filename>
<filename>images/arrow2.png</filename>
<filename>images/arrow3.png</filename>
<filename>images/author.gif</filename>
</images>
</source>

<translate>

For a Joomla 3 template this statement suffices:
</translate>
<source lang="xml">
<folder>images</folder></source>

<translate>
==== Module Tags ==== 
For 1.5, module positions were defined in the template. This has not changed. They still need to be listed.
</translate>

<translate>
==== Parameters ==== 
Parameters are an optional feature of templates that allow the template author to offer options for styling of the template in the Joomla Administrator. In Joomla 1.5 templates the parameters were listed in a "parameters.ini" file at the root level. This file has been eliminated and the parameters are now tags in the XML file.
</translate>

<translate>

Here is an example of the contents of a parameters.ini file:
</translate>

<source lang="xml">
colorVariation=blue
backgroundVariation=blue</source>

<translate>

To define the parameters in Joomla 3 you must add these lines to the XML file:
</translate>
<source lang="xml">
<config>
<fields name="params">
<fieldset name="advanced">
<field name="colorVariation" class="" type="color" default="#08C"
label="TPL PROTOSTAR COLOR LABEL"
description="TPL PROTOSTAR COLOR DESC" />
<field name="backgroundVariation" class="" type="color" default="#F4F6F7"
label="TPL PROTOSTAR BACKGROUND COLOR LABEL"
description="TPL PROTOSTAR BACKGROUND COLOR DESC" />
</fieldset>
</fields>
</config>
</source>

<translate>

For more complex parameter XML tags you may have to refer to more complex documentation. Also note that the index.php that reference the parameter variables will also need to be changed.
</translate>

<translate>

See these links for more information about:
*[[S:MyLanguage/Standard form field and parameter types|Standard form field and parameter types]]
*[[S:MyLanguage/Creating a basic templateDetails.xml file|Creating a basic templateDetails.xml file]]
</translate>

<translate>
=== index.php file === 


What needs to change in the index.php file?
</translate>

<translate>

<tt>Index.php</tt> files are as widely varied as there are designers and programmers that write them. The index.php in a template for Joomla 3 is the compilation of the many versions that came before including 1.5, 1.6, 1.7,2.5, etc. This template file is the "bloodstream" providing life to your skin, and it has access to every piece of Joomla's framework available and can use these pieces to manipulate what your site is going to look like to your users. This has always been true and still is. Template designers and programmers have taken advantage of this fact in previous versions and will continue to, so this file needs the most careful research and planning.
</translate>

<translate>

Changes that were made to the framework for Joomla 3 may cause problems to some older templates and when rendered could produce errors. Other templates may not have referenced the same piece of framework at all and work fine with almost no changes. For example, a 1.5 template that accesses the variable value "frontpage" to determine if they are on the home page or not. This doesn't work in Joomla 3. (See table below for code ) If a template referenced a changed piece or not will be the determining factor of how many issues you will have when trying to implement your updated template.
</translate>

<translate>

Be prepared to make some changes based on “best practices”. Although your index.php may function, it needs to be secure and execute efficiently. Consider that every page served to your audience uses the index.php file so make sure you are familiar with the recommended methods for the Joomla framework and building blocks for a template. A thorough study of the index.php file in both the Protostar Template and the Beez Template that is included with the Joomla 3 installation package can provide examples and best practices for more complex templates.
</translate>

<translate>
==== Guidelines ==== 
Here are some guidelines for your Joomla 3 template index.php file:


1. Again, some things haven't changed: all index.php templates need to start with this statement:
</translate>

<source lang="php">
<?php defined( '_JEXEC' ) or die;?></source>

<translate>

True for Joomla 1.5 and still true for Joomla 3.


2. For Joomla 3 the recommended DOCTYPE ( Document Type Declaration ) should be HTML5 as this is used throughout Joomla 3. Here is an example:
</translate>

<source lang="php">
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr"></source>

<translate>

3. To make use of Joomla 3's application framework:
</translate>

<translate>

In 1.5 access to the framework was done through the $mainframe variable. You might see something like this:
</translate>

<source lang="php">
<?php require_once (‘includes/../framework.php' );
$mainframe =& JFactory::getApplication('site'); ?></source>

<translate>
:replace it with this:</translate>

<source lang="php">
<?php $app = Jfactory::getApplication();?>
</source>

<translate>

4. To retrieve the Heading code use this statement directly beneath your heading tag and follow it with your stylesheets. This has not changed with the Joomla 3 but always bears repeating:
</translate>

<source lang="php">
<jdoc:include type="head" /></source>

<translate>

5. To retrieve the sitename in 1.5 you might see this:
</translate>

<source lang="php">
<?php echo $mainframe->getCfg('sitename');?></source>

<translate>

For Joomla 3 use this code:
</translate>

<source lang="php">
<?php $app->getCfg('sitename');?></source>

<translate>

6. Error Codes and Messages:


A better methodology for retrieving error codes is in place for Joomla 3. You might see this in your 1.5 template:
</translate>

<source lang="php">
<?php $this->error->code; ?></source>

<translate>
:replace it with this Joomla 3 convention:</translate>

<source lang="php">
<?php $this->error->getCode(); ?></source>

<translate>

For error messages, this is a typical 1.5 statement:
</translate>

<source lang="php">
<?php $this->error->message; ?></source>

<translate>

:Replace it with this statement for Joomla 3
</translate>

<source lang="php">
<?php $this->error->getMessage(); ?></source>

<translate>

7. To access the template parameters in replace code that looks like this:
</translate>

<source lang="php">
<?php $color = $this->params->get('colorVariation'); ?></source>

<translate>

:with this recommended methodology:
</translate>

<source lang="php">
<?php $app = Jfactory::getApplication();
$template = $app->getTemplate(true);
$params = $template->params;
$color = $params->get('colorVariation'); ?></source>

<translate>

This will work equally well as an example:
</translate>

<source lang="php">
<?php $app = Jfactory::getApplication();
$params = $app->getParams();
$color = $this->params->get('colorVariation'); ?></source>

<translate>

8. Access to the Global Document Object classes in the index.php template file is typically coded this way:
</translate>

<source lang="php">
<?php $doc = Jfactory::getDocument(); ?>
</source>

<translate>

This statement is the same in Joomla 3. However, it is valid to note that this statement is not necessary to access the page classes so it might be there or it might not depending on the original programmer.
For example: given the code:
</translate>

<source lang="php">
<?php $doc =& JFactory::getDocument();
echo 'Current title is: ' . $doc->getTitle(); ?>
</source>

<translate>

is equivalent to this code:
</translate>

<source lang="php">
<?php echo 'Current title is: ' . $this->getTitle(); ?>
</source>

<translate>

==== In Summary ==== 
</translate>

{{:Template_Code_Comparison_of_J1.5_and_J3.x/<translate>
en</translate>}}

<translate>
== Bootstrap Styling and Joomla 3 == 
</translate>

<translate>

To incorporate the new Bootstrap Styling ( 2.3.2 ) into your updated template, use these three lines at the very top of your index.php, replacing the one line php block.
</translate>

<source lang="php">
<?php defined( '_JEXEC' ) or die('Restricted access');
JHtml::_('bootstrap.framework');
JHtml::_('bootstrap.loadCss', true, $this->direction); ?>
</source>

<translate>

After these statements, you can add Bootstrap (2.3.2 ) classes wherever you need to and take advantage of the Bootstrap Framework offered in Joomla 3.
</translate>

<translate>

== This bears repeating... == 
</translate>

<translate>

There are many variations of coding practices and your success with translating a 1.5 template into a template fit for Joomla 3 depends on the complexity of the old and new design, and the original coding. Your template might have been previously converted from Joomla 1.0! Your best strategy is to research the documentation available and become familiar with the Protostar and Beez templates in Joomla 3. Techniques for coding and structuring in these 2 templates have undergone the scrutiny of the Joomla community and volunteer developers – the true experts on how to best make your template secure and function reliably.
</translate>

<translate>
== References == 
</translate>

<translate>

*[[S:MyLanguage/Creating a basic Joomla! template|Creating a basic Joomla! template]]
*[[S:MyLanguage/Creating a basic index file|Creating a basic index file]]
*[[S:MyLanguage/Creating a basic templateDetails.xml file|Creating a basic templateDetails.xml file]]
*[[S:MyLanguage/Understanding Joomla! templates|Understanding Joomla! templates]]
*[[S:MyLanguage/Standard form field and parameter types|Standard form field and parameter types]]
*[[S:MyLanguage/Talk:Creating a basic Joomla! template|Talk:Creating a basic Joomla! template]]
</translate>

<noinclude>
<translate>

[[Category:Migration|Migration]]
[[Category:Template Development|Template Development]]
[[Category:Tutorials|Tutorials]]
</translate>
</noinclude>

J3.x:Using Tags in an Extension

2015-05-03T08:23:27Z

Sovainfo: /* Introduction */ typo: one be too many

{{copyedit}}

==Introduction==
Joomla's tagging system is used in all core content extensions and is designed to be easy to integrate into other extensions that use standard Joomla design patterns.

Using tags in an extension is fairly straightforward. It requires these changes to a typical extension:

* Register a 'Content type' for the extension view(s)
* Add 'Observer methods' to the extension table class(es)
* Add 'Tag fields' to the extension edit forms
* Add 'Tag display' code to the extension view files
* Optionally, add a batch tagging method to the extension administration

== Register a content type for each view ==

In Joomla! 3 content types e.g. articles, weblinks, contacts, . . . are registered in the <tt>#__content_types</tt> table with a separate record for each content view e.g. article, weblink, article category, weblink category, . . .

Your extension installer needs to create a new record for each view.

Here is the structure of the <tt>#__content_types</tt> table; each column is described in the following sections.
{| class="wikitable"
|-
! Column name !! Column type !! Purpose
|-
| <tt>type_id</tt> || int(10) || Record key
|-
| <tt>type_title</tt>|| varchar(255)|| Type title e.g. <tt>Article</tt>
|-
| <tt>type_alias</tt> || varchar(255)|| Type alias e.g. <tt>com_content.article</tt>
|-
| <tt>table</tt> || varchar(255)|| Information about the Table class
|-
| <tt>rules</tt> || text || Not currently used
|-
| <tt>field_mappings</tt> || text || Maps the table column names to standard Joomla! names
|-
| <tt>router</tt> || varchar(255)|| Optional: name of a router method
|-
| <tt>content_history_options</tt> || varchar(5120)|| Optional: ????
|}

===type_id===
This is the auto-incremented record key, nothing to be done here.

===type_title===
The title for your Content Type e.g. Article, Contact, Weblink,
You can do this either using sql or postflight by creating an instance of JTableContenttype. Don't forget a category type if you use the Joomla categories API.

===type_alias===
A string identifying the component and view (that would be in the page request, typically matching the model name) e.g. <tt>com_contact.contact</tt>, <tt>com_weblinks.weblink</tt>.

===table===
You need to identify which tables used by your component contain records to be tagged. For example the 'Contact' view of the Contacts component uses <tt>#__contact_details</tt> and similarly the 'Weblinks' view of the Weblinks component uses <tt>#__weblinks </tt>.

Each of these components uses a class to write to the table: <tt>ContactTableContact</tt> for the Contacts component and <tt>WeblinksTableWeblink</tt> for the Weblinks component. You will need the class prefixes e.g. <tt>ContactTable</tt>, <tt>WeblinksTable</tt>.

Note that Category types all use the <tt>#__categories</tt> table.

The <tt>type_table</tt> entry gives the complete table class information for the table class as a JSON object with two elements. The first element represents your "special" table and the second an optional common table (otherwise it will default the <tt>JTableCorecontent</tt>).

Here is the JSON entry for the Weblink content type:
<source lang="php">{
"special": {
"dbtable": "#__weblinks",
"key": "id",
"type": "Weblink",
"prefix": "WeblinksTable",
"config": "array()"
},
"common": {
"dbtable": "#__ucm_content",
"key": "ucm_id",
"type": "Corecontent",
"prefix": "JTable",
"config": "array()"
}
}</source>
The values to be included are:
{| class="wikitable"
|-
! Entry name !! Content
|-
| <tt>dbtable</tt> || Table name
|-
| <tt>key</tt>|| Primary key name
|-
| <tt>type</tt> || Content type
|-
| <tt>prefix</tt> || Class prefix
|-
| <tt>config</tt> || An option array, as used in your component constructor and getInstance() methods, may be empty
|}

This information enables the tagging system (and other APIs) to access your table easily.

If you are using Joomla categories make sure to create a category type so that they can be tagged. In Joomla 3.1 and 3.1.1 there is an error where the tag field will show even if there is not a type, but this is corrected in 3.1.4.

====Notes====
* The table name for the common table is <tt>#__ucm_content</tt>; this is incorrect in 3.1 and 3.1.1 data but is not currently used. The data was updated in 3.1.4.

* The <tt>type_title</tt> field would potentially be used for display although this is not implemented currently except in the contenttype field. Usually it should begin with an upper case letter if it is in English. See note about how to make this translatable. To make your type names translatable add <tt>COM_TAGS_CONTENT_TYPE_+type_title="Type Title"</tt> in both the ini and sys.ini files.

===rules===
Rules is currently not used. It will likely be removed in favor of an <tt>asset_id</tt> for each type, but currently you can ignore this field which will be managed by <tt>JTable</tt>.

===field_mappings===
This entry maps the names of specific fields in your table to a set of standard Joomla! names. This mapping is stored as a JSON array with the first 'common' element mapping to the common fields and the second 'special' element mapping the other fields from the table.

Here is the field_mappings entry for the Banner Content Type (chosen because it is a richer example than Article or WebLink). Note that 'common' mappings that have no equivalent are included as 'null' (leaving them blank may cause sql issues); and the names and values in the 'special' element all match as they are limited to this component.
<source lang="php">{
"common": {
"core_content_item_id": "id",
"core_title": "name",
"core_state": "published",
"core_alias": "alias",
"core_created_time": "created",
"core_modified_time": "modified",
"core_body": "description",
"core_hits": "null",
"core_publish_up": "publish_up",
"core_publish_down": "publish_down",
"core_access": "access",
"core_params": "params",
"core_featured": "null",
"core_metadata": "metadata",
"core_language": "language",
"core_images": "images",
"core_urls": "link",
"core_version": "version",
"core_ordering": "ordering",
"core_metakey": "metakey",
"core_metadesc": "metadesc",
"core_catid": "catid",
"core_xreference": "null",
"asset_id": "null"
},
"special": {
"imptotal": "imptotal",
"impmade": "impmade",
"clicks": "clicks",
"clickurl": "clickurl",
"custombannercode": "custombannercode",
"cid": "cid",
"purchase_type": "purchase_type",
"track_impressions": "track_impressions",
"track_clicks": "track_clicks"
}
}</source>
At a minimum for common fields you need to map: content_item_id, alias and title in order to successfully create urls in the tagged items list. You also will probably want: access, status, and language. The special fields are optional.

====Note====
* The <tt>JHelperTags</tt> and JUcm APIs at 3.1.1 supported arrays for this field, but as of 3.1.4 either arrays or objects are supported; the default is objects.

===router===
This is an optional entry to include the name of a static helper router method for this type found in its front end helpers folder e.g. <tt>WeblinksHelperRoute::getWeblinkRoute</tt>.

If you do not have a custom router then Tags falls back to the rules in <tt>JHelperRoute</tt>.

If you only store data in <tt>#__ucm_content</tt> you will eventually be able to leave the router field blank although this option is not currently implemented.

===content_history_options===
This section was added in Joomla! 3.2 to link to the Content History component.

Here's the entry for the Banner Content Type:
<source lang="php">{
"formFile": "administrator\/components\/com_banners\/models\/forms\/banner.xml",
"hideFields": [
"checked_out",
"checked_out_time",
"version",
"reset"
],
"ignoreChanges": [
"modified_by",
"modified",
"checked_out",
"checked_out_time",
"version",
"imptotal",
"impmade",
"reset"
],
"convertToInt": [
"publish_up",
"publish_down",
"ordering"
],
"displayLookup": [
{
"sourceColumn": "catid",
"targetTable": "#__categories",
"targetColumn": "id",
"displayColumn": "title"
},
{
"sourceColumn": "cid",
"targetTable": "#__banner_clients",
"targetColumn": "id",
"displayColumn": "name"
},
{
"sourceColumn": "created_by",
"targetTable": "#__users",
"targetColumn": "id",
"displayColumn": "name"
},
{
"sourceColumn": "modified_by",
"targetTable": "#__users",
"targetColumn": "id",
"displayColumn": "name"
}
]
}</source>

===Creating the record===
You can create records in the installer in one of three ways:
* in the [[J2.5:Managing_Component_Updates_(Script.php)#postflight|postflight]] method
* by creating a <tt>JTableContenttype</tt> instance and adding a row, or
* by using SQL to create a record directly

== Modify your component's table class (or classes if you have multiple tables) ==

Add the following to your JTable constructor:

$this->_observers = new JObserverUpdater($this);
JObserverMapper::attachAllObservers($this);

'''The addition material formerly located here is no longer needed after 3.1.4''' Please read the document history for this page if you are required to support 3.1.0 or 3.1.1.

'''For joomla 3.2 I needed this line:''' ( Dont forget to replace weblinks by your component name )

JObserverMapper::addObserverClassToClass('JTableObserverTags', 'WeblinksTableWeblink', array('typeAlias' => 'com_weblinks.weblink'));

== Add tags to the getItem() method of the model ==

'''Note: this was only required in 3.1.0 and 3.1.1. It should not be used in 3.1.4 or later.''' Please read the history of this page if you need instructions for older versions.

== Add a tag field to edit screens ==

In any edit layouts where you want to allow tagging, you need to add the field to the xml and the appropriate layouts if necessary. The core layouts us a JLayout to manage this and the same layout by any extension.

Update: Note that in '''3.1.1 only''' there is special handling of this in the core. Tags in the edit screen '''MUST''' be part of a metadata <fields></fields> group. The core provides two JLayouts to help you manage standard layouts, one (details) for the metadata and one for the sidebar that includes the tabs. In update an extension to 3.1.4 you may need to fix adjust your edit views.

In 3.1.4 or later this special handling is not necessary. Best practice is to use the standard JLayouts since this provides a consistent experience for users.

<source lang="xml">
<field name="tags" type="tag"
label="JTAG" description="JTAG_DESC"
class="inputbox span12 small" multiple="true"
>
</field></source>

The field loads all the Javascript libraries required. You don't need to worry about that.

The field supports two modes:
* '''Nested tags mode.''' Hierarchical tag list. Doesn't support on the fly tag creation.
* '''AJAX mode.''' Tags are searched while user types (3 min. chars required to launch the AJAX search). Custom tags are added by pressing ENTER or COMMA keys. Tags show the global route/path. Example: <code>grandpa/parent/tag</code>

The field mode can be forced or use the com_tags setting <code>Tag field mode</code> to determine its mode. To set/force the field mode we have to add '''mode="ajax"''' or '''mode="nested"''' to the tag field definition.

Example of forced AJAX mode:

<source lang="xml">
<field name="tags" type="tag" mode="ajax"
label="JTAG" description="JTAG_DESC"
class="inputbox span12 small" multiple="true"
>
</field>
</source>
The field also includes an attribute to allow/deny the user to enter custom values. Currently this only works in AJAX mode. The attribute has to be added to the field definition like **custom="allow"** or **custom="deny"**

Example field definition with custom tags denied:

<source lang="xml">
<field name="tags" type="tag" mode="ajax" custom="denied"
label="JTAG" description="JTAG_DESC"
class="inputbox span12 small" multiple="true"
>
</field>

</source>
if it is not already there. Usually multiple should be true unless you have a specific reason for it not to be.
In the core components in administrator, the field is in the group shown on the right, below the language field.

Note: As of 3.1.2 if you wish to use the field to designate parent tags you must add parent="parent" to the xml definition of the field.

== Prepare the view ==

Add an appropriate version of this to your view.html.php file before loading the layout:

<source lang="php">
$item->tags = new JHelperTags;
$item->tags->getItemTags('com_newsfeeds.newsfeed.' , $this->item->id);
</source>

The first parameter should match a type in the types table. The second parameter is the primary key under which this record is stored in your table. This would be used in any display in any view where you want the tags associated with the item to display.

== Set up the display ==

In any layout where you want to display the tags associated with an item add:
<source lang="php">
<?php $this->item->tagLayout = new JLayoutFile('joomla.content.tags'); ?>
<?php echo $this->item->tagLayout->render($this->item->tags->itemTags); ?>

</source>
Changing the object and property names as appropriate.

You will most likely want to add the show_tags parameter to the item parameters, the menu item parameters and component configuration as appropriate for your use case.

<source lang="php">
<?php if ($this->params->get('show_tags', 1) && !empty($this->item->tags)) : ?>
<?php $this->item->tagLayout = new JLayoutFile('joomla.content.tags'); ?>
<?php echo $this->item->tagLayout->render($this->item->tags->itemTags); ?>
<?php endif; ?></source>

== Batch processing ==
If you want to add the ability to do batch tagging to a backend list view do the following.

Add tag to the default_batch layout

<source lang="php">
<div class="control-group">
<div class="controls">
<?php echo JHtml::_('batch.tag');?>
</div>
</div></source>

And add tag to the button class in the modal footer (Not totally necessary at this point, but good for potential future changes e.g. if unTag is added.)

<source lang="php">
<button class="btn" type="button" onclick="document.id('batch-category-id').value='';document.id('batch-access').value='';document.id('batch-language-id').value='';document.id('batch-user-id').value='';document.id('batch-tag-id)').value=''" data-dismiss="modal">
</source>

=== Add a batch method to your model if you are not extending JModelAdmin or overriding the batch method. ===

<source lang="php">
/**
* Batch tag a list of item.
*
* @param integer $value The value of the new tag.
* @param array $pks An array of row IDs.
* @param array $contexts An array of item contexts.
*
* @return void.
*
* @since 3.1
*/
protected function batchTag($value, $pks, $contexts)
{
$tagsHelper = new JHelperTags();
$tagsHelper->tagItems($value, $pks, $contexts);

return true;
}
</source>

And modify your batch method by adding
<source lang="php">
if (!empty($commands['tag']))
{
if (!$this->batchTag($commands['tag'], $pks, $contexts))
{
return false;
}

$done = true;
}

</source>

Pay attention to any JSON encoded strings that you need special handling for in batch processing -- remember that you are saving a copy of the core fields and you need save to work as expected.

That’s it, now create some tags, tag some items and you are set.

[[Category:Development]][[Category:Content Tags]]
[[Category:Tutorials]]

Adding JavaScript

2015-03-17T22:44:57Z

Sovainfo: /* Important notes for 3rd party developers */

{{version/tutor|1.5,2.5,3.1}}

JavaScript (also known as ECMAScript) is a scripting language primarily used in client-side web site development to extend and enhance an end-user's experience. Joomla provides developers with easy-to-use mechanisms to include JavaScript in their extensions using existing API methods.

There are a number of methods for including JavaScript in your Joomla extensions; some of these are described below.

==Usage==

There are three methods for embedding JavaScript into your code using the Joomla API; [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html#addScriptDeclaration JDocument::addScriptDeclaration], [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html#addScript JDocument::addScript] and [http://api.joomla.org/1.5/Joomla-Framework/HTML/JHTML.html#script script]. These methods should be called either in your component's View class (<yourcomponent>/views/<yourview>/view.html.php) or template script (<yourcomponent>/views/<yourview>/tmpl/<yourtemplate>.php or in the case of a module, in its template script (<yourmodule>/tmpl/<yourtemplate>.php).

===Inline JavaScript===

Blocks of JavaScript code can be declared directly within a component or module's display template using the [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html JDocument] class' [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html#addScriptDeclaration addScriptDeclaration] method:

<source lang="php">
<?php
$document = JFactory::getDocument();
$document->addScriptDeclaration('
window.event("domready", function() {
alert("An inline JavaScript Declaration");
});
');
?>
</source>

===External JavaScript===

Alternatively, you may wish to separate your JavaScript into a separate file. Separating your JavaScript into an external file can make your template code easier to read especially if the JavaScript is lengthy or complex.

There are two ways to include a JavaScript file using the Joomla API. The first involves using the [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html JDocument] class' [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html#addScript addScript] method:

<source lang="php">
<?php
$document = JFactory::getDocument();
$document->addScript('/media/system/js/sample.js');
?>
</source>

The second uses the [http://api.joomla.org/1.5/Joomla-Framework/HTML/JHTML.html JHTML] class' [http://api.joomla.org/1.5/Joomla-Framework/HTML/JHTML.html#script script] method:

<source lang="php">
<?php
// Add the path parameter if the path is different than 'media/system/js/'
JHTML::script('sample.js', 'templates/custom/js/');
?>
</source>

API has changed in 3.x, so the second parameter cannot be a string. If you really need to use this method, you must include the absolute link to your javacript file:

<source lang="php">
<?php
JHtml::script(Juri::base() . 'templates/custom/js/sample.js');
?>
</source>

==Description==
The Joomla API's [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html#addScriptDeclaration JDocument::addScriptDeclaration], [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html#addScript JDocument::addScript] and [http://api.joomla.org/1.5/Joomla-Framework/HTML/JHTML.html#script script] methods embed JavaScript into Joomla's index.php via the jdoc head tag:

<source lang="html4strict">
<jdoc:include type="head"/>
</source>

Using the [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html#addScript JDocument::addScript] or [http://api.joomla.org/1.5/Joomla-Framework/HTML/JHTML.html#script script] methods to embed JavaScript includes would result in the index.php rendering the following HTML:

<source lang="html4strict">
<head>
...
<script type="text/javaScript" src="/media/system/js/sample.js"></script>
...
</head>
</source>

Calling the class method [http://api.joomla.org/1.5/Joomla-Framework/Document/JDocument.html#addScriptDeclaration JDocument::addScriptDeclaration] would render the following HTML:

<source lang="html4strict">
<head>
...
<script type="text/javaScript">
window.addEvent("domready", function() {
alert("Embedded block of JS here");
});
</script>
...
</head>
</source>

Using these methods is highly recommended as it clearly differentiates another scripting language (JavaScript) from the main PHP code, ensures all JavaScript is correctly embedded between the <head></head> tags and, in the case of JDocument::addScript and JHTML::script ensures that a JavaScript file is included only once (I.e. there is no .js file duplication).

== Using a JavaScript Framework ==

A Javascript framework provides developers with generic functionality for handling various coding tasks in a familiar, consistent and platform-independent way. A framework enables the developer to forget about the intricacies of implementing a certain function in different web browsers and focus on the requirements of the software.

Two [[Javascript Frameworks]] are provided as part of Joomla 3.x; jQuery and Mootools. jQuery is a newly introduced framework which integrates with Joomla's new Bootstrap HTML framework; Mootools is Joomla's legacy Javascript library which is now superseded by jQuery and is included for backwards compatibility with 3rd party extensions.

In nearly all cases you should use a framework when developing Javascript in your extensions or templates and including one is very simple with Joomla's API.

===Joomla 3.x jQuery ===
Please see the guide on [[Javascript_Frameworks|Javascript Frameworks in Joomla 3.x]] for information about including a framework in Joomla 3.x

=== Joomla 1.5/2.5 Mootools ===

Unless you are maintaining Javascript code which leverages Mootools or you are developing an extension for Joomla 2.5 or earlier it is recommended you use jQuery instead.

Firstly, you will need to include the Mootools code in your extension. To include the Mootools framework in your extension, you add the following code to your view.html.php or tmpl file:

FOR JOOMLA 1.5
<source lang="php">
JHTML::_('behavior.mootools');
</source>

FOR JOOMLA 2.5
<source lang="php">
JHtml::_('behavior.framework');
</source>

The above code results in the same outcome as the similar jQuery framework statement; that is it ensures Mootools is included correctly and only once.

Then using Mootools is almost identical to jQuery:

<source lang="php">
JFactory::getDocument()->addScriptDeclaration('
window.addEvent("domready", function() {
alert($("list").getElements("li").length);
});
');
</source>

More information about Mootools is available at http://mootools.net/. For API documentation, visit http://mootools.net/docs/core.

== Important notes for 3rd party developers ==

If you are creating a custom template override or extension that needs to add a custom JS file, make sure to add important dependencies such as Jquery or Mootools before your custom JS files. JS framework fiels must always be loaded before any other files to make sure they get executed first, otherwise other files that load before the frameworks they need are likely to end in JS exceptions.

Some templates like Protostar or Beez insert all the dependencies you need using functions like

JHtml::_('bootstrap.framework');

to load Jquery + Bootstrap, but you should not rely in this fact on your extensions or custom templates overrides. Always make sure your extension or custom override load the dependencies you need before the template does it, I will explain why later:

For example if you got a custom template override that needs to insert a JS file with some Jquery scripts that does fancy things on all the pages where that template override is being used. In that case you should declare this on the top section of that override file:

JHtml::_('jquery.framework');
$doc->addScript('templates/'.$this->template.'/js/fancy-script.js');

If you are developing a 3rd party extension that you plan to put on the Joomla! extension directory you should do something like this:

if($params->get('add_extension_resources', false))
{
JHtml::_('jquery.framework');
$doc->addScript('media/com_fancy/js/fancy-script.js');
}

The conditional clause to decide whether to add or not the extension resources is '''strongly encouraged''' and considered a '''good practice''' because it gives flexibility to 3rd party developers who don't want to use your extension resources and use custom/modified files without having to battle with Joomla! using workarounds and hacks to be able to remove your original extensions resources in order to avoid duplicates and conflicts.

==== Explanation ====

If you check the source code of the index.php from the Protostar template, you can see that the statements

JHtml::_('bootstrap.framework');

is added way before the statement

<jdoc:include type="head" />

this can make you think that the framework files and your 3rd party files using methods like

$doc->addScript('templates/'.$this->template.'/js/fancy-script.js');
$doc->addScript('media/com_fancy/js/fancy-script.js');

will be added in the right order at the right spot, '''but that is not the case''', because extension files and template override files are processed '''first''' and the index.php file of your current template is processed the '''last'''. This will cause that your custom JS files get inserted first and the framework files inserted from the template get inserted after.

This happens because the Joomla API (such as $doc->addScript) uses an array to store the JS files paths and they get rendered in the document in the same order they where inserted into that array (FIFO stack), also once a file path is inserted on the array and another API call tries to insert the same file this action is ignored to avid duplicates, it also means that the order of the files is not altered when the same files is attempted to be inserted several times.

Having said that doing this

JHtml::_('jquery.framework');
$doc->addScript('templates/'.$this->template.'/js/fancy-script.js');

at your custom templates overrides and extension, is '''required''' and does not cause harm or conflict with the call

JHtml::_('bootstrap.framework');

at your template index.php file.

== See Also ==

[[JHtmlBehavior::framework/11.1| JHtmlBehaviour::framework method]] from the Joomla! Framework 11.1 documentation

[[Ajax using MooTools]]

[[Adding Javascript moo.fx to your component]]

== External Links ==
http://api.joomla.org/Joomla-Platform/HTML/JHtmlBehavior.html#methodframework

http://en.wikipedia.org/wiki/JavaScript

http://www.w3schools.com/js/default.asp

http://mootools.net/

http://jquery.com/

[[Category:Templates]]
[[Category:Modules]]
[[Category:Components]]
[[Category:Plugins]]
[[Category:Tutorials]]
[[Category:JavaScript]]

How do you put a module inside an article?

2015-03-17T13:31:33Z

Sovainfo: Added syntax

{{version/tutor|2.5,3.1}}

You will usually want to associate modules with articles in some way. The modules are allocated to module positions and the module positions appear somewhere on the Web page as determined by the template. However, it is sometimes useful to have a module actually embedded within the article. Joomla core provides two ways to do that: loadposition and loadmodule.
Syntax:
*{loadposition position[, style]}
*{loadmodule module[, title[, style]]}
===loadpostion===
To insert a module inside an article, you publish the module to a position and load that position in the article as follows:

#Create a module and set its position to '''''myposition'''''. '''''myposition''''' can be any value that doesn't conflict with an existing template position. Type in the position '''''myposition''''' and press enter instead of selecting it from the drop-down list.
#Assign the module to '''All''' the Menu Items. This will make sure that it always appears, no matter how the visitor got to the article. The module will not show unless you put the command to load the module in an [[article]].
#Edit the articles where you want this module to appear and insert the text '''''{loadposition myposition}''''' in the article at the place where you want the module.

{{dablink|*Note that this only works when the [[Help25:Extensions_Plugin_Manager_Edit#Content_-_Load_Modules|''Content - Load Module'' plugin is enabled]]. If this plugin is disabled, the text ''{loadposition myposition}'' shows unchanged in the article.

Also, the name of the position should be all lowercase. CamelCapitalization will fail.}}

===loadmodule===
An alternative to "{loadposition xx}" is the "{loadmodule yyy}" variation which is handled by the same plugin.

In this case the plugin looks for the first module who's '''type''' matches the string 'yyy'. So, you could load a "mod_login" module by placing {loadmodule login} in your text. If you wish to load a specific instance of a module, because you have more than one login module e.g. titled as login1, login2, etc. you have to use {loadmodule login,login2} for the module titled as login2. You can also add the a style that is used for rendering the module, to do so add the style as third parameter like {loadmodule login,login2,xhtml}. If you don't add a style then "none" is used.

===Modules within Modules===
It is possible in Joomla! 2.5+ and Joomla! 3.x+ to include a module within a "Custom HTML" module as they are processed by content plugins in the same way as articles.

To make this work, the option '''Prepare content''' must be enabled as shown in this screenshot.

[[File:j3x_custom_html_prepare_content_option.png||Showing the Prepare Content option in a Custom HTML module.]]

You should remember when doing this that you may experience formatting issues as the "chrome" of the "Custom HTML" module will surround the "chrome" of the included module potential having undesirable effects of the formatting or layout.

<noinclude>
[[Category:Content Management FAQ]]

[[Category:Article Management FAQ]]
</noinclude>

Category talk:Upgrading Issues

2015-01-15T08:41:51Z

Sovainfo:

== Link to Known issues and solutions results in blank screen ==

Link to Known issues and solutions results in blank screen.[[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 07:25, 7 October 2014 (CDT)
* Seems to work now! [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 02:41, 15 January 2015 (CST)

Talk:Joomla 2.5 to 3.x Common Migration Errors

2014-12-28T18:38:45Z

Sovainfo:

Errors and solutions
The topic that initiated this discussion is about a BLANK screen http://forum.joomla.org/viewtopic.php?f=710&t=869414. Expect this to be general and not specific to Migration. Would expect a link here to the topic explainig what to do. What about disabling system plugins, checking joomla_update.php? [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 12:27, 28 December 2014 (CST)

Talk:Joomla 2.5 to 3.x Common Migration Errors

2014-12-28T18:27:43Z

Sovainfo: Created page with "Errors and solutions The topic that initiated this discussion is about a BLANK screen. Expect this to be general and not specific to Migration. Would expect a link here to the..."

Errors and solutions
The topic that initiated this discussion is about a BLANK screen. Expect this to be general and not specific to Migration. Would expect a link here to the topic explainig what to do. What about disabling system plugins, checking joomla_update.php? [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 12:27, 28 December 2014 (CST)

Joomla 2.5 to 3.10 Step by Step Migration

2014-12-16T16:28:14Z

Sovainfo: /* Going to Joomla! 3.x */ Adding Purge Cache when update not showing

The following are step by step instructions to migrate your 2.5.x site to Joomla 3.x. While there are hundreds of different scenarios, this will give you the basic procedure to follow. Very complex migrations will likely be as a result of third-party extensions. You are encouraged to contact the developers of third-party extensions for their suggested path to migrate their extensions.

== Intro ==

The migration from Joomla 2.5 to 3.x is considered a mini-migration. This is because the Joomla core extensions will upgrade with a “one-click” upgrade via the Joomla! Update component in the backend administrator side of Joomla. Many third-party extensions are a one-click upgrade too. Some are not. You need to look at each one and determine what path the extension needs to follow to get from 2.5 to 3.x. If you haven't already, you might be interested in reading the [[Migration Step by Step Self Assessment|Self Assessment]] and [[Planning for Mini-Migration - Joomla 2.5 to 3.x|Planning for 2.5 to 3.x Migration]] prior to following the steps below.

Joomla Core Extensions:

* Categories
* Articles
* Menus
* Modules (core modules - not third-party)
* Banners
* Contacts
* Messaging
* Newsfeeds
* Redirect
* Search
* Smart Search
* Weblinks

=== For very large or complex 2.5 to 3.x migrations ===

The one-click update will be fine and work well for many. For some larger, more complex sites, the one-click update may not be the best route. For large or very complex sites, you may want to follow instructions for a regular migration and bypass the one-click update functionality. To do this, follow the same instructions for [[Planning Migration - Joomla 1.5 to 3|planning 1.5 to 3.x]] and [[Joomla 1.5 to 3.x Step by Step Migration|migrating from Joomla 1.5 to 3.x]], simply substitute 2.5 for 1.5 while reading.

== Step by Step ==

=== Set up a Development Location ===
# Take a backup of your live 2.5 site. You can use a suggested tool (see bottom of page) or you can do this manually
#*[[Backup_Basics_for_a_Joomla!_Web_Site|Backup Basics for a Joomla! Web Site]]
#*[[What_are_the_best_practices_for_site_backups%3F|What are the best practices for site backups?]]
# Make sure your environment meets the [http://www.joomla.org/about-joomla/technical-requirements.html technical requirements for Joomla 3] before proceeding
# Create a new database and new user to restore your 2.5 site to.
# Create a testing site or build area to work in and restore the back up copy of your 2.5 site in one of the following places:
#* A subdomain
#* A subdirectory
#* A local device via [http://www.wampserver.com/en/ WAMP], [http://www.mamp.info/en/ MAMP], [http://sourceforge.net/projects/lampas/ LAMP], [http://sourceforge.net/projects/xampp/ XAMPP].
#* A new hosting account on a temporary domain in the root (if you would like to change hosts in the process of migration)
#**Restoring a site on a local device. See [[Installing Joomla locally]] and [[Setting up your workstation for Joomla development]].
#**Restoring a site with a tool listed at bottom of page (read the developer documentation)''
# In your test location, update your Joomla 2.5 instance to the latest maintenance release (currently 2.5.28).
# Test.
# Backup again.

=== Assess Each Extension ===

# You are going to be looking at every single extension installed on your site. You will be determining if they need to update to the latest version or be uninstalled. In Joomla 2.5.28 you can go to {{rarr|Extension Manager,Update tab}} and click '''Find Updates''' which will add a tooltip in the Manage tab giving some compatibility information from the backend. This functionality only supports extensions that update via the Extension Manager Update tab. If you have extensions installed that do not use the Joomla extension update then they need to be assessed manually as detailed below. The same goes for those extensions that have a tooltip. You will still need to check the type of package and migration path with the extension developer to verify how to upgrade/migrate.
# Go to {{rarr|Extension Manager,Manage tab}}
# Click the drop-down for Type.
# Select Package from the drop-down.{{-}}[[File:J25-admin-extension-manage-package-en.png|border]]{{-}}{{note|Selecting Package first is recommended because if there is something you need to uninstall in a package, it will automatically uninstall the associated Modules, Plugins, or anything else in the package at one time.}}
# Uninstall any Packages that are no longer needed or will not be migrating to Joomla 3.
# Repeat this process of going through the Manage tab for all Types in the drop-down: Component, File, Language, Library, Module, Plugin, and Template. If the Author states Joomla! Project, then leave those extensions alone. Smart Search is a Joomla core supported extension even though the Author fields are blank. For all others, make sure that you uninstall those not in use or not compatible with Joomla 3.x.{{-}}{{note|'''NOTE!''' You will not be able to uninstall a Template that is set as default. You will need to select a Core supported template like Beez or Atomic and then uninstall the template if you need to do so.|type=serious}}
# Make a note of any versions of Packages and Components currently running that you will be keeping on your site. You can use the [http://docs.joomla.org/images/5/59/Third-Party_Extension_Inventory_Worksheet.pdf Third-Party Extension Inventory Worksheet] or just copy/paste them into a document for reference.
# Update all extensions to the latest versions.
# Before and as you update, note if the extensions have both 2.5 & 3.x versions in the same package. If so, they will be fine to "one-click update." If not, and 2.5 and 3.x have different packages, you need to look at them case by case. They will normally fall into one of the following scenarios:
#* The extension has separate packages but upon upgrading to 3.x, they automatically detect this and still work. Make sure the developer confirms this.
#* The extension has separate packages that need to be uninstalled in 2.5 and then installed with the Joomla 3.x version once the site is migrated. An example of this might be a content plugin. It is very simple to uninstall it in 2.5 and then install it again in 3.x.
#* See [[Template_Considerations_During_Migration|Template Considerations]] for more specific information on templates.
{{-}}{{note|'''Note on Core Supported Extensions:''' If you are using a Core Supported Extension (Banners, Contacts, Messaging, Newsfeeds, Redirect, Search, Smart Search, or Weblinks) in Joomla 2.5 and it has been decoupled in Joomla 3.4+, Joomla will detect their use during the upgrade and install those Core Supported Extensions automatically.|type=notice}}

=== Going to Joomla! 3.x ===
Once you have either updated or uninstalled your third-party extensions so that only those compatible with Joomla 3 are remaining in your installation continue with the following steps:

# Go to {{rarr|System,Global Configuration,Server tab}} and turn Error Reporting from System Default to Maximum. Make sure to Save & Close.{{-}} [[File:j25-system-global-config-server-tab-en.png|border]]
# Go to {{rarr|Extensions,Plugin Manager}} and enter Remember Me into the Filter and press enter.
# Disable the Remember Me plugin by clicking the green check mark and making it a red circle.{{-}}[[File:j25-extension-plugin-remember-me-en.png|border]]
# Take another backup
# Recommended but not required: Fix assets. ([[Fixing_the_assets_table|Fixing the assets table]]). See below for a tool to do this in just a few clicks.
# Go to {{rarr|Components,Joomla Update}}. (It should say no updates found. If it doesn’t, update Joomla to the latest version and test. Then do another backup.) Click on the Options button at the top right corner.
# Select Short Term Support (This is the current text - it may be different in the future) from the drop-down for Update server.{{-}}[[File:j25-component-joomla-update-select-support-en.png|border]]
# Click Save & Close.
# You will then see your Installed Joomla Version, the Latest Joomla! verion and the URL for the update package.{{-}}[[File:j25-component-joomla-version-update-en.png|border]]
# If the update is not showing go to {{rarr|Extension manager,Update}} and press Purge Cache from the toolbar. Now the update to J3 should show,
# Cross your fingers, make sure you turned off remember me and that you have a backup from just before this point.
# Click the Install the update button.
# Watch the spinning circle go round and round and feel the anxiety building. No just kidding. The amount of time the wheel spins is dependent on your site, internet connection, and server speed.
# If all goes well, you will get to a totally new look to the backend administrator panel.{{-}}[[File:j32-administrator-overview-en.png|border]]
# Click the Purge button given.
# Go to {{rarr|Extensions,Extension Manager,Database}} and click Fix
# From the Extension Manager go to Discover and see if there are any extensions to install
# # Recommended but not required: Fix assets. ([[Fixing_the_assets_table|Fixing the assets table]]). See below for a tool to do this in just a few clicks.
# Enable Remember Me from the Plugin Manager.
# Go to the frontend of your site and see if it shows up even if it’s not the right template. If so, continue. If not, see [[Joomla 2.5 to 3.x Common Migration Errors|common errors during migration]].
# Take a backup.
# Go to {{rarr|Content,Article Manager,Options button,Editing Layout tab}} and set the Save History to Yes.
# Install your new template or other extensions if you have them to install. Back up often.
# Configure them. Back up often.
# Test everything. Back up often.

=== Going Live with your Joomla! 3.x Site ===
# When you’re ready to go live, back up your 2.5 site for a last time. Restore it in a subdirectory or subdomain if you would like to.
# Back up your Joomla 3.x site and move or restore your Joomla! 3.x site to the root (or change nameservers if you were building on a temp domain at a new hosting account root).
# Test again.
# Remove 2.5 site from server within a couple of days.
# Remove all dev sites you may have been working with or keep them up-to-date if they are running a current version in order to ward off hack attempts on your server.

If you had data change on the 2.5 site while you were migrating to 3.x you will want to get that data moved over to the 3.x site before going live. You can do this manually (make sure you keep the same user IDs - go in order) or by using a [http://extensions.joomla.org/extensions/migration-a-conversion/data-import-a-export transfer tool/third-party extension].

== Suggested Tools ==
*[http://extensions.joomla.org/extensions/access-a-security/site-security/backup/1606 Akeeba Backup] for backup and restore.
*[http://extensions.joomla.org/extensions/access-a-security/site-access/backend-a-full-access-control/17951 ACL Manager ACL Manager] to fix asset issues in a few clicks.

[[Category:Migration]]
[[Category:Tutorials]]

Joomla 2.5 to 3.10 Step by Step Migration

2014-11-25T17:45:54Z

Sovainfo: /* Assess Each Extension */ Consider it a sinn referring to other docs without hyplerlink

The following are step by step instructions to migrate your 2.5.x site to Joomla 3.x. While there are hundreds of different scenarios, this will give you the basic procedure to follow. Very complex migrations will likely be as a result of third-party extensions. You are encouraged to contact the developers of third-party extensions for their suggested path to migrate their extensions.

== Intro ==

The migration from Joomla 2.5 to 3.x is considered a mini-migration. This is because the Joomla core extensions will upgrade with a “one-click” upgrade via the Joomla! Update component in the backend administrator side of Joomla. Many third-party extensions are a one-click upgrade too. Some are not. You need to look at each one and determine what path the extension needs to follow to get from 2.5 to 3.x. If you haven't already, you might be interested in reading the [[Migration Step by Step Self Assessment|Self Assessment]] and [[Planning for Mini-Migration - Joomla 2.5 to 3.x|Planning for 2.5 to 3.x Migration]] prior to following the steps below.

Joomla Core Extensions:

* Categories
* Articles
* Menus
* Modules (core modules - not third-party)
* Banners
* Contacts
* Messaging
* Newsfeeds
* Redirect
* Search
* Smart Search
* Weblinks

== Step by Step ==

=== Set up a Development Location ===
# Take a backup of your live 2.5 site. You can use a suggested tool (see bottom of page) or you can do this manually
#*[[Backup_Basics_for_a_Joomla!_Web_Site|Backup Basics for a Joomla! Web Site]]
#*[[What_are_the_best_practices_for_site_backups%3F|What are the best practices for site backups?]]
# Make sure your environment meets the [http://www.joomla.org/about-joomla/technical-requirements.html technical requirements for Joomla 3] before proceeding
# Create a new database and new user to restore your 2.5 site to.
# Create a testing site or build area to work in and restore the back up copy of your 2.5 site in one of the following places:
#* A subdomain
#* A subdirectory
#* A local device via [http://www.wampserver.com/en/ WAMP], [http://www.mamp.info/en/ MAMP], [http://sourceforge.net/projects/lampas/ LAMP], [http://sourceforge.net/projects/xampp/ XAMPP].
#* A new hosting account on a temporary domain in the root (if you would like to change hosts in the process of migration)
#**Restoring a site on a local device. See [[Installing Joomla locally]] and [[Setting up your workstation for Joomla development]].
#**Restoring a site with a tool listed at bottom of page (read the developer documentation)''
# In your test location, update your Joomla 2.5 instance to the latest maintenance release (currently 2.5.27, expecting 2.5.28 to be the last one).
# Test.
# Backup again.

=== Assess Each Extension ===

# Go to {{rarr|Extension Manager,Manage tab}}
# You are going to be looking at every single extension installed on your site. You will be determining if they need to update to the latest version or be uninstalled.
# Click the drop-down for Type.
# Select Package from the drop-down.{{-}}[[File:J25-admin-extension-manage-package-en.png|border]]{{-}}{{note|Selecting Package first is recommended because if there is something you need to uninstall in a package, it will automatically uninstall the associated Modules, Plugins, or anything else in the package at one time.}}
# Uninstall any Packages that are no longer needed or will not be migrating to Joomla 3.
# Repeat this process of going through the Manage tab for all Types in the drop-down: Component, File, Language, Library, Module, Plugin, and Template. If the Author states Joomla! Project, then leave those extensions alone. Smart Search is a Joomla core supported extension even though the Author fields are blank. For all others, make sure that you uninstall those not in use or not compatible with Joomla 3.x.{{-}}{{note|'''NOTE!''' You will not be able to uninstall a Template that is set as default. You will need to select a Core supported template like Beez or Atomic and then uninstall the template if you need to do so.|type=serious}}
# Make a note of any versions of Packages and Components currently running that you will be keeping on your site. You can use the [http://docs.joomla.org/images/5/59/Third-Party_Extension_Inventory_Worksheet.pdf Third-Party Extension Inventory Worksheet] or just copy/paste them into a document for reference.
# Update all extensions to the latest versions.
# Before and as you update, note if the extensions have both 2.5 & 3.x versions in the same package. If so, they will be fine to "one-click update." If not, and 2.5 and 3.x have different packages, you need to look at them case by case. They will normally fall into one of the following scenarios:
#* The extension has separate packages but upon upgrading to 3.x, they automatically detect this and still work. Make sure the developer confirms this.
#* The extension has separate packages that need to be uninstalled in 2.5 and then installed with the Joomla 3.x version once the site is migrated. An example of this might be a content plugin. It is very simple to uninstall it in 2.5 and then install it again in 3.x.
#* See [[Template_Considerations_During_Migration|Template Considerations]] for more specific information on templates.
{{-}}{{note|'''Note on Core Supported Extensions:''' If you are using a Core Supported Extension (Banners, Contacts, Messaging, Newsfeeds, Redirect, Search, Smart Search, or Weblinks) in Joomla 2.5 and it has been decoupled in Joomla 3.4+, Joomla will detect their use during the upgrade and install those Core Supported Extensions automatically.|type=notice}}

=== Going to Joomla! 3.x ===
Once you have either updated or uninstalled your third-party extensions so that only those compatible with Joomla 3 are remaining in your installation continue with the following steps:

# Go to {{rarr|System,Global Configuration,Server tab}} and turn Error Reporting from System Default to Maximum. Make sure to Save & Close.{{-}} [[File:j25-system-global-config-server-tab-en.png|border]]
# Go to {{rarr|Extensions,Plugin Manager}} and enter Remember Me into the Filter and press enter.
# Disable the Remember Me plugin by clicking the green check mark and making it a red circle.{{-}}[[File:j25-extension-plugin-remember-me-en.png|border]]
# Take another backup
# Recommended but not required: Fix assets. ([[Fixing_the_assets_table|Fixing the assets table]]). See below for a tool to do this in just a few clicks.
# Go to {{rarr|Components,Joomla Update}}. (It should say no updates found. If it doesn’t, update Joomla to the latest version and test. Then do another backup.) Click on the Options button at the top right corner.
# Select Short Term Support (This is the current text - it may be different in the future) from the drop-down for Update server.{{-}}[[File:j25-component-joomla-update-select-support-en.png|border]]
# Click Save & Close.
# You will then see your Installed Joomla Version, the Latest Joomla! verion and the URL for the update package.{{-}}[[File:j25-component-joomla-version-update-en.png|border]]
# Cross your fingers, make sure you turned off remember me and that you have a backup from just before this point.
# Click the Install the update button.
# Watch the spinning circle go round and round and feel the anxiety building. No just kidding. The amount of time the wheel spins is dependent on your site, internet connection, and server speed.
# If all goes well, you will get to a totally new look to the backend administrator panel.{{-}}[[File:j32-administrator-overview-en.png|border]]
# Click the Purge button given.
# Go to {{rarr|Extensions,Extension Manager,Database}} and click Fix
# From the Extension Manager go to Discover and see if there are any extensions to install
# # Recommended but not required: Fix assets. ([[Fixing_the_assets_table|Fixing the assets table]]). See below for a tool to do this in just a few clicks.
# Enable Remember Me from the Plugin Manager.
# Go to the frontend of your site and see if it shows up even if it’s not the right template. If so, continue. If not, see [[Joomla 2.5 to 3.x Common Migration Errors|common errors during migration]].
# Take a backup.
# Go to {{rarr|Content,Article Manager,Options button,Editing Layout tab}} and set the Save History to Yes.
# Install your new template or other extensions if you have them to install. Back up often.
# Configure them. Back up often.
# Test everything. Back up often.

=== Going Live with your Joomla! 3.x Site ===
# When you’re ready to go live, back up your 2.5 site for a last time. Restore it in a subdirectory or subdomain if you would like to.
# Back up your Joomla 3.x site and move or restore your Joomla! 3.x site to the root (or change nameservers if you were building on a temp domain at a new hosting account root).
# Test again.
# Remove 2.5 site from server within a couple of days.

If you had data change on the 2.5 site while you were migrating to 3.x you will want to get that data moved over to the 3.x site before going live. You can do this manually (make sure you keep the same user IDs - go in order) or by using a [http://extensions.joomla.org/extensions/migration-a-conversion/data-import-a-export transfer tool/third-party extension].

== Suggested Tools ==
*[http://extensions.joomla.org/extensions/access-a-security/site-security/backup/1606 Akeeba Backup] for backup and restore.
*[http://extensions.joomla.org/extensions/access-a-security/site-access/backend-a-full-access-control/17951 ACL Manager ACL Manager] to fix asset issues in a few clicks.

[[Category:Migration]]
[[Category:Tutorials]]

Joomla 2.5 to 3.10 Step by Step Migration

2014-11-23T15:22:43Z

Sovainfo: /* Set up a Development Location */ Update to 2.5.27/2.5.28

The following are step by step instructions to migrate your 2.5.x site to Joomla 3.x. While there are hundreds of different scenarios, this will give you the basic procedure to follow. Very complex migrations will likely be as a result of third-party extensions. You are encouraged to contact the developers of third-party extensions for their suggested path to migrate their extensions.

== Intro ==

The migration from Joomla 2.5 to 3.x is considered a mini-migration. This is because the Joomla core extensions will upgrade with a “one-click” upgrade via the Joomla! Update component in the backend administrator side of Joomla. Many third-party extensions are a one-click upgrade too. Some are not. You need to look at each one and determine what path the extension needs to follow to get from 2.5 to 3.x. If you haven't already, you might be interested in reading the [[Migration Step by Step Self Assessment|Self Assessment]] and [[Planning for Mini-Migration - Joomla 2.5 to 3.x|Planning for 2.5 to 3.x Migration]] prior to following the steps below.

Joomla Core Extensions:

* Categories
* Articles
* Menus
* Modules (core modules - not third-party)
* Banners
* Contacts
* Messaging
* Newsfeeds
* Redirect
* Search
* Smart Search
* Weblinks

== Step by Step ==

=== Set up a Development Location ===
# Take a backup of your live 2.5 site. You can use a suggested tool (see bottom of page) or you can do this manually
#*[[Backup_Basics_for_a_Joomla!_Web_Site|Backup Basics for a Joomla! Web Site]]
#*[[What_are_the_best_practices_for_site_backups%3F|What are the best practices for site backups?]]
# Make sure your environment meets the [http://www.joomla.org/about-joomla/technical-requirements.html technical requirements for Joomla 3] before proceeding
# Create a new database and new user to restore your 2.5 site to.
# Create a testing site or build area to work in and restore the back up copy of your 2.5 site in one of the following places:
#* A subdomain
#* A subdirectory
#* A local device via [http://www.wampserver.com/en/ WAMP], [http://www.mamp.info/en/ MAMP], [http://sourceforge.net/projects/lampas/ LAMP], [http://sourceforge.net/projects/xampp/ XAMPP].
#* A new hosting account on a temporary domain in the root (if you would like to change hosts in the process of migration)
#**Restoring a site on a local device. See [[Installing Joomla locally]] and [[Setting up your workstation for Joomla development]].
#**Restoring a site with a tool listed at bottom of page (read the developer documentation)''
# In your test location, update your Joomla 2.5 instance to the latest maintenance release (currently 2.5.27, expecting 2.5.28 to be the last one).
# Test.
# Backup again.

=== Assess Each Extension ===

# Go to {{rarr|Extension Manager,Manage tab}}
# You are going to be looking at every single extension installed on your site. You will be determining if they need to update to the latest version or be uninstalled.
# Click the drop-down for Type.
# Select Package from the drop-down.{{-}}[[File:J25-admin-extension-manage-package-en.png|border]]{{-}}{{note|Selecting Package first is recommended because if there is something you need to uninstall in a package, it will automatically uninstall the associated Modules, Plugins, or anything else in the package at one time.}}
# Uninstall any Packages that are no longer needed or will not be migrating to Joomla 3.
# Repeat this process of going through the Manage tab for all Types in the drop-down: Component, File, Language, Library, Module, Plugin, and Template. If the Author states Joomla! Project, then leave those extensions alone. Smart Search is a Joomla core supported extension even though the Author fields are blank. For all others, make sure that you uninstall those not in use or not compatible with Joomla 3.x.{{-}}{{note|'''NOTE!''' You will not be able to uninstall a Template that is set as default. You will need to select a Core supported template like Beez or Atomic and then uninstall the template if you need to do so.|type=serious}}
# Make a note of any versions of Packages and Components currently running that you will be keeping on your site. You can use the [http://docs.joomla.org/images/5/59/Third-Party_Extension_Inventory_Worksheet.pdf Third-Party Extension Inventory Worksheet] or just copy/paste them into a document for reference.
# Update all extensions to the latest versions.
# Before and as you update, note if the extensions have both 2.5 & 3.x versions in the same package. If so, they will be fine to "one-click update." If not, and 2.5 and 3.x have different packages, you need to look at them case by case. They will normally fall into one of the following scenarios:
#* The extension has separate packages but upon upgrading to 3.x, they automatically detect this and still work. Make sure the developer confirms this.
#* The extension has separate packages that need to be uninstalled in 2.5 and then installed with the Joomla 3.x version once the site is migrated. An example of this might be a content plugin. It is very simple to uninstall it in 2.5 and then install it again in 3.x.
#* See Template Considerations for more specific information on templates.
{{-}}{{note|'''Note on Core Supported Extensions:''' If you are using a Core Supported Extension (Banners, Contacts, Messaging, Newsfeeds, Redirect, Search, Smart Search, or Weblinks) in Joomla 2.5 and it has been decoupled in Joomla 3.4+, Joomla will detect their use during the upgrade and install those Core Supported Extensions automatically.|type=notice}}

=== Going to Joomla! 3.x ===
Once you have either updated or uninstalled your third-party extensions so that only those compatible with Joomla 3 are remaining in your installation continue with the following steps:

# Go to {{rarr|System,Global Configuration,Server tab}} and turn Error Reporting from System Default to Maximum. Make sure to Save & Close.{{-}} [[File:j25-system-global-config-server-tab-en.png|border]]
# Go to {{rarr|Extensions,Plugin Manager}} and enter Remember Me into the Filter and press enter.
# Disable the Remember Me plugin by clicking the green check mark and making it a red circle.{{-}}[[File:j25-extension-plugin-remember-me-en.png|border]]
# Take another backup
# Recommended but not required: Fix assets. ([[Fixing_the_assets_table|Fixing the assets table]]). See below for a tool to do this in just a few clicks.
# Go to {{rarr|Components,Joomla Update}}. (It should say no updates found. If it doesn’t, update Joomla to the latest version and test. Then do another backup.) Click on the Options button at the top right corner.
# Select Short Term Support (This is the current text - it may be different in the future) from the drop-down for Update server.{{-}}[[File:j25-component-joomla-update-select-support-en.png|border]]
# Click Save & Close.
# You will then see your Installed Joomla Version, the Latest Joomla! verion and the URL for the update package.{{-}}[[File:j25-component-joomla-version-update-en.png|border]]
# Cross your fingers, make sure you turned off remember me and that you have a backup from just before this point.
# Click the Install the update button.
# Watch the spinning circle go round and round and feel the anxiety building. No just kidding. The amount of time the wheel spins is dependent on your site, internet connection, and server speed.
# If all goes well, you will get to a totally new look to the backend administrator panel.{{-}}[[File:j32-administrator-overview-en.png|border]]
# Click the Purge button given.
# Go to {{rarr|Extensions,Extension Manager,Database}} and click Fix
# From the Extension Manager go to Discover and see if there are any extensions to install
# # Recommended but not required: Fix assets. ([[Fixing_the_assets_table|Fixing the assets table]]). See below for a tool to do this in just a few clicks.
# Enable Remember Me from the Plugin Manager.
# Go to the frontend of your site and see if it shows up even if it’s not the right template. If so, continue. If not, see [[Joomla 2.5 to 3.x Common Migration Errors|common errors during migration]].
# Take a backup.
# Go to {{rarr|Content,Article Manager,Options button,Editing Layout tab}} and set the Save History to Yes.
# Install your new template or other extensions if you have them to install. Back up often.
# Configure them. Back up often.
# Test everything. Back up often.

=== Going Live with your Joomla! 3.x Site ===
# When you’re ready to go live, back up your 2.5 site for a last time. Restore it in a subdirectory or subdomain if you would like to.
# Back up your Joomla 3.x site and move or restore your Joomla! 3.x site to the root (or change nameservers if you were building on a temp domain at a new hosting account root).
# Test again.
# Remove 2.5 site from server within a couple of days.

If you had data change on the 2.5 site while you were migrating to 3.x you will want to get that data moved over to the 3.x site before going live. You can do this manually (make sure you keep the same user IDs - go in order) or by using a [http://extensions.joomla.org/extensions/migration-a-conversion/data-import-a-export transfer tool/third-party extension].

== Suggested Tools ==
*[http://extensions.joomla.org/extensions/access-a-security/site-security/backup/1606 Akeeba Backup] for backup and restore.
*[http://extensions.joomla.org/extensions/access-a-security/site-access/backend-a-full-access-control/17951 ACL Manager ACL Manager] to fix asset issues in a few clicks.

[[Category:Migration]]
[[Category:Tutorials]]

Template Considerations During Migration

2014-11-23T14:50:11Z

Sovainfo: /* You are using a template that was purchased from a template club */

Templates sometimes throw people for a loop during a migration. It need not be so. With a little explanation things can become clear as to what your options are.

== Intro ==

Templates are an extension. Just like components, modules, and plugins are extensions so is a template.

In a migration setting you will need to decide what to do about your current template (which determines the current “look and feel” of your site).

For the most part your template scenario will fit into one of the options below:

* You are using a template that was purchased from a template club.
* You are using a template that was a one time purchase from some template provider.
* You had a custom template designed for you.
* You are using a default template that came with your Joomla installation (Joomla! 1.5 default templates are Rhuk_milkyway, JA Purity, Beez and Joomla! 2.5 default templates are Atomic and two different versions of Beez). It may have been customised significantly or not at all.

== Assessing your Template Scenario ==

Before deciding what to do, you will want to assess if you want to keep the existing look of your current template. If you want a change, this is the time to decide that. Perhaps the biggest reason you may want to change out your template is to utilize newer technology found in templates of the current day. Responsive templates were not available in 1.5 (unless you recently hired someone to make your 1.5 template mobile-friendly) and even at the beginning of the 2.5 life cycle, mobile versions of templates were slim and responsive not quite there yet.

Let’s take these scenarios one at a time:

=== You are using a template that was purchased from a template club ===

This is the easiest one - most of the time. If you purchased a template from a template club, go back to the company and see if they have a version of your template for Joomla 3.x. If so, excellent, with a few things to think about.
If you’re running 1.5 going to 3.x, check to see if the version for Joomla 3 is responsive if that’s important to you.
If you’re going from 1.5 to 3, chances are good that there will be some differences in the 1.5 version of the template and the 3 version of the template. Be prepared to make some customisations to the template if you want to get it to look ''exactly'' the same.

If you’re going from 2.5 to 3.x, check to see if the 2.5 and 3.x versions are packed in the same package from the developer. If they are not, check with the developer on steps to upgrade from Joomla 2.5 to 3.x. If 2.5 and 3.x are in the same package, you’re golden. If they’re not, you might still be golden. It just depends on the upgrade path of the developer.

=== You are using a template that was a one time purchase from some template provider ===
If you purchased a template from a template provider that was a one time purchase, go back to the company and see if there’s a version available for Joomla 3.x. If there isn’t, you’re probably out of luck. Yet you can try contacting someone from the company to see if they can update it for you and make it compatible with Joomla 3.x.

If that fails, then you will need to either:

# Choose a new template.
# Convert the template to be compatible with Joomla 3.x. (Note: may not be responsive.)

Item 1 is self explanatory. You can choose a template from a commercial provider or customise the Protostar default template (see more on Protostar below) that installs with Joomla 3.x. Item 2 not as simple. In order to convert your existing template to be compatible with Joomla 3, see the following section.

== Template Conversions or Template Migrations ==

=== 1.5 to 3 Template Conversions ===
[[Migrating a Template from Joomla 1.5 to 3.x]]

=== 1.5 to 2.5 Template Conversions ===
*[[Upgrading a Joomla 1.5 template to Joomla 2.5]]
* http://magazine.joomla.org/issues/issue-may-2012/item/740-How-to-convert-Joomla-15-template-to-Joomla-25

=== 2.5 to 3 Template Conversions ===
*[[J3.x:Converting A Previous Joomla! Version Template]]
*http://stackoverflow.com/questions/16055707/convert-joomla-2-5-template-to-3-0
*https://www.youtube.com/watch?v=E13QMWgvwlA

=== You had a custom template designed for you ===
If you had a custom template designed for your 1.5 or 2.5 site, it will need to be converted to be compatible with Joomla 3. See links in the previous section. If you need to hire someone to convert your existing template to be compatible with Joomla 3.x, check out the Joomla! Resource Directory in either the [http://www.joomla.org/about-joomla/technical-requirements.html Template Development] or [http://resources.joomla.org/en/providers-by-category/category/migration-and-upgrade-services Migrations & Upgrades] categories.

=== You are using a default template that came with your Joomla installation ===
Joomla! 1.5 default templates are Rhuk_milkyway, JA Purity, and Beez. Joomla! 2.5 default templates are Atomic and two different versions of Beez). It may have been customised significantly or not at all. If you are using a 2.5 default template and going to Joomla 3.x, you will be able to do a one-click update. If you are using a 1.5 default template then you will need to go through one of the steps above to update it for Joomla 3.x. (If someone finds this information incorrect, please contribute and fix it.

Before deciding you want to convert your 1.5 template to Joomla 3, you may want to seriously consider finding a new template with similarities to your existing template. Chances are it will be cheaper and faster to use a new one then convert the old one. If you want to convert the old one and don’t have the skills to do it yourself, visit the Joomla! Resource Directory (link to either design or migration? what do you guys think?).

=== When choosing templates ===

* Only look at one template company at a time or it gets overwhelming
* If you start to get overwhelmed, take a break even if that means another day
* Try to look past the busy and flashy demos. You’re going to be putting your content into the template, not doing everything the template can do.
* Look at the module positions and variations of the templates
* Drink plenty of water while looking for templates and stretch every hour or so

== Using the Protostar default template in Joomla 3.x ==
This section is incomplete. If you have knowledge in this topic, please participate by adding to this document. In the interim, a Google search on customising Protostar will yield you many results outside of Joomla! Docs.

[[Joomla_LESS]]

[[Category:Migration]]
[[Category:Tutorials]]

J3.x talk:Creating a simple module/Developing a Basic Module

2014-11-12T01:28:27Z

Sovainfo: /* Last line of mod_helloworld.php */

== Last line of mod_helloworld.php ==
As a newbie within module developing I'd say, even if it's maybe nothing - the last paragraph in this section states "The one line that we haven’t explained so far is the first line.". But the last line haven't been explained either. Not to go into any deep explanations, just a sentence or two - so you know what it'll do to the module if you'd leave it out. [[User:Alekks|Alekks]] ([[User talk:Alekks|talk]]) 14:33, 11 November 2014 (CST)
:Absolutely agree. section 2 is very hard to read. The line you are referring to implements the 3rd bullit point. Suggest to change the bullit points into a,b,c and mention add a, add b, add c so the reader knows whereto the comments apply. add c would at least show the code and the text at the bullit point. What do you think? [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 19:28, 11 November 2014 (CST)

== $params ==

This document explains calling a helper class passing $params for future use. The problem is, it doesn't mention where that $params is coming from. And what other data is available? [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 08:41, 6 May 2014 (CDT)

:So there probably should be a sentence saying $params is generated by us automatically. As this is a "simple" module tutorial - I really want to avoid going into the fact this is automatically generated by the JModuleHelper. I'd rather just say the thing with the params is created magically for you to manipulate. --[[User:Wilsonge|Wilsonge]] ([[User talk:Wilsonge|talk]]) 18:43, 6 May 2014 (CDT)

::Why would you want to avoid mentioning JModuleHelper::renderModule. The first thing that comes to mind is how should I know $params is available? Where to look for the other variables availabe. Or state them, would be nice to know $app is available!. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 03:49, 7 May 2014 (CDT)

:Because it's a "simple" module tutorial. When I first developed modules (which scarily wasn't that long ago) I didn't care where all this stuff came from - it was just amazing that it existed. Again for simple module development I'm not sure that matters - with the $app thing for example I'd rather get people redefining it. Firstly as I said I don't think people for a basic "here's how to create a module" tutorial we need to involve JModuleHelper and also because I really think you should define $app yourself for your things so it's as standalone as possible! The only thing arguably you should need is the $module object (as that contains params + module title instance) or if you only need the params then just $params.

::Never mind. Hope that the J4 redesign will get rid of modules anyway![[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 19:34, 7 May 2014 (CDT)

== Don't like "for page rendering" ==

Don't like "for page rendering", would say: while rendering the page. It completely puts me off, thinking the module is the procedure to render a page, which is handled by JDocumentHtml. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 04:05, 7 May 2014 (CDT)

:In retrospect I don't like it either :P changed

Form field

2014-10-20T10:34:30Z

Sovainfo: /* Showon */ comma-separated

<onlyinclude>
== Introduction ==
Form fields are fields in a HTML <code><form></code>. Joomla! 2.5 {{JVer|2.5}} and newer supply the JForm class to conveniently and flexibly create forms with a large amount of form fields. Each form field type is a subclass of JFormField.

In addition to being a flexible page creation tool, JFormFields are used by Joomla! to allow [[Administrator (User)|administrators]] to configure Joomla! or its extensions without changing the underlying code. In Joomla! 1.5, this was handled by the now deprecated [[API15:JParameter|JParameter]] and [[API15:JElement|JElement]] classes.

To define form fields in the configuration of an extension, you must include them in a named fieldset, such as <code><fieldset name="basic"></code>, that is within the <code><fields name="params"></code> section of the <code><config></code> element in your [[Manifest files|XML manifest file]].
</onlyinclude>

== Form validation ==
{{:Form validation}}
== Standard form field types ==
{{:Standard form field types}}
== Custom form field types ==
An [[extension]] can define its own form field types, which can then be used in its own forms or forms created by another extension. See [[Creating a custom form field type]] for instructions.
=== Modal form field types ===
If you have a field with a lot of values that don't fit a selection box, you can always make a modal form field that will allow the user to pick an item from a modal page with a table, filtering options, etc. (jut like any administrator table, e.g. "Articles")
See [[Creating a modal form field]]

== Common attributes ==
=== Labelclass ===
Adding the attribute <code>labelclass</code> adds a CSS class for form field's label. Source: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=28450

=== Showon ===
Adding the attribute <code>showon</code> allows to hide the field based on the value(s) of another field.

Syntax to show the field "bar" only when "foo" is set to "1":
<source lang="php"><field
name="foo"
type="list"
>
<option value="1">JYES</option>
<option value="0">JNO</option>
</field>
<field
name="bar"
type="text"
showon="foo:1"
/></source>
To match multiple values one can provide a comma-separated list of values. Like <code>shown="foo:1,2"</code>

This was introduced with PullRequest: https://github.com/joomla/joomla-cms/pull/3379, available starting with Joomla 3.2.4.
<noinclude>
[[Category:Landing Pages]]
[[Category:Form fields| ]]
[[Category:Development]]
</noinclude>

Connecting to an external database

2014-10-16T03:06:49Z

Sovainfo: JModelLegacy instead of JModel

If you need to access tables within the same database as your Joomla! installation then you can simply use the [[JFactory/getDBO|JFactory->getDbo]] method. This uses the already established connection that Joomla! uses to connect to the database. For example:

<source lang="php">
<?php
$db = JFactory::getDbo();
?>
</source>

$db is now an object of type [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html JDatabaseDriver] and you can perform database operations on it using the usual methods.

But what if you want to connect to a completely different database from the one used by Joomla!?. This might be a different database on the same machine as your Joomla! site or it might be on a different host and perhaps even require a different database driver. Well, you can do this using the [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html#getInstance JDatabaseDriver->getInstance] method.

<source lang="php">
<?php
$option = array(); //prevent problems

$option['driver'] = 'mysql'; // Database driver name
$option['host'] = 'db.myhost.com'; // Database host name
$option['user'] = 'fredbloggs'; // User for database authentication
$option['password'] = 's9(39s£h[%dkFd'; // Password for database authentication
$option['database'] = 'bigdatabase'; // Database name
$option['prefix'] = 'abc_'; // Database prefix (may be empty)

$db = JDatabaseDriver::getInstance( $option );
?>
</source>

$db is now an object of type [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html JDatabaseDriver] and you can perform database operations on it using the usual methods.

Note that if the database uses a non-standard port number then this can be specified by adding it to the end of the host name. For example, you might have your MySQL database running on port 3307 (the default is port 3306), in which case your host name might be 'db.myhost.com:3307'.

One feature of using [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html#getInstance JDatabaseDriver->getInstance] is that if another call is made with the same parameters it will return the previously created object rather than creating a fresh one.

Note, however, that the parameters must match exactly for this to happen. For example, if two calls were made to a MySQL database using [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html#getInstance JDatabaseDriver->getInstance], with the first using a host name of 'db.myhost.com' and the second using 'db.myhost.com:3306', then two separate connections would be made, even though port 3306 is the default port for MySQL and so the parameters are logically the same.

If you want to use the JModelLegacy with pagination etc. you can choose a different way. The point is, you have to replace the standard database object linked to the Joomla background database using [[JModelLegacy/setDbo|JModelLegacy->setDbo]]. The first step is to override the constructor of your JModelLegacy in your model file
<source>
public function __construct($config = array())
{
parent::__construct($config);

$option = array(); //prevent problems

$option['driver'] = 'mysql'; // Database driver name
$option['host'] = 'localhost'; // Database host name
$option['user'] = 'myusername'; // User for database authentication
$option['password'] = 'saltedpassword'; // Password for database authentication
$option['database'] = 'db_extern'; // Database name
$option['prefix'] = ''; // Database prefix (may be empty)

$db = JDatabaseDriver::getInstance( $option );
parent::setDbo($db);
}
</source>
After that JModelLegacy behaves normal but uses your database.
<noinclude>[[Category:Development]][[Category:Database]][[Category:FAQ]][[Category:Tutorials]]</noinclude>

Connecting to an external database

2014-10-16T02:50:25Z

Sovainfo: Using JDatabaseDriver instead of JDatabase

If you need to access tables within the same database as your Joomla! installation then you can simply use the [[JFactory/getDBO|JFactory->getDbo]] method. This uses the already established connection that Joomla! uses to connect to the database. For example:

<source lang="php">
<?php
$db = JFactory::getDbo();
?>
</source>

$db is now an object of type [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html JDatabaseDriver] and you can perform database operations on it using the usual methods.

But what if you want to connect to a completely different database from the one used by Joomla!?. This might be a different database on the same machine as your Joomla! site or it might be on a different host and perhaps even require a different database driver. Well, you can do this using the [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html#getInstance JDatabaseDriver->getInstance] method.

<source lang="php">
<?php
$option = array(); //prevent problems

$option['driver'] = 'mysql'; // Database driver name
$option['host'] = 'db.myhost.com'; // Database host name
$option['user'] = 'fredbloggs'; // User for database authentication
$option['password'] = 's9(39s£h[%dkFd'; // Password for database authentication
$option['database'] = 'bigdatabase'; // Database name
$option['prefix'] = 'abc_'; // Database prefix (may be empty)

$db = JDatabaseDriver::getInstance( $option );
?>
</source>

$db is now an object of type [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html JDatabaseDriver] and you can perform database operations on it using the usual methods.

Note that if the database uses a non-standard port number then this can be specified by adding it to the end of the host name. For example, you might have your MySQL database running on port 3307 (the default is port 3306), in which case your host name might be 'db.myhost.com:3307'.

One feature of using [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html#getInstance JDatabaseDriver->getInstance] is that if another call is made with the same parameters it will return the previously created object rather than creating a fresh one.

Note, however, that the parameters must match exactly for this to happen. For example, if two calls were made to a MySQL database using [http://api.joomla.org/cms-3/classes/JDatabaseDriver.html#getInstance JDatabaseDriver->getInstance], with the first using a host name of 'db.myhost.com' and the second using 'db.myhost.com:3306', then two separate connections would be made, even though port 3306 is the default port for MySQL and so the parameters are logically the same.

If you want to use the JModel with pagination etc. you can choose a different way. The point is, you have to replace the standard database object linked to the Joomla background database using [[JDatabase/setDbo|JDatabase->setDbo]]. The first step is to override the constructor of your JModel in your model file
<source>
public function __construct($config = array())
{
parent::__construct($config);

$option = array(); //prevent problems

$option['driver'] = 'mysql'; // Database driver name
$option['host'] = 'localhost'; // Database host name
$option['user'] = 'myusername'; // User for database authentication
$option['password'] = 'saltedpassword'; // Password for database authentication
$option['database'] = 'db_extern'; // Database name
$option['prefix'] = ''; // Database prefix (may be empty)

$db = JDatabaseDriver::getInstance( $option );
parent::setDbo($db);
}
</source>
After that JModel behaves normal but uses your database.
<noinclude>[[Category:Development]][[Category:Database]][[Category:FAQ]][[Category:Tutorials]]</noinclude>

J3.x:Updating from an existing version

2014-10-07T13:06:53Z

Sovainfo: /* Browse to Components, Joomla Update */ adding update server and caching

{{warning|This page is only for upgrading from Joomla! versions '''"1.7''' or '''2.5"''' to '''3.x''' OR a '''3.x.x''' version to '''{{CurrentSTSVer}}'''.<br/><center><big>'''Always back up your site before updating.'''</big></center>}}

The recommended way to update installations of Joomla! is to use the Joomla Updater component found in the Components menu of your site Administrator(Method A) introduced in J2.5.4.

Updating earlier versions? Use one of the following methods.
*Use Install Method ([[#Method B - Install Method|Method B]])

{{notice|You should always review '''[[:Category:Upgrading Issues|Upgrading Issues]]''' and '''[[J3.1:Known upgrading issues and solutions|Known upgrading issues and solutions]]''' before upgrading.|title=Before You Begin}}

==Browse to Components, Joomla Update==
[[File:Componentsmenu.PNG]]

If an update is available there will be a message indicating this and a button to press. Which update you'll see depends on the setting for Update Server and caching. See options for Joomla! Update component. The first option shows the latest update of the major release in use. The second option shows the latest update of the latest major. Caching may cause not detecting an available update, purge cache. For J2.5 go to Extension manager => Update and press Purge cache.

[[File:Updatewaitingj3.PNG|475px]]
{{-}}

==Click on the "Install the Update" button and allow the update to run==

[[File:Updatesuccess3.PNG]]

== When it has completed you may need to refresh your screen or empty your browser cache to adjust for template CSS changes.==

Note: Joomla! will notify you on your administrator home page (control panel) when an update is needed, but it will not do the update for you. You need to press the button to start the update.

{{ambox|text=[[J3.1:Detailed_instructions_for_updating_from_3.1.2_to_3.1.4| Special Instructions for Version 3.1.2 Upgrades]]}}

'''Recommended Steps and actions:'''
It is recommended that you follow these steps when updating a production site:
# Back up your site before upgrading to a new version. That way, if something goes wrong during the upgrade process, you can easily restore your site to the earlier version.
# Review the release notes for the new version to be familiar with what was changed.
# Update using one of the recommended methods outlined in this document. These methods install the new program files, delete unneeded old program files, and update the database as needed for the new Joomla version.
# Clear your browser cache and check that the update was successful, using the steps outlined in the '''Checking Site''' tab.

=Method A - Update Method=
This is the easier way, also called ''One click update''

==Step 1: Make sure you have a current backup of your site==
In many cases, your host will make periodic site backups.

==Step 2a: Find and install updates==
# '''If your site is prior to 2.5.4, see Step 2b instead'''
# In the back end of your Joomla site, navigate to Components → Joomla Update.
# Click on Install the Update {{-}}[[Image:Update-screenshot-20120618-01.png|800px]]
# '''IMPORTANT:''' This process will take a few minutes. Wait until the process completes and it tells you that you are already on the current release, similar to the screen shown below.{{-}} [[Image:Update-screenshot-20120618-02.png|800px]]
# Congratulations! At this point, your site is updated.
'''Important:''' Clear your browser cache and check that your site is working correctly. See below Checking Your Site

==Step 2b: Find and install updates (Prior to updating 2.5.4)==
# In the back end of your Joomla site, navigate to Extensions → Extension Manager and open the Update tab.
# Click on the Purge Cache icon to clear out the cache.
# Click on the Find Updates icon in the toolbar. If there is an available update, the screen will list it, similar to the screen shown below. [[Image:Update-screenshot-20120124-01.png|frame|center]] Note that available upgrades for extensions used in the site will also show in the list.
# Select the update (using the checkbox) and click on the Update icon in the toolbar.
# '''IMPORTANT:''' This process will take a few minutes. Wait until the process completes and the success message shows, similar to the screen shown below. [[Image:Update-screenshot-20120124-02.png|frame|center]]
# Congratulations! At this point, your site is updated.
'''Important:''' Clear your browser cache and check that your site is working correctly. See below Checking Your Site

=Method B - Install Method=
In some cases it may not be possible to use the Extension Manager: Update method to update your site. One reason for this might be that you are using a non-standard distribution (for example, a distribution with a different default language installed). Another reason might be that your don't have a reliable enough internet connection to support automatic installation.

In this case, you can still do an easy installation using the Extension Manager: Install screen. Like the Update screen, this method will do the database updates automatically and will completely update your system without any further steps.

==Step 1: Make sure you have a current backup of your site==
In many cases, your host will make periodic site backups.

==Step 2: Locate the update file==
Locate the required archive file (for example, .zip, .tag.gz, or tar.bz2 archive) for your version. If you are updating to an x.x.0 release (for example, from 1.7.3 to 2.5.0), this will normally be a file like Joomla_2.5.0-Stable-Update_Package.zip. If you are updating within the same release series (for example, 2.5.0 to 2.5.1), then the file will be named something like Joomla_2.5.0_to_2.5.1-Stable-Patch_Package.zip.

At this point, you have three options:
# Install from URL
# Install from Directory
# Upload Package File

Install from URL is the easiest to do. With this option, the upgrade archive is loaded directly by the server, so it works well even if your local computer has a slow or unreliable internet connection.

Install from Directory is the safest method if the server itself has a slow internet connection. With this method, you use FTP to load the unpacked update files into a temporary folder on the server. Then you point to that directory on the server for the installation.

Upload Package File is fairly simple, but it requires that you have a good connection between your local computer and the server.

The screen below shows the Extension Manager: Install screen with the three options labeled.
[[Image:Update-screenshot-20120124-03.png|frame|center]]

===Install from URL===
This option is the easiest, if the archive file is available on a website.
# In the Extension Manager: Install screen, enter the URL for the archive file in the Install URL field.
# Press the Install button.
The system will work for a period of time, up to two minutes or more for a full version update. Then a message indicating a successful installation will display.

===Install from Directory===
This option requires that you unpack the archive file in a directory on your server. This is the best method if you have a slow internet connection or you are experiencing timeouts during the update process.
# Unpack the archive file in a temporary directory on your local machine.
# Upload all the files in this directory (for example, using FTP) to a temporary directory that is visible to the web server. For example, you can create a sub-directory under the tmp directory in your Joomla root. For this example, let's say the directory on the server is <code>/home/myuser/myjoomla/tmp/upgrade250</code>).
# In the Extension Manager: Install screen, enter the full path of the temporary directory (on the server) from step 2 (for example, <code>/home/myuser/myjoomla/tmp/upgrade250</code>).
# Press the Install button.
The system will work for a short time (perhaps a minute or less, depending on your server). Then a message indicating a successful installation will display.

===Upload Package File===
This option requires that you first download the archive file to your local machine.
# Download the file to your local computer.
# In the Extension Manager: Install screen, click the Browse button next to the Package File field and browse to the archive file.
# Press the Install button.
The system will work for a period of time, up to two minutes or more for a full version update. Then a message indicating a successful installation will display.

# Congratulations! At this point, your site is updated.
'''Important:''' Clear your browser cache and check that your site is working correctly. See below Checking Your Site

=Method C - Manual Upgrade=

This method is similar to the old method for updating Joomla versions. Here we want to replace the existing program files with the files from the update archive. The advantage of this method is that it will work on slower shared hosts. The disadvantage is that it requires more work by the system administrator.

{{tip|''This method can also be used to repair a site where the automatic update failed due to a server timeout.''}}

===Copy the New Program Files to Your Site===
There are two ways you can do this.
# Copy the archive file to the root directory of your site and unpack the archive. The update archive will be named something like <code>Joomla_2.5.0-Stable-Update_Package.zip</code>. Note that you need to tell the system to replace any existing files. For example, in GoDaddy.com, use the FTP File Manager to upload the update file and then use "Unarchive" to unpack it. Check the box "Overwrite existing files".
# If you don't have the ability to unpack the archive on the server, create a temporary directory on your local machine and unpack the archive file there. Then FTP these files to the root directory of your site, overwriting the existing files.

===Update the Database===
At this point, you should be able to log into the back end of your site with the new version installed. However, you are not done. Navigate to Extension Manager: Database. You will initially have Database problems when you check the Database, similar to the screen below.
[[Image:Update-screenshot-20120124-08.png|center|Database Screen Before Fix]]
This is expected. Click on the Fix icon to correct the problems. Now the screen should show that the database is up to date.

===Install New Extensions===
Navigate to Extension Manager: Discover and click on the Discover icon in the toolbar. If the updated version has new core extensions, new extensions will be listed, as shown below.
[[Image:Update-screenshot-20120124-09.png|800px|center|Discover Screen Before Install]]
Select all the extensions and click on the Install icon in the toolbar. The system should display a success message similar to the screen below.
[[Image:Update-screenshot-20120124-10.png|center|Discover Screen After Install]]

===Delete removed files===
{{warning|title=Use Caution When Deleting|Use extreme care when deleting files and folders from your Joomla installation, deleting the wrong file or folder may break your site!}}
Look at the list of removed files located in <code>administrator/components/com_admin/script.php</code> file.
Delete each of the files and folders listed the their applicable array:
<source lang="php">
public function deleteUnexistingFiles()
{
$files = array(
'/includes/version.php',
'/installation/sql/mysql/joomla_update_170to171.sql',
'/installation/sql/mysql/joomla_update_172to173.sql',
'/installation/sql/mysql/joomla_update_17ga.sql',
'/libraries/cms/cmsloader.php',
....

$folders = array(
'/libraries/joomlacms',
'/media/editors/tinymce/jscripts/tiny_mce/plugins/media/img',
'/media/plg_highlight',

....
</source>

===Update the #__extensions Table===
At this point, your site is updated. However, there is one more thing to do. The site will think it needs to be updated because a value in the #__extensions table is wrong. To fix this:
* Using phpMyAdmin or a similar tool, edit the row of the #__extensions table where the id column is '700'. (Note that the table prefix will be different in your site. For example, if your table prefix is "jos_", then the table will be called "jos_extensions".
* In the manifest_cache column, you will see the old version in the text (for example, <code>"version":"1.7.3"</code>). Change this to the new version (for example, <code>"version":"2.5.0"</code>). Be careful to not change anything else in this column.
* To check that this was successful, navigate to Extension Manager: Update and click Check for Updates. You should '''not''' see the current Joomla version in the list.

At this point, your site should be updated correctly.

=Checking Site=
'''This is required for method A and B!'''
After an update, it is a good idea to clear your browser cache snd check your site to make sure the update was successful. There are two quick checks you can do from the Extension Manager.
==Extension Manager: Check Database==
{{JVer|2.5}} This feature was added in version 2.5.0. It checks that your database is up to date with your Joomla programs.

Navigate to Extension Manager: Database. If your database is up to date, you should see a screen similar to the one below:
[[Image:Update-screenshot-20120124-04.png|frame|center|Database Screen With No Problems]]

If your database is not up to date, you will see a screen listing the problems found, similar to the one below:
[[Image:Update-screenshot-20120124-05.png|frame|center|Database Screen With 3 Database Problems]]
In this case, press the Fix button in the upper right corner. Joomla will update your database to correct the issues listed and then it will re-display the screen. If the fix was successful, the display will indicate that the database is up to date.

'''N.B.''' If any errors fail to fix then make sure all the database Tables are checked in.

==Extension Manager: Discover==
In some cases, when you update to a new Joomla version, new core extensions are added. If there were problems with the database update, these extensions may not have been correctly installed. To check this, navigate to Extension Manager: Discover. Then click on the Discover icon in the toolbar. The screen should show as follows:
[[Image:Update-screenshot-20120124-06.png|frame|center|Discover Screen With No Extensions To Install]]
If so, you know that any new extensions added during the udpate were correctly installed in the database.

If there are uninstalled extensions, they will show similar to the following screen:
[[Image:Update-screenshot-20120124-07.png|frame|center|Discover Screen With Two Extensions To Install]]
In this case, check the check boxes and click on the Install icon in the toolbar. Joomla will install the extension(s) and then display the screen showing no extensions discovered. At this point, the new extensions have been installed in the database.

=Troubleshooting=
If you have any questions before, during, or after the upgrade then please ask them on the '''[[jforum:710|Migrating and Upgrading to Joomla! 3.x Forum]]'''.

If you have problems or errors during the update process, here are some tips.
* Check the following locations for more information:
:*'''[[J3.1:Known upgrading issues and solutions|Known upgrading issues and solutions]]'''
:*'''[[:Category:Upgrading Issues|Upgrading Issues]]'''
* Sometimes a simple clearing your browser cache as there may have been changes to the css or javascript that will need to be reloaded by your web browser after an upgrade.
* If any database error messages show after the update, be sure to check the Extension Manager: Database tab followed by the Extension Manager: Discover tab. In some cases, if a database error occurs it will prevent all the database updates from running. In this case, you can run them from the Database tab and then use the Discover→Install method to check and install any new extensions.
* If you encounter any errors or problems during or after the update, be sure to check the FAQ for the version you updated to. For example, for version 3.1.0, this will be an category entitled [[:Category:Version_3.1.0_FAQ|Category:Version 3.1.0 FAQ]].

[[Category:Upgrading]]
[[Category:Joomla! 3.0]][[Category:Joomla! 3.1]]
[[Category:Update Working Group]]

Category talk:Upgrading Issues

2014-10-07T12:25:06Z

Sovainfo: /* Link to Known issues and solutions results in blank screen */ new section

User talk:Jgress-

2014-10-07T04:34:17Z

Sovainfo: Created page with "Hi, just changed your name on the update working group.~~~~"

Hi, just changed your name on the update working group.[[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 23:34, 6 October 2014 (CDT)

Update Working Group

2014-10-07T04:29:59Z

Sovainfo: /* Team Members */

The Update Working Group is the [[Production Working Groups|Production Working Group]] that is responsible for finding ways to make updating, upgrading, or migrating Joomla!, a simpler and smoother experience.

Official support for Joomla! 2.5 is scheduled to end at the end of 2014. Users need to be encouraged to start planning and upgrading to Joomla! 3.x. Tips and resources will help to prevent issues during upgrading, and remove anxiety from the upgrade process.

A large number of Joomla! web sites are still on 1.5.x. These users require a lot more help and guidance to successfully migrate their websites to 3.x.

The Update Working Group will collate current resources relating to Joomla! upgrades and migrations, write new content where needed, and liaise with Documentation, Production and Marketing to coordinate efforts.

== Team Members ==

* Coordinator(s): [mailto:jacques.rentzke@community.joomla.org Jacques Rentzke], [[User:partic|Patrick Jackson]]
* PLT Contacts: [mailto:tom.hutchison@community.joomla.org Tom Hutchison] and [mailto:javier.gomez@community.joomla.org Javier Gómez]
* [[User:Wilsonge|George Wilson]], [[User:Jgress-|Jennifer Gress]], Nick Savov

=== How do I volunteer? ===

Please send an email to Jacques or one of the PLT contacts and you will be added to the communication channel for this working group.

==Announcements==

== Roadmap==
The next steps in this team are:

1. Documentation (docs.joomla.org)
* locate, organize and update current content.
* add new content where needed.
* structure for Update (update, upgrade, migration) content
2. Production (changes to the CMS)
* Finding solutions to assist users before and during upgrade/migration, for instance:
** pre-upgrade-check to see if server or extensions are compatible.
** post-upgrade-check to see if update completed without error, and if not, to roll back update. (proposal)
** An official Project-supported migration tool for 1.5 to 3.x. (proposal)
** Finding and fixing any upgrade-related bugs
** Working with Extension developers to ensure smooth upgrades.
3. Marketing (content for joomla.org, PR and Social Media)
* Create dedicated section on joomla.org that collates all the upgrade information, and guides the user through the process or toward resources.
* Create visual help
* Promote this Upgrade recourse via events, conferences, PR, releases, social media
4. Translations
* Translate content into multiple languages (Translation Teams and other volunteers).

== Meetings==
* 17 August 2014: Initial information
* 6 Sept 2014: [http://bit.ly/1n32JBW Update Working Group Meeting]
=== Calendar Items ===
'''Events are shown in time zone: GMT (no daylight saving or UTC + 0)
<div class="calendar-container">
{{#widget:Google Calendar
|id=community.joomla.org_24tcb4f5l3cj9b8i6p8pn59kb8@group.calendar.google.com
|view=agenda
|title=Joomla! Update Working Group Calendar
|showcals=false 
}}</div>

== Documents ==
=== Known Content on Joomla! Documentation ===

This is a list of known articles on JDocs. To add a page, just add the Category: Update Working Group to the page. "Edit the page found, at the bottom add <code><nowiki>[[Category:Update Working Group]]</nowiki></code>.
{{tip|Are you using [[wp:HotCat|HotCat]]? You should be! It's in your [[Special:Preferences#mw-prefsection-gadgets|preferences]].}}
==== Located Content ====
{{#dpl:category=Update Working Group|noresultsheader=None found}}

=== Known Content not on Joomla! Documentation ===
Please list content for updating, upgrading and migrating in this section.



[[Category:Working Groups]]
[[Category:PLT]]

User talk:Sovainfo

2014-10-07T00:09:19Z

Sovainfo:

== Update Working Group ==

Have no intention to join this group. Looks like I want to make some changes that might be related what they are working on. While trying to support someone on the forum discovered that there is no information on migrating to J3 to be found on the administrator portal. Consider that wrong and would like to change that. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 19:07, 6 October 2014 (CDT)

== wiki edits: ==
* Trying to find my own tag to use it in other discussions. Maybe there is a way to include it, i don't know. Found it, it is mentioned below in the edit window! Enter in the edit screen 4x~.

* To propose article for deletion add {<code>{delete|reason}</code>} at the top. reason should say why it needs to be removed. This will place it in the category candidates for deletion. Make sure it is not being referred to by other pages.

== Open questions ==

* How to move without reference.
:When you press move uncheck the box that says "Leave a redirect behind"
:: Tried that, but it left a reference anyway. Did notice that others are moving without it. So it must be possible. Reluctant to move anything now, because of it. Will try again to verify, thanks. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 08:15, 19 September 2013 (CDT)
:: Generally you should always leave a redirect because outside links could be to the page being moved. On rare occasions there could be a page that has no incoming links to it within the wiki and those are usually ones we leave the redirect out. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 13:42, 19 September 2013 (CDT)
* How to find out what pages are using the page.
: While on the page you want to find what links to it, click the gear in the top right hand corner drop-down menu. What links here, click that and it'll give you a list of what links to it and how. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 13:49, 19 September 2013 (CDT)
:: Found it, thanks. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 14:57, 19 September 2013 (CDT)

== Automation of Help Screen pages ==

Hi Sovainfo, I saw you have been working on the Help32 help screens. Mark Dexter did some work on automation of the screens from Selenium Tests. I think anything and everything he could grab he did and then I uploaded them to the Chunk30 namespace. You can find the list of all the Chunks here, [[User:Tom Hutchison/Finding pages with DPL]]. These included screenshots and the actual Field Data(which is what the chunks are). Then he integrated the screenshots into the chunks. All the UX changes really forced us to look at this method. A few hundred screenshots, ugh!

I've done about 25 of them and the good part will be, once integrated they can be updated in a matter of hours. Mostly waiting for the test loops to finish. Anyway, from changing the first 25 or so on the master list, I realized we needed to swap around How to Access with Description. It was a little backwards anyway. What is it, here is how you get to it. It is more for the wiki browsers anyway, not the admin accessed views.

Let me know what you think. The most painful part will be getting all the chunks into the Help screens, matching them to the actual File name or chunk name. We tried to create a descriptive naming pattern. There are just so many of them it will take time. Once they are integrated, everything can be changed quickly. I think it took a total of 4 mins to upload everything. 3 for the files and 1 minute for all the chunk pages. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 19:35, 6 December 2013 (CST)
:: Thank you for this information. Not sure whether I understand the impact completely. Stopped changing ( only 3 more to go). Will have a look before I continue. Sounds like you are telling me I am wasting my time. Here is what I was trying to do:
::A post on the forum about the article category triggered me to focus on the Module Manager help. My objective is to have it consistent for all modules. Noticed missing description of Advanced settings, Menu assignment and Permissions. Created chunks for those. Later on found out that also How to access was not consistently applied. Decided to change that first for all modules (3 to go). Next step would have been to go through all of them again to change advanced, menu assignment and permissions plus moving toolbar down. Not happy with the format as it is now, but don't worry, won't change it without discussion.
::Would love to see this automated, but wonder whether it is and when this could be expected. Looking forward to answer on that. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 20:23, 6 December 2013 (CST)

:::Nothing is a waste. The UX team really killed the modules, everything is moved around and changed. Definitely standardize the How to Access part. While you are there, just flip the location between Description and How To...move it down as a next section or move the description part up. I need to change that in the how to build a help screen page. I think the one thing is the Advanced Tab is going to be the same for all modules, that could be chunked and used on all of them. Actually, I think it is all three, Advanced settings, Menu assignment and Permissions. But again they are all the same so one chunk should cover them all. Did you look at any of the user pages? I'll try and get one of the module ones done as a sample.
:::Everything is there, it just needs integration. Once that happens, no more screenshots. At least from first count, 95% of all screenshots will be automated and a huge chunk of the help screen content too. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 20:34, 6 December 2013 (CST)
:::: Removing the header breaks the layout for all Module Manager help. Already created chunks for Menu Assignment and Permissions, they are always next to eachother. Advanced is the last tab, not always after Permissions, which is why it is separate. Do think the tabs should be in order of appearance. Advanced needs to be updated, somewhere there is a better description than that I initially created. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 21:24, 6 December 2013 (CST)
:::I know it did, sorry, but it is a great job on the use of templating!!! Yeah, someone else gets it.
:::The problem, a stupid problem because of DPL(Dynamic Page List) is there is no way to ignore a Heading Call. What I mean by that, if I tell DPL to pull in all content under 'Description' it will grab everything under 'Description' heading to the next page heading, this includes all template information. You can't even use the <nowiki><noinclude></nowiki> tags. I could go into why, but it would take a few more paragraphs. Anyway, we need the hard stops in there.
:::Next, when Mark laid out the wiki text with the data, he added the screenshot heading. In retrospect, we probably shouldn't have done it that way, but logically it made sense because it was also sectioning off all the tabs if there were more to section off.
:::Unfortunately, I had to down grade the headings from = to == again because of the automated content and how it was laid out.
:::Bright side, between your new how to access template and the automation, all a module needs to build the page is
<pre>
==Description==
A description...
==How to Access==
{{Chunk30:ModuleManager-How-to-acces-module|module=<name of Module>}}
\<name of module>/
{{Chunk30:Help-3x-module-site-articles-newsflash}}

===Common Details===
{{Chunk30:Module Details}}

===Common Tabs===
{{Chunk30:Help-3x-module-site-common-tabs}}

==Toolbar==
etc... the rest below
</pre>
:::As for in order, Common is common to all. I know what you mean by the common details is moved down. Mark, George, myself just figured they are all common to every module and required. Perhaps a better name for Common Details? [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 22:01, 6 December 2013 (CST)
:::Oh, I guess I should explain why the DPL call is important to "Description" too. There are several uses of DPL to grab a link to a Help Screen, with a Description of what the help screen does in tables through out docs. Mainly on the Admin Doc pages, but the related help screen template uses it too. Without the hard stop a description put in a table would include the description and the screenshot and all the information in the chunk for the screenshot. These can get pretty lengthy. Some of the automated chunks contain lots of information. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 22:21, 6 December 2013 (CST)
::::So, if there was a way to get the description from somewhere the whole page could be generated. Maybe placing it in a chunk together with getting the content from the source. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 06:05, 7 December 2013 (CST)
:Yes, the whole of anything under Description including all template and/or chunks up until the pages next real section. DPL used the logic of labeled section inclusion extension, which never had the noinclude tags. If we placed it in a chunk, then you would have to change the description parameter being looked for on all the pages using the labeled section calls. Which is an alternative to what is being done now. In the scheme of things, it prob is best to have the "what it is" first then how to get to it. In admin view calling help screens, it prob is a bit more logical that way too. What is this, click help, first paragraphs tell the story. The how to access only really exist for wiki(docs) readers. A help screen user will already be on the page. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 07:30, 9 December 2013 (CST)

User talk:Sovainfo

2014-10-07T00:07:23Z

Sovainfo: /* Update Working Group */ new section

== wiki edits: ==
* Trying to find my own tag to use it in other discussions. Maybe there is a way to include it, i don't know. Found it, it is mentioned below in the edit window! Enter in the edit screen 4x~.

* To propose article for deletion add {<code>{delete|reason}</code>} at the top. reason should say why it needs to be removed. This will place it in the category candidates for deletion. Make sure it is not being referred to by other pages.

== Open questions ==

* How to move without reference.
:When you press move uncheck the box that says "Leave a redirect behind"
:: Tried that, but it left a reference anyway. Did notice that others are moving without it. So it must be possible. Reluctant to move anything now, because of it. Will try again to verify, thanks. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 08:15, 19 September 2013 (CDT)
:: Generally you should always leave a redirect because outside links could be to the page being moved. On rare occasions there could be a page that has no incoming links to it within the wiki and those are usually ones we leave the redirect out. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 13:42, 19 September 2013 (CDT)
* How to find out what pages are using the page.
: While on the page you want to find what links to it, click the gear in the top right hand corner drop-down menu. What links here, click that and it'll give you a list of what links to it and how. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 13:49, 19 September 2013 (CDT)
:: Found it, thanks. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 14:57, 19 September 2013 (CDT)

== Automation of Help Screen pages ==

Hi Sovainfo, I saw you have been working on the Help32 help screens. Mark Dexter did some work on automation of the screens from Selenium Tests. I think anything and everything he could grab he did and then I uploaded them to the Chunk30 namespace. You can find the list of all the Chunks here, [[User:Tom Hutchison/Finding pages with DPL]]. These included screenshots and the actual Field Data(which is what the chunks are). Then he integrated the screenshots into the chunks. All the UX changes really forced us to look at this method. A few hundred screenshots, ugh!

I've done about 25 of them and the good part will be, once integrated they can be updated in a matter of hours. Mostly waiting for the test loops to finish. Anyway, from changing the first 25 or so on the master list, I realized we needed to swap around How to Access with Description. It was a little backwards anyway. What is it, here is how you get to it. It is more for the wiki browsers anyway, not the admin accessed views.

Let me know what you think. The most painful part will be getting all the chunks into the Help screens, matching them to the actual File name or chunk name. We tried to create a descriptive naming pattern. There are just so many of them it will take time. Once they are integrated, everything can be changed quickly. I think it took a total of 4 mins to upload everything. 3 for the files and 1 minute for all the chunk pages. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 19:35, 6 December 2013 (CST)
:: Thank you for this information. Not sure whether I understand the impact completely. Stopped changing ( only 3 more to go). Will have a look before I continue. Sounds like you are telling me I am wasting my time. Here is what I was trying to do:
::A post on the forum about the article category triggered me to focus on the Module Manager help. My objective is to have it consistent for all modules. Noticed missing description of Advanced settings, Menu assignment and Permissions. Created chunks for those. Later on found out that also How to access was not consistently applied. Decided to change that first for all modules (3 to go). Next step would have been to go through all of them again to change advanced, menu assignment and permissions plus moving toolbar down. Not happy with the format as it is now, but don't worry, won't change it without discussion.
::Would love to see this automated, but wonder whether it is and when this could be expected. Looking forward to answer on that. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 20:23, 6 December 2013 (CST)

:::Nothing is a waste. The UX team really killed the modules, everything is moved around and changed. Definitely standardize the How to Access part. While you are there, just flip the location between Description and How To...move it down as a next section or move the description part up. I need to change that in the how to build a help screen page. I think the one thing is the Advanced Tab is going to be the same for all modules, that could be chunked and used on all of them. Actually, I think it is all three, Advanced settings, Menu assignment and Permissions. But again they are all the same so one chunk should cover them all. Did you look at any of the user pages? I'll try and get one of the module ones done as a sample.
:::Everything is there, it just needs integration. Once that happens, no more screenshots. At least from first count, 95% of all screenshots will be automated and a huge chunk of the help screen content too. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 20:34, 6 December 2013 (CST)
:::: Removing the header breaks the layout for all Module Manager help. Already created chunks for Menu Assignment and Permissions, they are always next to eachother. Advanced is the last tab, not always after Permissions, which is why it is separate. Do think the tabs should be in order of appearance. Advanced needs to be updated, somewhere there is a better description than that I initially created. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 21:24, 6 December 2013 (CST)
:::I know it did, sorry, but it is a great job on the use of templating!!! Yeah, someone else gets it.
:::The problem, a stupid problem because of DPL(Dynamic Page List) is there is no way to ignore a Heading Call. What I mean by that, if I tell DPL to pull in all content under 'Description' it will grab everything under 'Description' heading to the next page heading, this includes all template information. You can't even use the <nowiki><noinclude></nowiki> tags. I could go into why, but it would take a few more paragraphs. Anyway, we need the hard stops in there.
:::Next, when Mark laid out the wiki text with the data, he added the screenshot heading. In retrospect, we probably shouldn't have done it that way, but logically it made sense because it was also sectioning off all the tabs if there were more to section off.
:::Unfortunately, I had to down grade the headings from = to == again because of the automated content and how it was laid out.
:::Bright side, between your new how to access template and the automation, all a module needs to build the page is
<pre>
==Description==
A description...
==How to Access==
{{Chunk30:ModuleManager-How-to-acces-module|module=<name of Module>}}
\<name of module>/
{{Chunk30:Help-3x-module-site-articles-newsflash}}

===Common Details===
{{Chunk30:Module Details}}

===Common Tabs===
{{Chunk30:Help-3x-module-site-common-tabs}}

==Toolbar==
etc... the rest below
</pre>
:::As for in order, Common is common to all. I know what you mean by the common details is moved down. Mark, George, myself just figured they are all common to every module and required. Perhaps a better name for Common Details? [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 22:01, 6 December 2013 (CST)
:::Oh, I guess I should explain why the DPL call is important to "Description" too. There are several uses of DPL to grab a link to a Help Screen, with a Description of what the help screen does in tables through out docs. Mainly on the Admin Doc pages, but the related help screen template uses it too. Without the hard stop a description put in a table would include the description and the screenshot and all the information in the chunk for the screenshot. These can get pretty lengthy. Some of the automated chunks contain lots of information. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 22:21, 6 December 2013 (CST)
::::So, if there was a way to get the description from somewhere the whole page could be generated. Maybe placing it in a chunk together with getting the content from the source. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 06:05, 7 December 2013 (CST)
:Yes, the whole of anything under Description including all template and/or chunks up until the pages next real section. DPL used the logic of labeled section inclusion extension, which never had the noinclude tags. If we placed it in a chunk, then you would have to change the description parameter being looked for on all the pages using the labeled section calls. Which is an alternative to what is being done now. In the scheme of things, it prob is best to have the "what it is" first then how to get to it. In admin view calling help screens, it prob is a bit more logical that way too. What is this, click help, first paragraphs tell the story. The how to access only really exist for wiki(docs) readers. A help screen user will already be on the page. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 07:30, 9 December 2013 (CST)

== Update Working Group ==

Have no intention to join this group. Looks like I want to make some changes that might be related what they are working on. While trying to support someone on the forum discovered that there is no information on migrating to J3 to be found on the administrator portal. Consider that wrong and would like to change that. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 19:07, 6 October 2014 (CDT)

Bug Tracking Process

2014-06-06T22:48:51Z

Sovainfo: /* Reporting Issues */ changed to j3 bug reporting

This article documents the current Joomla! bug tracking process from the time a new bug is reported to the time it is closed.

Joomla! bugs are tracked in the follower tracker:
;*[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103 Joomla! CMS Issue Tracker] - Active.
:This is for issues with supported Joomla Versions. As of November 2013, this is version 2.5 and 3.2.

==Helping out==

You do ''not'' need to be a member of the JBS to help fix bugs in Joomla. Anyone can report bugs, test patches, or submit patches. If you want to help with resolving bugs, go to the [http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103 Tracker]. You can help resolve Open issues as outlined below. You can create and submit patches for Confirmed issues. Or you can help test Pending issues. To report about what you have done, log in to joomlacode and add a comment. You'll be amazed at how much impact you can have and how good it feels to contribute to the Joomla! project.

If you have any questions, or are interested in joining the [[Portal:Bug_Squad|JBS]], please contact [mailto:mark.dexter@community.joomla.org Mark Dexter] or [mailto:nick.savov@community.joomla.org Nick Savov].

===Testing Pre releases===

Before a stable release of Joomla is released the update needs testing. This is a simple process:
# Install the current stable release of Joomla in a subfolder or on localhost (you can use a copy of a production site but '''never test on a live production site''').
# Navigate to the Options of the Joomla! Update component and set the 'Update server' to 'Test'. [[Help32:Components Joomla Update|Components Joomla Update]]
# When a Joomla pre release is ready for testing, log into your test site and install the Update. Then test the site works as expected. Please report any errors on the [http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103 Joomla! CMS Issue Tracker]

==Reporting Issues==

[[Image:ReportingIssues.png|ReportingIssues.png]]

The process is normally started in one of two ways: the bug is added to the respective tracker, or a user reports the bug in the [http://forum.joomla.org/viewforum.php?f=728 Joomla! Bug Forum] for the given maintenance release.

=== Issues reported on the forum ===

JBS members scan the forums to determine when issues need to be put into the tracker. If the issue can be reproduced, is clearly a bug, and there are step-by-step instructions for how to reproduce it, it can be entered into the tracker with a status of Confirmed. If it is not as clear-cut, it can be entered with a status of Open, so that other JBS members will know it needs further investigation.

=== Issues directly reported to the tracker ===

When an issue is added to the tracker, the status will be either
1. Open
2. Confirmed
3. or Pending
depending on the situation. If the issue needs more investigation, then it should be set to Open. If the issue (1) is a bug and (2) can be reproduced and (3) has good test instructions, it should be set to Confirmed. If it meets the three Confirmed criteria and also has a good patch attached, it should be set to Pending. See below for more information about the status codes.

=== Issue Priorities ===

[[Bug and Issue Tracker Priority|Why most issues are priority 3]], or Normal. The artifacts are prioritized according to the following characteristics:

'''Critical (1):'''
The trunk is not working at all. Significant parts of the source are broken preventing key operations. Examples would be login, installation, extension installers, javascript errors that prevent you from moving a save or similar action, etc. Also includes the generation of Fatal PHP errors and major security issues in a prerelease (Security issues for a stable release should NOT be reported in the tracker but instead reported to the security team security@joomla.org).

'''Major (2):'''
Parts of the source are obstructing operation in a serious way or causing a major loss in advertised function. Examples would includes PHP notices and warnings and reported javascript errors. Major issues will also typically prevent the release cycle from moving from Beta to Release Candidate (RC), or Release Candidate to General Availability (GA).

'''Normal: (3)'''
Issues that are hindering advertised behavior but the application is still workable. Examples would include parameters not working as advertised, language files not loading as expected, etc.

'''Minor (4):'''
Minor loss of function and generally annoying behavior. May include less common platform or browser specific problems that while they may be technically major in those environments, they represent a minority. Also include missing translation strings.

'''Trivial (5):'''
Cosmetic problems, misspelled words, graphically misaligned object, less common issues with parameters, etc.

== Resolving Issues ==

The bug squad takes care of the Joomla releases. For example, that means getting the 3.0.1, 3.0.2, 3.0.3, 3.0.4 etc releases ready by fixing problems that come up. The idea is to make the release increasingly stable and take care of issues that come up. At the same time, it is vitally important not to break anything that is working. That's called software regression and it's not something you want at this stage.

In the trackers there are several common statuses, mainly: open, confirmed, pending, ready to commit.

* '''Open''' means it's reported, but it hasn't been determined for sure whether it is a real bug or not. Many Open issues are not actually bugs. If the issue fits into one of the categories below, then the status is changed as indicated and the bug is closed:
** Cannot be reproduced. We have tried the same thing the reported did but the software appears to work correctly. (In many cases, more information is needed to be able to reproduce a bug. See "Information Required" below.) Change status to '''Unable to confirm'''.
** Has already been reported in a different issue number. Change status to '''Duplicate report''' and add the number on the duplicates tab.
** Is a known limitation of the software. Change status to '''Known issue'''.
** Is a feature request, a mistake made by a user, or is the way the software is intended to work. Change status to '''Not a bug'''.
** Is a bug with an extension or some other external program or a server issue that will not be addressed. Change status to '''Not Joomla! core'''.
* '''Information Required''' is used if we need more information ''from the person who reported the issue'' to decide about the issue. For example, there are questions about how to reproduce the problem or other questions about the issue. If we get the information we need, then we can continue processing the issue. If we don't get the information within two weeks, then we can change the status to Unable to confirm (or another of the closed status codes if that is more applicable).
* '''Needs Review''' is used if we need a JBS Coordinator, Development Coordinator, or other experienced developer to review the issue. This is different from Information Required, which means that we need more information from the person who reported the issue.
* '''Started''' means that JBS has checked the issue, but is not quite sure if the issue is an actual bug (i.e. confirmed), and that there is discussion going on about the issue, which doesn't require additional information ''from the person who reported the issue''. It is a state that's between '''Opened''' and '''Confirmed'''.
* '''Confirmed''' means that JBS has confirmed that this issue is a bug in Joomla! that should be fixed. That's when the JBS tries to solve it or consults with the development team about a solution. ''At this point there should be clear step-by-step test instructions that indicate how to reproduce the problem. For version 1.6, use the Test Instructions field for this information.''
* '''Pending''' means that a patch has been submitted that a JBS member or development coordinator or appropriate leadership team member believes fixes the bug. If needed, additional test instructions are entered for the issue. Every Pending issue should have instructions that tell the tester how to reproduce the problem and make sure the patch fixes the problem.
* '''In Progress''' means that an issue is being worked on. This will most likely be a situation where the issue was set to Pending but there were problems with the patch that require additional work. It also may be a case where the issue is complex and will take some time to solve. JBS members can participate in In Progress issues but generally should not start coding before discussing with others working on the issue already.
* '''Ready to commit''' means that (in general) two separate people have successfully tested the same patch file, and it works correctly with the patch. Note that, for some issues that are more complex or higher impact, we may need more than two people to test or may need to test on multiple platforms. For simple issues, such as fixing typos in language strings or comments, one tester is enough.
* '''Fixed in SVN''' means that, after reviewing the code, the JBS commit coordinators have determined that the patch is good and the change has been committed to the Joomla! codebase. At this point, it will be part of the next Joomla! maintenance release.

The flowchart below provides a visual guide to how the process for resolving bugs works.

[[Image:ResolvingIssues.png|ResolvingIssues.png]]

<noinclude> [[Category:Bug Squad]]</noinclude>
[[Category:Bug Tracker]]

J3.x talk:Developing a MVC Component/Adding a view to the site part

2014-05-22T12:47:47Z

Sovainfo: /* Class name HelloWorld */ new section

== tmpl/default.php ==

At the packaging you are told to include tmpl/default.php. But the view doesn't use it, should it? [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 07:43, 22 May 2014 (CDT)

== Class name HelloWorld ==

For class naming the <Name> is used. Where does the World come from. Someone reported it is deduced from <name></name> in the component.xml file. After removing space and special characters. Is that correct? [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 07:47, 22 May 2014 (CDT)

J3.x talk:Developing a MVC Component/Adding a view to the site part

2014-05-22T12:43:25Z

Sovainfo: /* tmpl/default.php */ new section

Absolute Basics of How a Component Functions

2014-05-22T10:50:51Z

Sovainfo: /* Getting the Data */ Name

{{review}}
This document describes the absolute basics of how a component functions in the most basic ways. It is written for beginner developers to read to help them understand how a basic Joomla! component works.

==Entering the Platform==
You enter the Joomla! Platform by making calls to index.php. Joomla! is designed mainly to deliver the results of component files. When you call a page link, like index.php?option=com_<name>, the Joomla! Platform tries to find and load the file components/com_<name>/<name>.php from whichever folder you have installed Joomla! into. So, if your component is 'com_read' you should have a 'com_read' folder and a file named 'read.php' inside of it. I will call this file the 'base file'. It is in this file that you make the decision whether to use an old flat model (returning the HTML code for the requested page) or to use a Model-View-Controller (MVC) pattern.

This MVC model, walks over two legs: a file and a class. The Joomla! Platform will usually look for a given file and, if found, tries to register a specific class within this file. If either one is missing the call will fail.

==Your controller.php File==
You start all the fireworks by including a reference to a controller file in your base file. The controller file can be named anything you want, but by convention it is called 'controller.php'. In your base file (<name>.php), the following code is typical:

<source lang="php">
require_once(JPATH_COMPONENT . '/controller.php');
</source>

Your controller.php file can be created anywhere you want because you are referencing it by path. If you have written the code exactly as shown above, it should be created in the same location where your base file is located because JPATH_COMPONENT holds the path where the executing component base file is.

So create controller.php and make a reference to the controller library inside by importing it with:

<source lang="php">
jimport('joomla.application.component.controller');
</source>

Now that you have controller.php included and the base JControllerLegacy class imported, you have to define a class that extends the JControllerLegacy base class. This is the class leg mentioned earlier. It is here where your action will happen. You can name this class as you like but, by convention, it is named after your component so you write:

<source lang="php">
class <Name>Controller extends JControllerLegacy
{
}
</source>

In this stage you have your first two files, the base file and the controller file. The base file loads the controller and the controller defines a class. So far so good and easy. The next step is to create an object of this class and to put it to work. So add the following lines to your base file:

<source lang="php">
// Get an instance of the controller prefixed by <name>
$controller = JControllerLegacy::getInstance('<Name>');

// Perform the Request task
$controller->execute(JFactory::getApplication()->input->getCmd('task'));

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

From this point on things start happening by themselves. Up to now you were able to name files/classes (except for the base one) and store them where you want because you were including the files by path/name and calling your classes by name within your code. (Well, only one file and only one class actually, but you could do it!) From now on the Joomla! Platform will begin loading your files and calling your classes automatically, so you must be careful where you put your files, what you name them, and what classes you define. A single letter mismatch will make Joomla! fail.

==Getting the Data==
Where does the Joomla! Platform get the data to play? Well, the answer is easy: from the request, be it a GET request or a POST request. But you have NOT written anything else in the request except option=com_<name>. Where does the 'task' in the execute call come from? Do you really have a meaningful 'task' variable?

Yes, and therein lies a 'problem': Whether you pass a request or not, Joomla! will use its defaults to complete a request, making some errors difficult to spot.

The controller->execute() call will make the Joomla! Platform try to do a request that, in this case, will be the default task 'display', because you have not specified otherwise.

<source lang="php">
class <Name>Controller extends JControllerLegacy

{
function display()
{
echo 'displaying';
}
}

</source>

If your request contained a 'task=jump' parameter the controller would have tried to call a method (function) named 'jump' in your controller class:

<source lang="php">

class <Name>Controller extends JControllerLegacy
{
function jump()
{
echo 'jumping';
}
}

</source>

==The View==
Up to now you have delved into the controller part of the model. This is a new point of decision. You can stop here or go a step further and enter the view part.

The different tasks given to the controller are methods in the controller.php file. All the needed variables are available from the Platform, so you will be able to retrieve them easily.

There is nothing that forces you to use the 'task' variable to drive the call because you can pass the value of any variable as the parameter to the execute method call. But in order to stick to the non-written rules, 'task' is usually used and as it is treated specially by the system, it is a good idea to stick with it.

To trigger the views, you have to call the __construct() method of JControllerLegacy. Do this by inserting, in your method, a call to parent::__construct() as in the last line. At a minimum, your controller file should contain the following:

<source lang="php">

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

class <name>Controller extends JControllerLegacy
{
}
</source>

'''What's a view?'''
A view is a subset of data. It's the same concept as views in SQL parlance. You deliver different parts of your data with different views. So you could have a detailed data view and a resumed data view, the later presenting a subset of the whole data presented in the former.

As you can have multiple views, Joomla! uses the 'views' folder in your component's base directory to keep things tidy. This folder is only a placeholder for your views. This means that you need to create a views folder with a hierarchy that looks like this:

<name> base folder
controller.php
<component_name>.php
'views' folder
view1 folder
view2 folder
...

Inside the views folder, other folders hold the files that build each view. The Joomla! Platform includes a file named view.html.php that should exist in your view folder. A bit messy, I know, so I'll try to explain.

When you built your request, you included a variable named 'view' that tells the MVC model what view you want. Or, if you did not include it, you need to include it now because there is no such a thing as a default view. So your URL is something like:

<code><nowiki>http://example.com/index.php?option=com_<name>&view=<myview>[&task=<mytask>]</nowiki></code>

The task part may or may not exist. Remember that if you omit it, you are defaulting to task=display. With this URL Joomla! is importing a file located at <site root dir>/components/<name>/views/<myview>/view.html.php. If this file or the path does not exist, Joomla! will fail. By simply swapping the value of the view, you deliver different views of your data.

Every request for a view requires that you also specify the format in which you are serving the view. There exist several well known formats such as html (the default one if none is specified), rss, etc. or you can use your own. If no format is specified in the request with the 'format=<myformat>' parameter a default value of 'html' is used.

The 'html' format makes the Joomla! Platform wrap the response in whatever template your site is using so that you get a fully built HTML page. This way, with very little effort from you, you get back your page fully loaded with modules or whatever you had configured.

The specific format you are using needs to be included in the middle part of the name of the file in your view folder (The file we talked about a few lines before 'view.html.php'). If you use a different format like 'rss' your file should be named after it like view.rss.php. Get it?

As mentioned before, you can have formats other than html and Joomla! will not wrap the template on them. You could have a 'pdf' format to deliver your data in pdf format or even an 'ajax' format to deliver ajax responses to the front-end easily. Just construct your URL like

<code><nowiki>http://example.com/index.php?option=com_<name>&view=<myview>&format=ajax</nowiki></code>

to make the Joomla! Platform look for and load the file view.ajax.php located at <site root dir>/components/<name>/views/<myview>/ from which you can echo anything you want. It's that easy.

Anyway, to achieve your goal, you will need some code inside the view.<format>.php file. You have the view file, now you need the view class. You have to extend the JView class with your own class following the strict rules mentioned before. In this case, your class name must be built by concatenating the component name, the word 'View', and the view name. So your class name will be a capitalized <name>View<myview>. If your component is named 'travels' and your view is named 'detail' (URL ...?option=com_travels&view=detail) your view class must be:

<source lang="php">

class TravelsViewDetail extends JViewLegacy
{
function display($tpl=null)
{
echo 'blah, blah';
}
}

</source>

Within this class, you only have to feed the data you want to display for your component under this specific case. You can do this directly by delivering the HTML code directly, or through calls to echo inside php tags, or be more subtle and use a layout (more on this later).

Can you have other functions besides display? I don't know. This is something that the gurus must answer. Where does the display function come from? Again, I don't know. Hope that someone else can help here.

Now you can go a bit further. Up to this point, you have a distributed Platform that dissects your request in such a way that allows you to create small and very specific files to react only to specific types of requests. In this way, the files that you must process can be very small and adjusted to the situation you are treating. This will speed up the global response time of the system by not loading a bunch of code that will never be used with these kind of requests.

Having reached this point, you can dissect a bit more and have another layer of detail: the final layout for the data you deliver.

A layout is a way to present the data for the view. The same data can be delivered under different visual aspects so that the same preparation code (inside the display function of your view class) can present the same data in different ways simply using different files. You 'inject' the view data into the layout template and use the template code to visually format it for presenting to the user.

As before, if you do not specify a layout you go with the 'default' layout. To use layouts you need to create a new folder under the related view folder named 'tmpl' and create a file named <mylayout>.php, nothing more nothing less. If you are using the default layout this file will be named 'default.php'.

The desired layout can be specified in the request by means of a 'layout=<mylayout>' variable or can be injected in the call if you manage to get the layout you want to use from other sources.

To use a layout, your view class must call 'parent::display();' and pass the layout template name as a parameter. So your class should be:

<source lang="php">

class <Name>View<Viewname> extends JViewLegacy
{
function display($tpl=null)
{
// Prepare the data
$data1 = ....
$data2 = ....
$moredata[] = array....

// Inject the data
$this->variablename = $data1;
$this->variablename2 = $data2;
$this->variablename3 = $moredata;

// Call the layout template. If no tpl value is set Joomla! will look for a default.php file
$tpl = 'myTemplate';
parent::display($tpl);
}
}
</source>

This way, Joomla! will look for a file named 'myTemplate.php' in the 'tmpl' folder of the given view. Inside this template file you get a '$this' object that has access to the variables you have injected by means of '$this->variablename' that you can use in your constructions to deliver your HTML *FINAL* code.

As you surely will have determined by now, you can have different layouts files in your tmpl folder thus driving easily your output with simple, small, very specific files.

If you have been observant, you will have noticed that you have not 'used' the 'model' part of MVC model. Here you have the last point of decision. You can go without this part or apply fully the model but I think I will keep this tale for another session. For sure I have already abused of my audience.

[[Category:Tutorials]]
[[Category:Explanations]]
[[Category:Component Development]]
[[Category:Beginner Development]]
[[Category:Development Recommended Reading]]

Absolute Basics of How a Component Functions

2014-05-22T10:49:27Z

Sovainfo: /* Your controller.php File */ Name instead of name to suggest starting with a Capital

{{review}}
This document describes the absolute basics of how a component functions in the most basic ways. It is written for beginner developers to read to help them understand how a basic Joomla! component works.

==Entering the Platform==
You enter the Joomla! Platform by making calls to index.php. Joomla! is designed mainly to deliver the results of component files. When you call a page link, like index.php?option=com_<name>, the Joomla! Platform tries to find and load the file components/com_<name>/<name>.php from whichever folder you have installed Joomla! into. So, if your component is 'com_read' you should have a 'com_read' folder and a file named 'read.php' inside of it. I will call this file the 'base file'. It is in this file that you make the decision whether to use an old flat model (returning the HTML code for the requested page) or to use a Model-View-Controller (MVC) pattern.

This MVC model, walks over two legs: a file and a class. The Joomla! Platform will usually look for a given file and, if found, tries to register a specific class within this file. If either one is missing the call will fail.

==Your controller.php File==
You start all the fireworks by including a reference to a controller file in your base file. The controller file can be named anything you want, but by convention it is called 'controller.php'. In your base file (<name>.php), the following code is typical:

<source lang="php">
require_once(JPATH_COMPONENT . '/controller.php');
</source>

Your controller.php file can be created anywhere you want because you are referencing it by path. If you have written the code exactly as shown above, it should be created in the same location where your base file is located because JPATH_COMPONENT holds the path where the executing component base file is.

So create controller.php and make a reference to the controller library inside by importing it with:

<source lang="php">
jimport('joomla.application.component.controller');
</source>

Now that you have controller.php included and the base JControllerLegacy class imported, you have to define a class that extends the JControllerLegacy base class. This is the class leg mentioned earlier. It is here where your action will happen. You can name this class as you like but, by convention, it is named after your component so you write:

<source lang="php">
class <Name>Controller extends JControllerLegacy
{
}
</source>

In this stage you have your first two files, the base file and the controller file. The base file loads the controller and the controller defines a class. So far so good and easy. The next step is to create an object of this class and to put it to work. So add the following lines to your base file:

<source lang="php">
// Get an instance of the controller prefixed by <name>
$controller = JControllerLegacy::getInstance('<Name>');

// Perform the Request task
$controller->execute(JFactory::getApplication()->input->getCmd('task'));

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

From this point on things start happening by themselves. Up to now you were able to name files/classes (except for the base one) and store them where you want because you were including the files by path/name and calling your classes by name within your code. (Well, only one file and only one class actually, but you could do it!) From now on the Joomla! Platform will begin loading your files and calling your classes automatically, so you must be careful where you put your files, what you name them, and what classes you define. A single letter mismatch will make Joomla! fail.

==Getting the Data==
Where does the Joomla! Platform get the data to play? Well, the answer is easy: from the request, be it a GET request or a POST request. But you have NOT written anything else in the request except option=com_<name>. Where does the 'task' in the execute call come from? Do you really have a meaningful 'task' variable?

Yes, and therein lies a 'problem': Whether you pass a request or not, Joomla! will use its defaults to complete a request, making some errors difficult to spot.

The controller->execute() call will make the Joomla! Platform try to do a request that, in this case, will be the default task 'display', because you have not specified otherwise.

<source lang="php">
class <name>Controller extends JControllerLegacy

{
function display()
{
echo 'displaying';
}
}

</source>

If your request contained a 'task=jump' parameter the controller would have tried to call a method (function) named 'jump' in your controller class:

<source lang="php">

class <name>Controller extends JControllerLegacy
{
function jump()
{
echo 'jumping';
}
}

</source>

==The View==
Up to now you have delved into the controller part of the model. This is a new point of decision. You can stop here or go a step further and enter the view part.

The different tasks given to the controller are methods in the controller.php file. All the needed variables are available from the Platform, so you will be able to retrieve them easily.

There is nothing that forces you to use the 'task' variable to drive the call because you can pass the value of any variable as the parameter to the execute method call. But in order to stick to the non-written rules, 'task' is usually used and as it is treated specially by the system, it is a good idea to stick with it.

To trigger the views, you have to call the __construct() method of JControllerLegacy. Do this by inserting, in your method, a call to parent::__construct() as in the last line. At a minimum, your controller file should contain the following:

<source lang="php">

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

class <name>Controller extends JControllerLegacy
{
}
</source>

'''What's a view?'''
A view is a subset of data. It's the same concept as views in SQL parlance. You deliver different parts of your data with different views. So you could have a detailed data view and a resumed data view, the later presenting a subset of the whole data presented in the former.

As you can have multiple views, Joomla! uses the 'views' folder in your component's base directory to keep things tidy. This folder is only a placeholder for your views. This means that you need to create a views folder with a hierarchy that looks like this:

<name> base folder
controller.php
<component_name>.php
'views' folder
view1 folder
view2 folder
...

Inside the views folder, other folders hold the files that build each view. The Joomla! Platform includes a file named view.html.php that should exist in your view folder. A bit messy, I know, so I'll try to explain.

When you built your request, you included a variable named 'view' that tells the MVC model what view you want. Or, if you did not include it, you need to include it now because there is no such a thing as a default view. So your URL is something like:

<code><nowiki>http://example.com/index.php?option=com_<name>&view=<myview>[&task=<mytask>]</nowiki></code>

The task part may or may not exist. Remember that if you omit it, you are defaulting to task=display. With this URL Joomla! is importing a file located at <site root dir>/components/<name>/views/<myview>/view.html.php. If this file or the path does not exist, Joomla! will fail. By simply swapping the value of the view, you deliver different views of your data.

Every request for a view requires that you also specify the format in which you are serving the view. There exist several well known formats such as html (the default one if none is specified), rss, etc. or you can use your own. If no format is specified in the request with the 'format=<myformat>' parameter a default value of 'html' is used.

The 'html' format makes the Joomla! Platform wrap the response in whatever template your site is using so that you get a fully built HTML page. This way, with very little effort from you, you get back your page fully loaded with modules or whatever you had configured.

The specific format you are using needs to be included in the middle part of the name of the file in your view folder (The file we talked about a few lines before 'view.html.php'). If you use a different format like 'rss' your file should be named after it like view.rss.php. Get it?

As mentioned before, you can have formats other than html and Joomla! will not wrap the template on them. You could have a 'pdf' format to deliver your data in pdf format or even an 'ajax' format to deliver ajax responses to the front-end easily. Just construct your URL like

<code><nowiki>http://example.com/index.php?option=com_<name>&view=<myview>&format=ajax</nowiki></code>

to make the Joomla! Platform look for and load the file view.ajax.php located at <site root dir>/components/<name>/views/<myview>/ from which you can echo anything you want. It's that easy.

Anyway, to achieve your goal, you will need some code inside the view.<format>.php file. You have the view file, now you need the view class. You have to extend the JView class with your own class following the strict rules mentioned before. In this case, your class name must be built by concatenating the component name, the word 'View', and the view name. So your class name will be a capitalized <name>View<myview>. If your component is named 'travels' and your view is named 'detail' (URL ...?option=com_travels&view=detail) your view class must be:

<source lang="php">

class TravelsViewDetail extends JViewLegacy
{
function display($tpl=null)
{
echo 'blah, blah';
}
}

</source>

Within this class, you only have to feed the data you want to display for your component under this specific case. You can do this directly by delivering the HTML code directly, or through calls to echo inside php tags, or be more subtle and use a layout (more on this later).

Can you have other functions besides display? I don't know. This is something that the gurus must answer. Where does the display function come from? Again, I don't know. Hope that someone else can help here.

Now you can go a bit further. Up to this point, you have a distributed Platform that dissects your request in such a way that allows you to create small and very specific files to react only to specific types of requests. In this way, the files that you must process can be very small and adjusted to the situation you are treating. This will speed up the global response time of the system by not loading a bunch of code that will never be used with these kind of requests.

Having reached this point, you can dissect a bit more and have another layer of detail: the final layout for the data you deliver.

A layout is a way to present the data for the view. The same data can be delivered under different visual aspects so that the same preparation code (inside the display function of your view class) can present the same data in different ways simply using different files. You 'inject' the view data into the layout template and use the template code to visually format it for presenting to the user.

As before, if you do not specify a layout you go with the 'default' layout. To use layouts you need to create a new folder under the related view folder named 'tmpl' and create a file named <mylayout>.php, nothing more nothing less. If you are using the default layout this file will be named 'default.php'.

The desired layout can be specified in the request by means of a 'layout=<mylayout>' variable or can be injected in the call if you manage to get the layout you want to use from other sources.

To use a layout, your view class must call 'parent::display();' and pass the layout template name as a parameter. So your class should be:

<source lang="php">

class <Name>View<Viewname> extends JViewLegacy
{
function display($tpl=null)
{
// Prepare the data
$data1 = ....
$data2 = ....
$moredata[] = array....

// Inject the data
$this->variablename = $data1;
$this->variablename2 = $data2;
$this->variablename3 = $moredata;

// Call the layout template. If no tpl value is set Joomla! will look for a default.php file
$tpl = 'myTemplate';
parent::display($tpl);
}
}
</source>

This way, Joomla! will look for a file named 'myTemplate.php' in the 'tmpl' folder of the given view. Inside this template file you get a '$this' object that has access to the variables you have injected by means of '$this->variablename' that you can use in your constructions to deliver your HTML *FINAL* code.

As you surely will have determined by now, you can have different layouts files in your tmpl folder thus driving easily your output with simple, small, very specific files.

If you have been observant, you will have noticed that you have not 'used' the 'model' part of MVC model. Here you have the last point of decision. You can go without this part or apply fully the model but I think I will keep this tale for another session. For sure I have already abused of my audience.

[[Category:Tutorials]]
[[Category:Explanations]]
[[Category:Component Development]]
[[Category:Beginner Development]]
[[Category:Development Recommended Reading]]

Absolute Basics of How a Component Functions

2014-05-22T10:25:08Z

Sovainfo: /* Your controller.php File */ Name instead of name to suggest starting with a Capital

{{review}}
This document describes the absolute basics of how a component functions in the most basic ways. It is written for beginner developers to read to help them understand how a basic Joomla! component works.

==Entering the Platform==
You enter the Joomla! Platform by making calls to index.php. Joomla! is designed mainly to deliver the results of component files. When you call a page link, like index.php?option=com_<name>, the Joomla! Platform tries to find and load the file components/com_<name>/<name>.php from whichever folder you have installed Joomla! into. So, if your component is 'com_read' you should have a 'com_read' folder and a file named 'read.php' inside of it. I will call this file the 'base file'. It is in this file that you make the decision whether to use an old flat model (returning the HTML code for the requested page) or to use a Model-View-Controller (MVC) pattern.

This MVC model, walks over two legs: a file and a class. The Joomla! Platform will usually look for a given file and, if found, tries to register a specific class within this file. If either one is missing the call will fail.

==Your controller.php File==
You start all the fireworks by including a reference to a controller file in your base file. The controller file can be named anything you want, but by convention it is called 'controller.php'. In your base file (<name>.php), the following code is typical:

<source lang="php">
require_once(JPATH_COMPONENT . '/controller.php');
</source>

Your controller.php file can be created anywhere you want because you are referencing it by path. If you have written the code exactly as shown above, it should be created in the same location where your base file is located because JPATH_COMPONENT holds the path where the executing component base file is.

So create controller.php and make a reference to the controller library inside by importing it with:

<source lang="php">
jimport('joomla.application.component.controller');
</source>

Now that you have controller.php included and the base JControllerLegacy class imported, you have to define a class that extends the JControllerLegacy base class. This is the class leg mentioned earlier. It is here where your action will happen. You can name this class as you like but, by convention, it is named after your component so you write:

<source lang="php">
class <Name>Controller extends JControllerLegacy
{
}
</source>

In this stage you have your first two files, the base file and the controller file. The base file loads the controller and the controller defines a class. So far so good and easy. The next step is to create an object of this class and to put it to work. So add the following lines to your base file:

<source lang="php">
// Get an instance of the controller prefixed by <name>
$controller = JControllerLegacy::getInstance('<name>');

// Perform the Request task
$controller->execute(JFactory::getApplication()->input->getCmd('task'));

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

From this point on things start happening by themselves. Up to now you were able to name files/classes (except for the base one) and store them where you want because you were including the files by path/name and calling your classes by name within your code. (Well, only one file and only one class actually, but you could do it!) From now on the Joomla! Platform will begin loading your files and calling your classes automatically, so you must be careful where you put your files, what you name them, and what classes you define. A single letter mismatch will make Joomla! fail.

==Getting the Data==
Where does the Joomla! Platform get the data to play? Well, the answer is easy: from the request, be it a GET request or a POST request. But you have NOT written anything else in the request except option=com_<name>. Where does the 'task' in the execute call come from? Do you really have a meaningful 'task' variable?

Yes, and therein lies a 'problem': Whether you pass a request or not, Joomla! will use its defaults to complete a request, making some errors difficult to spot.

The controller->execute() call will make the Joomla! Platform try to do a request that, in this case, will be the default task 'display', because you have not specified otherwise.

<source lang="php">
class <name>Controller extends JControllerLegacy

{
function display()
{
echo 'displaying';
}
}

</source>

If your request contained a 'task=jump' parameter the controller would have tried to call a method (function) named 'jump' in your controller class:

<source lang="php">

class <name>Controller extends JControllerLegacy
{
function jump()
{
echo 'jumping';
}
}

</source>

==The View==
Up to now you have delved into the controller part of the model. This is a new point of decision. You can stop here or go a step further and enter the view part.

The different tasks given to the controller are methods in the controller.php file. All the needed variables are available from the Platform, so you will be able to retrieve them easily.

There is nothing that forces you to use the 'task' variable to drive the call because you can pass the value of any variable as the parameter to the execute method call. But in order to stick to the non-written rules, 'task' is usually used and as it is treated specially by the system, it is a good idea to stick with it.

To trigger the views, you have to call the __construct() method of JControllerLegacy. Do this by inserting, in your method, a call to parent::__construct() as in the last line. At a minimum, your controller file should contain the following:

<source lang="php">

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

class <name>Controller extends JControllerLegacy
{
}
</source>

'''What's a view?'''
A view is a subset of data. It's the same concept as views in SQL parlance. You deliver different parts of your data with different views. So you could have a detailed data view and a resumed data view, the later presenting a subset of the whole data presented in the former.

As you can have multiple views, Joomla! uses the 'views' folder in your component's base directory to keep things tidy. This folder is only a placeholder for your views. This means that you need to create a views folder with a hierarchy that looks like this:

<name> base folder
controller.php
<component_name>.php
'views' folder
view1 folder
view2 folder
...

Inside the views folder, other folders hold the files that build each view. The Joomla! Platform includes a file named view.html.php that should exist in your view folder. A bit messy, I know, so I'll try to explain.

When you built your request, you included a variable named 'view' that tells the MVC model what view you want. Or, if you did not include it, you need to include it now because there is no such a thing as a default view. So your URL is something like:

<code><nowiki>http://example.com/index.php?option=com_<name>&view=<myview>[&task=<mytask>]</nowiki></code>

The task part may or may not exist. Remember that if you omit it, you are defaulting to task=display. With this URL Joomla! is importing a file located at <site root dir>/components/<name>/views/<myview>/view.html.php. If this file or the path does not exist, Joomla! will fail. By simply swapping the value of the view, you deliver different views of your data.

Every request for a view requires that you also specify the format in which you are serving the view. There exist several well known formats such as html (the default one if none is specified), rss, etc. or you can use your own. If no format is specified in the request with the 'format=<myformat>' parameter a default value of 'html' is used.

The 'html' format makes the Joomla! Platform wrap the response in whatever template your site is using so that you get a fully built HTML page. This way, with very little effort from you, you get back your page fully loaded with modules or whatever you had configured.

The specific format you are using needs to be included in the middle part of the name of the file in your view folder (The file we talked about a few lines before 'view.html.php'). If you use a different format like 'rss' your file should be named after it like view.rss.php. Get it?

As mentioned before, you can have formats other than html and Joomla! will not wrap the template on them. You could have a 'pdf' format to deliver your data in pdf format or even an 'ajax' format to deliver ajax responses to the front-end easily. Just construct your URL like

<code><nowiki>http://example.com/index.php?option=com_<name>&view=<myview>&format=ajax</nowiki></code>

to make the Joomla! Platform look for and load the file view.ajax.php located at <site root dir>/components/<name>/views/<myview>/ from which you can echo anything you want. It's that easy.

Anyway, to achieve your goal, you will need some code inside the view.<format>.php file. You have the view file, now you need the view class. You have to extend the JView class with your own class following the strict rules mentioned before. In this case, your class name must be built by concatenating the component name, the word 'View', and the view name. So your class name will be a capitalized <name>View<myview>. If your component is named 'travels' and your view is named 'detail' (URL ...?option=com_travels&view=detail) your view class must be:

<source lang="php">

class TravelsViewDetail extends JViewLegacy
{
function display($tpl=null)
{
echo 'blah, blah';
}
}

</source>

Within this class, you only have to feed the data you want to display for your component under this specific case. You can do this directly by delivering the HTML code directly, or through calls to echo inside php tags, or be more subtle and use a layout (more on this later).

Can you have other functions besides display? I don't know. This is something that the gurus must answer. Where does the display function come from? Again, I don't know. Hope that someone else can help here.

Now you can go a bit further. Up to this point, you have a distributed Platform that dissects your request in such a way that allows you to create small and very specific files to react only to specific types of requests. In this way, the files that you must process can be very small and adjusted to the situation you are treating. This will speed up the global response time of the system by not loading a bunch of code that will never be used with these kind of requests.

Having reached this point, you can dissect a bit more and have another layer of detail: the final layout for the data you deliver.

A layout is a way to present the data for the view. The same data can be delivered under different visual aspects so that the same preparation code (inside the display function of your view class) can present the same data in different ways simply using different files. You 'inject' the view data into the layout template and use the template code to visually format it for presenting to the user.

As before, if you do not specify a layout you go with the 'default' layout. To use layouts you need to create a new folder under the related view folder named 'tmpl' and create a file named <mylayout>.php, nothing more nothing less. If you are using the default layout this file will be named 'default.php'.

The desired layout can be specified in the request by means of a 'layout=<mylayout>' variable or can be injected in the call if you manage to get the layout you want to use from other sources.

To use a layout, your view class must call 'parent::display();' and pass the layout template name as a parameter. So your class should be:

<source lang="php">

class <Name>View<Viewname> extends JViewLegacy
{
function display($tpl=null)
{
// Prepare the data
$data1 = ....
$data2 = ....
$moredata[] = array....

// Inject the data
$this->variablename = $data1;
$this->variablename2 = $data2;
$this->variablename3 = $moredata;

// Call the layout template. If no tpl value is set Joomla! will look for a default.php file
$tpl = 'myTemplate';
parent::display($tpl);
}
}
</source>

This way, Joomla! will look for a file named 'myTemplate.php' in the 'tmpl' folder of the given view. Inside this template file you get a '$this' object that has access to the variables you have injected by means of '$this->variablename' that you can use in your constructions to deliver your HTML *FINAL* code.

As you surely will have determined by now, you can have different layouts files in your tmpl folder thus driving easily your output with simple, small, very specific files.

If you have been observant, you will have noticed that you have not 'used' the 'model' part of MVC model. Here you have the last point of decision. You can go without this part or apply fully the model but I think I will keep this tale for another session. For sure I have already abused of my audience.

[[Category:Tutorials]]
[[Category:Explanations]]
[[Category:Component Development]]
[[Category:Beginner Development]]
[[Category:Development Recommended Reading]]

How to access session variables set by an external script

2014-05-17T23:56:32Z

Sovainfo: Remove DS and &

Situation: when you call a session variable in Joomla from an external script, it appears to be empty.

Solution:
Replace session_start(); in your external script with
<source lang=php>
define( '_JEXEC', 1 );
define( 'JPATH_BASE', realpath(dirname(__FILE__).'/../..' ));

require_once ( JPATH_BASE '/includes/defines.php' );
require_once ( JPATH_BASE '/includes/framework.php' );
$mainframe = JFactory::getApplication('site');
$mainframe->initialise();
</source>
Be sure to change JPATH_BASE to suit your directory structure.

Replace the $_SESSION[ 'name' ] = "value"; in your external script with
<source lang=php>
$session = JFactory::getSession();
$session->set('name', "value");
</source>

Now you can retrieve this session variable using:
<source lang=php>
$session = JFactory::getSession();
echo $session->get('name');
</source>

J3.x talk:Creating a simple module/Developing a Basic Module

2014-05-08T00:34:45Z

Sovainfo: /* $params */

== $params ==

This document explains calling a helper class passing $params for future use. The problem is, it doesn't mention where that $params is coming from. And what other data is available? [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 08:41, 6 May 2014 (CDT)

:So there probably should be a sentence saying $params is generated by us automatically. As this is a "simple" module tutorial - I really want to avoid going into the fact this is automatically generated by the JModuleHelper. I'd rather just say the thing with the params is created magically for you to manipulate. --[[User:Wilsonge|Wilsonge]] ([[User talk:Wilsonge|talk]]) 18:43, 6 May 2014 (CDT)

::Why would you want to avoid mentioning JModuleHelper::renderModule. The first thing that comes to mind is how should I know $params is available? Where to look for the other variables availabe. Or state them, would be nice to know $app is available!. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 03:49, 7 May 2014 (CDT)

:Because it's a "simple" module tutorial. When I first developed modules (which scarily wasn't that long ago) I didn't care where all this stuff came from - it was just amazing that it existed. Again for simple module development I'm not sure that matters - with the $app thing for example I'd rather get people redefining it. Firstly as I said I don't think people for a basic "here's how to create a module" tutorial we need to involve JModuleHelper and also because I really think you should define $app yourself for your things so it's as standalone as possible! The only thing arguably you should need is the $module object (as that contains params + module title instance) or if you only need the params then just $params.

::Never mind. Hope that the J4 redesign will get rid of modules anyway![[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 19:34, 7 May 2014 (CDT)

== Don't like "for page rendering" ==

Don't like "for page rendering", would say: while rendering the page. It completely puts me off, thinking the module is the procedure to render a page, which is handled by JDocumentHtml. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 04:05, 7 May 2014 (CDT)

:In retrospect I don't like it either :P changed

J3.x talk:Creating a simple module/Developing a Basic Module

2014-05-07T09:05:45Z

Sovainfo: /* Don't like "for page rendering" */ new section

J3.x talk:Creating a simple module/Developing a Basic Module

2014-05-07T08:49:38Z

Sovainfo: /* $params */

J3.x talk:Creating a simple module/Developing a Basic Module

2014-05-06T13:41:03Z

Sovainfo: /* $params */ new section

Help310 talk:Components Joomla Update

2014-05-04T19:38:01Z

Sovainfo: /* Custom URL section */

== Request for arbitrage: update to current removed ==

Request for arbitrage: Changed the description to note that an update goes for the current version. Think the destinction is relevant because it doesn't allow you to pick one, it decides for you and picks the current one. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 05:21, 1 May 2014 (CDT)

:Agreed, the update is only the most current one. You do not have a choice if on 3.2.0 to update to 3.2.1, you'll get 3.2.4 or 3.3.0. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 07:53, 1 May 2014 (CDT)

::Sorry but you are incorrect because the update version can be defined in an xml file situated on a URL defined in the 'Custom' Server field. Topazgb 13:21, 1 May 2014 (CDT)

:::One has nothing to do with the other, but I can see what you are thinking. The problem is the word 'current' is used as it should be. The goal is to keep the users on the 'current' release, not a previous release. "A/an" is indefinite and "the" is specific. "A" current update would imply a non specific choice or even multiple choices for the end user. "The" current update would be the specific update offered, the "current" update. Since users aren't presented with a choice of updates, e.g. 3.0 installed, update to 3.1.0, 3.0.1, 3.2.4, 3.3.0, now pick one, "the current update" is appropriate as it is one specific update. Even if a user changes to a custom URL, different server(LTS or STS), only one update is presented, which may not be the current one, but to the component it is the current one(higher version compared to what is installed). Hope that helps. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 09:33, 2 May 2014 (CDT)

::::The Second sentence (of the help page)describes that there are choices of the different update servers ... but the first sentence only specifies the result of the default setting. ergo the first sentence (of the help page is inaccurate.

::::''"This screen allows Joomla! to be updated quickly by downloading the current update package"'' is inaccurate/incomplete because it only allows for the downloading of the current update package with the default/pre-set settings. Therefore the definite article 'the' is being incorrectly used because it is possible to download any update version.

::::In short ... that screen can be used to download any update version not just ''"the current update package"''
::::--Topazgb 11:36, 2 May 2014 (CDT)

::Now it states it is the default. While I was at it, noted the change of the server is for advanced users.
::So why would you want users to use a specific, unsupported update? Devs on the testing server are advanced users, regular users should always be using the latest version.
::The help screen's job is to give help to the common, everyday users. You are splitting hairs on the 99%(targeted audience) vs the 1%(highly advanced users/developers). [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 10:03, 3 May 2014 (CDT)

::I do not ''"want users to use a specific, unsupported update"'' ... And I am not ''splitting hairs''. There may be experienced Web masters who are not familiar with Joomla and (for a number of reasons) wish to use a specific update. Giving accurate information will help them without hindering the average user. But inaccurate information (by way of inferring only the current update can be downloaded from that screen) can cause a misconception for experienced Web masters that wish to experiment with Joomla. --Topazgb 11:14, 3 May 2014 (CDT)

I would like to see (a link to) an example xml file that updates to J3.2.3. Also the description of 4.1 should be changed so webmasters know when to choose the last two options. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 20:29, 3 May 2014 (CDT)

@Sovainfo
As requested http://www.weblinksonline.co.uk/testupdate/update3.2.3.xml
Method to replicate
# Install any version of Joomla prior to 3.2.3
#In Joomla! Update Component
#Set Update server to 'Custom URL'
#In the 'Custom URL' field put http://www.weblinksonline.co.uk/testupdate/update3.2.3.xml
#'Save and Close'
You should then see the download for http://joomlacode.org/gf/download/frsrelease/19240/158108/Joomla_3.2.x_to_3.2.3-Stable-Patch_Package.zip --Topazgb 08:54, 4 May 2014 (CDT)

:4.1 is automated, would need to change the form field tool tip in core to change it. After investigating more, updater works on a greater than. 4.0.14 must be greater than the installed, 4.0.11. You can point to a XML file, but must point to a greater than version to get update is available. '''You can not regress''', 4.0.14 to 4.0.11. The example is a '''testing''' URL example, not real world practical for everyday users. URL practical uses, '''development''', '''testing''' or a '''developer supplying a custom update to their client(s)'''. The last example, a custom component or core addition or changes, which obviously is more work for a developer. This statement:
<blockquote>There may be experienced Web masters who are not familiar with Joomla and (for a number of reasons) wish to use a specific update.</blockquote>
:is not an accurate use of updater. The specific update must always be greater than the version installed. I can't think a a reason off-hand why an experience webmaster would "want to target" an update, especially if they are not familiar with Joomla. An truly experienced webmaster knows better than to tweak settings they don't understand fully.
:In any regards, I think we are past the point of putting this to rest. Thanks for all the input, the use of "the current update" will stay in place. Thanks [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 09:06, 4 May 2014 (CDT)

== Proposed changes to 4.1 ==

Understand that this section is automated. Wonder why 4.1 doesn't mention the two fields separately. The Custom URL description doesn't make sense to me. It is in the list of options but describes the field where you enter the url itself. The option should be described as Pick this when you want to specify your own update server. Provide the url in Custom URL data entry field.
Description for Custom URL data entry field should be something like Provide your own url here, only applicable when update server is set to Custom URL.

Suggest to change "Currently configured (no change)" to "No update server".[[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 09:53, 4 May 2014 (CDT)

Agreed ... the 'Custom URL' setting has the description of the 'Custom URL' field ... have edited to specify the difference.

'Currently configured (no change)' is the name of an option in the 'Update server' drop down' list and therefore is correct in the documentation. --Topazgb 10:16, 4 May 2014 (CDT)

:I will keep an eye for the changes coming so we can address all of these tweaks and changes at the same time. The use of LTS and STS do not fit in with the new development strategy. The problem is... LTS/STS are deeply entangled with our terminology and used everywhere. I far as I know, we have not discussed any changes to the update component, e.g. LTS to Current Major and STS to Most Current Major. One would indicate, stay on the major you are on. The other, check to see if there is a higher major version. Technically, 2.5 and 3.x are now both current supported versions. 2.5 just has a EOL set with no feature releases. Docs will have to make a lot of changes too. We use LTS and STS everywhere in templates to output version numbers. That will have to change too. My first order of business will be to get rid of Help31 or Help33 and all the aliases to a set permanent Help3x. Same for J3.2 or now J3.3 namespace to J3.x. Actually, I can go ahead and do both. Help3x is a bit more complicated. I would like to see the core's Help link formation change at core level. FYI, 3.4 is supposed to mark our first release under new strategy so this is why I am holding off. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 10:23, 4 May 2014 (CDT)

== Custom URL section ==

@Topazgb: Thanks for providing the information on the XML. Actually meant this information to be provided in the help document. Not the step by step instructions, the higher level of information. No need to tell an experienced webmaster to press buttons. The xml contents with the example information and instructions what to change for their situation. And how to find that information. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 09:53, 4 May 2014 (CDT)

@Sovainfo
When setting out PoC it is customary to list the exact steps ... that is why I gave 'step by step' when answering your request. However as for documentation for creating an xml for a custom update server ... http://docs.joomla.org/Deploying_an_Update_Server gives the basics. It covers updating third party extensions as well as updating Joomla to a specific version.

So, do you suggest to only link to http://docs.joomla.org/Deploying_an_Update_Server in the help?[[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 14:38, 4 May 2014 (CDT)

Help310 talk:Components Joomla Update

2014-05-04T14:59:17Z

Sovainfo: /* Custom URL section */

== Request for arbitrage: update to current removed ==

Request for arbitrage: Changed the description to note that an update goes for the current version. Think the destinction is relevant because it doesn't allow you to pick one, it decides for you and picks the current one. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 05:21, 1 May 2014 (CDT)

:Agreed, the update is only the most current one. You do not have a choice if on 3.2.0 to update to 3.2.1, you'll get 3.2.4 or 3.3.0. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 07:53, 1 May 2014 (CDT)

::Sorry but you are incorrect because the update version can be defined in an xml file situated on a URL defined in the 'Custom' Server field. Topazgb 13:21, 1 May 2014 (CDT)

:::One has nothing to do with the other, but I can see what you are thinking. The problem is the word 'current' is used as it should be. The goal is to keep the users on the 'current' release, not a previous release. "A/an" is indefinite and "the" is specific. "A" current update would imply a non specific choice or even multiple choices for the end user. "The" current update would be the specific update offered, the "current" update. Since users aren't presented with a choice of updates, e.g. 3.0 installed, update to 3.1.0, 3.0.1, 3.2.4, 3.3.0, now pick one, "the current update" is appropriate as it is one specific update. Even if a user changes to a custom URL, different server(LTS or STS), only one update is presented, which may not be the current one, but to the component it is the current one(higher version compared to what is installed). Hope that helps. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 09:33, 2 May 2014 (CDT)

::::The Second sentence (of the help page)describes that there are choices of the different update servers ... but the first sentence only specifies the result of the default setting. ergo the first sentence (of the help page is inaccurate.

::::''"This screen allows Joomla! to be updated quickly by downloading the current update package"'' is inaccurate/incomplete because it only allows for the downloading of the current update package with the default/pre-set settings. Therefore the definite article 'the' is being incorrectly used because it is possible to download any update version.

::::In short ... that screen can be used to download any update version not just ''"the current update package"''
::::--Topazgb 11:36, 2 May 2014 (CDT)

::Now it states it is the default. While I was at it, noted the change of the server is for advanced users.
::So why would you want users to use a specific, unsupported update? Devs on the testing server are advanced users, regular users should always be using the latest version.
::The help screen's job is to give help to the common, everyday users. You are splitting hairs on the 99%(targeted audience) vs the 1%(highly advanced users/developers). [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 10:03, 3 May 2014 (CDT)

::I do not ''"want users to use a specific, unsupported update"'' ... And I am not ''splitting hairs''. There may be experienced Web masters who are not familiar with Joomla and (for a number of reasons) wish to use a specific update. Giving accurate information will help them without hindering the average user. But inaccurate information (by way of inferring only the current update can be downloaded from that screen) can cause a misconception for experienced Web masters that wish to experiment with Joomla. --Topazgb 11:14, 3 May 2014 (CDT)

I would like to see (a link to) an example xml file that updates to J3.2.3. Also the description of 4.1 should be changed so webmasters know when to choose the last two options. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 20:29, 3 May 2014 (CDT)

@Sovainfo
As requested http://www.weblinksonline.co.uk/testupdate/update3.2.3.xml
Method to replicate
# Install any version of Joomla prior to 3.2.3
#In Joomla! Update Component
#Set Update server to 'Custom URL'
#In the 'Custom URL' field put http://www.weblinksonline.co.uk/testupdate/update3.2.3.xml
#'Save and Close'
You should then see the download for http://joomlacode.org/gf/download/frsrelease/19240/158108/Joomla_3.2.x_to_3.2.3-Stable-Patch_Package.zip --Topazgb 08:54, 4 May 2014 (CDT)

:4.1 is automated, would need to change the form field tool tip in core to change it. After investigating more, updater works on a greater than. 4.0.14 must be greater than the installed, 4.0.11. You can point to a XML file, but must point to a greater than version to get update is available. '''You can not regress''', 4.0.14 to 4.0.11. The example is a '''testing''' URL example, not real world practical for everyday users. URL practical uses, '''development''', '''testing''' or a '''developer supplying a custom update to their client(s)'''. The last example, a custom component or core addition or changes, which obviously is more work for a developer. This statement:
<blockquote>There may be experienced Web masters who are not familiar with Joomla and (for a number of reasons) wish to use a specific update.</blockquote>
:is not an accurate use of updater. The specific update must always be greater than the version installed. I can't think a a reason off-hand why an experience webmaster would "want to target" an update, especially if they are not familiar with Joomla. An truly experienced webmaster knows better than to tweak settings they don't understand fully.
:In any regards, I think we are past the point of putting this to rest. Thanks for all the input, the use of "the current update" will stay in place. Thanks [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 09:06, 4 May 2014 (CDT)

== Proposed changes to 4.1 ==

Understand that this section is automated. Wonder why 4.1 doesn't mention the two fields separately. The Custom URL description doesn't make sense to me. It is in the list of options but describes the field where you enter the url itself. The option should be described as Pick this when you want to specify your own update server. Provide the url in Custom URL data entry field.
Description for Custom URL data entry field should be something like Provide your own url here, only applicable when update server is set to Custom URL.

Suggest to change "Currently configured (no change)" to "No update server".[[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 09:53, 4 May 2014 (CDT)

== Custom URL section ==

@Topazgb: Thanks for providing the information on the XML. Actually meant this information to be provided in the help document. Not the step by step instructions, the higher level of information. No need to tell an experienced webmaster to press buttons. The xml contents with the example information and instructions what to change for their situation. And how to find that information. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 09:53, 4 May 2014 (CDT)

Help310 talk:Components Joomla Update

2014-05-04T14:53:39Z

Sovainfo: /* Proposed changes to 4.1 */

== Request for arbitrage: update to current removed ==

Request for arbitrage: Changed the description to note that an update goes for the current version. Think the destinction is relevant because it doesn't allow you to pick one, it decides for you and picks the current one. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 05:21, 1 May 2014 (CDT)

:Agreed, the update is only the most current one. You do not have a choice if on 3.2.0 to update to 3.2.1, you'll get 3.2.4 or 3.3.0. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 07:53, 1 May 2014 (CDT)

::Sorry but you are incorrect because the update version can be defined in an xml file situated on a URL defined in the 'Custom' Server field. Topazgb 13:21, 1 May 2014 (CDT)

:::One has nothing to do with the other, but I can see what you are thinking. The problem is the word 'current' is used as it should be. The goal is to keep the users on the 'current' release, not a previous release. "A/an" is indefinite and "the" is specific. "A" current update would imply a non specific choice or even multiple choices for the end user. "The" current update would be the specific update offered, the "current" update. Since users aren't presented with a choice of updates, e.g. 3.0 installed, update to 3.1.0, 3.0.1, 3.2.4, 3.3.0, now pick one, "the current update" is appropriate as it is one specific update. Even if a user changes to a custom URL, different server(LTS or STS), only one update is presented, which may not be the current one, but to the component it is the current one(higher version compared to what is installed). Hope that helps. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 09:33, 2 May 2014 (CDT)

::::The Second sentence (of the help page)describes that there are choices of the different update servers ... but the first sentence only specifies the result of the default setting. ergo the first sentence (of the help page is inaccurate.

::::''"This screen allows Joomla! to be updated quickly by downloading the current update package"'' is inaccurate/incomplete because it only allows for the downloading of the current update package with the default/pre-set settings. Therefore the definite article 'the' is being incorrectly used because it is possible to download any update version.

::::In short ... that screen can be used to download any update version not just ''"the current update package"''
::::--Topazgb 11:36, 2 May 2014 (CDT)

::Now it states it is the default. While I was at it, noted the change of the server is for advanced users.
::So why would you want users to use a specific, unsupported update? Devs on the testing server are advanced users, regular users should always be using the latest version.
::The help screen's job is to give help to the common, everyday users. You are splitting hairs on the 99%(targeted audience) vs the 1%(highly advanced users/developers). [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 10:03, 3 May 2014 (CDT)

::I do not ''"want users to use a specific, unsupported update"'' ... And I am not ''splitting hairs''. There may be experienced Web masters who are not familiar with Joomla and (for a number of reasons) wish to use a specific update. Giving accurate information will help them without hindering the average user. But inaccurate information (by way of inferring only the current update can be downloaded from that screen) can cause a misconception for experienced Web masters that wish to experiment with Joomla. --Topazgb 11:14, 3 May 2014 (CDT)

I would like to see (a link to) an example xml file that updates to J3.2.3. Also the description of 4.1 should be changed so webmasters know when to choose the last two options. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 20:29, 3 May 2014 (CDT)

@Sovainfo
As requested http://www.weblinksonline.co.uk/testupdate/update3.2.3.xml
Method to replicate
# Install any version of Joomla prior to 3.2.3
#In Joomla! Update Component
#Set Update server to 'Custom URL'
#In the 'Custom URL' field put http://www.weblinksonline.co.uk/testupdate/update3.2.3.xml
#'Save and Close'
You should then see the download for http://joomlacode.org/gf/download/frsrelease/19240/158108/Joomla_3.2.x_to_3.2.3-Stable-Patch_Package.zip --Topazgb 08:54, 4 May 2014 (CDT)

:4.1 is automated, would need to change the form field tool tip in core to change it. After investigating more, updater works on a greater than. 4.0.14 must be greater than the installed, 4.0.11. You can point to a XML file, but must point to a greater than version to get update is available. '''You can not regress''', 4.0.14 to 4.0.11. The example is a '''testing''' URL example, not real world practical for everyday users. URL practical uses, '''development''', '''testing''' or a '''developer supplying a custom update to their client(s)'''. The last example, a custom component or core addition or changes, which obviously is more work for a developer. This statement:
<blockquote>There may be experienced Web masters who are not familiar with Joomla and (for a number of reasons) wish to use a specific update.</blockquote>
:is not an accurate use of updater. The specific update must always be greater than the version installed. I can't think a a reason off-hand why an experience webmaster would "want to target" an update, especially if they are not familiar with Joomla. An truly experienced webmaster knows better than to tweak settings they don't understand fully.
:In any regards, I think we are past the point of putting this to rest. Thanks for all the input, the use of "the current update" will stay in place. Thanks [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 09:06, 4 May 2014 (CDT)

== Proposed changes to 4.1 ==

Understand that this section is automated. Wonder why 4.1 doesn't mention the two fields separately. The Custom URL description doesn't make sense to me. It is in the list of options but describes the field where you enter the url itself. The option should be described as Pick this when you want to specify your own update server. Provide the url in Custom URL data entry field.
Description for Custom URL data entry field should be something like Provide your own url here, only applicable when update server is set to Custom URL.

Suggest to change "Currently configured (no change)" to "No update server".[[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 09:53, 4 May 2014 (CDT)

== Custom URL section ==

Thanks for providing the information on the XML. Actually meant this information to be provided in the help document. Not the step by step instructions, the higher level of information. No need to tell an experienced webmaster to press buttons. The xml contents with the example information and instructions what to change for their situation. And how to find that information. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 09:53, 4 May 2014 (CDT)

Help310 talk:Components Joomla Update

2014-05-04T14:53:23Z

Sovainfo: /* Custom URL section */ new section

== Request for arbitrage: update to current removed ==

Request for arbitrage: Changed the description to note that an update goes for the current version. Think the destinction is relevant because it doesn't allow you to pick one, it decides for you and picks the current one. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 05:21, 1 May 2014 (CDT)

:Agreed, the update is only the most current one. You do not have a choice if on 3.2.0 to update to 3.2.1, you'll get 3.2.4 or 3.3.0. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 07:53, 1 May 2014 (CDT)

::Sorry but you are incorrect because the update version can be defined in an xml file situated on a URL defined in the 'Custom' Server field. Topazgb 13:21, 1 May 2014 (CDT)

:::One has nothing to do with the other, but I can see what you are thinking. The problem is the word 'current' is used as it should be. The goal is to keep the users on the 'current' release, not a previous release. "A/an" is indefinite and "the" is specific. "A" current update would imply a non specific choice or even multiple choices for the end user. "The" current update would be the specific update offered, the "current" update. Since users aren't presented with a choice of updates, e.g. 3.0 installed, update to 3.1.0, 3.0.1, 3.2.4, 3.3.0, now pick one, "the current update" is appropriate as it is one specific update. Even if a user changes to a custom URL, different server(LTS or STS), only one update is presented, which may not be the current one, but to the component it is the current one(higher version compared to what is installed). Hope that helps. [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 09:33, 2 May 2014 (CDT)

::::The Second sentence (of the help page)describes that there are choices of the different update servers ... but the first sentence only specifies the result of the default setting. ergo the first sentence (of the help page is inaccurate.

::::''"This screen allows Joomla! to be updated quickly by downloading the current update package"'' is inaccurate/incomplete because it only allows for the downloading of the current update package with the default/pre-set settings. Therefore the definite article 'the' is being incorrectly used because it is possible to download any update version.

::::In short ... that screen can be used to download any update version not just ''"the current update package"''
::::--Topazgb 11:36, 2 May 2014 (CDT)

::Now it states it is the default. While I was at it, noted the change of the server is for advanced users.
::So why would you want users to use a specific, unsupported update? Devs on the testing server are advanced users, regular users should always be using the latest version.
::The help screen's job is to give help to the common, everyday users. You are splitting hairs on the 99%(targeted audience) vs the 1%(highly advanced users/developers). [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 10:03, 3 May 2014 (CDT)

::I do not ''"want users to use a specific, unsupported update"'' ... And I am not ''splitting hairs''. There may be experienced Web masters who are not familiar with Joomla and (for a number of reasons) wish to use a specific update. Giving accurate information will help them without hindering the average user. But inaccurate information (by way of inferring only the current update can be downloaded from that screen) can cause a misconception for experienced Web masters that wish to experiment with Joomla. --Topazgb 11:14, 3 May 2014 (CDT)

I would like to see (a link to) an example xml file that updates to J3.2.3. Also the description of 4.1 should be changed so webmasters know when to choose the last two options. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 20:29, 3 May 2014 (CDT)

@Sovainfo
As requested http://www.weblinksonline.co.uk/testupdate/update3.2.3.xml
Method to replicate
# Install any version of Joomla prior to 3.2.3
#In Joomla! Update Component
#Set Update server to 'Custom URL'
#In the 'Custom URL' field put http://www.weblinksonline.co.uk/testupdate/update3.2.3.xml
#'Save and Close'
You should then see the download for http://joomlacode.org/gf/download/frsrelease/19240/158108/Joomla_3.2.x_to_3.2.3-Stable-Patch_Package.zip --Topazgb 08:54, 4 May 2014 (CDT)

:4.1 is automated, would need to change the form field tool tip in core to change it. After investigating more, updater works on a greater than. 4.0.14 must be greater than the installed, 4.0.11. You can point to a XML file, but must point to a greater than version to get update is available. '''You can not regress''', 4.0.14 to 4.0.11. The example is a '''testing''' URL example, not real world practical for everyday users. URL practical uses, '''development''', '''testing''' or a '''developer supplying a custom update to their client(s)'''. The last example, a custom component or core addition or changes, which obviously is more work for a developer. This statement:
<blockquote>There may be experienced Web masters who are not familiar with Joomla and (for a number of reasons) wish to use a specific update.</blockquote>
:is not an accurate use of updater. The specific update must always be greater than the version installed. I can't think a a reason off-hand why an experience webmaster would "want to target" an update, especially if they are not familiar with Joomla. An truly experienced webmaster knows better than to tweak settings they don't understand fully.
:In any regards, I think we are past the point of putting this to rest. Thanks for all the input, the use of "the current update" will stay in place. Thanks [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 09:06, 4 May 2014 (CDT)

== Proposed changes to 4.1 ==

Understand that this section is automated. Wonder why 4.1 doesn't mention the two fields separately. The Custom URL description doesn't make sense to me. It is in the list of options but describes the field where you enter the url itself. The option should be described as Pick this when you want to specify your own update server. Provide the url in Custom URL data entry field.
Description for Custom URL data entry field should be something like Provide your own url here, only applicable when update server is set to Custom URL.

Suggest to change "Currently configured (no change)" to "No update server".

== Custom URL section ==

Thanks for providing the information on the XML. Actually meant this information to be provided in the help document. Not the step by step instructions, the higher level of information. No need to tell an experienced webmaster to press buttons. The xml contents with the example information and instructions what to change for their situation. And how to find that information. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 09:53, 4 May 2014 (CDT)

Help310 talk:Components Joomla Update

2014-05-04T14:44:43Z

Sovainfo: /* Proposed changes to 4.1 */ new section

Help310 talk:Components Joomla Update

2014-05-04T01:29:14Z

Sovainfo: /* Request for arbitrage: update to current removed */

J3.x talk:Database schema version (3.2.3-2014-02-20) does not match CMS version (3.2.3)

2014-05-04T00:48:11Z

Sovainfo: /* Wrong version tag */

== Wrong version tag ==

This topic has a wrong version tag. It says J3.3 while it should be J3.2. Please correct. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 05:40, 1 May 2014 (CDT)
: Yesterday we released 3.3, so the namespace was changed to reflect J3.3. There is no way to set the top tag, it is the namespace of the page. That said, there are a couple of options I have been kicking around. We definitely use docs a lot for FAQs. We also have a new version strategy in place which could lead to the namespace just being a simple J3.x.

:Options:
:# Just namespace and move all FAQs to a namespace called FAQ. Benefits, they are more prominently marked as a FAQ. Down the road we could Semantic MediaWiki this namespace and add Forms for reporting. Fill out the form, save and let SMW take care of everything. Automatic categorisation, lists by version, easier to search for FAQs. I have already half implemented this on FAQ category pages. Give a page title and click create, uses a boilerplate editor window fill of text.
:# The easy way out. Wait a few months and when the full development strategy is in place and we are done stripping out LTS and STS and the like, namespace J3.3 or J3.4, etc can eventually be made a static J3.x. Our docs strategy is to only support docs for the current versions supported. FAQs are a different story as they answer questions moving along the development and use of Joomla path to the current version.
: Thoughts? [[User:Tom Hutchison|Tom Hutchison]] ([[User talk:Tom Hutchison|talk]]) 08:09, 1 May 2014 (CDT)

:: Thank you for the answer, appreciated. Too bad it can't be changed, it is fixed in J3.3. I like both the options you suggest, not sure that I understand why we can't use J3.x right now. The information I want to get across is that it applies to j3.2.3 and is solved in j3.3. Now it looks like the problem still exists. [[User:Sovainfo|Sovainfo]] ([[User talk:Sovainfo|talk]]) 19:48, 3 May 2014 (CDT)