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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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