O sucesso de um software depende muito do quão podemos modificá-lo para atender nossas necessidades particulares. Do ponto de vista de desenvolvimento, eu sempre olho para um framework através da sua estrutura de API e hooks. As classes do moodle, na sua versão atual, 3.x, me lembra muito o Drupal 5.x ou 6.x e portanto não segue muito a estrutura de frameworks modernos como symfony, laravel ou o próprio Drupal 9.x. De qualquer modo, segue-se uma série de anotações referente ao desenvolvimento de plugins para o moodle.
Exemplo: Plugin de Administração
Estrutura mínima de um plugin
Tipos de plugins: lib/components.json
frankenstyle: nome do tipo _ nome do plugin
Verificação de styles: https://moodle.org/plugins/local_codechecker https://moodle.org/plugins/local_moodlecheck
Tipo de arquivos php no plugin:
request handlers: acessados pelo browser: devem ter require(DIR. ‘/../../config.php’);
Libraries: não acessíveis pelo browser: devem iniciar assim defined(‘MOODLE_INTERNAL’)
die(); - garabte que esse qrauivo será chamado por outro e não via request
podemos colocar bibliotecas em na pasta classes: assim não precisamos usar require_once() para chama-lás em outros arquivos \mod_forum\some_class is stored in file mod/forum/classes/some_class.php nas classes NÂO precisa ter MOODLE_INTERNAL!
Dependências mínimas para instalação moodle em debian 10:
Baixando o moodle com composer:
Instalação rápida:
O que eu ativo no config.php:
Subindo server local:
O moodle trabalha com tipos de plugins. Cada tipo de plugin deve ser colocado no diretório correspondente. Existe um tipo genérico chamado local onde criarei meu primeiro plugin. Chamo de genérico, pois quero fazer uma mudança que não está relacionada a estrutura de um curso, mas sim relacionada a parte administrativa da instância. Nosso plugin interceptará a renderização de strings na camada de template deixando tudo em maiúscula, o chamaremos de tudoupper. Crie o diretório do plugin:
Importante: todos arquivos do plugin devem conter: defined('MOODLE_INTERNAL') || die();.
Os arquivos mínimos para o moodle reconhecer nosso plugin são:
O outro arquivo obrigatório é o do idioma, no qual devemos ao menos especificar o pluginname. Neste momento não vou me preocupar com o idioma, então escreverei em português mesmo estando na pasta en. No mundo real, você criaria local/tudoupper/lang/pt_br/local_tudoupper.php e local/tudoupper/lang/en/local_tudoupper.php e colocaria as strings correspondentes de cada língua.
Neste momento, ao acessar o moodle como site administrator o sistema reconhecerá e habilitará nosso plugin.
String API
Grande parte das classes que no geral vamos querer alterar em um plugin do tipo local estão em lib/classes. Queremos interceptar a classe que renderiza string para o template, assim vamos na busca de uma interface que trare de string:
Identificamos a interface ./lib/classes/string_manager.php que é implementada pela classe ./lib/classes/string_manager_standard.php. Há um método chamado get_string com a descrição: Get String returns a requested string.
No nosso plugin criaremos um diretórios chamado classes:
Em tudoupper_string_manager.php vamos extender core_string_manager_standard e sobrescrever o método get_string() copiando sua assinatura assim como definida na interface:
Conforme a documentação informamos ao moodle no config.php para usar nossa classe ao invés da core_string_manager_standard:
No version.php podemos subir a versão do nosso plugin:
Composer
Posso estar enganado, mas não encontrei até o momento uma maneira de definir globalmente em um projeto moodle que usarei composer e que portanto as dependências dos meus plugins devem ser baixadas. Não é a melhor prática, mas vamos inicializar nosso plugin como um projeto composer distribuindo o diretório vendor junto se necessário. Vou instalar uma biblioteca chamada jawira/case-converter:
Agora vamos modificar tudoupper_string_manager para usar essa biblioteca:
Api de configuração
A página contém bastante informações sobre a API de configuração.
Vamos criar uma nova entrada em lang/en/local_tudoupper.php:
Adicionemos um novo arquivo chamado settings.php no nosso plugin tendo uma condição com $hassiteconfig que restringe esse acesso apenas para administradores da plataforma. Manipularemos um objetos do tipo admin_settingpage que cuidará da camada de formulário e persistência no banco de dados das configurações do plugin. Depois adicionamos esse objeto na variável global $ADMIN que se encarregará de disponibilizar as opções do nosso plugin na área de configurações da plataforma.
Suba a versão em version.php e agora em Site Administration -> Plugins -> Local Plugins temos uma entrada para configuração do nosso plugin, ainda sem campo algum.
Vamos adicionar os seguintes campos, em parentese estão as classes moodle da api de formulário que fornece o markup necessário para cada tipo:
checkbox: ativar ou desativa o recurso desse plugin (admin_setting_configcheckbox)
select: para usar tudo em uppercase ou camelCase (admin_setting_configselect)
input text: prefixo (admin_setting_configtext)
input text: suffixo (admin_setting_configtext)
Começamos complementando nossas strings em lang/en/local_tudoupper.php:
Inicialmente vamos adicionar somente o campo $enabled:
Antes de adicionarmos os demais campos, vamos ler essa opção na nossa classe tudoupper_string_manager e habilitar ou não o recurso:
Agora pela interface de configuração podemos desativar ou ativar esse recurso.
Adicionemos os demais campos:
Por fim modificaremos a classe tudoupper_string_manager para usar esses novos campos: