Joomla! Documentation - User contributions [en]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:20:14Z

Dieter: /* Database tables */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map.
User groups can be mapped to rules via the jos_usergroup_rule_map table.

===Actions===
Actions are things your users will perform such as logging in to backend.

===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* action, assetgroup and user groups are all mapped to this rule.
* When three of them map to the same rule then JUser::getAuthorisedLevels() will also return the new asset group id.

===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets.
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)

==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default: Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is a JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:15:57Z

Dieter: /* Core Access Levels */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map.
User groups can be mapped to rules via the jos_usergroup_rule_map table.

===Actions===
Actions are things your users will perform such as logging in to backend.

===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* action, assetgroup and user groups are all mapped to this rule.
* When three of them map to the same rule then JUser::getAuthorisedLevels() will also return the new asset group id.

===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets.
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)

==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default: Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:14:33Z

Dieter: /* Rules */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map.
User groups can be mapped to rules via the jos_usergroup_rule_map table.

===Actions===
Actions are things your users will perform such as logging in to backend.

===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* action, assetgroup and user groups are all mapped to this rule.
* When three of them map to the same rule then JUser::getAuthorisedLevels() will also return the new asset group id.

===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets.
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)

==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:13:58Z

Dieter: /* Asset Groups */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map.
User groups can be mapped to rules via the jos_usergroup_rule_map table.

===Actions===
Actions are things your users will perform such as logging in to backend.

===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* action, assetgroup and user groups are all mapped to this rule.
* When three of them map to the same rule then JUser::getAuthorisedLevels() will also return the new asset group id.

===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)
==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:10:44Z

Dieter: /* Actions */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map.
User groups can be mapped to rules via the jos_usergroup_rule_map table.

===Actions===
Actions are things your users will perform such as logging in to backend.

===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* Both action, assetgroup and user groups are mapped to this rule.
*When three of them maps to the same rule JUser::getAuthorisedLevels() will also return the new asset group id.
===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)
==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:10:25Z

Dieter: /* Actions */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map.
User groups can be mapped to rules via the jos_usergroup_rule_map table.

===Actions===
Actions are things your users will perform such as logging in to backend

===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* Both action, assetgroup and user groups are mapped to this rule.
*When three of them maps to the same rule JUser::getAuthorisedLevels() will also return the new asset group id.
===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)
==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:09:50Z

Dieter: /* User Groups */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map.
User groups can be mapped to rules via the jos_usergroup_rule_map table.

===Actions===
Actions are things your users will perform such that logging in to backend
===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* Both action, assetgroup and user groups are mapped to this rule.
*When three of them maps to the same rule JUser::getAuthorisedLevels() will also return the new asset group id.
===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)
==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:08:48Z

Dieter: /* User Groups */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map.
User groups can be mapped to rules via jos_usergroup_rule_map table.

===Actions===
Actions are things your users will perform such that logging in to backend
===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* Both action, assetgroup and user groups are mapped to this rule.
*When three of them maps to the same rule JUser::getAuthorisedLevels() will also return the new asset group id.
===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)
==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:08:17Z

Dieter: /* User Groups */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are hold in the table jos_user_usergroup_map.
User groups can be mapped to rules via jos_usergroup_rule_map table.

===Actions===
Actions are things your users will perform such that logging in to backend
===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* Both action, assetgroup and user groups are mapped to this rule.
*When three of them maps to the same rule JUser::getAuthorisedLevels() will also return the new asset group id.
===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)
==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:07:39Z

Dieter: /* Users */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
In phpGACL, users were called AROs (Access Request Object).

===User Groups===
These are user groups that are hold in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are hold in the table jos_user_usergroup_map.
User groups can be mapped to rules via jos_usergroup_rule_map table.
===Actions===
Actions are things your users will perform such that logging in to backend
===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* Both action, assetgroup and user groups are mapped to this rule.
*When three of them maps to the same rule JUser::getAuthorisedLevels() will also return the new asset group id.
===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)
==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

Archived:Access Control System In Joomla 1.6

2010-05-22T22:06:27Z

Dieter: /* Sections */

{{RightTOC}}
==Overview==
===Sections===
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

===Users===
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system.
Users can be mapped to rules via jos_user_rule_map table.
in phpGACL, users were called AROs (Access Request Object)

===User Groups===
These are user groups that are hold in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are hold in the table jos_user_usergroup_map.
User groups can be mapped to rules via jos_usergroup_rule_map table.
===Actions===
Actions are things your users will perform such that logging in to backend
===Assets===
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
===Asset Groups===
These are used for creating different view permissions for a combination of usergroups. (???)
How this is achieved:
* First a view action is created with access type 3. (eg. core.view)
* Then an asset group is created with some user groups in it.
* A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
* Both action, assetgroup and user groups are mapped to this rule.
*When three of them maps to the same rule JUser::getAuthorisedLevels() will also return the new asset group id.
===Rules===
Rules are combinations of actions and usergroups (or users) and optionally assets
There are three types of rules:
* Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
* Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
* Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)
==Library==
TODO
==Examples==
===Core Access Levels===
There are three access levels in core by default Public, Registered, Special. These are access levels. For them we use the action ''core.view''. Let's use '''Special''' for our example:
First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is ''core.view.3''. As you remember naming convention is action_name.asset_group_id and here our id is 3.

==Database tables==

It seems that this diagram has been deprecated in favor of much simpler structure.

* jos_assets: id, parent_id, lft, rgt, level, name, title, rules
* jos_usergroups: id, parent_id, lft, rgt, title
* jos_user_usergroup_map: user_id, group_id
* jos_viewlevels: id, title, ordering, rules

* jos_categories and jos_content contain foreign key asset_id
* Rules field is JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

[[Image:Dia_acl_base.png]]

[[Category:Joomla! 1.6]]

J2.5:What's new in Joomla 2.5

2010-05-22T21:40:37Z

Dieter: /* JCacheStorage */

Lots of things.

...and:
* '''New Access Control System''' - Allows site administrators control over who can view and manage content.
* '''Unlimited Depth Organizational Model''' - Gives site administrators and content creators user-defined category levels that allow for the creation of a category tree with as many or as few levels for organizing articles and other content as needed.
* '''One-Click Extension Updates''' - Allows users to keep sites secure and controlled by simplifying the process of updating extensions.
* '''Semantic XHTML Layouts''' - Provides a better baseline for content presentation.

...and:

==Administrators==
===Introduction===
*Consistent UI
*Consistent Features
*Richer sample data
*IE 7+, Firefox 3.x, Safari 4.x
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)

===Administrator===
*Menu Changes
*Submenu consistency

====Toolbar Features====
*Save
*Save & Close
*Save & New
*Save as Copy
*Expired session will return to the page you were on then you got logged out (can be hit and miss)
*Most search filters allow you to search for a record id via [ id:123 ]
*"Parameters" are now referred to as "Options"
*Template Styles
*Integrated Trash Management
*Consistent archive support for most content
*Extension Installer Improvements

===Module Enhancements===
*Publish up and down
*Add option to display on all pages "except" selected
*Expanded Category System
*404 Page Redirection
*Better Menu Management
*Alternative layouts for content, modules and menus (taken from the home template)

===New Templates===
*Atomic
*Beez2
*(Administrator) Bluestork (replaces Khephri)
*(Administrator) Hathor
*Legacy layer in Milkyway
*Backend supports layout overrides
*New Modules
*New Plugins
*Content Languages
*User Login Permissions
*Activate selected users from the user list now (and filter)
*Administrator registration approval
*Polls component removed
*New codemirror editor

===SEO Improvements===
*Meta decription and keywords for categories
*Articles can change the page title and page header separately

===Global Configuration===
*Add site name to titles
*Default Access Level
*Set Metadata Language (buggy)
*Unicode Aliases
*Cookie domain and path
*User Setting moved to User Manager -> Options
*Media Settings moved to Media Manager -> Options
*Debug Modules - allows you to enabled to disable the tp=1 feature
*Server Timezone now a location, not an integer offset
*New Global Permissions tab

===User Manager===
*Can activate a user from the list now
*User can be assigned to multiple groups
*Manage user groups
*Manager content access levels

===Media Manager===
*Flash uploader fixed

===Menu Manager===
====Menus List====
*Rebuild button to press when you brick the menu
*Clicking the menu name brings up the menu items list rather than going into Edit Menu. To edit the menu, click on the check box next to the name and click on the Edit icon in the toolbar.

====Items List====
*Menus support the language filter
*Default now called Home
*Home is now clickable in the menu item list
*A separate home can be set for different languages

=====New batch operations=====
*Set access level
*Copy or move to another part of this or another menu

====Edit Item====
*Improved "Type" selector with human readable view and layout names
*Note field added
*New window target
*New Language assignment
*New Template style
*Ability to add & edit Module assignments from this page

=====New options for the menu links and pages themselves=====
*Link title attribute
*Link CSS style
*Menu image is changed to a modal selector
*CSS class for page heading
*Page meta description
*Page meta keywords
*Robots options

===Articles Manager===
*Frontpage is now referred to a Featured
*Article manager uses submenu to quickly skip between articles , categories and featured
*Sections and categories are now merged.

====Articles List====
*''"Missing move and copy; filter by author"''
*New column to show language
*Filtering by language available

====Article Edit====
*Created by user now selected by modal popup
*New ability to set the page title from the article
*Define create, delete, edit and publishing permissions

===Categories===
====Category List====
*Nested view
*Filtering on language

====Edit Category====
*New note field
*Section replaced with ability to assign a parent category
*Ability to assign content language

=====New Options (not previously available in 1.5)=====
*Assign alternate layout
*Define create, delete, edit and publishing permissions
*Meta description
*Meta keywords
*Alternative page title
*Meta author
*Meta robots

===Banners===
====Banners list====
*** Missing copy toolbar button
*New archive toolbar button
*New columns to show meta keywords, purchase type and language
*New filtering by client and language

====Edit Banner====
*New type toggle for Image or Custom (dynamically changes the available form fields)
*New alt text field for image
*New language field

=====New Options=====
*Ability to set the created date
*Ability to set start and finish publishing times
*Ability to set the purchase type
*Ability to track impressions
*Ability to track clicks
*Use own prefix ?
*Tags renamed to meta
*Contacts
*Messaging
*Newsfeeds
*Search
*Weblinks
*Redirect

===Extensions Manager===
====Discover====
*Module mgr
*Plugin Mgr
*Template Mgr
*Language mgr

===Misc===
*Auto create linked contact when creating new user ??

==Access Controls==
*Introduction
*User Groups
*Access Levels
*Permission Layers
*How Permissions are Inherited
*How to debrick your site

==Developers==
===Introduction===
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)
*IE7+, Firefox 3+, Safari 4+
*Focus on code consistency
*Focus on code reduction

Usage of PHP Native Functions where possible, for example:
*[[JXMLElement]] extends the native [http://php.net/manual/en/book.simplexml.php SimpleXML] class
*[[JDate]] extends the [http://www.php.net/manual/en/class.datetime.php DateTime] class
*Native INI parser to load languages

===Removed features===
*ADODB compatibility methods in database classes
*DOMIT (unsupported XML library)
*Legacy mode (includes global $mainframe, etc)
*JTemplate (based on patTemplate)
*patTemplate (templating engine)
*PDF support
*PEAR libraries (due to license incompatibilities)
*phpgacl
*PHP 4.0 and 5.0 compatibility files
*XStandard Editor

===Deprecated Features===
*JController::_acoSection
*JController::_acoSectionValue
*JController::authorize()
*JController::setAccessControl()
*JDatabase::stderr()
*JDate::offest
*JDate::setOffset()
*JDate::toFormat() - use JDate::format() instead
*JException::toString()
*JFactory::getXMLParser()
*JHtmlGird::access()
*JHtmlImage::administrator - use JHtml::image instead
*JHtmlImage::site - use JHtml::image instead
*JHtmlList::accesslevel()
*JHtmlList::specificordering() - use JHtml::_('list.ordering')
*JHtmlList::category()
*JHtmlSelect::optgroup() - see JHtmlSelect::groupedList()
*JLanguage::_parseLanguageFiles - renamed to parseLanguageFiles
*JLanguage::_parseXMLLanguageFile - renamed to parseXMLLanguageFile
*JLanguage::_parseXMLLanguageFiles - renamed to parseXMLLanguageFiles
*JObject::toString - replaced with magic method
*JRegistry::getNameSpaces()
*JRegistry::getValue()
*JRegistry::makeNameSpace()
*JRegistry::setValue()
*JPane - See JHtmlSliders
*JParameter - replaced by JForm
*JSimpleXML, JSimpleXMLElement - Use JXMLElement instead, based on the native SimpleXMLElement
*JTable::canDelete() - models or controllers should be doing the access checks
*JTable::toXML()
*JToolbarHelper customX(), addNewX(), editListX(), editHtmlX(), editCssX(), deleteListX()
*JUser::authorize() - Use JUser::authorise()
*JUtility::dump()
*JUtility::array_unshift_ref() - Not needed in PHP 5
*JUtility::getHash() - Use JApplication::getHash()
*JUtility::getToken() - Use JFactory::getSession()->getFormToken()
*JUtility::isWinOS() - Use JApplication::isWinOS()
*JUtility::return_bytes() - See InstallerModelWarnings::return_bytes()
*JUtility::sendMail() - Use JFactory::getMailer()->sendMail()
*JUtility::sendAdminMail() - Use JFactory::getMailer()->sendMail()
*JXMLElement::data() - Provided for backward compatibility
*JXMLElement::getAttribute() - Provided for backward compatibility

===Database===
*JTable now automatically looks up the fields from the database schema
*New JDatabaseQuery - A chained CRUD query builder
*New JDatabase::getNextRow
*New JDatabase::getNextObject
*JDatabase::loadAssocList - Now takes a second argument to just return the value of a column
*JDatabase::setQuery - Added chaining support

====Important Schema Changes====
*New jos_extensions table to list all extensions
*Components table information moved and split between jos_extensions and jos_menu (special menu called _adminmenu)

The old phpgacl (jos_core_acl*) and jos_groups tables have been reworked into:
*jos_assets
*jos_user_usergroup_map
*jos_usergroups
*jos_viewlevels
*Archived state changed from a value of -1 to +2

===Improved MVC===
====Models====
*JModelList
*JModelForm
*JModelAdmin
*Format handling (eg JSON)
*Sub-controller handling

====Controllers====
*JControllerForm
*JControllerAdmin
*JController::setMessage takes second arg to set the message type
*JController can set the default view
*Added chaining support to several JController methods

====Views====
*Semantic core output
*Milkyway legacy layouts
*The old component parameters are not automatically added to the menu anymore. You need to explicitly put them in the layout XML files.
*The menu manager will now detect additional layouts for a given view in the default template.

===Form API===
====Event manipulation====
*onContentPrepareForm
*onContentPrepareFormData

===Translation and Language Support===
*Support for unicode slugs, eg, SEF URL's with Greek characters
*3-letter languages now supported, xxx-XX
*All existing language keys have been refactored

====INI files must validate====
*Upper case key with no spaces, alphanumeric characters and underscores
*Quoted values
*Double quotes within literal strings must use _QQ_ in the form KEY="<a href="_QQ_"index.php"_QQ_">Click</a>"

====Javascript translation layer====
*See the flash uploader script for an example
Local extension language files

====Language file API====
*Pluralisation support
*Transliteration support for ASCII or Unicode slugs
*Ignore Search Words
*Minimum search word length
*Custom language overrides
*System language file to support administrator menu and installation (.sys.ini)

====Language switcher====
*Language Filter plugin enables language switching
*Sets the automatic filtering via JFactory::getApplication()->setLanguageFilter(true)
*A frontend component with language support would test JFactory::getApplication()->getLanguageFilter(), which returns the selected language code from the Languages Module
*The language field can be a language code for a single language, or "*" to be displayed for all languages
*Community extension for language maintenance com_localise

===Extension management===
====New installation types====
=====Libraries=====
*Must include an XML manifest where type="library"
*Can only be installed into a sub-folder of /libraries/
*Can extend parts of an existing library, eg /libraries/joomla/database/database/oracle.php

=====Packages multi-installer=====
*Must include an XML manifest where type="package"
*A package is a zip of zip's

New install script can be provided with 5 methods:
=====preflight=====
*Runs before anything is run and while the extracted files are in the uploaded temp folder

======Could allow for:======
*secondary extraction of custom zip's
*version checks to be performed
*halting the installer on an error

=====install / update=====
*Runs after the database scripts are executed
*If the extension is new, the install method is run
*If the extension exists then update method is run if method="upgrade", otherwise assumes that the extension is not meant to be upgradable

=====postflight=====
*Runs after the extension is registered in the database
*Is not run for the uninstall process (nothing left to do obviously)

====Discover====
*Does not do any file copying, only works with what it finds
*Performs preflight, install and postflight
*Developer of installer has two language files??

====Update site====
*Can publish an XML manifest on your site that can include individual extensions and extension sets.

====XML Manifest Changes====
*<install> is deprecated - use <extension>
*New <update> tag. Takes a <schemas> tag which can define <schemapath>
*<params> and <param> tags are deprecated, use <fields>, <fieldsets> and <field> instead

====File changes====
*Installation manifest must be the same name as the extension, eg com_foobar/foobar.xml This helps with discovery (otherwise the function has to go through all the files in the extension folder
*Plugins are now in folders like modules and components
*See SVN/tests/_data/installer_packages/ for complete examples of all extensions and manifests.
*The method="upgrade" will compare individual files in the original and incoming manifests and will remove files as appropriate. However, it will not remove differences in the <folder> tags.
*Future support for rollback

===Events===
====New Events====
*onBeforeRender
*onContentBeforeDelete
*onContentAfterDelete
*onContentChangeState
*onContentPrepareForm
*onContentPrepareFormData
*onExtensionBeforeInstall
*onExtensionBeforeUpdate
*onExtensionBeforeUninstall
*onExtensionAfterInstall
*onExtensionAfterUpdate
*onExtensionAfterUninstall

====Renamed Events====
*onContentAfterSave
*onContentAfterTitle
*onContentAfterDisplay
*onContentBeforeDisplay
*onContentBeforeSave
*onContentSearch
*onContentSearchAreas
*onUserAuthenticate
*onUserAfterDelete
*onUserAfterSave
*onUserBeforeDelete
*onUserBeforeSave
*onUserLogin
*onUserLogout
*All content events (except for search and search areas) now pass a 'context' as the first argument to alert the plugin as to what type of content is being passed. The plugin event may or may not heed this context.

===Categories===
*Component can provide custom options for its own categories via optional category.xml
*Supported via JTableNested

===Access Controls===
*A thing that can be controlled by permissions is registered in the assets table
*JTable handles this transparently via asset_id field
*For view permissions, support is as simple as adding
:::$user = JFactory::getUser();
:::$groups = implode(',', $user->authorisedLevels());
:::$query->where('a.access IN (' . $groups . ')');

For action permissions, same format as in 1.5:
$user->authorise($actionName, $assetName)
*OpenID library moved to plugin folder
*Geshi library moved to plugin folder
*JRegistry notes defaults to JSON (new format), dynamically converting existing data in INI format
*New JStream
*New JApplicationHelper::getComponentName
*Core icons moved to /media/
*Backward incompatible change to JEditor::display
*Added chaining support to JMail
*JFilterInput can no longer be called statically
*JHtml::image now supports relative paths
*All system images are overridable in the default template
*New JHtmlString
*Added wincache session handler for IIS
*New JFilterOutput::stripImages
*JPath::check takes second arg for separator (to pass to JPath::clean)
*Expanded configuration support through config.xml (multiple tabs)

====Core actions====
*core.login.site
*core.login.admin
*core.admin
*core.manage
*core.create
*core.edit
*core.edit.state
*core.delete
*Miscellaneous changes

===Debug Plugin===
*More tools for assisting with translation

===Mootools 1.2/1.3===
*Need to use document.id instead of $

==Cache changes ==
===API changes relevant to 3rd party developers===
====Component view cache====

Component view cache now takes an array of url parameters and their types to create Cacheid. This is a replacement for a previous unsafe way which took the whole URL for this and so opened the doors for DOS attacks via random url parameters added to request URL's.

Com_contact example:

<pre>
$safeurlparams = array(
'id'=>'INT',
'catid'=>'INT', 'limit'=>'INT',
'limitstart'=>'INT',
'filter_order'=>'CMD',
'filter_order_Dir'=>'CMD'
);

parent::display($cachable,$safeurlparams);
</pre>

Old cacheid created from URL was retained for backwards compatibility and takes effect if there are no $safeurlparams.

====Module cache====
This has been completly reconceptualized. Module cache now has 5 different modes of operation, 3 of them are to be set from module XML file, while 2 are meant to be used from within the module itself. Default is backwards compatible oldstatic mode that requires no changes to a module.

Modes to be set in XML:
*'''static''' - one cache file for all pages with the same module parameters
*'''oldstatic''' - 1.5. definition of module caching, one cache file for all pages with the same module id and user aid. Default for backwards compatibility
*'''itemid''' - changes on itemid change

In addition to cache field that was required in 1.5 there is now another hidden field called cachemode that sets any of the above modes.

<pre>
<field name="cachemode" type="hidden" label="" default="static">
<option value="static"></option>
</pre>

Modes to be called from inside the module:
*'''safeuri''' - id is created from $cacheparams->modeparams array, the same as in component view cache
*'''id''' - module sets own cache id's

To use this modes one must rename cache field in xml to owncache field and call JModuleHelper::ModuleCache from within the module's main php file. This is actually a shortcut to cache callback to avoid code duplication in every module.

An example that uses safeuri mode and replaces uncached
$list = modRelatedItemsHelper::getList($params) :

<pre>
$cacheparams = new stdClass;
$cacheparams->cachemode = 'safeuri';
$cacheparams->class = 'modRelatedItemsHelper';
$cacheparams->method = 'getList';
$cacheparams->methodparams = $params;
$cacheparams->modeparams = array('id'=>'int','Itemid'=>'int');
$list = JModuleHelper::ModuleCache ($module, $params, $cacheparams);
</pre>

====Functional changes====
'''Cache administration (Clean cache, Purge cache) now works with all drivers''', not only with file cache.
'''New standalone garbage collect script''' that is to be called from crontab has been added. It can be found in libraries/joomla/utilities/garbagecron.php . For safety reasons it is recommended that it is renamed to something unique.

====CMS and framework level functional changes====
'''Caching is implemented in all components and modules''' that can potentially gain from cache.
Caching has also been added to some most expensive and frequent framework calls JComponentHelper::_load(), JModuleHelper::_load(),JMenuSite::load();

====Cache library changes====
Cache library has been completely refactored.
*Cache '''handlers have been renamed to controllers''' to better reflect their role and avoid confusion with cache storage handlers (referred to as drivers in following text).
*'''New JCacheController''' parent class has been added and inheritance has been changed to prevent bugs occurring from controller's and storage handler's get method clashes.

====JCache====
*'''getAll()''' method was added to JCache, JCacheStorage and all drivers, and it returns all cached items (this was previously possible only with file driver and hardcoded in administration)
*New '''lock and unlock''' methods were added to JCache, JCacheStorage and drivers. They enable cache item locking and unlocking to prevent errors on parallel accesses and double saves. This functionally was also implemented in controllers.
*Workarounds are now consolidated in new '''JCache getWorkarounds and setWorkarounds''' methods, are now used by all controllers and their use has been made optional.
*New makeId() method in JCache that creates cache id from registered url parameters set by components and system plugins

====JCacheController====
New parent class to Controllers that also functions as an intermediate to JCache. There is no JObject inheritance as otherwise magic __call doesn't work.
Change was needed to prevent bugs occurring from controller's and storage handler's get method clashes. They could be renamed but this would break backwards compatibility.

====JCacheStorage====
*_getCacheId method was moved from drivers to their parent JCacheStorage and all drives now use the same method by default
*CacheItem was moved from cache admin to framework JCacheStorageHelper, it is used by getAll
*There are new cachelite and wincache drivers. All other drivers have been fixed with missing functions (gc, clean) added, their code cleaned and tested they should be now working properly.
*Replaced separate _expire files in filecache driver with timestamps (this should amount to cca. 40% speed gain). The same in all drivers that had this.
*Numerous bugfixes on all levels, most important is proper use of options defaulting to configuration parameters settings and correctly passing from level to level.

====Other framework level changes====
*Safe url parameters registration added to JControler view method.
*New ModuleCache method in JModuleHelper that performs the above described module cache (in 5 modes) for both, modules and module renderer.
*JFactory::getFeedParser has been changed to use Joomla caching instead of simplepie's.

==Performance==
===Eliminate the usage of JTable for general browsing on the frontend===
*Session drops the usage of JTable
*Item views use a dedicated question, not JTable->load

==Known Issues==
*Still Mootools 1.2. Will be upgrading to 1.3 during the beta process.
*Scaling issues to address

==Notes==
===Releases===
*Alpha 1: 22 June 2009
*Alpha 2: 25 October 2009
*Beta 1: 18 May 2010
*Beta 2: 2 weeks after Beta 1

[[Category:Joomla! 1.6]]

J2.5:What's new in Joomla 2.5

2010-05-22T21:39:02Z

Dieter: /* JCache */

Lots of things.

...and:
* '''New Access Control System''' - Allows site administrators control over who can view and manage content.
* '''Unlimited Depth Organizational Model''' - Gives site administrators and content creators user-defined category levels that allow for the creation of a category tree with as many or as few levels for organizing articles and other content as needed.
* '''One-Click Extension Updates''' - Allows users to keep sites secure and controlled by simplifying the process of updating extensions.
* '''Semantic XHTML Layouts''' - Provides a better baseline for content presentation.

...and:

==Administrators==
===Introduction===
*Consistent UI
*Consistent Features
*Richer sample data
*IE 7+, Firefox 3.x, Safari 4.x
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)

===Administrator===
*Menu Changes
*Submenu consistency

====Toolbar Features====
*Save
*Save & Close
*Save & New
*Save as Copy
*Expired session will return to the page you were on then you got logged out (can be hit and miss)
*Most search filters allow you to search for a record id via [ id:123 ]
*"Parameters" are now referred to as "Options"
*Template Styles
*Integrated Trash Management
*Consistent archive support for most content
*Extension Installer Improvements

===Module Enhancements===
*Publish up and down
*Add option to display on all pages "except" selected
*Expanded Category System
*404 Page Redirection
*Better Menu Management
*Alternative layouts for content, modules and menus (taken from the home template)

===New Templates===
*Atomic
*Beez2
*(Administrator) Bluestork (replaces Khephri)
*(Administrator) Hathor
*Legacy layer in Milkyway
*Backend supports layout overrides
*New Modules
*New Plugins
*Content Languages
*User Login Permissions
*Activate selected users from the user list now (and filter)
*Administrator registration approval
*Polls component removed
*New codemirror editor

===SEO Improvements===
*Meta decription and keywords for categories
*Articles can change the page title and page header separately

===Global Configuration===
*Add site name to titles
*Default Access Level
*Set Metadata Language (buggy)
*Unicode Aliases
*Cookie domain and path
*User Setting moved to User Manager -> Options
*Media Settings moved to Media Manager -> Options
*Debug Modules - allows you to enabled to disable the tp=1 feature
*Server Timezone now a location, not an integer offset
*New Global Permissions tab

===User Manager===
*Can activate a user from the list now
*User can be assigned to multiple groups
*Manage user groups
*Manager content access levels

===Media Manager===
*Flash uploader fixed

===Menu Manager===
====Menus List====
*Rebuild button to press when you brick the menu
*Clicking the menu name brings up the menu items list rather than going into Edit Menu. To edit the menu, click on the check box next to the name and click on the Edit icon in the toolbar.

====Items List====
*Menus support the language filter
*Default now called Home
*Home is now clickable in the menu item list
*A separate home can be set for different languages

=====New batch operations=====
*Set access level
*Copy or move to another part of this or another menu

====Edit Item====
*Improved "Type" selector with human readable view and layout names
*Note field added
*New window target
*New Language assignment
*New Template style
*Ability to add & edit Module assignments from this page

=====New options for the menu links and pages themselves=====
*Link title attribute
*Link CSS style
*Menu image is changed to a modal selector
*CSS class for page heading
*Page meta description
*Page meta keywords
*Robots options

===Articles Manager===
*Frontpage is now referred to a Featured
*Article manager uses submenu to quickly skip between articles , categories and featured
*Sections and categories are now merged.

====Articles List====
*''"Missing move and copy; filter by author"''
*New column to show language
*Filtering by language available

====Article Edit====
*Created by user now selected by modal popup
*New ability to set the page title from the article
*Define create, delete, edit and publishing permissions

===Categories===
====Category List====
*Nested view
*Filtering on language

====Edit Category====
*New note field
*Section replaced with ability to assign a parent category
*Ability to assign content language

=====New Options (not previously available in 1.5)=====
*Assign alternate layout
*Define create, delete, edit and publishing permissions
*Meta description
*Meta keywords
*Alternative page title
*Meta author
*Meta robots

===Banners===
====Banners list====
*** Missing copy toolbar button
*New archive toolbar button
*New columns to show meta keywords, purchase type and language
*New filtering by client and language

====Edit Banner====
*New type toggle for Image or Custom (dynamically changes the available form fields)
*New alt text field for image
*New language field

=====New Options=====
*Ability to set the created date
*Ability to set start and finish publishing times
*Ability to set the purchase type
*Ability to track impressions
*Ability to track clicks
*Use own prefix ?
*Tags renamed to meta
*Contacts
*Messaging
*Newsfeeds
*Search
*Weblinks
*Redirect

===Extensions Manager===
====Discover====
*Module mgr
*Plugin Mgr
*Template Mgr
*Language mgr

===Misc===
*Auto create linked contact when creating new user ??

==Access Controls==
*Introduction
*User Groups
*Access Levels
*Permission Layers
*How Permissions are Inherited
*How to debrick your site

==Developers==
===Introduction===
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)
*IE7+, Firefox 3+, Safari 4+
*Focus on code consistency
*Focus on code reduction

Usage of PHP Native Functions where possible, for example:
*[[JXMLElement]] extends the native [http://php.net/manual/en/book.simplexml.php SimpleXML] class
*[[JDate]] extends the [http://www.php.net/manual/en/class.datetime.php DateTime] class
*Native INI parser to load languages

===Removed features===
*ADODB compatibility methods in database classes
*DOMIT (unsupported XML library)
*Legacy mode (includes global $mainframe, etc)
*JTemplate (based on patTemplate)
*patTemplate (templating engine)
*PDF support
*PEAR libraries (due to license incompatibilities)
*phpgacl
*PHP 4.0 and 5.0 compatibility files
*XStandard Editor

===Deprecated Features===
*JController::_acoSection
*JController::_acoSectionValue
*JController::authorize()
*JController::setAccessControl()
*JDatabase::stderr()
*JDate::offest
*JDate::setOffset()
*JDate::toFormat() - use JDate::format() instead
*JException::toString()
*JFactory::getXMLParser()
*JHtmlGird::access()
*JHtmlImage::administrator - use JHtml::image instead
*JHtmlImage::site - use JHtml::image instead
*JHtmlList::accesslevel()
*JHtmlList::specificordering() - use JHtml::_('list.ordering')
*JHtmlList::category()
*JHtmlSelect::optgroup() - see JHtmlSelect::groupedList()
*JLanguage::_parseLanguageFiles - renamed to parseLanguageFiles
*JLanguage::_parseXMLLanguageFile - renamed to parseXMLLanguageFile
*JLanguage::_parseXMLLanguageFiles - renamed to parseXMLLanguageFiles
*JObject::toString - replaced with magic method
*JRegistry::getNameSpaces()
*JRegistry::getValue()
*JRegistry::makeNameSpace()
*JRegistry::setValue()
*JPane - See JHtmlSliders
*JParameter - replaced by JForm
*JSimpleXML, JSimpleXMLElement - Use JXMLElement instead, based on the native SimpleXMLElement
*JTable::canDelete() - models or controllers should be doing the access checks
*JTable::toXML()
*JToolbarHelper customX(), addNewX(), editListX(), editHtmlX(), editCssX(), deleteListX()
*JUser::authorize() - Use JUser::authorise()
*JUtility::dump()
*JUtility::array_unshift_ref() - Not needed in PHP 5
*JUtility::getHash() - Use JApplication::getHash()
*JUtility::getToken() - Use JFactory::getSession()->getFormToken()
*JUtility::isWinOS() - Use JApplication::isWinOS()
*JUtility::return_bytes() - See InstallerModelWarnings::return_bytes()
*JUtility::sendMail() - Use JFactory::getMailer()->sendMail()
*JUtility::sendAdminMail() - Use JFactory::getMailer()->sendMail()
*JXMLElement::data() - Provided for backward compatibility
*JXMLElement::getAttribute() - Provided for backward compatibility

===Database===
*JTable now automatically looks up the fields from the database schema
*New JDatabaseQuery - A chained CRUD query builder
*New JDatabase::getNextRow
*New JDatabase::getNextObject
*JDatabase::loadAssocList - Now takes a second argument to just return the value of a column
*JDatabase::setQuery - Added chaining support

====Important Schema Changes====
*New jos_extensions table to list all extensions
*Components table information moved and split between jos_extensions and jos_menu (special menu called _adminmenu)

The old phpgacl (jos_core_acl*) and jos_groups tables have been reworked into:
*jos_assets
*jos_user_usergroup_map
*jos_usergroups
*jos_viewlevels
*Archived state changed from a value of -1 to +2

===Improved MVC===
====Models====
*JModelList
*JModelForm
*JModelAdmin
*Format handling (eg JSON)
*Sub-controller handling

====Controllers====
*JControllerForm
*JControllerAdmin
*JController::setMessage takes second arg to set the message type
*JController can set the default view
*Added chaining support to several JController methods

====Views====
*Semantic core output
*Milkyway legacy layouts
*The old component parameters are not automatically added to the menu anymore. You need to explicitly put them in the layout XML files.
*The menu manager will now detect additional layouts for a given view in the default template.

===Form API===
====Event manipulation====
*onContentPrepareForm
*onContentPrepareFormData

===Translation and Language Support===
*Support for unicode slugs, eg, SEF URL's with Greek characters
*3-letter languages now supported, xxx-XX
*All existing language keys have been refactored

====INI files must validate====
*Upper case key with no spaces, alphanumeric characters and underscores
*Quoted values
*Double quotes within literal strings must use _QQ_ in the form KEY="<a href="_QQ_"index.php"_QQ_">Click</a>"

====Javascript translation layer====
*See the flash uploader script for an example
Local extension language files

====Language file API====
*Pluralisation support
*Transliteration support for ASCII or Unicode slugs
*Ignore Search Words
*Minimum search word length
*Custom language overrides
*System language file to support administrator menu and installation (.sys.ini)

====Language switcher====
*Language Filter plugin enables language switching
*Sets the automatic filtering via JFactory::getApplication()->setLanguageFilter(true)
*A frontend component with language support would test JFactory::getApplication()->getLanguageFilter(), which returns the selected language code from the Languages Module
*The language field can be a language code for a single language, or "*" to be displayed for all languages
*Community extension for language maintenance com_localise

===Extension management===
====New installation types====
=====Libraries=====
*Must include an XML manifest where type="library"
*Can only be installed into a sub-folder of /libraries/
*Can extend parts of an existing library, eg /libraries/joomla/database/database/oracle.php

=====Packages multi-installer=====
*Must include an XML manifest where type="package"
*A package is a zip of zip's

New install script can be provided with 5 methods:
=====preflight=====
*Runs before anything is run and while the extracted files are in the uploaded temp folder

======Could allow for:======
*secondary extraction of custom zip's
*version checks to be performed
*halting the installer on an error

=====install / update=====
*Runs after the database scripts are executed
*If the extension is new, the install method is run
*If the extension exists then update method is run if method="upgrade", otherwise assumes that the extension is not meant to be upgradable

=====postflight=====
*Runs after the extension is registered in the database
*Is not run for the uninstall process (nothing left to do obviously)

====Discover====
*Does not do any file copying, only works with what it finds
*Performs preflight, install and postflight
*Developer of installer has two language files??

====Update site====
*Can publish an XML manifest on your site that can include individual extensions and extension sets.

====XML Manifest Changes====
*<install> is deprecated - use <extension>
*New <update> tag. Takes a <schemas> tag which can define <schemapath>
*<params> and <param> tags are deprecated, use <fields>, <fieldsets> and <field> instead

====File changes====
*Installation manifest must be the same name as the extension, eg com_foobar/foobar.xml This helps with discovery (otherwise the function has to go through all the files in the extension folder
*Plugins are now in folders like modules and components
*See SVN/tests/_data/installer_packages/ for complete examples of all extensions and manifests.
*The method="upgrade" will compare individual files in the original and incoming manifests and will remove files as appropriate. However, it will not remove differences in the <folder> tags.
*Future support for rollback

===Events===
====New Events====
*onBeforeRender
*onContentBeforeDelete
*onContentAfterDelete
*onContentChangeState
*onContentPrepareForm
*onContentPrepareFormData
*onExtensionBeforeInstall
*onExtensionBeforeUpdate
*onExtensionBeforeUninstall
*onExtensionAfterInstall
*onExtensionAfterUpdate
*onExtensionAfterUninstall

====Renamed Events====
*onContentAfterSave
*onContentAfterTitle
*onContentAfterDisplay
*onContentBeforeDisplay
*onContentBeforeSave
*onContentSearch
*onContentSearchAreas
*onUserAuthenticate
*onUserAfterDelete
*onUserAfterSave
*onUserBeforeDelete
*onUserBeforeSave
*onUserLogin
*onUserLogout
*All content events (except for search and search areas) now pass a 'context' as the first argument to alert the plugin as to what type of content is being passed. The plugin event may or may not heed this context.

===Categories===
*Component can provide custom options for its own categories via optional category.xml
*Supported via JTableNested

===Access Controls===
*A thing that can be controlled by permissions is registered in the assets table
*JTable handles this transparently via asset_id field
*For view permissions, support is as simple as adding
:::$user = JFactory::getUser();
:::$groups = implode(',', $user->authorisedLevels());
:::$query->where('a.access IN (' . $groups . ')');

For action permissions, same format as in 1.5:
$user->authorise($actionName, $assetName)
*OpenID library moved to plugin folder
*Geshi library moved to plugin folder
*JRegistry notes defaults to JSON (new format), dynamically converting existing data in INI format
*New JStream
*New JApplicationHelper::getComponentName
*Core icons moved to /media/
*Backward incompatible change to JEditor::display
*Added chaining support to JMail
*JFilterInput can no longer be called statically
*JHtml::image now supports relative paths
*All system images are overridable in the default template
*New JHtmlString
*Added wincache session handler for IIS
*New JFilterOutput::stripImages
*JPath::check takes second arg for separator (to pass to JPath::clean)
*Expanded configuration support through config.xml (multiple tabs)

====Core actions====
*core.login.site
*core.login.admin
*core.admin
*core.manage
*core.create
*core.edit
*core.edit.state
*core.delete
*Miscellaneous changes

===Debug Plugin===
*More tools for assisting with translation

===Mootools 1.2/1.3===
*Need to use document.id instead of $

==Cache changes ==
===API changes relevant to 3rd party developers===
====Component view cache====

Component view cache now takes an array of url parameters and their types to create Cacheid. This is a replacement for a previous unsafe way which took the whole URL for this and so opened the doors for DOS attacks via random url parameters added to request URL's.

Com_contact example:

<pre>
$safeurlparams = array(
'id'=>'INT',
'catid'=>'INT', 'limit'=>'INT',
'limitstart'=>'INT',
'filter_order'=>'CMD',
'filter_order_Dir'=>'CMD'
);

parent::display($cachable,$safeurlparams);
</pre>

Old cacheid created from URL was retained for backwards compatibility and takes effect if there are no $safeurlparams.

====Module cache====
This has been completly reconceptualized. Module cache now has 5 different modes of operation, 3 of them are to be set from module XML file, while 2 are meant to be used from within the module itself. Default is backwards compatible oldstatic mode that requires no changes to a module.

Modes to be set in XML:
*'''static''' - one cache file for all pages with the same module parameters
*'''oldstatic''' - 1.5. definition of module caching, one cache file for all pages with the same module id and user aid. Default for backwards compatibility
*'''itemid''' - changes on itemid change

In addition to cache field that was required in 1.5 there is now another hidden field called cachemode that sets any of the above modes.

<pre>
<field name="cachemode" type="hidden" label="" default="static">
<option value="static"></option>
</pre>

Modes to be called from inside the module:
*'''safeuri''' - id is created from $cacheparams->modeparams array, the same as in component view cache
*'''id''' - module sets own cache id's

To use this modes one must rename cache field in xml to owncache field and call JModuleHelper::ModuleCache from within the module's main php file. This is actually a shortcut to cache callback to avoid code duplication in every module.

An example that uses safeuri mode and replaces uncached
$list = modRelatedItemsHelper::getList($params) :

<pre>
$cacheparams = new stdClass;
$cacheparams->cachemode = 'safeuri';
$cacheparams->class = 'modRelatedItemsHelper';
$cacheparams->method = 'getList';
$cacheparams->methodparams = $params;
$cacheparams->modeparams = array('id'=>'int','Itemid'=>'int');
$list = JModuleHelper::ModuleCache ($module, $params, $cacheparams);
</pre>

====Functional changes====
'''Cache administration (Clean cache, Purge cache) now works with all drivers''', not only with file cache.
'''New standalone garbage collect script''' that is to be called from crontab has been added. It can be found in libraries/joomla/utilities/garbagecron.php . For safety reasons it is recommended that it is renamed to something unique.

====CMS and framework level functional changes====
'''Caching is implemented in all components and modules''' that can potentially gain from cache.
Caching has also been added to some most expensive and frequent framework calls JComponentHelper::_load(), JModuleHelper::_load(),JMenuSite::load();

====Cache library changes====
Cache library has been completely refactored.
*Cache '''handlers have been renamed to controllers''' to better reflect their role and avoid confusion with cache storage handlers (referred to as drivers in following text).
*'''New JCacheController''' parent class has been added and inheritance has been changed to prevent bugs occurring from controller's and storage handler's get method clashes.

====JCache====
*'''getAll()''' method was added to JCache, JCacheStorage and all drivers, and it returns all cached items (this was previously possible only with file driver and hardcoded in administration)
*New '''lock and unlock''' methods were added to JCache, JCacheStorage and drivers. They enable cache item locking and unlocking to prevent errors on parallel accesses and double saves. This functionally was also implemented in controllers.
*Workarounds are now consolidated in new '''JCache getWorkarounds and setWorkarounds''' methods, are now used by all controllers and their use has been made optional.
*New makeId() method in JCache that creates cache id from registered url parameters set by components and system plugins

====JCacheController====
New parent class to Controllers that also functions as an intermediate to JCache. There is no JObject inheritance as otherwise magic __call doesn't work.
Change was needed to prevent bugs occurring from controller's and storage handler's get method clashes. They could be renamed but this would break backwards compatibility.

====JCacheStorage====
*_getCacheId method was moved from drivers to their parent JCacheStorage and all drives now use the same method by default
*CacheItem was moved from cache admin to framework JCacheStorageHelper , it is used by getAll
*There are new cachelite and wincache drivers. All other drivers have been fixed with missing functions (gc, clean) added, their code cleaned and tested they should be now working properly.
*Replaced separate _expire files in filecache driver with timestamps (this should amount to cca. 40% speed gain). The same in all drivers that had this.
*Numerous bugfixes on all levels, most important is proper use of options defaulting to configuration parameters settings and correctly passing from level to level.

====Other framework level changes====
*Safe url parameters registration added to JControler view method.
*New ModuleCache method in JModuleHelper that performs the above described module cache (in 5 modes) for both, modules and module renderer.
*JFactory::getFeedParser has been changed to use Joomla caching instead of simplepie's.

==Performance==
===Eliminate the usage of JTable for general browsing on the frontend===
*Session drops the usage of JTable
*Item views use a dedicated question, not JTable->load

==Known Issues==
*Still Mootools 1.2. Will be upgrading to 1.3 during the beta process.
*Scaling issues to address

==Notes==
===Releases===
*Alpha 1: 22 June 2009
*Alpha 2: 25 October 2009
*Beta 1: 18 May 2010
*Beta 2: 2 weeks after Beta 1

[[Category:Joomla! 1.6]]

J2.5:What's new in Joomla 2.5

2010-05-22T21:33:20Z

Dieter: /* Functional changes */

Lots of things.

...and:
* '''New Access Control System''' - Allows site administrators control over who can view and manage content.
* '''Unlimited Depth Organizational Model''' - Gives site administrators and content creators user-defined category levels that allow for the creation of a category tree with as many or as few levels for organizing articles and other content as needed.
* '''One-Click Extension Updates''' - Allows users to keep sites secure and controlled by simplifying the process of updating extensions.
* '''Semantic XHTML Layouts''' - Provides a better baseline for content presentation.

...and:

==Administrators==
===Introduction===
*Consistent UI
*Consistent Features
*Richer sample data
*IE 7+, Firefox 3.x, Safari 4.x
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)

===Administrator===
*Menu Changes
*Submenu consistency

====Toolbar Features====
*Save
*Save & Close
*Save & New
*Save as Copy
*Expired session will return to the page you were on then you got logged out (can be hit and miss)
*Most search filters allow you to search for a record id via [ id:123 ]
*"Parameters" are now referred to as "Options"
*Template Styles
*Integrated Trash Management
*Consistent archive support for most content
*Extension Installer Improvements

===Module Enhancements===
*Publish up and down
*Add option to display on all pages "except" selected
*Expanded Category System
*404 Page Redirection
*Better Menu Management
*Alternative layouts for content, modules and menus (taken from the home template)

===New Templates===
*Atomic
*Beez2
*(Administrator) Bluestork (replaces Khephri)
*(Administrator) Hathor
*Legacy layer in Milkyway
*Backend supports layout overrides
*New Modules
*New Plugins
*Content Languages
*User Login Permissions
*Activate selected users from the user list now (and filter)
*Administrator registration approval
*Polls component removed
*New codemirror editor

===SEO Improvements===
*Meta decription and keywords for categories
*Articles can change the page title and page header separately

===Global Configuration===
*Add site name to titles
*Default Access Level
*Set Metadata Language (buggy)
*Unicode Aliases
*Cookie domain and path
*User Setting moved to User Manager -> Options
*Media Settings moved to Media Manager -> Options
*Debug Modules - allows you to enabled to disable the tp=1 feature
*Server Timezone now a location, not an integer offset
*New Global Permissions tab

===User Manager===
*Can activate a user from the list now
*User can be assigned to multiple groups
*Manage user groups
*Manager content access levels

===Media Manager===
*Flash uploader fixed

===Menu Manager===
====Menus List====
*Rebuild button to press when you brick the menu
*Clicking the menu name brings up the menu items list rather than going into Edit Menu. To edit the menu, click on the check box next to the name and click on the Edit icon in the toolbar.

====Items List====
*Menus support the language filter
*Default now called Home
*Home is now clickable in the menu item list
*A separate home can be set for different languages

=====New batch operations=====
*Set access level
*Copy or move to another part of this or another menu

====Edit Item====
*Improved "Type" selector with human readable view and layout names
*Note field added
*New window target
*New Language assignment
*New Template style
*Ability to add & edit Module assignments from this page

=====New options for the menu links and pages themselves=====
*Link title attribute
*Link CSS style
*Menu image is changed to a modal selector
*CSS class for page heading
*Page meta description
*Page meta keywords
*Robots options

===Articles Manager===
*Frontpage is now referred to a Featured
*Article manager uses submenu to quickly skip between articles , categories and featured
*Sections and categories are now merged.

====Articles List====
*''"Missing move and copy; filter by author"''
*New column to show language
*Filtering by language available

====Article Edit====
*Created by user now selected by modal popup
*New ability to set the page title from the article
*Define create, delete, edit and publishing permissions

===Categories===
====Category List====
*Nested view
*Filtering on language

====Edit Category====
*New note field
*Section replaced with ability to assign a parent category
*Ability to assign content language

=====New Options (not previously available in 1.5)=====
*Assign alternate layout
*Define create, delete, edit and publishing permissions
*Meta description
*Meta keywords
*Alternative page title
*Meta author
*Meta robots

===Banners===
====Banners list====
*** Missing copy toolbar button
*New archive toolbar button
*New columns to show meta keywords, purchase type and language
*New filtering by client and language

====Edit Banner====
*New type toggle for Image or Custom (dynamically changes the available form fields)
*New alt text field for image
*New language field

=====New Options=====
*Ability to set the created date
*Ability to set start and finish publishing times
*Ability to set the purchase type
*Ability to track impressions
*Ability to track clicks
*Use own prefix ?
*Tags renamed to meta
*Contacts
*Messaging
*Newsfeeds
*Search
*Weblinks
*Redirect

===Extensions Manager===
====Discover====
*Module mgr
*Plugin Mgr
*Template Mgr
*Language mgr

===Misc===
*Auto create linked contact when creating new user ??

==Access Controls==
*Introduction
*User Groups
*Access Levels
*Permission Layers
*How Permissions are Inherited
*How to debrick your site

==Developers==
===Introduction===
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)
*IE7+, Firefox 3+, Safari 4+
*Focus on code consistency
*Focus on code reduction

Usage of PHP Native Functions where possible, for example:
*[[JXMLElement]] extends the native [http://php.net/manual/en/book.simplexml.php SimpleXML] class
*[[JDate]] extends the [http://www.php.net/manual/en/class.datetime.php DateTime] class
*Native INI parser to load languages

===Removed features===
*ADODB compatibility methods in database classes
*DOMIT (unsupported XML library)
*Legacy mode (includes global $mainframe, etc)
*JTemplate (based on patTemplate)
*patTemplate (templating engine)
*PDF support
*PEAR libraries (due to license incompatibilities)
*phpgacl
*PHP 4.0 and 5.0 compatibility files
*XStandard Editor

===Deprecated Features===
*JController::_acoSection
*JController::_acoSectionValue
*JController::authorize()
*JController::setAccessControl()
*JDatabase::stderr()
*JDate::offest
*JDate::setOffset()
*JDate::toFormat() - use JDate::format() instead
*JException::toString()
*JFactory::getXMLParser()
*JHtmlGird::access()
*JHtmlImage::administrator - use JHtml::image instead
*JHtmlImage::site - use JHtml::image instead
*JHtmlList::accesslevel()
*JHtmlList::specificordering() - use JHtml::_('list.ordering')
*JHtmlList::category()
*JHtmlSelect::optgroup() - see JHtmlSelect::groupedList()
*JLanguage::_parseLanguageFiles - renamed to parseLanguageFiles
*JLanguage::_parseXMLLanguageFile - renamed to parseXMLLanguageFile
*JLanguage::_parseXMLLanguageFiles - renamed to parseXMLLanguageFiles
*JObject::toString - replaced with magic method
*JRegistry::getNameSpaces()
*JRegistry::getValue()
*JRegistry::makeNameSpace()
*JRegistry::setValue()
*JPane - See JHtmlSliders
*JParameter - replaced by JForm
*JSimpleXML, JSimpleXMLElement - Use JXMLElement instead, based on the native SimpleXMLElement
*JTable::canDelete() - models or controllers should be doing the access checks
*JTable::toXML()
*JToolbarHelper customX(), addNewX(), editListX(), editHtmlX(), editCssX(), deleteListX()
*JUser::authorize() - Use JUser::authorise()
*JUtility::dump()
*JUtility::array_unshift_ref() - Not needed in PHP 5
*JUtility::getHash() - Use JApplication::getHash()
*JUtility::getToken() - Use JFactory::getSession()->getFormToken()
*JUtility::isWinOS() - Use JApplication::isWinOS()
*JUtility::return_bytes() - See InstallerModelWarnings::return_bytes()
*JUtility::sendMail() - Use JFactory::getMailer()->sendMail()
*JUtility::sendAdminMail() - Use JFactory::getMailer()->sendMail()
*JXMLElement::data() - Provided for backward compatibility
*JXMLElement::getAttribute() - Provided for backward compatibility

===Database===
*JTable now automatically looks up the fields from the database schema
*New JDatabaseQuery - A chained CRUD query builder
*New JDatabase::getNextRow
*New JDatabase::getNextObject
*JDatabase::loadAssocList - Now takes a second argument to just return the value of a column
*JDatabase::setQuery - Added chaining support

====Important Schema Changes====
*New jos_extensions table to list all extensions
*Components table information moved and split between jos_extensions and jos_menu (special menu called _adminmenu)

The old phpgacl (jos_core_acl*) and jos_groups tables have been reworked into:
*jos_assets
*jos_user_usergroup_map
*jos_usergroups
*jos_viewlevels
*Archived state changed from a value of -1 to +2

===Improved MVC===
====Models====
*JModelList
*JModelForm
*JModelAdmin
*Format handling (eg JSON)
*Sub-controller handling

====Controllers====
*JControllerForm
*JControllerAdmin
*JController::setMessage takes second arg to set the message type
*JController can set the default view
*Added chaining support to several JController methods

====Views====
*Semantic core output
*Milkyway legacy layouts
*The old component parameters are not automatically added to the menu anymore. You need to explicitly put them in the layout XML files.
*The menu manager will now detect additional layouts for a given view in the default template.

===Form API===
====Event manipulation====
*onContentPrepareForm
*onContentPrepareFormData

===Translation and Language Support===
*Support for unicode slugs, eg, SEF URL's with Greek characters
*3-letter languages now supported, xxx-XX
*All existing language keys have been refactored

====INI files must validate====
*Upper case key with no spaces, alphanumeric characters and underscores
*Quoted values
*Double quotes within literal strings must use _QQ_ in the form KEY="<a href="_QQ_"index.php"_QQ_">Click</a>"

====Javascript translation layer====
*See the flash uploader script for an example
Local extension language files

====Language file API====
*Pluralisation support
*Transliteration support for ASCII or Unicode slugs
*Ignore Search Words
*Minimum search word length
*Custom language overrides
*System language file to support administrator menu and installation (.sys.ini)

====Language switcher====
*Language Filter plugin enables language switching
*Sets the automatic filtering via JFactory::getApplication()->setLanguageFilter(true)
*A frontend component with language support would test JFactory::getApplication()->getLanguageFilter(), which returns the selected language code from the Languages Module
*The language field can be a language code for a single language, or "*" to be displayed for all languages
*Community extension for language maintenance com_localise

===Extension management===
====New installation types====
=====Libraries=====
*Must include an XML manifest where type="library"
*Can only be installed into a sub-folder of /libraries/
*Can extend parts of an existing library, eg /libraries/joomla/database/database/oracle.php

=====Packages multi-installer=====
*Must include an XML manifest where type="package"
*A package is a zip of zip's

New install script can be provided with 5 methods:
=====preflight=====
*Runs before anything is run and while the extracted files are in the uploaded temp folder

======Could allow for:======
*secondary extraction of custom zip's
*version checks to be performed
*halting the installer on an error

=====install / update=====
*Runs after the database scripts are executed
*If the extension is new, the install method is run
*If the extension exists then update method is run if method="upgrade", otherwise assumes that the extension is not meant to be upgradable

=====postflight=====
*Runs after the extension is registered in the database
*Is not run for the uninstall process (nothing left to do obviously)

====Discover====
*Does not do any file copying, only works with what it finds
*Performs preflight, install and postflight
*Developer of installer has two language files??

====Update site====
*Can publish an XML manifest on your site that can include individual extensions and extension sets.

====XML Manifest Changes====
*<install> is deprecated - use <extension>
*New <update> tag. Takes a <schemas> tag which can define <schemapath>
*<params> and <param> tags are deprecated, use <fields>, <fieldsets> and <field> instead

====File changes====
*Installation manifest must be the same name as the extension, eg com_foobar/foobar.xml This helps with discovery (otherwise the function has to go through all the files in the extension folder
*Plugins are now in folders like modules and components
*See SVN/tests/_data/installer_packages/ for complete examples of all extensions and manifests.
*The method="upgrade" will compare individual files in the original and incoming manifests and will remove files as appropriate. However, it will not remove differences in the <folder> tags.
*Future support for rollback

===Events===
====New Events====
*onBeforeRender
*onContentBeforeDelete
*onContentAfterDelete
*onContentChangeState
*onContentPrepareForm
*onContentPrepareFormData
*onExtensionBeforeInstall
*onExtensionBeforeUpdate
*onExtensionBeforeUninstall
*onExtensionAfterInstall
*onExtensionAfterUpdate
*onExtensionAfterUninstall

====Renamed Events====
*onContentAfterSave
*onContentAfterTitle
*onContentAfterDisplay
*onContentBeforeDisplay
*onContentBeforeSave
*onContentSearch
*onContentSearchAreas
*onUserAuthenticate
*onUserAfterDelete
*onUserAfterSave
*onUserBeforeDelete
*onUserBeforeSave
*onUserLogin
*onUserLogout
*All content events (except for search and search areas) now pass a 'context' as the first argument to alert the plugin as to what type of content is being passed. The plugin event may or may not heed this context.

===Categories===
*Component can provide custom options for its own categories via optional category.xml
*Supported via JTableNested

===Access Controls===
*A thing that can be controlled by permissions is registered in the assets table
*JTable handles this transparently via asset_id field
*For view permissions, support is as simple as adding
:::$user = JFactory::getUser();
:::$groups = implode(',', $user->authorisedLevels());
:::$query->where('a.access IN (' . $groups . ')');

For action permissions, same format as in 1.5:
$user->authorise($actionName, $assetName)
*OpenID library moved to plugin folder
*Geshi library moved to plugin folder
*JRegistry notes defaults to JSON (new format), dynamically converting existing data in INI format
*New JStream
*New JApplicationHelper::getComponentName
*Core icons moved to /media/
*Backward incompatible change to JEditor::display
*Added chaining support to JMail
*JFilterInput can no longer be called statically
*JHtml::image now supports relative paths
*All system images are overridable in the default template
*New JHtmlString
*Added wincache session handler for IIS
*New JFilterOutput::stripImages
*JPath::check takes second arg for separator (to pass to JPath::clean)
*Expanded configuration support through config.xml (multiple tabs)

====Core actions====
*core.login.site
*core.login.admin
*core.admin
*core.manage
*core.create
*core.edit
*core.edit.state
*core.delete
*Miscellaneous changes

===Debug Plugin===
*More tools for assisting with translation

===Mootools 1.2/1.3===
*Need to use document.id instead of $

==Cache changes ==
===API changes relevant to 3rd party developers===
====Component view cache====

Component view cache now takes an array of url parameters and their types to create Cacheid. This is a replacement for a previous unsafe way which took the whole URL for this and so opened the doors for DOS attacks via random url parameters added to request URL's.

Com_contact example:

<pre>
$safeurlparams = array(
'id'=>'INT',
'catid'=>'INT', 'limit'=>'INT',
'limitstart'=>'INT',
'filter_order'=>'CMD',
'filter_order_Dir'=>'CMD'
);

parent::display($cachable,$safeurlparams);
</pre>

Old cacheid created from URL was retained for backwards compatibility and takes effect if there are no $safeurlparams.

====Module cache====
This has been completly reconceptualized. Module cache now has 5 different modes of operation, 3 of them are to be set from module XML file, while 2 are meant to be used from within the module itself. Default is backwards compatible oldstatic mode that requires no changes to a module.

Modes to be set in XML:
*'''static''' - one cache file for all pages with the same module parameters
*'''oldstatic''' - 1.5. definition of module caching, one cache file for all pages with the same module id and user aid. Default for backwards compatibility
*'''itemid''' - changes on itemid change

In addition to cache field that was required in 1.5 there is now another hidden field called cachemode that sets any of the above modes.

<pre>
<field name="cachemode" type="hidden" label="" default="static">
<option value="static"></option>
</pre>

Modes to be called from inside the module:
*'''safeuri''' - id is created from $cacheparams->modeparams array, the same as in component view cache
*'''id''' - module sets own cache id's

To use this modes one must rename cache field in xml to owncache field and call JModuleHelper::ModuleCache from within the module's main php file. This is actually a shortcut to cache callback to avoid code duplication in every module.

An example that uses safeuri mode and replaces uncached
$list = modRelatedItemsHelper::getList($params) :

<pre>
$cacheparams = new stdClass;
$cacheparams->cachemode = 'safeuri';
$cacheparams->class = 'modRelatedItemsHelper';
$cacheparams->method = 'getList';
$cacheparams->methodparams = $params;
$cacheparams->modeparams = array('id'=>'int','Itemid'=>'int');
$list = JModuleHelper::ModuleCache ($module, $params, $cacheparams);
</pre>

====Functional changes====
'''Cache administration (Clean cache, Purge cache) now works with all drivers''', not only with file cache.
'''New standalone garbage collect script''' that is to be called from crontab has been added. It can be found in libraries/joomla/utilities/garbagecron.php . For safety reasons it is recommended that it is renamed to something unique.

====CMS and framework level functional changes====
'''Caching is implemented in all components and modules''' that can potentially gain from cache.
Caching has also been added to some most expensive and frequent framework calls JComponentHelper::_load(), JModuleHelper::_load(),JMenuSite::load();

====Cache library changes====
Cache library has been completely refactored.
*Cache '''handlers have been renamed to controllers''' to better reflect their role and avoid confusion with cache storage handlers (referred to as drivers in following text).
*'''New JCacheController''' parent class has been added and inheritance has been changed to prevent bugs occurring from controller's and storage handler's get method clashes.

====JCache====
*'''getAll()''' method was added to JCache ,JCacheStorage and all drivers and it returns all cached items (this was previously possible only with file driver and hardcoded in administration)
*New '''lock and unlock''' methods were added to JCache, JCacheStorage and drivers. They enable cache item locking and unlocking to prevent errors on parallel accesses and double saves. This functionally was also implemented in controllers.
*Workarounds are now consolidated in new '''JCache getWorkarounds and setWorkarounds''' methods, are now used by all controllers and their use has been made optional.
*New makeId() method in JCache that creates cache id from registered url parameters set by components and system plugins

====JCacheController====
New parent class to Controllers that also functions as an intermediate to JCache. There is no JObject inheritance as otherwise magic __call doesn't work.
Change was needed to prevent bugs occurring from controller's and storage handler's get method clashes. They could be renamed but this would break backwards compatibility.

====JCacheStorage====
*_getCacheId method was moved from drivers to their parent JCacheStorage and all drives now use the same method by default
*CacheItem was moved from cache admin to framework JCacheStorageHelper , it is used by getAll
*There are new cachelite and wincache drivers. All other drivers have been fixed with missing functions (gc, clean) added, their code cleaned and tested they should be now working properly.
*Replaced separate _expire files in filecache driver with timestamps (this should amount to cca. 40% speed gain). The same in all drivers that had this.
*Numerous bugfixes on all levels, most important is proper use of options defaulting to configuration parameters settings and correctly passing from level to level.

====Other framework level changes====
*Safe url parameters registration added to JControler view method.
*New ModuleCache method in JModuleHelper that performs the above described module cache (in 5 modes) for both, modules and module renderer.
*JFactory::getFeedParser has been changed to use Joomla caching instead of simplepie's.

==Performance==
===Eliminate the usage of JTable for general browsing on the frontend===
*Session drops the usage of JTable
*Item views use a dedicated question, not JTable->load

==Known Issues==
*Still Mootools 1.2. Will be upgrading to 1.3 during the beta process.
*Scaling issues to address

==Notes==
===Releases===
*Alpha 1: 22 June 2009
*Alpha 2: 25 October 2009
*Beta 1: 18 May 2010
*Beta 2: 2 weeks after Beta 1

[[Category:Joomla! 1.6]]

J2.5:What's new in Joomla 2.5

2010-05-22T21:25:18Z

Dieter: /* Component view cache */

Lots of things.

...and:
* '''New Access Control System''' - Allows site administrators control over who can view and manage content.
* '''Unlimited Depth Organizational Model''' - Gives site administrators and content creators user-defined category levels that allow for the creation of a category tree with as many or as few levels for organizing articles and other content as needed.
* '''One-Click Extension Updates''' - Allows users to keep sites secure and controlled by simplifying the process of updating extensions.
* '''Semantic XHTML Layouts''' - Provides a better baseline for content presentation.

...and:

==Administrators==
===Introduction===
*Consistent UI
*Consistent Features
*Richer sample data
*IE 7+, Firefox 3.x, Safari 4.x
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)

===Administrator===
*Menu Changes
*Submenu consistency

====Toolbar Features====
*Save
*Save & Close
*Save & New
*Save as Copy
*Expired session will return to the page you were on then you got logged out (can be hit and miss)
*Most search filters allow you to search for a record id via [ id:123 ]
*"Parameters" are now referred to as "Options"
*Template Styles
*Integrated Trash Management
*Consistent archive support for most content
*Extension Installer Improvements

===Module Enhancements===
*Publish up and down
*Add option to display on all pages "except" selected
*Expanded Category System
*404 Page Redirection
*Better Menu Management
*Alternative layouts for content, modules and menus (taken from the home template)

===New Templates===
*Atomic
*Beez2
*(Administrator) Bluestork (replaces Khephri)
*(Administrator) Hathor
*Legacy layer in Milkyway
*Backend supports layout overrides
*New Modules
*New Plugins
*Content Languages
*User Login Permissions
*Activate selected users from the user list now (and filter)
*Administrator registration approval
*Polls component removed
*New codemirror editor

===SEO Improvements===
*Meta decription and keywords for categories
*Articles can change the page title and page header separately

===Global Configuration===
*Add site name to titles
*Default Access Level
*Set Metadata Language (buggy)
*Unicode Aliases
*Cookie domain and path
*User Setting moved to User Manager -> Options
*Media Settings moved to Media Manager -> Options
*Debug Modules - allows you to enabled to disable the tp=1 feature
*Server Timezone now a location, not an integer offset
*New Global Permissions tab

===User Manager===
*Can activate a user from the list now
*User can be assigned to multiple groups
*Manage user groups
*Manager content access levels

===Media Manager===
*Flash uploader fixed

===Menu Manager===
====Menus List====
*Rebuild button to press when you brick the menu
*Clicking the menu name brings up the menu items list rather than going into Edit Menu. To edit the menu, click on the check box next to the name and click on the Edit icon in the toolbar.

====Items List====
*Menus support the language filter
*Default now called Home
*Home is now clickable in the menu item list
*A separate home can be set for different languages

=====New batch operations=====
*Set access level
*Copy or move to another part of this or another menu

====Edit Item====
*Improved "Type" selector with human readable view and layout names
*Note field added
*New window target
*New Language assignment
*New Template style
*Ability to add & edit Module assignments from this page

=====New options for the menu links and pages themselves=====
*Link title attribute
*Link CSS style
*Menu image is changed to a modal selector
*CSS class for page heading
*Page meta description
*Page meta keywords
*Robots options

===Articles Manager===
*Frontpage is now referred to a Featured
*Article manager uses submenu to quickly skip between articles , categories and featured
*Sections and categories are now merged.

====Articles List====
*''"Missing move and copy; filter by author"''
*New column to show language
*Filtering by language available

====Article Edit====
*Created by user now selected by modal popup
*New ability to set the page title from the article
*Define create, delete, edit and publishing permissions

===Categories===
====Category List====
*Nested view
*Filtering on language

====Edit Category====
*New note field
*Section replaced with ability to assign a parent category
*Ability to assign content language

=====New Options (not previously available in 1.5)=====
*Assign alternate layout
*Define create, delete, edit and publishing permissions
*Meta description
*Meta keywords
*Alternative page title
*Meta author
*Meta robots

===Banners===
====Banners list====
*** Missing copy toolbar button
*New archive toolbar button
*New columns to show meta keywords, purchase type and language
*New filtering by client and language

====Edit Banner====
*New type toggle for Image or Custom (dynamically changes the available form fields)
*New alt text field for image
*New language field

=====New Options=====
*Ability to set the created date
*Ability to set start and finish publishing times
*Ability to set the purchase type
*Ability to track impressions
*Ability to track clicks
*Use own prefix ?
*Tags renamed to meta
*Contacts
*Messaging
*Newsfeeds
*Search
*Weblinks
*Redirect

===Extensions Manager===
====Discover====
*Module mgr
*Plugin Mgr
*Template Mgr
*Language mgr

===Misc===
*Auto create linked contact when creating new user ??

==Access Controls==
*Introduction
*User Groups
*Access Levels
*Permission Layers
*How Permissions are Inherited
*How to debrick your site

==Developers==
===Introduction===
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)
*IE7+, Firefox 3+, Safari 4+
*Focus on code consistency
*Focus on code reduction

Usage of PHP Native Functions where possible, for example:
*[[JXMLElement]] extends the native [http://php.net/manual/en/book.simplexml.php SimpleXML] class
*[[JDate]] extends the [http://www.php.net/manual/en/class.datetime.php DateTime] class
*Native INI parser to load languages

===Removed features===
*ADODB compatibility methods in database classes
*DOMIT (unsupported XML library)
*Legacy mode (includes global $mainframe, etc)
*JTemplate (based on patTemplate)
*patTemplate (templating engine)
*PDF support
*PEAR libraries (due to license incompatibilities)
*phpgacl
*PHP 4.0 and 5.0 compatibility files
*XStandard Editor

===Deprecated Features===
*JController::_acoSection
*JController::_acoSectionValue
*JController::authorize()
*JController::setAccessControl()
*JDatabase::stderr()
*JDate::offest
*JDate::setOffset()
*JDate::toFormat() - use JDate::format() instead
*JException::toString()
*JFactory::getXMLParser()
*JHtmlGird::access()
*JHtmlImage::administrator - use JHtml::image instead
*JHtmlImage::site - use JHtml::image instead
*JHtmlList::accesslevel()
*JHtmlList::specificordering() - use JHtml::_('list.ordering')
*JHtmlList::category()
*JHtmlSelect::optgroup() - see JHtmlSelect::groupedList()
*JLanguage::_parseLanguageFiles - renamed to parseLanguageFiles
*JLanguage::_parseXMLLanguageFile - renamed to parseXMLLanguageFile
*JLanguage::_parseXMLLanguageFiles - renamed to parseXMLLanguageFiles
*JObject::toString - replaced with magic method
*JRegistry::getNameSpaces()
*JRegistry::getValue()
*JRegistry::makeNameSpace()
*JRegistry::setValue()
*JPane - See JHtmlSliders
*JParameter - replaced by JForm
*JSimpleXML, JSimpleXMLElement - Use JXMLElement instead, based on the native SimpleXMLElement
*JTable::canDelete() - models or controllers should be doing the access checks
*JTable::toXML()
*JToolbarHelper customX(), addNewX(), editListX(), editHtmlX(), editCssX(), deleteListX()
*JUser::authorize() - Use JUser::authorise()
*JUtility::dump()
*JUtility::array_unshift_ref() - Not needed in PHP 5
*JUtility::getHash() - Use JApplication::getHash()
*JUtility::getToken() - Use JFactory::getSession()->getFormToken()
*JUtility::isWinOS() - Use JApplication::isWinOS()
*JUtility::return_bytes() - See InstallerModelWarnings::return_bytes()
*JUtility::sendMail() - Use JFactory::getMailer()->sendMail()
*JUtility::sendAdminMail() - Use JFactory::getMailer()->sendMail()
*JXMLElement::data() - Provided for backward compatibility
*JXMLElement::getAttribute() - Provided for backward compatibility

===Database===
*JTable now automatically looks up the fields from the database schema
*New JDatabaseQuery - A chained CRUD query builder
*New JDatabase::getNextRow
*New JDatabase::getNextObject
*JDatabase::loadAssocList - Now takes a second argument to just return the value of a column
*JDatabase::setQuery - Added chaining support

====Important Schema Changes====
*New jos_extensions table to list all extensions
*Components table information moved and split between jos_extensions and jos_menu (special menu called _adminmenu)

The old phpgacl (jos_core_acl*) and jos_groups tables have been reworked into:
*jos_assets
*jos_user_usergroup_map
*jos_usergroups
*jos_viewlevels
*Archived state changed from a value of -1 to +2

===Improved MVC===
====Models====
*JModelList
*JModelForm
*JModelAdmin
*Format handling (eg JSON)
*Sub-controller handling

====Controllers====
*JControllerForm
*JControllerAdmin
*JController::setMessage takes second arg to set the message type
*JController can set the default view
*Added chaining support to several JController methods

====Views====
*Semantic core output
*Milkyway legacy layouts
*The old component parameters are not automatically added to the menu anymore. You need to explicitly put them in the layout XML files.
*The menu manager will now detect additional layouts for a given view in the default template.

===Form API===
====Event manipulation====
*onContentPrepareForm
*onContentPrepareFormData

===Translation and Language Support===
*Support for unicode slugs, eg, SEF URL's with Greek characters
*3-letter languages now supported, xxx-XX
*All existing language keys have been refactored

====INI files must validate====
*Upper case key with no spaces, alphanumeric characters and underscores
*Quoted values
*Double quotes within literal strings must use _QQ_ in the form KEY="<a href="_QQ_"index.php"_QQ_">Click</a>"

====Javascript translation layer====
*See the flash uploader script for an example
Local extension language files

====Language file API====
*Pluralisation support
*Transliteration support for ASCII or Unicode slugs
*Ignore Search Words
*Minimum search word length
*Custom language overrides
*System language file to support administrator menu and installation (.sys.ini)

====Language switcher====
*Language Filter plugin enables language switching
*Sets the automatic filtering via JFactory::getApplication()->setLanguageFilter(true)
*A frontend component with language support would test JFactory::getApplication()->getLanguageFilter(), which returns the selected language code from the Languages Module
*The language field can be a language code for a single language, or "*" to be displayed for all languages
*Community extension for language maintenance com_localise

===Extension management===
====New installation types====
=====Libraries=====
*Must include an XML manifest where type="library"
*Can only be installed into a sub-folder of /libraries/
*Can extend parts of an existing library, eg /libraries/joomla/database/database/oracle.php

=====Packages multi-installer=====
*Must include an XML manifest where type="package"
*A package is a zip of zip's

New install script can be provided with 5 methods:
=====preflight=====
*Runs before anything is run and while the extracted files are in the uploaded temp folder

======Could allow for:======
*secondary extraction of custom zip's
*version checks to be performed
*halting the installer on an error

=====install / update=====
*Runs after the database scripts are executed
*If the extension is new, the install method is run
*If the extension exists then update method is run if method="upgrade", otherwise assumes that the extension is not meant to be upgradable

=====postflight=====
*Runs after the extension is registered in the database
*Is not run for the uninstall process (nothing left to do obviously)

====Discover====
*Does not do any file copying, only works with what it finds
*Performs preflight, install and postflight
*Developer of installer has two language files??

====Update site====
*Can publish an XML manifest on your site that can include individual extensions and extension sets.

====XML Manifest Changes====
*<install> is deprecated - use <extension>
*New <update> tag. Takes a <schemas> tag which can define <schemapath>
*<params> and <param> tags are deprecated, use <fields>, <fieldsets> and <field> instead

====File changes====
*Installation manifest must be the same name as the extension, eg com_foobar/foobar.xml This helps with discovery (otherwise the function has to go through all the files in the extension folder
*Plugins are now in folders like modules and components
*See SVN/tests/_data/installer_packages/ for complete examples of all extensions and manifests.
*The method="upgrade" will compare individual files in the original and incoming manifests and will remove files as appropriate. However, it will not remove differences in the <folder> tags.
*Future support for rollback

===Events===
====New Events====
*onBeforeRender
*onContentBeforeDelete
*onContentAfterDelete
*onContentChangeState
*onContentPrepareForm
*onContentPrepareFormData
*onExtensionBeforeInstall
*onExtensionBeforeUpdate
*onExtensionBeforeUninstall
*onExtensionAfterInstall
*onExtensionAfterUpdate
*onExtensionAfterUninstall

====Renamed Events====
*onContentAfterSave
*onContentAfterTitle
*onContentAfterDisplay
*onContentBeforeDisplay
*onContentBeforeSave
*onContentSearch
*onContentSearchAreas
*onUserAuthenticate
*onUserAfterDelete
*onUserAfterSave
*onUserBeforeDelete
*onUserBeforeSave
*onUserLogin
*onUserLogout
*All content events (except for search and search areas) now pass a 'context' as the first argument to alert the plugin as to what type of content is being passed. The plugin event may or may not heed this context.

===Categories===
*Component can provide custom options for its own categories via optional category.xml
*Supported via JTableNested

===Access Controls===
*A thing that can be controlled by permissions is registered in the assets table
*JTable handles this transparently via asset_id field
*For view permissions, support is as simple as adding
:::$user = JFactory::getUser();
:::$groups = implode(',', $user->authorisedLevels());
:::$query->where('a.access IN (' . $groups . ')');

For action permissions, same format as in 1.5:
$user->authorise($actionName, $assetName)
*OpenID library moved to plugin folder
*Geshi library moved to plugin folder
*JRegistry notes defaults to JSON (new format), dynamically converting existing data in INI format
*New JStream
*New JApplicationHelper::getComponentName
*Core icons moved to /media/
*Backward incompatible change to JEditor::display
*Added chaining support to JMail
*JFilterInput can no longer be called statically
*JHtml::image now supports relative paths
*All system images are overridable in the default template
*New JHtmlString
*Added wincache session handler for IIS
*New JFilterOutput::stripImages
*JPath::check takes second arg for separator (to pass to JPath::clean)
*Expanded configuration support through config.xml (multiple tabs)

====Core actions====
*core.login.site
*core.login.admin
*core.admin
*core.manage
*core.create
*core.edit
*core.edit.state
*core.delete
*Miscellaneous changes

===Debug Plugin===
*More tools for assisting with translation

===Mootools 1.2/1.3===
*Need to use document.id instead of $

==Cache changes ==
===API changes relevant to 3rd party developers===
====Component view cache====

Component view cache now takes an array of url parameters and their types to create Cacheid. This is a replacement for a previous unsafe way which took the whole URL for this and so opened the doors for DOS attacks via random url parameters added to request URL's.

Com_contact example:

<pre>
$safeurlparams = array(
'id'=>'INT',
'catid'=>'INT', 'limit'=>'INT',
'limitstart'=>'INT',
'filter_order'=>'CMD',
'filter_order_Dir'=>'CMD'
);

parent::display($cachable,$safeurlparams);
</pre>

Old cacheid created from URL was retained for backwards compatibility and takes effect if there are no $safeurlparams.

====Module cache====
This has been completly reconceptualized. Module cache now has 5 different modes of operation, 3 of them are to be set from module XML file, while 2 are meant to be used from within the module itself. Default is backwards compatible oldstatic mode that requires no changes to a module.

Modes to be set in XML:
*'''static''' - one cache file for all pages with the same module parameters
*'''oldstatic''' - 1.5. definition of module caching, one cache file for all pages with the same module id and user aid. Default for backwards compatibility
*'''itemid''' - changes on itemid change

In addition to cache field that was required in 1.5 there is now another hidden field called cachemode that sets any of the above modes.

<pre>
<field name="cachemode" type="hidden" label="" default="static">
<option value="static"></option>
</pre>

Modes to be called from inside the module:
*'''safeuri''' - id is created from $cacheparams->modeparams array, the same as in component view cache
*'''id''' - module sets own cache id's

To use this modes one must rename cache field in xml to owncache field and call JModuleHelper::ModuleCache from within the module's main php file. This is actually a shortcut to cache callback to avoid code duplication in every module.

An example that uses safeuri mode and replaces uncached
$list = modRelatedItemsHelper::getList($params) :

<pre>
$cacheparams = new stdClass;
$cacheparams->cachemode = 'safeuri';
$cacheparams->class = 'modRelatedItemsHelper';
$cacheparams->method = 'getList';
$cacheparams->methodparams = $params;
$cacheparams->modeparams = array('id'=>'int','Itemid'=>'int');
$list = JModuleHelper::ModuleCache ($module, $params, $cacheparams);
</pre>

====Functional changes====
'''Cache administration (Clean cache, Purge cache) now works with all drivers''', not only with file cache.
'''New standalone garbage collect script''' that is to be called from crontab has been added. It can be found in libraries/joomla/utilities/garbagecron.php . For safety reasons it is recommended that it is renamed it to something unique.

====CMS and framework level functional changes====
'''Caching is implemented in all components and modules''' that can potentially gain from cache.
Caching has also been added to some most expensive and frequent framework calls JComponentHelper::_load(), JModuleHelper::_load(),JMenuSite::load();

====Cache library changes====
Cache library has been completely refactored.
*Cache '''handlers have been renamed to controllers''' to better reflect their role and avoid confusion with cache storage handlers (referred to as drivers in following text).
*'''New JCacheController''' parent class has been added and inheritance has been changed to prevent bugs occurring from controller's and storage handler's get method clashes.

====JCache====
*'''getAll()''' method was added to JCache ,JCacheStorage and all drivers and it returns all cached items (this was previously possible only with file driver and hardcoded in administration)
*New '''lock and unlock''' methods were added to JCache, JCacheStorage and drivers. They enable cache item locking and unlocking to prevent errors on parallel accesses and double saves. This functionally was also implemented in controllers.
*Workarounds are now consolidated in new '''JCache getWorkarounds and setWorkarounds''' methods, are now used by all controllers and their use has been made optional.
*New makeId() method in JCache that creates cache id from registered url parameters set by components and system plugins

====JCacheController====
New parent class to Controllers that also functions as an intermediate to JCache. There is no JObject inheritance as otherwise magic __call doesn't work.
Change was needed to prevent bugs occurring from controller's and storage handler's get method clashes. They could be renamed but this would break backwards compatibility.

====JCacheStorage====
*_getCacheId method was moved from drivers to their parent JCacheStorage and all drives now use the same method by default
*CacheItem was moved from cache admin to framework JCacheStorageHelper , it is used by getAll
*There are new cachelite and wincache drivers. All other drivers have been fixed with missing functions (gc, clean) added, their code cleaned and tested they should be now working properly.
*Replaced separate _expire files in filecache driver with timestamps (this should amount to cca. 40% speed gain). The same in all drivers that had this.
*Numerous bugfixes on all levels, most important is proper use of options defaulting to configuration parameters settings and correctly passing from level to level.

====Other framework level changes====
*Safe url parameters registration added to JControler view method.
*New ModuleCache method in JModuleHelper that performs the above described module cache (in 5 modes) for both, modules and module renderer.
*JFactory::getFeedParser has been changed to use Joomla caching instead of simplepie's.

==Performance==
===Eliminate the usage of JTable for general browsing on the frontend===
*Session drops the usage of JTable
*Item views use a dedicated question, not JTable->load

==Known Issues==
*Still Mootools 1.2. Will be upgrading to 1.3 during the beta process.
*Scaling issues to address

==Notes==
===Releases===
*Alpha 1: 22 June 2009
*Alpha 2: 25 October 2009
*Beta 1: 18 May 2010
*Beta 2: 2 weeks after Beta 1

[[Category:Joomla! 1.6]]

J2.5:What's new in Joomla 2.5

2010-05-22T21:16:59Z

Dieter: /* Discover */

Lots of things.

...and:
* '''New Access Control System''' - Allows site administrators control over who can view and manage content.
* '''Unlimited Depth Organizational Model''' - Gives site administrators and content creators user-defined category levels that allow for the creation of a category tree with as many or as few levels for organizing articles and other content as needed.
* '''One-Click Extension Updates''' - Allows users to keep sites secure and controlled by simplifying the process of updating extensions.
* '''Semantic XHTML Layouts''' - Provides a better baseline for content presentation.

...and:

==Administrators==
===Introduction===
*Consistent UI
*Consistent Features
*Richer sample data
*IE 7+, Firefox 3.x, Safari 4.x
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)

===Administrator===
*Menu Changes
*Submenu consistency

====Toolbar Features====
*Save
*Save & Close
*Save & New
*Save as Copy
*Expired session will return to the page you were on then you got logged out (can be hit and miss)
*Most search filters allow you to search for a record id via [ id:123 ]
*"Parameters" are now referred to as "Options"
*Template Styles
*Integrated Trash Management
*Consistent archive support for most content
*Extension Installer Improvements

===Module Enhancements===
*Publish up and down
*Add option to display on all pages "except" selected
*Expanded Category System
*404 Page Redirection
*Better Menu Management
*Alternative layouts for content, modules and menus (taken from the home template)

===New Templates===
*Atomic
*Beez2
*(Administrator) Bluestork (replaces Khephri)
*(Administrator) Hathor
*Legacy layer in Milkyway
*Backend supports layout overrides
*New Modules
*New Plugins
*Content Languages
*User Login Permissions
*Activate selected users from the user list now (and filter)
*Administrator registration approval
*Polls component removed
*New codemirror editor

===SEO Improvements===
*Meta decription and keywords for categories
*Articles can change the page title and page header separately

===Global Configuration===
*Add site name to titles
*Default Access Level
*Set Metadata Language (buggy)
*Unicode Aliases
*Cookie domain and path
*User Setting moved to User Manager -> Options
*Media Settings moved to Media Manager -> Options
*Debug Modules - allows you to enabled to disable the tp=1 feature
*Server Timezone now a location, not an integer offset
*New Global Permissions tab

===User Manager===
*Can activate a user from the list now
*User can be assigned to multiple groups
*Manage user groups
*Manager content access levels

===Media Manager===
*Flash uploader fixed

===Menu Manager===
====Menus List====
*Rebuild button to press when you brick the menu
*Clicking the menu name brings up the menu items list rather than going into Edit Menu. To edit the menu, click on the check box next to the name and click on the Edit icon in the toolbar.

====Items List====
*Menus support the language filter
*Default now called Home
*Home is now clickable in the menu item list
*A separate home can be set for different languages

=====New batch operations=====
*Set access level
*Copy or move to another part of this or another menu

====Edit Item====
*Improved "Type" selector with human readable view and layout names
*Note field added
*New window target
*New Language assignment
*New Template style
*Ability to add & edit Module assignments from this page

=====New options for the menu links and pages themselves=====
*Link title attribute
*Link CSS style
*Menu image is changed to a modal selector
*CSS class for page heading
*Page meta description
*Page meta keywords
*Robots options

===Articles Manager===
*Frontpage is now referred to a Featured
*Article manager uses submenu to quickly skip between articles , categories and featured
*Sections and categories are now merged.

====Articles List====
*''"Missing move and copy; filter by author"''
*New column to show language
*Filtering by language available

====Article Edit====
*Created by user now selected by modal popup
*New ability to set the page title from the article
*Define create, delete, edit and publishing permissions

===Categories===
====Category List====
*Nested view
*Filtering on language

====Edit Category====
*New note field
*Section replaced with ability to assign a parent category
*Ability to assign content language

=====New Options (not previously available in 1.5)=====
*Assign alternate layout
*Define create, delete, edit and publishing permissions
*Meta description
*Meta keywords
*Alternative page title
*Meta author
*Meta robots

===Banners===
====Banners list====
*** Missing copy toolbar button
*New archive toolbar button
*New columns to show meta keywords, purchase type and language
*New filtering by client and language

====Edit Banner====
*New type toggle for Image or Custom (dynamically changes the available form fields)
*New alt text field for image
*New language field

=====New Options=====
*Ability to set the created date
*Ability to set start and finish publishing times
*Ability to set the purchase type
*Ability to track impressions
*Ability to track clicks
*Use own prefix ?
*Tags renamed to meta
*Contacts
*Messaging
*Newsfeeds
*Search
*Weblinks
*Redirect

===Extensions Manager===
====Discover====
*Module mgr
*Plugin Mgr
*Template Mgr
*Language mgr

===Misc===
*Auto create linked contact when creating new user ??

==Access Controls==
*Introduction
*User Groups
*Access Levels
*Permission Layers
*How Permissions are Inherited
*How to debrick your site

==Developers==
===Introduction===
*PHP 5.2.4+
*MySQL 5.0.4 (allows for wide varchars)
*IE7+, Firefox 3+, Safari 4+
*Focus on code consistency
*Focus on code reduction

Usage of PHP Native Functions where possible, for example:
*[[JXMLElement]] extends the native [http://php.net/manual/en/book.simplexml.php SimpleXML] class
*[[JDate]] extends the [http://www.php.net/manual/en/class.datetime.php DateTime] class
*Native INI parser to load languages

===Removed features===
*ADODB compatibility methods in database classes
*DOMIT (unsupported XML library)
*Legacy mode (includes global $mainframe, etc)
*JTemplate (based on patTemplate)
*patTemplate (templating engine)
*PDF support
*PEAR libraries (due to license incompatibilities)
*phpgacl
*PHP 4.0 and 5.0 compatibility files
*XStandard Editor

===Deprecated Features===
*JController::_acoSection
*JController::_acoSectionValue
*JController::authorize()
*JController::setAccessControl()
*JDatabase::stderr()
*JDate::offest
*JDate::setOffset()
*JDate::toFormat() - use JDate::format() instead
*JException::toString()
*JFactory::getXMLParser()
*JHtmlGird::access()
*JHtmlImage::administrator - use JHtml::image instead
*JHtmlImage::site - use JHtml::image instead
*JHtmlList::accesslevel()
*JHtmlList::specificordering() - use JHtml::_('list.ordering')
*JHtmlList::category()
*JHtmlSelect::optgroup() - see JHtmlSelect::groupedList()
*JLanguage::_parseLanguageFiles - renamed to parseLanguageFiles
*JLanguage::_parseXMLLanguageFile - renamed to parseXMLLanguageFile
*JLanguage::_parseXMLLanguageFiles - renamed to parseXMLLanguageFiles
*JObject::toString - replaced with magic method
*JRegistry::getNameSpaces()
*JRegistry::getValue()
*JRegistry::makeNameSpace()
*JRegistry::setValue()
*JPane - See JHtmlSliders
*JParameter - replaced by JForm
*JSimpleXML, JSimpleXMLElement - Use JXMLElement instead, based on the native SimpleXMLElement
*JTable::canDelete() - models or controllers should be doing the access checks
*JTable::toXML()
*JToolbarHelper customX(), addNewX(), editListX(), editHtmlX(), editCssX(), deleteListX()
*JUser::authorize() - Use JUser::authorise()
*JUtility::dump()
*JUtility::array_unshift_ref() - Not needed in PHP 5
*JUtility::getHash() - Use JApplication::getHash()
*JUtility::getToken() - Use JFactory::getSession()->getFormToken()
*JUtility::isWinOS() - Use JApplication::isWinOS()
*JUtility::return_bytes() - See InstallerModelWarnings::return_bytes()
*JUtility::sendMail() - Use JFactory::getMailer()->sendMail()
*JUtility::sendAdminMail() - Use JFactory::getMailer()->sendMail()
*JXMLElement::data() - Provided for backward compatibility
*JXMLElement::getAttribute() - Provided for backward compatibility

===Database===
*JTable now automatically looks up the fields from the database schema
*New JDatabaseQuery - A chained CRUD query builder
*New JDatabase::getNextRow
*New JDatabase::getNextObject
*JDatabase::loadAssocList - Now takes a second argument to just return the value of a column
*JDatabase::setQuery - Added chaining support

====Important Schema Changes====
*New jos_extensions table to list all extensions
*Components table information moved and split between jos_extensions and jos_menu (special menu called _adminmenu)

The old phpgacl (jos_core_acl*) and jos_groups tables have been reworked into:
*jos_assets
*jos_user_usergroup_map
*jos_usergroups
*jos_viewlevels
*Archived state changed from a value of -1 to +2

===Improved MVC===
====Models====
*JModelList
*JModelForm
*JModelAdmin
*Format handling (eg JSON)
*Sub-controller handling

====Controllers====
*JControllerForm
*JControllerAdmin
*JController::setMessage takes second arg to set the message type
*JController can set the default view
*Added chaining support to several JController methods

====Views====
*Semantic core output
*Milkyway legacy layouts
*The old component parameters are not automatically added to the menu anymore. You need to explicitly put them in the layout XML files.
*The menu manager will now detect additional layouts for a given view in the default template.

===Form API===
====Event manipulation====
*onContentPrepareForm
*onContentPrepareFormData

===Translation and Language Support===
*Support for unicode slugs, eg, SEF URL's with Greek characters
*3-letter languages now supported, xxx-XX
*All existing language keys have been refactored

====INI files must validate====
*Upper case key with no spaces, alphanumeric characters and underscores
*Quoted values
*Double quotes within literal strings must use _QQ_ in the form KEY="<a href="_QQ_"index.php"_QQ_">Click</a>"

====Javascript translation layer====
*See the flash uploader script for an example
Local extension language files

====Language file API====
*Pluralisation support
*Transliteration support for ASCII or Unicode slugs
*Ignore Search Words
*Minimum search word length
*Custom language overrides
*System language file to support administrator menu and installation (.sys.ini)

====Language switcher====
*Language Filter plugin enables language switching
*Sets the automatic filtering via JFactory::getApplication()->setLanguageFilter(true)
*A frontend component with language support would test JFactory::getApplication()->getLanguageFilter(), which returns the selected language code from the Languages Module
*The language field can be a language code for a single language, or "*" to be displayed for all languages
*Community extension for language maintenance com_localise

===Extension management===
====New installation types====
=====Libraries=====
*Must include an XML manifest where type="library"
*Can only be installed into a sub-folder of /libraries/
*Can extend parts of an existing library, eg /libraries/joomla/database/database/oracle.php

=====Packages multi-installer=====
*Must include an XML manifest where type="package"
*A package is a zip of zip's

New install script can be provided with 5 methods:
=====preflight=====
*Runs before anything is run and while the extracted files are in the uploaded temp folder

======Could allow for:======
*secondary extraction of custom zip's
*version checks to be performed
*halting the installer on an error

=====install / update=====
*Runs after the database scripts are executed
*If the extension is new, the install method is run
*If the extension exists then update method is run if method="upgrade", otherwise assumes that the extension is not meant to be upgradable

=====postflight=====
*Runs after the extension is registered in the database
*Is not run for the uninstall process (nothing left to do obviously)

====Discover====
*Does not do any file copying, only works with what it finds
*Performs preflight, install and postflight
*Developer of installer has two language files??

====Update site====
*Can publish an XML manifest on your site that can include individual extensions and extension sets.

====XML Manifest Changes====
*<install> is deprecated - use <extension>
*New <update> tag. Takes a <schemas> tag which can define <schemapath>
*<params> and <param> tags are deprecated, use <fields>, <fieldsets> and <field> instead

====File changes====
*Installation manifest must be the same name as the extension, eg com_foobar/foobar.xml This helps with discovery (otherwise the function has to go through all the files in the extension folder
*Plugins are now in folders like modules and components
*See SVN/tests/_data/installer_packages/ for complete examples of all extensions and manifests.
*The method="upgrade" will compare individual files in the original and incoming manifests and will remove files as appropriate. However, it will not remove differences in the <folder> tags.
*Future support for rollback

===Events===
====New Events====
*onBeforeRender
*onContentBeforeDelete
*onContentAfterDelete
*onContentChangeState
*onContentPrepareForm
*onContentPrepareFormData
*onExtensionBeforeInstall
*onExtensionBeforeUpdate
*onExtensionBeforeUninstall
*onExtensionAfterInstall
*onExtensionAfterUpdate
*onExtensionAfterUninstall

====Renamed Events====
*onContentAfterSave
*onContentAfterTitle
*onContentAfterDisplay
*onContentBeforeDisplay
*onContentBeforeSave
*onContentSearch
*onContentSearchAreas
*onUserAuthenticate
*onUserAfterDelete
*onUserAfterSave
*onUserBeforeDelete
*onUserBeforeSave
*onUserLogin
*onUserLogout
*All content events (except for search and search areas) now pass a 'context' as the first argument to alert the plugin as to what type of content is being passed. The plugin event may or may not heed this context.

===Categories===
*Component can provide custom options for its own categories via optional category.xml
*Supported via JTableNested

===Access Controls===
*A thing that can be controlled by permissions is registered in the assets table
*JTable handles this transparently via asset_id field
*For view permissions, support is as simple as adding
:::$user = JFactory::getUser();
:::$groups = implode(',', $user->authorisedLevels());
:::$query->where('a.access IN (' . $groups . ')');

For action permissions, same format as in 1.5:
$user->authorise($actionName, $assetName)
*OpenID library moved to plugin folder
*Geshi library moved to plugin folder
*JRegistry notes defaults to JSON (new format), dynamically converting existing data in INI format
*New JStream
*New JApplicationHelper::getComponentName
*Core icons moved to /media/
*Backward incompatible change to JEditor::display
*Added chaining support to JMail
*JFilterInput can no longer be called statically
*JHtml::image now supports relative paths
*All system images are overridable in the default template
*New JHtmlString
*Added wincache session handler for IIS
*New JFilterOutput::stripImages
*JPath::check takes second arg for separator (to pass to JPath::clean)
*Expanded configuration support through config.xml (multiple tabs)

====Core actions====
*core.login.site
*core.login.admin
*core.admin
*core.manage
*core.create
*core.edit
*core.edit.state
*core.delete
*Miscellaneous changes

===Debug Plugin===
*More tools for assisting with translation

===Mootools 1.2/1.3===
*Need to use document.id instead of $

==Cache changes ==
===API changes relevant to 3rd party developers===
====Component view cache====

Component view cache now takes an array of url parameters and their types to create Cacheid. This is a replacement for a previous unsafe way which took the whole URL for this and so opened the doors for DOS attacks via random url parameters added to request URL's.

Com_contact example:

<pre>
$safeurlparams = array(
'id'=>'INT',
'catid'=>'INT', 'limit'=>'INT',
'limitstart'=>'INT',
'filter_order'=>'CMD',
'filter_order_Dir'=>'CMD'
);

parent::display($cachable,$safeurlparams);
</pre>

Old cacheid created from URL was retained for backwards compatibility and takes effect if there are no $saferlparams.

====Module cache====
This has been completly reconceptualized. Module cache now has 5 different modes of operation, 3 of them are to be set from module XML file, while 2 are meant to be used from within the module itself. Default is backwards compatible oldstatic mode that requires no changes to a module.

Modes to be set in XML:
*'''static''' - one cache file for all pages with the same module parameters
*'''oldstatic''' - 1.5. definition of module caching, one cache file for all pages with the same module id and user aid. Default for backwards compatibility
*'''itemid''' - changes on itemid change

In addition to cache field that was required in 1.5 there is now another hidden field called cachemode that sets any of the above modes.

<pre>
<field name="cachemode" type="hidden" label="" default="static">
<option value="static"></option>
</pre>

Modes to be called from inside the module:
*'''safeuri''' - id is created from $cacheparams->modeparams array, the same as in component view cache
*'''id''' - module sets own cache id's

To use this modes one must rename cache field in xml to owncache field and call JModuleHelper::ModuleCache from within the module's main php file. This is actually a shortcut to cache callback to avoid code duplication in every module.

An example that uses safeuri mode and replaces uncached
$list = modRelatedItemsHelper::getList($params) :

<pre>
$cacheparams = new stdClass;
$cacheparams->cachemode = 'safeuri';
$cacheparams->class = 'modRelatedItemsHelper';
$cacheparams->method = 'getList';
$cacheparams->methodparams = $params;
$cacheparams->modeparams = array('id'=>'int','Itemid'=>'int');
$list = JModuleHelper::ModuleCache ($module, $params, $cacheparams);
</pre>

====Functional changes====
'''Cache administration (Clean cache, Purge cache) now works with all drivers''', not only with file cache.
'''New standalone garbage collect script''' that is to be called from crontab has been added. It can be found in libraries/joomla/utilities/garbagecron.php . For safety reasons it is recommended that it is renamed it to something unique.

====CMS and framework level functional changes====
'''Caching is implemented in all components and modules''' that can potentially gain from cache.
Caching has also been added to some most expensive and frequent framework calls JComponentHelper::_load(), JModuleHelper::_load(),JMenuSite::load();

====Cache library changes====
Cache library has been completely refactored.
*Cache '''handlers have been renamed to controllers''' to better reflect their role and avoid confusion with cache storage handlers (referred to as drivers in following text).
*'''New JCacheController''' parent class has been added and inheritance has been changed to prevent bugs occurring from controller's and storage handler's get method clashes.

====JCache====
*'''getAll()''' method was added to JCache ,JCacheStorage and all drivers and it returns all cached items (this was previously possible only with file driver and hardcoded in administration)
*New '''lock and unlock''' methods were added to JCache, JCacheStorage and drivers. They enable cache item locking and unlocking to prevent errors on parallel accesses and double saves. This functionally was also implemented in controllers.
*Workarounds are now consolidated in new '''JCache getWorkarounds and setWorkarounds''' methods, are now used by all controllers and their use has been made optional.
*New makeId() method in JCache that creates cache id from registered url parameters set by components and system plugins

====JCacheController====
New parent class to Controllers that also functions as an intermediate to JCache. There is no JObject inheritance as otherwise magic __call doesn't work.
Change was needed to prevent bugs occurring from controller's and storage handler's get method clashes. They could be renamed but this would break backwards compatibility.

====JCacheStorage====
*_getCacheId method was moved from drivers to their parent JCacheStorage and all drives now use the same method by default
*CacheItem was moved from cache admin to framework JCacheStorageHelper , it is used by getAll
*There are new cachelite and wincache drivers. All other drivers have been fixed with missing functions (gc, clean) added, their code cleaned and tested they should be now working properly.
*Replaced separate _expire files in filecache driver with timestamps (this should amount to cca. 40% speed gain). The same in all drivers that had this.
*Numerous bugfixes on all levels, most important is proper use of options defaulting to configuration parameters settings and correctly passing from level to level.

====Other framework level changes====
*Safe url parameters registration added to JControler view method.
*New ModuleCache method in JModuleHelper that performs the above described module cache (in 5 modes) for both, modules and module renderer.
*JFactory::getFeedParser has been changed to use Joomla caching instead of simplepie's.

==Performance==
===Eliminate the usage of JTable for general browsing on the frontend===
*Session drops the usage of JTable
*Item views use a dedicated question, not JTable->load

==Known Issues==
*Still Mootools 1.2. Will be upgrading to 1.3 during the beta process.
*Scaling issues to address

==Notes==
===Releases===
*Alpha 1: 22 June 2009
*Alpha 2: 25 October 2009
*Beta 1: 18 May 2010
*Beta 2: 2 weeks after Beta 1

[[Category:Joomla! 1.6]]

J1.5:How to add tooltips to your Joomla! website

2009-09-18T22:42:02Z

Dieter: /* Create a Tooltip Using a CSS Class Name */

{{review}}
===Tooltips Overview===
A tooltips is a piece of text that pops up when you hover the mouse over a region on a website. If you use the Joomla! back end, for example, tooltips are used to help explain the action of different parameters, as shown in the screenshot below:

[[Image:Screen_tooltip_example_20090208.png]]

Tooltips are a great way to give the user access to information without using up space on the screen. You can use basic tooltips just by adding a "title" attribute to a tag. However, this doesn't give you the option to style the tooltips. With Joomla! version 1.5, it is very easy to add styled tooltips to your site. This tutorial will show you how. <blockquote>''Note: If you are converting old code, make sure it doesn't use the prototype.js file. That file will keep the tooltips from working.''</blockquote>

===Activate Tooltip Behavior===
To start, you must activate the tooltip behavior. This is done with the following line of code:
<source lang="php">
JHTML::_('behavior.tooltip');
</source>
Note that you only put this line in once per file. A good place is right after the <code>defined('_JEXEC') or die('Restricted access');</code> line. If you are curious about what this line does, it inserts the following JavaScript code in the heading of the HTML page:
<source lang="html4strict">
<script type="text/javascript">
window.addEvent('domready', function(){
var JTooltips = new Tips($$('.hasTip'),
{ maxTitleChars: 50, fixed: false});
});
</script>
</source>
This allows tooltips to function, as outlined below.

===Create a Tooltip with the JHTML::tooltip Method===
One way to create a tooltip is using the JHTML::tooltip method. The API documentation is available at [http://api.joomla.org/Joomla-Framework/HTML/JHTML.html#tooltip http://api.joomla.org/Joomla-Framework/HTML/JHTML.html#tooltip]. The method definition is shown below.
<source lang="php">
void tooltip (string $tooltip, [string $title = ''], [string $image = 'tooltip.png'],
[string $text = ''], [string $href = ''], [boolean $link = 1])
</source>
The brackets mean the parameter is optional. The first parameter, "$tooltip", is the only required parameter. The equals specifies the default if you do not pass that parameter. For example, the image file 'tooltip.png' is the default image.

The following is a basic tooltip. Keep in mind that the image variable must be in reference to 'includes/js/ThemeOffice'. Use the prefix '../../../' to reference from the root of the Joomla installation.
<source lang="php">
JHTML::tooltip('This is the tooltip text', 'Tooltip title', 'tooltip.png', '',
'http://www.joomla.org');
</source>
The above will make a tooltip using the default "tooltip.png" image, as shown below.[[Image:Tooltip_tutorial_example_screenshot_20090208.png|center|frame]]Clicking the image will take you to <tt>http://www.joola.org</tt>, since that is the "$href" argument. The HTML source for this tooltip is as follows:
<source lang="html4strict">

<a href="http://www.joomla.org">
<img src="/my_joomla_path/includes/js/ThemeOffice/tooltip.png" border="0" alt="Tooltip"/></a>

</source>

<blockquote>''Internet Explorer Bug: As shown above, when you use the JHTML::tooltip method to create an image tooltip, it creates an "alt" attribute with the value "Tooltip". The "alt" attribute is used in cases where the image file cannot be found or for accessibility (for example, for blind users). Internet Explorer automatically -- and incorrectly -- displays the "alt" attribute as a tooltip. This means that image tooltips created by JHTML::tooltip (like the example above) will display with two tooltips when viewed with Internet Explorer, as shown below.''</blockquote>
[[Image:Tooltip_tutorial_ie7bug_20090301.png|center|frame]]
<blockquote>''You can avoid this problem either by using text tooltips or by not using this method for image tooltips. Instead, just enter the HTML manually and set the "alt" attribute to an empty string (alt="").''</blockquote>

This code is almost the same as above except the image will not be a link (because the "$href" argument is omitted).
<source lang="php">
JHTML::tooltip('This is the tooltip text', 'Tooltip title',
'tooltip.png', '', '', false);
</source>

A tooltip can be attached to an image or to text. For example, this code
<source lang="php">
echo JHTML::tooltip('This is a tooltip attached to text', 'Text Tooltip Title',
'', 'Hover on this text to see the tooltip');
</source>
will show a tooltip attached to text, as shown below.

[[Image:Tooltip_tutorial_example_screenshot2_20090208.png|center|frame]]

Note that specifying the "$text" parameter will override any image you have passed to tooltip.

===Create a Tooltip Using a CSS Class Name===
If we look at the HTML page source generated by the <code>JHTML::tooltip</code> function above, here is what we see:
<source lang="html4strict">

Hover on this text to see the tooltip
</source>
This function generates an HTML "span" tag with the classes "editlinktip" and "hasTip" and an attribute called "title". Notice that the the "title" attribute has two parts, <code><tooltip title>::<tooltip text></code> (for example, "Tooltip Title::This is the tooltip text"). You can create a tooltip with only text or with only a title. The title has implications for styling, as we'll see below.

The Javascript inserted by the <code>JHTML::('behavior_tooltip')</code> command we entered earlier picks up this tag based on the class called "hasTip". So, a second way of creating a tooltip is to simply create a tag with a class called "hasTip" and an attribute of "title". For example, this code
<source lang="html4strict">

Hover on this text to see the tooltip
</source>
will produce exactly the same effect as the <code>JHTML::tooltip()</code> example above.

===Adding CSS Styling to the Tooltip===
The default tooltips, whether using the JHTML::tooltip method or class method, use the following three CSS classes: <tt>.tool-tip</tt>, <tt>.tool-title</tt>, and <tt>.tool-text</tt>.

Here are the default styles.
<source lang="css">
/* Tooltips */
.tool-tip {
float: left;
background: #ffc;
border: 1px solid #D4D5AA;
padding: 5px;
max-width: 200px;
}

.tool-title {
padding: 0;
margin: 0;
font-size: 100%;
font-weight: bold;
margin-top: -15px;
padding-top: 15px;
padding-bottom: 5px;
background: url(../images/selector-arrow.png) no-repeat;
}

.tool-text {
font-size: 100%;
margin: 0;
}
</source>

If you have a custom CSS file, copy this code and alter it to your liking. Note that the <tt>.tool-title</tt> class uses by default the "selector-arrow.png" image. This is what gives the outline of the tooltip the little pointer in the upper left of the tooltip box. If you leave out a title in your tooltip, you will just get a rectangle, without the pointer.

===Customizing Your Yooltips===
Ok, now it's time to have some fun. The <code>JHTML::_('behavior.tooltip')</code> can take two optional parameters. The first parameter is the name of the CSS class that will be used to identify the tooltip. As we saw earlier, this defaults to "hasTip". The second optional parameter is an array of parameters that you can use to fine-tune the tooltip functionality. These are explained below.
* '''maxTitleChars:''' The maximum length of the title (the part of the "title" attribute before the "::")
* '''showDelay, hideDelay:''' The time to delay showing or hiding the tooltip, in milliseconds. Default is 100.
* '''className:''' The first part of the class name used to style the actual tooltip. The default, as we saw, is "tool", and the full class names by default are "tool-tip", "tool-title', and "tool-text". So, for example, if we set this to "custom", we would style the classes "custom-tip", "custom-title", and "custom-text".
* '''fixed:''' Whether or not to have the tooltip move with the mouse. If set to "true", the tooltip will be centered below the text or image. If set to "false", the tooltip will move with the mouse. Default is "false".
* '''onShow, onHide:''' Functions to call for the onShow and onHide events. We'll see an example below where we can use these to create a fade-in and fade-out for the tooltip.

In the next section, we'll show how to use these parameters with some examples.

===Tooltip With Different Classes===
In this example, we will create a tooltip using different selector and tooltip styling classes. Why might we want to do this? One reason would be if we had different types of tooltips and we wanted to style them differently.

Here is the code to create the tooltip Javascript function:
<source lang="php">
$toolTipArray = array('className'=>'custom2');
JHTML::_('behavior.tooltip', '.hasTip2', $toolTipArray);
</source>
In this code, we are creating an array with just one element -- to set the "className" parameter to "custom2". This means that, to style these tooltips, we would use the classes <tt>custom2-tip</tt>, <tt>custom2-title</tt>, and <tt>custom2-text</tt>. Then we call the method with the arguments ".hasTip2" and the array "$toolTipArray". It can be a little confusing, because we have two CSS classes at work here. The class ".hasTip2" is used in the HTML tag. That is how the Javascript program identifies the tooltips to operate on. The class "custom2" is used as the first part of the three CSS classes to use to style the actual tooltip itself.

To use this new tooltip, we could use the following code:
<source lang="html4strict">

hasTip2 and custom2 example
</source>
Since we set the class to "hasTip2", this tag will be processed by the new version of the tooltip program. So, if we use both the default tooltip ("hasTip" class) and the new tooltip ("hasTip2" class) in the same page, we can style them differently using "tool-" styles for the default and "custom2-" styles for the "hasTip2" tooltips.

Next, let's look at a more complex example, shown below.
<source lang="php">
$toolTipArray = array('className' => 'custom2', 'showDelay'=>'500',
'hideDelay'=>'500', 'fixed'=>true,
'onShow'=>"function(tip) {tip.effect('opacity',
{duration: 500, wait: false}).start(0,1)}",
'onHide'=>"function(tip) {tip.effect('opacity',
{duration: 500, wait: false}).start(1,0)}");
JHTML::_('behavior.tooltip', '.hasTip2', $toolTipArray); ?>
</source>
Again, we are building an array to pass to the <code>JHTML::_('behavior.tooltip')</code> function. Again, we are setting the "className" parameter to "custom2". We are also setting the "showDelay" and "hideDelay" parameters to 500 milliseconds (.5 seconds). So the tooltip will show only after the mouse has hovered for this amount of time.

Notice that we are setting the parameter "fixed" to "true" (without the quotes). This means that the tooltip will not move with the mouse. Instead, it will always show centered below the tooltip text or image.

Finally, the tricky part. We are creating functions to pass in to the "onShow" and "onHide" events. These functions cause the tooltip to fade in and fade out over the space of 500 milliseconds. This is done by gradually varying the tooltip's CSS "opacity" style from "0" (completely transparent) to "1" (completely opaque). If we wanted the tooltip to be partially transparent, we could change these to <code>start(0,.8)</code> and <code>start(.8,0)</code>.

These functions are similar to the sample code in the [http://demos111.mootools.net/Tips MooTools demo tutorial]. Click on the link called "js code" and look at the code for the "Tips2" demo. We have just taken the code from the initialize function and incorporated it into the "onShow" and "onHide" functions.

The last line of code above creates the actual Javascript code in our Joomla! document. If we show the page and view source, we see the following:
<source lang="javascript">
window.addEvent('domready', function(){
var JTooltips = new Tips($$('.hasTip2'), {
maxTitleChars: 50, showDelay: 500, hideDelay: 500, className: 'custom2',
fixed: true,
onShow: function(tip) {tip.effect('opacity', {duration: 500, wait: false}).start(0,1)},
onHide: function(tip) {tip.effect('opacity', {duration: 500, wait: false}).start(1,0)}
});
});
</source>
So we can see the effect of the parameters that we passed to the <code>JHTML::_('behavior.tooltip')</code> method.

'''offsets Parameter'''
<blockquote>''Note: The "offsets" parameter doesn't work in version 1.5.9 and earlier because of a bug. As of version 1.5.10 it should work as outlined below.''</blockquote>
You can control the x and y distance, in pixels, from the cursor to the tooltip using the "offsets" parameter. This parameter must be an array as shown in the example code below:
<source lang="php">
// set x (horizontal) distance to 20 pixels, y (vertical) distance to 30 pixels
$toolTipArray = array('offsets'=>array('x'=>20, 'y'=>30), 'maxtitlechars'=>40);
JHTML::_('behavior.tooltip', '.customOffset', $toolTipArray);
</source>

===Using an External Javascript File===
There are times when you might prefer to work with a separate Javascript file. This gives you complete flexibility to use all of the mootools capabilities. To do this:
# Create the separate Javascript file and save it somewhere in your Joomla! site (for example, "templates/<your template>/js/yourjsfile.js".
# Use the <code>JHTML::script</code> function to add this script to your document. For example:
<source lang="php">
$filename = 'testtooltip.js'; // this file is used for class="hasTip3" titles
$path = 'templates/rhuk_milkyway/js/'; // path to the file
// true means MooTools will load if it is not already loaded
JHTML::script($filename, $path, true);
</source>
This will load your script into the document and make sure that the MooTools library is available.

===Complete Code Example===
Here is an example that incorporates all of the elements discussed in this tutorial. So you can see the code in action, we will create an override of the "mod_stats" Module and add our test code there. We will use the rhuk_milkyway template.

To set up the template override, create a folder called "templates/rhuk_milkyway/html/mod_stats" and copy the file "modules/mod_stats/tmpl/default.php" to this new folder.

After line 2 of this file (<code>defined('_JEXEC') or die('Restricted access');</code>), insert the following:
<source lang="php">
JHTML::_('behavior.tooltip');
$toolTipArray = array('className' => 'custom2', 'showDelay'=>'500', 'hideDelay'=>'500',
'fixed'=>'true'
, 'onShow'=>"function(tip) {tip.effect('opacity',
{duration: 500, wait: false}).start(0,1)}"
, 'onHide'=>"function(tip) {tip.effect('opacity',
{duration: 500, wait: false}).start(1,0)}");
JHTML::_('behavior.tooltip', '.hasTip2', $toolTipArray); // class="hasTip2" titles
$filename = 'testtooltip.js'; // used for class="hasTip3" titles
$path = 'templates/rhuk_milkyway/js/';
JHTML::script($filename, $path, true); // MooTools will load if it is not already loaded
</source>
Here we are creating the Javascript functions we will need later. The first line is the simple default declaration that will use the ".hasTip" and "tool-" CSS classes.

The next 5 lines create the more customized function that includes the fade-in and fade-out. It uses the ".hasTip2" to create the tip and the classes starting with "custom2-" to style the tooltip.

The last 3 lines reference the external Javascript file, which will be created below. The class information will be contained in that file.

Now, time for some more coding. At the end of the "modules/mod_stats/tmpl/default.php" file, add the code shown below:
<source lang="php">
<h1>Tooltip Examples</h1>
<?php echo JHTML::tooltip('This is the tooltip text', 'Tooltip title',
'tooltip.png', '', 'http://www.joomla.org');?>
 
<?php echo JHTML::tooltip('This is a tooltip attached to text', 'Text Tooltip Title',
'', 'Hover on this text to see the tooltip');?>
 
<a class="hasTip" title="My Title::Tooltip on 'a' tag text using default 'hasTip' class"
href="http://www.joomla.org">Tooltip on a link example</a>
 

hasTip2 and custom2 example
 

hasTip3 hover text
 
</source>
The first two examples using the <code>JHTML::tooltip</code> function to create the tooltip HTML code.

The third example shows an "a" tag with a tooltip. This illustrates that you can put tooltips on most HTML tags, not just "span" tags. Again, it is using the "hasTip" class, so it will be controlled by the Javascript above called with the ".hasTip" argument and will be styled with the default "tool-" styles.

The fourth example shows a "span" tag using the "hasTip2" class. So it will be styled using the "custom2-" classes and will have the "showDelay" and "hideDelay" of 500 milliseconds and have "fixed" equal to "true" (so the tip will not move with the mouse). Also, it uses the special fade-in and fade-out effects.

The last example will use the Javascript code from the external file, shown below.

Now, some more coding. Create a JavaScript file called "testtooltip.js" and save it into the folder "templates/rhuk_milkyway/js":
<source lang="javascript">
window.addEvent('domready', function(){
//do your tips stuff in here...
var zoomTip = new Tips($$('.hasTip3'), {
className: 'custom3', //this is the prefix for the CSS class
offsets: {
'x': 20, //default is 16
'y': 30 //default is 16
},
initialize:function(){
this.fx = new Fx.Style(this.toolTip, 'opacity',
{duration: 1000, wait: false}).set(0);
},
onShow: function(toolTip) {
this.fx.start(0,.8);
},
onHide: function(toolTip) {
this.fx.start(.8,0);
}
});
});
</source>
This code will operate on the "hasTip3" class and will use style classes starting with "custom3-". We are setting the x distance (from the cursor to the tooltip) to 20 pixels and the y distance to 30 pixels. This also has the fade-in and fade-out functionality, but the final "opacity" value is set to .8, meaning that the tooltip will be slightly transparent.

Finally, add this to the end of your "templates/rhuk_milkyway/css/template.css" file:
<source lang="css">
.custom2-tip {
color: #000;
width: 130px;
z-index: 13000;
}

.custom2-title {
font-weight: bold;
font-size: 11px;
margin: 0;
color: #024A68;
padding: 8px 8px 4px;
background: #3CA0D0;
border-bottom: 1px solid #024A68;
}

.custom2-text {
font-size: 11px;
padding: 4px 8px 8px;
background: #63ADD0;
}

.custom3-tip {
color: #000;
width: 130px;
z-index: 13000;
}

.custom3-title {
font-weight: bold;
font-size: 11px;
margin: 0;
color: #3E4F14;
padding: 8px 8px 4px;
background: #C3DF7D;
border-bottom: 1px solid #B5CF74;
}

.custom3-text {
font-size: 11px;
padding: 4px 8px 8px;
background: #CFDFA7;
}
</source>
Here we are just adding different colors for the "custom2-" and "custom3-" styles so you can see the effect of the different tooltip code.

Notice that <tt>.custom2-title</tt> and <tt>.custom3-title</tt> classes do not have a background property. So these tooltips will be a box without the neat little arrow pointing at the mouse. If you wanted, you could create an image similar to "templates/system/images/selector-arrow.png" of the right color and add that as a background to these classes.

===Example Code Screenshots===
Here are some screenshots taken from the sample code above. The first screenshot shows the modified "mod_stats" modules with our sample code.
[[Image:Screen_tooltip_example2_20090210.png|center|frame]]
The screenshot below shows the fade-in effect for the ".hasTip2" tooltip. Notice also that the tooltip is centered below the text. This is the effect of setting "fixed" equal to "true".
[[Image:Screen_tooltip_example1_20090209.png|center|frame]]
The last screenshot shows the different styling for the ".hasTip3" tooltip, based on the "custom3-" CSS class styles.
[[Image:Screen_tooltip_example3_20090210.png|center|frame]]

===More Information===
More information about the topics covered in this tutorial is available at the links below. Note that Joomla! version 1.5 uses MooTools version 1.11. The current version of MooTools is 1.2.
* Joomla API - [http://api.joomla.org http://api.joomla.org]
* Documentation for 1.11 MooTools Tips: [http://docs111.mootools.net/Plugins/Tips.js http://docs111.mootools.net/Plugins/Tips.js]
* Mootools demos for version 1.11 - [http://demos111.mootools.net/Tips http://demos111.mootools.net/Tips]
* Mootools Website - [http://www.mootools.net/ http://www.mootools.net/]

[[Category:Development]]

Localisation

2008-01-24T22:19:09Z

Dieter: /* The challenges and the solutions */

{{review}}

== Implementation of UTF-8 in Joomla! 1.5 ==

''This text is based on an article rewritten by former core team member David Gal for a German Linux publication.''

UTF-8 is a variable length character encoding using one to four bytes per character, depending on the Unicode symbol. Four bytes may seem like a lot for one character, however, this is required only for special characters outside the Basic Multilingual Plane, which are generally very rare. The first byte (positions 0-127) is used for encoding ASCII which gives the character set full backward compatibility with ASCII.

UTF-8 is becoming the standard and internationally accepted multilingual environment and is the preferred way to communicate non-ASCII characters over the Internet. Being a subset of Unicode, UTF-8 has the special benefit of using less space to store or transmit ASCII. As the bulk of Internet transmissions are using the 7 bit ASCII characters, UTF-8 encoding saves volume and bandwidth.

It also provides a single encoding for all other characters that were previously implemented using 8 bit character codes hand-in-hand with a specific encoding table (i.e iso-8859-2) in order to know how to represent the character code. Up to now this basically limited Web page display to ASCII Latin characters plus one other language or set of diacritic Latin characters (accents and umlauts for example). UTF-8 now provides one code page for all languages.

Migration to UTF-8 promises to be simple for existing ASCII texts as UTF-8 encoding for ASCII has no changes.

=== Implementing in Joomla! – a bit more than setting encoding to ‘utf-8’ ===

Up to now in order to change from one encoding to another all that was required was to change the _ISO definition in the language file resulting in the ‘charset=myNewEncoding’ statement in the html meta tag. This was simple as all encodings were single-byte character encodings. For the entire Joomla! system, a character equals a byte and Joomla! didn’t really care what the character representation of the particular byte is.

Now, in Joomla! 1.5, we are starting to use multi-byte characters and not only that – some are one byte long and some are 3 bytes long. How does this affect Joomla! and what is required to truly be able to state that Joomla! supports UTF-8?

=== There are four affected areas: ===

# The database needs to support utf-8 data storage. For example: a text field of type varchar was given a length of 20 with the intention of being able to store up to 20 characters – which also meant 20 bytes. Now, with UTF-8, 20 characters might mean between 20 and 60 bytes. The database needs to be able to adjust accordingly. Fortunately MySQL version 4.1.2 and up, support UTF-8.
# The connection between the Joomla! application and the database needs to know the encoding of the data in order to know whether encoding translation is required. (There are cases where the application uses one encoding and the database uses another).
# The html page needs to know which encoding it carries. This is trivial and all that is required is that the html meta tags will show that the encoding is ‘utf-8’.
# Joomla’s PHP string handling functions need to be UTF-8 aware. This is not at all trivial as PHP’s regular string functions are all single-byte aware and a special set of functions is needed.

=== The challenges and the solutions ===

The first major challenge was the fact that there are still many hosts that are running MySQL version 4.0.x and older databases. These do not have UTF-8 support. It is possible to store UTF-8 data in non UTF-8 tables. As far as the database is concerned it is storing bytes and returning them to the application when needed.

However, as already mentioned, there is a possibility that the user will want to store a 20 character field that holds UTF-8 characters that are not in the regular ASCII area. If these are committed to a varchar (20) database field – the data will be truncated. This is not only a problem with non “Latin character�? languages (that are normally in the multi-byte area) but also with all European languages with possible the exception of English. Every one of these languages has some special Latin characters (accents and umlauts for example) that are now multi-byte characters. The word ‘käse’ is now 5 bytes long!

The core team rightfully decided that Joomla! 1.5 should also be able to work on older databases and not only that – the backward compatibility should be transparent to the user. The installer now checks for the version of MySQL – if it is version 4.1.2 and up, then UTF-8 tables are created with the user being able to choose the desired collation. If the database is not supporting UTF-8 then the installer actually runs a separate script creating a database structure that provides extra storage space for potentially longer strings. This is anticipated to eliminate the danger of data truncation by the database.

The second major challenge relates to the lack of UTF-8 support in PHP. All standard string functions in PHP are only able to work with single-byte characters. Using these functions on UTF-8 encoded data can result in logical failures and also in data corruption.

The problem lies with the fact that until PHP 6 is released, there is no comprehensive native UTF-8 support in PHP. There is a multi-byte extension named ‘mbstring’ which exists from version 4.1 but it is not loaded by default. In addition it also serves other multi-byte encodings such as some Far Eastern languages. This means that it may be present but not set to the correct settings for UTF-8. An additional extension named ‘iconv’, which has some parallel capability, is present in PHP 5 but optional and missing some functions in PHP 4.

Here again, the core team decided to vote for full backward compatibility and for the solution to be transparent to the user. The solution is a combination of either using PHP provided functions, if they are present, or using a special library of UTF-8 aware string functions, if no PHP native functions are available. This provides the best performance (PHP functions available) together with complete backward compatibility. A Joomla String Class provides this functionality and it will be included in the API for third party developers.

There is no user configuration or setup required regarding PHP UTF-8 support. There is one small exception to this rule which could theoretically occur if, in the host, one or two of the mbstring settings (that cannot be changed from within code) are set to a value that is adverse to UTF-8. The installer will identify this and advise on how to change the setting locally using .htaccess.

=== Migration ===

Considering that data will, in most cases, need to be converted to UTF-8, it will be recommended to migrate existing data to a freshly installed Joomla! 1.1 site and not to perform upgrades of existing Joomla! 1.0.x sites. Specific migration guidance will be provided with the release.

=== The quantum jump ===

Joomla! 1.5 will take a huge jump ahead of the rest of the CMS pack with its Internationalisation features. UTF-8 is undoubted, the big discriminator – all languages with one encoding. In addition, RTL support and the language packs for back-end, installer and help system, make Joomla! 1.5 a complete package for use in any language or combination of languages. JoomFish will be the icing on the cake.

== Language codes - RFC 3066 ==

Providing decent localisation support for Joomla - the kind of support that will carry smoothly across to the work of all extension providers (from language packs to components, modules and plugins), requires a certain amount of attention to some nitty gritty details. A questions that pops up are: “How do we identify a language?” - followed by: “How do we provide a consistent naming convention?” and: “How will everyone know about this?”

Simple - we need a convention - preferably public - hopefully without ambiguity - and it should be kept current.

A little bit of digging unearthed RFC 3066 and a decision was made to use it as the convention for language identification in Joomla as of version 1.5.

This results in the following conventions for the language names :
# The delimiter between the subtags should be the HYPHEN / MINUS character and not the UNDERSCORE character
# The first tag with the language tag (based on ISO 639) should use the TWO letter code for a language and not the THREE letter code. The THREE letter code may only be used if a TWO letter code does not exist for the language

Localisation

2008-01-24T15:56:00Z

Dieter: /* The challenges and the solutions */

{{review}}

== Implementation of UTF-8 in Joomla! 1.5 ==

''This text is based on an article rewritten by former core team member David Gal for a German Linux publication.''

UTF-8 is a variable length character encoding using one to four bytes per character, depending on the Unicode symbol. Four bytes may seem like a lot for one character, however, this is required only for special characters outside the Basic Multilingual Plane, which are generally very rare. The first byte (positions 0-127) is used for encoding ASCII which gives the character set full backward compatibility with ASCII.

UTF-8 is becoming the standard and internationally accepted multilingual environment and is the preferred way to communicate non-ASCII characters over the Internet. Being a subset of Unicode, UTF-8 has the special benefit of using less space to store or transmit ASCII. As the bulk of Internet transmissions are using the 7 bit ASCII characters, UTF-8 encoding saves volume and bandwidth.

It also provides a single encoding for all other characters that were previously implemented using 8 bit character codes hand-in-hand with a specific encoding table (i.e iso-8859-2) in order to know how to represent the character code. Up to now this basically limited Web page display to ASCII Latin characters plus one other language or set of diacritic Latin characters (accents and umlauts for example). UTF-8 now provides one code page for all languages.

Migration to UTF-8 promises to be simple for existing ASCII texts as UTF-8 encoding for ASCII has no changes.

=== Implementing in Joomla! – a bit more than setting encoding to ‘utf-8’ ===

Up to now in order to change from one encoding to another all that was required was to change the _ISO definition in the language file resulting in the ‘charset=myNewEncoding’ statement in the html meta tag. This was simple as all encodings were single-byte character encodings. For the entire Joomla! system, a character equals a byte and Joomla! didn’t really care what the character representation of the particular byte is.

Now, in Joomla! 1.5, we are starting to use multi-byte characters and not only that – some are one byte long and some are 3 bytes long. How does this affect Joomla! and what is required to truly be able to state that Joomla! supports UTF-8?

=== There are four affected areas: ===

# The database needs to support utf-8 data storage. For example: a text field of type varchar was given a length of 20 with the intention of being able to store up to 20 characters – which also meant 20 bytes. Now, with UTF-8, 20 characters might mean between 20 and 60 bytes. The database needs to be able to adjust accordingly. Fortunately MySQL version 4.1.2 and up, support UTF-8.
# The connection between the Joomla! application and the database needs to know the encoding of the data in order to know whether encoding translation is required. (There are cases where the application uses one encoding and the database uses another).
# The html page needs to know which encoding it carries. This is trivial and all that is required is that the html meta tags will show that the encoding is ‘utf-8’.
# Joomla’s PHP string handling functions need to be UTF-8 aware. This is not at all trivial as PHP’s regular string functions are all single-byte aware and a special set of functions is needed.

=== The challenges and the solutions ===

The first major challenge was the fact that there are still many hosts that are running MySQL version 4.0.x and older databases. These do not have UTF-8 support. It is possible to store UTF-8 data in non UTF-8 tables. As far as the database is concerned it is storing bytes and returning them to the application when needed.

However, as already mentioned, there is a possibility that the user will want to store a 20 character field that holds UTF-8 characters that are not in the regular ASCII area. If these are committed to a varchar (20) database field – the data will be truncated. This is not only a problem with non “Latin character�? languages (that are normally in the multi-byte area) but also with all European languages with possible the exception of English. Every one of these languages has some special Latin characters (accents and umlauts for example) that are now multi-byte characters. The word ‘käse’ is now 5 bytes long!

The core team rightfully decided that Joomla! 1.5 should also be able to work on older databases and not only that – the backward compatibility should be transparent to the user. The installer now checks for the version of MySQL – if it is version 4.1.2 and up, then UTF-8 tables are created with the user being able to choose the desired collation. If the database is not supporting UTF-8 then the installer actually runs a separate script creating a database structure that provides extra storage space for potentially longer strings. This is anticipated to eliminate the danger of data truncation by the database.

The second major challenge relates to the lack of UTF-8 support in PHP. All standard string functions in PHP are only able to work with single-byte characters. Using these functions on UTF-8 encoded data can result in logical failures and also in data corruption.

The problem lies with the fact that until PHP 6 is released, there is no comprehensive native UTF-8 support in PHP. There is a multi-byte extension named ‘mbstring’ which exists from version 4.1 but it is not loaded by default. In addition it also serves other multi-byte encodings such as some Far Eastern languages. This means that it may be present but not set to the correct settings for UTF-8. An additional extension named ‘iconv’, which has some parallel capability, is present in PHP 5 but optional and missing some functions in PHP 4.

Here again, the core team decided to vote for full backward compatibility and for the solution to be transparent to the user. The solution is a combination of either using PHP provided functions, if they are present, or using a special library of UTF-8 aware string functions, if no PHP native functions are available. This provides the best performance (PHP functions available) together will complete backward compatibility. A Joomla String Class provides this functionality and it will be included in the API for third party developers.

There is no user configuration or setup required regarding PHP UTF-8 support. There is one small exception to this rule which could theoretically occur if, in the host, one or two of the mbstring settings (that cannot be changed from within code) are set to a value that is adverse to UTF-8. The installer will identify this and advise on how to change the setting locally using .htaccess.

=== Migration ===

Considering that data will, in most cases, need to be converted to UTF-8, it will be recommended to migrate existing data to a freshly installed Joomla! 1.1 site and not to perform upgrades of existing Joomla! 1.0.x sites. Specific migration guidance will be provided with the release.

=== The quantum jump ===

Joomla! 1.5 will take a huge jump ahead of the rest of the CMS pack with its Internationalisation features. UTF-8 is undoubted, the big discriminator – all languages with one encoding. In addition, RTL support and the language packs for back-end, installer and help system, make Joomla! 1.5 a complete package for use in any language or combination of languages. JoomFish will be the icing on the cake.

== Language codes - RFC 3066 ==

Providing decent localisation support for Joomla - the kind of support that will carry smoothly across to the work of all extension providers (from language packs to components, modules and plugins), requires a certain amount of attention to some nitty gritty details. A questions that pops up are: “How do we identify a language?” - followed by: “How do we provide a consistent naming convention?” and: “How will everyone know about this?”

Simple - we need a convention - preferably public - hopefully without ambiguity - and it should be kept current.

A little bit of digging unearthed RFC 3066 and a decision was made to use it as the convention for language identification in Joomla as of version 1.5.

This results in the following conventions for the language names :
# The delimiter between the subtags should be the HYPHEN / MINUS character and not the UNDERSCORE character
# The first tag with the language tag (based on ISO 639) should use the TWO letter code for a language and not the THREE letter code. The THREE letter code may only be used if a TWO letter code does not exist for the language