Share
Vandaag de dag bekleedt WordPress 25% van alle websites ter wereld, dus het is veilig om te zeggen dat wat begon als blogsoftware uitgegroeid is tot iets dat veel groter is dan de eenvoudige afkomst en dat het klaar is om te worden gebruikt op productieniveau-sites van nieuwsportals tot complete webapplicaties.
Met dit niveau van professionaliteit ontstaan er nieuwe behoeften.
Op een persoonlijke blog die wordt gelezen door vrienden en familie, zal een verbroken update van de plug-in niet veel meer veroorzaken dan lichte ergernis - hoogstwaarschijnlijk zullen uw lezers de fout niet eens zien. Wanneer u echter voor honderdduizenden bezoekers werkt, wordt een dergelijke fout onmiddellijk opgemerkt en komt u er niet zo gemakkelijk vanaf..
"Het werkte op mijn computer" misschien waar, maar het maakt de gefrustreerde klant niet gelukkiger.
Dat is waarom, terwijl je een professionele WordPress-site bouwt voor een groter publiek, je een hosting-opstelling nodig hebt die ervoor zorgt dat je updates veilig zijn en de live-omgeving nooit doorbreken.
Dus, hoe zorg je ervoor dat je server niet kapot gaat als je een nieuwe update live pusht, of het nu een nieuwe versie van je thema is of een update voor een of meer van je plug-ins?
Door te testen in een omgeving die identiek is aan de live server voordat u uw wijzigingen live doorvoert.
De installatie begint met een ontwikkelserver die u gebruikt voor uw dagelijkse werkzaamheden aan het product: testen van ontwikkelaars, vroege wijzigingen bij klanten voorstellen, enzovoort. Deze server kan op uw computer of op een server in de cloud worden uitgevoerd.
Als je tevreden bent met hoe de dingen eruit zien op de ontwikkelserver, zul je in deze opstelling niet haasten om je code live te pushen. In plaats daarvan legt u uw wijzigingen vast in versiebeheer en implementeert u ze in een testserver.
Omdat in de testomgeving serversoftware wordt uitgevoerd die identiek is aan de software op de live server, met uitzondering van het feit dat de nieuwe code nog niet is bijgewerkt naar de live-server, kunt u deze gebruiken om problemen op te sporen die zich op de server kunnen voordoen, maar niet op uw ontwikkelomgeving. Om het testen nog realistischer te maken en fouten te herkennen die worden veroorzaakt door gegevens die door uw klanten zijn ingevoerd, kunt u ook de testdatabase vullen met echte gegevens van uw live server.
Op de testserver zorgt u ervoor dat alles naar behoren werkt door de site handmatig te testen of door geautomatiseerde tests uit te voeren, of een combinatie van beide. En pas dan, als de tests succesvol zijn afgerond, druk je de wijzigingen live aan. Met vertrouwen, wetende dat de wijzigingen uw site niet zullen breken.
Hoewel de Dev-Test-Live-aanpak goed bekend is bij softwarebedrijven die online diensten bouwen, is deze van oudsher beperkt tot ontwikkelaars en bedrijven met de middelen om op eigen kracht meerdere servers te beheren en te beheren - en ze synchroon te houden met dezelfde server software en gegevens.
Dat betekent betalen voor veel servers, maar ook voor veel onderhoudswerk.
Op Pantheon komt deze aanpak samen met de service.
Pantheon is een schaalbare, snelle WordPress- en Drupal-hostingservice waarmee je niet alleen je code kunt testen op een testserver voordat je deze live pusht, maar die je ook dwingt de best-practice-procedure in al je implementaties te volgen.
In deze tutorial leert u hoe u een WordPress-site op Pantheon kunt opzetten en deze veilig kunt ontwikkelen en onderhouden met behulp van de Dev-Test-Live-architectuur en versiebeheer.
Laten we beginnen!
Nu je weet wat we gaan bouwen (en waarom), is het tijd om te beginnen.
Een van de geweldige dingen aan Pantheon is zijn prijsmodel: u betaalt pas wanneer uw site live gaat, dus u kunt alles proberen en zelfs uw website aan vrienden en klanten laten zien voordat u voor uw account moet betalen.
Ga eerst naar de Pantheon-website en maak je gratis account aan.
Als uw werk bestaat uit het maken van websites voor een heleboel klanten of als u een team van ontwikkelaars bij u heeft, kunt u zich aanmelden als een bureau. Bureaus hebben dezelfde prijsstructuur, maar krijgen ook enkele extra functies zoals Multidev, waarmee u een site in meerdere ontwikkelomgevingen kunt afhandelen om de samenwerking te vergemakkelijken en om nieuwe functies te bouwen en te demonstreren zonder de primaire omgeving bij te werken.
Als u niet zeker weet welk type account geschikt voor u is, kiest u gewoon de standaard account. U kunt uw account altijd later converteren naar een bureau-account.
Nadat u bent ingelogd, ziet u de volgende weergave:
Klik op Maak een nieuwe site om je eerste WordPress-site op Pantheon te bouwen.
Kies op dit scherm een naam voor uw site op Pantheon: de naam wordt gebruikt in uw Pantheon-beheerder en voor het genereren van de URL's van uw omgevingen. Je kunt deze naam later niet wijzigen, dus het is goed om erover na te denken, maar maak je geen zorgen. Het hoeft niet hetzelfde te zijn als de definitieve naam van je WordPress-site..
De namen zijn globaal over Pantheon, dus het selecteren van iets heel generieks kan tot een fout leiden. Probeer in dat geval iets anders.
Nadat u de naam hebt geselecteerd, klikt u op Maak een site.
Vervolgens wordt u gevraagd om de startstatus voor uw nieuwe site te kiezen. U kunt vanuit het niets een nieuwe website starten of een bestaande Drupal- of WordPress-site importeren:
Kiezen Begin met Scratch.
Onder de selectie ziet u een lijst met verschillende startpakketten of upstreams, zoals ze op Pantheon worden genoemd.
Deze standaard upstreams worden onderhouden door Pantheon, zodat wanneer een nieuwe update beschikbaar wordt voor een die u gebruikt (WordPress, in ons geval), u deze eenvoudig kunt bijwerken naar uw site via het Pantheon-dashboard.
Terwijl we een WordPress-site maken, klikt u op Installeer WordPress.
De installatie begint. En na een tijdje is het klaar.
Klik op de Bezoek je Pantheon-dashboard knop.
Nu heb je een gloednieuwe WordPress-installatie die draait op een Pantheon-ontwikkelingsserver en deze kan openen en beheren via het Pantheon-dashboard.
Bovenaan het scherm ziet u drie tabbladen voor de verschillende serveromgevingen: dev, Test, en Leven. Onder elk tabblad vindt u vervolgens een vergelijkbare menustructuur voor het onderhouden van die server en het implementeren van code en gegevens tussen omgevingen:
Klik op de Sitebeheerder knop in het linkerbovengedeelte van het scherm. Dat zal je door je normale WordPress-instellingsstroom leiden:
U kunt ook op de klikken Bezoek Development Site knop om de site te bekijken.
Nu uw ontwikkelomgeving aan de gang is, laten we eens kijken naar de andere twee omgevingen.
Zoals we hierboven hebben gezien, vindt u op het dashboard van het Pantheon de tabbladen voor de drie serveromgevingen: dev, Test, en Leven.
Elk van de tabbladen vertegenwoordigt een van de serveromgevingen waarop uw site wordt uitgevoerd. dev is de ontwikkelomgeving voor testen terwijl u op de site werkt en misschien een vroege versie van de site aan klanten laten zien. Leven is de versie van de site die actief is en wordt gebruikt door echte gebruikers.
Tussen de twee is Test, de omgeving die uw live-site relatief veilig houdt van uw fouten. Voordat je iets live op Pantheon kunt duwen, moet het altijd door een Test omgeving, zodat u nog een laatste kans krijgt om te controleren of alles naar behoren werkt voordat u uw code in het wild verzendt.
Omdat we zojuist de nieuwe WordPress-site hebben gemaakt, bestaat deze nog steeds alleen in de ontwikkelomgeving.
Laten we er een testomgeving voor maken.
Klik op de Test tab.
Omdat dit je eerste keer is op de Test tab, zult u enige informatie zien over hoe de testomgeving werkt.
Klik op Maak een testomgeving om je Dev-omgeving te klonen voor testen. In dit stadium worden zowel de code als de gegevens van Dev gekloond omdat er nog geen live-omgeving bestaat. In toekomstige updates ziet u echter spoedig dat alleen code van Dev naar Test wordt verplaatst. Dat komt omdat het idee is dat u op de testserver uw code controleert tegen gegevens die gekopieerd zijn uit de live omgeving.
De testomgeving is nu klaar.
Klik op Bezoek de testsite om te controleren of de testsite er hetzelfde uitziet als de site die wordt uitgevoerd op uw Dev-omgeving. U kunt ook klikken Sitebeheerder om u aan te melden bij uw WordPress-dashboard. Gebruik dezelfde beheerdersreferenties die u hebt gedefinieerd voor WordPress op de Dev-server.
U hebt een zeer eenvoudige WordPress-installatie met een ontwikkel- en testomgeving gemaakt en bent klaar om deze te gaan aanpassen.
Nu u een WordPress-installatie in de cloud uitvoert, wilt u er waarschijnlijk meer mee doen. Je installeert op zijn minst een paar plug-ins en misschien een thema en pas de site aan je eigen smaak aan. In een meer complexe opstelling, zult u uw eigen plug-ins schrijven en misschien een aangepast thema maken om uw site uw eigen te maken.
Daar komen we bij het hart van het werken met een Dev-Test-Live-opstelling.
De configuratie op Pantheon is gebaseerd op versiebeheer: Pantheon houdt je hele WordPress-installatie bij, met uitzondering van bestandsuploads, die worden afgehandeld met behulp van een speciaal bestandssysteem, in een Git-repository. Op deze manier blijft alles altijd synchroon en verliest u nooit uw wijzigingen wanneer u uw wijzigingen in de volgende omgeving implementeert.
Dat betekent ook dat versiebeheer de enige manier is om updates aan de test- en live-omgevingen uit te voeren. U kunt geen plug-ins of thema's op de Live-server installeren zoals u gewend bent wanneer u met WordPress werkt. Dat zou immers het idee van het testen van de installatie breken voordat het live wordt doorgevoerd.
Dus, hoe installeer en update je plug-ins en thema's op je WordPress-site?
U hebt toegang tot de sites van uw site dev omgeving op Pantheon op twee manieren: met Git of direct via SFTP.
Hoewel het gebruik van Git nuttig is voor geavanceerdere use-cases (we zullen het later in de tutorial bekijken), een deel van de schoonheid van de Pantheon-setup is dat je met behulp van SFTP de Dev-omgeving kunt gebruiken als je ontwikkelserver . Op deze manier is het zelfs mogelijk om een ontwikkelserver helemaal niet op uw computer uit te voeren.
De keuze is niet permanent: u kunt schakelen tussen de modi, afhankelijk van wat het beste werkt voor de taak die u moet uitvoeren.
Dus zorg er voor nu voor dat je Dev-omgeving de SFTP Verbindingsmodus:
In de SFTP-modus maak je de codebase van de WordPress-installatie rechtstreeks op de server en als alles er goed uitziet, breng je je wijzigingen in Git vast met behulp van de tools op het Pantheon-dashboard.
Op deze manier kunt u de Dev-site gebruiken zoals u elke WordPress-site zou gebruiken en de site aanpassen met behulp van het WordPress-dashboard, net als bij een enkele serverconfiguratie..
Laten we het in actie proberen.
Selecteer in het WordPress-beheerdersdashboard plugins > Voeg nieuw toe. Selecteer vervolgens een plug-in die u wilt installeren. Als voorbeeld heb ik geïnstalleerd JetPack door WordPress.com:
Activeer nu de plug-in en controleer of deze wordt uitgevoerd zoals verwacht op uw Dev-server.
Als u tevreden bent met de plug-in, keert u terug naar uw Pantheon-dashboard. Daar zie je dat het systeem je wijzigingen heeft opgemerkt en ze laat zien als wijzigingen die klaar zijn om naar versiebeheer te worden geduwd.
Klik op het tekstveld dat zegt Voeg een commit-bericht toe om uw commit-bericht in te voeren en meer details te zien over de wijzigingen die op het punt staan om in versiebeheer te gaan.
Controleer de wijzigingen, voeg een beschrijvend commit-bericht toe en klik op plegen om de veranderingen te plegen.
Nadat de commit is voltooid, zijn de wijzigingen beschikbaar om te worden geïmplementeerd op de testserver. Om dit te doen, klik op de Test tab.
Daar zie je de volgende melding.
Het is de commit die je zojuist op je hebt gemaakt dev omgeving, nu klaar om te worden ingezet Test.
Typ een beschrijvend logbericht en klik op Code van ontwikkeling naar testomgeving implementeren.
Ga vervolgens naar het WordPress-dashboard van uw testsite om de wijzigingen te bekijken.
Op de plugins pagina, ziet u dat de plug-in is geïnstalleerd, maar deze is nog niet actief.
Dat komt omdat op Pantheon, terwijl code wordt bijgewerkt van Dev naar de live server, database-wijzigingen, inclusief informatie over de actieve plug-ins, de andere kant op stromen, van Live naar Dev.
Omdat plug-ins vaak wat code uitvoeren bij activering, is dit voor plug-ins niet slecht. U hoeft alleen te onthouden om uw plug-ins te activeren nadat de implementatie is voltooid en u klaar bent om te gaan. In mijn volgende Pantheon-zelfstudie laat ik zien hoe je dit kunt automatiseren met behulp van het opdrachtregelprogramma van Pantheon.
Hoewel deze aanpak voor plug-ins werkt, zijn er andere gegevens, zoals plugin- en thema-instellingen, die een belangrijk onderdeel vormen van de setup van de site die u waarschijnlijk niet handmatig wilt configureren na de implementatie..
Laten we eens kijken hoe u ze kunt doorgeven van de ene omgeving naar de volgende.
Zoals we ons herinneren, stroomt code of bestanden in versiebeheer van de ontwikkelomgeving naar de live server. Dus, om instellingen op een vergelijkbare manier te verplaatsen, is de meest natuurlijke aanpak om ze op te slaan in versiebeheer.
Om dit te doen, zullen we een gratis WordPress plug-in gebruiken die precies dat doet.
De plug-in, WP-CFM, leest opties uit de WordPress-optietabellen en slaat ze op in een tekstbestand, dat vervolgens kan worden toegewezen aan versiebeheer (onthoud dat de hele WordPress-installatie, met uitzondering van de uploaddirectory, wordt opgeslagen in versiebeheer en wordt gelezen in de andere omgevingen).
Laten we het volgende doen.
Volg de instructies van stap 2 hierboven om de WP-CFM-plug-in te installeren in de Dev-omgeving en deze te gebruiken voor testen. Activeer vervolgens de plug-in in beide omgevingen.
Nu de plug-in actief is in beide omgevingen, kunnen we deze gebruiken om WordPress-opties van Dev naar Test te pushen. Als je wilt, kun je op dit moment enkele WordPress-instellingen aanpassen, zodat je kunt zien hoe de wijzigingen worden toegepast op de testserver (de naam van de site is bijvoorbeeld een vrij zichtbare wijziging).
Klik in het WordPress-dashboard van uw Dev-server op instellingen > WP-CFM.
Klik Voeg bundel toe om een nieuwe instellingenbundel te maken voor versiebeheer. Bundels zijn verzamelingen van instellingen die onafhankelijk van elkaar kunnen worden opgeslagen en geduwd.
Vervolgens wordt u gevraagd de opties te selecteren die u in de bundel wilt opnemen. Als u wilt dat sommige opties van de ene omgeving naar de andere blijven verschillen, kunt u ze in de lijst uitvinken.
In het bovenstaande voorbeeld heb ik alles gekozen WP-opties, behalve de lijst met actieve plug-ins (omdat ik de plug-ins-activeringsscripts in elke omgeving wil kunnen gebruiken), maar je kunt kiezen wat logisch aanvoelt voor je site-instellingen.
Als u tevreden bent met de lijst met opties, klikt u op Wijzigingen opslaan.
Nadat u de bundel hebt opgeslagen, ziet u er nieuwe knoppen voor:
Klik op de diff om de verschillen te zien tussen uw Dev-database en de inhoud van het optiebestand geëxporteerd door WP-CFM.
Omdat WP-CFM nog geen exportbestand heeft gemaakt, zal het diff alles tonen als toegevoegd:
Sluit de Diff-pop-up en klik op Duwen om de gegevens uit de database op te slaan in het exportbestand.
Nu, wanneer u teruggaat naar uw Pantheon-dashboard dev tabblad, ziet u dat WP-CFM een JSON-bestand heeft gemaakt (wp-content / config / site_options.json) klaar om toegewijd te zijn aan versiebeheer:
Breng de wijzigingen tot stand en implementeer ze in de Test milieu.
Ga vervolgens op het WordPress-dashboard van de testserver naar instellingen > WP-CFM.
Ten eerste zult u merken dat het Site-opties bundel is nu ook beschikbaar in deze omgeving.
Vanwege de beperkingen die zijn ingesteld voor de test- en livemilieus, zult u echter ook merken dat de optiespray slechts in één richting werkt: wp-content / config is niet beschrijfbaar in de testomgeving. Dit is geweldig omdat het ons helpt het exportbestand schoon te houden.
Klik op de Trekken om de inhoud van het configuratiebestand te lezen en toe te passen in uw WP-opties tafel. In het bevestigingsvenster met de vraag "Importeer bestandinstellingen naar DB?", Antwoord OK.
Als u enkele wijzigingen in uw WordPress-opties hebt aangebracht voordat u de Push on the Dev-server uitvoert, ziet u dat die wijzigingen ook op de testsite zijn toegepast..
Op een bepaald moment in de levenscyclus van uw site, wilt u misschien de feitelijke gegevens van uw Live-server naar Dev halen. Het zou kunnen zijn om een bug te testen tegen echte gegevens, of gewoon om te zien hoe dingen eruit zien met echte door gebruikers gegenereerde inhoud in plaats van een aantal testgegevens die door u zijn gemaakt, de ontwikkelaar.
Op de dev omgeving, klik op Database / bestanden in het menu aan de linkerkant.
Hier kunt u de omgeving kiezen waarvandaan de gegevens moeten worden gekloond (test / live) en of u alleen de database wilt klonen of ook eventuele bestandsuploads die in die omgeving zijn gemaakt.
U hebt ook de mogelijkheid om URL's in de database bij te werken zodat deze overeenkomen met de URL-structuur van de Dev-omgeving.
Merk op dat het klonen alles in de database van uw Dev-omgeving zal vervangen, dus als u aangepaste wijzigingen hebt die u na het klonen wilt terughalen, gebruikt u WP-CFM om ze in een tekstbestand te duwen voordat u gaat klonen.
Deze functionaliteit is vooral handig voor het ophalen van gegevens van Live en Test naar Dev, maar je kunt het ook gebruiken om de Dev-database te klonen om te testen (en zelfs live). Het kan bijvoorbeeld handig zijn als u uw initiële site-inhoud (pagina's en misschien blogposts) in de Dev-omgeving maakt en deze meteen wilt testen voordat u de Live-omgeving gaat maken.
We hebben nu gekeken naar de basis WordPress-beheertaken, zoals het installeren van nieuwe plug-ins en het pushen van configuratiewijzigingen tussen omgevingen.
Het bijwerken van plug-ins en het installeren van thema's kan op dezelfde manier worden gedaan, volgens dezelfde instructies. Dus, als u al het beheer van uw site uitvoert met behulp van reeds bestaande thema's en plug-ins, is dit zo ongeveer wat u moet weten over de basisbeginselen van Pantheon om er veel gebruik van te maken.
Vaak wilt u de code echter ook zelf wijzigen, bijvoorbeeld door een plug-in te schrijven of door een thema aan te passen en aan te passen..
Om te demonstreren hoe je dit kunt doen, laten we een eenvoudig kindthema maken voor het huidige standaardthema, Twenty Zestien, en het helemaal naar de testsite duwen.
Ga door met het benaderen van het gebruik van de Pantheon Dev-omgeving als uw ontwikkelserver, laten we uw favoriete FTP-client gebruiken om onze codemodificaties te uploaden naar de Dev-server.
Dit is gemakkelijk en we hebben dit waarschijnlijk allemaal wel eens gedaan op andere servers op internet.
Om verbinding te maken met de Pantheon-server, klikt u eerst op het Pantheon-dashboard op de STFP-verbindingsinfo om een popup te openen met informatie over hoe u verbinding kunt maken met uw ontwikkelserver.
Kopieer de Gastheer en Gebruikersnaam informatie naar uw FTP-client en gebruik uw Pantheon Dashboard-wachtwoord om verbinding te maken met de server. Zorg ervoor dat u de Haven gespecificeerd in de verbindingsinstructies.
Nadat u verbinding hebt gemaakt met de server, vindt u de volledige codebase van uw WordPress-site in de directory ~ / Code.
Eenmaal verbonden, kunt u uw FTP-client gebruiken om bestanden te vervangen of nieuwe te uploaden, en de aangebrachte wijzigingen meteen zien op de WordPress-site van uw Dev-server..
Met veel FTP-clients, codebewerkers en PHP IDE's (zoals PHPStorm en Eclipse) kunt u uw codewijzigingen rechtstreeks synchroniseren met een externe server met behulp van SFTP. Door deze tools te gebruiken, kunt u de ontwikkeling nog sneller maken met de extra stap van het uploaden van uw wijzigingen zodat testen automatisch op de achtergrond gebeurt.
Merk op dat de SFTP-URL van uw Dev-server van tijd tot tijd kan veranderen, dus als u merkt dat u geen verbinding kunt maken, vinkt u gewoon de huidige inloggegevens van het Dashboard aan en probeert u het opnieuw.
Laten we als voorbeeld van deze aanpak een eenvoudig kindthema maken voor het standaardthema, Twenty Sixteen. Omdat dit alleen voor demonstratiedoeleinden is, houden we het thema supereenvoudig met niets anders dan een style.css bestand dat de achtergrondkleur van de site wijzigt in rood en a functions.php bestand voor het inruilen van het stylesheet.
Maak op uw computer een map genaamd twentysixteen-kind, en daarbinnen een tekstbestand met de naam style.css.
Binnen style.css voeg de volgende inhoud toe:
/ * Theme Name: Twenty Sixteen Child Beschrijving: Een eenvoudig kindthema Sjabloon: twentysixteen Versie: 0.0.1 Licentie: GNU General Public License v2 of later License URI: http://www.gnu.org/licenses/gpl-2.0. html * / body background-colour: # ff0000;
Maak vervolgens een functions.php bestand met de volgende inhoud:
Upload vervolgens de map samen met de inhoud naar de directory van uw Dev-server ~ / Code / wp-content / themes /.
Nu, wanneer u de Verschijning > Thema's scherm op de WordPress-beheerder van uw Dev-server, ziet u dat het nieuwe thema nu beschikbaar is voor gebruik.
Ga je gang en activeer het!
Wanneer u nu uw Dev-site bezoekt, merkt u dat de achtergrond rood is geworden, net zoals we hebben gedefinieerd in het CSS-bestand van het Child-thema.
U hebt nu een nieuw kindthema geüpload naar uw Dev-server. Zorg er vervolgens voor dat u uw wijzigingen niet kwijtraakt en dat u deze kunt implementeren op de testserver. U moet dan uw wijzigingen toewijzen aan versiebeheer..
Wanneer u uw site rechtstreeks met behulp van SFTP in de Dev-omgeving ontwikkelt, is het belangrijk om te onthouden dat voordat u de wijzigingen in Git op uw Pantheon-dashboard vastlegt, deze niet worden opgeslagen in versiebeheer. Zorg ervoor dat u uw belangrijke wijzigingen niet kwijtraakt, vergeet niet om het vaak te doen, zelfs als u nog niet klaar bent om uw wijzigingen in Test te pushen..
Op het Dashboard-tabblad van de Dev-omgeving zul je merken dat je een aantal niet-gecommitteerde wijzigingen hebt die gereed zijn om te worden vastgelegd.
Typ een commit-bericht en klik op plegen.
In de bovenstaande schermafbeelding ziet u ook dat er wijzigingen zijn in de site_options.json bestand gemaakt door WP-CFM. Dat komt omdat ik de informatie over het activeren van het thema naar dat configuratiebestand heb gepusht. Op deze manier wordt het nieuwe thema bijna automatisch geactiveerd. Hoewel dit niet nodig is in dit eenvoudige voorbeeld, is het een goede gewoonte om te kiezen met het oog op de toekomst en eventuele complexere themainstellingen die u mogelijk aan het bouwen bent..
Nadat u de wijzigingen hebt doorgevoerd, implementeert u ze om te testen met behulp van de stappen die eerder zijn uitgelegd toen we onze plug-ins implementeerden. Als u vervolgens met behulp van WP-CFM de site-optiesbundel hebt gepusht, gebruikt u de plug-in om de wijzigingen in de database van de testsite over te brengen.
Nu, wanneer u de testomgeving bezoekt Verschijning > Thema's pagina, zou u het nieuwe thema als het actieve thema moeten zien.
Als u duidelijkere controle over de codebase wilt hebben en uw ontwikkel- en ontwikkelaarstests liever uitvoert op uw lokale computer, kunt u uw code naar de Dev-server sturen met de Git-versie zelf in plaats van eerst de wijzigingen via FTP op de server te uploaden.
Om dit te doen, opnieuw op de Dev-server Code tab, schakel het Verbindingsmodus van SFTP naar Git.
Als u niet-gecommiteerde wijzigingen aanbrengt op de Dev-server wanneer u overschakelt naar Git-modus, ziet u een pop-up waarin u wordt gevraagd om te bevestigen dat u de switch wilt uitvoeren en de wijzigingen wilt verliezen.
Als u de wijzigingen wilt behouden, sluit u de melding en commit voordat u doorgaat met het wijzigen van de modus. Als u de wijzigingen niet nodig hebt, typt u DELETE in het tekstveld en klik op de grote rode knop.
Git-authenticatie op Pantheon gebeurt met een SSH-sleutel, dus voordat je verder gaat, moet je een sleutel genereren en deze toevoegen aan je account. Je kunt dezelfde SSH-sleutel gebruiken voor al je Pantheon-sites, dus je hoeft dit maar één keer te doen.
Met je SSH-sleutel kun je werken met je WordPress-installatie met Git.
Klik op de Git Connection Info
Accentsconagua