Come gestite l'allineamento di database dopo l'upgrade di un sito?

jabba

Ultimamente sto lavorando molto in ambito migrazione/upgrade di siti complessi da Joomla3 a Joomla4/5. Lo trovo parecchio divertente perché ogni sito è una storia a sé e c'è sempre qualcosa da imparare.
Più o meno riesco ad automatizzare e gestire il tutto, tranne una cosa sola: l'allineamento dei database post aggiornamento.

L'iter lavorativo solitamente è questo:

Devo fare l'upgrade di un sito live molto attivo (5/10 articoli nuovi al giorno). Non posso metterlo offline durante l'upgrade quindi mi faccio una copia in locale e lavoro su quella.
Il lavoro può richiedere settimane quindi a livello di contenuti rimango spesso indietro e non posso chiedere al cliente di aggiornare due siti in contemporanea (sarebbe bellissimo ma mi insultano tutti quando lo chiedo )
Una volta che sul server di test è tutto pronto ho tre strade: 1) mettere a mano tutti i contenuti vecchi nel nuovo e poi uppare il sito aggiornato, 2) ripercorrere passo passo quello che ho fatto nel server di test anche sul server di produzione (ma richiede almeno una giornata di offline se tutto va bene), 3) rifare una copia aggiornata, rifare l'upgrade della copia aggiornata e mettere su la copia aggiornata del sito appena copiata (che però non è testata a pieno perché giocoforza è una nuova copia con un nuovo aggiornamento.

Non sono mai riuscito a fare il giochino di copiare i contenuti tra i vari database (anche della stessa versione di Joomla) perché le variabili in gioco sono tantissime (soprattutto se cambiano anche categorie, tag ecc ..)

Quindi, morale della favola: voi come vi comportate in questi casi? Avete un iter preferito? Oppure qualcuno conosce un tool magico a me sconosciuto che si occupa di riallineare database?

Grazie!

pietro strada

articoli nativi joomla ?

jabba

@pstrada ha detto in Come gestite l'allineamento di database dopo l'upgrade di un sito?:

articoli nativi joomla ?

Si,parlo principalmente di articoli nativi. Il resto inevitabilmente devi farti qualcosa di semi custom. Però per gli articoli mi piacerebbe trovare una "procedura standard"

pietro strada

su un sito di una piccola testata ho usato j2xml, che sicuramente conosci, però si trattava di prendere gli articoli nuovi, non facevano modifiche sul vecchio quindi è stato relativamente semplice

jabba

Sisi conosco, il problema è che spesso devo prendere anche articoli vecchi che vengono modificati (contenuti e immagini) ... Mi servirebbe proprio una cosa che prenda tabella per tabella e se qualcosa è uguale passa oltre, se qualcosa è nuova allora aggiorna. Fantascienza?

elmir

ROCSVI esporto tutto e poi importo

Gioacchino

J2XML 5/10 minuti di fermo circa

jabba

Conosco bene entrambi (sia J2XML che CSVI) e li uso senza problemi per spostare contenuti da un sito ad un altro, qui però la situazione è un pelo differente. Stiamo parlando di capire cosa è stato aggiornato e cosa no e di fare l'upgrade mantenendo però la struttura (e soprattutto gli ID) inalterati.
Mi spiego meglio.

Se carico 100 articoli con CSVI gli ID di MySQL saranno 1,2,3...100.
Se li cancello e poi ricarico gli stessi 100 articoli MySQL (che gestisce in autonomia gli auto-increment delle tabelle) mi assegnerà gli ID 101,102,103... 200.

Se devo semplicemente importare tutto in un sito nuovo questa cosa non mi tange perchè sostanzialmente riparto da zero. Se ho un sito con customizzazioni, oppure con URL gestite all'interno degli articoli o dei campi aggiuntivi questa cosa potrebbe creare scompensi. Questo perché è buona pratica, quando si crea un URL di collegamento, farla non formato non-sef, quindi tipo:

/index.php?option=com_content&view=article&id=XXX

Dove XXX è l'ID dell'articolo. In questo modo lasciamo poi al router il gravoso compito di creare l'URL vera e propria.

Qui arriva il problema: se io faccio tabula rasa degli articoli nel sito aggiornato e non intervengo a livello di ID mi si sfasano tutti gli ID anche dei vecchi articoli.
Se faccio tabula rasa e gli aggiungo anche dei nuovi articoli poi devo fare la stessa cosa su categorie, tag, connessioni, menu item ecc...
Senza togliere il fatto che che non poso semplicemente "spostare" il database via SQL perché (in teoria) stiamo parlando di migrare un sito, quindi la sorgente sarebbe un Joomla3 e la destinazione un Joomla5, quindi con tabelle diverse tra di loro in molti piccoli particolari.

Quindi alla fine la domanda è sempre quella: qual'è l'iter migliore per non perdere i collegamenti interni del database di joomla? Migrare sia sorgente che destinazione e poi spostare le tabelle? Importare con plugin esterni e sperare che i collegamenti interni siano corretti? Usare un qualche tool di allineamento database? Se si? Esiste?

Mia risposta... boh

Luca Capponi

La butto li ma potrebbe essere una consa insensata:

duplicare il database del "nuovo sito"
dal sito live esportare le tabelle "xxx_content", "xxx:_category", "xxx_asset"
importare/sostituire queste tabelle sul database duplicato
modificare il configuration.php facendolo puntare sul nuovo database
verifica

jabba

Il problema è che il sito live è ancora un Joomla3 (non aggiornato diciamo), andrebbe aggiornato a Joomla5 anche il sito live temo

Gioacchino

@jabba
Che io sappia puoi rigenerare l'id nelle tue tabelle da phpmyadmin (prima di importare).
Il comando è: ALTER TABLE nometabella AUTOINCREMENT = 0;

jabba

sisi però se poi inserisci 100 entry MySQL ti assegna da 1 a 100. Anche se gli item da importare sono sempre 100 ma con ID diversi (1,5,7,10,11,12,20,...) perchè magari negli anni alcuni articoli sono stati cancellati. Bisognerebbe capire se è possibile importare lasciando inalterati gli ID e facendo ripartire l'autoincrement dal valore esatto del vecchio database

elmir

@jabba Non ho mai affrontato una casistica simile ma se tu quando esporti da ROCSVI, selezioni esporta ID mantenendo ID originale tra i campi

Poi nel template di importazione imposti Ovewrite existing data?

jabba

Questo è ottimo per gli articoli vecchi che sono stati aggiornati, bisogna vedere se quelli invece aggiunti (anche dicendogli di mantenere l'ID) vengono inseriti con l'ID originale o con l'ID generato dall'auto-increment di MySQL...
farò qualche prova, grazie

elmir

Penso proprio di sì ma non l'ho mai provato, ho solo spostato gli articoli da un sito all'altro.

AlanT

Sto seguendo questo thread perchè capisco benissimo il problema. Non ho una soluzione a portata di mano purtroppo e fare una migrazione di un sito che si aggiorna al ritmo di 5/10 articoli al giorno è una bella rogna. Quando ho dovuto fare una cosa simile ad uno dei miei siti ho lavorato per cercare di prepararmi tutti gli update possibili facendo vari test. Poi ho aspettato fine dicembre per avere un periodo in cui poter mettere offline il sito per 24/48 H e poter lavorare alla migrazione senza trovarmi con contenuti che si aggiornavano.

Tutto questo solo per dire che non ti invidio...

Luca Capponi

@jabba ha detto in Come gestite l'allineamento di database dopo l'upgrade di un sito?:

Il problema è che il sito live è ancora un Joomla3 (non aggiornato diciamo), andrebbe aggiornato a Joomla5 anche il sito live temo

Non ho mai controllato, ma i vari update da joomla 3 a 4 o 5, variano gli id di articoli e categorie o comunque la struttura delle tabelle?

AlanT

Ci sono alcune modifiche nella struttura delle tabelle, gli id restano uguali.
Ad esempio J4 ha introdotto i workflows che non c'erano in J3 quindi se uno copia il db non si ritroverà direttamente gli articoli se prima non crea anche un reference con la tabella #__workflow_associations.

Si può lanciare una query per correggere la tabella worflow ma come sempre sono cose che vanno fatte con molta cautela.

Esempio con prefisso tabella 'jos' e per gli articoli con un id compreso tra 30 e 60.
ATTENZIONE: non usate questo codice se non siete esperti. Fate sempre prima un backup.

INSERT INTO jos_workflow_associations (`item_id`, `stage_id`, `extension`)
SELECT `id`, 1, "com_content.article"
FROM jos_content
WHERE `id` > 29 AND `id` < 61;

simbus82

@jabba noi facciamo qualcosa di simile al tuo punto 2:

Copia in staging con sottodominio dell'intero sito in un momento x (quindi il "vecchio" resta live) dopo aver concordato lo stop delle modifiche di "features" (quindi resta attivo solo ad es. il copywriting).
Lavorazione dello staging con traccia minuziosa degli step per "l'upgrade" (che appunto può richiedere giornate)
Concordare un cutoff delle lavorazioni sul sito sorgente anche lato copy (la giornata prima della migrazione che avver) ed eventuali blocchi con relativi avvisi se ci sono registrazioni, login ecc. per evitare disallineamente lato tabelle db.
Di notte (eh sì, tocca farlo) copia di nuovo dello staging, applicazione a raffica delle modifiche già tracciate (roba di una settimana si fa in un paio di ore se ben documentate, considerando che buona parte è tutta roba statica ci si fanno gli zip da sovrascrivere)
Pubblicazione (giocando con gli scambi di sottodomini)

Più o meno così, in pratica non viene percepito nessun down, ma solo un "blocco in scrittura" per qualche ora. Dove si può, si mette anche in offline per sicurezza.

Di meglio con Joomla è difficile fare, se non mettere in piedi svn, query di migrazione, ecc.

jabba

@simbus82 grazie per il feedback. A occhio sembra la soluzione più adatta anche a me, anche se implica veramente tenere traccia di ogni singola virgola fatta nel sito di test per replicarla accuratamente (e non avere effettivamente tempo di testare.. perchè puoi fare tutti i testi di funzionamento che vuoi ma effettivamente li fai in una copia che poi risulta "vecchia" e non in quella "ufficiale"). Speravo in un tool magico di "allineamento" tabelle ma capisco possa essere complesso da implementare e anche solo da ideare.
Grazie