Share
Heeft u zich ooit afgevraagd hoe u Versiebeheer met WordPress zou kunnen gebruiken? Als u liever lokaal aan uw WordPress-projecten werkt, maar ze op afstand moet synchroniseren, is deze zelfstudie iets voor u. U hebt waarschijnlijk geprobeerd om tussen de twee setups te synchroniseren door de gewijzigde bestanden handmatig te uploaden en PHPmyAdmin te gebruiken om uw database te exporteren en importeren nadat deze is gewijzigd en (zeer waarschijnlijk) iets in het proces te hebben gebroken. In deze tutorial gaan we naar automatiseer het synchronisatieproces; zodat je je kunt concentreren op wat je moet doen in plaats van worstelen met eindeloze migraties.
Meestal starten we de ontwikkeling van WordPress op onze lokale machines. Het gaat altijd sneller en gemakkelijker, vooral als je een trage internetverbinding hebt. Maar er zijn tijden dat u op afstand moet werken. Misschien wil je een kleine wijziging aanbrengen, wat opvulling repareren of gewoon een nieuw bericht publiceren. De wijzigingen worden niet opgeslagen in uw installatie van de WordPress lokale machine en dat is wanneer de rommel begint.
Het rommeltje begint, omdat je misschien een nieuwe versie moet vrijgeven en omdat je lokaal werkt, moeten wijzigingen die je op afstand hebt aangebracht offline worden gebracht. Het is een echte pijn. U moet uitzoeken welke bestanden u hebt gewijzigd en deze downloaden / FTP -en. Soms gebeuren de wijzigingen in de database, dus u hebt een speciale tool zoals phpmyAdmin nodig om de wijzigingen te bewerkstelligen.
In dit proces kunt u iets breken of een wijziging vergeten. Dat is wanneer alles rommelig wordt. In dit geval heeft u twee dingen nodig: versiebeheer en synchronisatie. In deze zelfstudie ga ik de oplossing beschrijven die ik volg om mijn ontwikkeling en synchronisatie tussen mijn lokale machine en mijn externe server te organiseren..
Laat me eerst uitleggen wat we gaan doen. Ons doel is om gemakkelijk te synchroniseren tussen de externe en lokale versie. Je zult werken in welke versie je wilt en ze vervolgens identiek maken. Om dat te doen, moeten we eerst rekening houden met verschillen tussen de externe en lokale instellingen.
WordPress slaat informatie over uw blog op in zowel statische bestanden als uw database. Een deel van deze informatie is relatief ten opzichte van uw huidige hosting. Daarom zal het niet werken wanneer u uw hele WordPress-directory uploadt en de externe versie vervangt.
De informatie is helaas verdeeld in twee delen:
Voor de wp-config.php implementeren we een proces dat detecteert of we zich op de lokale of externe server bevinden. Op die manier zal hetzelfde bestand in beide omgevingen werken. Voor de database zullen we het integreren met het versiecontrolesysteem en het bijwerken om overeen te komen met de lokale of externe hostinstellingen.
Ik gebruik Mercurial voor versiebeheer. Git is populairder in de webontwikkelarena, maar in ons geval zijn ze bijna hetzelfde: je hebt alleen een versiebeheerstool nodig.
Kies Mercurial als u op een Windows-computer werkt. Het heeft Tortoise, een gebruiksvriendelijke interface, om je repositories te beheren. Het hulpprogramma voor versiebeheer moet zowel op uw lokale machines als op externe computers zijn geïnstalleerd. Dat gezegd hebbende, heeft u een dedicated server of een VPS nodig om de applicatie van derden te kunnen installeren.
Om een repository in Mercurial te initialiseren, typt u het volgende in uw console
cd / mydev_directory hg init hg add hg commit
In de eerste regel veranderen we onze werkmap in de map waarin we versiebeheer willen inschakelen. Dit wordt uw WordPress-map (waar u WordPress installeert). De volgende regel initialiseert de repository. Op de derde regel wordt aangegeven dat alle versies van de map met mercurial moeten worden beheerd. Dit omvat ook submappen. De laatste regel maakt een nieuwe wijzigingenset in de map; je teksteditor wordt geopend en je wordt gevraagd om een beschrijving van deze commit te schrijven.
Deze zelfstudie behandelt niet hoe u Mercurial gebruikt. Als u versiebeheer niet kent, zou u het moeten leren. Dat is een belangrijk hulpmiddel om toe te voegen aan je vaardigheden. Hier zijn een paar tutorials die ik stel voor:
We zullen een nieuwe installatie van WordPress maken op onze lokale computer. Download de nieuwste WordPress-versie, pak deze uit in een lege map naar keuze in uw webserver en installeer deze vanuit uw browser of door het bestand wp-config.php te wijzigen.
Nu gaan we versiebeheer activeren in onze WordPress-directory
cd / testpress Hg init Hg voeg Hg commit toe
Deze opdrachten initialiseren de repository en maken de eerste changeset. Nu kunnen we deze repository gewoon klonen op onze server, WordPress installeren en kunnen we heen en weer synchroniseren tussen de lokale distributie en de distributie op afstand.
Er zijn echter verschillen zoals we eerder al zeiden. Voordat het synchronisatieproces wordt geïmplementeerd, moeten we een script implementeren dat controleert waar de WordPress-installatie wordt uitgevoerd en de juiste instellingen laadt.
De instellingen die moeten worden gewijzigd, zijn de database-informatie. Ze bevinden zich in het bestand wp-config.php en WordPress laadt ze uit dit bestand. Mijn lokale versie ziet er zo uit
Accentsconagua
// ** MySQL-instellingen - U kunt deze informatie opvragen bij uw webhost ** // / ** De naam van de database voor WordPress * / define ('DB_NAME', 'test'); / ** MySQL database gebruikersnaam * / define ('DB_USER', 'root'); / ** MySQL-databasewachtwoord * / define ('DB_PASSWORD', 'xxxxx'); / ** MySQL-hostnaam * / define ('DB_HOST', 'localhost'); / ** Database Charset om te gebruiken bij het maken van databasetabellen. * / define ('DB_CHARSET', 'utf8'); / ** Het type Database Sorteren. Verander dit niet bij twijfel. * / define ('DB_COLLATE', "); Merk op dat ik alleen het gedeelte heb gekopieerd dat er toe doet. In mijn externe server, zou dit deel enigszins moeten verschillen
// ** MySQL-instellingen - U kunt deze informatie opvragen bij uw webhost ** // / ** De naam van de database voor WordPress * / define ('DB_NAME', 'user_blog'); / ** MySQL database gebruikersnaam * / define ('DB_USER', 'root'); / ** MySQL-databasewachtwoord * / define ('DB_PASSWORD', 'xyxyx'); / ** MySQL-hostnaam * / define ('DB_HOST', 'localhost'); / ** Database Charset om te gebruiken bij het maken van databasetabellen. * / define ('DB_CHARSET', 'utf8'); / ** Het type Database Sorteren. Verander dit niet bij twijfel. * / define ('DB_COLLATE', "); De truc is om een code te schrijven die detecteert waar WordPress zich bevindt. De te gebruiken variabele is de PHP-variabele _SERVER [ "HTTP_HOST"]. De code evalueert de variabele en wijst de database-instellingen toe.
/ * * Uniforme variabelen * / $ user_name = 'root'; $ hostname = 'localhost'; $ charset = 'UTF-8'; $ collate = "; / * * Controleer de huidige omgeving * / if ($ _SERVER [" HTTP_HOST "] === 'onlineqrlab.com') $ db_name = 'user_wordpress'; $ password = 'xyxyxy'; else if ($ _SERVER ["HTTP_HOST"] === 'localhost') $ db_name = 'test'; $ password = 'xxxxxx'; // ** MySQL-instellingen - U kunt deze informatie van uw webhost ontvangen ** // / ** De naam van de database voor WordPress * / define ('DB_NAME', $ db_name); / ** MySQL-database gebruikersnaam * / define ('DB_USER', $ user_name); / ** MySQL-databasewachtwoord * / define ('DB_PASSWORD', $ wachtwoord); / ** MySQL-hostnaam * / define ('DB_HOST', $ hostname); / Database-karakterset om te gebruiken bij het maken van databasetabellen. * / define ('DB_CHARSET', $ grafiekset) ; / ** Het type Database Sorteren. Wijzig dit niet bij twijfel. * / Define ('DB_COLLATE', $ collate); In het bovenstaande voorbeeld heb ik slechts twee parameters gewijzigd: databasenaam en wachtwoord. Je hebt misschien meer dan dat. Als u bijvoorbeeld mijnSQL op een externe server host, moet u de hostnaam voor de instelling van de externe server wijzigen. Je kunt ook beter de toegang van het WordPress-blog beperken tot gebruikersniveau met beperkte mogelijkheden in plaats van beheerdersniveau.
Controleer of uw WordPress lokale versie werkt. Als dat zo was, dan ben je nog half klaar!
U kunt nu beginnen met werken aan uw lokale WordPress-installatie. Telkens wanneer u een belangrijke wijziging aanbrengt, maakt u een commit met Mercurial om de wijzigingen te volgen. In de externe server, ervan uitgaande dat je Apache hebt geïnstalleerd, maak je een nieuwe map aan waarin je je WordPress-repository uploadt.
cd / apache mkdir mywp_repo cd mywp_repo
Merk op dat deze opdrachten moeten worden uitgevoerd op uw externe server. Je hebt ook SSH-toegang en een commandoregel nodig. Ik gebruik Putty op Windows om verbinding te maken met mijn server.
Zodra onze repository is geïnitialiseerd, kunnen we wijzigingenets uit andere archieven pushen (uploaden) en ophalen (downloaden) om deze up-to-date te houden. Om dit proces te laten plaatsvinden, hebt u uw lokale of externe server nodig om de repository te publiceren, zodat u eraan kunt trekken / duwen.
Mercurial-webserver mist enkele belangrijke functies zoals toegangsbeheer, authenticatie en SSL. Het is dus onveilig om het op uw externe server te gebruiken. Bij voorkeur moet u de Mercurial-webserver lokaal uitvoeren en de wijzigingen van de lokale server naar de externe server trekken.
Om de Mercurial-server uit te voeren, typt u het volgende in uw lokale computer:
hg serveren
Nu zou u vanuit uw browser toegang moeten hebben tot uw repository. Typ de URL die wordt weergegeven op uw opdrachtregel. Meestal is het localhost: 8000. De repository is ook online beschikbaar. U kunt het openen vanaf elke computer die is verbonden met internet met uw adres: 8000.
Hg pull 192.xxx.xxx.xxx:8000 Hg update
Maar ik raad deze methode niet aan, omdat deze niet veilig is. Er is een gemakkelijke en veilige manier om dat te doen. Het is een middelgrote repository die wordt gehost door een externe service. Ik gebruik BitBucket. Het heeft een goede en betrouwbare service en biedt ook tracking van bugs en een wiki.
Registreer en maak een account aan in BitBucket. Ze bieden onbeperkte privé- en openbare opslagplaatsen met maximaal 5 gebruikers gratis. Maak een nieuwe repository in BitBucket en je zou naar deze pagina moeten worden geleid.
BitBucket heeft ondersteuning voor HTTPS en SSH. Als uw repository privé is, zoals in mijn geval, moet u verifiëren met uw gebruikersnaam en wachtwoord om te kunnen duwen en trekken uit de repository.
Nadat u uw nieuwe repository in BitBucket hebt gemaakt, voert u de volgende opdrachten uit op uw lokale computer
hg push https: //[email protected]/username/repository
U wordt gevraagd om uw wachtwoord in te voeren en de repository wordt geüpload naar BitBucket. Na het uploaden naar BitBucket, klonen de repository naar uw externe server.
hg clone https: //[email protected]/gebruikersnaam / repository hg update
Clonen downloadt de bestanden naar een nieuwe map (waarbij de naam hetzelfde is als de map van uw repository); je kunt deze map hernoemen. Dit maakt de eerste stap in deze sectie (waar we de WordPress setup-map hebben gemaakt) nogal achterhaald.
Zie BitBucket als een tussenpersoon tussen uw computer en uw externe host. Het is mogelijk om uw eigen beveiligde Mercurial-server in uw externe server te hebben, maar dit valt buiten het bestek van deze zelfstudie. Het voordeel is onafhankelijk te zijn van de middelste man. Hiermee kunt u wijzigingen direct naar uw webserver pushen.
Dus hoe is dit beter dan FTP?
Ben je al moe? Maak je geen zorgen, we zijn er bijna. Nadat u de repository hebt opgehaald van uw lokale computer of BitBucket, moet u de WordPress-installatie opnieuw uitvoeren; deze keer op de externe serversite. Zorg ervoor dat de instellingen die u in het wp-config.php-bestand dat we eerder hebben gemaakt juist zijn en laad uw WordPress externe site.
U wordt opnieuw gevraagd uw WordPress-blog te installeren, omdat uw database leeg is. Na de installatie is je WordPress-blog klaar. U kunt wijzigingen aanbrengen in de externe of lokale versie en deze synchroniseren met Mercurial.
Maar er is nog steeds een belangrijk probleem: de database synchroniseert niet met de bestanden. Dit is belangrijk omdat dingen zoals blogposts, opmerkingen, plug-in aangepaste tabellen zijn? zal niet hetzelfde zijn in de lokale en externe versie.
WordPress heeft een import / export-functie. Maar het is niet handig, omdat het geen echte synchronisatie doet. Wat u nodig heeft, is naar uw phpmyadmin gaan, al uw WordPress-tabellen aan één kant (op afstand of lokaal) exporteren en vervolgens naar de andere kant phpmyadmin gaan en de tabellen vervangen.
Na dit te doen, zullen uw WordPress-databases hetzelfde worden. U moet echter de rij site_url in de tabel wp_options wijzigen. Dit proces wordt pijnlijk als de database zwaarder wordt.
Zoals we eerder zagen, is de database een beetje problematisch. Het wordt niet gesynchroniseerd met de bestanden, is moeilijker te bereiken en vereist bij elke synchronisatie twee velden. Het is niet leuk om het steeds opnieuw te doen. Automatisering is de oplossing; eigenlijk is dat onze taak.
Wat we nodig hebben is een script dat de lokale en externe databases synchroniseert zonder iets te breken. Het idee dat naar mijn mening opkwam, was om de database op te nemen in de revisiecontrole. De database-inhoud wordt geëxporteerd naar een bestand dat wordt bijgehouden door het revisiestuur. Telkens wanneer we wijzigingen doorvoeren, wordt de database-inhoud vervangen door dit bestand, waardoor onze database up-to-date is.
Aangezien er een aantal rijen zijn die van host tot host (de url van de site en de url van de startpagina) verschillen, hebben we een ander mysql-script nodig dat deze met de juiste waarden bijwerkt.
Een ander belangrijk ding is conflicten. Als u werkt en wijzigingen (commits) aanbrengt in zowel de externe als lokale versie, zal dit een conflict veroorzaken. Een typisch scenario is wanneer u werkt en vastlegt aan uw lokale versie en iemand (online) nieuwe inhoud toevoegt aan uw blog. Ik kan niet helpen in deze situatie, je moet leren over Mercurial (of je revisiebeheer) samenvoegen en teamwerk.
Om conflicten te voorkomen, moet u ervoor zorgen dat u de repository uit BitBucket haalt voordat u wijzigingen aanbrengt; en ook om de wijzigingen in BitBucket vast te leggen en te pushen na het maken ervan. Dit zorgt ervoor dat BitBucket altijd de nieuwste versie heeft en u werkt ook aan de nieuwste versie.
Deze stap is een beetje gevoelig, dus zorg ervoor dat u de stappen zorgvuldig volgt. Eerst ga ik uitleggen hoe de eindoplossing werkt. Je zult twee scripts hebben: duwen en trekken. Afhankelijk van je besturingssysteem wordt dit push.sh en pull.sh (Linux) of push.bat of pull.bat (Windows). Ik gebruik Windows lokaal en Linux (Ubuntu) remotly, dus deze zelfstudie zal beide besturingssystemen omvatten.
Het eerste script pusht de wijzigingen naar de Bitbucket-server. Wanneer u een aantal databasewijzigingen aanbrengt, gebruikt u het push-script om de wijzigingen in uw BitBucket-repository te uploaden. Push zal de huidige database dumpen naar een bestand (/db/db_sync.sql) dat wordt gevolgd door het versiecontrolesysteem. Het bestand wordt samen met de andere bestanden gepusht en geüpload naar BitBucket.
Het tweede script zal de wijzigingen van de Bitbucket-server ophalen. Het pull-script zal ook het bestand (/db/db_sync.sql) lezen en de database vervangen. Hiermee wordt de database bijgewerkt met de versie waarmee u hebt gepusht. Omdat ze verschillende hostnamen hebben, zal het pull-script de nodige velden wijzigen, namelijk de URL van de site en de URL van de startpagina.
Maak op de externe en lokale server een nieuwe map met de naam "db". Het geëxporteerde databasebestand wordt daar opgeslagen. Gebruik in je lokale server (ik neem aan dat je Windows gebruikt) een nieuw bestand met de naam push.bat. Het maakt niet echt uit waar u het bestand plaatst (zorg er wel voor dat u de juiste paden gebruikt). Ik zet het bestand in de hoofdmap van mijn WordPress-repository.
mysqldump -u gebruikersnaam -ppassword database_name> db / db_sync.sql hg add db / db_sync.sql hg commit hg push https: //[email protected]/username/repository
U kunt de opdracht "hg add db / db_sync.sql" verwijderen nadat u het script voor de eerste keer hebt uitgevoerd. Dit is maar één keer nodig.
Aan de serverzijde (Linux / Ubuntu) is het niet echt anders. De bestandsextensie verandert van .bat in .sh, en mogelijk de gebruikersnaam, het wachtwoord en de databasenaam van uw mySql-server. De inhoud van het bestand is precies hetzelfde.
Trekken is een beetje moeilijker. Hiervoor is het importeren van het SQL-bestand vereist en ook het wijzigen van enkele kritieke velden die verschillen van een omgeving naar een andere.
Maak op uw lokale computer een bestand met de naam pull.bat
hg pull https: //[email protected]/username/repository hg update cd db mysql -u gebruikersnaam -ppassword testpress < db_sync.sql mysql -u username -ppassword testpress < db.sql
Voeg in je map db een bestand met de naam "db.sql" toe. Dit bestand bevat SQL-instructies die de vereiste wijzigingen doorvoeren om overeen te komen met de hostinstellingen. U kunt meer instructies toevoegen als dat nodig is.
USE testpress; UPDATE wp_options SET option_value = "http: // localhost / testpress" WHERE option_name = "siteurl"; UPDATE wp_options SET option_value = "http: // localhost / testpress" WHERE option_name = "home";
Afgezien van de bestandsextensie, mySQL-instellingen en database-namen verandert er niets echt in de externe server. Dit komt omdat we programma-opdrachten uitvoeren. De opdrachten en het gebruik ervan is platformonafhankelijk. Zorg ervoor dat u de juiste waarden invoert voor de website-URL in het bestand "db.sql". Ze moeten overeenkomen met uw blog-URL, als u niet zeker weet of u altijd de waarden in de tabel wp_options kunt controleren.
Als u de scripts wilt uitvoeren, dubbelklik in Windows dan op?? Bat? bestand en in uw externe serverterminal voert u de opdracht? sh script_name.sh uit?.
Je zou nu 2 uitvoerbare bestanden in elke omgeving moeten hebben (pull en push). U zou ook een sqlscript (db.sql) moeten hebben dat niet aan versiebeheer zou moeten worden toegevoegd. We kunnen ons kleine systeem nu testen.
