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

Ответ 1

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

С функциями:

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

http://code.google.com/p/sqloo/source/browse/#svn/trunk/example < - examples

Ответ 4

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

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

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

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

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

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

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

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

Вы можете:

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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