Come autoaggiornare PHP + MySQL CMS?

Question

Sto scrivendo un CMS su PHP + MySQL. Voglio che sia auto aggiornabile (fai un clic nel pannello di amministrazione). Quali sono le migliori pratiche?
Come confrontare la versione corrente di cms e una versione dell'aggiornamento (applicazione stessa e database). Dovrebbe solo scaricare archivio zip, upzip e sovrascrivere i file? (ma cosa fare con i file che non vengono più utilizzati). Come verificare se un aggiornamento è stato scaricato correttamente? Inoltre supporta i moduli e voglio che questi moduli siano scaricabili dal pannello di amministrazione di cms.
E come devo aggiornare le tabelle MySQL?

Answer 1

Una soluzione leggermente più sperimentale potrebbe essere quella di utilizzare qualcosa come la libreria phpsvnclient.

con le caratteristiche:

• elencare tutti i file in una data directory repository SVN
• recuperare una data di revisione di un file
• Recupera il registro delle modifiche apportate in un repository o in un determinato file tra due revisioni
• Prendi il repository ultima revisione

In questo modo si può vedere se ci sono nuovi file, file rimossi o file aggiornati e solo quelli nella tua applicazione locale.

Ricordo che sarà un po 'più difficile da implementare, ma il vantaggio sarebbe probabilmente che è più facile e più veloce aggiungere aggiornamenti al CMS.

Answer 2

• mantenere il codice in un luogo separato dal file di configurazione e comunque variabili (le immagini caricate, i file di cache, ecc)
• Tenere i moduli separati dal codice principale pure.
• Assicurati che il tuo codice disponga delle autorizzazioni per il file system per cambiarsi (usa SuPHP per esempio).

Se si esegue questa procedura, è più semplice scaricare completamente la nuova versione (senza patch incrementali) e decomprimerla in una directory adiacente a quella contenente la versione corrente. Perché non ci saranno file variabili all'interno della directory del codice, è sufficiente rimuovere o rinominare quello vecchio e rinominare quello nuovo per sostituirlo.

È possibile mantenere il numero di versione in una costante globale nel codice.

Per quanto riguarda MySQL, non c'è altro modo che creare uno script di aggiornamento per ogni versione che modifica il layout del DB. Anche le soluzioni automatiche per modificare la definizione della tabella non possono sapere come aggiornare i dati esistenti.

Answer 3

Sono d'accordo con La risposta di Bart van Heukelom, è il modo più usuale di farlo.

L'unica altra opzione sarebbe quella di trasformare il tuo CMS in una serie di script/servizi Web remoti e file CSS/JS esterni ospitati solo in una posizione.

Quindi tutti quelli che utilizzano il CMS si collegano al "server CMS" centrale e tutto ciò che sarebbe sul loro server (di chiamata) è un insieme di script per chiamare i servizi Web/script che eseguono tutte le elaborazioni e l'output. Se si è passati a questa rotta, è necessario identificare/autenticare ogni richiesta in modo da restituire i dati corrispondenti per l'utente CMS specificato.

Answer 4

C'è una libreria SQL chiamata SQLOO (che ho creato) che tenta di risolvere questo problema. È ancora un po 'approssimativo, ma l'idea di base è quella di impostare lo schema SQL nel codice PHP e poi SQLOO cambia lo schema del database corrente in modo che corrisponda al codice. Ciò consente che lo schema SQL e il codice PHP allegato vengano modificati insieme e in blocchi molto più piccoli.

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

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

Answer 5

Si hanno due scenari da affrontare:

1. Il server web può scrivere i file.
2. Il server Web non può scrivere sui file.

Questo semplicemente impone se si sta decomprimendo un file ZIP o utilizzando FTP per aggiornare i file. In caso di etere, il primo passo consiste nel prendere una copia del database e un backup dei file esistenti, in modo che l'utente possa eseguire il rollback se qualcosa va orribilmente sbagliato. Come altri hanno già detto, è importante mantenere tutto ciò che l'utente probabilmente personalizzerà al di fuori dell'ambito dell'aggiornamento. Wordpress lo fa bene. Se un utente ha apportato modifiche al codice logico di base, è probabile che sia abbastanza intelligente da risolvere autonomamente eventuali conflitti di merge (e abbastanza intelligente da sapere che un aggiornamento con un solo clic sta probabilmente per perdere le proprie modifiche).

Il secondo passaggio consiste nell'assicurarsi che lo script non muoia se il browser è chiuso. Questo è un processo che davvero non dovrebbe essere interrotto. È possibile farlo tramite ignore_user_abort(true); o in altri modi. Oppure, se lo desideri, consenti all'utente di spuntare una casella che dice "Continua anche se mi disconnetto". Suppongo che tu gestirai gli errori internamente.

Ora, a seconda delle autorizzazioni, è possibile:

• comprimere i file da aggiornare nella directory di sistema/tmp
• comprimere i file da aggiornare in un file temporaneo nella directory home

allora siete pronti a:

• scaricare e decomprimere l'aggiornamento en situ o in posizione.
• Scaricare e decomprimere l'aggiornamento alla directory/tmp del sistema e utilizzare FTP per aggiornare i file nella directory principale web

È possibile:

• applicare le eventuali modifiche SQL come necessario
• chiedere all'utente se tutto è andato bene
• rollback se le cose fossero andate male
• pulire la directory temporanea nella directory di sistema/tmp, o qualsiasi fil messa in scena es nella directory radice/home dell'utente dell'utente.

L'aspetto più importante è assicurarsi di poter ripristinare le modifiche in caso di problemi. L'altra cosa da assicurare è che se si utilizza/tmp, assicurarsi di controllare le autorizzazioni dell'area di staging. 0600 dovrebbe fare bene.

Dai un'occhiata a come Wordpress e gli altri lo fanno. Se la tua scelta di licenze e le loro sono d'accordo, potresti persino essere in grado di riutilizzare parte di quel codice.

Buona fortuna per il tuo progetto.

Answer 6

Sulla base dell'esperienza con una serie di applicazioni, CMS e in caso contrario, si tratta di un modello comune:

• Gli aggiornamenti sono generalmente a senso unico. È possibile scattare un'istantanea dello stato di sistema completo per un ripristino in caso di errore, ma il ripristino di solito comporta la perdita di qualsiasi dato/contenuto/log aggiunti al sistema dall'aggiornamento. L'esecuzione di un rollback incrementale può mettere a rischio i dati se qualcosa non è stato convertito correttamente (ad es. Modifiche alla tabella del database, conversioni del contenuto, vincoli di chiavi esterne, creazione dell'indice, ecc.) Questo è particolarmente vero se hai fatto personalizzazioni che gli script di rollback non potevano forse conto.
• I file di aggiornamento sono impacchettati con alcuni metodi di autenticazione/verifica, come gli hash md5 o sha1 e/o la firma digitale per assicurarsi che provengano da una fonte attendibile e non siano stati manomessi. Questo è particolarmente importante per i processi di aggiornamento automatico. Supponiamo che un hacker abbia sfruttato una vulnerabilità e gli abbia detto di aggiornarsi da una fonte errata.
• L'applicazione deve essere in modalità offline durante l'aggiornamento.
• L'applicazione deve eseguire un autocontrollo dopo un aggiornamento.