É possível construir e atualizar um site do Wordpress offline?

4

Parece que o Wordpress é projetado para ter sites construídos e mantidos on-line - no site ao vivo. Eu vejo alguns posts 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 nem um pouco automatizado. Na verdade, não está claro apenas que as alterações podem ser movidas ou se o site inteiro precisaria ser recarregado. Isso parece complicado pelas alterações do visitante no site ao vivo enquanto as atualizações estão sendo criadas. E backups ou controle de versão do conteúdo - bem, eu não fui longe nisso ainda.

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

    
por Patrick Moloney 11.06.2012 / 16:25

5 respostas

1

Depende totalmente dos tipos de alterações que estão sendo feitas. Se você estiver modificando um tema ou um plug-in, dependendo das alterações, provavelmente poderá criá-los localmente ou em um servidor de desenvolvimento remoto e, em seguida, enviá-los para a produção com facilidade.

Isso funciona para um ou dois usuários, com mais usuários você precisa de controle de versão - algo como Git ou SVN - para acompanhar e mesclar as alterações.

Veja isto: enlace

Eu geralmente prefiro ter um servidor de desenvolvimento remoto porque é mais fácil replicar o ambiente de produção e é mais fácil acessar de várias máquinas. A maneira como eu o configurei não é mais lenta do que o desenvolvimento local ... talvez até mais rápido.

    
por user1337 11.06.2012 / 17:38
1
Concorra com @perpetualstudent sobre desenvolvimento off-line. Se você começar instalando no servidor da Web, sempre copie na direção do seu PC, você não estará sobrescrevendo os dados do usuário. Há dois registros na tabela wp_options que precisam ser modificados sempre que você copiar o banco de dados, estes são siteurl e home que precisam ser alterados para apontar para o servidor da Web do PC local.

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 seu site (s) como este:

127.0.0.1   website1 bikefun website3

Em seguida, edite a configuração do seu servidor da Web para criar hosts virtuais. Estou usando o WAMP, então edito

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

e adicione seções como

<VirtualHost *:80>
    ServerAdmin nik@blah.blah
    DocumentRoot "c:/wamp/www/bikefun"
    ServerName bikefun
</VirtualHost>

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

Para atualizar sua versão local para que ela seja igual ao seu servidor da Web, são necessárias duas etapas. O que você tem que fazer com mais freqüência é o banco de dados. Eu uso SQLyog que pode fazer uma cópia do banco de dados remoto em seu PC local, a primeira vez que você fizer isso, você cria um banco de dados vazio no local, em seguida, mude para o servidor, clique direito no nome do banco de dados e "copiar para host diferente ". Tenha cuidado ao copiar que você não sobrescreve acidentalmente um banco de dados de produção, certifique-se de estar copiando para o seu PC local!

Se você estiver usando o cPanel, você pode baixar um dump do banco de dados e executá-lo localmente.

Após a cópia, você precisa alterar esses dois campos na tabela wp_options .

Ao configurar a versão do PC local pela primeira vez, você precisa copiar os arquivos webroot do servidor da Web ou duplicar a instalação exata localmente. Por exemplo, no servidor da Web, acesse webroot e use algo como

tar -czf name.tgz website-directory/

copie name.tgz para sua máquina local e extraia-a em sua raiz local com algo como 7-zip.

Subsequentemente eu raramente repito a cópia dos arquivos, você pode manter a cópia local sincronizada fazendo as mesmas atualizações de 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 gravando plug-ins ou temas, precisará de controle de versão. Eu quase sempre criar um tema filho e colocá-lo em controle de versão, 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 repositório GIT no diretório plugin ou theme e clone-o no github.com. Então clonei do github para o servidor web (supondo que você o tenha criado / editado no seu PC local). Dessa forma, você pode desenvolver localmente e empurrar suas alterações para o github (ou para o seu repositório de escolha) e colocá-las no servidor da web para atualizar o plug-in / theme lá.

git pull origin master

Isso lhe dá a capacidade de retroceder caso as coisas dêem errado, apesar do teste cuidadoso no seu PC local. Assim, ambos os webroots do WordPress terão um ou mais repositórios GIT incorporados no diretório wp-content inside plugins or themes . Para implantar a partir do github para o servidor live, eu uso um script de shell simples:

#!/bin/bash
# Argument = -w <website> -t <theme> -n <name>
# 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. e.g. 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 de desenvolvimento local. Mas também acho útil porque alterno entre o desktop e o laptop.

Às vezes, estou trabalhando no meu laptop, onde não há conexão com a 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 os tempos limite de desacelerar tudo quando você estiver usando o WordPress offline: enlace

    
por Nik Dow 04.05.2015 / 13:20
0

Executamos todo o nosso desenvolvimento localmente em nossas máquinas. Nós usamos o MAMP Pro para hospedar nossos ambientes e bancos de dados locais. O Git é usado para controle de versão e implantamos essas alterações 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 trabalhar na sua máquina do que em um servidor), faremos uma exportação / despejo do banco de dados. Depois que o banco de dados é importado e os arquivos são implantados, é apenas uma questão de alterar alguns valores no banco de dados e wp-config.php .

Aconselho veementemente a não fazer alterações em nenhum site ativo. Você deseja fazer alterações em um ambiente protegido (leia-se: não público) para garantir que não estrague algo de verdade. É certo, no entanto, que é preciso um pouco de trabalho para criar uma infraestrutura que facilite a modificação segura dos sites ao vivo com segurança.

Por enquanto, eu ficaria com MAMP (WAMP, se o seu no Windows) rodando em sua máquina e obtendo um site local funcionando.

    
por perpetualstudent 11.06.2012 / 17:31
0

Acabei de atualizar um grande site WordPress em vários ambientes, colocando cada um deles totalmente offline enquanto realizava a atualização. Estamos usando o IIS como servidor da Web, mas, como agradeço que a maioria das pessoas use o Apache, tentarei e manteremos as etapas o mais genéricas possível para aplicá-las às duas configurações.

Estas são as etapas:

  1. Coloque o site offline (lembre-se de que fizemos isso no IIS, portanto, se estiver usando o Apache, você precisará usar a configuração do Apache para fazer isso):

    a) Tome nota de como os redirecionamentos 404 são feitos na configuração da web. Você precisará disso mais tarde. Alterar redirecionamentos 404 para apontar para a raiz do site, por exemplo enlace

    b) Altere a configuração do servidor da web para apontar para uma página de retenção em uma estrutura de pastas separada para a que contém o site do WordPress. Montamos apenas um arquivo, index.html, com uma mensagem "Website em manutenção".

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

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

  2. Crie um backup do banco de dados do WordPress. (verifique se você sabe como restaurar um banco de dados se precisar - usamos o heidisql para backup e restauração).

  3. Copie todos os arquivos do site para um servidor da Web local e configure o servidor da Web local para ter exatamente o mesmo domínio do site ativo. Em uma máquina Windows, a edição c:\windows\system32\drivers\etc\hosts para adicionar 127.0.0.1 example.com é necessária para garantir que o navegador seja resolvido para a máquina local.

Note que mesmo que você esteja atualizando apenas arquivos localmente inicialmente, você estará atualizando o banco de dados ativo, e quaisquer backups / restaurações de banco de dados etc. referem-se ao banco de dados ativo, isto é, usado pelo site ativo .

  1. Faça uma lista de todos os plug-ins ativos .

  2. Desativar todos os plug-ins

  3. Atualize todos os plug-ins

  4. Atualize o WordPress, seguindo as etapas implementadas, incluindo a atualização do banco de dados.

  5. Antes de ativar os plug-ins, veja se mais plugins precisam ser atualizados (isso pode acontecer - mesmo que você já tenha concluído uma rodada de atualização)

  6. Ative cada plug-in que requer ativação de 1 em 1. Se você for solicitado a fazer upgrade do plug-in neste estágio, faça upgrade.

  7. Teste o site nas extremidades frontal e traseira. Se você receber algum erro irrecuperável, restaure os arquivos do site de backup em seu servidor local e restaure seu banco de dados de backup ativo e comece novamente a partir da etapa 6. Se você tiver os mesmos problemas novamente, talvez seja necessário fazer alguma pesquisa sobre como resolvê-los antes de prosseguir. Se você precisar restaurar seu antigo site ativo nesse meio tempo, restaure o banco de dados e siga as etapas 14 e 15 abaixo.

  8. Após o teste bem-sucedido do site em sua máquina local, copie os arquivos de sua instalação local de volta para sua pasta do WordPress ativa.

  9. Na sua máquina local, comente " # " a entrada feita no seu arquivo hosts no item 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 WordPress ao vivo.

    b) Restaurando o redirecionamento 404 para o que era antes de você alterá-lo

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

por dewd 22.05.2015 / 12:11
-3

Use enlace , pois acho que esse é o melhor plugin do mercado ... e não, eu não tenho interesse comercial nisso.

Felicidades Mac

    
por Mac 16.07.2013 / 11:24