Как самостоятельно обновить PHP + MySQL CMS?

Question

Я пишу CMS на PHP + MySQL. Я хочу, чтобы оно самообновлялось (один клик в админке). Каковы лучшие практики?
Как сравнить текущую версию cms и версию обновления (само приложение и база данных). Стоит ли просто скачать zip-архив, разархивировать его и перезаписать файлы? (но что делать с файлами, которые больше не используются). Как проверить, правильно ли загружено обновление? Также он поддерживает модули, и я хочу, чтобы эти модули можно было загрузить из админ-панели cms.
И как мне обновить таблицы MySQL?

Answer 1

• Храните ваш код отдельно от конфигурационных и других переменных файлов (загруженные изображения, файлы кэша и т. Д.)
• Держите модули отдельно от основного кода.
• Убедитесь, что у вашего кода есть разрешения на изменение файловой системы (например, используйте SuPHP).

Если вы сделаете это, проще всего будет полностью загрузить новую версию (без дополнительных исправлений) и разархивировать ее в каталог рядом с каталогом, содержащим текущую версию. Поскольку в каталоге кода не будет переменных файлов, вы можете просто удалить или переименовать старый и переименовать новый, чтобы заменить его.

Вы можете сохранить номер версии в глобальной константе в коде.

Что касается MySQL, нет другого способа, кроме создания сценария обновления для каждой версии, которая меняет структуру БД. Даже автоматические решения по изменению определения таблицы не могут знать, как обновить существующие данные.

Answer 2

Несколько более экспериментальным решением может быть использование чего-то вроде библиотеки phpsvnclient .

С функциями:

• Список всех файлов в данном каталоге хранилища SVN
• Получить заданную ревизию файла
• Получить журнал изменений, внесенных в хранилище или в данный файл между двумя ревизиями
• Получить последнюю версию репозитория

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

Я считаю, что это будет немного сложнее реализовать, но выгода, вероятно, будет заключаться в том, что проще и быстрее добавлять обновления в вашу CMS.

Answer 3

Основываясь на опыте работы с несколькими приложениями, CMS и т. Д., Это общая схема:

• Обновления, как правило, односторонние. Можно сделать снимок полного состояния системы для восстановления после сбоя, но восстановление обычно влечет за собой потерю любых данных / содержимого / журналов, добавленных в систему после обновления. Инкрементный откат может подвергнуть риску данные, если что-то не было правильно конвертировано (например, изменения таблицы базы данных, преобразования контента, ограничения внешнего ключа, создание индекса и т. Д.) Это особенно верно, если вы сделали настройки, которые скрипты отката не могли возможно, приходится.
• Файлы обновления упакованы с некоторыми средствами аутентификации / проверки, такими как хеши md5 или sha1 и / или цифровая подпись, чтобы гарантировать, что они поступили из надежного источника и не были подделаны. Это особенно важно для автоматизированных процессов обновления. Предположим, что хакер воспользовался уязвимостью и сказал ему выполнить обновление из мошеннического источника.
• Приложение должно быть в автономном режиме во время обновления.
• Приложение должно выполнить самопроверку после обновления.

Answer 4

У вас есть два сценария:

1. Веб-сервер может записывать в файлы.
2. Веб-сервер не может записывать в файлы.

Это просто определяет, будете ли вы распаковывать ZIP-файл или использовать FTP для обновления файлов.В случае эфира ваш первый шаг - сделать дамп базы данных и сделать резервную копию существующих файлов, чтобы пользователь мог откатиться, если что-то пойдет не так.Как уже говорили другие, важно сохранить все, что пользователь, скорее всего, настроит за рамками обновления.Wordpress делает это красиво.Если пользователь внес изменения в основной логический код, он, вероятно, достаточно умен, чтобы самостоятельно разрешать любые конфликты слияния (и достаточно умен, чтобы знать, что обновление одним щелчком, вероятно, потеряет свои модификации).

Ваш второй шаг - убедиться, что ваш скрипт не умирает, если браузер закрыт.Это процесс, который действительно не должен прерываться.Вы можете сделать это с помощью ignore_user_abort(true); или каким-либо другим способом.Или, если хотите, разрешите пользователю установить флажок «Продолжайте, даже если я отключусь».Я предполагаю, что вы будете обрабатывать ошибки внутренне.

Теперь, в зависимости от разрешений, вы можете:

• Сжать файлы для обновления в каталог system / tmp
• Сжатие файлов для обновления во временный файл в домашнем каталоге

Затем вы готовы:

• Скачать и распаковать обновление en situ или на месте.
• Загрузите и распакуйте обновление в системный каталог / tmp и используйте FTP для обновления файлов в веб-корне

Затем вы можете:

• Примените все необходимые изменения SQL
• Спросите пользователя, все ли прошло нормально
• Откатитесь, если дела пошли плохо
• Очистите временный каталог в каталоге system / tmp илилюбые промежуточные файлы в корневом / домашнем каталоге пользователя.

Самый важный аспект - убедиться, что вы можете откатить изменения, если что-то пошло не так.Еще одна вещь, которую нужно гарантировать, это то, что если вы используете / tmp, обязательно проверьте разрешения вашей промежуточной области.0600 должно быть хорошо.

Посмотрите, как это делают Wordpress и другие.Если ваш выбор лицензий и их согласен, вы можете даже использовать этот код повторно.

Удачи в вашем проекте.

Answer 5

Существует библиотека SQL под названием SQLOO (которую я создал), которая пытается решить эту проблему. Это все еще немного грубо, но основная идея состоит в том, что вы настраиваете схему SQL в коде PHP, а затем SQLOO изменяет текущую схему базы данных в соответствии с кодом. Это позволяет изменять схему SQL и присоединенный код PHP вместе и гораздо меньшими частями.

http://code.google.com/p/sqloo/

http://code.google.com/p/sqloo/source/browse/#svn/trunk/example <- примеры </p>

Answer 6

Я согласен с ответом Барт ван Хейкелом , это самый обычный способ сделать это.

Единственным другим вариантом будет превращение вашей CMS в набор удаленных веб-служб / сценариев и внешних файлов CSS / JS, которые вы размещаете только в одном месте.

Тогда каждый, кто использует вашу CMS, подключится к вашему центральному «серверу CMS», и все, что будет на их (вызывающем) сервере, - это набор сценариев для вызова ваших веб-служб / сценариев, которые выполняют всю обработку и вывод. Если вы пошли по этому маршруту, вам нужно будет идентифицировать / аутентифицировать каждый запрос, чтобы вы вернули соответствующие данные для данного пользователя CMS.