Bästa sättet att skicka e-post via WordPress

Bättre e-post med WordPressAtt skicka e-post via WordPress är inte alltid så enkelt.

E-post som hanteras via WordPress, såsom användarregistreringar och kontaktformulär, skickas som standard via en e-postfunktion i PHP (PHPMailer) på den webbserver som hanterar webbplatsen ifråga.

Detta är, i min mening, ett direkt felaktigt beteende.

E-post är en av de mest komplexa tjänster som finns på Internet. Inte för att det är svårt att hantera en e-postserver nuförtiden (som när jag satte upp Sendmail på Loopia en gång i tiden), utan för att det finns så många olika spamfällor.

Mer än hälften av all e-post i världen är skräppost (spam). Därför motverkas spam med SPF, svartlistor, innehåll/beteendeanalyser, SMTP-portblockeringar och mycket mer. Att fastna i ett spamfilter, även med legitim e-post, är väldigt enkelt.

För störst chans att skicka e-post framgångsrikt bör man använda en renodlad e-postserver. En korrekt uppsatt e-postserver underhålls och hanteras oftast så att spamfilter inte biter på den. Detsamma går inte att säga om webbservrar, som ofta spamklassas och saknar rutiner för felhantering av e-post.

– Hur rättar man då denna (felaktiga) hantering av e-post i WordPress?

Jo, med ett WordPress-tillägg. Det tillägg som jag använder (och har översatt till svenska) heter WP Mail SMTP. Det är det mest populära tillägget för e-posthantering i WordPress, med över 700 000 aktiva installationer.

WP Mail SMTP installeras/aktiveras enkelt via wp-admin. Inställningarna för tillägget hanteras därefter under “Inställningar” och “WP Mail SMTP”. Så här ser mina inställningar för WP Mail SMTP ut:

Inställningar för WP Mail SMTP

Alternativet “Övrig SMTP” är det som de flesta bör välja, med undantag för Google-användare. SSL/TLS är ett måste, annars skickar man sitt lösenord i klartext över nätet. Övriga uppgifter är nog rätt så självförklarande (och något man får från sin e-postleverantör).

Det som främst är värt att notera här är hur lösenordet hanteras. Istället för att ange/spara det i wp-admin så är det inlagt i wp-config.php (WordPress’ konfigurationsfil) med följande två rader:

define( 'WPMS_ON', true );
define( 'WPMS_SMTP_PASS', 'mitthemligalösenord' );

När man har lagt in sina uppgifter under inställningarna så bör man även testa e-postfunktionen under fliken “Test av e-post”. Om man senare upplever problem med e-posten så kan man här enkelt testa om det beror på e-postservern eller WordPress.

Håller du med eller är du av annan åsikt än mig? Lämna gärna en kommentar nedan!

Hantera WordPress, tillägg och teman centralt med WP Remote

Som alla vet så är det väldigt viktigt att hålla WordPress ordentligt uppdaterat, både vad det gäller WordPress själv samt dess många olika tillägg och teman. Jag har tidigare tipsat om separata lösningar och tillägg för detta, men nu har jag hittat något ännu bättre.

WP Remote är en ny webbtjänst där man via ett centralt gränssnitt kan hålla koll på ett flertal olika WordPress-sidor. Med ett tillhörande tillägg, som installeras på varje sida som ska övervakas, så är det både enkelt och säkert att uppdatera WordPress med tillägg och teman.

Man skapar bara ett konto hos WP Remote, lägger upp en sida och får gå igenom en snabb installation av deras tillägg med tillhörande API-kod. Att lägga till en ny sida tar ett par minuter, inklusive installationen av deras tillägg.

Istället för att man ska behöva ange användarnamn/lösenord för varje WordPress-sida så uppger man en slumpmässigt genererad API-kod från WP Remote i inställningarna för tillägget.

Så här ser det ut när man uppdaterar ett WordPress-tillägg via WP Remote:

Här behöver visst Akismet uppdateras
Ett klick, sen var det klart

Det är även möjligt att skapa grupper för smidig sortering av WordPress-sidor samt att ta backup på varje sida till Amazon S3. Inom kort kommer det bli möjligt att schemalägga backuper. Backuperna är likaså krypterade hos Amazon.

WP Remote är inte den enda centrala övervaknings/hanteringstjänsten för WordPress, men till skillnad från många andra tjänster så är WP Remote helt gratis. Utvecklarna av denna tjänst har sagt att det så kommer att förbli, med reservation för att de kan behöva ta betalt/visa reklam om kostnaderna för Amazon S3 blir för stora.

WP Remote har dessutom stöd för både vanliga WordPress-sidor och sidor i WordPress Multi-site. För det sistnämnda är jag inte helt säker på funktionaliteten med nätverksuppdateringar (av WordPress själv), men en uppdatering av detta inlägg kommer så snart jag har fått möjlighet att testa det.

Sist men inte minst, WP Remote har en responsiv design. Du kan därmed hantera och uppdatera alla dina WordPress-sidor enkelt oavsett om du sitter med en dator, en surfplatta eller en mobiltelefon.

Så om du arbetar med många olika WordPress-sidor, spana då gärna in WP Remote! 🙂

Kontrollera laddningstiderna på dina WordPress-tillägg

Den vanligaste orsaken till en långsam WordPress-sida, det är olika WordPress-tillägg. På samma sätt som tillägg utökar en sidas funktionalitet, så ökar de likaså en sidas laddningstider. Detta tack vare fler databasanrop, externa anrop osv.

Jag har tidigare berättat hur man kan snabba upp sin WordPress-sida, samt gett tips på optimering av WordPress-servrar och enskilda tillägg. Nu har jag hittat något som gör det möjligt att analysera hur enskilda tillägg påverkar en laddningstiderna i WordPress.

Med tillägget P3 (Plugin Performance Profiler) kan man både automatiskt och manuellt kontrollera sina tillägg. Resultatet redovisas tydligt med grafer och statistik. Här är ett exempel på hur det kan se ut:

Det går att gräva ner sig rejält under de olika flikarna och om man kör kontrollen flera gånger, efter att ha inaktiverat/tagit bort olika tillägg, så får man en fin historik.

P3 (Plugin Performance Profiler) är klart värt ett test!

Och du, glöm för all del inte bort att balansera funktionalitet och snabbhet. En väldigt snabb sida, utan någon funktionalitet, kan likaså bidra till ett lägre antal besökare.

Enkel koll på uppdateringar av WordPress-tillägg

En uppdaterad WordPress-sida är en bra WordPress-sida. Jag har tidigare tipsat om en separat lösning för enkel koll och uppdatering av flera WordPress-sidor. Men det går även att lösa detta direkt i WordPress.

Det finns ett rätt så stort antal tillägg som skickar e-post när säkerhetsuppdateringar, av installerade WordPress-tillägg, är tillgängliga. Jag har testat flera av dessa tillägg och det var ett som stod ut lite extra: Mail on Update.

Alla tilläggen fungerade bra, men fördelen med Mail on Update är att man redan i e-postmeddelandets avsändare och ämnesrad kan se vilken WordPress-sida som behöver uppdateras.

Jag lyckades dock, konstigt nog, inte hitta något tillägg som skickar e-post när det finns en uppdatering till själva WordPress. Om du känner till något sådant så får du gärna lämna en kommentar här.

En smygtitt på WordPress 3.2

Idag släpptes den första betan av WordPress 3.2. Bland nyheterna märks bl a förbättrad prestanda, lite snyggare gränssnitt, ett fullskärmsläge när man skriver inlägg och ett nytt standardtema. Här är några skärmbilder:

Stiligt och rent i wp-admin

Fullskärm med WordPress

Jag har lattjat runt med WordPress 3.2 en knapp timme och ja, visst känns det lite rappare. Det nya standardtemat ger jag däremot inte mycket för (än). Det känns alldeles på tok för luftigt och stort. Att sidhuvudet tar upp halva skärmen från början är inte ok.

Testa gärna WordPress 3.2, med det nya temat, på Letsbuyshit.com.

Vill du även köra det på din egen webbplats så kan du göra det med tillägget WordPress Beta Tester (installera, aktivera, välj “Verktyg” > “Beta Testing” och “Bleeding edge nightlies”). Notera dock att det är en tidig beta, med allt vad det innebär.

WordPress 3.2 kommer att släppas skarpt den 30:e juni.

Det bör noteras att versionskraven på PHP och MySQL kommer att öka (avsevärt) med WordPress 3.2. Nu krävs minst PHP 5.2.4 och MySQL 5.0. Om du inte har detta, då kan du inte uppdatera (eller ja, då kommer din uppdaterade webbplats inte fungera).

Du kan testa om ditt webbhotell har stöd för WordPress 3.2 med tillägget WordPress Requirements Check. Så här ser det t ex ut på ett webbhotell som inte kan hantera WordPress 3.2:

WordPress 3.2 #fail hos Crystone