WordPress-innehåll ändras snabbt. Sedan frågar någon: ”Vad ändrade vi förra veckan?” och du fastnar i att gräva igenom versioner, skärmdumpar eller halvt ihågkomna redigeringar.
Innehållsansvariga märker det när godkännanden blir röriga. Marknadsansvariga stöter på det när flera personer rör samma inlägg. Och byråteam får skulden när en kund svär att ett stycke ”brukade vara där”. Det här arbetsflödet för WordPress GitHub-backuper ger dig en felfri, versionshanterad historik som du faktiskt kan lita på.
Du får se hur automatiseringen hämtar inlägg från WordPress, gör om dem till filer, kontrollerar vad som ändrats och committar uppdateringar till GitHub så att du kan granska diffar eller rulla tillbaka snabbt.
Problemet: innehållshistoriken i WordPress blir otydlig
WordPress-versioner hjälper, tills de inte gör det. De är svåra att överblicka snabbt, inte optimala för teamflöden och de matchar sällan hur ni redan hanterar ”riktiga” förändringar i resten av verksamheten. Samtidigt är innehållsuppdateringar inte små. Först en rubrikjustering, sedan ett CTA-byte, sedan en compliance-ändring, och plötsligt läser hela inlägget annorlunda. När något går fel (trafiken droppar, juridik flaggar ett påstående, en produktdetalj ändras) måste du snabbt kunna svara på en enkel fråga: vad ändrades, och när?
Friktionen växer. Här är var det faller isär i det dagliga arbetet.
- Du slutar med att kopiera och klistra in inlägg i dokument eller Slack-trådar bara för att få till grundläggande granskning och godkännande.
- Små ändringar slinker igenom utan insyn, vilket gör att teamet argumenterar utifrån minnet i stället för fakta.
- Att rulla tillbaka blir stressigt eftersom ”revert” ofta innebär att du också backar andra bra ändringar som gjorts efteråt.
- När flera inlägg uppdateras under en vecka blir det en återkommande tidstjuv att spåra ändringar mellan dem.
Så fungerar automatiseringen
Hela n8n-arbetsflödet, från trigger till slutresultat:
n8n Workflow Template: WordPress och GitHub för versionshanterade backuper
flowchart LR
subgraph sg0["Execute Workflow Flow"]
direction LR
n0@{ icon: "mdi:swap-vertical", form: "rounded", label: "Return", pos: "b", h: 48 }
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Get File"]
n2@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If file too large", pos: "b", h: 48 }
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Merge Items"]
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>isDiffOrNew"]
n5@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Check Status", pos: "b", h: 48 }
n6@{ icon: "mdi:cog", form: "rounded", label: "Same file - Do nothing", pos: "b", h: 48 }
n7@{ icon: "mdi:cog", form: "rounded", label: "File is different", pos: "b", h: 48 }
n8@{ icon: "mdi:cog", form: "rounded", label: "File is new", pos: "b", h: 48 }
n9["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Create new file"]
n10["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Edit existing file"]
n11["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Get file data"]
n12@{ icon: "mdi:swap-vertical", form: "rounded", label: "Globals", pos: "b", h: 48 }
n13@{ icon: "mdi:play-circle", form: "rounded", label: "Execute Workflow Trigger", pos: "b", h: 48 }
n14@{ icon: "mdi:swap-vertical", form: "rounded", label: "/", pos: "b", h: 48 }
n15@{ icon: "mdi:swap-horizontal", form: "rounded", label: "tag?", pos: "b", h: 48 }
n14 --> n12
n15 --> n14
n15 --> n12
n12 --> n11
n1 --> n3
n8 --> n9
n3 --> n4
n4 --> n5
n5 --> n6
n5 --> n7
n5 --> n8
n11 --> n2
n9 --> n0
n7 --> n10
n2 --> n1
n2 --> n3
n10 --> n0
n6 --> n0
n13 --> n3
n13 --> n15
end
subgraph sg1["Manual Flow"]
direction LR
n16@{ icon: "mdi:play-circle", form: "rounded", label: "Manual Trigger", pos: "b", h: 48 }
n17["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/wordpress.svg' width='40' height='40' /></div><br/>Get All WP Posts"]
n18["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Format JSON"]
n19@{ icon: "mdi:cog", form: "rounded", label: "Execute Workflow", pos: "b", h: 48 }
n20@{ icon: "mdi:play-circle", form: "rounded", label: "Schedule Trigger", pos: "b", h: 48 }
n18 --> n19
n16 --> n17
n17 --> n18
n20 --> n17
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n13,n16,n20 trigger
class n2,n5,n15 decision
class n1 api
class n4,n18 code
classDef customIcon fill:none,stroke:none
class n1,n3,n4,n9,n10,n11,n17,n18 customIcon
Lösningen: synka WordPress-inlägg till GitHub som versionshanterade filer
Det här n8n-arbetsflödet hämtar dina WordPress-artiklar enligt schema (eller när du kör det manuellt), konverterar varje inlägg till en konsekvent JSON-payload och lagrar sedan innehållet i ett GitHub-repo som filer. Innan det skriver något kontrollerar det om en matchande fil redan finns, hämtar den aktuella versionen och jämför den med hur WordPress ser ut just nu. Om inget har ändrats gör det ingenting. Om något har ändrats committar det en uppdaterad fil. Om det är helt nytt skapar det filen för första gången. Resultatet är en Git-liknande innehållstidslinje som du kan diff:a, granska och rulla tillbaka utan gissningar.
Arbetsflödet startar med WordPress som källa till sanningen. Sedan utvärderar n8n filmetadata i GitHub, hämtar den befintliga filen vid behov och upptäcker ändringar innan det bestämmer om det ska skapa, uppdatera eller hoppa över. Till sist skriver det resultatet tillbaka till GitHub och returnerar en felfri statusutdata för dina loggar.
Det du får: automatisering vs. resultat
| Det här arbetsflödet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut i praktiken
Säg att du publicerar eller uppdaterar 20 inlägg i månaden och att du ”backar upp” innehåll genom att kopiera det till ett dokument och spara en daterad export. Även vid cirka 10 minuter per inlägg blir det runt 3 timmar monotont arbete, plus den mentala belastningen med att namnge filer och hålla ordning på mappar. Med det här arbetsflödet är ”efter”-läget i princip noll: du låter schematriggaren köra, n8n bearbetar inlägg i batchar och GitHub lagrar varje version automatiskt. Du öppnar bara GitHub när du faktiskt behöver granska en diff eller återställa en äldre version.
Det här behöver du
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
- WordPress som källa för inlägg och innehåll.
- GitHub för att lagra versionshanterade filer och diffar.
- GitHub personal access token (skapa den i GitHub Developer Settings).
Kunskapsnivå: Medel. Du kopplar WordPress och GitHub och verifierar sedan repo-sökvägar, taggar och inloggningsuppgifter.
Vill du inte sätta upp det här själv? Prata med en automationsexpert (kostnadsfri 15-minuters konsultation).
Så fungerar det
Ett schema (eller manuell körning) startar backupen. Arbetsflödet kan köras via Scheduled Start för löpande skydd eller via Manual Start när du vill testa det eller köra en engångsinhämtning.
WordPress-artiklar hämtas och normaliseras. n8n hämtar dina inlägg och ett kodsteg förbereder en JSON-payload så att varje inlägg får samma struktur innan det når GitHub.
Arbetsflödet kontrollerar vad som redan finns i GitHub. Det bygger en sökväg (inklusive valfri taggbaserad struktur), sätter repo-kontext, hämtar filmetadata och hämtar bara filinnehåll från GitHub när det behövs för jämförelse.
Ändringar upptäcks och skrivs felfritt. Ett jämförelsesteg avgör om det inte finns någon ändring, en modifierad fil eller en helt ny fil, och GitHub-noder uppdaterar antingen den befintliga filen eller skapar en ny.
Du kan enkelt justera logiken för taggmappar så att den matchar dina kategorier, författare eller inläggstyper utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera triggertypen
Det här arbetsflödet kan köras manuellt, enligt ett schema eller när det anropas som ett underarbetsflöde. Konfigurera alla tre ingångspunkter så att automatiseringen kan startas från olika sammanhang.
- Öppna Manual Start och behåll den som manuell trigger för ad hoc-testning.
- Öppna Scheduled Start och ställ in schemaregeln så att den körs vid
triggerAtHour: 17. - Öppna Incoming Workflow Trigger och ställ in Input Source på
passthroughså att underarbetsflöden kan skicka data vidare in i backup-flödet.
Steg 2: Anslut WordPress
Hämta alla WordPress-inlägg som källdata för backup-processen.
- Lägg till eller öppna Retrieve WP Articles och ställ in Operation på
getAll. - Aktivera Return All genom att sätta den till
true. - Inloggningsuppgifter krävs: Anslut era wordpressApi-uppgifter.
Steg 3: Konfigurera bearbetning och körning av underarbetsflöde
Förbered JSON-payloaden och skicka varje post vidare till underarbetsflödet för hantering av backup.
- Öppna Prepare JSON Payload och bekräfta att JavaScript-koden lägger till fältet
myNewFieldpå varje item. - Öppna Run Sub-Workflow (Configure Required) och behåll Mode inställt på
eachså att varje item körs oberoende. - I Run Sub-Workflow (Configure Required) väljer ni målflödet i Workflow (fältet är för närvarande tomt och måste anges).
Steg 4: Konfigurera taggroutning och repository-kontext
Bygg en taggbaserad sökväg och ställ in repository-identifierare som används av GitHub-operationer.
- Öppna Check Tag Presence och verifiera att den kontrollerar
{{ $json.tags[0] }}för existens med två utgångar (tagochnone). - I Build Tag Path ställer ni in tags[0].name till
{{ $('Incoming Workflow Trigger').item.json.tags[0].name }}/. - I Set Repository Context ställer ni in repo.owner till
[YOUR_ID]och repo.name till[YOUR_ID]. - I Set Repository Context ställer ni in repo.path till
=workflows/{{ $json.tags[0].name }}så att filer sparas under taggmappen.
Steg 5: Hämta och jämför repository-innehåll
Kontrollera GitHub efter befintliga filer, hämta eventuellt fjärrinnehåll och jämför det sedan med inkommande data.
- Öppna Retrieve File Metadata och ställ in File Path till
{{ $json.repo.path }}{{ $('Incoming Workflow Trigger').item.json.id }}.json. - Inloggningsuppgifter krävs: Anslut era githubApi-uppgifter i Retrieve File Metadata.
- Öppna Evaluate File Size och behåll villkoren som kontrollerar att
{{ $json.content }}är tomt och att{{ $json.error }}inte finns. - Öppna Fetch Remote File och ställ in URL till
{{ $json.download_url }}. - Öppna Combine Records för att slå ihop GitHub-filens data med inkommande data från arbetsflödet.
- Öppna Detect Changes och behåll JavaScript-koden som sätter
github_statustillsame,differentellernew. - Öppna Route Status och bekräfta att Value 1 är
{{ $json.github_status }}med rutter försame,differentochnew.
Steg 6: Konfigurera GitHub-filåtgärder
Baserat på upptäckt status uppdaterar, skapar eller hoppar ni över ändringar i repositoryt.
- Lämna No Change Action som en no-op-gren för statusen
same. - Öppna Modify Repository File och ställ in File Path till
{{ $('Set Repository Context').item.json.repo.path }}{{ $('Incoming Workflow Trigger').first().json.id }}.json. - I Modify Repository File ställer ni in File Content till
{{ $('Detect Changes').item.json["n8n_data_stringy"] }}och Commit Message till{{ $('Incoming Workflow Trigger').first().json.name }} ({{ $json.github_status }}). - Inloggningsuppgifter krävs: Anslut era githubApi-uppgifter i Modify Repository File.
- Öppna Create Repository File och ställ in File Path till
{{ $('Set Repository Context').item.json.repo.path }}{{ $('Incoming Workflow Trigger').first().json.id }}.json. - I Create Repository File ställer ni in File Content till
{{ $('Detect Changes').item.json["n8n_data_stringy"] }}och Commit Message till{{ $('Incoming Workflow Trigger').first().json.name }} ({{ $json.github_status }}). - Inloggningsuppgifter krävs: Anslut era githubApi-uppgifter i Create Repository File.
- I Finalize Output ställer ni in Done till
trueför att indikera att allt är klart.
Steg 7: Testa och aktivera ert arbetsflöde
Verifiera arbetsflödet från början till slut och slå sedan på schemalagd körning.
- Klicka på Manual Start och kör arbetsflödet för att skapa en testbackup.
- Bekräfta att Route Status routar till No Change Action, Modify Repository File eller Create Repository File baserat på
github_status. - Kontrollera ert GitHub-repository efter filen på
workflows/och säkerställ att commits matchar förväntad status./ .json - När det är bekräftat, aktivera arbetsflödet så att Scheduled Start körs automatiskt vid den konfigurerade tiden.
Vanliga fallgropar
- GitHub-inloggningsuppgifter kan löpa ut eller kräva specifika behörigheter. Om något slutar fungera: kontrollera först token-scopes i GitHub Developer Settings (repo-åtkomst är ofta det som saknas).
- Om du använder Wait-liknande beteende indirekt (batchning, stora inlägg eller långsammare GitHub-svar) varierar processtiderna. Öka tidsmarginalerna eller minska batchstorleken om noder längre fram misslyckas på tomma svar.
- Standardlogiken i ”Prepare JSON Payload” kanske inte matchar hur du vill lagra filer. Lägg till dina önskade fält och namngivning tidigt, annars kommer du att omorganisera repot senare.
Vanliga frågor
Cirka 30–60 minuter om din åtkomst till WordPress och GitHub redan är klar.
Nej. Du kopplar konton och justerar några repo- och sökvägsinställningar. Den enda ”tekniska” delen är att vara bekväm med att skapa en GitHub-token och klistra in den i n8n.
Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in GitHub-kostnader om du kräver privata repon på betalda nivåer.
Två alternativ: n8n Cloud (hanterad, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger dig obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det är en av de bästa justeringarna du kan göra. Du kan justera tagg-/kategori-routingen runt ”Check Tag Presence” och sökvägslogiken i ”Build Tag Path” så att inlägg hamnar i mappar som /category/seo/ eller /author/jamie/. Många team anpassar också filnamngivning för att använda inläggets slug, och de lägger till extra fält i ”Prepare JSON Payload” (som anpassade fält eller URL:er till utvald bild) så att repot blir ett komplett innehållsarkiv.
Oftast är det en token som gått ut eller saknade repo-behörigheter. Skapa en ny GitHub personal access token, bekräfta att den har åtkomst till målrepot och uppdatera sedan inloggningsuppgiften i n8n. Om fel bara händer på större inlägg, titta också på beslutet ”Evaluate File Size” och bekräfta att arbetsflödet får hämta filinnehåll från GitHub via steget HTTP Request.
De flesta mindre sajter kan köra hundratals inlägg per körning utan problem.
För det här användningsfallet passar n8n oftare bättre än inte. Du behöver villkorslogik (kontrollera fil, jämför innehåll, sedan skapa vs uppdatera vs hoppa över), och du kan behöva hämta och slå ihop fjärrdata för filen innan du kan upptäcka ändringar. Zapier och Make kan göra delar av det, men det blir ofta dyrt eller klumpigt när du lägger till förgreningar och filjämförelse. n8n ger dig också ett alternativ för egen drift, vilket är praktiskt om du vill ha obegränsade körningar och full kontroll. Om du är osäker, prata med en automationsexpert så får du en rak rekommendation utifrån din volym och ert teamflöde.
När det här väl rullar slutar dina WordPress-ändringar att vara ett mysterium och blir en tidslinje. Arbetsflödet tar hand om den repetitiva spårningen så att du kan fokusera på själva innehållet.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.