From tecmint.com/
J4 - Porque o Joomla! deve limpar a sua estrutura de ficheiros
Hugo Azevedo 69

J4 - Porque o Joomla! deve limpar a sua estrutura de ficheiros

Nota: Este documento faz parte duma série de documentos que constituem um ensaio sobre o que o Joomla! é, e poderá ser no futuro. Estes documentos não representam o estado actual de desenvolvimento do Joomla!, nem são apenas "despejos de memória". Eles listam um conjunto de ideias estruturadas sobre o que o Joomla! poderá ser, e apresentam algumas soluções para lá chegar. O seu maior propósito é gerar discussão na comunidade do Joomla!.

Este é o segundo documento da série. I primeiro documento explicou (na minha opinião), porque o Joomla! deveria ser separado em duas partes distintas, a Framework e a Plataforma. Este documento irá continuar a discussão anterior, e propor uma estrutura de ficheiros que suporte essa ideia.

A primeira coisa que queria conseguir, após instalação do Joomla!, era a separação entre a área do "administrator" e o front-end. Temos de admitir que, um site Joomla!, é na realidade duas aplicações separadas partilhando os mesmos recursos. Front-office e Back-office. Quando analisei o código do Joomla! pela primeira vez, encontrei o ficheiro defines.php na pasta include, que parecia à primeira vista deixar-me configurar a estrutura de ficheiros do Joomla!, e customizar as localizações dos directórios. Óptimo! Eu estava convencido. Não precisaria de procurar mais nada.

Embora o Joomla!, à primeira vista, nos deixa com a impressão de que poderíamos alterar a sua estrutura de ficheiros, a verdade é que, se alterarmos essas mesma localizações, o sistema quebra. Isto não acontece por nenhuma incapacidade técnica da pilha tecnológica usada (LAMP). Isto acontece porque a maioria dos ficheiros são referenciados por localizações "rígidas" (hard-coded).

A razão principal que eu queria dissociar o Back-office, era segmentar o tráfego do site usando o Awstats (logs do Apache). O log de tráfego do Back-office é o mesmo log de tráfego do Front-office. Não há nenhum cenário que me lembre, onde eu queira ter apenas um log para o tráfego de ambas as aplicações.

Existe uma outra boa razão para esta dissociação, que é a ofuscação da localização pública do Back-office. Mas quando tentei configurar isto, o Back-office partiu todo. Algumas extensões não funcionavam convenientemente, e outras deixaram de funcionar completamente. Na minha opinião, isto é um grande problema, e procurando um pouco na Internet, pareceu-me claro que eu não seria o único.

Estrutura complexa e redundante

Outra coisa de que me apercebi, é a complexidade e redundância da estrutura de directórios do Joomla!.

As extensões estão espalhadas por todo o lado. Funcionalidade do Joomla! propriamente dito está também espalhada por todo o lado. Temos duas directorias na raiz, onde podemos colocar dependências (media e images)... Algumas pessoas usam mesmo o ficheiro script.php apenas para copiar dependências do directório media (onde os ficheiros são instalados), para o directório images. Qual será o propósito, pergunto eu! São todas dependências. Porque não usar só um directório, e criar um sub-directório gallery para uso do Media Manager?

Não é muito fácil assumir seja o que for da estrutura de ficheiros do Joomla!, apenas olhando para ela. É também difícil perceber inicialmente, que directórios proteger contra escrita no servidor, na eventualidade dum update do Joomla!.

Uniformidade vs Continuidade

Parece que existe sempre uma grande preocupação na comunidade de desenvolvimento do Joomla!, em facultar compatibilidade com versões (major) anteriores. Para o Joomla!4, e de acordo com o Joomla! PLT, esta compatibilidade com versões anteriores irá partir, de forma a evoluir o produto, e eu, pessoalmente concordo com isto.

Re-escrever completamente o núcleo do Joomla! não implica necessariamente uma alteração completa do US/UI. Os utilizadores finais podem nem sequer notar, porque os utilizadores interagem com o Template, e manipulam o conteúdo através das extensões instaladas. O código do núcleo, "apenas" faz a ligação entre tudo.

Pessoal, penso que se houvesse uma ruptura completa entre o Joomla!3 e o Joomla!4, seria aconselhável uma revisão completa do código interno/núcleo. Isto poderá não ser mau. Implicaria um novo começo.

Migração vs Melhoramento vs Actualização vs Portação (Migration vs Upgrading vs Updating vs Porting)

Parece haver um equívoco institucionalizado acerca destes termos na comunidade do Joomla!, que poderá levar em erro quer os utilizadores quer os programadores do mesmo.

Em desenvolvimento de software, existe uma convenção (a mais popular) em relação às versões de produtos, em que o número da versão é separada até 4 sub-grupos, separados por uma notação de pontos. Chama-se a isto, versão semântica. Este número de versão é composta pelos números Principal.Secundária.Revisão.Compilação (os nomes usados são traduções literais do inglês Major.Minor.Resivion.Build). Um exemplo dum número de versão é v1.2.34.56789.

Duma forma geral, um Melhoramento (Upgrade) acontece quando a versão principal do produto (major) é incrementada, que geralmente significa uma alteração no paradigma/filosofia, e geralmente implica uma rescrita/reestruturação da aplicação. Isto geralmente implica também, uma quebra de compatibilidade com versões anteriores.

Um incremento nos restantes números da versão (Secundária, Revisão e/ou Compilação), são apenas Actualizações (updates), e que não deverão quebrar a compatibilidade. Incrementar o número de versão Secundário (Minor), implica que foi adicionada/removida uma ou mais funcionalidades. Incrementar o número de Revisão (Revision/Patch), implica que o produto sobre melhoramentos ao nível de desempenho e/ou segurança, sem adicionar ou perder funcionalidade. O último número da versão, a Compilação (Build), é um número incremental que identifica quantas vezes o produto foi compilado (não é o caso do Joomla!).

Outro problema com os termos usados pela comunidade, é a diferença entre Migração e Portação. Geralmente, e duma forma muito simplista, código de software (tecnologia) é Portado, e os dados são Migrados. Se estivermos a mudar de CMS, então teremos de migrar os nossos dados entre plataformas/ambientes. Se estivermos a planear re-escrever o Joomla! noutra tecnologia (ex:. Java.NET), então estaremos a Portar o código.

Agora que desabafei isto, podemos então falar em Melhorar (upgrade) o Joomla! da versão 3 para a versão 4. Em vez de termos o Joomla! a mudar da versão 3 para a versão 4 apenas por questões de marketing, deveríamos estar a mudar a versão porque o produto assim necessita. E se o Joomla! vai quebrar a compatibilidade com versões anteriores, porque não tirar partido disso, e tentar limpar a sua estrutura de ficheiros, para uma estrutura mais permanente?

Solução proposta

Penso que a estrutura de ficheiros poderá ser melhorada, tornando-a simplificada e contextualizada. Um Melhoramento (upgrade) é o pretexto certo para o fazer. Não poderá ser feito numa Actualização (update).

Na minha opinião, e numa instalação minimalista, a estrutura de directorias do Front-end, apenas deverá ser composta por 4 ficheiros e uma pasta.

O Administrator (Back-office) ficaria com a mesma aparência. Poderia até ter a sua própria pasta media dedicada. O Media Manager procuraria ficheiros (na pasta media do Front-office) usando o sistema de ficheiros, e poderia exibir as miniaturas (thumbnails) usando pedidos HTTP.

O ficheiro index.php teria apenas 3 instruções:

<?php
define('_JEXEC', 1);

// Include directory specification file.
include_once 'directories.php';

// Call the Engine's main file, that starts execution.
include_once JPATH_CORE . 'index.php';

O último ficheiro index.php incluído, seria o ponto de entrada para o Motor do Joomla!.

O ficheiro directories.php, teria as variáveis para ttodas as directorias de sistema, quer do Motor, quer da Plataforma (ver posts anteriores), e poderia ser algo do género:

<?php
defined('_JEXEC') or die;

// Defines Web Application ID (if used).
define('JPATH_SITE', 'WebSiteID');// site or admin, in the CMSs case.

// Defines all path variables.
define('JPATH_ROOT', __DIR__);
define('JPATH_BASE', '/path/to/public_html/');
define('JPATH_CORE', '/path/to/core/');

define('JPATH_ENGINE', JPATH_CORE . 'bin');
define('JPATH_LIBS', JPATH_CORE . 'lib');
define('JPATH_APPS', JPATH_CORE . 'usr');
define('JPATH_AUTOLOADER', JPATH_CORE . 'opt/autoloader');

define('JPATH_MEDIA', JPATH_BASE . 'media/');
define('JPATH_THEMES', JPATH_APPS . 'templates/');

define('JPATH_CACHE', JPATH_CORE . 'var/cache/');
define('JPATH_TMP', JPATH_CORE . 'var/tmp/');
define('JPATH_LOG', JPATH_CORE . 'var/log/');

define('JPATH_...', '...'); // Other needed values.

O ficheiro index.php e o ficheiro directories.php permaneceriam imutáveis entre versões, mesmo que o Joomla! fosse actualizado. Isto quer dizer que poderiam estar protegidos contra escrita no sistema de ficheiros.

A pasta media, que iria conter todos os ficheiros de media (imagens e dependências) necessários para as Extensões e Templates do Joomla!. Poderia também conter uma pasta dedicada para cada uma das extensões (possivelmente criada na instalação do mesmo).

.
..
media
media / core
media / com_extension1
media / com_extension1 / js
media / com_extension1 / css
media / com_extension1 / img
media / com_extension1 / etc...
media / com_extension2
media / com_extensionN
...

Estrutura de ficheiros do Motor

Se leu o post anterior, sabe que propus que o Joomla! fosse uma Plataforma em cima de um Motor. Isto quer dizer que, a actual estrutura de ficheiros fosse a estrutura de ficheiros do Motor. A estrutura poderá estar mais organizada, e se a fossemos alterar, uma estrutura mais familiar/popular poderia ser adoptada.

Hoje em dia, mais pessoas estão familiarizadas com o sistema de ficheiros *nix, quer através de um Mac, que seja através duma máquina Linux. Na minha opinião, uma versão mais simplificada desta estrutura poderia também ser acomodada às necessidades do Joomla!. Uma estrutura de ficheiros do Linux poderá ser parecer-se com a seguinte imagem (dependendo da distribuição):

From www.tecmint.com

A maioria das directorias listadas não fazem muito sentido no contexto do Joomla!, mas outras fazem.

O Motor poderia conter as seguintes directorias na sua raiz (que não teria uma localização fixa):

A pasta bin iria conter todos os ficheiros (classes) que seriam automáticamente incluídas no script de execução.

A pasta etc, iria conter ficheiros de configuração, quer do Motor, Plataforma ou qualquer Extensão instalada no sistema (mas apenas para instalações globais).

A pasta lib, iria servir o mesmo propósito das actuais directorias libraries e layouts. Seriam importadas com a ajuda de classes estáticas, como actualmente.

A pasta opt seria usada, por exemplo, para add-ons do Motor (Plataforma ou outro pacote grande de instalação maior). Também seria a pasta onde colocar add-ons/pacotes que fossem incluídos de forma automática.

A pasta usr iria conter o software de utilizador (extensões e templates). Dentro da directoria usr, a mesma estrutura de raiz seria adoptada, mas o seu conteúdo seria apenas para extensões. A directoria usr poderia parecer-se assim:

Cada sub-pasta usr->bin teria o nome da extensão e/ou template, e no caso de extensões, cada pasta de extensão teria as seguintes sub-pastas: controllers, models e views (front-office, back-office, etc...). Mas mais sobre isto no próximo post. usr->etc teria as configurações das extensões (config.xml, access.xml e nome_extensao.xml). usr->lib iria extender a pasta root->lib, e as suas bibliotecas estariam disponíveis ao sistema todo. Penso não ser necessário explicar a estrutura e propósito da directoria usr->var.

E por último, temos a pasta (root) var, que contem diverso conteúdo variável/temporário de sistema, como por exemplo a cache, log (principal), lang (principal), sql (principal) ou a pasta tmp.

Porquê um estrutura de ficheiros assim? Qual é a finalidade?

Bem, pela mesma razão que os sistemas *nix a usam, e precisamente por esses sistemas a usam.

A razão para adoptar esta estrutura de ficheiros, é porque cada directoria num sistema *nix tem a sua própria função, e sendo assim, poderá mesmo ter permissões distintas. No caso do Joomla!, as permissões poderão não se aplicar, mas separar cada funções na sua directoria dedicada pode ser uma mais valia. Por exemplo, o configurador do site, poderá querer separar uma a directoria que contém as extensões, e movê-la para uma localização mais "escondida".

O Motor e/ou Plataforma poderão também (hipoteticamente) ser instalados centralmente num servidor, e cada site teria apenas as suas instalações locais (cada uma usando os seus próprios recursos). Assim, a instalação central do Joomla! seria partilhada por vários sites.

A estrutura de directorias do Joomla! tornar-se-ia mais limpa e de fácil leitura/interpretação. Pastas públicas (site e admin) ficariam então muito mais limpas e organizadas.

Isto poderia também facilitar a dissociação do administrator (Back-office). Pelo que tenho lido online, parece que não sou o único a querer o administrator num sub-domínio do site principal, em vez de o ter numa sub-pasta pré-definida.

Backup mais limpo e pequeno. Não faria muito sentido fazer backup de todos os ficheiros do site, para além das pastas usr, var e media.

Mas a maior razão é, que poderíamos alterar a localização de todos os ficheiros principais, e colocá-los numa directoria não-pública do servidor. Geralmente, todos os ficheiros php do Joomla! começam com a mesma instrução de validação, que previne acesso directo a esses ficheiros, e cada directoria deverá ter um ficheiro index.html, mas ficheiros XML e TXT não têm essa validação, e directorias poderão não conter o ficheiro index.html.

Protecção de acesso a directorias poderá ser conseguida por outros meios, mas isto não é feito dentro do Joomla!. Se tivermos um ou mais sites Joomla!, e estivermos atentos aos logs de acesso, sabemos que o acesso directo a ficheiros é uma realidade.

SmarterQueue - A forma mais inteligente de criar em redes sociais

SmarterQueue - A forma mais inteligente de criar em redes sociais

LRTT - Limited Resource Teacher Training

LRTT - Limited Resource Teacher Training

shareOptic - Solução de monitorização de cyber segurança

shareOptic - Solução de monitorização de cyber segurança

Blockz RAD framework web em Php

Blockz RAD framework web em Php