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

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

С функциями:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете:

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

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

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

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

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

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

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

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

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