Joomla! 1.5x Customization: Make Your Site Adapt to Your Needs

By Daniel Chapman
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. The Skills Required to Customize Joomla!

About this book

Setting up a basic Joomla! Web site is easy; what comes next is hard and expensive – making the site do exactly what and look exactly how you want. With this book in hand, it is easy to adapt your site to bring your vision fully to life.

This book will help you to separate your site from the crowd of other Joomla! sites without having to invest in developers. It will guide you through how to customize different parts and aspects of your site and will also show you how to turn your site into a profitable business via these customizations. You will be able to build a successful, professional web site that will adapt to all your business needs.

You will be taken beyond the basics of Joomla!, and given an insight into the techniques and tools used by the professionals to rapidly develop unique, custom sites. This will enable you to develop your own professional-quality Joomla! site without assistance, saving you time and money. You will learn how modules, plugins, components, and templates are constructed, and how to make changes in them, giving you the confidence to make more elaborate changes to your site. On top of this will be a look at common problems Joomla! site developers face and how best to deal with them.

You will also learn techniques for building a business with Joomla!, as you step through building a subscription-based web business. Towards the end, you will look at marketing and monetizing this business fully to maximize your return.

Publication date:
August 2009
Publisher
Packt
Pages
288
ISBN
9781847195166

 

Chapter 1. The Skills Required to Customize Joomla!

Before we get into designing and building our new web business, it is important for us to understand how the Internet works and how Joomla! itself fits into the picture. This information will be critical to us later when we want to make changes to our site, or fix problems with it, because without this knowledge we will have little or no idea where to start.

To help us with this, we will look at:

  • The architecture of the Internet

  • HTML

  • CSS

  • Server-side scripting and PHP

  • Client-side scripting with JavaScript

  • Database work with MySQL and SQL

 

The architecture of the Internet


The Internet is primarily based off on a client/server relationship, with client computers, mostly people at home or at their office, connecting to web servers, usually as part of browsing a web site.

Because the web servers are physically separated from the client computers, and could be thousands of miles away, Internet interactions are limited to distinct requests and responses to and from web servers. It doesn't happen instantaneously, like with a native application that is running on our computer. Even though some modern web sites and high-speed connections can seem almost to act like a native application, they still operate in the same way as other web sites, via request and response.

This difference is illustrated in the following figure:

When building a web site, the web developer will put all the files needed for the site onto the web server. Then when a person on their client computer visits the web site using a web browser, they don't actually go to the site. The reality is that the site comes to them. The client sends their request to the web server, the web server sends them a copy of all of the web pages and files that are needed to fulfill their request, and then their web browser assembles the files into a presentable web page, as illustrated in the following figure:

Why is this important? Because it is important to realize that when someone is interacting with our web business, they aren't interacting with it live, but only with its copy that was downloaded onto their computer. This will affect how we approach designing, building, and also fixing our web business.

Note

Modern Internet advances, such as cloud computing, AJAX, caching, and the like have recently produced a growing number of instances that are slightly different to the model given above, or at least appear to be different. However, they all still follow the basic premise of request and response.

 

HTML


Originally, web pages consisted primarily of many individual files, each containing all the design information and data, and links to any images that needed to be displayed on a single viewable page. This information and data was, and still is, written in a language called HTML.

While many people refer to HTML as a programming language, it is in fact, as the name states, a markup language. That is a language that doesn't provide instructions on something to do (a program) but instead, tells how to display itself and the data it contains.

This means that HTML code by itself is not capable of actually doing anything except structuring and displaying static data in a certain way.

HTML works by putting the data inside tags, indicated with greater than and less than symbols, and these tags tell the reader (usually a web browser) how to organize the data structurally.

Some examples of HTML tags:

<h1>This is a level 1 Header</h1>
<p>This is a paragraph</p>
<div>This is a div, used to divide information into logical containers.</div>
<ul>
<li>A List Item (li) in an unordered list (ul).</li>
</ul>
<span>This is a span of text. </span>

An HTML document almost always has at least the following tags:

<html>
<head></head>
<body></body>
</html>

The <head></head> tags are used to hold information about the document which affects the display of the data, but does not actually get displayed on the page itself, whereas the <body></body> tags contain the data that is to be displayed in the web browser.

HTML can also contain extra pieces of information inside the actual tags themselves, and not just between the tags. These bits of information are called attributes. The extra information in these attributes is used to provide extra features and functionality to the HTML when displayed. For example, links and images need to be told where to send people when clicked, or what image to load.

<a href="www.awebsite.com">A link to a website</a>
<img src="www.awebsite.com/logo.jpg" />

We probably noticed that the image tag, <img>, didn't have a closing tag with a slash in it. This is because some tags can be self closed if it doesn't make sense for them to have two tags, such as with our image. To self close a tag, simply put a slash as the last character in the tag.

Note

This is far from a complete guide to HTML, as there are dozens, if not hundreds of guides to HTML online and in book form. Please look to them for more information HTML. Also recommended is the website www.w3schools.com for more detailed information on HTML and its descendant, XHTML.

We can also use a style attribute in our HTML code to add design elements to what is otherwise only a logical structure.

<span style="color:red; font-weight:bold; background-color:yellow">It's an emergency!</span>

Originally, this was how most HTML was styled. However, it was quickly realized that mixing design information, structural information, and the data itself into the same file was dangerous and made updating the data difficult without affecting the design, and updating the design was difficult without potentially affecting the data. So an attempt was made to strip the design information out of the HTML files, leaving only the data and data structure in the original files, and putting the design information into separate files.

This led to what is today called cascading style sheets (CSS), separate files containing the majority of the design information for a web page:

 

CSS


CSS is used to style the logical layout elements of HTML into attractive web sites. It differs from HTML, in that HTML organizes the data on the page into logical containers, and then CSS provides the information needed to then style these containers.

CSS is usually stored in its own file(s) separate to the main HTML document. This is to separate the styling from the logical data structure, so that one of them can be changed or altered without affecting the other, resulting in web sites that are easier to maintain.

Also, if HTML and CSS are in separate files, then one CSS file can be used for many different HTML pages, as opposed to painstakingly putting the styling into each file separately. This allows for site wide changes to the design to be done by editing only a single file. This also naturally saves disk space as well as identical styling information is no longer repeated on every page.

Note

There are times when the CSS code may be required to be written directly into a HTML document. Many of the reasons are the result of dynamic page generation, which we will cover soon. But at these times the CSS should be written between the <head></head> tags.

CSS works via referencing HTML tags and attributes and then applying styles to them.

For example, to style all of our paragraph tags, <p>, to be bold and blue, we could use the following CSS code.

p {
font-weight:bold;
color: blue;
}

Then, all data between any <p> tags on our page would turn bold and blue. As we can see that is much easier than typing the same thing into a style attribute on every single set of <p> tags.

However, sometimes we won't want to style all of the tags on a page identically. What if we want to only style one of our paragraphs, and to give it red text?

If we need to identify individual tags, we can use class and id attributes in our HTML to focus the target for our CSS styles. Class attributes are used for CSS that will style multiple HTML elements in the same way, and id attributes are used for CSS that will only affect unique HTML elements. In other words:

  • class = More than one per page

  • id = A maximum one per page

So let's return to our red paragraph and say that it is for a warning box. The chances are that our warning box will only be used once per page, but there is a possibility that it could be used more than once if there are multiple warnings. So we should choose a class for our attribute. It might look like this:

<p class="warningbox">Be careful when doing this!</p>

Now, into our CSS file we will add:

p.warningbox {
color: red;
}

Notice how after our p we now have .warningbox. The full stop before warningbox indicates that we are after a class. If warningbox was an id, then we would use a hash symbol, #, between p and warningbox.

But what about when there are two or more declarations that overlap? Such as:

p {
font-weight:bold;
color: blue;
}
p.warningbox {
color: red;
}

Do we get red or blue <p> tags? Are they all bold or not?

Referring back to the full name of CSS, the C in it stands for Cascading. This is because when several styles attempt to affect the same HTML, a set of rules are applied that give priority to certain styles, and allow others to flow down, in a logical cascade.

Generally, the cascade is dictated by the following rules, with number 4 having the highest priority:

  1. Browser Default Style

  2. External Style Sheet (loaded from a different file)

  3. Internal Style Sheet (inside the <head> tag)

  4. Inline Style (written in the style attribute in an HTML tag)

On top of these rules, the more specific a rule is, the higher its priority, with classes outranking basic HTML elements, and ids outranking classes.

So given the above rules, and looking back at our two rules for <p> tags listed above, the following will happen:

  • All <p> tags on the page without a class of warningbox will be colored blue

  • All <p> tags with a class of warningbox will override the blue color with red because it is more specific

  • All <p> tags will be bold, regardless of class, as the font-weight style cascades down

When including CSS styles in the <head> tags of a document we will need to put them inside their own <style> tags such as:

<head>
<style type="text/css">
p {color:blue}
</style>
</head>

Did we notice the type="text/css" attribute? This is not technically required, but is highly encouraged and recommended to future proof a web site. Not doing it is considered bad practice by many developers.

When putting CSS styles into a separate file there is no need to put <style> tags into the CSS file, the styles can just be written directly into the file.

However, in the HTML page we use <link> tags to load the external CSS file, and put these into the site header, similar to what we did above.

<link rel="stylesheet" type="text/css" href="/cssfile.css" />

Usually this tag will be used exactly as it is here and will only need the href attribute changed to point to the correct CSS file.

In a Joomla! site, most of our CSS references will come from one of three places, either from our site template, the frontend or admin template, or the references will come from extensions we have installed. Usually these are components, but modules and plugins can also add their own CSS references in.

Note

As with the HTML section, this is far from a complete guide to CSS, and there are an equally large number of books and online resources available to study CSS. Also I recommended again is the website www.w3schools.com for more detailed information on HTML, and its descendant, XHTML.

CSS gives us a lot of power to style our site, and prevents the same styles from being repeated in the HTML files for every page of the site and consolidates them into one file. But what can be done about repeated HTML? Quite a lot of our site's logical structure will be identical on every page, things such as our company logo, menus, headers, advertisements, and other things all look the same on every page, so why are we wasting time and disk space recoding them over and over?

It was this last type of thinking that lead to the next step in web site evolution, "dynamically generated HTML" via "server-side scripting".

 

Server-side scripting and PHP


Server-side scripting is a web server technology that replaces the use of static, unchanging HTML pages with dynamically generated HTML pages. The pages are generated by scripts on the server (hence the name) when requested and passed back to the browser.

These dynamically generated pages have a number of significant benefits over static pages:

  • Easier maintenance, because there is usually only a single copy of any site-wide HTML

  • Content can change and react to user preferences or input

  • Content can be added or changed without changing any HTML

  • Sites are often constantly evolving and improving as users and developers alike add content to the site via dynamic communication technologies such as forums or comments

  • Much faster to make updates to the entire site layout

There are many different languages that can be used for server-side scripting, but since Joomla! uses PHP, so we will be focusing our studies there.

A dynamic, PHP powered, site's structure differs from a static web site in several key ways:

  • There is usually only one main file that is ever called from the browser, almost always named index.php, and different pages are generated according to parameters passed to the server from the client.

  • Usually a database or data files of some sort are used to separate the raw data from the HTML, and they are then assembled upon the user's request.

  • A PHP web site only sends generated pages to the client. Pages that do not actually exist on the server as a file in the form that the client receives them. However, most static HTML sites send exact copies of the HTML files that are on the server.

  • Instead of a mass of HTML files, there are usually fewer files, and they contain mainly scripting code, and much less HTML.

Note

Because PHP runs on the server, our client browser only ever downloads the already generated HTML and never sees, nor even knows about, the PHP.

Joomla!, like most PHP sites, uses the file index.php as the primary gateway to a site. This file receives the requests from the browser and then calls the appropriate PHP functions needed to create a page that matches the request. However, please note that we will usually never change any of the code inside a Joomla! site's index.php file because all it does is call other files, many of these are template or extension files. It is the template and extension PHP files that we will usually be editing.

Note

Joomla! templates also include an index.php file. This index.php file and the Joomla! core index.php file are different and serve different purposes. Editing a template's index.php file is a very common practice, unlike the core Joomla! file. Be careful when you start opening any index.php files to make sure you are editing the right one.

As mentioned above, most PHP generated sites, including Joomla! use a database to store their raw data. This makes it much easier, and faster, to retrieve data when it is requested by the user. It also allows powerful data operations and functions to be performed on the data if needed, such as aggregating it, sorting it, or making it easier to read.

The most common database for PHP sites, and the one used by Joomla! is MySQL. It is popular because not only is it open source and requires no cost to download and install, but it is also very reliable and powerful.

PHP code is designed to operate in two main methods. First, it can be run as complete PHP file. Usually these files are used for data processing, function declarations, or other unseen work.

The other method is to embed PHP into HTML code, usually to add loops, conditions, and load data into the otherwise static HTML, and usually these mixed HTML/PHP files are used as templates, or parts of templates, for displaying data on a site.

PHP can be easily recognized by the telltale <?php … ?> tags around sections of code. These tags are needed to complete PHP files and appear at the very start and end of the file. However, in a mixed HTML/PHP file, there are usually many, shorter code sections and tags.

Note

PHP is a detailed and complex language and there is no way we could cover it in any usable detail in this chapter. Instead, it is recommended again that you find some of the many great online and offline resources. One of the best sites to get PHP information is www.php.net, which contains a complete list of the available functions and commands for PHP. You can also pick up one of the great PHP books from Packt Publishing (www.packtpub.com/php-mysql)

The basic operation of a Joomla! site revolves around the index.php file, calling the PHP files for the extensions and template required by the client request, and then assembling the HTML code output by them into a page and then sending it to the client. Extension PHP files usually reside in a /components/com_componentname directory, /modules/mod_modulename, or /plugin/plugintype/plg_pluginname and templates in a /templates/templatename folder.

Note

Plugins were not included in the preceding diagram because they execute at many different times throughout the site.

MVC programming and PHP

From Joomla! 1.5, the PHP code architecture has been converted into what is called a Model-View-Controller (MVC) architecture. MVC is an attempt to separate business logic from data and from the user interface, with the model representing the data, the view representing the user interface, and the controller representing the business logic.

This is easily seen with Joomla! Extensions, which will often have model, view, and controller subfolders containing the relevant MVC PHP files for that extension.

The files in the view folders are most likely to have PHP and embedded HTML files, and the model and controller folders should only contain fully PHP files.

Note

For more information about PHP and MVC within Joomla! extensions, I highly recommend the book Joomla! Extension Development, also from Packt Publishing.

PHP does have limitations though. Its dynamically generated pages still look fairly static by the time they reach the client, and PHP operates on the server, so what do we do if we want some dynamic activities on the client?

This question brings us to client-side scripting, and JavaScript.

 

Client-side scripting and JavaScript


Client-side scripting was designed to fill a similar purpose to server-side scripting, to add dynamic features to otherwise static HTML pages, but with a completely different target. Where server-side scripting is used to make the generation of HTML dynamic, client-side scripting is used to make the interaction with HTML dynamic. This operation is conveniently referred to as Dynamic HTML or DHTML.

DHTML refers to anything constructed out of HTML which is then animated, updated, re-colored or otherwise changed in some fashion via scripting languages such as JavaScript or VBScript. It is the power behind many tabs, slideshows, sliding menus, validation for forms, and much more.

In the same way that Joomla! uses PHP for its server-side scripting, it also uses JavaScript for its client-side scripting. So we will place our focus on understanding how JavaScript works.

Similar to CSS, JavaScript, often just called JS, can either be entered directly into a HTML document or loaded from an external file which is the preferred method. The main differences are in the syntax for doing so.

Where CSS uses <style> tags, JS uses <script> tags when entering it into an HTML file, as shown:

<head>
<script type="text/javascript">
var someVariable = "a value";
</script>
</head>

Notice how we have entered the type attribute again, only this time it says text/javascript and not text/css .

When loading external JS files, the syntax is also similar, but different, to CSS.

<script type="text/javascript" src="myJSScript.js"></script>

Unlike CSS, which has different tags for loading external files and entering directly into the HTML file <link> and <style> respectively, JS uses the same tags, <script>, for both operations. The main difference being that external files are loaded by adding a src attribute to the tags, indicating source, which contains the address of the required JS file.

Note

JS is just as detailed and complex a language as PHP, so again it is recommended that you find some of the many great online and offline resources. One of the best sites to get JS information is one you will already be familiar with, www.w3schools.com. Or, alternatively, pick up one of the many great JS books also from Packt Publishing (www.packtpub.com/ajax)

Asynchronous JavaScript and XML (AJAX)

AJAX, is an Internet buzzword that many people will be familiar with but few understand it properly. Many people attribute moving and sliding elements on a web site to AJAX, when in reality these are usually just DHTML. AJAX, in reality, refers to a process of making requests to the server, usually via something called the XMLHttpRequest object, in the background to send or retrieve data to and from the web server without having to reload the entire page. This is the normal practice for a web site.

For example, a set of tabs that loads all the data at the same time as the page loads and then shows them one at a time is DHTML.

But a set of tabs that dynamically loads the data for each tab one at a time from the server, after the page has already loaded, and when the tab in question is selected by the user is AJAX (and DHTML for the actual showing/hiding of the tabs).

AJAX offers several advantages for web sites:

  • Initial page load times are reduced as not all data is needed up front

  • Interaction with the page seems faster as new information can be grabbed on request, without full page reloads

  • The pages feel more like a native application with live feedback than a web site with a fixed request/response system

But it also carries some disadvantages:

  • Page changes aren't usually recorded in the browser history, so hitting the Back button on the browser may produce unexpected behavior

  • Disabled visitors, or visitors without JS enabled may not be able to use the site properly

  • Search engines may not be able to index the site properly as they can't record all the changes

Because of these disadvantages, there is a consensus among many professional developers today that JS and AJAX should be used sparingly, and for enhancement of sites that can operate without it, and not as an essential part of the site operation.

JavaScript frameworks—Mootools and jQuery

In web programming terms, a framework is a collection of prewritten program code designed to make it easier to develop using the language that the framework is designed for. The prewritten code usually contains many functions that bundle up more difficult commands needed to do common activities, and makes them far simpler to perform.

These frameworks generally lower the entry barrier for using those languages, and allow less skilled developers to produce far more powerful web sites than they could otherwise.

In the Joomla! community, there are two main JavaScript frameworks that are widely used. The first one is Mootools, which is also included by default in Joomla! 1.5, and is used by many of the larger template clubs. The second is jQuery, a framework favored by many extension developers (though many also use Mootools).

Mootools is most apparent initially on a Joomla! site in the administrator side. Where the accordion effect appears on the right-hand side modules in the control panel, the pop-ups for parameter screens, the attractive tooltips around the site, and more are all thanks to Mootools.

Generally, frameworks don't play well together and the end result of loading two or more on a page is usually that none of them work and all our JS fails. Luckily, however, the jQuery team implemented some commands known as no-conflict mode, which has allowed jQuery to operate alongside other frameworks without a conflict.

The frameworks generally consist of one or more JavaScript files which are loaded onto our page like normal JavaScript. After loading these scripts, we are free to call the functions from these frameworks and use them in our own JavaScript, saving us time and effort.

One of the main drawbacks with frameworks is that they are almost always going to be larger than we need and include functions that we are never going to use. This can affect our site performance, as we will discuss later.

The other main drawback, as noted above, is that of potential conflicts. Personally, the largest single support problem I encounter in my day-to-day work is without a doubt because of JavaScript framework conflicts. In the later chapter, we will cover how we can determine if a JavaScript framework has caused our site problems, and how to diagnose and fix those problems.

Note

More information about Mootools and jQuery can be found at their respective sites, http://mootools.net and http://jquery.com. Also there are many useful titles available at http://www.packtpub.com/ajax.

 

Database work with MySQL and SQL


Jumping back to the server, an understanding the technologies behind Joomla! can't be considered complete without a discussion on Structured Query Language (SQL). SQL is the language of choice for most databases, and anytime we want to add or retrieve data from the database of a Joomla! site, we will need to do it via SQL.

SQL is a relatively straightforward and simple language to pick up, but it can get quite complex at higher levels of development. It is designed purely to interact with data in a database and can do very little else.

The four most common SQL commands we will use are:

  • SELECT

  • INSERT

  • UPDATE

  • DELETE

There are others, but these are the ones we will need to know most.

Following one of these initial commands will usually be a preposition and a table name. Or it could be a comma separated list of columns, then the proposition and table name and is written in fairly easy to understand language. For example:

SELECT name, address FROM person_table …
INSERT INTO person_table …
UPDATE person_table …
DELETE FROM person_table …

For SELECT, UPDATE, and DELETE, there will also usually be a WHERE clause that provides the criteria upon which to do the search.

SELECT name, address FROM person_table WHERE age > "16"
UPDATE person_table … WHERE name = "John Doe"
DELETE FROM person_table WHERE name = "John Doe"

For INSERT queries, there will also be a set of values to insert, and possibly a list of columns to INSERT INTO.

INSERT INTO person_table (name, address, age)
VALUES ( "John Doe","10 This St, Atown","25")

For UPDATE queries, they are again a little different, but easy to understand.

UPDATE person_table SET address="25 Anew St, Atown" WHERE name = "John Doe"

Something we will sometimes see with SELECT statements is the use of an asterix (*) character in place of a column list. This is shorthand to indicate that we want to use all of the available columns, arranged in the same order as they appear in the database.

SELECT * FROM person_table WHERE age > "16"

Something we will quickly notice if we are looking over existing Joomla! database queries is that almost all of them will have a hash and two underscores before the table name. For example:

SELECT * FROM #__person_table

This hash underscore is replaced at run time with the current database prefix. So #__person_table will be converted into something similar to jos_person_table by the Joomla! database functions when they run the query.

The database prefix exists to allow people to install multiple Joomla! sites and use the same database for all of them, without the data for each one overwriting the others. The different sites can then just use different prefixes, and that way they keep all their data in separate tables.

Note

As with all of our programming topics, there is a lot more useful information available on the Internet regarding MySQL and the SQL programming language (sites such as http://www.w3schools.com/SQl/default.asp).

 

Summary


We should by now have a basic understanding of the main technologies and programming languages used by a Joomla! site. Enough at least to allow us to tell the difference between a CSS file and a JavaScript file, between PHP and HTML, and so on.

It is strongly recommended that anyone serious about his or her site take their studies of these technologies further and builds up their skills with them. Even if they themselves are not going to do most of the development, perhaps they have hired developers for example, understanding these things will still make communicating with those developers much easier.

About the Author

  • Daniel Chapman

    Daniel Chapman has been working in IT since 1995, firstly as an Oracle Database consultant and trainer, then in freelance web development, and now as a Joomla extension developer. He is the founder and CEO of Ninja Forge, a leading Joomla! extension club. Currently based in Japan, he is an entrepreneur with extensive experience in designing and customizing sites, as well as in building successful web-based businesses, having worked on the design and development of several.

    Browse publications by this author
Joomla! 1.5x Customization: Make Your Site Adapt to Your Needs
Unlock this book and the full library for FREE
Start free trial