NeoFrag Reborn 1.2.24

O NeoFrag Reborn abre-se no GitHub. O código do CMS (NeoFragReborn/neofrag), os addons à la carte (NeoFragReborn/extensions) e o bot do Discord (NeoFragReborn/bot-discord) são lá publicados com a história das suas versões — desde a 1.0.0 para o CMS e os addons, desde a 0.1.0 para o bot: o código de cada versão, as suas notas, e os pacotes a partir da 1.2.23.

Alterado

• As bases de dados indicadas são as que são testadas: cada versão instala-se e passa todo o seu conjunto de testes, com PHP 8.2 e 8.5, em MySQL 5.7, 8.0 e 8.4 e em MariaDB 10.5, 10.6, 10.11, 11.4 e 11.8 — o guia de instalação cita essas versões, e já não «5.7+» e «10.5+».
• Os guias dizem onde encontrar o projeto: o pacote de instalação e o arquivo do bot na sua página de versões, os addons à la carte e o seu catálogo na de extensions, o código para quem quiser contribuir. Na wiki, as referências a um documento do repositório (implementação, arquitetura, ferramentas) levam a esse documento no GitHub, em vez de manterem só o seu título.

Corrigido

• As definições dos módulos voltam a abrir-se: a janela «Configuração» dos módulos Fórum, Recrutamento, Notícias, Galeria, Eventos, Calendário e Artigos respondia «erro 500» de cada vez que era aberta, em todos os sites, desde a 1.2.0: o campo «número» recusava um inteiro (o seu passo, e o valor lido da base de dados) desde que o código passou à tipagem estrita.
• Equipas: a opção «Mostrar jogos realizados» volta a poder ser desmarcada. Guardar as definições guardava a palavra «Array» em vez de um sim ou de um não, que era sempre lido como «sim».
• As definições de um autenticador nunca configurado (Google, Discord, GitHub) abrem-se sem escrever oito avisos no registo.
• O painel e as estatísticas de um site sem Artigos, Gestor de bugs ou Fórum já não escrevem avisos no registo de cada vez que são abertos: os cartões destes módulos só aparecem se estiverem instalados, e já não é consultada nenhuma tabela ausente.
• O assistente de instalação volta a ler a configuração que acabou de escrever: num alojamento cuja cache do PHP não volta a verificar os ficheiros, uma segunda tentativa do passo «Base de dados» ainda lia o antigo config/db.php.
• Um site implementado a partir do git e instalado pelo assistente web funciona: o assistente não escrevia config/neofrag.php (o pacote tem-no, um clone só tem o seu modelo), e cada página respondia «erro 500» sem uma única linha no registo.
• O exemplo nginx.conf arranca: a regra do TinyMCE, sem aspas, fazia o nginx recusar toda a configuração («missing closing parenthesis»). Os seus redirecionamentos já não têm o parâmetro interno request_url.
• Os ficheiros enviados são servidos com Apache e PHP como módulo: a proteção de upload/ usava uma diretiva proibida num .htaccess, e toda essa pasta — avatares, galeria, mediateca — respondia «erro 500».
• Com o Caddy, os ficheiros enviados que não são imagens (um PDF da mediateca) são servidos: o exemplo só servia imagens.
• /index.php leva à página inicial (redirecionamento permanente) em vez de a uma página não encontrada; e um endereço com uma extensão que nenhuma página serve (/newsletter/.env, que os robôs tentam) responde 404 sem escrever uma anomalia no registo.
• tools/check-all.php com PHP 8.2: cada verificação contava lá como falha, mesmo quando passava — o código de saída era lido uma vez a mais, o que o PHP só permite a partir da 8.3. Para quem contribui com PHP 8.2.

Segurança

• O assistente de instalação já não volta a abrir-se num site instalado cuja base de dados não responde. Se o bloqueio install/db.txt tivesse desaparecido, uma falha temporária da base de dados voltava a abrir o assistente, cujo passo «Base de dados» reescreve config/db.php: um visitante podia então desviar o site para a sua própria base de dados. O site mostra agora «temporariamente indisponível». E o passo «Administrador» recusa criar uma conta assim que o site tem uma.
• O Apache só executa agora o index.php da raiz: a regra de reescrita deixava correr diretamente qualquer ficheiro index.php de uma subpasta (mais de oitenta controladores internos).

Adicionado

• Mais quatro verificações: check-assistant percorre o assistente de instalação do princípio ao fim, como um visitante, para cada perfil (ecrãs, recusas, conta criada, início de sessão com a palavra-passe introduzida, registo silencioso); check-reglages abre o ecrã de definições de cada addon, guarda-o tal como está e volta a abri-lo; check-serveur-web testa o Apache, o nginx e o Caddy, com as configurações incluídas, colocando sondas (pastas e ficheiros proibidos, scripts que não devem correr, reescrita, cabeçalhos de segurança); check-nouveau-venu segue à letra o README e o guia do contribuidor numa máquina limpa. Os fluxos installation.yml e nouveau-venu.yml voltam a corrê-los todas as semanas.
• Os comandos do README funcionam numa máquina nova: o seu bloco «Desenvolver» terminava num conjunto de testes que falhava por falta de uma base de testes; remete agora para o guia do contribuidor, que cria essa base (php tools/prepare-test-db.php).