Implantando atualizações de conteúdo do servidor intermediário para o servidor ativo

Estamos tentando implantar atualizações de conteúdo do servidor de temporariedade para o servidor ativo, mas estamos tendo dificuldade em encontrar uma boa maneira de fazer isso. Precisamos ser capazes de implantar novas páginas, atualizações de página e, ocasionalmente, exclusões de páginas. Nosso site também faz uso extensivo do módulo book, para que o módulo Deploy não funcione para nós no momento. Estamos usando recursos para grandes atualizações de estrutura. Portanto, nossa preocupação é apenas as atualizações diárias de conteúdo.

Existem módulos que podem fazer isso e lidar com páginas de livros?

Os recursos UUID e UUID permitem exportar um nó para um recurso, que pode ser exatamente o que você procura, significa que você não precisa mexer no banco de dados.

Você já tentou o node_export e o Backup Migrate . Ambos os módulos são usados ​​para migrar conteúdo entre instalações do Drupal. Aqui está uma comparação entre os módulos de importação / exportação de dados que você pode achar útil.

Estou assumindo o Drupal 6 aqui e pessoalmente não sei se ele funcionará com o módulo book, mas você já olhou para o Deployment ?

Você também pode tentar Phing , com o qual você pode automaticamente:

• Despejar o banco de dados temporário usando o mysqldump.
• Copie o arquivo mysqldump de um servidor para outro usando a criptografia SCP e chave pública-privada.
• Importe o mysqldump do sistema de arquivos para o banco de dados.
• Execute o comando Reverter tudo ( drush fra -y) para que o servidor de produção selecione as configurações de produção (como blocos, visualizações, contextos etc.) encontradas no código de recursos.

Problemas que vejo com esta abordagem:

Você precisará fazer uma exportação de banco de dados com granulação muito fina, isso significa pegar apenas as tabelas node, node_revisions, cck e menu.

Nesse último ponto (links de menu), a menos que você acesse o servidor de palco e de produção usando os mesmos aliases de URL, você terá entradas de itens de menu diferentes, e isso será um problema sério.

Na verdade, eu gosto do método de despejo de banco de dados completo, que pode ser script e geralmente pode ser concluído em apenas alguns segundos. (Manter suas revisões sob controle e excluir tabelas de cache etc. pode reduzir muito o tamanho.) Você pode até criar um módulo simples para fornecer uma interface para os editores de conteúdo acionarem esse processo.

Você precisa prestar contas de qualquer conteúdo que possa aceitar dos usuários de seu site ativo, como comentários ou envios de formulários de contato. Se houver algum - surpreendentemente, não existe - você pode usar um serviço externo, como Disqus para comentários ou Marketo para formulários de geração de leads, segregar cuidadosamente esses envios em um banco de dados Drupal separado que não seja sobrescrito ou cuidadosamente não sobrescrever aqueles tabelas afetadas durante o processo de exportação / importação.

Onde pode ser feito para funcionar, pode acabar sendo o método mais simples, rápido e confiável. E um site que nunca aceita informações dos usuários (exceto serviços externos) abre muitas portas para tornar-se muito mais rápido e mais seguro.