30
października
2010
Strony błędów (error.php) oraz logowania (offline.php) są generowane w trochę inny sposób niż zwykłe strony szablonu. Nie mamy w nich bezpośredniego dostępu do parametrów naszego szablonu. Na szczęście możemy to łatwo naprawić.
Parametry szablonów są przechowywane przez obiekt klasy JParameter. Nadpisywane przez nas pliki stron błędów i logowania znajdują się w głównym katalogu szablonu. W tym samym katalogu znajduje się też plik params.ini, który przechowuje informacje o wartościach parametrów szablonu. Dodatkowo konstruktor klasy JParameter przyjmuje jako pierwszy argument ciąg danych w formacie znanym z plików *.ini.
Zatem wystarczy wczytać plik params.ini i tak odczytane dane podać jako argument konstruktora klasy JParameter aby uzyskać dostęp do potrzebnych nam danych. Całość wymaga dosłownie jednej linijki kodu PHP:
$tpl_params = new JParameter(JFile::read(dirname(__FILE__).DS.'params.ini'));
Odczyt wartości parametrów szablonu odbywa się poprzez następujący kod:
$opcja1 = $tpl_params->get('NAZWA_OPCJI');
Dzięki temu możemy nie tylko odczytywać ważne dla nas parametry szablonu, ale też definiować w szablonie nowe opcje związane ściśle z plikami error.php i offline.php
28
października
2010
Moduł mod_custom to bardzo użyteczne narzędzie, jednak brakuje mu jednej ważnej rzeczy: jego zawartość nie jest parsowana pod kątem zawartości pluginów. Na szczęście można łatwo ten problem rozwiązać.
Wystarczy zmodyfikować sposób generowania styli modułów. Style te znajdują się w pliku html/modules.php większości szablonów, które takie style stosują.
Musimy zmodyfikować funkcję modChrome_NAZWASTYLU - na pewno znajduje się w niej linijka podobna do tej:
echo $module->content;
Odpowiada ona za wyświetlanie treści modułu. My musimy zmienić ją na następujący kod:
echo ($module->module == 'mod_custom') ? JHTML::_('content.prepare', $module->content) : $module->content;
Powyższy kod sprawdza typ modułu i w wypadku gdy jest to moduł typu mod_custom do generowania treści wykorzystywanie jest parsowanie pluginów, w przeciwnym wypadku treść generuje się tak samo jak przed modyfikacją.
W wypadku gdy szablon nie używa własnych styli modułów musimy odbyć małą podróż wgłąb kodu źródłowego szablonu system - predefiniowane style modułów dla Joomla! znajdują się w pliku templates/system/html/modules.php.
Uwaga! ten sposób parsowania kodu pluginów jest dużo lepszy niż niektóre inne metody. Widziałem przykładowo rozwiązanie bazujące na modyfikacji pliku index.php, gdzie po zdarzeniu onAfterRender był umieszczony kod parsowania pluginów. Problem polegał na tym, że przy takim wywołaniu pluginy nie mogą już modyfikować sekcji head szablonu (problem tego typu już opisywałem).
12
października
2010
Dobór stylu modułu poprzez dodanie konkretnego sufiksu w opcjach modułu to standard. Ostatnio coraz częściej korzystam z innego udogodnienia, które gwarantuje mi dużo większą elastykę przy określaniu stylistyki modułu - przekazywanie parametrów w tytule modułu.
Koncepcja ta ma dwie główne zalety:
Decydujemy się, że chcemy stworzyć styl modułu, który np. w swoim prawy górnym rogu wyświetla ikonkę kanału RSS. Oczywiście adres tego kanału jest różny dla różnych modułów, a dodatkowo chcemy mieć taką ikonkę przy różnych modułach. Zatem logiczne jest, że lepiej stworzyć ze stylu modułu swoisty kontener na te dane, zamiast przerabiać kilka modułów by dodać im taką funkcjonalność.
Jedyny problem to właśnie przekazywanie parametrów takiemu stylowi modułu - i tutaj rozwiązanie jest dość proste: dodajemy po tytule modułu np. w nawiasach klamrowych adres kanału RSS:
Tytuł naszego modułu {http://adres.rss.pl}
Teraz wystarczy tak zdefiniować funkcję generującą styl modułu, by wydobyła ów adres z tytułu modułu - czyli w skrócie musimy wykonać kilka elementarnych operacji z użyciem wyrażeń regularnych:
$title = $module->title;
preg_match('/\{.+?\}/', $title, $address);
$title = preg_replace('/\{.+?\}/', '', $title);
W powyższym wypadku wystarczy potem dokonać sprawdzenia:
if(isset($address[0])
by wiedzieć czy w ogóle podano parametr, a jeżeli tak to właśnie zmienna $address[0] przechowuje jego wartość.
Oczywiście sami możemy sobie zdefiniować sposób podawania parametrów - równie dobrze możemy wykorzystywać nawiasy kwadratowe (choć w wypadku adresów internetowych to zły pomysł, gdyż takie znaki mogą występować w adresie) czy po prostu ciąg symboli lub symbol stanowiący separator tytułu od parametrów.
Daje to nam naprawdę duże możliwości - przede wszystkim jest to rozwiązanie elastyczne. Oczywiście moglibyśmy przekazywać parametry stylowi modułu poprzez atrybuty znacznika jdoc:include, ale to nam nie daje możliwości powiązania wartości parametru z modułem tylko z pozycją modułu.
Na koniec jeszcze ciekawa koncepcja - przeniesienie sufiksów modułów właśnie do parametrów przekazywanych w tytule. Dzięki temu od razu w menadżerze modułów zobaczymy jaki sufiks nadano konkretnemu modułowi. Przy czym odradzam takie rozwiązanie przy projektach udostępnianych na szerszą skalę - wielu użytkowników jest przyzwyczajonych do opcji "module suffix" ;)
18
sierpnia
2010
Proces renderowania szablonu w Joomla! składa się generalnie z dwóch etapów. Zrozumienie jak on przebiega ma często kluczowe znaczenie dla działania niektórych skryptów. W dzisiejszym wpisie opiszę dość ciekawy i sądzę, że ciekawy przypadek, kiedy to potrzebujemy uzyskać dostęp do finalnej (powstałej po wszystkich operacjach) wersji sekcji head naszego szablonu.
Problem na jaki się ostatnio natknąłem, polegał na tym, że potrzebowałem zmienić kolejność kilku plików CSS dodawanych przez niektóre moduły do sekcji head szablonu.
Niestety - ze względu na ideę parsowania szablonów w Joomla! nie da się tego zrobić tworząc zwykły kod operujący na sekcji head dokumentu - w czasie gdy będzie się on wykonywał, pliki CSS/JS dodawane przez moduły/komponenty nie będą jeszcze w niej dostępne. Dlaczego ? Joomla! parsuje szablon w dwóch etapach - najpierw parsowany jest kod szablonu wraz z towarzyszącym mu kodem PHP, a dopiero w drugim etapie następuje podmiana wstawek jdoc na właściwie im fragmenty strony. Co za tym idzie dopiero wtedy wykonywany jest kod modułów i komponentów.
W wielkim skrócie proces ten wygląda następująco:
Jeżeli w naszym szablonie wykonujemy jakiś kod operujący na sekcji head to występuje on na etapie pierwszym. Natomiast część danych w sekcji head pojawia się dopiero na etapie trzecim. Co za tym idzie jedyne miejsce w którym możemy operować na kompletnej sekcji head jest etap czwarty.
I w tym momencie mamy dwa wyjścia:
I na tym drugim rozwiązaniu się skupimy gdyż wymaga ono aż 2 linii kodu ;) Musimy mianowicie stworzyć obiekt klasy JDispatcher, który odpowiada za generowanie zdarzeń i rejestrację funkcji obsługi zdarzeń, a następnie musimy zarejestrować dodatkową funkcję dla zdarzenia onAfterRender. Cały kod to:
$dispatcher = JDispatcher::getInstance();
$dispatcher->register('onAfterRender', 'NASZA_FUNKCJA');
Oczywiście NASZA_FUNKCJA to nazwa funkcji, która ma zostać podczas zdarzenia wywołana. W ten oto sposób część kodu naszego szablonu wykona się znacznie później w procesie renderowania szablonu.
Pora na złą wiadomość - po drugim etapie renderowania szablonu nie jesteśmy już w stanie modyfikować sekcji head z użyciem standardowych metod API - po tym etapie jedyne co możemy modyfikować to zawartość bufora, która ma zostać zwrócona do przeglądarki. Aby dostać się do rzeczonego bufora korzystamy z klasy JResponse:
$buf = JResponse::getBody();
Aby zapisać efekty naszej pracy na zmiennej $buf korzystamy z metody setBody:
JResponse::setBody($buf);
I w ten oto sposób mamy zapisane modyfikacje pełnej sekcji head naszego szablonu.
12
lipca
2010
Szablony dla Joomla! mają tą cechę, że z reguły są dość rozbudowane, zwłaszcza jeżeli chodzi o kod CSS: tworząc szablon trzeba ostylować standardowe podstrony, dodatkowe moduły, komponenty. Im bardziej chcemy zadbać o detale tym bardziej rośnie ilość kodu. Kodu w którym pewne rzeczy się powielają. Dlatego od pewnego czasu jestem zwolennikiem wykorzystywania do tworzenia szablonów prekompilatorów CSS. Jednym z takich narzędzi jest LESS. Pokażę jak bezboleśnie zaimplementować LESS w swoim szablonie oraz jak wykorzystać jego możliwości.
LESS pierwotnie został stworzony w języku Ruby, jednak nie stanowi to żadnego problemu gdyż istnieją jego implementacje w innych językach m.in. w PHP (lessphp) i JavaScript (LESS.js). Wersja JavaScript jest mniej wymagająca pod względem dołączenia do szablonu, natomiast jeżeli wyłączymy JavaScript w przeglądarce to niestety mamy problem. Dlatego bezpieczniej skorzystać z wersji LESS, która działa po stronie serwera.
Tutaj mała uwaga - osobiście polecam korzystanie z LESS tylko na etapie tworzenia szablonu i jego ewentualnych modyfikacji. Dlaczego ? Nie ma sensu by LESS przetwarzał nasze pliki *.less przy każdym wywołaniu strony lub co określony czas (przy wykorzystaniu cache). Dlatego po zakończeniu prac najlepiej zamienić prezentowany kod na odwołania do wygenerowanych z użyciem LESS plików *.css.
LESS rozszerza składnię CSS-a o wiele nowych możliwości. Zacznijmy od mojej ulubionej czyli zmiennych. Większość layoutów ma to do siebie, że bazuje na kilku kolorach. W LESS zmienne tworzymy korzystając z zapisu:
@nazwa_zmiennej: WARTOŚĆ;
Przykład:
@kolor1: #000;
@kolor2: #fff;
#nawigacja{
color: @kolor1;
background: @kolor2;
}
.code{
color: @kolor2;
background: @kolor1;
}
W powyższej sytuacji gdybyśmy chcieli odwrócić kolory w elemencie #nawigacja oraz elementach z klasą code wystarczy zmienić wartości zmiennych. Niesamowicie przydatne gdy mamy ogromny plik CSS z mnóstwem powtarzających się kolorów.
Druga ważna funkcjonalność - zagnieżdżanie elementów. Zamiast pisać:
#nawigacja {}
#nawigacja a {}
#nawigacja a:hover {}
Zapisujemy:
#nawigacja {
/* tu style dla elementu #nawigacja */
color: #000;
margin: 10px;
a {
/* tu style dla linków w #nawigacja */
color:#aaa;
display:block;
/* a tu style dla pseudoklas */
:hover {
text-decoration:none;
}
}
}
Taki zapis jest o wiele czytelniejszy bo często niektórzy próbują kod formatować następująco:
#nawigacja {}
#nawigacja a {}
#nawigacja a:hover {}
By podkreślić, że selektory tyczą się elementów zagnieżdżonych w innym elemencie.
Inna warta wspomniena rzecz to możliwość ponownego wykorzystana raz już stworzonego kodu:
.test{
color:#000;
background:#fff;
}
Teraz możemy osadzić właściwości color i background w innym elemencie pisząc po prostu:
.test2{
.test;
}
Możemy też się odwoływać bezpośrednio do elementów zagnieżdżonych czy nawet do konkretnych wartości właściwości lub zmiennych, a nawet tworzyć klasy z parametrami.
Możliwości LESS są naprawdę duże - zainteresowanych odsyłam do dokumentacji lessphp
My tymczasem wróćmy do meritum tego posta czyli użycia LESS w Joomla!.
Aby użyć LESS polecam najpierw w katalogu zawierającym style CSS szablonu utworzyć katalog less/, który będzie zawierał pliki źródłowe *.less do przetworzenia. W katalogu ze stylami umieszamy plik lessphp.inc.php pobrany ze strony projektu lessphp.
W pliku index.php naszego szablonu dołączamy plik lessphp.inc.php:
require_once('css/lessc.inc.php');
oraz definiujemy następującą funkcję:
function generate_less($file, $template_name = 'beez5'){
try {
lessc::ccompile(JPATH_THEMES.DS.$template_name.DS.'css'.DS.'less'.DS.$file.'.less', JPATH_THEMES.DS.$template_name.DS.'css'.DS.$file.'.css');
echo '<link rel="stylesheet" type="text/css" href="templates/'.$template_name.'/css/'.$file.'.css" />';
} catch (exception $e) {
exit('LESS ERROR:'.$e->getMessage()."\nFILE:".$file.'.less');
}
}
Oczywiście musimy pamiętać też o zapewnieniu stosownych uprawnień do zapisu w katalogu css/ i zmienieniu w parametrach funkcji nazwy szablonu na nazwę naszego szablonu.
Dzięki temu możemy odwoływać się do plików CSS poprzez zapis:
<?php generate_less('template'); ?>
Powyższy zapis wygeneruje z pliku css/less/template.less plik css/template.css i umieści odnośnik do niego w miejscu wywołania.
Jedną z bolączek LESS jest dosyć małe wsparcie dla składni w edytorach. Osobiście korzystam z edytora Coda i tego rozwiązania.
LESS.js ma jeszcze tą wadę, że wszystkie generowane przez niego style są osadzane bezpośrednio w kodzie strony - stąd jeżeli mamy w plikach *.less odnośniki do grafik tła to musimy je definiować względem głównego dokumentu strony a nie położenia pliku *.less (oczywiście w wypadku naszych plików *.less odniesienia do plików tła tworzymy tak jakby się znajdowały one w katalogu css/ a nie css/less/).
09
marca
2010
Dzisiaj szybkie skryptowe rozwiązanie dość często spotykanego problemu zmiany tła w zależności od podstrony, który powinien w jakimś stopniu zniknąć w Joomla! 1.6, gdzie będzie istniała możliwość zmiany ustawień szablonu dla konkretnych podstron (obecnie trzeba tworzyć kopie danego szablonu i przypisywać go do konkretnych podstron).
Do osiągnięcia pożądanych rezultatów musimy zrobić dwie rzeczy: stworzyć w katalogu images/ naszego szablonu katalog backgrounds/ wypełniony grafikami tła, których chcemy użyć oraz dodać poniższy skrypt w sekcji head naszego szablonu (najlepiej na samym jej końcu):
<?php
// tablica powiązań Itemid <-> grafika tła
$bg_images = array(
"53" => "1.jpg",
"54" => "2.jpg",
"default" => "3.jpg" // grafika domyślna
);
$itemID_value = JRequest::getCmd('Itemid');
$bg_image = (isset($bg_images[$itemID_value])) ? $bg_images[$itemID_value] : $bg_images["default"];
$url =& JURI::getInstance();
?>
<style type="text/css">
body{
background:#fff url('<?php echo $url->root(); ?>templates/<?php echo $this->template; ?>/images/backgrounds/<?php echo $bg_image; ?>') center 0!important;
}
</style>
Powyższy skrypt dysponuje tablicą powiązań $bg_images, która definiuje powiązania pomiędzy wartościami zmiennej Itemid z adresu i obrazkiem tła przypisanym do danej wartości Itemid. Skrypt wczytuje wartość Itemid z adresu i na tej podstawie określa czy do danej wartości został przypisany jakiś szczególny typ tła, w przeciwnym wypadku zostanie zastosowana grafika domyślna.
Za ustawienie tła odpowiada osadzony styl CSS, w którym można oczywiście pozmieniać parametry pozycjonowania tła, koloru tła i jego powielania ;)
Oczywiście nic nie stoi na przeszkodzie by określać także inne parametry tła w ten sposób, a nawet dodawać całe style CSS
04
marca
2010
Tworząc szablon dla Joomla! możemy zdefiniować nie tylko wygląd strony i jej podstron, ale także wygląd standardowych komunikatów o błędach czy informacji o pracach konserwacyjnych witryny. W razie potrzeby możemy też zdefiniować kilka własnych szablonów spełniających określone warunki - np. potrzebne do wymiany danych z użyciem AJAX-a. A wszystko to dzięki jednej zmiennej znajdującej się w adresie - tmpl.
Z reguły szablony posiadają w głównym katalogu jedynie plik index.php, czasem plik component.php - są one wykorzystywane do generowania treści strony w zależności od wartości zmiennej tmpl w adresie (domyślna jej wartość to index). W pliku component.php definiujemy wygląd strony zawierającej wyłącznie aktualny komponent. Jeżeli przyjrzymy się zawartości katalogu templates/system/ to zauważymy, że istnieją jeszcze dwa pliki tego typu: error.php oraz offline.php. Pierwszy z nich odpowiada za komunikaty o błędach wyświetlane np. w wypadku wpisania nieistniejącego adresu, a drugi odpowiada za wygląd strony informującej o pracach konserwacyjnych. Oba pliki także możemy nadpisać w katalogu głównym naszego szablonu i w ten sposób uzyskać stylowanie spójne z wyglądem naszego projektu.
Tak naprawdę największe możliwości daje nam możliwość stworzenia własnych szablonów tego typu. Jeżeli ktoś się zastanawiał jak zaimplementować skrypty korzystające z AJAX-a w Joomla! to odpowiedzią jest: odpowiedni komponent + odpowiedni szablon.
Komponent w tym wypadku wygeneruje nam odpowiednie dane (załóżmy, że będą one w formacie XML), a szablon wygeneruje nam zawartość komponentu bez całej zbędnej otoczki jaką stanowi w tym wypadku np. nagłówek dokumentu.
Wystarczy stworzyć w głównym katalogu naszego szablonu plik ajax.php o następującej zawartości:
<?php
$document =& JFactory::getDocument();
$document->setMimeEncoding('application/xml');
defined( '_JEXEC' ) or die( 'Restricted access' );
?>
<jdoc:include type="component" />
Pierwsze dwie linijki powodują zmianę wyjściowego typu MIME dokumentu (jeżeli chcemy otrzymywać dane w formacie JSON to wystarczy zmienić atrybut metody setMimeEncoding), kolejna linijka uniemożliwia zdalne wywoływanie naszego szablonu, a treść naszego szablonu stanowi zawartość komponentu zależna od parametrów zawartych w adresie strony.
Od teraz każde wywołanie strony gdzie w adresie znajdzie się zmienna tmpl o wartości ajax spowoduje wykorzystanie naszego nowego szablonu. Przykładowo adres:
index.php?option=com_ajax&tmpl=ajax
Spowoduje wygenerowanie danych udostępnianych na stronie komponentu com_ajax z użyciem szablonu ajax.php.
Usuwając zmienną tmpl z adresu wyświetlimy zawartość komponentu w tradycyjny sposób.
W ten sposób możemy łatwo tworzyć szablony odgórnie określające format wyjścia danych z komponentu. Można też teoretycznie korzystać ze zmiennej format w adresie, ale wymaga ona zdefiniowania w komponencie odpowiednich widoków odpowiadających danemu formatowi wyjścia, a dzięki prezentowanemu sposobowi robimy wszystko tylko raz zamiast robić to dla każdego komponentu oddzielnie.
Przy okazji warto też wspomnieć, że dla danego szablonu można dosyć w łatwy sposób zmieniać formaty wyjścia - np. w wypadku szablonu ajax.php pożądanymi formatami byłyby JSON i XML - nie ma sensu tworzyć dwóch oddzielnych szablonów - wystarczy zdefiniować dodatkową zmienną np. output i w zależności od jej wartości generować odpowiedni typ MIME dla dokumentu.
Na koniec przykładowy kod takiego szablonu z użyciem klasy JRequest:
<?php
$format = JRequest::getCmd('output') == 'json' ? 'application/json' : 'application/xml';
$document =& JFactory::getDocument();
$document->setMimeEncoding($format);
defined( '_JEXEC' ) or die( 'Restricted access' );
?>
<jdoc:include type="component" />
Oczywiście jak widać w ramach lenistwa - gdy podamy jakąkolwiek wartość zmiennej output (lub jej nie podamy) inną niż json wtedy otrzymamy dane w formacie XML.
Na koniec dodam jeszcze, że warto rozważyć stosowanie wspomnianych szablonów np. do tworzenia mobilnych wersji szablonów czy różnych odmian szablonu odgórnie pozbawionych pewnych pozycji modułów.
25
lutego
2010
Joomla! 1.5 oraz większość jej rozszerzeń w skryptach JavaScript korzysta z MooTools 1.11, które jak już kiedyś wspominałem ma czasem problem z obsługą zdarzenia DomReady w przeglądarkach IE.
Jeżeli nie chcemy oglądać błędów postaci:
Wiadomość: HTML Parsing Error:
Unable to modify the parent container element before the
child element is closed (KB927917)
Wiersz: 0
Znak: 0
Kod: 0
To proponuję dodać poniższy fragment kodu na końcu pliku mootools.js z katalogu media:
Element.Events.domready = {
add: function(fn){
if (window.loaded){
fn.call(this);
return;
}
var domReady = function(){
if (window.loaded) return;
window.loaded = true;
window.timer = $clear(window.timer);
this.fireEvent('domready');
}.bind(this);
if (document.readyState && window.webkit){
window.timer = function(){
if (['loaded','complete'].contains(document.readyState)) domReady();
}.periodical(50);
} else {
window.addListener("load", domReady);
document.addListener("DOMContentLoaded", domReady);
}
}
};
Zamiast szukać wszystkich skryptów z linijką:
window.addEvent("domready", function(){
I zamieniać jej na:
window.addEvent("load", function(){
To rozwiązanie ma ten plus, że w normalnych przeglądarkach (innych niż IE) zdarzenie domready będzie cały czas działało jako domready, a tylko w IE zostanie od razu zamienione na zdarzenie load.
23
lutego
2010
Dziś krótki wpis z dosyć istotną wskazówką związaną ze stylowaniem rozszerzeń dla Joomla!. Otóż Joomla! oferuje nam dostęp do sekcji head dokumentu, dzięki czemu z poziomu modułu/komponentu możemy w łatwy sposób dodać skrypt lub styl CSS. I niektórzy developerzy z tej możliwości chętnie korzystają żeby np. uniknąć osadzania elementów link wewnątrz sekcji body witryny (co zresztą powoduje błędy walidacji). Sam dostęp i operacje na sekcji head szablonu dla Joomla! opiszę w jednym z najbliższych wpisów, gdyż jest to dość ważny i szeroki temat, a póki co mały trick, który może być przydatny gdy tworzymy np. szablon w wersji dla urządzeń mobilnych.
Gdy tworzymy jakiś szablon okrojony z większości gadżetów - taki jak na przykład layout dla iPhone, chcemy mieć pewność, że załadujemy tylko te style CSS, których potrzebujemy (można by tu jeszcze uwzględnić kwestie oszczędności transferu). Jak wspominałem niektóre rozszerzenia np. K2 dodają style bezpośrednio do sekcji head - jeżeli nie chcemy tworzyć ręcznie znaczników typu title, meta i po prostu bardzo potrzebujemy w naszym szablonie zapisu:
<jdoc:include type="head" />
a dodatkowo chcemy mieć pewność, że żaden zewnętrzny komponent nie będzie ładował w naszym szablonie swoich styli CSS, to musimy się ich pozbyć. Jak to zrobić ?
Rozwiązaniem jest poniższy kod, który najlepiej umieścić gdzieś pod koniec kodu naszego szablonu:
<?php
$document =& JFactory::getDocument();
$headData = $document->getHeadData();
$headData["styleSheets"] = array();
$document->setHeadData($headData);
?>
Oczywiście jeżeli mamy zainstalowane na serwerze PHP5 to możemy pozbyć się operatora =& z pierwszej linijki.
Prezentowany skrypt wczytuje do zmiennej zawartość sekcji head naszego szablonu, czyści tablicę styli CSS, a nastepnie zapisuje sekcję head w nowej wersji. Dzięki temu mamy pewność, że użytkownik wchodząc na podstronę z komponentem nie zobaczy stylowania charakterystycznego dla danego komponentu, co w niektórych wypadkach bez usunięcia styli wyglądałoby dość tragicznie na telefonach.
I jeszcze mała uwaga na koniec - w powyższym kodzie sekcję head rozumiemy jako pewną strukturę przechowującą informacje o różnych znacznikach umieszczanych potem na stronie poprzez zapis:
<jdoc:include type="head" />
Owa struktura nie jest równoznaczna całej zawartości naszej sekcji head, gdyż poza tym zapisem możemy sami ręcznie dodać własne style CSS lub skrypty, które w tej strukturze nie będą widoczne.