Alterar identidade de todos os usuários para anônimo no Moodle com script PHP

Você fez uma cópia da base do Moodle  que está na produção e colocou no ambiente de teste. Para evitar possíveis transtornos porque não mudar identidade de todos os usuários? Isso evita possíveis dores de cabeça.

Vamos lá, para mudar identidade para que cada fique com nome anônima como : Usuário 3, Usuário 4 e Usuário   5 etc.  Além de  mudar o nome, mudar também o login e senha para um padrão simples. Exemplo: usuario3  é o login e senha do Usuário 3.  Usuario4  é o login e senha do Usuário 4. 

Para fazer isso, basta executar o seguinte código PHP:

Continue a leitura deste post no fórum da comunidade Badiu:
http://comunidade.badiu.com.br/mod/forum/discuss.php?d=235

Hackear login no Moodle usando API - Logar no Moodle sem login e senha

Nesse post vou compartilhar com vocês como efetuar login automaticamente no Moodle sem passar login e senha usando API do Moodle. Esse procedimento requer acesso ao FTP  / sistema de arquivos  php do Moodle.

O código apresentado a seguir mostra como fazer isso.  Esse procedimento pode ser útil em seguintes situações:

• Perdeu a senha de administrador e precisa logar como admin para providenciar alteração de senha;
• Precisa integrar sistemas para que um usuário entre no Moodle já logado vindo de outros sistema;
• Acessar como um determinado aluno sem alterar/conhecer a senha dele;

Continue a leitura deste post no fórum da comunidade Badiu:
http://comunidade.badiu.com.br/mod/forum/discuss.php?d=227

Duplicar Curso do Moodle com API

Este post apresenta a codificação PHP para duplicar um curso do Moodle usando o  API do próprio framework Moodle.

 A duplicação pelo código possibilita automatizar o processo de backup e restauração. Imagine a situação em que você tem um curso modelo com todo o conteúdo formatado e pronto para ofertar.  Para cada turma no sistema acadêmico é criado uma instancia diferente do curso no Moodle com o mesmo conteúdo.  Neste caso, ninguém merece o processo repetitivo de restaurar manualmente o backup para cada instancia do curso. Se isso for a sua situação, relaxe. Tome uma cerva gelada para se animar com as sopas de letrinhas reaproveitando o API do Moodle. 



Continue a leitura deste post no fórum da comunidade Badiu: http://comunidade.badiu.com.br/mod/forum/discuss.php?d=178

Tipos de plugin do Moodle

A tabela abaixo lista os vários tipos de plugin que existem no Moodle.
A coluna local de instalação se refere a pasta do Moodle onde o plugin deve ficar instalado.

Tipo de Plugin	Local de Instalação
Matrícula	moodle/enrol
Autenticação	moodle/auth
Relatório do curso	moodle/course/reporter
Relatório de nota	moodle/grade/reporter
Relatório no contexto do sistema	moodle/admin/report (até versão 2.1) moodle/report (a partir da verão 2.2)
Exportação de nota	moodle /grade/export
Tema (interface gráfica)	moodle/theme
Formato de curso	moodle/course/format
Tipo de questão	moodle/question/type
Atividade	moodle/mod
Campos para base de dados	moodle/mod/data/field
Tipo de Atividade tarefa	moodle/mod/assignment/type
Relatório de questionário	moodle/mod/quiz/report
Blocos	moodle/blocks
Campo de perfil de usuário	moodle/user/profile/field
Plugin deversos	moodle/local

Diretrizes gerais de desenvolvimento para Mooodle

    Assim como qualquer framework, o Moodle oferece um ambiente de desenvolvimento em que o programador deve seguir um  conjunto de regras para implementar código que seja compatível ou reconhecidos pelo kernel do sistema.  Segue algumas regras básicas. 

1-    Modularização - Para implementar uma nova funcionalidade ou alterar uma já existente sem modificar o código da distribuição padrão do Moodle, crie um novo  módulo ou plugin.

Para cada tipo de funcionalidade há um tipo de plugin do Moodle. Por exemplo, há plugin  para cadastro/autenticação de usuário, matricula no curso, relatório de nota, relatório de curso etc.  A implementação de cata tipo de plugin deve seguir uma regra para se integrar ao sistema do Moodle. A implementação do código fora da estrutura de modularização dificulta ou inviabiliza não só a portabilidade, como também a atualização do Moodle para versão mais recente sem perder o código que implementa as novas funcionalidades. 

2-    Padronização Nomes  – O framework Moodle  faz integração dos plugins através do nome.  O nome da pasta do plugin é a chave de identificação do plugin no framework. Dois plugin do mesmo tipo não podem ter o mesmo nome, ou seja, não podem ficar na mesma pasta. Cada tipo de plugin tem um local específico que deve ser instalado. Por exemplo, os plugins de matrícula ficam na pasta MOODLE_DIR/enrol. Cada subpasta da pasta enrol representa um plugin. Cada tipo de plugin deve ter uma estrutura de arquivos, classes e funções específicas. Por exemplo, o plugin de matrícula da versão 1.9 deve ter um arquivo enrol.php. Nesse arquivo deve existir uma classe enrolment_plugin_NOME_PASTA_PLUGIN. O nome do plugin deve compor o nome da classe para evitar duplicação de nome da classe. Dentro dessa classe deve existir um conjunto de função já definidas. Desse modo, o framework carrega dinamicamente o plugin e a classe.  Da mesma forma, as tabelas do banco de dados do plugin devem ter o  prefixo do nome do plugin. Isso evita duplicação de nome da tabela. Por outro lado, facilita a identificação das tabelas. 

3-    Permissão  - Para gerenciar as permissões de acesso as funcionalidade de um plugin, é necessário que todas as permissões do plugin sejam definidas no arquivo access.php. Na estrutura de arquivo padrão de qualquer plugin, o arquivo access.php deve ficar dentro da pasta bd. Esse arquivo é carregado automaticamente durante a instalação do plugin. O core do sistema lê as permissões definidas nesse arquivo e alimenta a tabela mdl_capabilities e mdl_role_capabilities. 

4-    Banco de dados – Para gerar a tabela do banco de dados automaticamente durante o processo de instalação de um plugin, é necessário definir a estrutura da tabela no arquivo install.xml. Esse arquivo deve ficar na pasta db do plugin. O core do moodle faz leitura desse arquivo durante o processo de instalação e gera  a tabela do banco de dados.  

5-    Internacionalização de idioma – O core do framework Moodle gerencia o pacote de idioma de todos os plugins.  Para isso, é necessário que todas as mensagens  e textos do plugins  sejam definidos no arquivo específico do pacato de idioma. Por padrão em qualquer plugin o pacote de idioma deve ficar na pasta lang.

    Seguir essas regras durante o processo de desenvolvimento para Moodle garante total compatibilidade e portabilidade do código. Por outro lado, a atualização não compromete a customização já feita desde que não haja incompatibilidade do core da versão recente em relação a versão anterior.   Na contramão está o hacker do código que impacta a portabilidade  e a atualização.

Arquitetura do Sistema Moodle

    Moodle é um framework de desenvolvimento PHP. A sua arquitetura de organização e sistematização de dados é centralizada em curso, ou seja, na sala de aula virtual.
    A arquitetura da Plataforma Moodle é complexa. Para explicá-la de uma forma mais simples, vamos explorar a relação entre três elementos:

•    Material didático;
•    Curso;
•    Matrícula.

Material didático
    Material didático é o conteúdo do curso. São textos, arquivos, imagens, vídeos, recursos de comunicação síncrona / assíncrona, questionários etc. No ambiente do curso do Moodle, há um sistema de editoração de conteúdo sistematizado em recursos e atividades. Cada recurso e atividade é gerenciado por um módulo específico. Por exemplo, para criar um questionário, será usado o módulo quiz. Para criar um texto, será usado o módulo page. O material didático é um item dependente do curso. Este só pode existir se estiver vinculado a um curso. Isso significa que os módulos de recursos e atividades do Moodle só podem ser instanciados dentro do ambiente do curso.

Curso
    O curso é a sala de aula virtual. É um espaço de publicação do material didático. O curso é organizado em categorias. Uma categoria pode ter vários níveis de subcategoria. Um curso deve ser vinculado a uma determinada categoria. Da mesma forma, uma atividade deve ser vinculada a um curso. Nessa estrutura de organização, há três níveis:

 1.  Categoria de curso

     1.1 Curso

        1.1.1 Atividades (material didático)

    A categoria ocupa o nível mais alto na hierarquia e a atividade o nível mais baixo. A categoria serve para sistematizar a oferta de curso. Em cada curso, há um conjunto de recursos e atividades que compõe o material didático.

Matrícula
    Matrícula é o vínculo de um usuário cadastrado na base do Moodle a um determinado curso. Um usuário pode ser vinculado a mais de um curso. Para efetuar a matrícula, é necessário definir o perfil. Pode ser aluno, tutor, professor etc. O perfil define a permissão do usuário no ambiente do curso. A matrícula pode ser efetuada em nível do curso, categoria de curso ou do sistema. A matrícula no contexto do sistema possibilita acesso a todos os cursos cadastrados do Moodle. Já no contexto da categoria de curso, dá acesso apenas aos cursos daquela categoria.
    O usuário matriculado no curso terá acesso a todas as atividades criadas dentro do curso. Quando o usuário realiza uma atividade, como postar uma mensagem no fórum, a postagem é vinculada à instância do usuário e não à da matrícula. Isso significa que os módulos de atividades são vinculados ao usuário e não à matrícula. O usuário só poderá ser instanciado na atividade se estiver matriculado no ambiente do curso ao qual a atividade está vinculada.
    Tendo em conta que o usuário é instanciado no módulo de atividade e não no de matrícula, em caso da exclusão  da matrícula, o histórico de participação do usuário nas atividades do curso não será excluído em efeito cascata. O histórico permanecerá inalterado. Se a matrícula for reativada, o aluno continuará no curso do ponto onde havia parado.
    A matrícula no curso ainda pode ser estruturada em grupo e agrupamento. Após cadastrar um aluno no curso, este pode ser vinculado a um ou mais grupos. Grupos servem para efetuar divisão de turmas dentro do ambiente de um curso. Ainda há possibilidade de criar agrupamentos, grupos de grupos. Um agrupamento pode ter um ou mais grupos de usuários. Serve para isolar uma atividade apenas a determinado grupo de usuários. Geralmente é usado para atividade recuperação que só determinados alunos devem fazer.

    Em suma, a arquitetura do Moodle é focada no ambiente do curso. O material didático é instanciado no curso. A matrícula é instância do usuário no ambiente do curso. O aluno acessa o material didático instanciado no curso. Pelo padrão da arquitetura, não há possibilidade de vincular um material didático ou atividade na instância da matrícula. Ou seja, não é possível alocar uma atividade só para um aluno. Isso gera uma grande restrição para projetos pedagógicos que demandam do professor uma atuação personalizada para cada aluno.
     Essa restrição fica muito evidente quando um aluno reprova em um curso e precisa refazê-lo novamente. Como não é possível rematricular na mesma sala de aula, será necessário replicar o curso numa nova sala de aula e inscrever o aluno.  É comum fazer backup de um curso inteiro e restaurar numa nova instância do curso apenas para um aluno que ficou em recuperação.
    Embora o Moodle seja um framework modularizado, toda sua estrutura seguem as regras da arquitetura.  É possível fazer um módulo que solucione essa restrição. No entanto, isso implica reescrever alguns APIs para atender ao desvio do padrão do framework.

Tornar o Campo Descrição Obrigatório ao Editar Perfil do Usuário pelo Código PHP

O campo descrição é opcional no formulário de cadastro e edição do perfil do usuário. Caso queira torná-lo obrigatório apenas ao editar o perfil, será necessário    fazer um hacker no código do core do Moodle. O hacker será desnecessário se houver alguma opção de configuração na interface do Moodle. Pelas pesquisas que fiz, não encontrei essa opção. Então vamos ao hacker. Se você descobrir como fazer essa configuração na interface do Moodle, não esquece de me avisar.
   
    Para obrigar o preenchimento do campo descrição na edição do perifl pelo código PHP, siga os seguintes passos:

1° Passo  - Abrir o arquivo editlib.php
    Abra em um editor de texto o seguinte arquivo:
    $CFG->wwwroot /user/editlib.php
$CFG->wwwroot  se refere ao endereço da pasta em que a aplicação do Moodle está instalada. 

2° Passo  - Localizar o campo descrição do formulário de cadastro/edição
    O código que gera o campo descrição no formulário de cadastro/edição do usuário fica  geralmente na linha  230. Na versão 2.2.2 na linha 260.

Moodle 1.9
Na versão 1.9.x, localize a seguinte linha de código:

$mform->setHelpButton('description', array('text', get_string('helptext')));

Abaixo dessa linha insira o seguinte código:

if(optional_param('id', 0,PARAM_INT)>0) $mform->addRule('description',  get_string('required'), 'required', null, 'client');

Moodle 2
Na versão 2.x , localize a seguinte linha de código:

$mform->addHelpButton('description_editor', 'userdescription');

Abaixo dessa linha insira o seguinte código:

if(optional_param('id', 0,PARAM_INT)>0) $mform->addRule('description_editor',  get_string('required'), 'required', null, 'client');

O código adicionado define a obrigatoriedade do campo descrição apenas se for a edição do  perfil e não o  cadastro de um novo usuário. A diferença do código da versão 1.9.x para 2.x está apenas no nome do campo que mudou de description  para description_editor.

O url de cadastro de usuário e de edição do perfil é  o mesmo . A diferença está no parâmetro id.

Url para cadastro de usuário:
$CFG->wwwroot /user/editadvanced.php?id=-1

Url para edição do perfil do  usuário:
$CFG->wwwroot /user/editadvanced.php?id=5

O parâmetro -1 indica é o processo de cadastro de um novo usuário. Se o parâmetro id for maior que zero, significa que se trata de edição do usuário. Id maior que zero é o id do usuário na base de dados.

O código   if(optional_param('id', 0,PARAM_INT)>0)   verifica se o valor do parâmetro id é maior que zero. Se for, a função addRule aplica a obrigatoriedade no campo descrição. 
 

3° Passo  - Gravar alteração do arquivo editlib.php
    Para que a alteração seja efetivada, grave o arquivo. Feito isso, basta acessar o formulário de edição do perfil  para verificar se o campo descrição ficou obrigatório. 


    Esse procedimento é um hacker do código, ou seja, altera o código padrão do Moodle. Em caso de atualização, esse código será perdido. Para manter, é necessário seguir os mesmos procedimentos após a atualização da versão.