Share
Quando si tratta di lavorare con progetti basati su WordPress, probabilmente uno degli aspetti più frustranti o noiosi della distribuzione è quello di far sì che i database degli ambienti siano sincronizzati l'uno con l'altro.
Certo, c'è qualcosa da dire per usare i dati di test in fase di sviluppo, i dati degli utenti nella messa in scena e dati reali in produzione, ma non esiste un proiettile d'argento, giusto? Ciò significa che qualche volta i dati dei test funzioneranno; altre volte, non lo farà.
Ad esempio, supponiamo che tu erediti un progetto per il quale devi aprire un database e iniziare a lavorare con i dati esistenti. Oppure diciamo che devi migrare un intero sito o applicazione da un server all'altro.
In casi come quello, i dati dei test non aiutano molto. Invece, hai bisogno di uno strumento per questo. E certo, l'importatore di WordPress è un valido strumento per le migrazioni di base e l'esportazione e l'importazione SQL è ok se sei a tuo agio con i front-end del database e lavorando con SQL stesso.
Ma che dire di quelli che sono da qualche parte nel mezzo?
La verità è che, quando si tratta di lavorare con le migrazioni di database di WordPress, è una borsa mista perché molti di noi hanno livelli di abilità che variano a seconda della parte dello stack con cui lavoriamo maggiormente.
Con ciò intendo:
Questo non vuol dire che non ci siano sviluppatori di stack completi. Ovviamente, ci sono; tuttavia, non tutti sono in quella posizione.
Quindi, quando si tratta di lavorare sulla migrazione dei database di WordPress, alcuni hanno un tempo molto più difficile di altri. In alternativa, nonostante il livello di comfort di SQL, alcuni potrebbero cercare uno strumento semplicemente per facilitare l'intero processo.
In questa serie, daremo un'occhiata a un'utilità che funziona appena ma, prima di farlo, diamo un veloce primer sul database di WordPress per assicurarci che siamo tutti sulla stessa pagina.
Quando si tratta di discutere del database di WordPress, è possibile scrivere un'intera serie di articoli su ciascuna tabella, ogni colonna, lo schema, come scrivere query ottimali e così via.
Questa non è la serie per questo.
Invece, faremo due cose in questo articolo:
In definitiva, questo dovrebbe aiutare a spiegare o demistificare parte del lavoro di base per coloro che trascorrono più tempo sul front-end, e può aiutare coloro che passano più tempo a livello dell'applicazione a lavorare con l'API di WordPress a capire quali funzioni corrispondono a quale tabella (che alla fine può portare a scrivere un codice migliore).
In generale, penso che la maggior parte dei lettori di Wptuts + sappia cos'è un database.
Direttamente da Wikipedia:
Un database è una raccolta organizzata di dati. I dati sono generalmente organizzati per modellare aspetti rilevanti della realtà (ad esempio, la disponibilità di camere negli hotel), in un modo che supporta processi che richiedono tali informazioni (ad esempio, la ricerca di un hotel con posti vacanti).
Questa è una definizione corretta, ma non penso che faccia un buon lavoro illustrando il database di WordPress o applicazioni web simili - è un po 'troppo generico. Quindi, da qui, creiamo la nostra definizione operativa che possiamo usare per il resto della serie.
Proviamo questo:
Un database è composto da almeno una tabella. Una tabella è composta da righe e colonne ciascuna delle quali memorizza informazioni uniche. Ogni riga è chiamata record. Possono esistere più tabelle in un database e talvolta le tabelle possono essere correlate l'una con l'altra.
Forse la parte più confusa di ciò che ho condiviso sopra è che le tabelle possono essere correlate l'una con l'altra. Rivedremo questa idea prima della fine dell'articolo, ma prima, discutiamo del database di WordPress.
In breve, il database di WordPress è composto da undici tabelle (a meno che tu non stia usando Multisite, ma questo è al di fuori dell'ambito di questa serie).
Ora, ogni tabella ha anche il proprio set di colonne che rappresentano una varietà di informazioni memorizzate all'interno della tabella. Ad esempio, il wp_posts la tabella ha una colonna chiamata POST_CONTENT che rappresenta il contenuto effettivo archiviato in un post.
Le tabelle e le loro descrizioni sono le seguenti:
E questo è tutto ciò che c'è nel database di WordPress. È relativamente semplice e diretto, giusto?
I post vengono mantenuti nella tabella dei post, i commenti nella tabella dei commenti, gli utenti nella tabella degli utenti e così via. Certo, ci sono alcune sfumature sottili (come il fatto che le pagine sono memorizzate nella tabella Post); tuttavia, è uno schema relativamente semplice da seguire.
È una buona cosa.
Inoltre, ricorda come abbiamo detto prima che alcune tabelle possono riferirsi l'una all'altra? Un buon esempio di questo sarebbe la tabella dei commenti e la tabella dei post. Dato che i commenti vengono lasciati su un post specifico, un commento deve sapere a quale post ID è associato in modo che quando un post viene caricato, i commenti relativi all'ID di quel post possano essere recuperati.
Ad ogni modo, questo è più dettagliato di quello che ci immergeremo in questa serie, ma speriamo sia abbastanza per darvi un'idea. Se ti interessano maggiori informazioni tecniche, le relazioni tra le tabelle, le colonne e altro ancora, quindi controlla definitivamente l'articolo Codex di WordPress nella descrizione del database.
A questo punto, abbiamo coperto tutto ciò di cui abbiamo bisogno per coprire il nostro database di WordPress. Speriamo che questo aiuti a tirare indietro il sipario per ciò che accade sotto il cofano ogni volta che salvate le informazioni in WordPress, ma ora che abbiamo coperto questo è il momento di guardare uno strumento che rende estremamente facile il lavoro con le migrazioni dei dati.
E considerando che ora abbiamo una comprensione di come è organizzato il database, dovremmo anche avere una comprensione di come funzionano le migrazioni.
Accentsconagua