Joomla! Documentation - User contributions [en]

Archived:Upgrading a Joomla 1.5 template to Joomla 2.5

2012-06-28T14:00:03Z

Drewgg: changed typo in code: type=" to type=""

{{RightTOC}}
This page provides feedback on the process of upgrading or converting a Joomla 1.5 template for use with Joomla 1.6 and later versions from those who have already attempted it. This is intended to be a living document that can be added to as more experience is gained and is likely to be reorganised periodically. If you have encountered a problem when upgrading a template, or if you have any information that you think will help smooth the way for others who will follow then please add your comments initially on the Talk page. We will then collate the information and incorporate it into this page.

[[User:Chris Davenport|Chris Davenport]] prepared [http://www.slideshare.net/chrisdavenport/template-changes-for-joomla-16 slides for a presentation at the JoomlaDay UK 2010 event] which explain the changes in templates for Joomla! 1.6.

== Template Manifest File ==
There are important changes to the ''templateDetails.xml'' file:
# Add the new 1.6 Doctype
# Change the ''<install>'' tag to ''<extension>'' as shown below.
<pre>
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE install PUBLIC "-//Joomla! 1.6//DTD template 1.0//EN" "http://www.joomla.org/xml/dtd/1.6/template-install.dtd">
<extension version="1.7" type="template" client="site">
</pre>
Notice the additional new ''client'' attribute which is set to ''site'' for a front-facing template and ''administrator'' for an back-end template.

Be sure to change the closing tag from ''</install>'' to ''</extension>''.

=== Template Parameters ===
In Joomla! 1.5, 1.6 and later versions, the template parameters are defined in templateDetails.xml.

Whereas in 1.5 parameters are defined as part of the <code><params></code> section, and each parameter is defined as a <code><param></code>, in 1.6 and later template parameters are contained in the <code><config></code> section and treated as a <code><field></code> nested within the <code><fieldset></code> and <code><fields></code> tags, as illustrated below.

<pre>
<config>
<fields name="params">
<fieldset name="basic">
<field name="" type="" default="" label="" description="">
<option value="1">On</option>
<option value="0">Off</option>
</field>
<field name="" type="" default="" label="e" description="" />
</fieldset>
</fields>
</config>
</pre>

<code><fieldset name="basic"></code> wraps the parameters in a grouping element. Using ''name="basic"'' labels that element as "Basic Options" and ''name="advanced"'' labels it as "Advanced Options".

The ''name'', ''type'', ''default'', ''label'' and ''description'' attributes still apply.

Outside of the main template files, you can access these parameters using the JApplication class. Previously, the values of the template parameters were stored in a plain text .ini file. In order to access those values outside of the template you needed to read the ini file and load the data into a JRegistry or JParameters object. Now, the values are stored in the database with other template information. We can load the params by passing the true variable to the getTemplate method of the JApplication object. It can be accessed like this:

<pre>
$app =& JFactory::getApplication();
$template = $app->getTemplate(true);
$params = $template->params;
$variable = $params->get('variable');
</pre>

This will allow you to access the template params in your layout overrides for other components, and modules.

== Objects and Methods ==
=== Sitename ===
* <code><?php echo $mainframe->getCfg('sitename');?></code> is now <code>$app->getCfg('sitename');</code> Where <code>$app = JFactory::getApplication();</code>

=== Error Codes ===
* <code>$this->error->code</code> is replaced by <code>$this->error->getCode();</code>
* <code>$this->error->message</code> is replaced by <code>$this->error->getMessage();</code>

== Discovery ==
In some cases your converted template may not be shown in the Template Manager even though all coding appears to be correct. Verify that your template files are installed in the ''/templates'' directory. Then run the Discover process as follows.
# Go to Administrator > Extensions > Extension Manager > Discover
# Click the Discover icon.
# If your template appears on the list, select it and then click the Install icon.

== Layout Overrides ==
=== com_content ===
If you have used the Beez overrides, or code derived from the Beez overrides, in your 1.5 template, you may encounter a ''JHtml::icon not supported. File not found.'' error when migrating the template to Joomla 1.6 and later. To fix this, simply add the following statement near the top of the template html/com_content/article/default.php file:
<source lang="php">
JHtml::addIncludePath( JPATH_COMPONENT . '/helpers' );
</source>

==Alternate Method Using a Version 2.5 Template==
Start with a basic template that works with a current version of Joomla. For this example, use the Atomic template that is supplied with Joomla 2.5.

# Copy the entire ''/templates/atomic'' folder to a new folder in the ''/templates'' directory.
# Rename this new folder. For instance, you might call it ''mysitename-atomic'' to designate it as the custom template for this site and adding the reminder that it was derived from the ''atomic'' template.
# In the new template's ''index.php'' file, delete everything between the ''<body> </body>'' tags.
# Copy and paste everything within the ''<body> </body>'' tags from your version 1.5 template to the body of the new template's ''index.php'' file.
# Delete or rename the ''template.css'' file copied from the Atomic template.
# Copy the ''template.css'' file from the old version 1.5 template.
# Update the ''templateDetails.xml'' file in the revised template.
## Change the ''<name>'' entry to match the name of the template folder. It is case-sensitive. If the folder is ''/templates/mysitename-atomic'', the entry in the ''templateDetails.xml'' file will be ''<name>mysitename-atomic</name>''.
## Replace the ''<positions>'' section of the file so that they match the positions used in the ''index.php'' file.
## Change the other elements as necessary. For instance, you might want to modify the creation date and version number.
# Delete images in the ''/template/image'' file and add your images.
# Delete the lines in the ''<head>'' section of the ''index.php'' file that load CSS and Javascript files that are not needed.
==Template Root Directory Considerations==
Compare the files in the root directory of the new template to old template's root directory files. It may be necessary to copy a few of the old files to the new template.

For example, copy the old favicon.ico file to the new template's root directory.

Remove the ''/html'' directory that was in the donor template. Copy the ''/html'' directory from your old template's files.

[[Category:Joomla! 1.6]]
[[Category:Template Development]]
[[Category:Tutorials]]

Talk:Creating a custom form field type

2012-05-30T17:14:49Z

Drewgg:

Set up base class is not neccessary. I have implemented custom list field using JFormField as parent class.
No need for class like specified in step 2, just write our getInput() or getOptions().

- Mrs.siam

<br>
<hr>
<br>

When creating a custom field for a front-end component ( /administrator/components/<component>/views/<view>/tmpl/<layout>.xml ) I was unable to use the custom field until I added the field path to my <fieldset>

<source lang="xml">
<fieldset addfieldpath="/administrator/components/<component>/models/fields" ...>
<field name="foo" type="customFieldName" ... />
</fieldset>
</source>

I don't know where else this would be required, ie: if it's required when using /administrator/components/<component>/models/forms/<whatever>.xml.

I also don't know if there is an alternative to using addfieldpath.

[[User:Drewgg|Drewgg]] 12:14, 30 May 2012 (CDT) Drewgg

Talk:Creating a custom form field type

2012-05-30T17:14:01Z

Drewgg:

Set up base class is not neccessary. I have implemented custom list field using JFormField as parent class.
No need for class like specified in step 2, just write our getInput() or getOptions().

- unknown author

<br>
<hr>
<br>

When creating a custom field for a front-end component ( /administrator/components/<component>/views/<view>/tmpl/<layout>.xml ) I was unable to use the custom field until I added the field path to my <fieldset>

<source lang="xml">
<fieldset addfieldpath="/administrator/components/<component>/models/fields" ...>
<field name="foo" type="customFieldName" ... />
</fieldset>
</source>

I don't know where else this would be required, ie: if it's required when using /administrator/components/<component>/models/forms/<whatever>.xml.

I also don't know if there is an alternative to using addfieldpath.

[[User:Drewgg|Drewgg]] 12:14, 30 May 2012 (CDT) Drewgg

Creating a custom form field type

2012-05-30T17:02:05Z

Drewgg: /* Using the custom field type */

[[JForm]], a feature introduced in Joomla 1.6, lets you easily create HTML forms (<code><form></code>). Forms created using JForm consist of [[Form field|form fields]], implemented as [[JFormField|JFormFields]]. There is a JFormField for each different field type you can find in a form, such as a text field type and a date field type. JForm supports a large selection of standard field types. For a full list, see [[Standard form field types]].

Joomla 1.6 makes it possible to extend standard field types or define your own. For example, if your component manages phone book entries, you might want to define a form field type that outputs a select list of cities. There are several advantages to defining a custom form field type:

* You will be able to mix standard field types with your custom field type in a JForm-based form.
* You will eventually have a reusable code package that can be used easily throughout your code.
* Extensions that collaborate with your extension will be able to create form fields without meddling with your database tables and other internals.

== Form field type class requirements ==

A form field type is defined in a [[wikipedia:Class (computer programming)|class]] that must be a (not necessarily direct) subclass of JFormField. To work correctly, the class must define at least two methods:

* <code>public function getLabel()</code>
*: This function will be called to create the label that belongs to your field and must return a HTML string containing it. Since JFormField defines a ready-to-use <code>getLabel()</code> implementation, custom form field types usually do not define their own <code>getLabel()</code>. If you leave it out, the inherited method of creating labels will be used. It is recommended to leave out the <code>getLabel()</code> method for consistency and speed unless you actually want to modify the label's HTML.
* <code>public function getInput()</code>
*: This function will be called to create the field itself and must return a HTML string containing it. This is also where most of the processing usually happens. In our phone book City field example, this function will have to retrieve a list of available cities and return a HTML <code><select></code> with the cities inserted as <code><option></code>s.

Inside your code, you will have to process the attributes set by the field's user in the XML form definition. Some of those attributes are accessible via protected member variables of JFormField. For example, the <code>name</code> attribute is available in your code as <code>$this->name</code>. Similarly, <code>label</code>, <code>description</code>, <code>default</code>, <code>multiple</code> and <code>class</code> are also available as properties of <code>$this</code>. Other parameters you might have defined can be accessed through the <code>$this->element</code> array: the attribute <code>size</code> will be in <code>$this->element['size']</code>.

== Which class to subclass? ==

For a form field type to be usable in JForm, it needs do be a subclass of JFormField. However, it does not have to be a direct child of that class: you can also subclass an existing (standard or custom) form field type and thereby inherit useful code.

'''If your form field type is quite similar to an existing type,''' you should subclass that type. Especially if your form field type is a '''list''', please subclass [[JFormFieldList]]. You only have to override <code>getOptions()</code> method to return the options to be shown; the <code>getInput()</code> method will convert those options to HTML.

To subclass an existing type, for example JFormFieldList, load it by adding the following to after <code>jimport('joomla.form.formfield');</code>:

<source lang="php">
jimport('joomla.form.helper');
JFormHelper::loadFieldClass('list');
</source>

'''If your form field type is unlike any existing type,''' subclass JFormField directly.

== Location of files ==

* The standard form field types are located in <code>joomla/libraries/joomla/form/fields/</code>. You should not store custom fields there, nor should you have to use this path in your own code, but the standard types are usually good examples.
* The custom field types that belong to your component are usually located in <code>administrator/components/<name of your component>/models/fields</code>. You can specify this or another path in your code:
<source lang="php">JForm::addFieldPath(JPATH_COMPONENT . DS . 'models' . DS . 'fields');</source>
* The XML files that define forms are usually located in <code>administrator/components/<name of your component>/models/forms</code>. Use something like the following snippet to specify a path to your forms:
<source lang="php">JForm::addFormPath(JPATH_COMPONENT . DS . 'models' . DS . 'forms');</source>

== Naming conventions and skeleton ==

In this section, <ComponentName> represents the camel-cased name of your component and <TypeName> represents the camel-cased name of your form field type. The field's class should be placed in <code>administrator/components/<name of your component>/models/fields/<name of your field>.php</code>, and look like this:

<source lang="php"><?php
// Check to ensure this file is included in Joomla!
defined('_JEXEC') or die('Restricted access');

jimport('joomla.form.formfield');

// The class name must always be the same as the filename (in camel case)
class JFormField<FieldName> extends JFormField {

//The field class must know its own type through the variable $type.
protected $type = '<FieldName>';

public function getLabel() {
// code that returns HTML that will be shown as the label
}

public function getInput() {
// code that returns HTML that will be shown as the form field
}
}
</source>

=== Grouping custom field types ===

'''Warning: this information is partially incorrect and needs to be improved.'''

Custom field types can be grouped by using an underscore in the field name. A field class with a name for example like "JFormFieldMy_randomField" must be stored in <code>administrator/components/<name of your component>/models/fields/my/randomField.php</code>. We can prefix our form field names with some group name, then we put an underscore and then a name of a field.

== An example custom field type ==

Suppose you're working on your component named ''com_phonebook'' and you want to define a field that contains cities. Create the file <code>administrator/components/com_phonebook/models/fields/city.php</code> and write something similar to the following:

<source lang="php"><?php
// Check to ensure this file is included in Joomla!
defined('_JEXEC') or die('Restricted access');

jimport('joomla.form.formfield');

class JFormFieldCity extends JFormField {

protected $type = 'City';

// getLabel() left out

public function getInput() {
return '<select id="'.$this->id.'" name="'.$this->name.'">'.
'<option value="1" >New York</option>'.
'<option value="2" >Chicago</option>'.
'<option value="3" >San Francisco</option>'.
'</select>';
}
}
</source>

=== Using the custom field type ===

To use the field type City, we need to update the XML file that contains the form fields. Open your XML file located in <code>administrator/components/com_phonebook/models/forms</code> and add the field in the usual way:

<source lang="xml"><field name="title" type="City" label="JGLOBAL_TITLE"
description="JFIELD_TITLE_DESC"
required="true" /></source>
The type name is cAsE-sEnSiTiVe.

In addition, you may need to add the field path to the parent <fieldset>:

<source lang="xml">
<fieldset addfieldpath="/administrator/components/<component name>/models/fields">
</source>

== Overriding <code>getLabel()</code> ==

As mentioned in the section [[#Form field type class requirements|Form field type class requirements]], custom form field types usually do not define their own <code>getLabel()</code>. If you do want to create a custom label, you can still make use of the <code>getLabel()</code> that every field type class inherits from JFormField, for example by defining it as follows:

<source lang="php">public function getLabel() {
return '<span style="text-decoration: underline;">' . parent::getLabel() . '</span>';
} </source>

This code will underline your form labels. (Please note that if your goal is to underline form labels, using [[CSS]] is the preferred way.)

If you want to do something completely different, you can of course also override it completely:

<source lang="php">public function getLabel() {
// Initialize variables.
$label = '';
$replace = '';

// Get the label text from the XML element, defaulting to the element name.
$text = $this->element['label'] ? (string) $this->element['label'] : (string) $this->element['name'];

// Build the class for the label.
$class = !empty($this->description) ? 'hasTip' : '';
$class = $this->required == true ? $class.' required' : $class;

// Add replace checkbox
$replace = '<input type="checkbox" name="update['.$this->name.']" value="1" />';

// Add the opening label tag and main attributes attributes.
$label .= '<label id="'.$this->id.'-lbl" for="'.$this->id.'" class="'.$class.'"';

// If a description is specified, use it to build a tooltip.
if (!empty($this->description)) {
$label .= ' title="'.htmlspecialchars(trim(JText::_($text), ':').'::' .
JText::_($this->description), ENT_COMPAT, 'UTF-8').'"';
}

// Add the label text and closing tag.
$label .= '>'.$replace.JText::_($text).'</label>';

return $label;
}</source>

This example will add a checkbox before the label.

<noinclude>[[Category:Development]][[Category:Form fields]][[Category:Joomla! 1.6]]</noinclude>

API16:JHtml/date

2012-03-02T21:32:02Z

Drewgg: /* Examples */

===Description===
Returns formated date according to a given format and time zone.

<span class="editsection" style="font-size:76%;">
<nowiki>[</nowiki>[[Description:JHtml/date|Edit Descripton]]<nowiki>]</nowiki>
</span>

{{Description:JHtml/date}}

===Syntax===
<source lang="php">static date($input= 'now', $format=null, $tz=true)</source>

{| class="wikitable"
|-
!Parameter Name
!Default Value
!Description
|-
| $input
| 'now'
| String in a format accepted by strtotime(), defaults to "now".
|-
| $format
| null
| format optional format for strftime
|-
| $tz
| true
| Time zone to be used for the date. Special cases: boolean true for user setting, boolean false for server setting.
|}

===Returns===
string A date translated by the given format and time zone.

===Defined in===
libraries/joomla/html/html.php
===Importing===
<source lang="php">jimport( 'joomla.html.html' );</source>

===Source Body===
<source lang="php">
public static function date($input = 'now', $format = null, $tz = true)
{
// Get some system objects.
$config = JFactory::getConfig();
$user = JFactory::getUser();

// UTC date converted to user time zone.
if ($tz === true)
{
// Get a date object based on UTC.
$date = JFactory::getDate($input, 'UTC');

// Set the correct time zone based on the user configuration.
$date->setOffset($user->getParam('timezone', $config->getValue('config.offset')));
}
// UTC date converted to server time zone.
elseif ($tz === false)
{
// Get a date object based on UTC.
$date = JFactory::getDate($input, 'UTC');

// Set the correct time zone based on the server configuration.
$date->setOffset($config->getValue('config.offset'));
}
// No date conversion.
elseif ($tz === null)
{
$date = JFactory::getDate($input);
}
// UTC date converted to given time zone.
else
{
// Get a date object based on UTC.
$date = JFactory::getDate($input, 'UTC');

// Set the correct time zone based on the server configuration.
$date->setOffset($tz);
}

// If no format is given use the default locale based format.
if (!$format) {
$format = JText::_('DATE_FORMAT_LC1');
}

return $date->toFormat($format);
}
</source>

<span class="editsection" style="font-size:76%;">
<nowiki>[</nowiki>[[SeeAlso:JHtml/date|Edit See Also]]<nowiki>]</nowiki>
</span>
{{SeeAlso:JHtml/date}}

===Examples===
<CodeExamplesForm />
<dpl>
noresultsheader=\n
category=date
category=JHtml
category=CodeExample
category=MethodExample
include=*
format= ,,,
</dpl>

<source lang="php">
// Server Timezone: "New York" (-0500 GMT)
// User Timeszone: "Los Angeles" (-0800 GMT)

jimport( 'joomla.html.html' );

$sqlGmtTimestamp = "2012-03-01 20:00:00"

echo JHtml::date($sqlGmtTimestamp , 'D F n, Y g:i a'); // Fri March 1, 2012 12:00 pm
echo JHtml::date($sqlGmtTimestamp , 'D F n, Y g:i a', true); // Fri March 1, 2012 12:00 pm
echo JHtml::date($sqlGmtTimestamp , 'D F n, Y g:i a', false); // Fri March 1, 2012 3:00 pm

</source>

API16:JHtml/date

2012-03-02T21:31:38Z

Drewgg: /* Examples */

===Description===
Returns formated date according to a given format and time zone.

<span class="editsection" style="font-size:76%;">
<nowiki>[</nowiki>[[Description:JHtml/date|Edit Descripton]]<nowiki>]</nowiki>
</span>

{{Description:JHtml/date}}

===Syntax===
<source lang="php">static date($input= 'now', $format=null, $tz=true)</source>

{| class="wikitable"
|-
!Parameter Name
!Default Value
!Description
|-
| $input
| 'now'
| String in a format accepted by strtotime(), defaults to "now".
|-
| $format
| null
| format optional format for strftime
|-
| $tz
| true
| Time zone to be used for the date. Special cases: boolean true for user setting, boolean false for server setting.
|}

===Returns===
string A date translated by the given format and time zone.

===Defined in===
libraries/joomla/html/html.php
===Importing===
<source lang="php">jimport( 'joomla.html.html' );</source>

===Source Body===
<source lang="php">
public static function date($input = 'now', $format = null, $tz = true)
{
// Get some system objects.
$config = JFactory::getConfig();
$user = JFactory::getUser();

// UTC date converted to user time zone.
if ($tz === true)
{
// Get a date object based on UTC.
$date = JFactory::getDate($input, 'UTC');

// Set the correct time zone based on the user configuration.
$date->setOffset($user->getParam('timezone', $config->getValue('config.offset')));
}
// UTC date converted to server time zone.
elseif ($tz === false)
{
// Get a date object based on UTC.
$date = JFactory::getDate($input, 'UTC');

// Set the correct time zone based on the server configuration.
$date->setOffset($config->getValue('config.offset'));
}
// No date conversion.
elseif ($tz === null)
{
$date = JFactory::getDate($input);
}
// UTC date converted to given time zone.
else
{
// Get a date object based on UTC.
$date = JFactory::getDate($input, 'UTC');

// Set the correct time zone based on the server configuration.
$date->setOffset($tz);
}

// If no format is given use the default locale based format.
if (!$format) {
$format = JText::_('DATE_FORMAT_LC1');
}

return $date->toFormat($format);
}
</source>

<span class="editsection" style="font-size:76%;">
<nowiki>[</nowiki>[[SeeAlso:JHtml/date|Edit See Also]]<nowiki>]</nowiki>
</span>
{{SeeAlso:JHtml/date}}

===Examples===
<CodeExamplesForm />
<dpl>
noresultsheader=\n
category=date
category=JHtml
category=CodeExample
category=MethodExample
include=*
format= ,,,
</dpl>

<source lang="php">
// Server Timezone: "New York" (-0500 GMT)
// User Timeszone: "Los Angeles" (-0800 GMT)

jimport( 'joomla.html.html' );

$sqlGmtTimestamp = "2012-03-01 20:00:00"

echo JHtml::date(sqlGmtTimestamp , 'D F n, Y g:i a'); // Fri March 1, 2012 12:00 pm
echo JHtml::date(sqlGmtTimestamp , 'D F n, Y g:i a', true); // Fri March 1, 2012 12:00 pm
echo JHtml::date(sqlGmtTimestamp , 'D F n, Y g:i a', false); // Fri March 1, 2012 3:00 pm

</source>

Archived:Adapting a Joomla 1.5 extension to Joomla 2.5

2011-02-08T16:31:54Z

Drewgg: /* Plugin files now in different locations */

{{incomplete}}

This article is written to help developers upgrade their extensions from Joomla 1.5 to Joomla 1.6. If you have any further tips, feel free to add them onto this wiki article.

== System setup ==
This document assumes that you are running the program eclipse for your development. This will allow you to automate most of the Joomla conversion process. For more instructions on how to setup eclipse, see [[Setting up your workstation for Joomla! development]].

== Background reading ==
[[What's new in Joomla 1.6#Developers]] describes most changes of Joomla 1.6 and how this affect developers.

== Updating your Joomla 1.5 language files to work on Joomla 1.6 ==
Using the native php ini parser for language files has many benefits including much faster performace. Converting your exisiting Joomla 1.5 into the new format is very easy if you use a coding platform like eclipse. Search your file for *.ini in your project of choice. Then use the following search/replace values to automatically, replace exisiting quotes, add quotes to string values and update your comments.

'''''Double quotes are NOT allowed inside the string value''', except when using "_QQ_" to represent them. In case of js use, better use html entities or single quotes.''

#Single quotes are allowed.
#Put a closing double quote at end of line if not empty or a comment. Find ^((?!#).+)\R replace with $1"\R
#Put an opening double quote at start of translated string if not empty or comment. Find ^((?!#).+?\=)(.+)\R replace with $1"$2\R
#Now replace the hash comments with the new semi colon. Find ^# and replace with ;
#Remove any illegal strings that can prevent files loading. Find ^(null|yes|no|true|false|on|off|none)=(.+)\R and replace with nothing.

Enabling Debug System in Global configuration will display the parsing errors per file and lines.

If you do not remove the illegal strings, then your language file will load until one of them is reached. The now "illegal" strings in the language file like NO, are handled by adding a 'J' in-front of them. Just make sure you change these language strings in your XML files as well. You can include in your language file:
<source lang="ini">
;forbidden words
JNULL="Null"
JYES="Yes"
JNO="No"
JTRUE="True"
JFALSE="False"
JON="On"
JOFF="Off"
JNONE="None"
</source>

== Changing Javascript function overrides ==
Joomla now has some of its Javascript functions prefixed with "Joomla". This means the functions are always unique and won't clash with other javascript functions on your server/webpage. However, you now need a different method to override the default Joomla Javascript. The Joomla 1.5 method was:
<source lang="javascript">
function submitbutton(pressbutton) {
var form = document.adminForm;
if (pressbutton == 'applyconfig') {
//do something unique
form.action.value = 'apply'
submitform('saveconfig');
return;
}

submitform(pressbutton);
return;
}
</source>
For Joomla 1.6 you need to copy your exisiting function but modify your top line to:
<source lang="javascript">
Joomla.submitbutton = function(pressbutton) {
var form = document.adminForm;
if (pressbutton == 'applyconfig') {
//do something unique
form.action.value = 'apply'
submitform('saveconfig');
return;
}

submitform(pressbutton);
return;
}
</source>

== Changing removed functions ==
Some functions were removed for various reasons. You can find a list of them on [[What's new in Joomla_1.6#Removed_features]].

Note that the ADODB compatibility methods included function like $db->Execute($query) which now need a separate $db->setQuery($query);$db->Query();

== Renamed events ==

A large number of the Joomla 1.5 events have been renamed. Here is the list of 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.

This means that if you use Joomla events you have two options:<br/>
1) rename the event and your extension can only be used on Joomla 1.6<br/>
2) create your own "legacy layer" and add the new event function name to your plugin. Here is an example of the user plugin:<br/>

<source lang="php">
//joomla 1.6 compatibility code
public function onUserLogin($user, $options){
$result = $this->onLoginUser($user, $options);
return $result;
}
public function onUserLogout($user) {
$result = $this->onLogoutUser($user);
return $result;
}
public function onUserAfterDelete($user, $succes, $msg) {
$result = $this->onAfterDeleteUser($user, $succes, $msg);
return $result;
}
public function onUserBeforeSave($user, $isnew, $new){
$result = $this->onBeforeStoreUser($user, $isnew, $new);
return $result;
}
public function onUserAfterSave($user, $isnew, $success, $msg){
$result = $this->onAfterStoreUser($user, $isnew, $success, $msg);
return $result;
}
</source>

== Changing name="adminForm" to id="adminForm" ==
To create your own admin forms in joomla you now need to use id="adminForm". This is because the use of the tag "name" is not valid HTML strict and has compatibility issues when used in XHTML served as XML.\. Although there is build in compatibility check to look for the old name="adminForm" tag, it is best to add the new id tag. Depending on the features you want to use you may need to include both, name="adminForm" and id="adminForm" because not all core functionality has been updated to use id's. An example of the new form code is:
<source lang="html4strict"><form method="post" action="index.php" name="adminForm" id="adminForm"></form></source>

== Removing references to index2.php and index3.php ==
Joomla 1.0 had different index files to serve admin content in different manners. Joomla 1.6 has now got better way to handle this and you need to search your codebase for "index2.php" and "index3.php" to ensure you don't have any Joomla 1.0 style links. If you need to display your component without any of the other Joomla 1.6 admin content (menus, etc) then add the following to the url: "&tmpl=component"

== Upgrading core table and field name usage ==
Many of the core Joomla tables have been simplified, combined or renamed. This was needed to get rid of some limitation dating back to Joomla 1.0. This means however that if you have code that directly manipulates Joomla tables, that you need to add a function that detects Joomla 1.6 and had different SQL queries based on the joomla version. Plase note that both tables and field names have been renamed or removed. An example is the following function that can find if a plugin is published on both Joomla 1.5 and 1.6:

<source lang="php">
function getPluginStatus($element, $folder) {
//get joomla specs
$db = & JFactory::getDBO();
$version = new JVersion;
$joomla = $version->getShortVersion();
if(substr($joomla,0,3) == '1.6'){
//Joomla 1.6 code
$query = 'SELECT published FROM #__extensions WHERE element=' . $db->Quote($element) . ' AND folder=' . $db->Quote($folder);
} else {
//Joomla 1.0/1.5 code
$query = 'SELECT published FROM #__plugins WHERE element=' . $db->Quote($element) . ' AND folder=' . $db->Quote($folder);
}
$db->setQuery($query);
$result = $db->loadResult();
return $result;
}
</source>

== Changing in the XML installer manifest file ==
Joomla 1.6 now uses a more streamlined approach to the XML file inside the ZIP file that installs Joomla extentions.

== New mootools version ==
Most important is that the Ajax class has been depreciated and replaced by the Request class. That means that if you use ajax calls you need to have a version switcher (below a sample code)

<source lang="php">
$version = new JVersion;
$joomla = $version->getShortVersion();

..... (your code) ....

/* our ajax istance for starting the sync */
<?php if(substr($joomla,0,3) == '1.6'){
echo 'var ajax = new Request.HTML({
url: url,';
} else {
echo 'var ajax = new Ajax(url, {';
}?>

.... your code .....

<?php if(substr($joomla,0,3) == '1.6'){
echo 'var ajaxsync = new Request.HTML({
url: url, ';
} else {
echo 'var ajaxsync = new Ajax(url, {';
}?>

.... your code .....

</source>

Also another common usuage of mootools in Joomla is the popup box. The Joomla 1.5 javascript code to close this box is:
<source lang="javascript">document.getElementById('sbox-window').close();</source>
in Joomla 1.6 you need to use:
<source lang="javascript">window.parent.SqueezeBox.close();</source>

== Converting your JParameters to JForms ==
Joomla 1.6 now uses the JForms class to handle parameters and it has also changed the way parameters are defined in your XML files. To make menu/component/module/plugin parameters work, first you need to update the XML file. Here is an automated way to handle the bulk of the conversion. (added "" to the examples below so you can see spaces in the search query as well). Use eclipse to search and replace parameters in *.xml files

replace "<param " with "<field "<br>
replace "</param>" with </field>"<br>
replace "<params> with "<config><fields name="params"><fieldset name="basic">"<br>
replace "<params*?> with "<config><fields name="params"><fieldset name="basic">"<br>
replace "</params>" with "</fieldset></fields></config>"<br>
replace "<install " with "<extension "<br>
replace "</install>" with "</extension>"

Change the "extension" node to add the following attributes:
* Keep the existing "type" attribute
* version="1.6.0"
* client="site"
* method="upgrade"

Example for a module:
<source lang="xml">
<extension type="module" version="1.6.0" client="site" method="upgrade">
</source>

Now if you want to use your joomla extension on both Joomla 1.5 and 1.6 you will need to go to your "team synchronising" view in eclipse. Double click on your changed xml file, which will open the compare editor. Then simply copy-paste back your old Joomla 1.5 params into your new Joomla 1.6 xml file and save.

If you have custom parameter types, you will need to do some additional work. In Joomla 1.5 you would use the following code:

<source lang="php"><params addpath="/administrator/components/com_yourname/elements"></source>
In joomla 1.6 JParameter classes won't work and you will need to convert your jparameter fields into JForm fields. Create a new directory and copy your "old elements" into them. Then you need to load these new fields with the individual parameter

<source lang="php"><field name="sample" type="sampleField" size="5" default="" label="sampleField" description="sampleField" addfieldpath="/administrator/components/com_yourname/fields"/></source>

Use eclipse to search and replace files in your newly created fields directory.
replace "JElement" with "JFormField"<br>
replace "var $_name =" with "public $type ="<br>
replace "function fetchElement($name, $value, &$node, $control_name)" with "protected function getInput()"<br>

Then you still need to replace the references to $control_name and others in your new JForm field, but at least the bulk of the work has been done automatically

== renamed core component names and login form parameters ==
A login module for Joomla 1.5 will not work without modifications on Joomla 1.6. Here is a part of the logout module that will work on both Joomla 1.5 and Joomla 1.6. You can compare the two to see the difference in input names.

<source lang="php">
$version = new JVersion;
$joomla = $version->getShortVersion();
if(substr($joomla,0,3) == '1.6'){
//joomla 1.6 format
$output .= '<input type="hidden" name="task" value="user.logout" />';
$output .= '<input type="hidden" name="option" value="com_users" />';
} else {
//joomla 1.5 format
$output .= '<input type="hidden" name="task" value="logout" />';
$output .= '<input type="hidden" name="option" value="com_user" />';
}
</source>

here is the code for the login module

<source lang="php">
$version = new JVersion;
$joomla = $version->getShortVersion();
if(substr($joomla,0,3) == '1.6'){
//joomla 1.6 format
$output .= '<input type="hidden" name="task" value="user.login" />';
$output .= '<input type="hidden" name="option" value="com_users" />';
$output .= '<input id="modlgn_passwd" type="password" name="password" class="inputbox" size="18" alt="password" /> ';
} else {
//joomla 1.5 format
$output .= '<input type="hidden" name="task" value="login" />';
$output .= '<input type="hidden" name="option" value="com_user" />';
$output .= '<input id="modlgn_passwd" type="password" name="passwd" class="inputbox" size="18" alt="password" /> ';
}
</source>

These changes might also apply to front-end forms of other Joomla core components (more information needed)

== ACL changes ==
Joomla 1.6 now has an advanced ACL system. It is unknown how this affects people that have previously used the ACL API in their extension. Please add some information here if you know more.

== Plugin files now in different locations ==
Joomla 1.6 now creates a different hierarchy structure for plugins. Files are no longer placed where they used to be, so if your other parts of your application (comp, mods, etc.) expects them to be in a certain position, it won't work. The change has been that now plugins are in an additional subdirectory. If you only load your plugins via the 1.5 API you should be fine.
* Joomla 1.5 example location
<source lang="php">JPATH_SITE . DS . 'plugins' . DS . 'authentication' . DS . 'example.php';</source>
* Joomla 1.6 example location
<source lang="php">JPATH_SITE . DS . 'plugins' . DS . 'authentication' . DS . 'example'. DS . 'example.php';</source>

== Changes to view parameters ==
J!1.6 has a strict new way of specifying parameters for views. J!1.5 allowed a bit of freedom where the parameters could be defined at the view.html.php level but now ithas to be at the tmpl level. AE believes the view paramters were removed.

== Installation process - preflight, postflight, etc ==
These are new events that can screw up an existing installlation process. -1 on me for not documenting the process while stepping through xdebug.
They should be totally optional access points to the installation process. But if your 1.5 install process is tricky for some reason, then these can be used to do clean up activities.

== Admin template changes ==
Admin functions that depended on certain functions, naming conventions etc no longer work. Khepri has been removed. Other admin functions/libraries may have changed.

== ACL ==
gid and aid have been removed. Significant changes to ACL archtecture. Bricking refers to totally locking your self and everyone else out - Last chance backdoor involves adding a emergency pw to the config file.

==sys.ini language translation file==
This file has 3 purposes:

1. It is used for installation process translations, when a folder language is included in the pack.

pack/language/en-gb/en-gb.extension.ini

pack/language/en-gb/en-gb.extension.sys.ini

In this case, the <description>COM_MYCOMPONENT_XML_DESCRIPTION</description> used in the sys.ini will display on installing/updating the extension.

When editing the extension in administration, it will be the .ini version of COM_MYCOMPONENT_XML_DESCRIPTION which will display.

2. It is used to replace the former .menu.ini

3. It is used to display the translated extension name in many managers.

== removed include folders ==
Most of the 3rd party libraries (Archive, domit, js, PEAR, etc) in the include folder have been removed in J!1.6.

== Use paths defined in defines.php. ==
(Note they are different for the site and the administration)

[[Category:Joomla! 1.6]]
[[Category:Tutorials]]
[[Category:Development]]
[[Category:Module Development]]
[[Category:Component Development]]
[[Category:Plugin Development]]

Accessing the database using JDatabase

2009-06-22T15:24:00Z

Drewgg: /* Misc Result Set Methods */