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

Question

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

Answer 1

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

С функциями:

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Тогда вы готовы:

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

Вы можете тогда:

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

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

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

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

Answer 4

Основываясь на опыте работы с рядом приложений, CMS и других, это общая схема:

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

Answer 5

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

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

http://code.google.com/p/sqloo/source/browse/ <- примеры

Answer 6

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

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

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