Desenvolvimento Plugins WordPress – Como utilizar autoloading?

Quando estamos a desenvolver plugins para WordPress uma das questões prementes é como gerir a inclusão de classes para poderem ser instanciadas. Apesar do autoloading poder ser a melhor solução, existem menos valias a serem consideradas, como as versões PHP que o WordPress suporta, e a versão do PHP que passou a suportar os namespaces. De qualquer das formas, explico neste artigo como utilizar o autoloading com PSR-4.

O que é o autoloading?

Trata-se de um mecanismo que automaticamente carrega classes que ainda não foram instanciadas, incluindo os ficheiros que as contêm.

Assim não precisamos de andar preocupados em fazer require das classes que precisamos, uma a uma, um trabalho entediante, manual, e que poderá ser falível.

Basta ver um boilerplate plugin muito utilizado do github, para perceber a ideia.

require_once plugin_dir_path( dirname( __FILE__ ) ) . 'includes/class-plugin-name-loader.php';
require_once plugin_dir_path( dirname( __FILE__ ) ) . 'includes/class-plugin-name-i18n.php';
require_once plugin_dir_path( dirname( __FILE__ ) ) . 'admin/class-plugin-name-admin.php';

Mas para termos um autoloader temos também de definir um standard para a nomeação de ficheiros, algo que vamos ver mais à frente com o PSR-4.

Menos-valias do autoloading

A questão prende-se com a compatibilidade. Apesar do mecanismo spl_autoload_register estar disponível no PHP a partir da versão 5.1.2, os namespaces não.

Os namespaces surgiram apenas na versão 5.3 do PHP, e o WordPress continua a suportar a versão 5.2 do PHP. Por isso, se quisermos optar por autoloading, o nosso plugin poderá não poder ser utilizado por muitos dos utilizadores que usam o WordPress.

Claro que é tudo uma questão de escolhas, já que alguns plugins bastante utilizados, como o do Twitter, já não suportam PHP inferior a 5.4.

Mas, podemos ter também autoloading sem namespaces. Por exemplo, este autoloader definiu uma regra para os nomes de classes, à moda do WordPress.

Assim, se instanciarmos uma classe de nome ‘Main’ o autoloader carrega um ficheiro em /class-main.php.

Implementar um autoloader

Existem varias possibilidades, mas caso definirmos que a versão mínima que o PHP deverá ter para que o nosso plugin funcione seja 5.4, então uma das boas opções é utilizar os exemplos oficiais do PSR-4.

Se não quisermos fazer essa restrição, o autoloader do Rarst acima referido é uma boa opção.

Mas o que é afinal o PSR-4?

O PSR-4 é um standard definido pelo PHP Framework Interop Group, um grupo de pessoas da comunidade PHP, que conta com representantes das maiores frameworks e gestores de conteúdos do mundo PHP. Infelizmente o WordPress não é uma delas.

Eles definem standards para as praticas mais comuns no desenvolvimento para PHP, e entre eles, constam dois standards para autoloaders: PSR-0 e mais recentemente, o PSR-4.

São standards muito semelhantes, mas têm duas grandes diferenças. Primeiro, o PSR-4 requer namespaces, e segundo, o directório de base para um projecto, seguindo o PSR-4, não precisa de ser o namespace de base.

Por closure ou classe

Num plugin para WordPress que desenvolvi recentemente, optei pela versão closure. Bastou ter um ficheiro com o autoload, que tive de incluir manualmente no principal ficheiro do plugin.

No entanto se utilizarmos a versão “classe” teremos a vantagem de poder registar diversos namespaces.

Isso poderá ser vantajoso, caso queiramos ter um namespace para o código, e outro para os testes.

O que costumam utilizar?

Se já desenvolveram plugins para WordPress, como costumam resolver este problema? Optam por autoloading, ou incluem os ficheiros que precisam manualmente? Se sim, porque é que ainda não usam autoloading? Haverão muitas instalações WordPress com PHP abaixo de 5.4 que justique um desenvolvimento mais dificil?

Categoria:Truques e Dicas

Etiquetas:

Deixar uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

Artigo por: Luís Nóbrega

Fundador do PowerUser, programador PHP de profissão e dono orgulhoso de um Android. Gosta especialmente de programar para WordPress e Symfony, mas para outras frameworks também.