Como atualizar o OJS com segurança sem perder dados da revista

# Como atualizar o OJS com segurança sem perder dados da revista

Título SEO: Como atualizar o OJS com segurança

Meta description: Veja como planejar uma atualização do OJS com backups completos, homologação, validação de requisitos, plugins, testes e estratégia de rollback.

Slug sugerido: como-atualizar-ojs-com-seguranca

Palavra-chave principal: atualizar OJS

Palavras-chave secundárias: atualização OJS, upgrade OJS, migrar OJS, backup OJS, erro atualização OJS

Atualizar o OJS não deve ser tratado como simplesmente substituir os arquivos da aplicação. Uma instalação em produção reúne banco de dados, arquivos enviados pelos usuários, configurações, código da aplicação, plugins e, em alguns casos, temas ou modificações locais.

Um erro no planejamento pode deixar a revista indisponível ou produzir uma atualização parcialmente concluída.

A forma mais segura de atualizar é tratar o procedimento como uma mudança controlada de infraestrutura: identificar o estado atual, validar o caminho de atualização, criar backups recuperáveis, reproduzir o ambiente em homologação, executar o upgrade, testar e somente depois repetir o procedimento em produção.

Por que manter o OJS atualizado?

Atualizações podem incorporar correções, mudanças de compatibilidade, melhorias no sistema e correções de segurança.

Manter versões antigas indefinidamente também cria um problema operacional: o servidor continua evoluindo. PHP, banco de dados, sistema operacional e bibliotecas mudam, enquanto uma versão antiga do OJS pode depender de componentes que já não são adequados ao ambiente atual.

A atualização deve ser planejada considerando o conjunto inteiro, e não apenas a versão do OJS.

Primeiro: descubra exatamente o que está instalado

Antes de alterar qualquer componente, registre o estado atual.

O inventário deve incluir pelo menos:

versão exata do OJS;
versão do PHP utilizada pela aplicação web;
versão do PHP utilizada em linha de comando, se aplicável;
banco de dados e versão;
servidor web;
plugins instalados;
tema utilizado;
customizações;
tarefas agendadas;
configuração de envio de e-mail;
diretório configurado para arquivos enviados;
integrações externas.

Esse inventário será utilizado para comparar requisitos da versão de destino.

Um detalhe importante: ambientes PHP podem usar configurações diferentes na interface web e no CLI. A própria documentação do repositório oficial alerta que uma verificação executada no terminal pode não representar exatamente a configuração PHP usada pelo servidor web.

Atualização de manutenção e mudança de série não são a mesma coisa

Não presuma que atualizar entre releases da mesma série e migrar entre séries maiores possuem o mesmo risco.

Uma atualização pode envolver alterações de esquema de banco, migrações de dados, novos requisitos de plataforma e mudanças de plugins ou APIs.

Também não se deve assumir que qualquer versão antiga pode saltar diretamente para qualquer versão nova.

O código oficial possui rotinas de upgrade condicionadas às versões de origem e destino. Portanto, o caminho precisa ser validado na documentação e nos arquivos de upgrade da versão que será efetivamente instalada.

\[Link interno sugerido: OJS Gerenciado\]

Verifique os requisitos da versão de destino

Antes do upgrade, consulte a documentação correspondente ao release exato.

No repositório oficial atual do OJS, os requisitos publicados incluem PHP e bancos compatíveis, mas esses requisitos evoluem. Não use números encontrados em um tutorial antigo para planejar uma atualização atual.

Além da versão principal do PHP, verifique extensões e dependências requeridas pela aplicação.

Faça o mesmo para MySQL, MariaDB ou PostgreSQL, conforme o ambiente.

A pergunta correta não é apenas "meu servidor possui PHP?", mas "a versão de destino do OJS e suas dependências são compatíveis com a versão e extensões PHP que realmente executarão a aplicação?".

Verifique plugins antes da atualização

Plugins merecem uma etapa própria.

Liste todos os plugins adicionais e identifique:

quais são essenciais;
quais pertencem à distribuição padrão;
quais foram instalados separadamente;
quais possuem versão compatível com o OJS de destino;
quais não são mais utilizados.

Um plugin incompatível pode causar problemas mesmo quando o núcleo do OJS foi atualizado corretamente.

Não atualize primeiro para depois descobrir se um componente indispensável à operação da revista funciona na nova versão.

Avalie temas e customizações

Temas personalizados podem depender de estruturas que mudaram entre versões.

O risco é ainda maior quando a instalação possui modificações diretamente no código do OJS.

Alterações locais no núcleo dificultam upgrades porque a substituição dos arquivos pode remover essas mudanças, enquanto simplesmente copiar os arquivos antigos sobre a versão nova pode reintroduzir código incompatível.

Antes da atualização:

identifique todas as modificações;
documente por que foram feitas;
verifique se ainda são necessárias;
determine como serão adaptadas;
teste a adaptação na versão de destino.

Quando possível, customizações devem ser mantidas de maneira que reduzam alterações diretas no núcleo.

Backup do banco não é backup completo do OJS

Este é um dos pontos mais importantes do processo.

Salvar apenas o banco de dados não representa necessariamente um backup completo da instalação OJS.

O banco contém uma parte essencial das informações, mas a instalação também depende de arquivos existentes no sistema.

Uma estratégia de recuperação deve considerar pelo menos:

banco de dados;
arquivos da aplicação;
config.inc.php utilizado pela instalação;
diretório configurado em files_dir;
plugins e temas adicionais;
customizações necessárias;
outros arquivos de configuração relevantes ao ambiente.

O diretório de arquivos é especialmente importante porque contém arquivos submetidos e gerenciados pela aplicação. Um banco restaurado sem os arquivos correspondentes não reconstrói integralmente o acervo operacional.

\[Link interno sugerido: Manutenção preventiva no OJS\]

Verifique se o backup pode ser restaurado

A existência de um arquivo de backup não prova que ele funciona.

Antes de uma mudança importante, o ideal é validar a restauração em ambiente separado.

Verifique:

se o dump do banco pode ser importado;
se os arquivos foram copiados integralmente;
se permissões necessárias podem ser restabelecidas;
se a configuração aponta para os caminhos corretos;
se a aplicação restaurada consegue localizar os arquivos enviados.

O objetivo é responder antecipadamente: se a atualização falhar, conseguimos voltar?

Crie um ambiente de homologação

Executar pela primeira vez uma atualização complexa diretamente em produção aumenta desnecessariamente o risco.

A homologação deve reproduzir, tanto quanto possível, o cenário real:

cópia do banco;
cópia dos arquivos;
mesma versão inicial do OJS;
versão de PHP planejada;
banco compatível;
plugins;
tema;
customizações.

O ambiente também precisa ser isolado para evitar efeitos externos indesejados. Por exemplo, uma cópia de produção não deve começar a enviar e-mails reais aos usuários durante testes.

O arquivo de configuração oficial do OJS 3.5 possui, entre outras opções, um modo sandbox, destinado a impedir interações com sistemas externos em ambientes de desenvolvimento ou teste. A utilização concreta deve ser validada para o ambiente e integrações existentes.

Faça uma atualização de ensaio

Na homologação, documente todas as etapas.

Registre:

duração;
mensagens apresentadas;
avisos;
erros;
ajustes necessários;
plugins desabilitados;
mudanças de configuração;
testes executados.

O resultado deve ser um roteiro reproduzível para produção.

Se a atualização de homologação exige improvisação constante, o procedimento ainda não está pronto para produção.

Prepare a janela de manutenção

Durante a atualização de produção, novas submissões ou alterações podem criar divergências entre o backup e o estado atual.

Planeje uma janela de manutenção adequada ao volume da revista.

Comunique a indisponibilidade quando necessário e evite que usuários continuem alterando dados enquanto a cópia definitiva é realizada.

O tempo da janela deve considerar não apenas o comando de upgrade, mas também backup final, substituição da aplicação, ajustes, testes e margem para rollback.

Execute o upgrade conforme a documentação da versão

O OJS possui processo próprio de upgrade que executa mudanças necessárias na aplicação e no banco.

Os comandos e procedimentos exatos devem ser obtidos da documentação do release utilizado. Não copie cegamente um comando de um tutorial referente a outra versão.

Antes da execução definitiva, confirme novamente:

versão de origem;
versão de destino;
requisitos;
backup;
espaço disponível;
permissões;
configuração;
plugins;
modo de manutenção;
possibilidade de rollback.

Não interrompa deliberadamente uma migração em andamento sem compreender seu estado.

Leia o resultado e os logs

Uma tela aparentemente funcional não significa que toda a atualização terminou corretamente.

Procure mensagens de erro e analise os registros produzidos pelo servidor e pela aplicação conforme o problema encontrado.

Erros de atualização podem estar relacionados a banco, arquivos, permissões, dependências, plugins, dados legados ou etapas preparatórias.

Não adote como primeira resposta a exclusão de dados que bloquearam uma migração. Descubra o que esses dados representam e por que a rotina recusou continuar.

\[Link interno sugerido: Como atualizar o OJS com segurança\]

Testes obrigatórios depois da atualização

Não limite o teste à página inicial.

Uma homologação adequada deve percorrer operações reais.

Acesso e navegação

Teste páginas públicas, autenticação e painel administrativo.

Submissão

Crie uma submissão de teste e confirme arquivos e metadados.

Fluxo editorial

Verifique atribuição editorial, revisão, decisões e movimentação entre etapas.

Produção e publicação

Teste o fluxo necessário até a publicação de um conteúdo de teste.

Arquivos históricos

Abra artigos antigos e verifique se arquivos publicados e documentos internos continuam acessíveis conforme as permissões esperadas.

E-mail

Confirme o mecanismo de envio sem disparar mensagens indevidas durante a homologação.

Plugins e integrações

Teste os plugins realmente usados pela revista, especialmente os relacionados a identificadores, exportação de metadados, autenticação e serviços externos.

Tema

Verifique páginas públicas em diferentes tamanhos de tela e procure erros de template ou componentes quebrados.

Tenha critérios claros para rollback

Rollback não deve significar "tentar colocar os arquivos antigos de volta".

Depois que um processo de upgrade modifica o banco, restaurar apenas o código anterior pode criar incompatibilidade entre aplicação e esquema de dados.

Uma reversão segura normalmente depende da restauração coerente do estado anterior: banco, aplicação, configuração e arquivos relevantes.

Por isso, o ponto de restauração precisa ser criado imediatamente antes da atualização de produção e preservado até que a nova versão seja validada.

Atualizar PHP antes ou depois do OJS?

Não existe uma resposta universal.

A sequência depende da compatibilidade entre:

OJS atual;
OJS de destino;
PHP atual;
PHP de destino;
dependências;
plugins.

Se a versão atual do OJS não suporta o novo PHP, trocar o PHP primeiro pode derrubar a instalação antes mesmo de iniciar o upgrade.

Se a nova versão exige um PHP que o servidor ainda não possui, pode ser necessário preparar paralelamente um ambiente compatível para executar a migração.

O planejamento deve buscar uma sequência em que cada estado intermediário seja suportado.

E se a atualização falhar?

Pare e identifique em qual etapa ocorreu a falha.

Evite repetir a rotina indefinidamente sobre um banco que pode ter sido parcialmente alterado.

Compare a mensagem com os logs, documentação e código da versão correspondente. Dependendo do ponto de falha, a estratégia mais segura pode ser corrigir a causa em homologação, restaurar o estado anterior e repetir o procedimento.

O objetivo não é fazer o upgrade "passar a qualquer custo", mas preservar a integridade da revista.

Checklist antes de atualizar produção

versão atual confirmada;
versão de destino definida;
caminho de upgrade validado;
PHP e extensões validados;
banco de dados validado;
plugins verificados;
customizações inventariadas;
backup do banco concluído;
backup do files_dir concluído;
configuração preservada;
aplicação e customizações preservadas;
restauração testada;
homologação atualizada com sucesso;
testes editoriais executados;
janela de manutenção planejada;
procedimento de rollback documentado.

Perguntas frequentes

Posso atualizar o OJS apenas substituindo os arquivos?

Não é uma regra segura. Atualizações podem exigir migrações de banco e outras etapas. Siga o procedimento oficial correspondente à versão.

Fazer dump do MySQL ou MariaDB é suficiente?

Não. O banco é apenas uma parte da instalação. Também devem ser preservados os arquivos enviados, configuração e demais componentes necessários à restauração.

Posso atualizar diretamente de qualquer OJS antigo para o mais novo?

Não assuma isso. O caminho precisa ser validado na documentação e nas rotinas de upgrade da versão de destino.

Preciso testar todos os plugins?

Priorize todos os plugins efetivamente utilizados, especialmente os críticos para publicação e integrações. A compatibilidade deve ser verificada antes de produção.

É necessário ambiente de homologação?

Para uma revista em produção, é uma das medidas mais importantes para reduzir risco. Permite descobrir incompatibilidades sem afetar usuários e dados ativos.

Conclusão

Uma atualização segura do OJS começa antes do upgrade.

Inventário, compatibilidade, backup completo, teste de restauração e homologação reduzem drasticamente a quantidade de decisões improvisadas durante a janela de produção.

Se a instituição não possui equipe para avaliar versões, dependências, plugins e recuperação, a atualização pode ser executada como um serviço técnico planejado, com homologação e validação antes da mudança definitiva.

Precisa atualizar uma instalação existente?

Uma atualização profissional pode incluir diagnóstico da versão atual, análise de compatibilidade, backup, ambiente de homologação, execução do upgrade e testes posteriores.

Antes de qualquer intervenção, o ponto principal deve ser preservar o conteúdo e garantir uma rota de recuperação.

Fontes consultadas

Public Knowledge Project --- repositório oficial do OJS e

requisitos: https://github.com/pkp/ojs

Public Knowledge Project --- PKP Documentation Hub:

https://docs.pkp.sfu.ca/

Public Knowledge Project --- arquivo oficial de configuração do OJS:

https://github.com/pkp/ojs/blob/main/config.TEMPLATE.inc.php

Public Knowledge Project --- descritor oficial de upgrades:

https://github.com/pkp/ojs/blob/main/dbscripts/xml/upgrade.xml