Actions

Difference between revisions of "Understanding Output Overrides"

From Joomla! Documentation

m (Introduction)
(Module Chrome: Fixed spelling error)
Line 1: Line 1:
[[Category:Development]] [[Category:Templates]]
+
{{version/tutor|1.5,2.5,3.1}}
= Understanding Output Overrides in "Joomla!" 1.5 =
+
[[Category:Development]] [[Category:Templates]] [[Category:Overrides]] [[Category:Tips and tricks 1.5]]
Written by Andrew Eddie
+
This was a Developer Blog post by Andrew Eddie, initially copied to the wiki with minor edits by Alan Langford.
 
+
This was Developer Blog post by Andrew, initially copied to the wiki with minor edits by Alan Langford. This is still a work in progress.
+
 
== Introduction ==
 
== Introduction ==
There are many competing requirements for web designers ranging from accessibility to legislative to personal preferences. Rather than trying to over-parameterise views, or trying to aim for some sort of line of best fit, or, worse, sticking its head in the sand, "Joomla!" has added the potential for the designer to take over control of virtually all of the output that is generated.
+
There are many competing requirements for Web designers ranging from accessibility to legislative to personal preferences. Rather than trying to over-parameterise views, or trying to aim for some sort of line of best fit, or, worse, sticking its head in the sand, Joomla! has added the potential for the designer to take over control of virtually all the output that is generated.
  
"Joomla!" has been criticized by some for not giving due attention to accessibility or being archaic in their approach to web standards. However, with 1.5, the responsibility -- and, more importantly, the power -- to control output is back in the designer's hands.
+
Joomla! has been criticized by some for not giving due attention to accessibility or being archaic in their approach to Web standards. However, with 1.5, the responsibility--and, more importantly, the power--to control output is back in the designer's hands.
  
In addition, except for files that are provided in the "Joomla!" distribution itself, these methods for customisation eliminate the need for designers and developers to "hack" core files that could change when the site is updated to a new version. Because they are contained within the template, they can be deployed to the Web site without having to worry about changes being accidentally overwritten when your System Administrator upgrades the site.
+
In addition, except for files that are provided in the Joomla! distribution itself, these methods for customisation eliminate the need for designers and developers to "hack" core files that could change when the site is updated to a new version. Because they are contained within the template, they can be deployed to the Website without having to worry about changes being accidentally overwritten when your System Administrator upgrades the site.
  
The aim of this tutorial is to introduce the how fours areas of the output of "Joomla!" are able to be customised by the template designer.
+
The aim of this tutorial is to introduce the fours areas of the output of Joomla! that are able to be customised by the template designer.
  
Not interested in all the theory? Jump straight to the cheat sheet.
+
Not interested in all the theory? Jump straight to the cheat sheet below.
  
 
== MVC 101 ==
 
== MVC 101 ==
MVC can be a scary acronym. It stands for Model-View-Controller and the concepts behind MVC are responsible for the extra flexibility that is now afforded to the designer. While parts of the theory can be rather involved and complicated, the only part that the designer need worry about is the V for View. This is the part that is concerned with output.
+
MVC can be a scary acronym. It stands for Model-View-Controller and the concepts behind MVC are responsible for the extra flexibility that is now afforded to the designer. While parts of the theory can be rather involved and complicated, the only part that the designer need worry about is the V for View. This is the part that is concerned with output.
  
 
Different extensions display output in different ways.
 
Different extensions display output in different ways.
  
Components, as you would already know, are fairly complex and have the ability to display different information in different ways. For example, the Articles Component (com_content) is able to display a single article, or articles in a category, or categories in a section. Each of the ways of representing the different types of data (an article, or a category, or a section) is called a "view" (this comes from our MVC terminology). Most components will have many views. However, the view doesn't actually display the output. This is left up to what we call a "layout" and it is possible for a view to have a variety of layouts.
+
Components, as you already know, are fairly complex and have the ability to display different information in different ways. For example, the Articles Component (com_content) is able to display a single article, or articles in a category, or categories in a section. Each of the ways of representing the different types of data (an article, or a category, or a section) is called a "view" (this comes from our MVC terminology). Most components will have many views. However, the view doesn't actually display the output. This is left up to what we call a "layout" and it is possible for a view to have a variety of layouts.
  
The main thing to remember here is that components can have multiple views, and each view can have one or more layouts. Each view assembles a fixed set of information, but each layout can display that information in different ways. For example, the Category view in the Articles component assembles a number of articles. These articles could be displayed in a list or in a table (and probably other ways as well). So this view may have a "list" layout and a "table" layout to choose from.
+
The main thing to remember here is that components can have multiple views, and each view can have one or more layouts. Each view assembles a fixed set of information, but each layout can display that information in different ways. For example, the Category view in the Articles component assembles a number of articles. These articles could be displayed in a list or in a table (and probably other ways as well). So this view may have a "list" layout and a "table" layout to choose from.
  
Modules, on the other hand, are very simple. They generally display one thing one way. Modules don't really have views but they do support a layout. Some developers might even support a choice of layout through module parameters.
+
Modules, on the other hand, are very simple. They generally display one thing one way. Modules don't really have views but they do support a layout. Some developers might even support a choice of layout through module parameters.
 
=== Template versus Layout ===
 
=== Template versus Layout ===
 +
It is very important to distinguish between the role of templates and the role of layouts. The template sets up a structural framework for the page of the Web site. Within this framework are positions for modules and a component to display. What actually gets displayed is governed by the module layout, or the combination of view and layout in the case of the component.
  
It is very important to distinguish between the role of template and the role of layouts.  The template sets up a structural framework for the page of the Web site.  Within this framework are positions for modules and a component to display.  What actually gets displayed is governed by the module layout, or the combination of view and layout in the case of the component.
+
The following image shows the structural layout of a typical Joomla! template (rhuk_milkyway, the default for 1.5). The module positions are displayed by adding tp=1 to the URL (eg, index.php?tp=1). You can clearly see where the module output is contained within the overall template, as well as the main component output starting in the lower-centre region. However, what is actually output in those regions is controlled by the layouts.
 
+
The following image shows the structural layout of a typical "Joomla!" template (rhuk_milkyway, the default for 1.5). The module positions are displayed by adding tp=1 to the URL (eg, index.php?tp=1). You can clearly see where the module output is contained within the overall template, as well as the main component output starting in the lower-centre region. However, what is actually output in those regions, is controlled by the layouts.
+
  
 
[[Image:FrontpageTemplatePositions.png|Typical Joomla! screenshot with template positions shown.]]
 
[[Image:FrontpageTemplatePositions.png|Typical Joomla! screenshot with template positions shown.]]
  
 
=== Ancillary Customisation ===
 
=== Ancillary Customisation ===
 +
While not strictly related to the MVC, there are two other important areas to consider when looking at customising the output of Joomla!.
  
While not strictly related to the MVC, there are two other important areas to consider when looking at customising the output of "Joomla!".
+
=== Ancillary Customisation:Chrome ===
 
+
In addition to layouts, modules have what we call "chrome". Chrome is the style(s) with which a module is to display. Most developers, designers and probably some end-users will be familiar with the different built-in styles for modules (raw, xhtml, etc). It is also possible to define your own chrome styles for modules depending on the designer result. For example, you could design a chrome to display all the modules in a particular position in a fancy Javascript collapsing blind arrangement.
In addition to layouts, modules have what we call "chrome". Chrome is the style with which a module is to display. Most developers, designers and probably some end-users will be familiar with the different built-in styles for modules (raw, xhtml, etc). It is also possible to define your own chrome styles for modules depending on the designer result. For example, you could design a chrome to display all the modules in a particular position in a fancy Javascript collapsing blind arrangement.
+
  
 
In the screenshot above, you can just make out the names of some of the built-in module chrome used (rounded, none and xhtml).
 
In the screenshot above, you can just make out the names of some of the built-in module chrome used (rounded, none and xhtml).
  
The second area has to do with controlling the pagination controls when viewing lists of data. We will look at that in more detail later.
+
Note the potential plural.  A module or component can have multiple chrome styles applied to it.  For example, When the global template setting "preview module positions" is enabled and the page is loaded with ?tp=1 at the end of the url the chrome "outline" is added to all modules and the component.  This is in addition to their regular chrome styling.  The default chrome settings can be found in the template/system/html/modules.php file and additional chrome styles may be added by adding your own modules.php file to your template.
 +
 
 +
Chrome styles are functions and are written in this manner:
 +
<source lang="php">
 +
/*
 +
* foobar (outputs foo before module content and bar after)
 +
*/
 +
function modChrome_foobar($module, &$params, &$attribs)
 +
{
 +
        echo '<h1>Foo</h1>';
 +
echo $module->content;
 +
        echo '<h1>Bar</h1>';
 +
}
 +
</source>
 +
 
 +
Use $module->content to access the content generated by the module.  You may access the module parameters and attributes by using the appropriate variables passed to this function.
 +
 
 +
=== Ancillary Customisation:Pagination ===
 +
The second area has to do with controlling the pagination controls when viewing lists of data. We will look at that in more detail later.
 +
 
 
== Component Output Types and Layout Overrides ==
 
== Component Output Types and Layout Overrides ==
  
To understand layout overrides we must first understand the file structure of a component. While there are many parts to a component, all fulfilling different roles and responsibilities, we want to look just in the /views/ directory. Here is the partial structure for two of the com_content views:
+
To understand layout overrides we must first understand the file structure of a component. While there are many parts to a component, all fulfilling different roles and responsibilities, we want to look just in the /views/ directory. Here is the partial structure for two of the com_content views:
 
<pre>
 
<pre>
 
/components
 
/components
Line 54: Line 70:
 
  form.php (this is a layout)
 
  form.php (this is a layout)
 
view.html.php (this is the view that outputs the HTML)
 
view.html.php (this is the view that outputs the HTML)
view.pdf.php (this is the view that outputs the PDF)
+
view.pdf.php (this is the view that outputs the PDF)
 
  /category
 
  /category
 
/tmpl
 
/tmpl
Line 63: Line 79:
 
view.feed.php (RSS feed)
 
view.feed.php (RSS feed)
 
</pre>
 
</pre>
So what you see here is that under the /views/ directory, each view is placed in a directory of its own. The content component actually has three other views not shown: archive, frontpage and section.
+
So what you see here is that under the /views/ directory, each view is placed in a directory of its own. The content component actually has three other views not shown: archive, frontpage and section.
 
=== Output Types ===
 
=== Output Types ===
Under the /articles/ directory we have a number of files. There is almost always a file called view.html.php. This is what we call the view file, but there can be more than one depending on the type of output to produce. It has a specific naming convention, view.output_type.php, where the output type can be html, feed, pdf, raw or error (for more information see JDocument in the API reference and look in the directory /libraries/joomla/document/). What this means is when we want html output for this particular view, the view.html.php file is used. When we want the RSS output, the view.feed.php file is used.
+
Under the /articles/ directory we have a number of files. There is almost always a file called view.html.php. This is what we call the view file, but there can be more than one depending on the type of output to produce. It has a specific naming convention, view.output_type.php, where the output type can be html, feed, pdf, raw or error (for more information see JDocument in the API reference and look in the directory /libraries/joomla/document/). What this means is when we want html output for this particular view, the view.html.php file is used. When we want the RSS output, the view.feed.php file is used.
  
The affect of these different output types is most apparent when the Global Configuration setting for Search Engine Friendly URLs is set to Yes, Use Apache mod_rewrite is set to Yes, and Add suffix to URLs is also set to Yes. When this is done, the site URLs will look something like this:
+
The affect of these different output types is most apparent when the Global Configuration setting for Search Engine Friendly URLs is set to Yes, Use Apache mod_rewrite is set to Yes, and Add suffix to URLs is also set to Yes. When this is done, the site URLs will look something like this:
  
 
<pre>
 
<pre>
Line 75: Line 91:
 
http://domain/sports/rowing.pdf
 
http://domain/sports/rowing.pdf
 
</pre>
 
</pre>
The exact URL will vary depending on how you set up your site but the point here is to show that sports.html will use the category view's view.html.php file to, and that sports.feed will display the RSS feed for the category using view.feed.php. It should be noted that you cannot currently customise feed or PDF output types. However, you can customise the html output type and this is where layouts come into play.
+
The exact URL will vary depending on how you set up your site but the point here is to show that sports.html will use the category view's view.html.php file to, and that sports.feed will display the RSS feed for the category using view.feed.php. It should be noted that you cannot currently customise feed or PDF output types. However, you can customise the html output type and this is where layouts come into play.
  
 
=== Layouts ===
 
=== Layouts ===
Under the view directory there is a /tmpl/ directory in which the layout files reside. Each PHP file in this directory represents a layout. For example, article/tmpl/default.php is the default layout for an article whereas article/tmpl/form.php is the edit form for an article; category/tmpl/default.php is the default layout for a category whereas category/tmpl/blog.php displays the list of article differently.
+
Under the view directory there is a /tmpl/ directory in which the layout files reside. Each PHP file in this directory represents a layout. For example, article/tmpl/default.php is the default layout for an article whereas article/tmpl/form.php is the edit form for an article; category/tmpl/default.php is the default layout for a category whereas category/tmpl/blog.php displays the list of article differently.
  
The relationship between component views and layout is most plainly seen when adding a new menu item. The next screenshot represents the typical display of the New Menu Item page. Having clicked on Articles (which represents com_content), the tree expands to show the list of views and each layout within the view.
+
The relationship between component views and layout is most plainly seen when adding a new menu item. The next screenshot represents the typical display of the New Menu Item page. Having clicked on Articles (which represents com_content), the tree expands to show the list of views and each layout within the view.
  
 
[[Image:Menu_item_type_articles.png|Screenshot of creating a new menu item fro an article.]]
 
[[Image:Menu_item_type_articles.png|Screenshot of creating a new menu item fro an article.]]
  
You will notice that while there are extra files in some of the /tmpl/ directories (like pagebreak.php in the article view), they are missing from the list. This is due to instructions in the XML file for the layout (for example, pagebreak.xml) to hide the layout (or even the view) from the menu item list. However, this is another broad topic which will be covered in another tutorial.
+
You will notice that while there are extra files in some of the /tmpl/ directories (like pagebreak.php in the article view), they are missing from the list. This is due to instructions in the XML file for the layout (for example, pagebreak.xml) to hide the layout (or even the view) from the menu item list. However, this is another broad topic which will be covered in another tutorial.
  
 
Armed with all that knowledge of how all the parts relate to each other, we are now ready to actually create our layout overrides.
 
Armed with all that knowledge of how all the parts relate to each other, we are now ready to actually create our layout overrides.
Line 90: Line 106:
 
=== Copying or Creating Layout Files ===
 
=== Copying or Creating Layout Files ===
  
Layout overrides only work within the active template and are located under the /html/ directory in the template. For example, the overrides for rhuk_milkyway are located under /templates/rhuk_milkyway/html/, for the JA Purity template under /templates/ja_purity/html/ and for Beez under /templates/beez/html/.
+
Layout overrides only work within the active template and are located under the /html/ directory in the template. For example, the overrides for rhuk_milkyway are located under /templates/rhuk_milkyway/html/, for the JA Purity template under /templates/ja_purity/html/ and for Beez under /templates/beez/html/.
  
It is important to understand that if you create overrides in one template, they will not be available in other templates. For example, rhuk_milkyway has no component layout overrides at all. When you use this template you are seeing the raw output from all components. When you use the Beez template, almost every piece of component output is being controlled by the layout overrides in the template. JA Purity is in between having overrides for some components and only some views of those components.
+
It is important to understand that if you create overrides in one template, they will not be available in other templates. For example, rhuk_milkyway has no component layout overrides at all. When you use this template you are seeing the raw output from all components. When you use the Beez template, almost every piece of component output is being controlled by the layout overrides in the template. JA Purity is in between having overrides for some components and only some views of those components.
  
The layout overrides must be placed in particular way. Using Beez as an example you will see the following structure:
+
The layout overrides must be placed in particular way. Using Beez as an example you will see the following structure:
 
<pre>
 
<pre>
 
/templates
 
/templates
Line 105: Line 121:
 
</pre>
 
</pre>
  
The structure for component overrides is quite simple: /html/com_component_name/view_name/layout_file_name.php. Let's look at a few examples.
+
The structure for component overrides is quite simple: /html/com_component_name/view_name/layout_file_name.php. Let's look at a few examples.
  
The rhuk_milkyway template does not have any layout overrides for any components. If we want to override the default layout for an article, first we need to copy this file:
+
The rhuk_milkyway template does not have any layout overrides for any components. If we want to override the default layout for an article, first we need to copy this file:
  
 
/components/com_content/views/article/tmpl/default.php
 
/components/com_content/views/article/tmpl/default.php
Line 123: Line 139:
 
/templates/rhuk_milkyway/html/com_content/category/blog.php
 
/templates/rhuk_milkyway/html/com_content/category/blog.php
  
Once the files are copied, you are free to customise these files as much or as little as required or desired. You do not have to honour parameter settings if you don't want to.
+
Once the files are copied, you are free to customise these files as much or as little as required or desired. You do not have to honour parameter settings if you don't want to.
 
=== Overriding Sub-Layouts ===
 
=== Overriding Sub-Layouts ===
  
In some views you will see that some of the layouts have a group of files that start with the same name. The category view has an example of this. The blog layout actually has three parts: the main layout file blog.php and two sub-layout files, blog_item.php and blog_links.php. You can see where these sub-layouts are loaded in the blog.php file using the loadTemplate method, for example:
+
In some views you will see that some of the layouts have a group of files that start with the same name. The category view has an example of this. The blog layout actually has three parts: the main layout file blog.php and two sub-layout files, blog_item.php and blog_links.php. You can see where these sub-layouts are loaded in the blog.php file using the loadTemplate method, for example:
 
<source lang="php">
 
<source lang="php">
 
echo $this->loadTemplate('item');
 
echo $this->loadTemplate('item');
Line 134: Line 150:
 
When loading sub-layouts, the view already knows what layout you are in, so you don't have to provide the prefix (that is, you load just 'item', not 'blog_item').
 
When loading sub-layouts, the view already knows what layout you are in, so you don't have to provide the prefix (that is, you load just 'item', not 'blog_item').
  
What is important to note here is that it is possible to override just a sub-layout without copying the whole set of files. For example, if you were happy with the "Joomla!" default output for the blog layout, but just wanted to customise the item sub-layout, you could just copy:
+
What is important to note here is that it is possible to override just a sub-layout without copying the whole set of files. For example, if you were happy with the Joomla! default output for the blog layout, but just wanted to customise the item sub-layout, you could just copy:
  
 
/components/com_content/views/category/tmpl/blog_item.php
 
/components/com_content/views/category/tmpl/blog_item.php
Line 142: Line 158:
 
/templates/rhuk_milkyway/html/com_content/category/blog_item.php
 
/templates/rhuk_milkyway/html/com_content/category/blog_item.php
  
When "Joomla!" is parsing the view, it will automatically know to load blog.php from com_content natively and blog_item.php from your template overrides.
+
When Joomla! is parsing the view, it will automatically know to load blog.php from com_content natively and blog_item.php from your template overrides.
 
== Module Layout Overrides ==
 
== Module Layout Overrides ==
  
Line 155: Line 171:
 
mod_latest_news.xml  (the installation XML file)
 
mod_latest_news.xml  (the installation XML file)
 
</pre>
 
</pre>
Similar to components, under the main module directory (in the example, mod_latest_news) there is a /tmpl/ directory. There is usually only one layout file but depending on who wrote the module, and how it is written, there could be more.
+
Similar to components, under the main module directory (in the example, mod_latest_news) there is a /tmpl/ directory. There is usually only one layout file but depending on who wrote the module, and how it is written, there could be more.
  
As for components, the layout override for a module must be placed in particular way. Using Beez as an example again, you will see the following structure:
+
As for components, the layout override for a module must be placed in particular way. Using Beez as an example again, you will see the following structure:
 
<pre>
 
<pre>
 
/templates
 
/templates
Line 168: Line 184:
 
=== Copying or Creating Layout Files ===
 
=== Copying or Creating Layout Files ===
  
The rhuk_milkyway template does not have any layout overrides for any modules. If we want to override the default layout for Latest News module, we need to copy this file:
+
The rhuk_milkyway template does not have any layout overrides for any modules. If we want to override the default layout for Latest News module, we need to copy this file:
  
 
/modules/mod_latest_news/tmpl/default.php
 
/modules/mod_latest_news/tmpl/default.php
Line 180: Line 196:
 
== Module Chrome ==
 
== Module Chrome ==
  
"Joomla!" 1.0 had a number of fixed styles that could display a list of modules in a particular position. These where represented by numbers:
+
Joomla! 1.0 had a number of fixed styles that could display a list of modules in a particular position. These where represented by numbers:
  
 
* 0 (the default) displayed modules in a vertical table
 
* 0 (the default) displayed modules in a vertical table
Line 193: Line 209:
 
# You couldn't expand on the styles.
 
# You couldn't expand on the styles.
  
Well, in 1.5, the numbers are still recognised, but more commonly the style is represented as a word. As well as that, the syntax for displaying a module position was changed. For example, this snippet displays each module in the left position in the xhtml style:
+
Well, in 1.5, the numbers are still recognised, but more commonly the style is represented as a word. As well as that, the syntax for displaying a module position was changed. For example, this snippet displays each module in the left position in the xhtml style:
 
<source lang="php">
 
<source lang="php">
 
<jdoc:include type="modules" name="left" style="xhtml" />
 
<jdoc:include type="modules" name="left" style="xhtml" />
Line 206: Line 222:
 
* outline (new - used to preview module positions - see screenshot above)
 
* outline (new - used to preview module positions - see screenshot above)
  
In the source code, these styles are actually referred to as "chrome". The default chrome can actually be found in the system template provided in the default "Joomla!" install:
+
In the source code, these styles are referred to as "chrome". The default chrome is in the system template of the default Joomla! install:
  
 
/templates/system/html/modules.php
 
/templates/system/html/modules.php
  
This file is maintained by the project so you should never modify it directly otherwise there is a risk that you will loose your changes if and when you upgrade your "Joomla!" installation.
+
This file is maintained by the project so you should never modify it. You will lose your changes when you upgrade your Joomla! installation.
  
To create your own chrome, or module styles, all you need to do is create or edit modules.php under the templates /html/ directory (this is the same directory we have been talking about for component and module layout overrides).
+
To create your own chrome, or module styles, create or edit modules.php under the templates /html/ directory. (This is the same directory we have been talking about for component and module layout overrides).
  
The rhuk_milkyway template actually does provide some extra chrome as an example (it provides and new example style called "slider"). This can be found in the following file:
+
The rhuk_milkyway template provides some extra chrome as an example. (It provides an example style called "slider"). This can be found in the following file:
  
 
/templates/rhuk_milkyway/html/modules.php
 
/templates/rhuk_milkyway/html/modules.php
  
To create your own chrome is really easy. Let's look at ficticious example that displays the module in a Definition List (a set of DL's, DT's and DD's).
+
Creating your own chrome is easy. Let's look at example that displays the module in a Definition List (a set of DL's, DT's and DD's).
  
 
Just add the following function to the /html/modules.php file in your default template directory (create it if it does not exist):
 
Just add the following function to the /html/modules.php file in your default template directory (create it if it does not exist):
Line 227: Line 243:
 
function modChrome_dlist($module, &$params, &$attribs)
 
function modChrome_dlist($module, &$params, &$attribs)
 
{ ?>
 
{ ?>
<dl class="<?php echo $params->get('moduleclass_sfx'); ?>">
+
  <dl class="<?php echo $params->get('moduleclass_sfx'); ?>">
<?php if ($module->showtitle != 0) : ?>
+
      <?php if ($module->showtitle != 0) : ?>
<dt>
+
<dt>
<?php echo $module->title; ?>
+
    <?php echo $module->title; ?>
</dt>
+
        </dt>
<?php endif; ?>
+
    <?php endif; ?>
 
<dd>
 
<dd>
<?php echo $module->content; ?>
+
    <?php echo $module->content; ?>
</dd>
+
        </dd>
</dl>
+
    </dl>
 
<?php
 
<?php
 
}
 
}
Line 250: Line 266:
 
* content is the output of the module (from its layout)
 
* content is the output of the module (from its layout)
  
This is a very simple case and you can of course design more complex styles, possibly using custom atrributes in the XML tag.
+
This is a very simple case and you can, of course, design more complex styles, possibly using custom atrributes in the XML tag.
 +
 
 
== Pagination Links Overrides ==
 
== Pagination Links Overrides ==
  
The final override we will look at is the pagination override. This override can control the display of items-per-page and the pagination links that are used with lists of information, as shown in the following screenshot.
+
The final override we will look at is the pagination override. This override can control the display of items-per-page and the pagination links used with lists of information, as shown in the following screenshot.
  
 
[[Image:Article_list_pagination.png|Typical Joomla! page showing a paginated list.]]
 
[[Image:Article_list_pagination.png|Typical Joomla! page showing a paginated list.]]
  
The rhuk_milkyway template provides a well commented example for this override. The file is found here:
+
The rhuk_milkyway template provides a well-commented example for this override. The file is found here:
  
 
/templates/rhuk_milkyway/html/pagination.php
 
/templates/rhuk_milkyway/html/pagination.php
  
When the pagination list is required, "Joomla!" will look for this file in the default templates. If it is found it will be loaded and the display functions it contains will be used.
+
When the pagination list is required, Joomla! will look for this file in the default templates. If it is found, it will be loaded and the display functions it contains will be used.
  
 
There are four functions that can be used:
 
There are four functions that can be used:
Line 282: Line 299:
  
 
== Cheat Sheet ==
 
== Cheat Sheet ==
 
+
Using the rhuk_milkyway template as an example, here is a brief summary of the principles we've looked at.
Using the rhuk_milkyway template as an example, here is a brief summary of the priniciples we've looked at.
+
 
=== Customise the Component Output ===
 
=== Customise the Component Output ===
 
 
To override a component layout (for example the default layout in the article view), copy:
 
To override a component layout (for example the default layout in the article view), copy:
  
Line 297: Line 312:
  
 
=== Customise the Module Output ===
 
=== Customise the Module Output ===
 
 
To override a module layout (for example the Latest News module using the rhuk_milkyway template), copy:
 
To override a module layout (for example the Latest News module using the rhuk_milkyway template), copy:
  
Line 309: Line 323:
  
 
=== Add New Module Styles ===
 
=== Add New Module Styles ===
 
 
To add new module styles (chrome), add them to the following file:
 
To add new module styles (chrome), add them to the following file:
  
Line 317: Line 330:
  
 
=== Customise the Pagination Links ===
 
=== Customise the Pagination Links ===
 
 
To customise the way the items-per-page selector and pagination links display, edit the following file:
 
To customise the way the items-per-page selector and pagination links display, edit the following file:
  
Line 325: Line 337:
  
 
== Conclusion ==
 
== Conclusion ==
 
+
Joomla! 1.5, through the use of an MVC paradigm has greatly improved the flexibility that is afforded to Web site designers. By way of a few simple principles, like copying certain files to certain places in your template, the designer is able to override almost all the output generated by Joomla!.
"Joomla!" 1.5, through the use of an MVC paradigm has greatly improved the flexibility that is afforded to Web site designers. By way of a few simple principles, like copying certain files to certain places in your template, the designer is able to override almost all of the output generated by "Joomla!".
+
 
+
If you have any questions relating to output overrides please let us know so that we can improve this tutorial.
+
 
+
If you have translated this article into another language, please let us know.
+

Revision as of 02:59, 28 December 2013