web-dev-qa-db-fra.com

Est-il possible de créer et de mettre à jour un site Web Wordpress hors ligne?

Il semble que Wordpress est conçu pour que les sites Web soient construits et maintenus en ligne - sur le site Web en direct. Je vois quelques articles ici qui indiquent que certaines personnes font un tel développement hors ligne - dans Localhost. Mais l’effort de mise en ligne d’un site Web - en particulier pour les mises à jour - apparaît complexe, quelque peu manuel et pas du tout automatisé. En fait, il n’est pas clair que les modifications peuvent être déplacées, ou si le site Web entier doit être rechargé. Cela semble compliqué par les modifications apportées par les visiteurs au site Web en direct pendant la création des mises à jour. Et les sauvegardes ou le contrôle de version du contenu - eh bien, je ne suis pas encore allé trop loin là-dessus.

Alors qu'est-ce qui fonctionne? Est-il préférable de modifier le site Web en direct? Quelle serait la meilleure approche pour faire du développement hors ligne?

theme-developmentlocalhostlocal-installationoffline
4
Patrick Moloney

Cela dépend totalement des types de changements apportés. Si vous modifiez un thème ou un plug-in, en fonction de la nature des modifications, vous pouvez probablement les construire localement ou sur un serveur de développement distant, puis les mettre facilement en production.

Cela fonctionne pour un utilisateur ou deux, et avec plus d'utilisateurs, vous avez besoin d'un contrôle de version - quelque chose comme Git ou SVN - pour suivre et fusionner les modifications.

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

Je préfère généralement disposer d'un serveur de développement distant, car il est plus facile de répliquer l'environnement de production et d'accéder à plusieurs machines. La façon dont je l'ai mis en place n'est pas plus lente que le développement local ... peut-être même plus vite.

1
user1337

Convenez avec @perpetualstudent à propos du développement hors ligne. Si vous commencez par installer sur le serveur Web, puis copiez-le toujours dans le sens de votre ordinateur, vous ne remplacerez pas les données de l'utilisateur. Il existe deux enregistrements dans la table wp_options qui doivent être modifiés chaque fois que vous copiez la base de données. Il s'agit de siteurl et home qui doivent être modifiés pour pointer vers votre serveur Web PC local.

Pour cela, j'utilise le fichier windows/etc/hosts (sous Windows 7, vous devez exécuter un éditeur en tant qu'administrateur pour modifier ce fichier, qui se trouve à C:\Windows\System32\drivers\etc\hosts). Créez des noms DNS statiques pour votre (vos) site (s) comme ceci:

127.0.0.1   website1 bikefun website3

Puis modifiez votre configuration de serveur Web pour créer des hôtes virtuels. J'utilise WAMP, donc je modifie

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

et ajouter des sections comme

<VirtualHost *:80>
    ServerAdmin [email protected]
    DocumentRoot "c:/wamp/www/bikefun"
    ServerName bikefun
</VirtualHost>

alors vous pouvez pointer votre navigateur sur http://bikefun (par exemple). Cela vaut mieux que de simplement exécuter via http://localhost/src/bikefun par exemple, mis à part le reste, les chemins relatifs restent les mêmes sur votre PC par rapport à votre serveur de production.

Pour actualiser votre version locale de la même manière que votre serveur Web, vous devez suivre deux étapes. Celui que vous devez faire le plus souvent est la base de données. J'utilise SQLyog qui peut faire une copie de la base de données distante sur votre PC local. La première fois que vous faites cela, vous créez une base de données vide sur local, puis basculez vers le serveur, cliquez avec le bouton droit sur le nom de la base de données et effectuez une copie sur un autre hôte. ". Lors de la copie, veillez à ne pas écraser accidentellement une base de données de production. Assurez-vous de bien la copier sur votre PC local!

Si vous utilisez cPanel, vous pouvez télécharger un dump de la base de données et l'exécuter localement.

Après la copie, vous devez modifier ces deux champs dans la table wp_options.

Lorsque vous configurez la version de votre ordinateur local pour la première fois, vous devez copier les fichiers Webroot à partir du serveur Web ou dupliquer l’installation exacte localement. Par exemple, sur le serveur Web, accédez à Webroot et utilisez quelque chose comme:

tar -czf name.tgz website-directory/

copiez ensuite name.tgz sur votre ordinateur local et extrayez-le dans votre racine Web avec quelque chose comme 7-Zip.

Par la suite, je répète rarement la copie des fichiers; vous pouvez conserver la copie locale synchronisée en effectuant les mêmes mises à jour de version et en installant les mêmes plug-ins, etc.

Si vous modifiez ou écrivez des plugins ou des thèmes, vous avez besoin d'un contrôle de version. Je crée presque toujours un thème enfant et le mets dans le contrôle de version, mais cela n'est pas nécessaire si vous ne modifiez pas le thème. Une fois que je crée un nouveau plugin, ou que je modifie un existant, je crée un référentiel GIT dans le répertoire du plugin ou du thème et le clone à github.com. Ensuite, je clone de github sur le serveur Web (en supposant que vous l’ayez créé/édité sur votre PC local). De cette façon, vous pouvez développer localement et transmettre vos modifications à github (ou à votre référentiel de choix) et les transférer dans le serveur Web pour y mettre à niveau le plugin/thème.

git pull Origin master

Cela vous donne la possibilité de revenir en arrière en cas de problème en dépit de vos tests minutieux sur votre PC local. Ainsi, vos deux webroots WordPress auront un ou plusieurs référentiels GIT incorporés dans le répertoire wp-content du répertoire plugins ou themes. Pour déployer de github sur le serveur live, j'utilise un script Shell simple:

#!/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

L'utilisation de GIT évolue si vous travaillez avec d'autres développeurs sur le même projet et que chacun de vous dispose d'une copie de développement local. Mais je le trouve aussi pratique car je bascule entre un ordinateur de bureau et un ordinateur portable.

Parfois, je travaille sur mon ordinateur portable où il n'y a pas de connexion Internet. C'est un excellent moyen de faire un long vol d'avion et il n'y a aucune interruption ou distraction pendant que vous travaillez! Voici un article sur la façon d'empêcher les délais d'attente de tout ralentir lorsque vous utilisez WordPress hors connexion: http://www.cbdweb.net/wordpress-development-offline/

1
Nik Dow

Nous exécutons tous nos développements localement sur nos machines. Nous utilisons MAMP Pro pour héberger nos bases de données et environnements locaux. Git est utilisé pour le contrôle de version et nous déployons ces modifications sur nos serveurs de production avec Beanstalk .

Une fois que le développement est fait localement (ce qui est principalement fait pour des raisons de rapidité - il est beaucoup plus rapide de travailler sur votre machine que sur un serveur), nous allons effectuer un export/dump de la base de données. Une fois la base de données importée et les fichiers déployés, il vous suffit de modifier quelques valeurs de la base de données et wp-config.php.

Je déconseille fortement d'apporter des modifications à un site Web en direct. Vous souhaitez apporter des modifications dans un environnement protégé (lire: non public) pour vous assurer de ne pas gâcher royalement quelque chose. Toutefois, il faut certes beaucoup de travail pour mettre en place une infrastructure facilitant la modification de sites en direct en toute sécurité.

Pour le moment, je préférerais que MAMP (WAMP sous Windows) soit exécuté sur votre ordinateur et qu'un site local soit opérationnel.

0
perpetualstudent

Je viens de mettre à niveau un grand site WordPress dans plusieurs environnements, en les mettant complètement hors ligne pendant l'exécution de la mise à niveau. Nous utilisons IIS en tant que serveur Web, mais comme j'apprécie l'utilisation d'Apache pour la plupart des gens, je vais essayer de conserver les étapes aussi génériques que possible pour les appliquer aux deux configurations.

Ce sont les étapes:

  1. Mettez le site hors ligne (n'oubliez pas que nous l'avons fait dans IIS. Par conséquent, si vous utilisez Apache, vous devrez utiliser la configuration d'Apache pour le faire):

    a) Notez comment les redirections 404 sont effectuées dans la configuration Web. Vous en aurez besoin plus tard. Modifiez les redirections 404 pour pointer vers la racine du site, par exemple. http://example.com

    b) Modifiez la configuration du serveur Web pour qu'elle pointe vers une page de stockage dans une structure de dossiers distincte de celle contenant le site WordPress. Nous mettons en place un seul fichier, index.html, avec le message "Site Web en maintenance".

Le site est maintenant arrêté et il est impossible d'y accéder ou de le mettre à jour. Il est effectivement statique pendant la mise à niveau - sauf si vous avez une autre configuration Web pointant vers le dossier WordPress. Si vous le faites, déconnectez-le de la même manière.

  1. Créez une copie de sauvegarde des fichiers du dossier WordPress.

  2. Créez une sauvegarde de la base de données WordPress. (assurez-vous de savoir comment restaurer une base de données si vous en avez besoin - nous utilisons heidisql pour la sauvegarde et la restauration).

  3. Copiez tous les fichiers du site sur un serveur Web local et configurez-le pour qu'il corresponde exactement au même domaine que votre site actif. Sur un ordinateur Windows, il est nécessaire d’éditer c:\windows\system32\drivers\etc\hosts pour ajouter 127.0.0.1 example.com afin de s’assurer que le navigateur est résolu en ordinateur local.

notez que même si vous ne mettez initialement à niveau que les fichiers localement, vous allez mettre à niveau la base de données active. Toutes les sauvegardes/restaurations de bases de données font référence à la base de données active, c'est-à-dire celle utilisée par le site actif.

  1. Faites une liste de tous lesactifsplugins.

  2. Désactiver tous les plugins

  3. Mettre à jour tous les plugins

  4. Mettez à niveau WordPress en suivant les étapes proposées, y compris la mise à niveau de la base de données.

  5. Avant d'activer les plugins, voyez s'il en faut d'autres (cela peut arriver, même si vous avez déjà effectué une série de mises à jour).

  6. Activez chaque plug-in qui nécessite l'activation 1 par 1. Si vous êtes invité à mettre à niveau le plug-in à ce stade, mettez-le à niveau.

  7. Testez le site à l'avant et à l'arrière. Si vous rencontrez des erreurs irrécupérables, restaurez les fichiers du site de sauvegarde sur votre serveur local et restaurez votre base de données de sauvegarde en direct, puis recommencez à partir de l'étape 6. Si vous rencontrez de nouveau les mêmes problèmes, vous devrez peut-être effectuer des recherches pour les résoudre. avant d'aller plus loin. Si vous devez restaurer votre ancien site actif entre-temps, restaurez la base de données, puis suivez les étapes 14 et 15 ci-dessous.

  8. Après avoir testé avec succès le site sur votre ordinateur local, copiez les fichiers de votre installation locale dans votre dossier Live WordPress.

  9. Sur votre ordinateur local, commentez "#" l’entrée faite dans votre fichier hosts dans 4 ci-dessus.

  10. Inverser ce qui a été fait en 1) ci-dessus en:

    a) Modification de la configuration du serveur Web pour pointer vers le site WordPress actif.

    b) Restauration de la redirection 404 sur ce qu'elle était avant de la modifier

  11. Testez votre site sur le domaine en direct.

0
dewd