How Joomla! builds a webpage (annotated)

How Joomla!
Builds a Web Page
implications for flexibility, plugins, cache, and special formats
Randy Carey
Careytech Studios, LLC
Careytech.com

agenda
 Joomla! as a CMS
 Joomla’s Flexibility
 MVC
 How Joomla builds a page
 plugins
 caching
 APIs / JSON responses

I feel Joomla is a true CMS. While it does generate
websites, look deeper and you’ll see it manages content
and metadata as independent of the output type (a web
page, an RSS feed, JSON, etc).
As a true CMS, Joomla has a process for how it takes the
content and builds the output that is requested. We’ll be
looking primarily at Joomla builds a webpage.

dynamic CMS
vs static
The original websites were a
collection of HTML files, each
edited and managed by hand
and per file
These days a dynamic CMS separates
content from formatting and the page
layout. The page is build frequently
so it can use the most recent versions
of content and layout.

Flexibility
This diagram reflects the considerable flexibility that
we get from Joomla. Let’s review each “flex point”
to help us appreciate the flexibility this system buys
us…

Flexibility 1. A Modules is assigned to ONE particular position.
2. A Module is assigned to its own set of menu
items (all, none, or a custom selection).
… I bet you already knew that

Flexibility3. Each template has its own set of named module positions. So …
• a particular position name may exist in one template, but not in another.
• Also, for any given template, the same name may occupy a different position
within the layout. The example below suggests this.
If we introduce multiple templates (or template styles) within our installation, we
have the opportunity to introduce a lot of flexibility

Flexibility
4. Each menu item has a dropdown field allowing you to declare which template it
should use. Typically we ignore it and Default is always used. But there is
nothing stopping you from setting that field so that certain menu items use a
variant template.
Since each template can layout the positions differently (and apply different
styling), we have the potential additional flexibilities that you probably have not
even thought about. … Let me show you an application of this…

Flexibility
default CTA media-room mods-only
I use Gantry 5, and that framework allows me to set a different layout for each
template style. (same template, different “style”) In this example, the layouts and some
position names differ across templates.
Consider CTA (call-to-action). If a page is set to a CTA template, that page will
automatically the CTA module (a sidebar form) that I set up for the site.

Flexibility
The template/style assignment is
made on the menu item. All my
styles are listed as an option.
In this example, I can set a page
to a layout that will exclude the
component.

Flexibility
overrides
5. But let’s not forget that alternative layouts (overrides)
also introduce flexibility. Create multiple module
templates and the user can select alternate outputs.
These can vary slightly or greatly.
…Flexibility accessed through a simple dropdown field.

Flexibility
overrides
This diagram reflects 1, 2, 3, 4, FIVE
flex-points that provide the
considerable flexibility we get from
Joomla’s module system.

MVC
You’ve probably heard of Joomla’s MVC. Each component has its own set.
(some rogue developers try to short-circuit this, but that is another story)
This is an important feature of Joomla’s architecture. We’ll just summarize…

MVC
The component’s Controller
interprets the request that is
implied by the URL. It then
creates and launches the
correct model-view objects.
(example: the MVC to display an article
versus the MVC to display a category
list)
It should be noted that each Model-
View pair can have its own controller to
handle view-specific tasks such as
logging in a user or performing front-
end editing tasks.

MVC
The Model manages the data
that flows between a
component and the database.
It implements things like
save, update, delete, as well
as maintaining rules (such as
returning only content that the user is
allowed to access).

MVC
Each View knows its output type
(HTML, RSS, etc) and orchestrates
function calls accordingly. These
functons could be for setting
metadata or managing pagination.
For an HTML page, it calls upon the
appropriate template to build the
HTML using the data that the
model provided.

MVC
1. execute( )
2. display( )
3. gets/returns data
4. injects metadata/CSS/JS, other housekeeping.
5. calls upon template to render the HTML
using the data it received
is created
creates respective View
asks its Model for data
The red text below outlines the order of steps taken
by a component when a webpage is being built.

A. We’ve outlined the flexibility we have with Joomla’s module
system.
B. We’ve summarize what happens when a component is invoked
during the page-building process.
C. Now… Let’s step back and look at the steps Joomla
takes as it builds a web page …. From the time it
gets a URL to the time it sends the respective
HTML back to the requesting browser.

How Joomla builds a page
1. loads Joomla framework, gets user session
The next slide show some of
the things that get set up

Document
Application
JFactory
Session
PATHS: /home/public_html/…
Cookies
Server variables
• URL parameters
• language
User

2. determines parameters (option, etc)
Every page has one and only one component. This is
always implied by the URL.
Joomla’s routing system parses the URL to determine
the component as well as other related settings (such
as view, id, or task)

option = com_content
view = article
id = 758
itemid = 133
task =
template =
format =
Router Parses URL
These values are obtained
from parsing the URL
and possibly from GET/POST values.

3. render Component
Now that we know what component to call and we have all the
variables it expects, we ask the component to render itself into HTML.

3. render Component
Document • Rendered HTML
• Title
• Styles
• Scripts
• Metadata
• Base URL (SEF)
The Document object stores
the HTML for this component
along with other values
associated to what was
rendered.
NOTE: Joomla is just building the pieces and storing each. It has
yet to assemble them into any type of output (such as a webpage).

3. render Component
4. determine template and module positions

Document • template HTML
• template name
• Styles
• Scripts
• Module Positions (template tags)
Again, each piece is stored
within the Document object.
In addition to the template’s
HTML, other pieces include CSS
and JS declarations, as well as
a list names for each module
position held by the template.

• template name
• Styles
• Scripts
Note:
Only those position names
found within the template are
stored. When Joomla renders the
modules, it will consider only those
modules belonging to a position
within the template.
Consider the “component” template that is
meant to display just the component but no
modules: It contains no module positons.

• template name
• Styles
• Scripts
only if
format is
HTML
If the format is to be RSS,
JSON, or something other
than HTML (a webpage),
then there is no need to
process a template.

3. render Component
5. render modules

5. render modules
For each module position to be
processed, Joomla queries the
database for those modules.
In addition to module position, the
query also limits results to the current
menu item, the current language,
the current access level, and a state
of published.
Each module returned by the database
is rendered individually…

5. render modules
Document • modules HTML
For each module:
• HTML
• Styles
• Scripts
Each module’s HTML is stored
in the Document.
If a module includes a
dependency upon a CSS or
JS file, that reference is
added to the Document.
What happens if the same CSS or JS is
included by multiple modules? …

5. render modules
Document • modules HTML
For each module:
• HTML
• Styles
• Scripts
What happens if the same CSS or JS
is included by multiple modules?
No problem. The document will keep
only one reference to a file if
duplicates are added during the
page-building process.

3. render Component
5. render modules
6. assemble parts into page / output
At this point we have all the HTML pieces,
metadata, and JSS/CSS references
collected.
Time to let Joomla assemble all these
parts into the page according to the
template.

Document
• Styles
• Scripts
• Metadata
The document is holding all the
parts. Time to assemble them
into the output (in our case, a webpage)

• page HTML

• page HTML
if page is
not cached
If page-caching is on and the page was cached…
the page-building process concluded a few steps
back – we would never reached this point.

3. render Component
5. render modules
7. send page to browser (output to requester)

• onAfterInitialize
• onAfterRoute
3. render Component
• onAfterDispatch
• onBeforeRender
5. render modules
• onBeforeCompileHead
• onAfterRender
Interspersed between
each of these steps is a
call to one of the events
that triggers the system
plugins.
Because each of these
steps represent some
completed state within the
page building process…
a system plugin can inject
additional processing at
any of these points in the
page-building process.

System Plugin Events
When a client asks for some customization, I often can accommodate with a
custom-built system plugin. Here are some example requests that can be
handle as such…
• Redirect all anonymous users to a login page
• Block a given user from accessing any page belonging to a
particular component
• Make sure only one copy of JQuery is added to the header, and
select the most recent version.
• Replace the text {current-time} with the current time – within just
the component .. anywhere within the HTML page … and time zone
or format adjusted according to user, language, or IP address
• Add ® behind each instance of a particular brand name.
• Suppress certain module positions based upon the user’s usergroup.
• Store the last five viewed shop products in a cookie so that you can
display the most recently viewed products in a module.
• Add a css file to every page.
• … more than anyone can think of …
If you understand how Joomla builds the webpage, you’ll know which event
you use to add your custom code.

System Plugin Events
• onAfterRoute
3. render Component
• onAfterDispatch
• onBeforeRender
5. render modules
• onAfterRender

plugins & plugin events
 system : as a page builds
 content: as content is created/edited/deleted
 authentication : identify user by login, LDAP,
Facebook, etc.
 user : create/manage users, react to login/logout events
 search: indexing content as it is changed
 …others…
 custom
The book to read to learn
about coding Joomla plugins

caching
-VS -
Page caching Module caching

caching
html
<head>
<body>
Page cache is the simplest and fastest.
The entire HTML for a page is retrieved
and used instead of rebuilding the page.

caching
Page : system plugin
Page Caching is a system plugin

caching
1.loads Joomla framework,
gets user session
2. determines parameters
(option, etc)
• onAfterRoute
3. render Component
4. determine template and
module positions
5. render modules
6. assemble parts into
page / output
7. send page to browser
(output to requester)
The Page Cache plugin is triggered
by onAfterRoute()
If a cached version of the page is
found, that is returned and the
plugin halts the page-building
process – saving valuable time.

caching
Sometimes part of the page is
dynamic and needs to be built
based upon the user or
something that changes often.
(Examples: user profile, a
module should display only to
a particular access level, a
twitter feed, etc.)
If a site has conditional
modules, we must cache
per module.

caching
Let’s say the events list
changes often so it’s
module should not be
cached…

caching
module
<div>…
</div>
When modules are
rendered, each module will
try to get a cached HTML
instead of investing time to
make database calls and
build the HTML. …
…However, our dynamic
module is set to never
cache (i.e., it is to render its
HTML on each page visit).

caching
gets user session
(option, etc)
3. render Component
module positions
5. render modules
6. assemble parts into
page / output
7. send page to browser
(output to requester)
All 7 steps are processed,
however, caching speeds up
the results of steps 3 and 5
(which are the most costly steps
regarding time to process)

cachingcaching
module positions
selects modules to render by:
• Position
• Page (menu item)
• State
• Language
• Access level
then…
5. render modules
Unlike Page caching, Module
caching still processes each
module based upon the points
in red.
Important: Module caching
accommodates a module’s
Access Level – an important
feature that will not be caught
by page caching.

caching
per Module : config and module settings In the Global Settings:
Select Conservative caching
In each module:
If a module is not to be
cached, set its cache to No
Cache. Otherwise, leave
that field set to Default so it
will be cached.

APIs and JSON
https://mysite.com/departments/data
As a true Content Management System,
Joomla allows its content to be returned
in any format. A common request is to
return content in the JSON format and
in response to an API call.
Using our knowledge as to the steps
Joomla follows in building output, let’s
think through how we can do this.

APIs and JSON
The “view” approach
has us create a sibling
view file, but with a
format of JSON instead
of HTML (view.json.php)
In that file we can do
something simple like
get the data, format it
as JSON, echo the JSON
string, then exit() from
the output-building
process.
Rather simple.

APIs and JSON
gets user session
(option, etc)
3. render Component
(done)
Here are the page-building
steps used for this approach.

APIs and JSON
Another approach is to use a system plugin.
The plugin evaluates the request implied by the
URL. If the plugin determines the URL is a valid
API request, it makes a database call to gather
the information, converts the data to JSON,
echo() the JSON string, and exit() from the
output-building process.
This actually saves us one step…

APIs and JSON
1. loads Joomla
framework, gets user
session
(option, etc)
• onAfterRoute
(--done--)
3. render Component
With the plugin approach, we don’t
need to add a JSON view and the
component is never called.

Review
overrides
Joomla was crafted to be very flexible.

Review
• onAfterRoute
3. render Component
• onAfterDispatch
• onBeforeRender
5. render modules
• onAfterRender
The steps Joomla uses to build a
webpage (or any other output format)
allows for…
1. Plugins, which can inject
custom processing upon the
page and its pieces
2. Caching (even module-specific)
3. Variant outputs such as RSS,
JSON, or any new format
that may emerge in the
future

How Joomla! builds a webpage (annotated)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a How Joomla! builds a webpage (annotated)

Similar a How Joomla! builds a webpage (annotated) (20)

Más de Randy Carey

Más de Randy Carey (7)

Último

Último (20)

How Joomla! builds a webpage (annotated)

Notas del editor