Så här fixar du ett 500 Internt serverfel på din webbplats

Det fruktade 500 internt server-felet. Det verkar alltid komma vid de mest opassande tidpunkterna och plötsligt har du fullt upp att räkna ut hur du ska få din WordPress-webbplats tillbaka online. Lita på oss, vi har alla varit där.

Andra fel som uppträder på samma sätt som du kanske också sett är det skrämmande fel i anslutningen till databasen och den fruktade dödens vita skärm. Men från det ögonblick som din webbplats har driftstopp förlorar du besökare och kunder. För att inte tala om att det ser dåligt ut för ditt varumärke.

Idag kommer vi att dyka ner i 500 internt server-fel och gå igenom några sätt att snabbt få tillbaka din webbplats. Läs mer nedan om vad som orsakar detta fel och vad du kan göra för att förhindra det i framtiden.

Kolla in vår ultimata guide för att åtgärda 500 internt serverfel

Vad är ett 500 Internt Serverfel?

Internet Engineering Task Force (IETF) definierar 500 Internt serverfel som:

Statuskoden 500 (internt serverfel) indikerar att servern stötte på ett oväntat tillstånd som hindrade den från att uppfylla en begäran.

När du besöker en webbplats skickar din webbläsare en begäran till servern där webbplatsen hostas. Servern tar den här förfrågan, behandlar den och skickar tillbaka de begärda resurserna (PHP, HTML, CSS, etc.) tillsammans med en HTTP-rubrik. HTTP innehåller även vad de kallar en HTTP-statuskod. En statuskod är ett sätt att meddela dig statusen för begäran. Det kan vara en 200 statuskod som betyder ”Allt är OK” eller en 500 statuskod vilket innebär att något har gått fel.

Det finns många olika typer av 500 statusfelkoder (500, 501, 502, 503, 504, etc.) och de betyder alla olika saker. I det här fallet indikerar ett 500 internt serverfel att servern stötte på ett oväntat villkor som hindrade det från att uppfylla förfrågan (RFC 7231, avsnitt 6.6.1).

500 internt serverfel-variationer

500 internt serverfel i WordPressPå grund av olika webbservrar, operativsystem och webbläsare kan ett 500 internt serverfel presentera sig på ett antal olika sätt. Men de kommunicerar alla samma sak. Nedan är bara några av de många olika variationerna du kan se på webben:

• • “500 Intern Serverfel”
  • ”HTTP 500”
  • ”Internal Server Error”
  • ”HTTP 500 – Internt serverfel”
  • ”500 fel”
  • ”500 – Internt serverfel”
  • ”500 Intern Serverfel. Förlåt, något gick fel.”
  • ”500. Det där är ett fel. Det uppstod ett problem. Vänligen försök igen senare. Det är allt vi vet.”
  • ”Webbplatsen kan inte visa sidan – HTTP 500.”
  • ”Kan för närvarande inte hantera denna begäran. HTTP ERROR 500.”

Du kan också se det här meddelandet som följer med det:

Servern stötte på ett internt fel eller felkonfiguration och kunde inte uppfylla din förfrågan. Vänligen kontakta serverns administratör, [email protected] och informera dem om hur felet inträffade, och allt du kan ha gjort för att ha orsakat felet. Mer information om detta fel kan vara tillgängligt i serverns fel-logg.

Andra gånger ser du kanske helt enkelt en blank vit skärm. När det gäller 500 interna serverfel är det faktiskt ganska vanligt i webbläsare som Firefox och Safari.

Större varumärken kan till och med ha egna anpassade 500 interna felmeddelanden, som den här från Airbnb.

Här är ett annat kreativt 500-server-fel från gänget på readme.

Även den mäktiga YouTube är inte säkrad från 500 internt serverfel.

Om det är en server med IIS 7.0 (Windows) eller högre, så har de ytterligare HTTP-statuskoder för att på ett mer exakt sätt ange orsaken till 500-felet:

• 500.0 – Modul- eller ISAPI-fel uppstod.
• 500.11 – Applikationen stängs ner på webbservern.
• 500.12 – Applikationen är upptagen med att starta om på webbservern.
• 500.13 – Webbservern är upptagen.
• 500.15 – Direkt begäran av global.asax är inte tillåten.
• 500.19 – Konfigurationsdata är ogiltiga.
• 500.21 – Modul känns inte igen.
• 500.22 – En ASP.NET httpModules-konfiguration gäller inte i Managed Pipeline-läge.
• 500.23 – En ASP.NET httpHandlers-konfiguration gäller inte i Managed Pipeline-läge.
• 500.24 – En ASP.NET-personifieringskonfiguration gäller inte i Managed Pipeline-läge.
• 500.50 – Ett omskrivningsfel uppstod under hanteringen av RQ_BEGIN_REQUEST-notifieringen. Ett fel uppstod i hanteringen av konfigurationen eller inkommande regler.
• 500.51 – Ett omskrivningsfel uppstod under hanteringen av GL_PRE_BEGIN_REQUEST-notifieringen. Ett fel uppstod i hanteringen av global konfiguration eller global regel.
• 500.52 – Ett omskrivningsfel uppstod under hanteringen av RQ_SEND_RESPONSE-notifieringen. Ett fel uppstod i hanteringen av en utgående regel.
• 500.53 – Ett omskrivningsfel uppstod under hanteringen av RQ_RELEASE_REQUEST_STATE- notifieringen. Ett fel uppstod i hanteringen av en utgående regel. Regeln är konfigurerad för att köras innan utgångsanvändarcachen uppdateras.
  500.100 – Internt ASP-fel.

500-fels påverkan på SEO

Till skillnad från 503-fel, som används för WordPress-underhållsläge och säger att Google ska kolla igen vid ett senare tillfälle, kan ett 500-fel negativt påverka SEO om det inte fixas direkt.

Om din webbplats bara är nere i tio minuter och det genomsöks konsekvent många gånger, kommer sökroboten helt enkelt att få sidan levererad från cacheminnet. Eller så kanske Google inte ens har möjlighet att genomsöka det innan det säkerhetskopieras. I det här scenariot är allt okej.

Men om webbplatsen är nere under en längre tid, säg 6+ timmar, så kan Google se 500-felet som ett problem på webbplatsnivå som behöver åtgärdas. Detta kan påverka dina rankningar. Om du är orolig för upprepade 500 fel bör du räkna ut varför de händer till att börja med. Några av lösningarna nedan kan hjälpa till.

Så här fixar du 500 Internt Serverfel?

Var ska du starta felsökning när du ser ett 500-internt serverfel på din webbplats? Ibland kanske du inte ens vet var du ska börja. Vanligtvis finns 500 fel på servern, men från vår erfarenhet kommer dessa fel från två saker, den första är användarfel (klientsidemission) och den andra är att det finns ett problem med servern. Så vi dyker in i lite av båda.

This is never not annoying 😖 pic.twitter.com/pPKxbkvI9K

— Dare Obasanjo🐀 (@Carnage4Life) September 26, 2019

Kolla in dessa vanliga orsaker och sätt att fixa 500 internt server-felet och få igång igen och köra på nolltid.

1. Försök ladda om sidan

Det här kan tyckas vara lite uppenbart för vissa, men en av de enklaste och första sakerna du bör försöka när du stöter på ett 500 Internt server-fel är att helt enkelt vänta en minut eller så och ladda om sidan (F5 eller Ctrl+F5). Det kan vara så att värden eller servern helt enkelt är överbelastade och webbplatsen kommer tillbaka direkt. Medan du väntar kan du också snabbt prova en annan webbläsare för att utesluta det som ett problem.

En annan sak du kan göra är att klistra in webbplatsen i downforeveryoneorjustme.com. Den här webbplatsen kommer att berätta om webbplatsen är nere eller om det är ett problem från din sida. Ett verktyg som detta kontrollerar HTTP-statuskoden som returneras från servern. Om det är något annat än en 200 ”Allt är OK” kommer det att returnera en “nere” indikation.

Vi har också märkt ibland kan detta inträffa omedelbart efter att du uppdaterat ett plugin eller ett tema på din webbplats. Vanligtvis är detta på värdar som inte är korrekt inställda. Vad händer är att de upplever en tillfällig timeout direkt efteråt. Men saker och ting löser vanligtvis sig om ett par sekunder och därför räcker det att ladda om sidan.

2. Rensa din webbläsarcache

Att rensa webbläsarens cache är alltid ett annat bra felsökningssteg innan du dyker in i djupare felsökning på din webbplats. Nedan så finns instruktioner om hur du rensar cacheminnet i de olika webbläsarna:

• Så här tvingar du Uppdatera en enda sida för alla webbläsare
• Så här rensar du webbläsarcache för Google Chrome
• Så här rensar du webbläsarcache för Mozilla Firefox
• Så här rensar du webbläsarcache för Safari
• Så här rensar du webbläsarcache för Internet Explorer
• Så här rensar du webbläsarcache för Microsoft Edge
• Så här rensar du webbläsarcache för Opera

3. Kontrollera dina serverloggar

Du bör också dra nytta av din fel-loggar. Om du är en Kinsta-kund kan du enkelt se fel i loggvisaren i MyKinsta-panelen. Det här kan hjälpa dig att snabbt begränsa problemet, särskilt om det beror på ett plugin på din webbplats.

Om din värd inte har ett loggningsverktyg kan du också aktivera WordPress felsökningsläge genom att lägga till följande kod i filen wp-config.php för att aktivera loggning:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Loggarna ligger vanligtvis i katalogen /wp-content. Andra, som här på Kinsta, kan ha en egen mapp som heter ”loggar”.

Du kan också kontrollera loggfilerna i Apache och NGINX, som ofta finns här:

• Apache: /var/log/apache2/error.log
• Nginx: /var/log/nginx/error.log

Om du är en Kinsta-kund kan du också dra nytta av vårt analytics-verktyg för att få en sammanfattning av det totala antalet 500 fel och se hur ofta och när de uppstår. Det här kan hjälpa dig att felsöka om det här är ett pågående problem, eller kanske något som har löst sig själv.

Om 500-felet visas på grund av ett allvarligt PHP-fel kan du också försöka möjliggöra PHP-felrapportering. Lägg bara till följande kod i filen som orsakar felet. Vanligtvis kan du hitta filen genom konsolfliken i Google Chrome DevTools.

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

Och du kan också behöva ändra din php.ini-fil med följande:

display_errors = on

4. Kontrollera om det finns fel vid etablering av en databasanslutning

500 internt serverfel kan också uppstå genom ett databasanslutningsfel. Beroende på din webbläsare kan du se olika fel. Men båda kommer att generera en 500 HTTP-status kod i dina serverloggar, oavsett.

Nedan visas ett exempel på hur ett meddelande om ett “fel med att upprätta en databasanslutning” ser ut i din webbläsare. Hela sidan är tom eftersom inga data kan hämtas att skapa sidan, eftersom anslutningen inte fungerar korrekt. Detta bryter inte bara din webbplats front-end, men det hindrar dig också från att komma åt din WordPress-panel.

Så varför händer detta? Tja, här är några vanliga skäl nedan.

• Det vanligaste problemet är att dina inloggningsuppgifter för databasen är felaktiga. Din webbplats använder separat inloggningsinformation för att ansluta till MySQL-databasen.
• Din WordPress-databas är skadad. Med så många rörliga delar med teman, plugin och användare som ständigt raderar och installerar dem, blir databaser ibland skadade. Detta kan bero på en saknad eller individuellt skadad tabell, eller kanske en del information togs bort av misstag.
• Du kanske har korrupta filer i din WordPress-installation. Detta kan till och med ibland hända på grund av hackare.
• Problem med din databasserver. Ett antal saker kan vara fel på webbhotellets sida, till exempel att databasen överbelastas från en trafikspik eller inte svarar alltför många samtidiga anslutningar. Det här är faktiskt ganska vanligt med delade värdar eftersom de använder samma resurser för många användare på samma servrar.

Kolla in vårt djupgående inlägg om hur du kan fixa felet med att upprätta en databasanslutning.

5. Kontrollera dina plugin och teman

Tredjeparts plugin och teman kan enkelt orsaka 500 internt serverfel. Vi har sett alla typer orsaka dem här hos Kinsta, från slider-plugins till ad rotator-plugin. Många gånger borde du se felet omedelbart efter att du installerat något nytt eller kör en uppdatering. Detta är en anledning till att vi alltid rekommenderar att du använder en stagingmiljö för uppdateringar eller åtminstone släpper uppdateringar en efter en. Annars, om du stöter på ett 500 internt serverfel har du plötsligt en massa problem med att ta reda på vilken av dem som orsakade det.

Några sätt du kan felsöka detta är att inaktivera alla dina plugins. Kom ihåg att du inte kommer att förlora några data om du helt enkelt inaktiverar ett plugin. Om du fortfarande kan komma åt din admin-panel är det snabbt gjort genom att bläddra till ”Plugins” och välj ”Avaktivera” från menyn bulkhandlingar. Det här inaktiverar alla dina plugins.

Om det här löser problemet behöver du hitta den skyldige. Börja aktivera dem en efter en, ladda om webbplatsen efter varje aktivering. När du ser svaret 500 internt server-fel, har du hittat det felaktiga plugin-programmet. Du kan sedan nå ut till pluginutvecklaren för hjälp eller skicka en supportbiljett i WordPress-repository.

Om du inte kan logga in på WordPress admin kan du FTP till din server och byta namn på din plugin-mapp till något som plugins_old. Kontrollera sedan din webbplats igen. Om det fungerar måste du testa varje plugin en efter en. Byt namn på din pluginmapp tillbaka till ”plugins” och byt sedan namn på varje pluginmapp i den, en efter en, tills du hittar boven. Du kan också försöka återskapa detta på en testwebbplats först.

Se alltid till att dina plugins, teman och WordPress-kärnan är uppdaterade. Och kontrollera att du kör en stödd version av PHP. Om det visar sig vara en konflikt med dålig kod i ett plugin kanske du behöver ta in en WordPress-utvecklare för att åtgärda problemet.

6. Installera om WordPress-kärnan

Ibland kan WordPress-kärnfiler bli skadade, särskilt på äldre webbplatser. Det är faktiskt ganska enkelt att återuppladda bara kärnan i WordPress utan att påverka dina plugin eller teman. Vi har en fördjupad guide med 5 olika sätt att installera om WordPress. Och se till att du tar en säkerhetskopia innan du fortsätter. Gå till ett av nedanstående avsnitt:

• Så här ominstallerar du WordPress från WordPress-panelen samtidigt som du bevarar befintligt innehåll
• Så här ominstallerar du WordPress manuellt via FTP samtidigt som du bevarar befintligt innehåll
• Så här ominstallerar du WordPress manuellt via WP-CLI samtidigt som du bevarar befintligt innehåll

7. Kontrollera om det finns behörighetsfel

Ett behörighetsfel med en fil eller mapp på din server kan också orsaka ett internt serverfel på 500. Här är några typiska rekommendationer för behörigheter när det gäller fil och mappbehörigheter i WordPress:

• Alla filer ska vara 644 (-rw-r-r-) eller 640.
• Alla kataloger ska vara 755 (drwxr-xr-x) eller 750.
• Inga kataloger ska någonsin ges 777, till och med uppladdningskataloger.
• Härdning: wp-config.php kan också ställas in till 440 eller 400 för att förhindra att andra användare på servern läser den.

Se WordPress Codex artikel om att ändra filbehörigheter för en fördjupad förklaring.

Du kan enkelt se dina filbehörigheter med en FTP-klient (se nedan). Du kan också nå ut till din värds supportteam och be dem snabbt få GREP-filbehörigheter på dina mappar och filer för att säkerställa att de är ordentligt inställda.

8. Öka PHP-minnesgränsen

Ett 500 internt serverfel kan också orsakas av att uttömma PHP-minnesgränsen på din server. Du kan försöka öka gränsen. Följ instruktionerna nedan om hur du ändrar gränsen i cPanel, Apache, din php.ini-fil och wp-config.php-filen.

Öka PHP Minnesgränsen i cPanel

Om du kör på en värd som använder cPanel kan du enkelt ändra det från användargränssnittet. Under Programvara klicka på ”Välj PHP-Version”.

Klicka på ”Byt till PHP-alternativ.”

Du kan sedan klicka på memory_limit-attributet och ändra dess värde. Klicka sedan på ”Spara”.

Öka PHP Minnesgräns i Apache

.htaccess-filen är en speciell dold fil som innehåller olika inställningar som du kan använda för att modifiera serverns beteende, helt ner till en katalogspecifik nivå. Logga först in på din webbplats via FTP eller SSH, ta en titt på din rotkatalog och se om det finns en .htaccess-fil där.

Om det finns kan du redigera den filen för att lägga till nödvändig kod för att öka PHP-minnesgränsen. Troligtvis är den inställd på 64M eller lägre, du kan försöka öka detta värde.

php_value memory_limit 128M

Öka PHP-minnesgränsen i php.ini-filen

Om ovanstående inte fungerar kan du försöka redigera din php.ini-fil. Logga in på din webbplats via FTP eller SSH, gå till webbplatsens rotkatalog och öppna eller skapa en php.ini-fil.

Om filen redan var där, leta efter de tre inställningarna och ändra dem om det behövs. Om du nyss skapat filen, eller om inställningarna inte finns någonstans kan du klistra in koden nedan. Du kan naturligtvis ändra värdena för att passa dina behov.

memory_limit = 128M

Vissa delade värdar kan också kräva att du lägger till suPHP-direktivet i din .htaccess-fil för ovanstående php.ini-filinställningar för att fungera. För att göra det, redigera din .htaccess-fil, som också finns i roten till din webbplats och lägger till följande kod överst i filen:

<IfModule mod_suphp.c> 
suPHP_ConfigPath /home/yourusername/public_html
</IfModule>

Om ovanstående inte fungerade för dig kan det vara så att din värd har de globala inställningarna låsta och istället har den konfigurerad att utnyttja .user.ini-filer. För att redigera din .user.ini-fil, logga in på din webbplats via FTP eller SSH, gå till webbplatsens rotkatalog och öppna eller skapa en .user.ini-fil. Du kan sedan klistra in i följande kod:

memory_limit = 128M

Öka PHP minnesgränsen i wp-config.php

Det sista alternativet är inte en vi är särskilt förtjusta i, men om allt annat misslyckas kan du testa det. Först, logga in på din webbplats via FTP eller SSH, och leta reda på din wp-config.php-fil, som oftast ligger i roten på din webbplats.

Lägg till följande kod högst upp av din wp-config.php-fil:

define('WP_MEMORY_LIMIT', '128M');

Du kan också fråga din värd om du får problem med minnesgränser. Vi använder Kinsta APM verktyg och andra felsökningsmetoder här på Kinsta för att hjälpa kunderna att begränsa vilken plugin, förfrågan eller skript som kanske uttömmer gränsen. Du kan även använda din egen anpassade New Relic-nyckel från din egen licens.

9. Fixa din .htaccess-fil

Kinsta använder bara Nginx, men om du använder en värd som kör Apache kan det mycket väl vara att din .htaccess-fil har ett problem eller har blivit skadat. Följ stegen nedan för att återskapa en ny från början.

Först, logga in på din webbplats via FTP eller SSH, och byt namn på din .htaccess-fil till .htaccess_old.

Normalt kan du för att återskapa den här filen helt enkelt rädda dina permalänkar i WordPress. Om du befinner dig mitt i ett 500 internt serverfel, kan du dock vanligtvis inte få tillgång till din WordPress-adminpanel, så det här är inte ett alternativ. Därför kan du skapa en ny .htaccess fil och ange följande innehåll. Ladda sedan upp den till din server.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Se WordPress Codex för fler exempel, som standard .htaccess-fil för multisite.

10. Åtgärda kodnings- eller syntaxfel i ditt CGI/Perl-skript

500-fel som orsakas av fel i CGI och Perl är mycket mindre vanliga än de brukade vara, även om de fortfarande är värda att nämna, speciellt för de som använder cPanel där det finns många en-klicks CGI-skript som fortfarande används. Som AEM på Stack Overflow säger:

CGI har ersatts av en mängd olika webbprogrammeringstekniker, inklusive PHP, olika Apache-tillägg som mod_perl, Java av olika smaker och ramar inklusive Java EE, Struts, Spring, etc., Python-baserade ramverk som Django, Ruby on Rails och många andra Ruby-ramverk och olika Microsoft-tekniker.

Här är några tips när du arbetar med CGI-skript:

• Vid redigering, använd alltid en vanlig textredigerare, som Atom, Sublime eller Notepad++. Detta säkerställer att de förblir i ASCII-format.
• Se till att rätt behörigheter för chmod 755 används på CGI-skript och kataloger.
• Ladda upp dina CGI-skript i ASCII-läget (som du kan välja i din FTP-editor) i cgi-bin-katalogen på din server.
• Bekräfta att Perl-modulerna du behöver för ditt skript installeras och stöds.

11. Kontrollera med din host om serverproblem

Slutligen, eftersom 500 interna serverfel också kan förekomma från PHP-timeouts eller allvarliga PHP-fel med plugin från tredje part, kan du alltid kolla med din värd. Ibland kan dessa fel vara svåra att felsöka utan expert. Här är bara några vanliga exempel på fel som utlöser 500 HTTP-statuskoder på servern som kan få dig att klia dig på hakan.

PHP message: PHP Fatal error: Uncaught Error: Call to undefined function mysql_error()...

PHP message: PHP Fatal error: Uncaught Error: Cannot use object of type WP_Error as array in /www/folder/web/shared/content/plugins/plugin/functions.php:525

Vi övervakar alla kunders webbplatser här på Kinsta och meddelas automatiskt när dessa typer av fel uppstår. Detta gör att vi kan vara proaktiva och börja lösa problemet direkt. Vi använder även LXD-hanterade värdar och orkestrerade LXC-programvarucontainrar för varje webbplats. Detta innebär att varje webbplats är inrymd i en egen isolerad container, som har alla programvaruresurser som krävs för att köra den (Linux, Nginx, PHP, MySQL). Resurserna är 100 % privata och delas inte med någon annan eller ens dina egna webbplatser.

PHP timeouts kan också uppstå vid brist på PHP-arbetare, även om dessa typiskt orsakar 504-fel, inte 500-fel. Dessa bestämmer hur många samtidiga förfrågningar din webbplats kan hantera vid en given tidpunkt. För att uttrycka det enkelt hanteras varje ocachad förfrågan på din webbplats av en PHP-arbetare.

När PHP-arbetare redan är upptagna på en webbplats börjar de bygga upp en kö. När du har nått din gräns för PHP-arbetstagare börjar kön att trycka ut äldre förfrågningar som kan resultera i 500-fel eller ofullständiga förfrågningar. Läs vår djupartikel om PHP-arbetare.

Övervaka din webbplats

Om du är orolig för dessa typer av fel som händer på din webbplats i framtiden, kan du också använda ett verktyg som updown.io för att övervaka och meddela dig omedelbart om de uppstår. Det skickar regelbundet en HTTP HEAD-förfrågan till den webbadress du vill ha. Du kan helt enkelt använda din startsida. Med verktyget kan du ställa in kontrollfrekvenser på:

• 15 sekunder
• 30 sekunder
• 1 minut
• 2 minuter
• 5 minuter
• 10 minuter

Det skickar dig ett mail om och när din webbplats får driftstopp. Här är ett exempel nedan.

Det här kan vara särskilt användbart om du försöker felsöka ett felaktigt plugin eller har en gemensam värd, som tenderar att överbelasta sina servrar. Detta kan ge dig bevis på hur ofta din webbplats faktiskt får stopp (även mitt i natten).

Det är därför som vi alltid rekommenderar att du använder en host för applikationer, databaser och hanterad WordPress-hosting (som Kinsta).

Se till att kolla in vårt inlägg som utforskar de bästa 9 skälen att välja hanterade WordPress hosting.

Sammanfattning

500 internt serverfel är alltid frustrerande, men förhoppningsvis vet du nu några ytterligare sätt att felsöka dem för att snabbt få din webbplats att fungera igen. Kom ihåg, typiskt är dessa typer av fel orsakade av plugins från tredje part, allvarliga PHP-fel, problem med databasförbindelser, problem med .htaccess-filen eller PHP-minnesgränserna och ibland PHP-timeouts.

Var det något vi saknade? Kanske har du ett annat tips om felsökning av 500 internt serverfel. Om så är fallet, meddela oss nedan i kommentarerna.

Brian Jackson

Brian har stor passion för WordPress och har använt det i över ett årtionde, han har till och med utvecklat ett par premium-plugins. Brian gillar att blogga, kolla filmer och hiking. Ta kontakt med Brian via Twitter.

• LinkedIn
• Twitter