Share
Idag har WordPress 25% av världens webbplatser, så det är säkert att säga att det som började som bloggarprogramvara har vuxit till något mycket större än sitt ödmjuka ursprung och är redo att användas på produktionsnivåer från nyhetsportaler till kompletta webbapplikationer.
Med denna nivå av professionalism uppstår nya behov.
På en personlig blogg som läses av vänner och familj kommer en bruten pluginuppdatering inte att orsaka mycket mer än liten irritation - troligtvis kommer dina läsare inte ens att se misstaget. När du arbetar framför hundratusentals besökare kommer emellertid ett sådant fel att märkas omedelbart, och du kommer inte att komma undan med det så lätt.
"Det fungerade på min dator" Det kan vara sant, men det kommer inte att göra den frustrerade kunden lyckligare.
Det är därför som du bygger en professionell WordPress-webbplats för en större publik, behöver du en värduppsättning som hjälper dig att se till att dina uppdateringar är säkra och aldrig bryta levnadsmiljön.
Så, hur ser du till att din server inte kommer att bryta när du trycker på en ny uppdatering live, det är en ny version av ditt tema eller en uppdatering till en eller flera av dina pluginprogram?
Genom att testa i en miljö som är identisk med live-servern innan du trycker på dina ändringar live.
Inställningen börjar med a utvecklingsserver som du använder för ditt vardagliga arbete på produkten: utvecklare testning, presentera tidiga förändringar till kunder, och så vidare. Den här servern kan köra på din dator eller en server i molnet.
När du är nöjd med hur saker ser ut på utvecklingsservern, i denna inställning kommer du inte att skynda för att driva din kod live. I stället begår du dina ändringar i versionskontroll och distribuerar dem till en testserver.
Eftersom testmiljön kör serverprogramvara som är identisk med programvaran på live-servern, förutom att den nya koden inte har uppdaterats till live-servern ännu, kan du använda den för att upptäcka eventuella problem som kan uppstå på servern men inte på din utvecklingsmiljö. För att göra testningen ännu mer realistisk och upptäcka fel som orsakas av data som skrivs in av dina kunder, kan du även fylla i testdatabasen med verkliga data från din live-server.
På testservern ser du till att allt fungerar som det ska genom att testa webbplatsen manuellt eller genom att köra automatiska tester eller en kombination av de två. Och först då, när testen slutförs framgångsrikt, tryck ändringarna live. Med förtroende, vetande att förändringarna inte kommer att bryta din webbplats.
Medan Dev-Test-Live-tillvägagångssättet är välkänt bland mjukvaruföretag som bygger tjänster på nätet har det traditionellt varit begränsat till utvecklare och företag med resurser att driva och hantera flera servrar på egen hand och för att hålla dem synkroniserade med samma server mjukvara och data.
Det innebär att betala för många servrar, men också mycket underhållsarbete.
På Pantheon kommer detta tillvägagångssätt inbyggt i tjänsten.
Pantheon är en skalbar, snabb WordPress och Drupal webbtjänst som inte bara gör det möjligt för dig att testa din kod på en testserver innan du trycker på den, men tvingar ganska mycket på att du följer de bästa rutinerna i alla dina implementeringar.
I denna handledning lär du dig att skapa en WordPress-webbplats på Pantheon och utveckla och underhålla den säkert med Dev-Test-Live-arkitekturen och versionskontrollen.
Låt oss börja!
Nu när du vet vad vi ska bygga (och varför) är det dags att komma igång.
En av de fantastiska sakerna om Pantheon är dess prissättningsmodell: du betalar bara när din webbplats går live, så du kan prova allt och till och med visa din webbplats till vänner och kunder innan du måste betala för ditt konto.
Gå först till Pantheons webbplats och skapa ditt gratis konto.
Om ditt arbete består av att skapa webbplatser för en massa kunder, eller om du har ett team utvecklare som arbetar med dig, kan du registrera dig som en byrå. Byråer har samma prissättning men får även några extrafunktioner som Multidev, som gör att du kan gaffla en webbplats i flera utvecklingsmiljöer för att underlätta samarbete och bygga upp och visa nya funktioner utan att behöva uppdatera den primära miljön.
Om du inte är säker på vilken typ av konto som passar dig, gå bara med standarden. Du kan alltid konvertera ditt konto till ett agentkonto senare.
När du är inloggad visas följande vy:
Klicka på Skapa ny webbplats att börja bygga din första WordPress-webbplats på Pantheon.
På den här skärmen väljer du ett namn på din webbplats på Pantheon: namnet används i din Pantheon-admin och för att generera dina miljöers webbadresser. Du kan inte ändra det här namnet senare, så det är bra att tänka på det, men oroa dig inte - det behöver inte vara detsamma som ditt WordPress-webbplatsens sista namn.
Namnen är globala över Pantheon, så att välja något mycket generiskt kan leda till ett fel. I så fall försök något annat.
Efter att ha valt namnet klickar du på Skapa webbplats.
Därefter kommer du att bli ombedd att välja startstatus för din nya sajt. Du kan antingen starta en ny webbplats från början eller importera en befintlig Drupal eller WordPress-webbplats:
Välja Börja från början.
Nedanför valet ser du en lista med olika startpaket eller uppströms, som de kallas på Pantheon.
Dessa standardupstreams upprätthålls av Pantheon så att när en ny uppdatering blir tillgänglig för en som du använder (WordPress, i vårt fall), kan du enkelt uppdatera dem till din webbplats via Pantheon Dashboard.
När vi skapar en WordPress-webbplats klickar du på Installera WordPress.
Installationen börjar. Och efter ett tag är det klart.
Klicka på Besök din Pantheon Dashboard knapp.
Nu har du en helt ny WordPress-installation som körs på en Pantheon-utvecklingsserver och kan komma åt och styra den via Pantheon Dashboard.
Överst på skärmen ser du tre flikar för de olika serverns miljöer: dev, Testa, och leva. Under varje flik hittar du en liknande menystruktur för att behålla den servern och distribuera kod och data mellan miljöer:
Klicka på Webbplatsadministratör knappen längst upp till vänster på skärmen. Det leder dig genom ditt vanliga WordPress installationsflöde:
Du kan också klicka på Besök utvecklingswebbplatsen knappen för att visa webbplatsen.
Nu när din utvecklingsmiljö är igång, låt oss ta en titt på de andra två miljöerna.
Som vi såg ovan, hittar du på fliken Pantheon för de tre serverns miljöer: dev, Testa, och leva.
Var och en av flikarna representerar en av de serverns miljöer som kör din webbplats. dev är utvecklingsmiljön för testning när du arbetar på webbplatsen, och kanske visar en tidig version av webbplatsen till kunderna. leva är den version av webbplatsen som är igång och används av faktiska användare.
Mellan de två är Testa, miljön som håller din levande webbplats relativt säker från dina misstag. Innan du kan trycka någonting live på Pantheon, måste det alltid gå igenom en Testa miljö så att du får en sista chans att kontrollera att allt fungerar korrekt innan du skickar din kod till det vilda.
När vi just skapat den nya WordPress-webbplatsen finns den fortfarande bara i utvecklingsmiljön.
Låt oss skapa en testmiljö för den.
Klicka på Testa flik.
Eftersom det här är din första gång på Testa fliken, ser du lite information om hur testmiljön fungerar.
Klicka på Skapa testmiljö att klona din Dev-miljö för testning. I det här skedet klonas både koden och data från Dev eftersom det inte finns någon levande miljö än. I framtida uppdateringar, liksom även snart, flyttas endast kod från Dev to Test. Det beror på att idén är att på testservern ska du kolla din kod mot data som kopieras från den levande miljön.
Testmiljön är nu klar.
Klicka på Besök testwebbplatsen för att kontrollera att testplatsen ser ut precis som webbplatsen som körs på din Dev-miljö. Du kan också klicka på Webbplatsadministratör att logga in på din WordPress dashboard. Använd samma administratörsuppgifter som du definierade för WordPress på Dev-servern.
Du har skapat en mycket grundläggande WordPress-installation med en utvecklings- och testmiljö och är redo att börja anpassa den.
Nu när du har en WordPress-installation som körs i molnet, vill du förmodligen göra något mer med det. Åtminstone installerar du några plugins och kanske ett tema och anpassar webbplatsen så att den passar din smak. I en mer komplex inställning skriver du dina egna plugins och skapar kanske ett anpassat tema för att göra din webbplats din egen.
Det är här vi kommer till hjärtat av att arbeta med en Dev-Test-Live-installation.
Installationen på Pantheon bygger på versionskontroll: Pantheon håller hela WordPress-installationen, förutom filuppladdningar, som hanteras med ett speciellt filsystem, i ett Git-arkiv. På det här sättet, när du distribuerar dina ändringar till nästa miljö, förblir allt alltid synkroniserat och du förlorar aldrig dina ändringar.
Det betyder också att det enda sättet att göra uppdateringar i test- och levnadsmiljöerna är genom versionskontroll. Du kan inte installera plugins eller teman på Live-servern så som du förmodligen är van vid när du arbetar med WordPress. Det skulle trots allt bryta idén om att testa inställningen innan du trycker på den.
Så, hur installerar du och uppdaterar plugins och teman på din WordPress-webbplats?
Du kan komma åt din webbplats dev miljö på Pantheon på två sätt: Använd Git eller direkt över SFTP.
Medan du använder Git är användbar för några mer avancerade användningsfall (vi tar en titt på det senare i handledningen), en del av skönheten i Pantheon-inställningen är att med hjälp av SFTP kan du använda Dev-miljön som din utvecklingsserver . På så sätt kan du hoppa över att ha en utvecklingsserver som körs på din dator alls.
Valet är inte permanent: du kan byta mellan lägena beroende på vad som passar bäst för uppgiften.
Så, för nu, se till att din Dev-miljö använder SFTP anslutningsläge:
I SFTP-läget gör du dina ändringar i WordPress-installationsens kodbas direkt på servern och sedan, när allt ser bra ut, begår du ändringarna till Git med hjälp av verktygen på Pantheon-instrumentpanelen.
På så sätt kan du använda Dev-webbplatsen som du skulle använda någon WordPress-webbplats och anpassa webbplatsen med hjälp av WordPress-instrumentpanelen precis som du skulle göra på en enda serverinstallation.
Låt oss försöka göra det.
I WordPress-kontrollpanelen väljer du plugins > Lägg till ny. Välj sedan ett plugin som du vill installera. Som ett exempel installerade jag JetPack av WordPress.com:
Aktivera nu pluginet och kontrollera att det körs som förväntat på din Dev-server.
När du är nöjd med pluginet, återgå till din Pantheon Dashboard. Där ser du att systemet har märkt dina ändringar och visar dem som ändringar redo att skjutas till versionskontroll.
Klicka på det textfält som säger Lägg till ett commit-meddelande för att ange ditt engagemang och för att se några detaljer om de förändringar som ska gå till versionskontroll.
Kontrollera ändringarna, lägg till ett beskrivande commit-meddelande och klicka på Begå att begå ändringarna.
När engagemanget har slutförts är ändringarna tillgängliga för att distribueras till testservern. För att göra detta klickar du på Testa flik.
Där ser du följande meddelande.
Det är det engagemang du gjort just på din dev miljö, nu redo att distribueras till Testa.
Skriv ett beskrivande loggmeddelande och klicka på Distribuera kod från utveckling till testmiljö.
Därefter besöker du testplatsens WordPress Dashboard för att kontrollera ändringarna.
På plugins sidan ser du att plugin har installerats, men det är inte aktivt än.
Det beror på att Pantheon, medan kod uppdateras från Dev upp mot live-servern, ändras databasförändringar, inklusive information om de aktiva plugins, från Live till Dev.
Eftersom plugins ofta kör någon kod vid aktivering, för plugins, är det inte dåligt. Du behöver bara komma ihåg att aktivera dina plugins efter att implementeringen har slutförts och du är redo att gå. I min nästa Pantheon-handledning visar jag hur du kan automatisera detta med Pantheons kommandoradsverktyg.
Men medan detta tillvägagångssätt fungerar för plugins, finns det andra data, till exempel plugin och temainställningar, som utgör en viktig del av webbplatsens inställning som du förmodligen inte vill konfigurera manuellt efter installationen.
Låt oss titta på hur du kan skicka dem från en miljö till nästa.
Som vi kommer ihåg, körs kod- eller filer i versionsstyrning upp från utvecklingsmiljön mot live-servern. Så, för att flytta inställningarna på ett liknande sätt, är det mest naturliga sättet att lagra dem i versionskontroll.
För att göra detta använder vi ett gratis WordPress-plugin som gör just det.
Plugin, WP-CFM, läser alternativ från WordPress-alternativtabellerna och lagrar dem i en textfil, som sedan kan användas för versionskontroll (kom ihåg att hela WordPress-installationen - förutom uppladdningsmappen - lagras i versionskontroll och läses i andra miljöer).
Låt oss göra det här nästa.
Följ anvisningarna från steg 2 ovan för att installera WP-CFM-plugin i Dev-miljön och för att distribuera den till Test. Aktivera sedan pluginet i båda miljöerna.
Nu när pluginet är aktivt i båda miljöerna kan vi använda det för att trycka på WordPress-alternativ från Dev to Test. Om du vill kan du ändra vissa WordPress-inställningar vid den här tiden så att du kan se hur ändringarna tillämpas på testservern (webbplatsens namn är till exempel en ganska synlig förändring).
Klicka på på din Dev-serverens WordPress-instrumentpanel inställningar > WP-CFM.
Klick Lägg till Bundle för att skapa en ny inställningsbunt för versionsstyrning. Bundlar är samlingar av inställningar som kan sparas och drivas oberoende av varandra.
Därefter uppmanas du att välja vilka alternativ du vill inkludera i buntet. Om du vill behålla vissa alternativ olika från en miljö till nästa kan du avmarkera dem i listan.
I exemplet ovan valde jag allting i WP-alternativ, förutom listan över aktiva plugins (eftersom jag vill kunna köra pluginaktiveringsskripten i varje miljö), men du kan välja vad som är logiskt med din webbplatsinställning.
När du är nöjd med listan över alternativ klickar du på Spara ändringar.
När du har sparat buntet ser du nya knappar för det:
Klicka på Diff knappen för att se skillnaderna mellan din Dev-databas och innehållet i alternativfilen som exporteras av WP-CFM.
Eftersom WP-CFM inte har skapat en exportfil ännu, visar diffen allt som läggs till:
Stäng Diff-popupen och klicka Tryck för att lagra data från databasen till exportfilen.
Nu när du går tillbaka till din Pantheon instrumentpanel dev fliken ser du att WP-CFM har skapat en JSON-fil (wp-innehåll / config / site_options.json) redo att vara förpliktad till versionskontroll:
Förbind ändringarna och använd dem till Testa miljö.
Därefter navigerar du på testserverns WordPress-instrumentpanel till inställningar > WP-CFM.
Först märker du att Webbplatsalternativ bunt är nu också tillgängligt i denna miljö.
På grund av de begränsningar som ställts in i test- och levnadsmiljöerna märker du dock att alternativpaketet bara fungerar i en riktning: wp-innehåll / config kan inte skrivas på testmiljön. Det här är bra eftersom det hjälper oss att hålla exportfilen ren.
Klicka på Dra knappen för att läsa innehållet i konfigurationsfilen och tillämpa dem i din WP-alternativ tabell. I bekräftelse popup som frågar "Importera filinställningar till DB?", Svara ok.
Nu, om du gjort några ändringar i dina WordPress-alternativ innan du gör Push på Dev-servern, bör du se de ändringarna som också tillämpas på testplatsen.
Vid någon tidpunkt i din webbplats livscykel kanske du vill ta de faktiska data från din Live-server till Dev. Det kan vara att testa en bugg mot verkliga data, eller bara för att se hur sakerna ser ut med verkligt användargenererat innehåll istället för några testdata skapade av dig, utvecklaren.
På dev miljö, klicka på Databas / Filer i menyn till vänster.
Här kan du välja den miljö för att klona data (test / live) och om du vill klona bara databasen eller också filuppladdningar som gjorts i den miljön.
Du har också möjlighet att uppdatera alla webbadresser i databasen för att matcha Dev-miljöens webbadressstruktur.
Observera att kloningen kommer att ersätta allt i din Dev-miljöens databas, så om du har några anpassade ändringar som du vill återkomma efter kloningen, använd WP-CFM för att trycka dem in i en textfil innan du klonar.
Denna funktion är mest användbar för att dra data från Live och Test to Dev, men du kan också använda den för att klona Dev-databasen till Test (och även Live). Det kan vara användbart till exempel om du skapar ditt ursprungliga webbplatsinnehåll (sidor och kanske blogginlägg) på Dev-miljön och vill trycka på det för att testa omedelbart innan du skapar Live-miljön.
Vi har nu tittat på de grundläggande WordPress-hanteringsuppgifterna som att installera nya plugins och driva konfigurationsförändringar mellan miljöer.
Uppdatering av plugins och installation av teman kan göras på samma sätt, enligt samma instruktioner. Så om du gör hela webbplatsens hantering med hjälp av befintliga teman och plugins, så är det ganska mycket vad du behöver veta om grunderna i Pantheon för att göra stor nytta av det.
Ofta vill du också ändra koden själv, vare sig du skriver ett plugin eller genom att ändra och anpassa ett tema.
För att visa hur du kan göra det här, låt oss skapa ett enkelt barntema för det aktuella standardtemat, tjugosjätton och trycka hela vägen till testplatsen.
Vi fortsätter med att använda Pantheon Dev-miljön som din utvecklingsserver, låt oss använda din favorit FTP-klient för att ladda upp våra kodändringar till Dev-servern.
Det här är enkelt, och vi har alla noga gjort det på en eller annan gång på andra servrar på internet.
För att ansluta till Pantheon-servern, först på Pantheon Dashboard, klicka på STFP-anslutningsinfo knappen för att öppna en popup med information om hur du ansluter till din utvecklingsserver.
Kopiera Värd och Användarnamn information till din FTP-klient och använd ditt Pantheon Dashboard-lösenord för att ansluta till servern. Se till att du använder Hamn specificerat i anslutningsanvisningarna.
När du är ansluten till servern hittar du din WordPress-webbplatsens hela kodbas i katalogen ~ / Kod.
När du är ansluten kan du använda din FTP-klient för att ersätta filer eller ladda upp nya och se ändringarna som tillämpas direkt på din Dev-serverns WordPress-webbplats.
Många FTP-klienter, kodredigerare och PHP-IDE (till exempel PHPStorm och Eclipse) låter dig synkronisera dina kodändringar direkt med en fjärrserver med SFTP. Genom att använda dessa verktyg kan du göra utvecklingen ännu snabbare med det extra steget att ladda upp dina ändringar för att testningen ska ske automatiskt i bakgrunden.
Observera att din Dev-serverens SFTP-URL kan ändras från gång till gång, så om du inte kan ansluta, kolla bara de aktuella anslutningsuppgifterna från instrumentpanelen och försök igen.
Som ett exempel på detta tillvägagångssätt, låt oss skapa ett enkelt barntema för standardtemat, tjugoseksten. Eftersom det här bara är för demonstration, kommer vi att hålla temat super enkelt med ingenting annat än a style.css fil som ändrar webbplatsens bakgrundsfärg till röd och a functions.php filen för att skriva in stilarket.
På din dator, skapa en katalog som heter twentysixteen-barn, och inuti den, en textfil med namnet style.css.
Inuti style.css lägg till följande innehåll:
/ * Tema Namn: Tjugosexton Barn Beskrivning: Ett enkelt barntema Mall: Twentysixteen Version: 0.0.1 Licens: GNU General Public License v2 eller senare Licens URI: http://www.gnu.org/licenses/gpl-2.0. html * / body background-color: # ff0000;
Skapa sedan en functions.php fil med följande innehåll:
Ladda sedan katalogen tillsammans med innehållet till din Dev-serverns katalog ~ / Code / wp-content / themes /.
Nu när du besöker Utseende > teman skärm på din Dev-serverens WordPress-admin, ser du att det nya temat nu är tillgängligt för användning.
Gå vidare och aktivera det!
Nu när du besöker din Dev-webbplats kommer du att märka att dess bakgrund har blivit röd, precis som vi definierade i barntemaets CSS-fil.
Du har nu laddat upp ett nytt barntema till din Dev-server. För att försäkra dig om att du inte förlorar dina ändringar och för att kunna distribuera den till testservern måste du begå dina ändringar i versionskontroll.
När du utvecklar din webbplats direkt på Dev-miljön med SFTP, är det viktigt att komma ihåg att innan du begår ändringarna till Git på din Pantheon Dashboard, lagras de inte i versionskontroll. Så, för att du inte kommer att förlora några av dina viktiga förändringar, glöm inte att begå ofta - även om du inte är redo att driva dina ändringar till testet.
På Dev-miljöens Dashboard-flik märker du att du har några obestämda ändringar redo att bli begåvade.
Skriv in ett commit-meddelande och klicka på Begå.
I skärmbilden ovan kommer du också att märka att det finns ändringar i site_options.json fil skapad av WP-CFM. Det beror på att jag tryckte på informationen om att aktivera temat till den konfigurationsfilen. På så sätt aktiveras det nya temat nästan automatiskt. Även om detta inte är nödvändigt i det här enkla exempelfallet är det en bra praxis att anta övervägande i framtiden och mer komplicerade tematillställningar du kanske bygger.
När du har begått ändringarna ska du distribuera dem till Test med hjälp av de steg som förklarades tidigare när vi installerade våra plugininstallationer. Om du sedan trycker på platsalternativpaketet med WP-CFM använder du plugin-modulen för att dra ändringarna till testwebbplatsens databas.
Nu när du besöker testmiljön Utseende > teman sida ska du se det nya temat som det aktiva temat.
Om du vill ha tydligare kontroll över kodbasen och föredrar att göra din utveckling och utvecklare testning på din lokala maskin, kan du trycka din kod till Dev-servern med hjälp av Git-versionen, kontrollera dig själv istället för att först ladda upp ändringarna till servern över FTP.
För att göra det, igen på Dev-serverns Koda fliken, byt ut Anslutningsläge från SFTP till Git.
Om du har några obeställda ändringar på Dev-servern när du växlar till Git-läget kommer du att se en popup som ber dig att bekräfta att du vill göra omkopplaren och förlora ändringarna.
Om du vill behålla ändringarna stänger du notifieringen och begår innan du fortsätter med att byta läge. Om du inte behöver ändringarna skriver du in RADERA i textfältet och klicka på den stora röda knappen.
Git-autentisering på Pantheon görs med en SSH-nyckel, så innan du fortsätter behöver du skapa en nyckel och lägga till den i ditt konto. Du kan använda samma SSH-nyckel för alla dina Pantheon-webbplatser, så du behöver bara göra det här en gång.
Med din SSH-nyckel på plats kan du börja arbeta med din WordPress-installation med hjälp av Git.
Klicka på Git Connection Info knappen på Dev-miljön för att avslöja exakt git klon kommando att använda för att dra din webbplats Git-förvar till din lokala dator.
Springa det git klon kommandot på kommandoraden, i en katalog där du vill lagra koden på din dator. Om du föredrar att använda ett grafiskt användargränssnitt är det också bra: du kan fortsätta använda din favorit Git-klient.
När du har klonat Git-förvaret ser du att katalogen innehåller hela WordPress-installationen.
För att testa att arbeta med Git, gör en liten ändring av det barntema som vi skapade i de föregående stegen.
Ändra barntematets style.css, ändra bakgrundsfärgen till grön istället för röd. Sedan begå ändringen till git.
I projektkatalogen skriver du följande kommandon på kommandoraden:
$ git lägg till wp-innehåll / teman / twentysixteen-child / style.css $ git commit -m "Ändrade barntemaets bakgrundsfärg" $ git push origin master
När push-kommandot har slutförts, besök Pantheon Dashboard.
Där hittar du din ändring som anges i commit-loggen, och när du besöker webbplatsen ser du att bakgrunden har blivit grön.
Så den förändring du gjorde är nu närvarande på Dev-servern men också redo att distribueras till testmiljön.
På ett sätt kan du använda den här metoden för att helt enkelt förbikoppa Dev-servern (kör utveckling på din lokala dator och använda Pantheon för bara test- och levnadsmiljöer) eller som ett annat sätt att ladda upp kod till din utvecklingsserver.
Det är allt u
Accentsconagua