Подскажите решение для реализации рабочей копии сайта на wordpress с возможностью залития изменений на основной сайт?

Рейтинг: 0Ответов: 1Опубликовано: 29.05.2023

Подскажите в какую сторону посмотреть, хочется иметь полную работоспопобную копию сайта на WP для разработки. Если просто сделаю копию файлов и БД, то сталкиваешься с проблемой двойной работы, сначала сделал на dev потом сделал на основном, тратишь в 2 раза больше времени.

Возможно существуют какие-то автоматические решения которые можно было бы внедрить/применить?

В использовании вижу это так: Сделал работу на dev (предположим работа была не только по шаблону php/html), а так же вносился какой-то контент, после проверки и подтверждения успешной работы изменения заливаются на основной сайт включая файлы и обновленную базу данных.

Ответы

▲ 1

Для распределенной разработки используют GitHub и GitHub Action. Код темы и/или плагинов должен находиться в репозитории для отслеживания версий, командной работы и т.п. Разработка новой фичи ведется в отдельной ветке. При смерживании этой ветки в мастер выполняется код на GitHub Actions, который заливает изменения на продакшн сайт. Это достигается наличием в репозитории примерно такого файла .github/workflows/prod.yml:

name: Deploy to Production

on:
  push:
    branches:
      - master

jobs:
  release:
    name: Deploy to Production

    runs-on: ubuntu-latest

    strategy:
      matrix:
        os: [ ubuntu-latest ]
        php-version: [ '7.4' ]

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Get Composer cache directory
        id: composer-cache
        run: echo "::set-output name=dir::$(composer config cache-files-dir)"

      - name: Set up Composer caching
        uses: actions/cache@v3
        env:
          cache-name: cache-composer-dependencies
        with:
          path: ${{ steps.composer-cache.outputs.dir }}
          key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
          restore-keys: |
            ${{ runner.os }}-composer-

      - name: Install PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}
        env:
          COMPOSER_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Install dependencies in prod version
        run: |
          composer config github-oauth.github.com ${{ secrets.GITHUB_TOKEN }}
          composer install --no-dev
        env:
          COMPOSER_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Build JS ans CSS
        run: |
          npm install
          npm run build
          npm run build-css

      - name: Deploy the code to the production server
        uses: burnett01/rsync-deployments@5.2
        with:
          switches: -cvzr --delete --exclude-from=.distignore
          path: ${{ env.GITHUB_WORKSPACE }}
          remote_path: ${{ secrets.REMOTE_PATH }}
          remote_host: ${{ secrets.REMOTE_HOST }}
          remote_user: ${{ secrets.REMOTE_USER }}
          remote_key: ${{ secrets.REMOTE_KEY }}

Secrets должны быть установлены в GitHub и содержать, соответственно, путь к папке WordPress на сервере, имя/IP хоста, имя пользователя, под которым будут записываться файлы и его ключ.

Таким образом, файлы при разработке идут снизу вверх (от локальной машины на продакшен сервер).

База, напротив, должна идти сверху вниз - все изменения вносятся на сервере, а разработчики скачивают эти изменения для обновления на локальных машинах. Кроме того, сверху вниз скачиваются файлы uploads.

Для синхронизации локального сайта с сервером может быть использован следующий файл sync-site.

#!/bin/bash

#set -x

if [ "$OSTYPE" == "linux-gnu" ] && grep -q Microsoft /proc/version; then
  WP_PATH=$(wp config path)
else
  WP_PATH=$(wp config path 2>/dev/null)
fi

if [[ ! $WP_PATH ]]; then
  echo "This is not a WordPress install"
  exit 1
fi

WP_PATH="$(dirname "$WP_PATH")"

PARAMETERS_FILE=""$WP_PATH/sync.params""

if [[ ! -f "$PARAMETERS_FILE" ]]; then
  echo "Parameters file $PARAMETERS_FILE does not exist"
  exit 1
fi

TYPE="$1"
if [[ -z $TYPE ]]; then
  TYPE="db"
fi

if [[ "db" != "$TYPE" && "plugins" != "$TYPE" && "uploads" != "$TYPE" && "all" != "$TYPE" ]]; then
  echo "Argument can be 'db', 'plugins', 'uploads' or 'all' only"
  exit 1
fi

# shellcheck disable=SC1090
if ! source "$PARAMETERS_FILE";
then
  exit 1
fi

if [[ "" == "$REMOTE_USER" ]]; then
  REMOTE_USER=$USER
fi

SECONDS=0

if [[ "db" == "$TYPE" || "all" == "$TYPE" ]]; then
  echo -e "\nSyncing database..."
  ssh -l "$REMOTE_USER" -i "$KEY_FILE" "$REMOTE_DOMAIN" "cd $REMOTE_PATH > /dev/null&&/usr/local/bin/wp db export /tmp/wp.sql > /dev/null"
  scp -i "$KEY_FILE" "$REMOTE_USER"@"$REMOTE_DOMAIN":/tmp/wp.sql wp.sql
  ssh -l "$REMOTE_USER" -i "$KEY_FILE" "$REMOTE_DOMAIN" "rm /tmp/wp.sql"
  echo -e "Done."

  echo -e "\nImporting database..."
  wp --quiet db import wp.sql
  echo -e "Done."

  rm wp.sql

  echo -e "\nReplacing domain in database..."
  wp search-replace --url="$REMOTE_URL" "$REMOTE_URL" "$LOCAL_URL" --recurse-objects --report-changed-only --precise --skip-columns=guid --skip-tables=wp_users --skip-plugins --skip-themes --allow-root
  wp cache flush
  echo -e "Done."
fi

if [[ "plugins" == "$TYPE" || "all" == "$TYPE" ]]; then
  if [ "$OSTYPE" == "linux-gnu" ] && grep -q Microsoft /proc/version; then
    # Fix paths if we are in Windows Subsystem Linux (WSL)
    LOCAL_PATH=$(wslpath "$LOCAL_PATH")
  fi

  echo -e "\nSyncing plugins..."
  IFS=' '
  read -ra PLUGINS <<< "$SYNC_PLUGINS"
  for PLUGIN in "${PLUGINS[@]}"; do
    rsync -ase "ssh -l $REMOTE_USER -i $KEY_FILE" "$REMOTE_USER"@"$REMOTE_DOMAIN":"$REMOTE_PATH"/wp-content/plugins/"$PLUGIN"/* "$LOCAL_PATH"/wp-content/plugins/"$PLUGIN"
  done
  echo -e "Done."
fi

if [[ "uploads" == "$TYPE" || "all" == "$TYPE" ]]; then
  if [ "$OSTYPE" == "linux-gnu" ] && grep -q Microsoft /proc/version; then
    # Fix paths if we are in Windows Subsystem Linux (WSL)
    LOCAL_PATH=$(wslpath "$LOCAL_PATH")
  fi

  echo -e "\nSyncing uploads..."
  rsync -ase "ssh -l $REMOTE_USER -i $KEY_FILE" --exclude "*backwpup*/*" "$REMOTE_USER"@"$REMOTE_DOMAIN":"$REMOTE_PATH"/wp-content/uploads/* "$LOCAL_PATH"/wp-content/uploads
  echo -e "Done."
fi

echo -e "\nDoing after sync commands..."
$AFTER_SYNC_COMMANDS
echo -e "Done."

echo -e "\nFinished. Time elapsed: $SECONDS seconds."

Ну и для вызова его под Windows sync-site.bat.

@echo off
call bash sync-site %*

Файлы надо поместить где-то в PATH. В корневой папке локального сайта надо добавить файл параметров sync.params.

REMOTE_DOMAIN="xxx.xxx.xxx.xxx"
KEY_FILE="~/.ssh/user-key.rsa"
REMOTE_PATH="/var/www/site-dir/"
LOCAL_PATH="/mnt/d/site-dir"
REMOTE_URL="https://my-site.com"
LOCAL_URL="https://my-site.test"
AFTER_SYNC_COMMANDS="wp plugin deactivate backwpup cloudflare ewww-image-optimizer wordfence wp-super-cache && wp option delete otgs_wpml_tm_ate_cloned_site_lock"

sync-site db обновит базу на локалке sync-site uploads обновит папку uploads sync-site plugins обновит плагины (это нужно для случаев, когда платные плагины имеют привязку только к серверу) sync-site all обновит все вышеперечисленное.