Guia de atualização

Roteiro para levar o WordPress de cursos de WordPress 4.9.9 / PHP 7.2 / MariaDB 10.3, com tema pirateado, para versões suportadas, sem quebrar matrículas, pagamentos e o progresso dos alunos. Enquanto isso não for feito, o site continua exposto às falhas listadas em Vulnerabilidades confirmadas.

Regras do processo:

  1. Nunca atualizar direto em produção. Todo passo é ensaiado em homologação.

  2. Um passo por vez, com teste e backup entre eles. Atualizar tudo junto torna impossível saber o que quebrou.

  3. A homologação não envia e-mails nem cobra ninguém. Ver Etapa 1: sandbox (homologação).

Pré-requisitos

Item Detalhe

Licença do Eduma

Comprar na ThemeForest (autor ThimPress). A licença dá acesso ao tema oficial, ao Thim Core e aos plugins premium do pacote (WPBakery, Slider Revolution, add-ons do LearnPress). Sem isso, não há como sair da cópia pirata.

Outras licenças

ACF PRO, Admin Columns Pro, Admin Menu Editor Pro e GP Premium, somente dos que continuarem necessários depois da limpeza de inventário (ver Plugins e temas).

Responsável pelo conteúdo

Alguém da escola para validar cursos, aulas, certificados e o fluxo de compra.

Lista de fluxos críticos

Ver Fluxos críticos para testar em cada etapa.

Janela de manutenção

Necessária só na virada final (Etapa 8: virada em produção). Usar horário de baixo uso.

Etapa 0: backup

Com o backup automático ativo (ver Backup e restore), basta um backup avulso e conferir que ele terminou:

kubectl --context oracle -n legacy-sites create job --from=cronjob/wp-cursos-backup antes-da-atualizacao
kubectl --context oracle -n legacy-sites logs -f job/antes-da-atualizacao -c upload   # "backup ok: ..."

Sem ele, a cópia manual:

# banco (o arquivo fica na máquina local; guardar fora do cluster)
kubectl --context oracle -n legacy-sites exec mariadb-0 -- \
  sh -c 'mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" --single-transaction --routines enj | gzip' \
  > enj-$(date +%Y%m%d).sql.gz

# arquivos (webroot inteiro do volume)
kubectl --context oracle -n legacy-sites exec deploy/wp-cursos -c wordpress -- \
  tar -C /var/www/html -czf - . > wp-cursos-$(date +%Y%m%d).tar.gz

Conferir se os dois arquivos abrem (gunzip -t, tar -tzf … | head) antes de seguir.

Etapa 1: sandbox (homologação)

O sandbox já existe: namespace legacy-sites-staging, pasta legacy-sites-staging/ do repositório gitops. Ver Sandbox para o funcionamento. Em resumo:

  • é uma cópia da produção no mesmo domínio (cursos.artesmarciaisonline.com.br), num IP próprio. O especialista alterna entre real e sandbox pelo navegador (sandbox-chrome.sh, uma janela que sempre vai para o sandbox) ou pelo /etc/hosts (wp-sandbox-hosts.sh on|off);

  • pede senha de acesso antes de qualquer página; o login do WordPress é o da produção;

  • não envia e-mail, não roda WP-Cron e bloqueia HTTP externo (exceto *.wordpress.org, ThimPress e GitHub), via o mu-plugin sandbox-guard; PayPal e PMPro ficam em modo de teste e o ManageWP desativado; uma faixa vermelha SANDBOX aparece em todas as páginas;

  • refresh.sh (no gitops) recria o sandbox a partir da produção quando for preciso recomeçar.

O kit do especialista (scripts e LEIA-ME.md) fica em legacy-sites-staging/especialista/.

Para comandos administrativos, o WP-CLI roda dentro do container do sandbox: kubectl --context oracle -n legacy-sites-staging exec deploy/wp-cursos -c wordpress — sh -c 'curl -sO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && php wp-cli.phar --allow-root --path=/var/www/html plugin list'

Etapa 2: limpeza de inventário

Remover tudo marcado como remover em Plugins e temas, em especial os plugins que executam código pelo painel, o Easy Updates Manager, o WP Downgrade, o WP Rollback, o Hello Dolly e os temas padrão antigos. Retestar os fluxos críticos.

Etapa 3: tema e plugins premium legítimos

  1. Instalar o Eduma oficial na versão mais recente, junto com o Thim Core e os plugins exigidos pelo tema, a partir do pacote licenciado. A cópia pirata atual sai inteira, sem reaproveitar arquivos.

  2. Manter o tema filho eduma-child, mas revisar o functions.php dele linha a linha.

  3. Reinstalar WPBakery e Slider Revolution do pacote oficial e conferir as páginas montadas com eles.

  4. Ativar as licenças dos premium que ficarem.

Etapa 4: core do WordPress

php wp-cli.phar --allow-root core update            # 4.9.9 -> versão atual
php wp-cli.phar --allow-root core update-db         # migração do banco do core

Se algum plugin quebrar, voltar ao backup e fazer o salto em degraus (4.9 → 5.9 → 6.x).

Etapa 5: plugins de LMS e vendas

São as atualizações com migração de dados, e as mais arriscadas:

Plugin Salto Cuidado

LearnPress

3.x → 4.x

Mudança estrutural. O LearnPress 4 tem uma ferramenta própria de atualização do banco. Atualizar o LearnPress e todos os add-ons juntos, nas versões 4.x. A versão do Eduma precisa ser compatível com o LearnPress 4. Conferir o progresso e os certificados de alunos reais depois.

Paid Memberships Pro

1.9 → 3.x

Migração de banco automática. Conferir níveis, assinaturas ativas e configuração do gateway.

WooCommerce

3.4 → atual

Migração de banco automática (pode ser demorada). Conferir pedidos, produtos e e-mails.

Os demais plugins marcados como atualizar vêm em seguida, um a um ou em pequenos grupos.

Etapa 6: PHP 7.2 → 8.x

  1. Trocar a imagem do container wordpress por uma oficial atual (por exemplo wordpress:6-php8.2-fpm). No sandbox, isso é o bloco images: de gitops/legacy-sites-staging/kustomization.yaml; validado, a mesma linha vai para gitops/legacy-sites/kustomization.yaml na virada.

  2. Se algum plugin tiver erro fatal no PHP 8 (ver wp-content/debug.log), passar antes pelo wordpress:5-php7.4-fpm como degrau intermediário.

As imagens atuais não reescrevem mais o wp-config.php existente (ver o comportamento da imagem antiga). Depois da troca, mudar o Secret wp-cursos-db não altera mais nada no site. Escolha uma das opções:

  • manter o wp-config.php como fonte da verdade e atualizá-lo junto com o Secret; ou

  • ajustar o wp-config.php para ler as variáveis de ambiente (getenv('WORDPRESS_DB_PASSWORD')).

Etapa 7: MariaDB 10.3 → LTS atual

Preferir dump e restauração em um StatefulSet novo, com PVC novo e uma imagem LTS atual (por exemplo mariadb:11.4). Assim o volume antigo fica intacto como rollback. Depois:

  • criar um usuário de banco só para o enj (hoje o mesmo usuário acessa os três bancos);

  • apontar o Secret ou o wp-config.php para o Service novo.

Fluxos críticos para testar em cada etapa

  • Home, página de curso e listagem de cursos carregam sem erro

  • Login de aluno, login de administrador e recuperação de senha

  • Cadastro de aluno, se o cadastro continuar aberto

  • Compra/assinatura completa (gateway em sandbox) e liberação do curso

  • Aula, quiz, tarefa e conclusão de curso, com emissão do certificado

  • Painel do instrutor/administrador: editar curso, ver alunos e notas

  • E-mails transacionais (na homologação, para um destino de teste)

  • wp-content/debug.log sem erros fatais

  • Tempo de resposta e memória por worker (kubectl top pod), para recalibrar pm.max_children e os limites

Etapa 8: virada em produção

A homologação serve para ensaiar, não para ser promovida: durante as semanas de teste a produção continua recebendo alunos, pedidos e progresso. Na janela de manutenção:

  1. Pôr a produção em manutenção (arquivo .maintenance na raiz do webroot) e fazer o backup da etapa 0.

  2. Repetir em produção, na mesma ordem, os passos ensaiados e registrados no sandbox (o sandbox não é copiado por cima da produção). Trocas de imagem entram por commit em gitops/legacy-sites/.

  3. Limpar o cache (wp-content/cache/all/) e retirar a manutenção.

  4. Executar os fluxos críticos em produção.

Rollback

  • Arquivos: voltar a imagem anterior no Deployment e restaurar o tar da etapa 0 no PVC.

  • Banco: restaurar o dump da etapa 0 (ou voltar o Service para o StatefulSet antigo, se a etapa 7 foi feita com volume novo).

  • Sem o backup verificado da etapa 0, não iniciar a virada.

Endurecimento depois da atualização

  • define('DISALLOW_FILE_EDIT', true); no wp-config.php (sem editor de temas e plugins no painel);

  • manter o bloqueio do xmlrpc.php (nginx do pod e WAF da Cloudflare);

  • autenticação em dois fatores para administradores e revisão de quem precisa ser administrador;

  • revisar o cadastro aberto (users_can_register). Se for mantido, adicionar CAPTCHA e confirmação de e-mail;

  • atualizações automáticas de segurança ligadas (sem Easy Updates Manager bloqueando);

  • backup automatizado do banco e do volume para fora do cluster;

  • NetworkPolicy isolando o namespace, quando o cluster tiver um controller de política.

Pegadinhas conhecidas

  • Entrypoint da imagem antiga: reescreve os DB_* do wp-config.php a cada start (ver arquitetura.adoc#entrypoint).

  • Estratégia Recreate: toda mudança no Deployment derruba o site por alguns segundos.

  • PVC RWO: um pod por vez. Não dá para subir uma segunda réplica nem um pod auxiliar em outro nó com o mesmo volume.

  • Cache: depois de mudar tema, plugin ou conteúdo, limpar o cache do WP Fastest Cache, ou o site continua servindo o HTML antigo.

  • IP real: plugins de segurança precisam ler CF-Connecting-IP/X-Forwarded-For (ver Arquitetura).