É viável construir e atualizar um site WordPress offline?

Parece que o WordPress foi projetado para ter sites construídos e mantidos on-line – no site ao vivo. Eu vejo algumas postagens aqui que indicam que algumas pessoas estão fazendo esse desenvolvimento offline – no Localhost. Mas o esforço para mover um site on-line – especialmente para atualizações – parece ser complexo, um tanto manual e não automatizado. Na verdade, não está claro se as mudanças podem ser movidas, ou se o site inteiro tiver que ser recarregado. Isso parece complicado pelas mudanças de visitantes no site ao vivo enquanto as atualizações estão sendo criadas. E backups ou version control do conteúdo – bem, eu ainda não fui tão longe disso.

Então, o que funciona? É melhor fazer alterações no site ao vivo? Qual seria a melhor abordagem para fazer o desenvolvimento offline?

Solutions Collecting From Web of "É viável construir e atualizar um site WordPress offline?"

Depende totalmente dos tipos de mudanças que estão sendo feitas. Se você estiver modificando um tema ou um plugin, dependendo de quais são as mudanças, provavelmente você pode construí-los localmente ou em um servidor de dev remoto, e empurre-os para a produção com facilidade.

Isso funciona para um usuário ou dois, com mais usuários você precisa de version control – algo como Git ou SVN – para rastrear e mesclar mudanças.

Veja isso: https://stackoverflow.com/questions/9705849/how-to-set-up-a-stageing-enviorment-for-wordpress-wordpress-mu/10837071

Normalmente, eu prefiro ter um servidor de dev remoto porque é mais fácil replicar o ambiente de produção e é mais fácil acessar várias máquinas. A maneira como eu configurou isso não é mais lenta que o desenvolvimento local … possivelmente ainda mais rápido.

Conforme com @perpetualstudent sobre o desenvolvimento offline. Se você começar por instalar no servidor web, então sempre copie na direção do seu PC, você não irá replace os dados do usuário. Existem dois registros na tabela wp_options que precisam ser modificados sempre que você copiar o database, estes são o siteurl e a home que precisam mudar para apontar para o seu servidor local do PC.

Para isso eu uso o arquivo Windows / etc / hosts (no Windows 7 você precisa executar um editor como administrador para editar este arquivo, e está em C:\Windows\System32\drivers\etc\hosts ). Crie nomes DNS estáticos para o (s) seu (s) site (s) como este:

 127.0.0.1 website1 bikefun website3 

Em seguida, edite sua config de servidor web para criar hosts virtuais. Estou usando o WAMP, então eu edito

 C:\wamp\bin\apache\apache2.4.9\conf\extra\httpd-vhosts.conf 

e adicione seções como

  ServerAdmin nik@blah.blah DocumentRoot "c:/wamp/www/bikefun" ServerName bikefun  

então você pode apontar seu navegador em http://bikefun (por exemplo). Isso é melhor do que apenas executar via http://localhost/src/bikefun por exemplo, além de qualquer outra coisa, mantém os caminhos relativos iguais no seu PC versus seu servidor de produção.

Para atualizar sua versão local para que seja igual ao seu servidor web, execute duas etapas. O que você tem que fazer com mais freqüência é o database. Eu uso o SQLyog, que pode fazer uma cópia do database remoto no seu PC local, na primeira vez que você faz isso, você cria um database vazio local, depois mude para o servidor, clique com o botão direito do mouse no nome do database e “copie para outro host “. Tenha cuidado ao copiar que você não substitui acidentalmente uma base de dados de produção, certifique-se de que está copiando para o seu PC local!

Se você estiver usando o cPanel, você pode baixar um despejo do database e executá-lo localmente.

Depois de copiar, você precisa alterar esses dois campos na tabela wp_options .

Ao configurar sua versão para PC local pela primeira vez, você precisa copiar os arquivos webroot do servidor web, ou então duplicar a instalação exata localmente. Por exemplo, no servidor web, vá para webroot e use algo como

 tar -czf name.tgz website-directory/ 

então copie name.tgz para sua máquina local e name.tgz -o em seu webroot local com algo como 7-zip.

Posteriormente, raramente repito a cópia dos arquivos, você pode manter a cópia local sincronizada fazendo as mesmas atualizações da versão e instalando os mesmos plugins etc. Mas você pode repetir a cópia do arquivo a qualquer momento se as coisas ficarem confusas no PC local.

Se você estiver modificando ou escrevendo plugins ou temas, você precisa de version control. Eu quase sempre crio um tema infantil e colocá-lo no version control, mas isso não é necessário se você não estiver modificando o tema. Uma vez que eu crie um novo plugin ou edite um existente, eu crio um repository GIT no diretório do plugin ou tema e clone isso para o github.com. Então eu clonei do github para o servidor web (assumindo que você criou / editou no seu PC local). Dessa forma, você pode se desenvolver localmente e empurrar suas mudanças para o github (ou seu repository de eleição) e puxá-las para dentro do servidor web para atualizar o plugin / tema lá.

 git pull origin master 

Isso lhe dá a capacidade de reverter se as coisas der errado, apesar do seu teste cuidadoso no PC local. Então, ambos seus webroots do WordPress terão um ou mais repositorys GIT embutidos no wp-content dentro do diretório de plugins ou themes . Para implantar a partir do github para o servidor ao vivo, eu uso um script de shell simples:

 #!/bin/bash # Argument = -w  -t  -n  # if -t is not given, plugin is assumed usage() { cat < < EOF usage: $0 options Deploy a git repository to a wordpress theme or plugin OPTIONS: -h Show this message -w website. eg bikefun -t it's a theme, otherwise it's a plugin -n name of plugin or theme EOF } THEME="false" WEBSITE= NAME= # anything that needs a parameter has a : after it. while getopts .htw:n:. OPTION do case $OPTION in h) usage exit 1 ;; t) THEME="true" ;; w) WEBSITE=$OPTARG ;; n) NAME=$OPTARG ;; ?) usage exit ;; esac done if [[ -z $WEBSITE ]] then usage exit 1 fi if [[ -z $NAME ]] then usage exit 1 fi # make sure the repository is up-to-date cd /home/lamp/webroot cd $WEBSITE cd wp-content if [ $THEME = "true" ] then cd themes else cd plugins fi cd $NAME # overwrite any local changes - # this gives freedom to hotfix directly on the server and later overwrite it git fetch origin master git reset --hard FETCH_HEAD git clean -df service apache2 reload 

Usando escalas GIT se você estiver trabalhando com outros desenvolvedores no mesmo projeto e cada um de vocês tiver uma cópia local do dev. Mas também acho útil porque troco de desktop e laptop.

Às vezes eu estou trabalhando no meu laptop, onde não há conexão à internet. É uma ótima maneira de preencher um vôo de avião longo e não há interrupções ou distrações enquanto você trabalha! Aqui está um artigo sobre como parar o tempo limite de desacelerar tudo quando você estiver usando o WordPress offline: http://www.cbdweb.net/wordpress-development-offline/

Nós executamos todo o nosso desenvolvimento localmente em nossas máquinas. Usamos o MAMP Pro para hospedar nossos ambientes e bancos de dados locais. O Git é usado para version control e nós implantamos essas mudanças em nossos servidores de produção com o Beanstalk .

Uma vez que o desenvolvimento é feito localmente (o que é feito principalmente por razões de velocidade – é muito mais rápido para trabalhar em sua máquina do que em um servidor), faremos uma exportação / despejo do database. Uma vez que o database é importado e os arquivos são implantados, é apenas uma questão de mudar alguns valores no database e wp-config.php .

Eu recomendaria fortemente contra qualquer alteração em qualquer site ao vivo. Você quer fazer alterações em um ambiente protegido (lido: não público) para se certificar de que você não descarta nada. É certo que, no entanto, é preciso um pouco de trabalho para criar uma infra-estrutura que facilite a modificação dos sites ao vivo com segurança.

Por enquanto, eu ficaria com o MAMP (WAMP se o seu no Windows) em execução na sua máquina e obter um site local funcionando.

Acabei de atualizar um grande site WordPress através de vários ambientes, levando cada um completamente offline enquanto eu fiz a atualização. Estamos usando o IIS como servidor web, mas desde que eu aprecio que a maioria das pessoas use o Apache, vou tentar manter as etapas tão genéricas quanto possível para aplicar a ambas as configurações.

Estas são as etapas:

  1. Tire o site offline (tenha em mente que fizemos isso no IIS, então, se usando o Apache, você precisaria usar a configuração do Apache para fazer isso):

    a) Tire nota de como 404 redirecionamentos são feitos na configuração da web. Você precisará disso mais tarde. Altere 404 redirecionamentos para apontar para a raiz do site, por exemplo, http://example.com

    b) Altere a configuração do servidor web para apontar para uma página de espera em uma estrutura de pasta separada para aquela que contém o site do WordPress. Nós configuramos apenas um arquivo, index.html com uma mensagem “Website em manutenção”.

O site agora está desligado e não pode ser acessado ou atualizado. É efetivamente estático enquanto você atualiza – a menos que você tenha outra configuração da web apontando para a pasta do WordPress. Se você fizer isso, tire isso offline da mesma maneira.

  1. Crie uma cópia de backup dos arquivos na pasta WordPress.

  2. Crie um backup do database do WordPress. (Certifique-se de saber como restaurar um database se você precisar – usamos o heidisql para fazer backup e restaurar).

  3. Copie todos os arquivos do site para um servidor web local e configure o servidor web local para ter exatamente o mesmo domínio que o seu site ao vivo. Em uma janela de edição de janelas c:\windows\system32\drivers\etc\hosts para adicionar 127.0.0.1 example.com é necessário para garantir que o navegador se resolva na máquina local.

Observe que, mesmo que você apenas esteja atualizando os arquivos localmente, você estará atualizando o database ao vivo e qualquer backup / restauração do database, etc, consulte o database ao vivo, ou seja, usado pelo site ao vivo.

  1. Faça uma lista de todos os plugins ativos .

  2. Desativar todos os plugins

  3. Atualize todos os plugins

  4. Atualize o WordPress, seguindo as etapas como proompted incluindo atualização de database.

  5. Antes de ativar os plugins, veja se mais plugins precisam ser atualizados (isso pode acontecer – mesmo se você já completou uma rodada de atualizá-los)

  6. Ative cada plugin que requer a ativação 1 em 1. Se você for solicitado a atualizar o plugin neste estágio, atualize-o.

  7. Teste o site nas extremidades frontal e traseira. Se você tiver algum erro irrecuperável, restaure os arquivos do site de backup no seu servidor local e restaure seu database de backup ao vivo e comece novamente a partir do passo 6. Se você tiver os mesmos problemas novamente, talvez seja necessário fazer alguma pesquisa sobre como resolvê-los antes de ir mais longe. Se você precisar restaurar o site ao vivo antigo, entretanto, restaure o database e siga as etapas 14 e 15 abaixo.

  8. Após testes bem sucedidos do site em sua máquina local, copie os arquivos da sua instalação local de volta para sua pasta ao vivo do WordPress.

  9. Em sua máquina local, comente ” # ” a input feita em seu arquivo de hosts em 4 acima.

  10. Inverta o que foi feito em 1) acima por:

    a) Alterando a configuração do servidor web para apontar para o site ao vivo do WordPress.

    b) Restaurando o redirecionamento 404 para o que era antes de mudá-lo

  11. Teste seu site no domínio ao vivo.

Basta usar http://www.seedprod.com, pois acho que este é o melhor plugin do mercado … e não tenho interesse comercial nisso.

Cheers Mac