
🚀 Automatisk uppdatering av WordPress-plugins från GitHub: steg för steg-guide
Du har släppt en ny pluginversion på GitHub, men användarna sitter fast på den gamla. Ladda ner ZIP-filer manuellt, ladda upp via adminpanelen, kontrollera kompatibilitet: rutinuppgifter som äter tid och skapar fel.
Standardmekanismen för uppdateringar i WordPress är knuten till den officiella katalogen på WordPress.org. Men alla plugins hamnar inte där: skräddarsydda kundlösningar, interna teamverktyg, forkade versioner av populära plugins med modifikationer. Dessa behöver en annan väg.
Lyckligtvis löstes problemet med att leverera uppdateringar direkt från GitHub för länge sedan. Här är två fungerande metoder: en enkel (pluginet Git Updater, ett par klick) och en avancerad (en inbyggd PHP-klass för full kontroll).
💡 Snabb översikt:
- Installera Git Updater: den fångar upp GitHub-releaser som vanliga WordPress-uppdateringar
- För privata repositories, konfigurera en åtkomsttoken i pluginets inställningar
- Om du skriver ett eget plugin och vill bädda in automatiska uppdateringar i koden: använd den inbyggda PHP-klassen
- Repositoriet måste innehålla en giltig plugin-header och versionstagg
Metod 1: Git Updater, uppdateringar med två klick

Git Updater är ett gratis plugin som lägger till stöd för GitHub, Bitbucket, GitLab och Gitea på den vanliga uppdateringssidan i WordPress. Efter installation uppdateras plugins och teman från GitHub på samma ställe som vanliga: Dashboard → Uppdateringar.
Utvecklaren Andy Fragen har underhållit projektet sedan 2015. Git Updaters GitHub-sida har över 400 stjärnor och ett aktivt repository med regelbundna commits. Kunskapsbasen på git-updater.com täcker installation, tokenkonfiguration och API-användning.
Installationen är enkel: ladda ner ZIP-filen från GitHub-releasen, ladda upp via Plugins → Lägg till ny → Ladda upp plugin och aktivera. Pluginet börjar omedelbart spåra de repositories som anges i redan installerade plugins och temans headers.
För privata repositories behöver du en token. Skapa en Personal Access Token i GitHub Settings → Developer settings → Tokens (behörigheter: repo för privata; ingen token behövs för publika), klistra in den i Inställningar → Git Updater. Därefter kan pluginet se även stängda repositories.
En viktig detalj: Git Updater söker efter taggar i formatet X.Y.Z (semantisk versionshantering) i repositoriet. Om det inte finns några taggar fungerar inte uppdateringen. Sätt alltid en tagg innan release: git tag 1.2.0 && git push --tags.
Metod 2: inbyggd PHP-klass för utvecklare
Om du är pluginutvecklare och vill bädda in mekanismen för automatisk uppdatering direkt i din kod (utan ett separat mellanhandsplugin), fungerar den klassiska PHP-klassmetoden fortfarande. Den är lättare än originalklassen från Joachim Kudish och radishconcepts och använder inbyggda WordPress-hooks.
Lägg till följande kod i ditt plugins huvudfil eller i en separat updater.php-fil som inkluderas via require_once:
1 /** 2 * Auto-update from GitHub releases. 3 * Place in main plugin file or include via require_once. 4 */ 5 function myplugin_check_github_update($transient) { 6 if (empty($transient->checked)) { 7 return $transient; 8 } 9 10 $plugin_slug = 'my-plugin/my-plugin.php'; 11 $github_repo = 'username/my-plugin'; 12 13 $response = wp_remote_get( 14 'https://api.github.com/repos/' . $github_repo . '/releases/latest', 15 array( 16 'headers' => array( 17 'Accept' => 'application/vnd.github.v3+json', 18 'User-Agent' => 'WordPress/' . get_bloginfo('version'), 19 ), 20 ) 21 ); 22 23 if (is_wp_error($response) || wp_remote_retrieve_response_code($response) !== 200) { 24 return $transient; 25 } 26 27 $release = json_decode(wp_remote_retrieve_body($response)); 28 29 if (!isset($release->tag_name)) { 30 return $transient; 31 } 32 33 $latest_version = ltrim($release->tag_name, 'v'); 34 $current_version = $transient->checked[$plugin_slug] ?? '0'; 35 36 if (version_compare($latest_version, $current_version, '>')) { 37 $transient->response[$plugin_slug] = (object) array( 38 'slug' => dirname($plugin_slug), 39 'new_version' => $latest_version, 40 'url' => 'https://github.com/' . $github_repo, 41 'package' => $release->zipball_url, 42 ); 43 } 44 45 return $transient; 46 } 47 add_filter('pre_set_site_transient_update_plugins', 'myplugin_check_github_update');
Koden gör exakt tre saker: frågar GitHub API efter den senaste releasen, jämför versionen från tag_name med den aktuella pluginversionen, och om GitHub har en nyare version registreras uppdateringen i den vanliga WordPress-mekanismen. Pluginversionen hämtas från den vanliga headern Version: X.Y.Z i huvudfilen.
Observera: för publika repositories behövs ingen token, men GitHub API utan token begränsar antalet förfrågningar till 60 per timme och IP. För ett produktionsplugin med många användare, lägg till resultatcachning via set_transient() i 6-12 timmar. På så sätt når du inte gränsen varje gång någon besöker pluginsidan.
Jämförelse av metoderna
Kriterium | Git Updater | Inbyggd PHP-klass |
|---|---|---|
Installationskomplexitet | Minimal (installera och det fungerar) | Medel (behöver skriva och testa kod) |
GitLab/Bitbucket-stöd | Ja (via API-tillägg) | Nej (endast GitHub, kräver separat kod) |
Privata repositories | Ja (inbyggt tokenstöd) | Ja (lägg till Authorization-header) |
Beroende av tredjepartskod | Ja (behöver uppdatera pluginet) | Nej (koden ligger i ditt plugin) |
Cachning av API-förfrågningar | Inbyggd | Behöver implementeras själv |
Passar för | Webbplatsägare, frilansare | Pluginutvecklare, byråer |
Slutsats: om du installerar någon annans GitHub-plugin på en webbplats, använd Git Updater. Om du är pluginutvecklare och distribuerar det via GitHub, bädda in automatiska uppdateringar i koden så att användarna slipper installera ett extra plugin.
Förbered repositoriet för automatiska uppdateringar
Oavsett vilken metod du väljer måste GitHub-repositoriet vara korrekt förberett. Tre obligatoriska punkter:
Plugin-header. I huvud-PHP-filen, inkludera den vanliga WordPress-headern: Plugin Name, Version, Author och Plugin URI med en länk till repositoriet. Git Updater läser Plugin URI och GitHub Plugin URI; ange minst en av dem.
Versionstaggar. Varje release måste åtföljas av en tagg:
git tag 1.3.0 && git push origin 1.3.0. Utan taggar kan varken Git Updater eller API-förfrågan se den nya versionen.Readme-fil. Lägg till en
README.mdmed beskrivning, ändringslogg och installationslänk. Git Updater visar readme-innehållet på plugininformationsskärmen, vilket sparar tid för användare som slipper besöka GitHub för instruktioner.
Med GitHub Actions kan du gå längre: vid tagg-push, bygg automatiskt ZIP-filen, generera en ändringslogg från commits och skapa en GitHub Release med det bifogade arkivet. Ett färdigt workflow finns i den officiella GitHub-dokumentationen; anpassa det för WordPress genom att ersätta build-steget med plugin-paketering.
Videon visar hela processen från installation av Git Updater till den första automatiska pluginuppdateringen. Vi rekommenderar att du tittar innan du börjar konfigurera: 12 minuters skärminspelning sparar en timmes experimenterande.
⁉️🤔 Vanliga frågor
Fungerar Git Updater med plugins från den officiella WordPress.org-katalogen?
Ja, men det är meningslöst. Plugins från WordPress.org får redan uppdateringar via standardmekanismen. Git Updater är specifikt till för plugins och teman som inte finns i katalogen: specialutvecklingar, forkade versioner, plugins under granskning.
Kan Git Updater användas på en produktionswebbplats?
Ja, projektet är stabilt och har underhållits sedan 2015. Gör en fullständig backup innan installation (som med alla nya plugins). På en testwebbplats, kontrollera uppdateringen av minst ett plugin, säkerställ att taggarna i repositoriet är korrekt satta och att uppdateringen genomförs utan fel.
Vad händer om GitHub API når förfrågningsgränsen?
För publika repositories är gränsen 60 förfrågningar per timme från en IP. Git Updater cachar svar i 12 timmar, så problemet uppstår sällan. Om det ändå gör det, skapa en gratis Personal Access Token (utan extra behörigheter) och lägg till den i Inställningar → Git Updater: gränsen höjs omedelbart till 5000 förfrågningar per timme.
Vad gör man om pluginet på GitHub använder Composer-beroenden?
Git Updater kör inte
composer installunder uppdateringar. Om ditt plugin är beroende av Composer-paket, bädda in autoloading via en bundle (packavendor/i release-ZIP:en) eller lägg till ett skript efter uppdatering som kontrollerar beroenden och varnar administratören om de saknas.
Kan plugins uppdateras från ett privat repository på gratis GitHub?
Ja. Gratis GitHub-konton inkluderar obegränsat antal privata repositories. Skapa en Personal Access Token med
repo-behörighet, lägg till den i Git Updater, så får pluginet åtkomst till dina privata repositories.
Automatiska uppdateringar från GitHub: vad man ska använda 2026
För en webbplatsägare är svaret tydligt: Git Updater. Gratis, stabilt, kräver ingen kod.
För en pluginutvecklare beror valet på målgruppen. Om din produkt installeras av vanliga användare, bädda in PHP-klassen för automatisk uppdatering direkt i pluginkoden. Ett extra mellanhandsplugin i kedjan minskar installationskonverteringen. Om produkten riktar sig till en teknisk målgrupp är Git Updater som beroende acceptabelt; nämn det bara i instruktionerna.
Kontrollera dina GitHub-plugins nu: finns taggar satta på de senaste releaserna, är Plugin URI ifylld i headern, har användaren en tydlig uppdateringsväg? Femton minuters konfiguration sparar dig och dina användare åratal av manuellt krångel med ZIP-arkiv.



