Как обновить PHP + MySQL CMS?

Question

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

Answer 1

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

С особенностями:

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

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

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

Answer 2

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

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

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

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

Answer 3

Я согласен с Ответ Bart van Heukelom, это самый обычный способ сделать это.

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Теперь, в зависимости от прав доступа, вы можете:

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

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

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

Вы можете затем:

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

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

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

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

Answer 6

На основе опыта ряда приложений, CMS и в противном случае, это общая картина:

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