Jak samodzielnie zaktualizować PHP+MySQL CMS?

• przechowuj kod w oddzielnej lokalizacji od plików konfiguracyjnych i innych zmiennych (przesłanych obrazów, plików pamięci podręcznej itp.)
• trzymaj Moduły oddzielnie od głównego kodu.
• Upewnij się, że Twój kod ma uprawnienia do zmiany systemu plików (użyj na przykład SuPHP).

Jeśli to zrobisz, najprościej będzie całkowicie pobrać nową wersję (bez poprawek przyrostowych) i rozpakować ją do katalogu sąsiadującego z tym, który zawiera bieżącą wersję. Ponieważ nie będzie zmiennych plików w katalogu kodu, możesz po prostu usunąć lub zmienić nazwę starego i zmienić nazwę nowego, aby go zastąpić.

Możesz zachować numer wersji w stałej globalnej w kodzie.

Jeśli chodzi o MySQL, nie ma innego sposobu niż wykonanie skryptu aktualizacji dla każdej wersji, która zmienia układ DB. Nawet automatyczne rozwiązania do zmiany definicji tabeli nie mogą wiedzieć, jak zaktualizować istniejące dane.

Istnieje Biblioteka SQL o nazwie sqloo (którą stworzyłem), która próbuje rozwiązać ten problem. Jest to trochę trudne, ale podstawową ideą jest to, że konfigurujesz schemat SQL w kodzie PHP, a następnie sqloo zmienia bieżący schemat bazy danych, aby dopasować kod. Pozwala to na zmianę schematu SQL i dołączonego kodu PHP razem i w znacznie mniejszym kawałki.

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

Http://code.google.com/p/sqloo/source/browse/#svn/trunk/example

Masz do czynienia z dwoma scenariuszami:

1. serwer WWW może zapisywać pliki.
2. serwer WWW nie może zapisywać plików.

To tylko określa, czy będziesz dekompresować plik ZIP lub używać FTP do aktualizacji plików. W przypadku ether pierwszym krokiem jest zrobienie zrzutu bazy danych i kopii zapasowej istniejących plików, aby użytkownik mógł cofnąć się, jeśli coś pójdzie okropnie źle. Jak powiedzieli inni, ważne jest, aby zachować wszystko, co użytkownik prawdopodobnie dostosuj poza zakresem aktualizacji. Wordpress robi to ładnie. Jeśli użytkownik dokonał zmian w kodzie logiki rdzenia, prawdopodobnie jest wystarczająco inteligentny, aby rozwiązać wszelkie konflikty scalania na własną rękę (i wystarczająco inteligentny, aby wiedzieć, że aktualizacja jednym kliknięciem prawdopodobnie straci swoje modyfikacje).

Twoim drugim krokiem jest upewnienie się, że skrypt nie umrze, jeśli przeglądarka jest zamknięta. Jest to proces, którego naprawdę nie należy przerywać. Można to osiągnąć poprzez ignore_user_abort(true);, lub inne znaczy. Lub, jeśli chcesz, pozwól użytkownikowi zaznaczyć pole z napisem "Kontynuuj, nawet jeśli zostanę rozłączony". Zakładam, że będziesz zajmował się wewnętrznymi błędami.

Teraz, w zależności od uprawnień, możesz:

• skompresuj pliki do aktualizacji do katalogu system / tmp
• skompresuj pliki do zaktualizowania do pliku tymczasowego w katalogu domowym

Wtedy jesteś gotowy do:

• Pobierz i zdekompresuj aktualizację en situ, lub na miejscu.
• Pobierz i zdekompresuj aktualizację do katalogu / tmp systemu i użyj FTP, aby zaktualizować pliki w katalogu głównym www

Możesz wtedy:

• Zastosuj wszelkie zmiany SQL w razie potrzeby
• zapytaj użytkownika, czy wszystko poszło dobrze
• Roll back if things went bad
• Wyczyść katalog tymczasowy w katalogu system / tmp lub dowolne pliki tymczasowe w katalogu głównym / domowym użytkownika.

Najważniejszym aspektem jest upewnienie się, że możesz cofnąć zmienia się, jeśli coś pójdzie źle. Inną rzeczą, którą należy zapewnić, jest to, że jeśli używasz /tmp, upewnij się, że sprawdzasz uprawnienia swojego miejsca postoju. Powinno wystarczyć.

Bazując na doświadczeniach z wieloma aplikacjami, CMS i innymi, jest to wspólny wzór:

Ulepszenia są zazwyczaj jednokierunkowe. Możliwe jest wykonanie migawki pełnego stanu systemu w celu przywrócenia po awarii, ale przywrócenie zwykle wiąże się z utratą danych/zawartości/dzienników dodanych do systemu od aktualizacji. Wykonywanie przyrostowego wycofywania danych może zagrozić poprawnemu przekonwertowaniu danych (np. zmiana tabeli w bazie danych, konwersja treści, klucz obcy ograniczenia, tworzenie indeksów itp.) Jest to szczególnie ważne, jeśli wprowadziłeś modyfikacje, których Skrypty wycofywania nie mogły wyjaśnić.
• pliki aktualizacji są pakowane za pomocą pewnych środków uwierzytelniania/weryfikacji, takich jak skróty md5 lub sha1 i / lub podpis cyfrowy, aby upewnić się, że pochodzą z zaufanego źródła i nie zostały naruszone. Jest to szczególnie ważne w przypadku zautomatyzowanych procesów aktualizacji. Załóżmy, że haker wykorzystał lukę i kazał ją uaktualnić z łotra źródło.
• aplikacja powinna być w trybie offline podczas aktualizacji.
• aplikacja powinna wykonać samokontrolę po aktualizacji.

Zgadzam się z Bart van Heukelom 's odpowiedź, to najbardziej zwykły sposób na to.

Jedyną inną opcją byłoby przekształcenie CMS w kilka zdalnych usług internetowych/skryptów i zewnętrznych plików CSS / JS, które hostujesz tylko w jednej lokalizacji.

Wtedy wszyscy korzystający z twojego CMS połączyłby się z Twoim centralnym "serwerem CMS" i wszystko, co byłoby na ich (wywołującym) serwerze, to kilka skryptów do wywoływania Twoich usług internetowych / skryptów, które wykonują wszystkie przetwarzanie i wyjście. Jeśli idąc tą trasą, musisz zidentyfikować / uwierzytelnić każde żądanie, aby zwrócić odpowiednie dane dla danego użytkownika CMS.