Esportazione delle impostazioni del pannello di amministrazione che vengono salvate nel database

Question

Durante la gestione di ambienti diversi per i siti Dev e Live, come passare le modifiche salvate solo sul database all'altro ambiente senza dover esportare il database ? Dì ad esempio ho disabilitato un'estensione, ha cambiato il contenuto di un blocco statico, ha creato una nuova pagina CMS statica, ha aggiunto un nuovo metodo di spedizione, regola fiscale o cosa hai. Come passare le piccole modifiche come questa al sito live senza dover esportare e importare l'intero database? Ovviamente ci sono informazioni sul sito live che non vorrei sovrascrivere.

Sono sicuro che qualcun altro deve averlo imbattuto in questo, specialmente quando si utilizza Controllo della versione . Abbiamo implementato Git, ma funziona solo per modifiche al livello di file. I file in entrambi gli ambienti possono essere esattamente uguali ma alcuni configurazione nel database possono cambiare in modo che si comportino diversamente.

Potrei tenere traccia di tutte le modifiche che faccio nel pannello di amministrazione, e quindi riproduconoli nell'altro ambiente, ma sembra molto impraticabile. Il numero di modifiche può essere abbastanza grande mentre modifichiamo continuamente il sito alla nostra soddisfazione. Inoltre, anche altri sviluppatori stanno lavorando, e abbiamo persino impostato un ambiente per gli sviluppatori in outsourcing e il supporto tecnico dei fornitori di estensioni magentali. Non riesco a tenere traccia di tutto ciò che fanno.

Ho visto tonnellate di post solo sui prodotti esportatori, quindi non è davvero il problema. Vorrei il contrario. Forse qualcuno ha effettuato un elenco di tutte le tabelle necessarie per clonare un sito magento senza prodotti e ordini e informazioni sui clienti. Solo tutto ciò che è configurabile nel pannello di amministrazione.

ha già fatto questo prima?

---

.

Aggiornamento: Per i lettori, mi sto segnando la risposta @ MbalParda sul manuale distribuendo i file come accettati fino a quando non viene visualizzato qualcos'altro che fa come richiesto. Io enformerò le regole per mantenere i registri sui cambiamenti nel pannello di amministrazione da tutti gli sviluppatori coinvolti in modo da avere una lista unificata alla fine. In realtà non è la risposta alla domanda, ma è il metodo che utilizzerò per risolverlo fino a quando non trovo un processo migliore.

Answer 1

core_config_data e core_resurces sono due buoni posti da avviare. cms_ * dovrebbe avere la maggior parte delle informazioni pertinenti su blocchi, cm e widget. Accanto a quei tavoli, la maggior parte delle tabelle Core_ * ha alcune informazioni pertinenti sul sito Web che stai eseguendo.

L'elenco è tutt'altro che completo.

Un'altra buona opzione è quella di mantenere una versione del database in Git e utilizzare uno strumento diffico per vedere cosa è cambiato tra le versioni, ma potrebbe avere alcuni problemi di sicurezza poiché le informazioni personali potrebbero essere nel repo.

Una buona pratica che uso spesso è avere un file di distribuzione manuale per salvare tutte le modifiche che abbiamo effettuato in un altro ambiente e una volta distribuito il codice, il passaggio successivo è quello di controllare il file di distribuzione manuale per vedere se qualcosa deve essere fatto. Questo è usato nei casi in cui non tutte le modifiche possono essere effettuate con gli aggiornamenti SQL / Dati, il normale modo Magento per creare SQL / Data Modifica.

Come nota, spostando i database tra ambienti non è sempre la scelta migliore poiché le modifiche potrebbero essere eseguite da un amministratore in diretta se non vengono replicate nel DB che si sta utilizzando nell'altro ambiente. .

Answer 2

Il database Magento non è il tuo normale database. È grande e complicato.
Le parti mobili di esso da un ambiente ad un altro non sono piccole attività.
Ecco perché di solito evito di cambiare le impostazioni di configurazione o aggiungere blocchi e / o pagine manualmente.
Ho lasciato che il cliente lo faccia solo sul server live.

Quello che devo fare mentre lo sviluppo lo faccio tramite gli script di aggiornamento.
In questo modo tutto è versionato e portatile.
So che è un tipo di trascinamento per scrivere uno script di aggiornamento solo per rimuovere la modalità di visualizzazione dell'elenco per le pagine dei prodotti, ma non ho trovato un modo migliore finora.

Ecco un piccolo esempio di come è possibile modificare un'impostazione di configurazione tramite lo script di aggiornamento.

Quanto segue consente la spedizione flatrata:

$path = 'carriers/tablerate/active';
$config = Mage::getModel('core/config_data')->load($path, 'path');
$config->setValue('1')->setPath($path);
$config->save();

.

Immagino che questo possa funzionare se lo si inserisce in uno script di aggiornamento all'interno di sql/[resource_name_here] ma per la manipolazione dei dati I utilizzo data/[resource_name_here].

Ecco un altro script che aggiunge un blocco statico.

$block = Mage::getModel('cms/block');
$block->setTitle('Some title here');
$block->setIdentifier('identifier_here');
$block->setContent('This is the content');
$block->setStatus(1);//enabled
$block->setStores(array(0)); //make it available in all stores
$block->save();

.

Puoi praticamente farlo per ogni entità che hai.

Answer 3

Ho trovato uno strumento adorabile per esportare e importare le impostazioni di configurazione https://github.com/zookal/Harrisstreet-Impex

Questo fa un sacco di ciò che voi ragazzi e io stia cercando, penso.