Share
Noen gang lurt på hvordan du kan bruke Versjonskontroll med WordPress? Hvis du foretrekker å jobbe på WordPress-prosjektene dine lokalt, men må få dem til å synkronisere eksternt, er denne opplæringen for deg. Du har sannsynligvis forsøkt å synkronisere mellom de to oppsettene manuelt ved å laste opp de endrede filene og bruke PHPmyAdmin til å eksportere og importere databasen en gang forandret, og (veldig sannsynlig) brøt noe i prosessen. I denne opplæringen skal vi automatiser synkroniseringsprosessen; slik at du kan konsentrere deg om hva du skal gjøre i stedet for å bryte med uendelige migrasjoner.
Vi starter vanligvis WordPress-utvikling på våre lokale maskiner. Det er alltid raskere og enklere, spesielt når du har en langsom internettforbindelse. Men det er tider når du trenger å jobbe eksternt. Du vil kanskje gjøre en liten endring, fikse litt polstring eller bare publisere et nytt innlegg. Modifikasjonene lagres ikke på din lokale WordPress-maskininstallasjon, og det er da rotet begynner.
Rotet starter fordi du må kanskje slippe ut en ny versjon, og siden du jobber lokalt, må endringer som du har gjort eksternt, hentes off-line. Det er en ekte smerte. Du må finne ut hvilke filer du endret og laste ned / FTP dem. Noen ganger skjer endringene i databasen, så du trenger et spesielt verktøy som phpmyAdmin for å få endringene.
I prosessen kan du bryte noe eller glemme en endring. Det er da alt blir rotete. I dette tilfellet trenger du to ting: versjonskontroll og synkronisering. I denne opplæringen skal jeg beskrive løsningen jeg følger for å organisere min utvikling og synkronisering mellom min lokale maskin og min eksterne server.
Først, la meg forklare hva vi skal gjøre. Vårt mål er å synkronisere lett mellom den eksterne og lokale versjonen. Du vil jobbe i hvilken versjon du vil, og deretter gjør dem identiske. For å gjøre det, må vi først regne med forskjeller mellom fjernkontrollen og det lokale oppsettet.
WordPress lagrer informasjon om bloggen din i både statiske filer og databasen din. Noen av denne informasjonen er i forhold til din nåværende hosting. Det er derfor når du laster opp hele WordPress-katalogen og erstatter fjernversjonen, vil den ikke fungere.
Informasjonen splittes uheldig i to deler:
For wp-config.php, vil vi implementere en prosess som oppdager om vi er i den lokale eller eksterne serveren. På samme måte vil den samme filen fungere i begge miljøer. For databasen integrerer vi den med versjonskontrollsystemet og oppdaterer den for å matche lokale eller eksterne vertsinnstillinger.
Jeg bruker Mercurial for versjonskontroll. Git er mer populært i webutviklingsarenaen, men i vårt tilfelle er de nesten like: Du trenger bare et versjonskontrollverktøy.
Velg Mercurial hvis du er på en Windows-maskin. Det har Skildpadde, et brukervennlig grensesnitt, for å administrere dine arkiver. Versjonskontrollverktøyet må installeres på både lokale og eksterne maskiner. Når det blir sagt, trenger du en dedikert server eller en VPS for å kunne installere tredjepartsprogrammet.
For å initialisere et lager i Mercurial, skriv følgende i konsollen
cd / mydev_directory hg init hg legg til hg commit
I den første linjen endrer vi arbeidskatalogen til mappen vi vil aktivere versjonskontroll i. Dette blir din WordPress-katalog (hvor du installerer WordPress). Neste linje initierer lageret. Den tredje linjen forteller mercurial til versjonskontroll av alle filene i katalogen. Dette vil også omfatte undermapper. Den siste linjen oppretter en ny endring i katalogen; Tekstredigeringsprogrammet ditt åpnes, og du blir bedt om å skrive en beskrivelse av denne plikten.
Denne veiledningen dekker ikke hvordan du bruker Mercurial. Hvis du ikke kjenner versjonskontroll, bør du lære det. Det er et viktig verktøy for å legge til dine ferdighetssett. Her er noen opplæringsprogrammer som jeg foreslår:
Vi vil lage en ny installasjon av WordPress i vår lokale maskin. Last ned den nyeste WordPress-versjonen, pakk den ut i en tom katalog av ditt valg i din webserver, og installer den fra nettleseren din eller ved å endre wp-config.php-filen.
Nå skal vi aktivere versjonskontroll i vår WordPress-katalog
cd / testpress Hg init Hg legg til Hg commit
Disse kommandoene initierer lageret og lager den første endringen. Nå kan vi bare klone dette depotet på vår server, installere WordPress og kunne synkronisere frem og tilbake mellom lokal og ekstern distribusjon.
Det er imidlertid forskjeller som vi sa tidligere. Før du implementerer synkroniseringsprosessen, må vi implementere et skript som kontrollerer hvor WordPress-installasjonen kjører og laster inn de riktige innstillingene.
Innstillingene som må endres, er databasen informasjon. De befinner seg i wp-config.php-filen, og WordPress laster dem fra denne filen. Min lokale versjon ser slik ut
Accentsconagua
// ** MySQL-innstillinger - Du kan få denne informasjonen fra webverten din ** // / ** Navnet på databasen for WordPress * / define ('DB_NAME', 'test'); / ** MySQL database brukernavn * / define ('DB_USER', 'root'); / ** MySQL database passord * / define ('DB_PASSWORD', 'xxxxx'); / ** MySQL vertsnavn * / define ('DB_HOST', 'localhost'); / ** Database Charset å bruke til å lage databasetabeller. * / define ('DB_CHARSET', 'utf8'); / ** Database-sorteringstypen. Ikke endre dette hvis du er i tvil. * / define ('DB_COLLATE', "); Merk at jeg bare kopierte den delen som betyr noe. På min eksterne server, bør denne delen avvike noe
// ** MySQL-innstillinger - Du kan få denne informasjonen fra webverten din ** // / ** Navnet på databasen for WordPress * / define ('DB_NAME', 'user_blog'); / ** MySQL database brukernavn * / define ('DB_USER', 'root'); / ** MySQL database passord * / define ('DB_PASSWORD', 'xyxyx'); / ** MySQL vertsnavn * / define ('DB_HOST', 'localhost'); / ** Database Charset å bruke til å lage databasetabeller. * / define ('DB_CHARSET', 'utf8'); / ** Database-sorteringstypen. Ikke endre dette hvis du er i tvil. * / define ('DB_COLLATE', "); Trikset er å skrive noen kode som oppdager hvor WordPress er plassert. Variabelen å bruke er PHP-variabelen _SERVER [ "HTTP_HOST"]. Koden evaluerer variabelen og tildeler databasens innstillinger.
/ * * Samlede variabler * / $ user_name = 'root'; $ hostname = 'localhost'; $ charset = 'UTF-8'; $ collate = "; / * * Sjekk for det nåværende miljøet * / hvis ($ _SERVER [" HTTP_HOST "] === 'onlineqrlab.com') $ db_name = 'user_wordpress'; $ password = 'xyxyxy'; else hvis ($ _SERVER ["HTTP_HOST"] === 'localhost') $ db_name = 'test'; $ password = 'xxxxxx'; // ** MySQL-innstillinger - Du kan få denne informasjonen fra webverten din ** // / ** Navnet på databasen for WordPress * / define ('DB_NAME', $ db_name); / ** MySQL database brukernavn * / define ('DB_USER', $ user_name); / ** MySQL database passord * / definere ('DB_PASSWORD', $ passord); / ** MySQL vertsnavn * / define ('DB_HOST', $ vertsnavn); / ** Database Charset å bruke til å lage database tabeller. * / define ('DB_CHARSET' ; / ** Database-sorteringstypen. Ikke endre dette hvis du er i tvil. * / Define ('DB_COLLATE', $ collate); I eksemplet ovenfor har jeg bare to parametere som endret: Databasens navn og passord. Du kan ha mer enn det. For eksempel, hvis du er vert for mySql på en ekstern server, må du endre vertsnavnet for det eksterne serveroppsettet. Du bør også begrense tilgangen til WordPress-bloggen til brukernivå med begrensede muligheter i stedet for administratornivå.
Kontroller at din WordPress lokale versjon fungerer. Hvis det gjorde det, så er du halvt ferdig!
Du kan begynne å jobbe med din lokale WordPress-installasjon. Hver gang du gjør en større modifikasjon, gjør du en forpliktelse med Mercurial for å spore endringene. På den eksterne serveren, forutsatt at du har installert Apache, opprett en ny mappe der du laster opp WordPress-depotet.
cd / apache mkdir mywp_repo cd mywp_repo
Merk at disse kommandoene skal utføres på den eksterne serveren. Du trenger SSH-tilgang og en kommandolinje også. Jeg bruker Putty på Windows for å koble til serveren min.
Når vårt arkiv er initialisert, kan vi presse (laste opp) og trekke (laste ned) endringer fra andre lagre for å holde den oppdatert. For at denne prosessen skal skje, trenger du enten den lokale eller eksterne serveren til å publisere depotet, slik at du kan trekke / skyve fra den.
Mercurial webserver mangler noen viktige funksjoner som tilgangskontroll, autentisering og SSL. Så det er usikkert å bruke det på den eksterne serveren din. Fortrinnsvis må du kjøre Mercurial-webserveren lokalt og trekke endringene fra den lokale serveren til den eksterne serveren.
For å kjøre Mercurial-serveren skriver du inn følgende i din lokale maskin:
hg tjene
Nå bør du kunne få tilgang til lageret ditt fra nettleseren din. Skriv inn nettadressen som vises på kommandolinjen. Vanligvis er det lokalehost: 8000. Lageret er også tilgjengelig på nettet. Du kan få tilgang til den fra hvilken som helst datamaskin som er koblet til Internett ved hjelp av din adresseadresse: 8000.
Hg trekke 192.xxx.xxx.xxx:8000 Hg oppdatering
Men jeg anbefaler ikke denne metoden fordi den ikke er sikker. Det er en enkel og sikker måte å gjøre det på. Det er et mellomregister som er vert for en tredjepartstjeneste. Jeg bruker BitBucket. Den har en god og pålitelig service og tilbyr også bugs sporing og en wiki.
Registrer og opprett en konto i BitBucket. De tilbyr ubegrensede private og offentlige repositorier med opptil 5 brukere gratis. Opprett et nytt lager i BitBucket, og du bør bli tatt til denne siden.
BitBucket har HTTPS og SSH-støtte. Hvis depotet ditt er privat, som i mitt tilfelle, må du autentisere med brukernavnet og passordet ditt for å kunne trykke og trekke fra depotet.
Etter å ha opprettet ditt nye lager i BitBucket, utfør følgende kommandoer på din lokale maskin
hg skyv https: //[email protected]/username/repository
Du vil bli bedt om å oppgi passordet ditt og depotet vil bli lastet opp til BitBucket. Etter opplasting til BitBucket, klone lagringsplassen til den eksterne serveren.
hg klone https: //[email protected]/brukernavn / repository hg oppdatering
Kloning laster ned filene til en ny katalog (med navnet er det samme som ditt arkivkatalog); Du kan gi nytt navn til denne katalogen. Dette vil gjøre det første trinnet i denne delen (der vi opprettet WordPress setup-katalogen) ganske foreldet.
Tenk på BitBucket som mellommann mellom datamaskinen og fjernkontrollen din. Det er mulig å ha din egen sikre Mercurial-server på den eksterne serveren din, men dette er utenfor omfanget av denne opplæringen. Fordelen er å være uavhengig av mellommannen. Dette gjør det mulig å skifte endringer direkte til webserveren din.
Så hvordan er dette bedre enn FTP?
Er du allerede sliten? Ikke bekymre deg, vi er nesten der. Etter at du har trukket lageret enten fra din lokale maskin eller BitBucket, må du kjøre WordPress-installasjonen på nytt. denne gangen på den eksterne serveren. Kontroller at innstillingene du legger inn i wp-config.php-filen vi laget tidligere, er riktige, og laster inn din WordPress-fjernside.
Du blir bedt om å installere WordPress-bloggen din igjen, det er fordi databasen din er tom. Etter installasjonen er WordPress-bloggen din klar. Du kan gjøre endringer i den eksterne eller lokale versjonen og synkronisere dem med Mercurial.
Men det er fortsatt et viktig problem: Databasen synkroniseres ikke med filene. Dette er viktig fordi ting som blogginnlegg, kommentarer, plugin-tilpassede tabeller? vil ikke være det samme i den lokale og eksterne versjonen.
WordPress har en import / eksport-funksjon. Men det er ikke nyttig, siden det ikke gjør en ekte synkronisering. Det du trenger er å gå til phpmyadmin, eksporter alle WordPress-tabellene dine på den ene siden (ekstern eller lokal) og gå til den andre siden phpmyadmin og erstatt tabellene.
Etter at du har gjort dette, blir WordPress-databasene dine de samme. Du må endre, men siden side_url-raden i wp_options-tabellen. Denne prosessen blir smertefull fordi databasen blir tyngre.
Som vi så tidligere, er databasen litt problematisk. Den blir ikke synkronisert med filene, er vanskeligere å nå, og krever oppdatering av to felt hver gang du synkroniserer. Det er ikke morsomt å gjøre det igjen og igjen. Automatisering er løsningen; faktisk, det er vår jobb.
Det vi trenger er et skript som synkroniserer lokale og eksterne databaser uten å bryte noe. Ideen som kom til å tenke meg er å inkludere databasen i revisjonskontrollen. Databasens innhold vil bli eksportert til en fil som spores av revisjonskontrollen. Hver gang vi trekker endringer, blir databasens innhold erstattet av denne filen, og gjør databasen oppdatert.
Siden det er et par rader som er forskjellige fra en vert til en annen (webadressen og hjemmesiden url), trenger vi et annet mysql-skript som oppdaterer disse med de riktige verdiene.
En annen viktig ting er konflikter. Hvis du jobber og gjør endringer (forplikter) til både den eksterne og lokale versjonen, vil dette skape en konflikt. Et typisk scenario er når du arbeider og forplikter deg til din lokale versjon, og noen (online) legger til nytt innhold på bloggen din. Jeg kan ikke hjelpe i denne situasjonen, du må lære mer om Mercurial (eller revisjonskontrollsystemet) fusjonere og lagarbeid.
For å unngå konflikter, sørg for at du trekker lageret fra BitBucket før du gjør endringer. og også å forplikte og presse endringene til BitBucket etter å ha gjort dem. Dette sikrer at BitBucket alltid har den nyeste versjonen, og du arbeider også med den nyeste versjonen.
Dette trinnet er litt følsomt, så sørg for at du følger trinnene nøye. Først skal jeg forklare hvordan sluttløsningen fungerer. Du skal ha to skript: trykk og trekk. Avhengig av operativsystemet, vil det være push.sh og pull.sh (Linux) eller push.bat eller pull.bat (Windows). Jeg bruker fjerntliggende Windows, og Linux (Ubuntu), så denne opplæringen vil dekke begge operativsystemene.
Det første skriptet vil skifte endringene til Bitbucket-serveren. Når du gjør noen databaseendringer, bruk push-skriptet for å laste opp endringene til BitBucket-depotet ditt. Push vil dumpe den nåværende databasen til en fil (/db/db_sync.sql) som spores av versjonskontrollsystemet. Filen vil bli presset sammen med de andre filene og lastet opp til BitBucket.
Det andre skriptet vil trekke endringene fra Bitbucket-serveren. Trekkskriptet vil også lese filen (/db/db_sync.sql) og erstatte databasen. Dette vil oppdatere databasen med den versjonen du presset med. Siden de har forskjellige vertsnavn, vil trekkskriptet modifisere de nødvendige feltene, nemlig webadressen til webadressen og hjemmesiden.
I den eksterne og lokale serveren oppretter du en ny katalog kalt "db". Den eksporterte databasefilen blir lagret der. I din lokale server (jeg antar at du bruker Windows) oppretter du en ny fil som heter push.bat. Det spiller ingen rolle hvor du legger filen (bare vær sikker på at du bruker de riktige banene). Jeg legger filen i rotkatalogen i mitt WordPress-depot.
mysqldump -u brukernavn - passord database_name> db / db_sync.sql hg legg til db / db_sync.sql hg commit hg push https: //[email protected]/brukernavn / repository
Du kan fjerne kommandoen "hg add db / db_sync.sql" etter at du har utført scriptet for første gang. Dette er bare nødvendig en gang.
På serversiden (Linux / Ubuntu) er ting ikke veldig mye forskjellige. Filforlengelsen endres fra .bat til .sh, og muligens ditt mySql-server brukernavn, passord og databasenavn. Filinnholdet er nøyaktig det samme.
Å trekke er litt vanskeligere. Det krever import av SQL-filen, og endrer også noen kritiske felt som adskiller seg fra et miljø til et annet.
I din lokale maskin oppretter du en fil som heter pull.bat
hg trekke https: //[email protected]/brukernavn / repository hg oppdatering cd db mysql -u brukernavn -ppassword testpress < db_sync.sql mysql -u username -ppassword testpress < db.sql
I din db-mappe, legg til en fil som heter "db.sql". Denne filen har SQL-setninger som vil gjøre de nødvendige endringene for å matche vertsinnstillingene. Du kan legge til flere uttalelser hvis du trenger det.
Bruk testpress; OPPDATERING wp_options SET option_value = "http: // localhost / testpress" WHERE option_name = "siteurl"; OPPDATERING wp_options SET option_value = "http: // localhost / testpress" HVOR option_name = "home";
Bortsett fra filtypen, endrer mySql-innstillinger og databaser navn ingenting på den eksterne serveren. Dette skyldes at vi utfører programkommandoer. Kommandoene og deres bruk er plattform agnostisk. Pass på at du oppgir de riktige verdiene for nettadressen til webområdet i "db.sql" -filen. De bør samsvare med nettadressen til bloggen din, hvis du ikke er sikker på at du kan sjekke verdiene i wp_options-tabellen.
For å kjøre skriptene, i Windows dobbeltklikker du på? .Bat? fil og i den eksterne serverterminalen, kjør kommandoen? sh script_name.sh?.
Du bør nå ha 2 kjørbare filer i hvert miljø (trekk og trykk). Du bør også ha et sql script (db.sql) som ikke bør legges til versjonskontrollerende. Vi kan nå teste vårt lille system.
