WebbMotell - Det prisvärda alternativet för era hemsidor

Grymt Koncept! Vårt Premium webbhotellkonto är något utöver det vanliga. Ni får en helt egen server för er själv. Ni konkurrerar inte med någon annan om CPU och minne, allt är ert! Och detta till ett pris som motsvarar ett vanligt webbhotell. Vi erbjuder också två instegskonton, Start och Standard. Dessa är vanliga webbhotellkonton där ni delar resurser som CPU och minne/RAM med andra kunder.

Detta är vår supportportal för denna produktlinje. Webbmotell kommer som standard utan support, förutom då felanmälan. Många kunder klarar sig helt utan support och då vill vi ge dem möjlighet att inte heller behöva betala för andras support, bara för deras egen support.

Denna portal är tänkt att vara ett komplement till support som en självhjälp, men också med möjligheten att ställa frågor. Frågor ni ställer besvaras av andra hjälpfulla kunder eller i mån av tid av vårt supportteam. Här hjälper vi varandra. För att ställa frågor behöver ni skapa ett konto och logga in.

Vissa webbhotellplaner tillåter att man skapar egna cron-job. Det finns två varianter av cron jobb:

1. Med URL, dvs man anropar ett program med https://…
2. Med ett program, t.ex ett php program.

Enklast är att använda URL. Man kan då skapa ett skript på ens hemsida som körs regelbundet, t.ex. https://mindoman/cron.php. Kryssar ni för “Log output” kommer resultatet att skrivas i filen /private/cron_wget.log.

Vill ni inte köra skriptet via er hemsida, då kan köra det på “kommandoraden”. Vi rekommenderar att ni lägger era skript i /private katalogen. Motsvarande kommando skulle då se ut så här:

/usr/bin/php /private/cron.php

Kryssar ni för “Log output” kommer resultatet att skrivas i filen /private/cron.log.

Det behöver naturligtvis inte vara php skript, det kan också vara shell skript, t.ex.

/bin/sh /private/cron.sh

De kataloger ni bör komma ihåg är

/private
/web

Dessa kommer ni åt med ftp och kan då ladda upp filer där. Allt ni lägger i /web är synlig för alla genom er hemsida, man kommer åt det med http, medan det som ni lägger i /private är helt skyddat från åtk

När ni skapar en webbplats i ISPconfig då skapas bara denna på web-servern. För att webbplatsen också skall fungera på internet måste den också skapas i DNS. Det sker inte automatiskt, det är något ni måste göra som utöver skapandet av webbplatsen. Detta gäller också e-post. E-post börjar inte fungera per automatik för att ni skapar en webbplats.

När ni skapar webbplatser/aliasdomäner/underdomäner med den enkla kontrollpanelen i er kundportal, då skapas allting ni behöver för er hemsida automatiskt. Ni kan välja om ni vill skapa en e-postdomän eller inte. Alla DNS records som behövs skapas automatiskt med den enkla kontrollpanelen.

Om er webbhotellplan tillåter er att sätta upp flera webbplatser kan ni göra det. I regel tillåter emellertid våra webbhotellplaner endast en webbplats och till denna kan ni skapa under-/sub-domäner och/eller aliasdomäner. Det som skiljer en webbplatsdomän mot en aliasdomän är att webbplatsdomänen kan placeras på olika servrar medan aliasdomänen måste placeras på den servern som den överordnade webbplatsdomänen finns.

De flesta av våra webbhotellplaner inkluderar bara en webbplatsdomän och kan då också inkludera flera aliasdomäner (multidomän).

VARNING: Tag aldrig bort en webbplats om ni verkligen inte är helt säker på vad det är ni gör. Tar ni bort en webbplatsdomän då tas också alla underordnade aliasdomäner och underdomäner bort. Finns bara en webbplats i ISPConfig och ni tar bort den, då försvinner alla era hemsidor.

Vi rekommendera följande gång när ni skapar webbplatser.

Webbplats

1. Skapa DNS zon för domännamnet

Det första ni skall göra är att skapa domänen i DNS. Det är viktigt att detta görs först eftersom detta behövs för att sätta upp SSL på er webbplats.
Ni kommer att få flera förslag på IP adresser, ange den IP adress som ni har fått angiven i det kontobrev ni fått. När ni skapat denna, vänta 5 minuter innan ni fortsätter.

2. Skapa webbplats

Nästa steg är att skapa webbplatsen.

Det är många parametrar som skall anges när denna skapas.


Server och IP adress är oftast redan givna och går inte att ändra på. Samma IP adress som står här skall anges i DNS enligt punkt 1 ovan.

En viktig parameter är sedan "Kvot för hårddisk". Där skall ni ange hur mycket utrymme er webbplats får ta och detta utrymme måste rymmas inom er plan. Har ni totalt 5000 MB till ert förfogande i er webbhotellplan, då kan ni ange det här, men då har ni inte utrymme för att skapa ytterligare webbplatser (om er plan tillåter er det).

Övriga inställningar kan ni låta stå som anges av bilden. Dessa kan alltid ändras i efterhand om man vill det.

Skapa maildomän

För att domänen skall fungera med e-post behöver en maildomän skapas för det aktuella domännamnet. Gå till E-Post/Domän/Lägg till ny domän.

Fyll i formuläret enligt bilden. Vill ni också sätta upp DKIM för maildomänen, se då en annan artikel för det.

Nästa steg är att skapa ett MX record i DNS. Öppna zonen för den aktuella domänen och klicka på gröna MX knappen

och skapa ett MX record.

De avslutande punkterna är mycket viktiga.

Med dessa inställningar kommer ni igång med e-post för domännamnet, ni kan skapa e-postkonton, e-postalises och så vidare.

Aliasdomäner

Aliasdomän för webbplats är en parkerad webbplats, den visar samma webbplats som någon annan av era webbplatser, det man brukar kalla parkerad. Det går också att vidarebefodra denna till en helt annan domän.

Aliasdomän (vhost) har en helt egen oberoende hemsida.

1. Skapa DNS zon för domännamnet

Samma som för Webbplats ovan.

2. Skapa aliasdomän

Vad gäller aliasdomäner med vhost är det många parametrar som skall anges. Om det gäller en parkerad domän då är det betydligt färre som behöver anges. Följande bild visar hur man skapar en aliasdomän med egen hemsida.


Det viktiga här är Webbmapp. Denna anger vart filerna för hemsidan skall lagras. För de flesta spelar detta ingen roll, men den kan behövas anges om man installerar vissa applikationer som då behöver veta detta. Denna folder måste vara unik, den får inte existera sedan tidigare. Vi rekommenderar att ni anger samma som domännamnet här.

Trafik kan ni i regel ange som -1.

Övriga inställningar kan ni låta stå som anges av bilden. Dessa kan alltid ändras i efterhand om man vill det.

3. Skapa maildomän

Se ovan.

Underdomän

Underdomän för webbplats är an parkerad webbplats, den visar samma webbplats som någon annan av era webbplatser. Den kan också vidarebefodras till någon helt annan hemsida. 

Underdomän (vhost) har en helt egen hemsida.

1. Skapa DNS zon för domännamnet

Här skiljer det sig ordentligt från webbplatser och aliasdomäner. Ni skall här inte skapa en ny DNS zon, ni skall istället skapa records i en befintlig DNS zon.

Antag att er huvuddomän är kallekula.se och ni vill skapa underdomänen hemma.kallekula.se.

Steg 1 är att öppna DNS zonen för kallekula.se och lägga till ett för underdomänen hemma.kallekula.se. Enklast är att lägga till ett CNAME, men skall man använda underdomänen för e-post, då behöver man ange ett A record. Detta exempel kommer att visa hur man lägger till ett CNAME.

Klicka på DNS i övre menyn, sedan klickar ni på den befintliga zonen kallekula.se. Klicka sedan på den gröna knappen CNAME 

Fyll i enligt bilden och klicka på spara. Det är mycket viktigt att huvuddomänen anges med en avslutande punkt.

2. Skapa underdomän

Samma som för Aliasdomän, men med ett undantag, Automatisk underdomän skall anges som Ingen

3. Skapa maildomän

Det går att skapa maildomän för en underdomän, men instruktionerna som angivits här stödjer inte det. Skall ni använda underdomänen för e-post behöver ni sätta upp A record istället för CNAME och ni behöver också ange ett MX record och också helst ett SPF record i er DNS-zon.

I ett nötskal

Det finns tre olika typer av domäner i ISPConfig kontrollpanel

1. Huvuddomän: Den högsta nivån för webbhotellkontot, t.ex. domänen exempel.se. Till denna kan sedan subdomäner och tilläggsdomäner kopplas.
2. Subdomän: Underdomän till huvuddomänen, t.ex. hemma.exempel.se.
3. Tilläggsdomän: Utöver huvudomänen kan man sätta upp tilläggsdomäner, typ exempel.com, example.com.

De två sistnämnda kan implementeras på 3 olika sätt:

1. Parkering: Det innebär att domänen i fråga visar exakt den webbplats som den parkeras på. T.ex. kan man parkera exempel.com på exempel.se, varvid https://exempel.se https://exempel.com kommer att visa exakt samma webbplats.
2. Omdirigering: Här skickas besökaren vidare till till en annan webbplats. T.ex kan https://foo.exempel.se skickas vidare till https://foo.se. 
3. Vhost: Här skapar man en helt egen webbplats för den aktuella domänen. Det kan vara typ foo.exempel.se, exempelnorge.se, exempel2.se och så vidare.

Tilläggsdomäner och subdomäner är kopplade till en huvuddomän och ligger alla under samma username. Deras disk-kvot ingår i den som angivits för huvuddomänen.

Alla typer kan dock ha olika versioner av php.

Parkerade domäner

Dessa har ingen egen webbplats utan de visar samma webbplats som någon annan webbplats.

Parkerade domäner kan man använda på två olika sätt:

1. Som parkerad domän på en annan domän
2. Som vidarebefodring till annan webbplats

En parkerad domän visar exakt samma webbplats som en annan webbplats, utan någon vidarebefodring. Antag att ni er ordinarie webbplats ligger på foo.se och att ni också vill att er domän foo.com skall visa exakt samma webbplats. Då parkerar ni domänen foo.com på domänen foo.se. Exakt samma webbplats kommer då att visas för https://foo.com som för https://foo.se. 

Omdirigerade domäner

Antag nu att ni har domänen foo.com och ni vill att den skall visa en helt annan webbplats, som ni inte har på ert webbhotellkonto, eller som ni kanske inte ens äger. Anta att denna webbplats är https://bar.se. Ni kan då sätta upp vidarebefodring till denna adress. Dvs går någon till https://foo.com då vidarbefodras man automatiskt till https://bar.se i sin webbläsare.

Vidarebefodring har ett antal nackdelar. Framförallt gillar inte sökmotorer det. Det går aldrig att få en bra ranking hos sökmotorer som använder vidarbefodring. Parkerade domäner emellertid, de fungerar alldeles utmärkt med sökmotorer. Det är till och med så att parkerade domäner är mycket vanligt för SEO.

En annan nackdel med vidarebefodring är att det bara går att vidarebefodra huvuddomänen, dvs https://foo.com. Skulle någan ange https://foo.com/contact/ så fungerar det inte med vidarebefodring, men med parkering fungerar det utmärkt.

Samma nomenklatur och funktioner gäller underdomäner.

Vhost domäner

Dessa är helt fristående webbplatser, med egna filer.

Det är ftp-konton som används för Installatron. Ta inte bort dessa.

Ja, under Spamfilter finns alternativ för svart- resp. vitlistning av inkommande e-post. Ni kan sätta upp filter som gäller för alla era e-postkonton eller för enskilda.

Notera att ni måsta ha aktiverat "Spamfilter" för respektive e-post-domän för att detta skall fungera. Som standard är det ofta inte satt. Vi rekommenderar att ni sätter det till "Normal".

Skapa Spamfilter:

• Användare: Här kan du välja mottagarens e-postkonto eller till och med hela mottagardomänen för vilken den här vitlisteposten kommer att vara giltig - den här vitlisteposten kommer inte att användas för andra mottagares e-postkonton eller domäner.

• E-post: Ange den e-postadress vars e-postmeddelanden ska vit/svartlistas. Du kan till och med vit/svartlista en hel domän genom att lämna den lokala delen av e-postadressen - det vill säga om du vill lista e-postmeddelanden från domänen spammer.com, skriv @spammer.com i det här fältet.

• Prioritet: Om flera poster för vitlista/svartlista tillämpas anger det här fältet vilken regel som ska användas först (10 = högsta prioritet, 1 = lägsta prioritet). Om du till exempel svartlistar @example.com med prioriteten 5 kan du vitlista user@example.com med prioriteten 6 så att user@example.com e-post kommer igenom medan @example.com är svartlistad.

• Aktiv: Detta definierar om den här listningen är aktiv eller inte.

Ni kan blocka utgående och/eller inkommande e-post till/från era egna e-postadresser.

Ja, i Installatron går det att ange vilka mail man vill få från Installatron.

Logga först in till Installatron från den enkla kontrollpanelen.

Gå till "Mina Applikationer" och klicka på det lilla verktyget för den aktuella applikationen.

Gå sedan sedan till "E-postmeddelanden" och där kan ni ange vilka meddelanden ni vill få från Installatron.

DKIM aktiveras via kontrollpanelen ISPConfig. Har ni inte tillgång till denna behöver ni kontakta Kundtjänst.

Stegen är

1. Logga in till ISPConfig
2. Gå till "E-Post/E-postkonton/Domän" och klicka på er domän
3. Klicka på "DomainKeys Identified Mail"
4. Kryssa för "enable DKIM"
5. Ange "mail1" som DKIM-Selector
6. Klicka på "Generate DKIM Private-key"
7. Klicka på Spara

DKIM aktiveras då för er domän och er DNS zon uppdateras med korrekta DNS records. 

Er Maildomän

I ISPconfig, gå till maildomänen för vilken ni vill aktivera DKIM:

Notera namnet för er mailserver. Ni skall använda er av detta namn när ni senare anger "DKIM-selector". Ni kan iofs använda godtycklig "DKIM-selector" så länge krockar inte uppstår. Vi rekommenderar att ni använder första delen i mailservernamnet, dvs "mail1" i detta fall. "DKIM-selector" får under inga omständigheter innehålla en punkt (".").

Konfigurera DKIM

Klicka som nästa steg på er maildomän och följande kommer upp:

Klicka på "DomainKeys Identified Mail" för att öppna inställningarna för DKIM.

Följ sedan bara instruktionerna bara instruktionerna i bilden ovan. Notera att ni i detta fall anger "mail1", som är den första delen i mailservernamnet, som DKIM-Selector.

Vi stödjer DNSSEC med vår DNS-tjänst som ingår mer WebbMotell. Vår DNS tjänst skapar nycklar som ni sedan ger till er registrar för ert domännamn. För att nycklarna skall propagera ut på internet ordentligt, avvakta en dag innan ni kontaktar er registrar.

Ni kan läsa mer om DNSSEC här.

Logga in till ISPconfig och gå till DNS administration för er domän:

Ni klickar på "Zone settings" för inställningarna för er DNS-zon. Längs ned på sidan visas då inställningarna för DNSSEC.

Eftersom SHA-1 inte längre stöds av de flesta registries skall ni bara anmäla det nedre recordet, det inramade "Digest Type"=2, record.

Efter att ni klickat på "Spara" skapas records enligt bilden ovan. Det kan ta upp till 10 minuter innan records skapas och visas enligt bilden ovan.

OBS: Notera att det ibland finns ett mellanrum i "digest", i detta fall mellan "A6B 9777". Detta mellanrum måste ni ta bort när ni registrera detta record till registriet. Kontrollera noga att alla eventuell mellanrum i ert "digest" tas bort.

När ni skall lägga till detta record hos er domännamnleverantör "kan" det se ut så här:

Ni kan se i detta exempel hur det record ni skapat i ISPconfig mappar mot det som ni skall ange till er domännamnsleverantör/registry.

Ni kan kontrollera era DNSSEC inställningar på https://dnsviz.net.

Problemet är sannolikt att ni inte har fått något SSL certifikat till er hemsida. Normalt sett skapas det när ert webbhotellkonto skapas, men om ert domännamn inte redan pekar på sätt namnservrar när ert webbhotellkonto skapas, då finns en risk för att något SSL certifikat inte skapas.

Vi använder oss av SSL certifikat från Let's Encrypt. Ni kan enkelt skapa ett certifikat för er hemsida via ISPConfig kontrollpanel. En förutsättning är dock att ert domännamn pekar på rätt namnservrar.

Innan ni laddar upp något innehåll till er webbsida bör ni först se till att SSL certifikatet är installerat. Kontrollera att typ

http://mindoman.se

fungerar och visar den standardsida som visas när konton installeras, observera "http:" här. När denna visas korrekt i er webbläsare, då kan ni fortsätta med att installera SSL certifikat för er hemsida.

Logga in till ISPConfig. Gå till "Webbplatser" och klicka på er domän:

Kryssa för "SSL" och "Let's Encrypt SSL" och klicka sedan på Spara. Efter ca 10 minuter kommer er hemsida att ha ett giltligt certifikat.

Är dessa redan ikryssade, kryssa då bort dem och klicka på spara. Vänta några minuter och kryssa i dem igen och klicka på Spara.

Redis cache ingår i våra Premium planer.

Aktivera Redis Cache för WordPress

Innan Redis installeras,  installera och aktivera Query Monitor-plugin.

Genom att lägga till Query Monitor kan databasfrågor, PHP etc felsökas. Det hjälper också till att visa totala antalet databasfrågor grupperade efter akutell plugin som gjort förfrågan.

Inloggad som admin, gå till förstasidan på er WordPress hemsida, alltså inte admin sidan utan den vanliga hemsidan. Högst upp på sidan visas nedanstående rad (om ni är inloggad som admin). Klicka på Query Monitor.

Detta startar en Query Monitor panelen.

Just detta exempel är en ganska enkel sida, och här kan man se totalt 23 databasanrop som tar 0,0013 millisekunder att köra.

Lägg nu till ett Redis Object Cache plugin. Sök på Redis och välj det här specifika plugin-programmet Redis Object Cache.

Installera och aktivera det här plugin-programmet. Gå sedan över till Redis-inställningar (på instrumentpanelsmenyn). Nu bör du aktivera Objektcache.

Detta ställer in Redis med standardinställningarna. Det går att ändra dessa inställningar, se Configuring the plugin. Vi rekommendera starkt att ni sätter WP_REDIS_PREFIX till något eget.

Kontrollera om Redis fungerar

Om du går till din webbplats och öppnar en blogg, låt oss säga standard hello world WordPress-bloggen, kommer resultaten av denna begäran att sparas på Redis.

Uppdatera nu startsidan som du laddade Query Monitor.

Och du kan se att sidan nu laddas med endast 3 databasfrågor som tar 0,0003 millisekunder. Vår totala databasfrågatid är nu betydligt lättare än där den var. Alla dessa frågor sparas nu i minnet, vilket minskar de samtal du måste göra direkt till MySQL-databasen. Detta gör backend snabbare för att returnera förfrågningar.

Slutsats

Om du har en omfattande webbplats som woo-commerce kommer detta att spela en stor roll för att göra din webbplats snabbare. Detta cachelagrar också databasintensiva uppgifter som gör webbplatsen mer motståndskraftig.

Även när du har många användare som gör beställningar drar de information från cachen. Du kommer att använda färre resurser och få en snabbare backend-upplevelse.

Redis cachelagrar bara databasfrågor och objekt. Detta innebär att du fortfarande kan fortsätta använda andra cache-plugins som Cache Enabler och WP Cloudflare för att cachelagra dina sidor och göra din webbplats ännu snabbare.

För att minimera risken för att den e-post ni skickar inte kommer fram för att kategoriseras som spam av mottagaren behöver ni göra följande:

1. Sätta SPF för domänen
2. Aktivera DKIM för domänen
3. Sätta DMARC för domänen
4. Lägg till domänen till Google "Postmaster Tools"

SPF är redan satt som standard för e-postdomäner som skapas med den enkla kontrollpanelen. För e-postdomäner som skapas i ISPConfig måste SPF sättas manuellt i domänens DNS zon. Följande SPF skall sättas för apex/root domänen:

v=spf1 mx a +include:_spf.ewn.se ~all

Det går också att sätta -all, men detta kan skapa problem för er när ni skickar e-post till någon som vidarebefodrar sin e-post till någon annan e-postadress. Vår rekommendation är att använda ~all.

För att sätta DKIM, se artikeln Hur aktiverar jag DKIM?

För att sätta DMARC rekommenderar vi Postmark som erbjuder en gratis-tjänst för detta.

Dessa steg skall man alltid göra. Man kan också gå med i Googles "Postmaster Tools" program för att förbättra sina möjligheter att skicka e-post till Gmail. Lite instruktioner går att hitta i deras forum.

Denna Google artikel ger också bra råd för hur man undviker att bli blockad av Gmail.

I ISPConfig finns ett alternativ för att ladda ned säkerhetskopior till sin egna dator. Detta är också något vi rekommenderar att det görs regelbundet.

Gå till Webbplatser/Webbplats och klicka på aktuell webbplats. Klicka sedan på fliken Backup.

Efter en stund har säkerhetskopiorna skapats i katalogen /backup. Ni kan då ladda ned dessa till er lokala dator med ftp.

Antagligen använder ni localhost för att ansluta till MySQL. 

Av säkerhetsskäl lever alla websiter i ett eget fängelse (jail), de kan inte se något från andra websiter som inte ägs av samma konto. Det går inte att se filer från andra websiter, inte eller går det att se systemfiler. Till systemfiler hör den socket som man kopplar sig till MySQL om man använder localhost. 

Eftersom denna socket inte är synlig behöver man koppla sig till MySQL på ett annat sätt, och det är över nätet, fast lokalt på servern.

Istället för localhost skall därför 127.0.0.1 användas som databasserver.

Är ni Admin och ni har skapat e-postkonton åt andra personer, då kan dessa personer själva ändra på inställningar för sitt e-postkonto utan att behöva fråga er som admin.

Som ägare till ett e-postkonto kan de själv göra följande:

• Ändra lösenord för e-postkontot
• Aktivera auto-svar
• Skicka kopia på alla inkommande mail
• Sätta skräppostfilter
• Sätta filter för inkommande e-post.

Att skicka kopia på alla inkommande mail skall endast göras till samma domän. Till exempel att brev till kalle@doman.se kan skickas till anna@doman.se. Sätter man upp vidarebefodring till andra domäner kommer dessa att tas bort av systemet.

Först loggar ni som e-postanvändare in till kontrollpanelen ISPConfig, https://ic.etableraweb.com:8080. Ni anger er e-postadress som användarnamn och som lösenord anger ni e-postadressens lösenord.

När ni väl loggat in möts ni av denna bild:

Inledning

Detta kan hända om ni inte har en fungerande SSL, dvs fungerande https, för er webbplats. Då kommer https://minwebplats.se att visa någon annans webbplats. http://minwebbplats.se kommer dock att visa er webbplats, OM INTE ni har satt automatiskt vidarebefodring till https.

Har ni bara den Enkla kontrollpanelen, då behöver ni kontakta Kundtjänst.

Steg 1 - Tag bort vidarebefodring

Tag bort automatiskt vidarebefodring gör https:

Klicka på "Spara" och vänta några minuter och se om er hemsida nu fungerar med http, dvs http://minwebplats.se. Gör den inte det, då behöver ni kontakta Kundtjänst.

Steg 2 - Tag bort SSL

Nästa steg är att ta bort SSL från webbplatsen, om den är satt. 

Se till att SSL och Let's Encrypt är avmarkerade och klicka sedan på "Spara". Vänta några minuter och kontrollera om er webbplats fungerar med http. Om den inte gör det, kontakta Kundtjänst.

Steg 3- Aktivera SSL med Let's Encrypt

SIsta steget är nu att aktivera SSL med Let's Encrypt. Kryssa nu för rutorna SSL och Let's Encrypt:

och klicka på "Spara", vänta några minuter, typ 5, och prova nu er webbplats med https. Om det inte fungerar nu, kontakta Kundtjänst.

1. Skapa record i DNS, antingen som A eller AAAA (typ hemma.foo.com). Ange godtycklige IP Adress
   
2. Skapa en hemlig DynDNS token för namnet hemma.foo.com. Ni behöver inte ange Begränsningar, det är mest till för säkerhet. Det anger ni bara om ni vill använda olika URLer/credentials för olika subdomäner. I regel kan ni lämna den tom.
   
3. Klicka på länk knappen så visas de URL'er ni skall använda för att uppdatera er IP Adress

Den URL ni skall använda ser ut enligt följande:

https://ic.etableraweb.com:8080/ddns/update.php?zone=ikasp.com.&type=A&record=hostname&data=YOUR_IP_ADDRESS&token=*****

Variabler:

zone: Er huvuddomän skall anges här. Observera att namnet måste avslutas med en punkt (.).
type: Typ av record. Kan vara A eller AAAA.
record: Den subdomän av huvuddomänen som skall sättas. I exemplet ovan kontor.
data: Den IP adress som ni vill sätta hostnamnet till. Ni kan utesluta denna, så kommer den IP adress från den datorn som anropet kommer ifrån att användas.
token: unik och hemlig sträng som genereras av ISPConfig

Enklast att använda denna funktion är att ange typ följande adress i er webbläsare:

https://ic.etableraweb.com:8080/ddns/update.php?zone=ikasp.com.&type=A&record=kontor&token=*****

IP adressen för kontor.ikasp.com kommer i detta exempel då att sättas till samma IP-adress som anropet kommer från.

Det går naturligtvis att automatisera detta med t.ex. cron:

curl -q 'https://ic.etableraweb.com:8080/ddns/update.php?zone=ikasp.com.&type=A&record=kontor&token=*****'

Anropa inte uppdateringar för ofta. I regel räcker det att göra det någon gång per dag. Oftare än per timme är inte meningsfullt då TTL för DNS records är satta till minst 1 timme.

Notera att alla parametrar förutom 'data' måste anges.

Vad gäller paarametern record kan den vara lite speciell.

Huvuddomän

Om det är huvuddomänen ni avser, då skall ni ange själva domännamnet med en avslutande punkt, t.ex 

record=ikasp.com.

Underdomäner

Vad ni skall ange för record här beror på vad som anges i er DNS zone. I regel räcker det med ange första delen av hela hostnamnet, men det kan också krävas att man sätter det kompletta domännamnet för underdomänen.

I exemplet ovan när man vill sätta DNS record för kontor.ikasp.com, kan det finnas två alternativ.

Det första, och det vanligaste är

record=kontor

men det kan också vara

record=kontor.ikasp.com.

notera den avslutande punkten. 

Vilken variant det skall vara kan ni se om ni tittar i DNS zonen och där ser hur detta record är definierat. Ett annat sätt är att helt enkelt prova sig fram.

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

php miljön ser lika ut i er cron och inloggning med ssh som er webbsida.

Vi erbjuder php 5.6, 7.4 och 8.x.

För installerade moduler och konfig för senaste php-version, se

https://phpinfo.webbmotell.se/

Som standard använder varje app som installeras med Installatron sin egen databas. Installerar ni många appar då krävs också många databaser. Ni har i regel ett begänsat antal databaser till ert förfogande.

Har ni inte tillgång till ISPConfig kontrollpanelen, då behöver ni uppgradera ert konto så att ni får det.

Ni kan annars göra något av följande:

1. Kontrollera om alla era databaser verkligen används till något. Ta bort dem som ni inte använder. Var mycket noga här med att verkligen inte ta bort sådana som ni använder.
2. Uppgradera er webbhotellplan med fler databaser.
3. Använd en databas för flera appar. Detta är möjligt i Installatron.

Använd en databas för flera appar

När ni installerar en app med Installatron, välj då att den skall använda en befintlig databas. Ni behöver då veta vilket databasnamn, databas-användarnamn och lösenordet till denna. I regel hittar ni detta i någon redan installerad app.

Till exempel om ni har WordPress installerad och vill använda den databasen, då hittar ni databasinformation i filen wp-config.php:

// ** Database settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'X68i22989999' );

/** Database username */
define( 'DB_USER', 'X68i2298' );

/** Database password */
define( 'DB_PASSWORD', 'a1609Q79d816!ba18ASb64a_64b613f3Bb' );

/** Database hostname */
define( 'DB_HOST', '127.0.0.1' );

När ni installerar en ny app i Installatron, gå då till section Utökad längst ned på sidan.

Fyll då in databasuppgifterna manuellt. Det är Tabellprefix som kommer att skilja de olika apparna från varandra i databasen. Ändra inte denna.

För att använda Microsoft 365 e-post måste ett antal DNS records sättas. Dessa records anger Microsoft för er, de är unika för varje användare.

Dessa records måste ni sätta manuellt i er DNS. Enklast är att göra det i den Enkla Kontrollpanelen.

1. Tag bort alla "AUTOMAIL records" genom att klicka på den knappen.
2. Tag bort alla MX records.
3. Tag bort ert autodiscover record.
4. Tag bort ert SPF record.

Nu kan ni lägga in de records som Microsoft angivit. I den enkla kontrollpanelen brukar det se ut så här:

Notera de avslutande punkterna. Dessa är mycket viktiga.

Där ett TXT record som är unikt för er satts, ett MX record som pekar mot Microsofts e-postserver, ett CNAME record som pekar på Microsofts autodiscovertjänst och slutligen ett SPF record som är anpassat för Microsoft 365 e-post. Ni behöver dock lägga till include:_spf.ewn.se till denna om ni också skickar e-post via er hemsida. Vi rekommenderar också att ni använder ~a istället för -a.

Inledning

Inloggning med ssh måste ske med ett ssh nyckelpar. Det går inte att logga in med lösenord. Gången är

1. Skapa ett ssh nyckelpar på er lokala klient
2. Lägg in den publika nyckeln för er shell-användare i ISPConfig.
3. Ange nyckelparet i er ssh-klient när ni loggar in.

Skapa ssh nyckelpar

Ett nyckelpar som består av en privat och en publik nycket måste först skapas på er lokala klient. Denna skapas i regel med ssh-keygen. På MacOS och Linux finns i regel denna redan installerad och skapas enkelt via kommandoraden.

Googla/Duckducka/Binga efter "How to Generate SSH key on Windows/MacOS/Linux" för att hitta lämpliga artiklar.

En lämplig artikel för Windows är https://www.howtogeek.com/762863/how-to-generate-ssh-keys-in-windows-10-and-windows-11/ (Bild).

Lägg in den publika nyckeln för shell-användaren

Logga in till er ISPConfig kontrollpanel och gå till Shell-användare. Ni kan här också skapa nya shell-användare. Välj ut den shell-användare ni vill välja och klicka på denna.

Kopiera er PUBLIKA nyckel till "SSH-RSA Offentlig nyckel" fältet och klicka på Spara.

När ni har gjort det kan ni nu logga in med ssh, med exemplet ovan, ssh bnekvqtkssh@www1.ic.etableraweb.com.

Eftersom angripare kommer från mycket stora IP-adressområden är det inte alltid .htaccess är en god idé. .htaccess är också resurskrävande om den är stor. Att blockera ett hundratal explicita IP adresser, eller hela subnät är dock inga problem

//Blocka en IP
Deny from 192.168.0.3
//Blocka flera IP
Deny from 111.111.111.111 222.222.222.222 333.333.333.333
//Blocka subnät, i detta fall blockas 192.168.*.*
Deny from 192.168

Om det är enbart vissa IP adresser ni vill tillåta, då kan ni sätta Deny som standard och sedan sätt Allow för de IP adresser ni vill tillåta.

Order Deny,Allow
Deny from all
Allow from 192.168.2.3 192.168.2.3 192.168.10

Kontakta gärna Kundtjänst för information om tjänster som kan tillhandahållas. T.ex. blocka all besökare från ett eller flera länder, bara tillåta besökare från vissa länder och så vidare.

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

Här är en bra artikeln, på engelska förvisso, som beskriver hur man skapar ett e-postkonto i ISPConfig. Den beskriver den fullständiga processen med att först skapa en maildomän för den aktuella domänen och sedan skapa e-postkontot. I regel är maildomänen redan skapad, men om det gäller tilläggsdomäner, då behöver man lägga till dem som maildomäner också.

How to Add an Email Account in ISPConfig 3.2

Vi rekommenderar att man använder SMTP för att skicka mail, och anledningen till det är att man då skickar e-post genom att autentisera sig och att då brevet tydligt kommer från en korrekt avsändare, och också i regel DKIM signerat.

Den inbyggda mail() funktionen i php använder programmet sendmail för att skicka e-post. Detta skickas då från www servern och som verklig avsändare kommer mottagaren att se själva servern, oavsett vad ni satt som From adress.

Även om det fungerar att skicka e-post, använder många e-postleverantörer, som Gmail, Outlook och andra, en mängd olika verktyg för att minska e-postspam. Dessa verktyg försöker upptäcka att ett e-postmeddelande verkligen kommer från den plats som det påstår sig vara plus flera ytterligare tester.

E-postmeddelanden som skickas via php's inbyggda mail() funktion misslyckas ofta i dessa test.

Detta innebär att när ett e-postmeddelande skickas ut från din webbplats (kontaktformulärplugin, adminavisering, etc), kanske det inte ens hamnar i mottagarens skräppostmapp, än mindre i inkorgen.

Det absolut bästa är att använda SMTP för att skicka mail med php. Ett enkelt sätt att göra det är att använda GitHub - PHPMailer/PHPMailer: The classic email sending library for PHP. Denna installerar ni enkelt på er hemsida.

För att skicka mail med SMTP med PHPMailer behöver ni först skapa ett e-postkonto på er mailserver, typ smtp@foo.com. Detta skapar ni med ett bra lösenord.

När ni sedan kodar i php använder ni följande för PHPMailer:

    $mail = new PHPMailer\PHPMailer();
    $mail->IsSMTP();
    $mail->Host = $SMTP['smtp_host_name'];
    $mail->Hostname = $SMTP['smtp_host_name'];
    $mail->Port = 587;
    $mail->SMTPSecure = 'tls';
    $mail->SMTPAuth = true;
    $mail->Username = $SMTP['smtp_user_name'];
    $mail->Password = $SMTP['smtp_user_pw'];
    $mail->Sender = $SMTP['smtp_user_name'];

Där $SMTP['smtp_user_name'] är smtp@foo.com i exemplet och $SMTP['smtp_user_pw'] dess lösenord. Där $SMTP['smtp_host_name'] är er e-postserver.

Nu är det möjligt att använda 2FA inloggning ISPConfig. Detta aktiveras genom Verktyg >> Användarinställningar, enligt bilden nedan.

För nuvarande finns bara alternativet 2-Faktor med e-post. Implementering med typ authenticator finns dessvärre inte med på ISPConfigs roadmap.

Ja, composer finns installerad som standard.

Skapa en shell användare och logga sedan in till denna med ssh.

Gå till er webbplats, typiskt 

cd /web

och ge ert composer kommando.

Om inte composer finns i /usr/local/bin, kontakta i så fall kundtjänst.

När ni har loggat in till en shell user med ssh, då finns det två sätt att se vilka versioner av php som finns tillgängliga.

Vilken version som är standard beror på vilket operativsystem som är installerat på servern. Ge kommadot "php --version" så ser ni vilket php version som är standard:

I detta fall är det version 7.3 som är standard.

För att se vilka ytterligare versionen av php som finns tillgängliga finns det (minst) två olika sätt:

Alternativ 1

Ange php på kommando raden och sedan TAB direkt efter:

I detta fall finns versionerna 7.0, 7.3, 7.4, 8.1 och 8.2 tillgängliga.

Alternativ 2

php binärerna ligger i regel i /usr/bin. Lista alla php binärer med kommandot ls -l /usr/bin/php*:

varvid ni kan identifiera vilka versioner som finns installerade.

För att använda t.ex. php version 8.2, använd då binären php8.2:

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

Om du är iCloud-användare och du har funnit ett behov av att dela ut en kalender till en applikation via en URL, har du förmodligen stött på ett antal hinder. Med en kalender-URL kan du använda den för att prenumerera på en kalender i ett program utanför Apples universum (som med Google eller Thunderbird/Lightning). Att hitta webbadressen till en offentlig kalender är väldigt enkelt:

1. Logga in på iCloud.
2. Öppna Kalender-appen.
3. Klicka på den nedtonade "trådlös"-ikonen.
4. Klicka på Offentlig kalender.
5. Kopiera den givna webbadressen (den börjar med webcal).

Du kan sedan använda den webbadressen för att prenumerera på kalendern i fråga. 

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

Dåligt.

En av de vanligaste frågorna användare av WordPress har är hur man åtgärdar problem med WordPress som inte skickar e-post.

Många användare på nybörjarnivå frågar varför deras plugin för kontaktformulär inte skickar e-post, eller varför de inte ser några WordPress-aviseringar.

I den här artikeln kommer vi att visa hur man åtgärdar problemet med att WordPress inte skickar e-post, så att din webbplats kan skicka e-postmeddelanden mer tillförlitligt och kringgå skräppostmappen. Ett annat alternativ är de lösningar som diskuteras i How to Change Sender Name in Outgoing WordPress Email och mer explicit i How to Fix WordPress Not Sending Email Issue. Dessa artiklar rekommenderar WP Mail SMTP plugin, medan vi  i denna artikel rekommderar Post SMTP.

WordPress har mycket dåligt stöd för att skicka e-post. WP använder den mailfunktion, mail(), som php tillhandahåller. Denna i sin tur använder sendmail() från operativsystemet. Detta ställer till problem när man skall skicka e-post, e-post man skickar uppfattas i regel som skräp av mottagarna, läs mer om detta i artikeln Hur kan jag använda mail med php?

Problemet med WordPress är denna inte erbjuder alternativ till detta. De flesta andra system som bygger på php gör det, men inte WP.

Lösningen är att installera en plugin till WordPress. Den plugin som vi rekommenderar är Post SMTP.:

Konfigurerar om funktionen wp_mail() för att använda Gmail/Mailgun/SendGrid/SMTP istället för standardmail() och skapar en alternativsida för att hantera inställningarna.

Med denna kan ni använda ert vanliga e-postkonto för att skicka e-post, eller skapa ett dedikerat e-postkonto för just WP.

Installera denna plugin och starta dess Setup Wizard. På första sidan anger ni en e-postadress som ni redan har skapat och som ni vet fungerar.

Nästa steg är att ange er mailserver. Nedan är ett exempel, ni får kontrollera med er leverantör vilken mailserver ni har.

När ni angivit mailserver och e-postadress kommer Post SMTP att försöka hitta er leverantör för e-post, och naturligtvis kommer denne att promota diverse kommersiella aktörer, POST SMTP är som sagt gratis. Efter en liten stund kommer denna bild fram.

Välj här ett av SMTP alternativen. I regel är alternativet på port 587 det säkraste och bästa, i andra hand port 465.

Nästa steg är att ange lösenordet den e-postadress ni angivit.

Lösenordet kommer att lagras någonstans i WordPress, hur vet man inte. Därför rekommenderar vi att ni skapar ett dedikerat e-postkonto för att skicka e-post, typ smtp@datest.se i detta fall. Använd denna endast för att skicka e-post, och för att bevaka e-poststudsar på mail ni har skickat.

I nästa steg kan ni sätta upp någon typ av monitorering av hur det går att skicka er e-post. Ni väljer här det som är lämpligt för er.

Nu när ni är klar med inställningarna återstår att testa att det fungerar. Klicka Send a Test Email och följ sedan instruktionerna.

Lyckas det skall ni få bilden ovan.

Ni kan sedan titta på era inställningar som denna wizzard nu skapat åt er. Ni kan också ändra dessa nu i efterhand, utan att behöva gå igenom wizzard igen.

Det skall se ut typ så här:

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

Att sätta upp alias eller vidarebefodring för befintligt e-postkonto fungerar inte.

Dock går det att sätta upp så att alla mail som kommer in också skickas vidare som CC till en annan e-postadress.

Detta görs enklast i webmail, https://webmail.webbmotell.se. Se denna bild för vägledning.

Har ni tillgång till kontrollpanelen ISPConfig kan ni också göra det där, med lite fler alternativ:

Skapa första ett mail som skall skickas. Klicka sedan på de tre cirklarna enligt bilden nedan.

Klicka sedan på Alternativ och bilagor enligt bilden nedan.

Klicka sedan på Bifoga fil för att ladda upp bilagan.

Dessa instruktioner gäller oavsett vilken enhet man använder, dator, mobiltelefon, padda, laptop osv.

Se denna film

I syfte att skydda användarnas e-post tillkännagav Gmail och Yahoo Mail en ny uppsättning krav för avsändare som gäller från februari 2024. Låt oss fördjupa oss i detaljerna och vad man behöver göra för att uppfylla dessa krav.

Vilka är de nya kraven för e-postavsändare?

De nya kraven inkluderar långvariga bästa praxis som alla e-postavsändare bör följa för att uppnå god leveransbarhet med postlådeleverantörer. Vad som är nytt är att Gmail, Yahoo Mail och andra postlådeleverantörer kommer att kräva anpassning till dessa bästa praxis för dem som skickar massmeddelanden över 5 000 per dag eller om ett stort antal mottagare anger att e-posten är skräppost.

Kraven kan destilleras in i tre kategorier: 1) striktare efterlevnad av domänautentisering, 2) ger mottagarna ett enkelt sätt att avbryta prenumerationen på massutskick och 3) övervakar antalet skräppostklagomål och håller dem under en tröskel på 0,3 %.

1. Domänautentisering

E-posteleverantörer kommer att kräva domänjusterad autentisering med DKIM och SPF, och de kommer att tillämpa DMARC-policyer för domänen som används i meddelandehuvudet From. De flesta e-postleverantörer gör inte det idag, möjligen använder man resultater från DMARC till att öka sannolikheten att brevet är skräp.

Till exempel kommer gmail.com att publicera en DMARC-policy som anger karantän, vilket innebär att obehöriga meddelanden som påstår sig vara från Gmail skall skickas till mottagarens skräppostmapp.

Har man då t.ex. en hemsida där man använder en gmail-epostadress för att skicka meddelanden till sina kunder, och man skickar brevet från den server som hemsidan ligger på, då kommer inte  DMARC att vara uppfyllt och mottagarens e-postsystem skall då lägga brevet i skräpkorgen. Skickar man till en gmail eller yahoo adress, då kommer definitivt brevet hamna i mottagarens skräpkorg.

Läs Artikeln: E-postautentisering och få ut värdet av en DMARC-policy för att få en djupare förståelse av SPF- och DKIM-domänanpassning och maximera värdet av din domäns DMARC-policy.

Det man behöver göra är att se till att ens domännamn lever upp till DMARC. För att ett domännamn skall leva upp till DMARC, då behöver SPF och DKIM sättas och e-post endast skickas från servrar där dessa är uppfyllda.

Vill man vara säker på att sina meddelanden verkligen skall komma fram till gmail och yahoo adresser, och sannolikt många andra, då skall man sätta DMARC, oavsett om man skickar över eller under 5000 meddelanden per dag.

2. Skapa en enkel avregistrering för e-postmottagare

Krav nummer 2 gäller massutskick av e-post, typ nyhetsbrev.

Bulksändare förväntas inkludera en mekanism för att avsluta prenumerationen genom att lägga till en länk i meddelandet som är lätt att hitt. Reglerna för postlådeleverantörer från februari 2024 kommer att kräva att avsändare dessutom lägger till rubriker för att avbryta prenumerationen med ett klick enligt definitionen i RFC 2369 och RFC 8058. Dessa rubriker gör det lättare för mottagare att avbryta prenumerationen, vilket minskar andelen  mottagare som kommer att klaga genom att markera meddelanden som skräppost .

Det finns många faktorer som kan leda till att dina meddelanden klassificeras som bulk av en e-postleverantörer. Volymer över 5000 per dag är en faktor, men den primära faktorn som postleverantörer använder är om mottagaren verkligen vill ta emot breven.

Så här lever du upp till kravet på enkel avregistrering

Följande steg beskriver hur man kan leva upp till kravet på enkel avregistrering:

Lägg till rubriker för att avsluta prenumerationen med ett klick till meddelandena du skickar: Skickar man massmeddelanden eller potentiellt oönskade meddelanden måste  man implementera en ett enkelt sätt för mottagare att avsluta prenumerationen.

E-postleverantörer kräver, eller kommer att kräva, att stora utskick ger mottagare möjlighet att avbryta prenumeration på massmejl med bara ett klick på en länk i meddelandet. Det är acceptabelt att avregistreringslänken i meddelandet dirigerar mottagaren till en webbsida för mottagaren att bekräfta sina inställningar och då avsluta/ändra prenumerationen.

För att uppnå detta, inkludera båda dessa rader i e-posthuvudet i det utgående meddelandet:

• List-Unsubscribe-Post: List-Unsubscribe=One-Click
• List-Unsubscribe: <https://example.com/ avregistrera/exempel>

Du behöver då implementera en av-prenumerationsfunktion på https://example.com/ avregistrera/exempel.

Gmails FAQ och Yahoos FAQ förtydligar båda att kravet på att avbryta prenumerationen med ett klick inte kommer att tillämpas förrän i juni 2024 så länge som masssändaren har en funktionell avregistreringslänk som är tydligt synlig i sidfoten i varje meddelande.

Besvara begäranden om att avsluta prenumerationen inom 2 dagar: Kontrollera att din avregistreringsprocess omedelbart tar bort mottagaren från att ta emot liknande framtida meddelanden. E-posteverantörer kräver att massavsändare ger mottagarna möjlighet att avsluta prenumerationen på e-post med ett klick, och att avsändarna behandlar begäranden om avregistrering inom två dagar.

Granska dina e-postlistor: Säkerställ en ansvarsfull e-postpraxis genom att avstå från att köpa e-postlistor, skydda opt-in-formulär från botmissbruk, verifiera mottagarnas preferenser genom bekräftelsemeddelanden och avstå från att automatiskt registrera mottagare i kategorier som inte efterfrågades.

3. Övervaka skräppostfrekvensen

E-postleverantörer kommer att kräva att alla avsändare håller andelen spamklagomål under 0,3 % för att undvika att deras e-post behandlas som skräppost av brevlådeleverantören. 

Registrera dig med Google Postmaster Tools: Man bör registrera sig för Google Postmaster Tools för att övervaka antalet skräppostklagomål för Gmail-mottagare.

Gmail rekommenderar att andelen skräppostklagomål håller sig under 0,1 %. Om du skickar till en blandning av Gmail-mottagare och mottagare hos andra brevlådeleverantörer, är andelen skräppostklagomål som rapporteras av Gmails Postmaster Tools en bra indikator på antalet skräppostklagomål hos brevlådeleverantörer som inte låter dig se statistik.

Slutsats

Dessa ändringar är planerade till februari 2024, men tänk på att den exakta tidpunkten och de metoder som används av varje postlådeleverantör kan variera. Om du upplever leveransproblem med någon postlådeleverantör före februari, är det i ditt bästa intresse att följa dessa nödvändiga bästa praxis som ett första steg.

Vi hoppas att den här artikeln klargör eventuella områden av förvirring om denna förändring och ger dig den information du behöver för att vara förberedd inför februari 2024. 

Användbara länkar:

• Gmail-meddelande: https://blog.google/products/gmail/gmail-security-authentication-spam-protection/
• Yahoo Announcement: https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam

Källa: https://aws.amazon.com/blogs/messaging-and-targeting/an-overview-of-bulk-sender-changes-at-yahoo-gmail/

Inledning

För företag av alla storlekar är e-post en viktig del av infrastrukturen som stöder stora mängder kommunikation. För att förbättra säkerheten och pålitligheten för e-postkommunikation vänder sig många organisationer till e-postleverantörer (ESP) som webbmotell.se. Dessa ESP:er tillåter användare att skicka autentiserade e-postmeddelanden från sina domäner, genom att använda industristandardprotokoll som Sender Policy Framework (SPF) och DomainKeys Identified Mail (DKIM). Meddelanden som autentiserats med SPF eller DKIM kommer att klara din domäns policy för domänbaserad meddelandeautentisering, rapportering och överensstämmelse (DMARC).

Den här artikeln kommer att fokusera på DMARC:s policytillämpningsmekanism. Artikeln kommer att utforska några av anledningarna till att e-post kan misslyckas med DMARC-policyutvärderingen och föreslå lösningar för att åtgärda eventuella fel som du identifierar.

För en introduktion till DMARC och hur du noggrant väljer din e-postsändande domänidentitet. DMARC-efterlevnad är kritiskt för e-postleverans och är avgörande för organisationer som strävar efter att upprätthålla ett positivt avsändarrykte och säkerställa framgångsrik e-postleverans.

Det finns många fördelar när organisationer har denna korrekta inställning, dessa inkluderar:

• Förbättrad e-postleverans
• Minskad risk för att bli utsatt för e-postförfalskning och nätfiske
• Positivt avsändarrykte
• Minskad risk för att skickad e-post hamnar i mottagarens skräpkorg
• Ert "Brands" rykte.

Utifrån detta, låt oss utforska komplexiteten med DMARC och hur det kan gynna din organisations e-postkommunikation.

Vad är DMARC?

DMARC är en mekanism för domänägare att publisera SPF- och DKIM-skydd och berätta för mottagare hur de ska agera om dessa autentiseringsmetoder misslyckas.

Domänens DMARC-policy skyddar din domän från tredje part som försöker förfalska domänen i e-postheadern "From:" i e-postmeddelanden. Skadliga e-postmeddelanden som syftar till att skicka nätfiskeförsök med din domän kommer att bli föremål för en DMARC-policyutvärdering, vilket kan leda till att de sätts i karantän eller avvisas av den e-postmottagande organisationen. Denna strikta policy säkerställer att e-postmeddelanden som tas emot av e-postmottagare verkligen kommer från den påstådda sändningsdomänen, vilket minimerar risken för att människor faller offer för e-postbaserade bedrägerier.

Domänägare publicerar DMARC-policyer som en TXT-post i domänens _dmarc.<domain> DNS-post. Till exempel, om domänen som används i "From:"-rubriken är exempel.se, så skulle domänens DMARC-policy finnas i en DNS TXT-post med namnet _dmarc.exempel.se. DMARC-policyn kan ha ett av tre policylägen:

• En typisk DMARC-distribution av en befintlig domän börjar med att publicera "p=none". En ingen-policy betyder att domänägaren befinner sig i en övervakningsfas; domänägaren övervakar meddelanden som inte är autentiserade med SPF och DKIM och försöker se till att all e-post är korrekt autentiserad
  
  
• När domänägaren är säker på att alla legitima användningsfall är korrekt autentiserade med SPF och/eller DKIM, kan de ändra DMARC-policy till "p=quarantine". En karantänpolicy innebär att meddelanden som misslyckas med att skapa en domänjusterad autentiserad identifierare via SPF eller DKIM kommer att sättas i karantän av den e-postmottagande organisationen. Den e-postmottagande organisationen kan filtrera dessa meddelanden i skräppostmappar eller vidta en annan åtgärd som de anser bäst skyddar sina mottagare.
  
  
• Slutligen kan domänägare som är övertygade om att alla legitima meddelanden som använder deras domän är autentiserade med SPF eller DKIM ändra DMARC-policyn till "p=reject". En avvisningspolicy innebär att meddelanden som misslyckas med att skapa en domänjusterad autentiserad identifierare via SPF eller DKIM kommer att avvisas av den e-postmottagande organisationen.

Följande är exempel på en TXT-post som innehåller en DMARC-policy, beroende på önskad policy (p-taggen):

Denna policy säger åt e-postleverantörer att tillämpa DMARC-policyn på meddelanden som inte skapar en DKIM- eller SPF-autentiserad identifierare som är anpassad till domänen i "From"-huvudet. Justering innebär att en eller båda av följande inträffar:

• Meddelanden passerar SPF-policyn för MAIL FROM-domänen och MAIL FROM-domänen är densamma som domänen i "From"-huvudet, eller en underdomän av denna.
• Meddelanden har en DKIM-signatur signerad av en offentlig nyckel i DNS på en plats inom domänen för "From:"-huvudet. 

DMARC-rapportering

Rua-taggen i domänens DMARC-policy anger platsen dit e-postmottagande organisationer ska skicka sammanställda rapporter om meddelanden som godkänner eller misslyckas med SPF- och DKIM-anpassning. I regel är detta en e-postadress, typ rua=mailto:dmarcreports@exempel.se.

Domänägare, dmarcreports@exempel.se i detta exempel, analyserar dessa rapporter för att upptäcka meddelanden som använder domänen i "From:"-huvudet men som inte är korrekt autentiserade med SPF eller DKIM. Domänägaren kommer att försöka säkerställa att alla legitima meddelanden autentiseras genom analys av DMARC:s samlade rapporter över tid.

E-postmottagande organisationer som stöder att skicka DMARC-rapporter skickar vanligtvis dessa sammanställda rapporter en gång om dagen, även om dessa metoder skiljer sig från leverantör till leverantör.

Vad skall man typiskt göra för implementera DMARC framgångsrikt?

I ett nötskal:

• Se till att alla e-postmeddelanden som använder domänen i "From:"-huvudet autentiseras med DKIM- och SPF-domänjusterade identifierare. Fokusera på DKIM som det primära sättet för autentisering.
• Publicera en DMARC-policy (none, quarantine, eller reject) för domänen som återspeglar hur domänägaren vill att e-postmottagande organisationer ska hantera oautentiserad e-post som påstår sig vara från deras domän.

Nya domäner och underdomäner

Det är enkelt att implementera DMARC för domäner och subdomäner som aldrig använts för e-post. Man har ingen ryggsäck här att ta hänsyn till.

Dessa domäner kan börja direkt med "p=reject" DMARC-tillämpningspolicy eftersom policyn inte kommer att påverka befintliga program för att skicka e-post. Denna strikta tillämpning är till för att säkerställa att det inte finns någon oautentiserad användning av domänen och dess underdomäner.

Befintliga domäner

Domäner, och subdomäner, som redan används för e-post, där är det lite trickigare. Problemet här är att få kolla på hur domänen används för att skicka e-post, vilka organisationer använder den, vilka hemsidor och program använder den, och när de använder den, vilka e-postservrar skickar de igenom, och så vidare.

För dessa är en DMARC-implemtentering en iterativ process. Det är viktigt att få en fullständig förståelse för hur domänen och dess underdomäner används för e-postsändning innan du publicear en restriktiv DMARC-policy (p=quarantine eller p=reject).

För att komma igång med DMARC-implementeringen är det här några åtgärder att vidta:

1. Publicera en p=none DMARC-policy (ibland kallad övervakningsläge) och ställ in rua-taggen till den mottagre där du vill ta emot samlade rapporter.
2. Analysera de samlade rapporterna. E-postmottagande organisationer skickar rapporter som innehåller information för att avgöra om domänen och dess underdomäner används för att skicka e-post och hur meddelandena autentiseras (eller inte) med en DKIM- eller SPF-domänjusterad identifierare. Ett lättanvänt analysverktyg är Dmarcian XML to Human Converter.
3. Undvik att publicera en "p=quarantine"- eller "p=reject"-policy i förtid. Om du gör det kan det leda till blockerad eller minskad leverans av legitima meddelanden från befintliga e-postprogram.
   
   

Ett alternativ att börja använda DMARC på en befintlig domän är att skapa en helt ny subdomän och använda denna för att skicka e-post. Denna är då "ren" och man kan vara säker på att den uppfyller en restriktiv DMARC och mail från denna kommer att komma fram. "Ryggsäcken" får man hantera med en ingen-policy under en period.

Överhuvudtaget är det en mycket bra ide att skapa separata subdomäner för massutskick av mail. Dessa riskerar i mycket större omfattning att bli "skitiga" och när de väl blir det, påverkar det inte den ordinarie domänen som organsiationen skickar vanlig mail med.

Bilden nedan illustrerar hur DMARC kommer att tillämpas på ett e-postmeddelande som tas emot av den e-postmottagande servern och åtgärder som vidtas baserat på tillämpningspolicyn:

För att DMARC skall uppfyllas hos den mottande e-postservern måste båda resultaten ovan vara Y.

Hur får SPF och DKIM DMARC att uppfyllas?

Hur SPF lever upp till DMARC

När du skickar ett e-postmeddelanden sätts automatiskt av e-post servern en MAIL FROM adress genom att sätta ett e-posthuvud Return-Path. Denna kan se ut så här:

Return-Path: <kalle@exempel.se>

När man skall skicka e-post måste man autentisera sig. Det gör man med sin e-postadress och lösenordet till denna (i regel). I detta exempel är det kalle@exempel.se som autentiserat sig. E-postservern vet då att det är just det här e-postkontot som skickar brevet. Denna rad är inte något som man som användare kan påverka, det är servern som sätter den. Till skillnad till From: raden i e-posthuvudet som användaren kan sätta till vad som helst i sin e-postklient. Så, MAIL FROM kan man lita på, men inte på From:.

När den mottagande e-postservern skall utvärdera SPF tittar den på den SPF policy som MAIL FROM domänen (exempel.se i detta exempel) har. Denna skall då innehålla den avsändande e-postserver, dess IP-adress mer specifikt. Stämmer det, då får man "SPF=PASS".

Utöver "SPF=PASS" kräver DMARC att MAIL FROM domänen och From: domänen hör ihop, dvs att de antingen är desamma eller att MAIL FROM är en subdomän till From: domänen. Det sistnämnda fungerar endast om DMARC innehåller direktivet aspf=r, vilket är standardinställning om man inte anger den alls. r står här för relaxed.

Hur DKIM lever upp till DMARC

Två kriterier:

1. Att DKIM aktiverats för er domän. Detta är något ert webbhotell gör. Med ISPConfig kan användaren gör det själv, har man bara tillgång till den Enkla kontrollpanelen behöver man kontakta support.
2. Att man alltid skickar mail via sin mailserver hos webbhotellet. Detta är särskilt viktigt att tänka på när man skickar e-post från sin hemsida, t.ex. om man använder WordPress. Som standard skickar dessa e-post genom webbservern, och då kommer inte DKIM vara uppfyllt.

DMARC ställer dock ytterligare ett krav på DKIM, vilket också framgår av bilden ovan. MAIL FROM domänen måste vara samma som den är i "d=" taggen i DKIM-signaturen som finns i själva e-postbrevet.

DKIM och SPF tillsammans

E-postmeddelanden är helt autentiserade när meddelandena passerar både DKIM och SPF, och både DKIM- och SPF-autentiserade identifierare är domänjusterade, dvs att de angivna domänerna stämmer överens enligt bilden ovan.

Om endast DKIM är domänjusterat, kommer meddelandena fortfarande att passera DMARC-policyn, även om SPF "pass" är ojusterat. E-postmottagare kommer att ta hänsyn till hela sammanhanget för SPF och DKIM när de avgör hur de kommer att hantera dispositionen av meddelandena du skickar, så det är bäst att fullständigt autentisera dina meddelanden när det är möjligt.

Google har satt som krav att antingen DKIM eller SPF skall vara uppfyllt för att brev överhuvudtaget skall tas emot. Här behöver de inte vara domänjusterade. Dock, om någon av dessa fallerar, då är det sannolikt att brevet tas emot, men hamnar i mottagarens skräpkorg.

Skickar man stora mängder mail till Google gmail adresser, då kräver Google att DMARC uppfylls fullt ut för att ta emot mailet.

Webbhotellet förenklar i regel denna process väsentligt, genom att kunna göra det genom några klick.

Varför misslyckas DMARC?

Det finns tillfällen då du kanske märker att meddelanden misslyckas med DMARC, oavsett om dina meddelanden är helt autentiserade eller delvis autentiserade. Följande är saker du bör hålla utkik efter:

Ändring av e-postinnehåll Ibland ändras e-postinnehåll under leveransen till mottagarnas e-postservrar.

Denna ändring kan vara ett resultat av en säkerhetsanordning eller anti-spam-agent längs leveransvägen (till exempel: meddelandet Ämne kan ändras med en "[EXTERN]"-varning till mottagarna). Det modifierade meddelandet ogiltigförklarar DKIM-signaturen vilket orsakar ett DKIM-fel. Kom ihåg att syftet med DKIM är att säkerställa att innehållet i ett e-postmeddelande inte har manipulerats under leveransprocessen. Om detta händer kommer DKIM-autentiseringen att misslyckas med ett autentiseringsfel som liknar "DKIM-signature body hash not verified".

Lösningar:

• Om du har full kontroll över hela vägen som e-postmeddelandet kommer att passera från avsändare till mottagare, se till att ingen e-postserver emellan ändrar e-postinnehållet under överföring.
• Sätt DMARC-policyn i övervakningsläge (p=none) tills dessa problem har identifierats/lösts.

Vidarebefordran av e-post

Vidarebefodran av e-post är ett stort problem att få att fungera med SPF/DKIM/DMARC. Med policies som Google har är det högst osäkert om vidarebefodrad e-post verkligen kommer fram till ens gmail-adress, och gör det väl det, då hamnar det i skräpposten.

Det är inte ovanligt att ett meddelande som vidarebefordras, resulterar i att både/antingen SPF och DKIM misslyckas med att skapa en domänjusterad autentiserad identifierare. För SPF betyder det att e-postservern för vidarebefordran inte är listad i MAIL FROM-domänens SPF-policy.

Det är möjligt för en e-postserver för vidarebefordran att undvika SPF-fel och ta ansvar för e-posthanteringen för de meddelanden den vidarebefordrar genom att skriva om MAIL FROM-adressen så att den ligger i den domän som kontrolleras av vidarebefordranservern. Vidarebefordran av servrar som inte skriver om MAIL FROM-adressen utgör en risk för identitetsattacker och nätfiske. Å andra sidan, om e-postservern gör denna ändring i meddelandet, då kommer DKIM att fallera. Det har utarbetats olika lösningar för att lösa detta, men ingen av dessa är tillräckligt robusta. Slutsatsen är helt enkelt att man inte skall använda sig av vidarebefodran. Gör man det ändå, då får man ta eget ansvar för det, e-postleverantören kan inte lösa det problemet.

Skickar e-post från sin webbsida

Detta är något som ofta glöms bort. Mail som skickas från en webbsida kan t.ex. vara beställningsinformation, fakturor, supportärenden osv. Om man använder de standardfunktioner som ofta finns i olika program, då kommer man att skicka e-post som inte uppfyller DMARC. Man riskerar också att SPF och DKIM fallerar, och då kommer inte den e-post man skickar komma fram till t.ex. Google Gmail.

Här måste man se till att man konfigurerar sin hemsida att skicka e-post på rätt sätt. Läs mer om detta i denna artikel Hur kan jag använda mail med php?.

Referenser

• https://aws.amazon.com/blogs/messaging-and-targeting/email-authenctication-dmarc-policy/

Vi rekommenderar 

Marcs Updater

Ja det går, man behöver byta stilmall och sedan ändra på inställningarna i Hantering av meddelanden.

Stilmall

Gå till Inställningar/Användargränssnitt.

Hantering av meddelanden

Klicka sedan på Hantering av meddelanden och välj Skrivbord.... och klicka sedan på Spara.

Byt stilmall till Stretched Elastic och klicka på Spara.

Resultatet blir då följande:

OBS: Multipla identiteter fungerar inte med denna stilmall

Använder ni er av multipla identiteter kan ni inte växla mellan olika när ni använder denna stilmall. Den pop-up som ni normalt kan få enligt ovanstående bild fungerar inte med denna stilmall. Vi hoppas på att denna bug kommer att rättas till.

Vi har Memcached installerad på våra servrar, men appar kommer inte att använda det förrän ni säger åt dem att göra det. Processen skiljer sig beroende på app, men Memcached-tillägg är tillgängliga för de flesta populära innehållshanteringssystem och e-handelsbutiker.

• WordPress: W3 Total Cache, Cachify, Batcache och många andra plugins stöder Memcached.
• Drupal: Memcache API och integrationsmodulen möjliggör cachning, hantering och statistik.
• Joomla: Joomla inkluderar inbyggt memcached-stöd.
• Adobe Commerce: Memcachad integration stöds med bara några konfigurationsredigeringar.

Läs Memcached-dokumentationen för din PHP-app eller plugin. De kan kanske automatiskt upptäcka Memcached, och allt du behöver göra är att slå på caching. Du kan dock behöva ange IP-adressen och porten som cachen är ansluten till, vilket är 127.0.0.1:11211. Port är delen efter kolon: 11211.

För mer information om hur man kan få sin webbsida att bli snabbare, läs gärna den bifogade artikeln.

Har ni glömt lösenordet behöver det återställas. Detta kan göras dels via kontrollpanelen ISPConfig, men enklast är att göra det via den Enkla Kontrollpanelen.

Logga in till ert kundkonto på https://kunder.support

Gå till administration av den aktuella tjänsten, klicka på E-postkonton i menyn på vänstra sidan.

Klicka på pennan på för den e-postadress det gäller. Ange där ett nytt lösenord och klicka på Uppdatera E-postkonto.

Följande inställningar fungerar:

I regel hittar Apple Mail dessa själv, dock behöver mail fylla i Värdnamn för både utgående och inkommande server. Användarnamn och Lösenord skall vara samma både för utgående och inkommande server.

För att vara helt säker på att rätt Användarnamn och Lösenord anges, logga in till https://webmail.webbmotell.se med dessa för att kontrollera att de är korrekta.

Notera att Apple Mail kan vara knepig då den blandar ihop Internetkonton med mailkonton.

I Apple Mail, använd dess inställningar genomgående (⌘,), inte de som du hittar i systeminställningar.

En opcode-cache är en mekanism som används för att förbättra prestandan hos PHP-applikationer genom att lagra kompilerad bytekod (opcode) av PHP-skript i minnet. När ett PHP-skript körs utan opcode-cache sker följande steg:

1. Läsa in skriptet: PHP läser källkoden från disken.
2. Parsa: Källkoden analyseras och bryts ner i mindre delar (tokens) för att kontrollera syntaxen.
3. Kompilera: Koden omvandlas till bytekod (en mellanrepresentation).
4. Exekvera: Bytekoden körs av PHP:s runtime.

Denna process upprepas varje gång ett PHP-skript begärs, vilket skapar en extra belastning, särskilt för ofta använda skript.

Hur fungerar opcode-cache?

En opcode-cache minskar denna belastning genom att:

1. Lagra den kompilerade bytekoden i minnet efter den första körningen av ett skript.
2. Återanvända den lagrade bytekoden vid senare körningar, vilket eliminerar behovet av att läsa, parsa och kompilera koden igen.

Fördelar med opcode-cache

• Snabbare körning: Skript exekveras snabbare eftersom parsing och kompilering hoppar över.
• Minskad CPU-belastning: Mindre resurser krävs eftersom processen blir effektivare.
• Bättre skalbarhet: Minskad overhead gör att servern kan hantera fler samtidiga förfrågningar.

Vanliga opcode-cache-lösningar

1. OPcache: Inbyggd i PHP sedan version 5.5 och är den vanligaste lösningen idag.
2. APC (Alternative PHP Cache): En äldre lösning som främst användes före OPcache blev standard.
3. XCache och eAccelerator: Mindre vanliga tredjepartslösningar.

Exempel på konfiguration av OPcache

För att aktivera OPcache i php.ini:

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2

Våra samtliga webbhotellplaner har opcache aktiverat som standard.

Sammanfattning

En opcode-cache som OPcache är ett enkelt och effektivt sätt att förbättra PHP-prestanda genom att lagra kompilerad bytekod i minnet. Detta sparar resurser och snabbar upp exekveringen av skript, vilket är särskilt viktigt för webbplatser med hög trafik.

Memcached är ett distribuerat cacheminnessystem som används för att förbättra prestanda och skalbarhet i applikationer genom att lagra data i RAM. Det fungerar som ett snabbt och enkelt sätt att tillhandahålla tillfällig lagring av data som ofta begärs, vilket minskar belastningen på databaser och andra långsammare lagringsmekanismer.

Hur fungerar Memcached?

Memcached fungerar som en nyckel-värde-databas i minnet:

1. Data Lagring: Data lagras som nyckel-värde-par där varje nyckel är unik.
2. Snabb Åtkomst: När en applikation begär en viss nyckel, hämtas värdet direkt från RAM, vilket är mycket snabbare än att slå upp det i en databas.
3. Eviction Policy: Memcached använder en LRU (Least Recently Used)-algoritm för att automatiskt ta bort gamla poster när minnet blir fullt.
4. Distribuerat System: Memcached kan köras på flera servrar för att stödja större datamängder och högre belastning.

Typiska användningsområden

1. Caching av databasfrågor: Resultatet av tidskrävande databasfrågor kan lagras i cache och snabbt hämtas vid behov.
2. Session-hantering: Webbsessioner kan lagras i Memcached för snabb åtkomst och skalbarhet.
3. API-calls cache: Resultatet från externa API-anrop kan cachas för att minska nätverksanrop och svarstider.
4. Objektcaching: Applikationer kan cacha objekt och data som ofta används för att förbättra prestandan.

Fördelar med Memcached

• Snabbhet: Data lagras i RAM, vilket ger extremt låga svarstider.
• Skalbarhet: Kan enkelt skalas horisontellt genom att lägga till fler servrar.
• Plattform oberoende: Fungerar med olika programmeringsspråk som PHP, Python, Ruby, Java, m.fl.
• Enkelhet: Har en enkel och lättanvänd design.

Begränsningar

• Volatilitet: Eftersom Memcached lagrar data i RAM, går all cache-data förlorad vid serveromstart.
• Enkel struktur: Ingen inbyggd funktionalitet för mer komplex datalagring, som relationer eller frågespråk.
• Inget peristent lagring: Memcached är inte en långsiktig lagringslösning.

Exempel på användning i PHP

Här är ett enkelt exempel på hur man ansluter till och använder Memcached i PHP:

// Anslut till Memcached
$memcached = new Memcached();
$memcached->addServer("127.0.0.1", 11211);
// Lagra ett värde
$memcached->set("key", "value", 300); // 300 sekunders giltighetstid
// Hämta ett värde
$value = $memcached->get("key");
if ($value) {
    echo "Värdet är: $value";
} else {
    echo "Nyckeln finns inte i cachen.";
}

Sammanfattning

Memcached är ett lättviktigt och kraftfullt cacheminnessystem som används för att optimera applikationsprestanda genom att tillhandahålla snabb tillgång till ofta använda data. Det är idealiskt för applikationer som behöver hantera hög trafik och stora mängder data med låg latens.

Opcode caching och Memcached är två olika teknologier med olika syften, så valet mellan dem handlar inte om att använda den ena eller den andra, utan snarare när och hur man använder dem. I många fall används de tillsammans för att maximera prestanda i en applikation.

Syftet med Opcode Caching

Opcode caching, som exempelvis OPcache, används för att förbättra PHP-kodens prestanda.

• Den fokuserar på att minska den tid och resurser som krävs för att tolka och kompilera PHP-skript vid varje begäran.
• Den lagrar den kompilerade bytekoden i minnet och återanvänder den vid framtida anrop, vilket sparar processorkraft.
• Användningsområde: Bra för att snabba upp själva exekveringen av PHP-skript på servernivå.

När ska du använda Opcode Caching?

• När din applikation är PHP-baserad och du vill minska serverns bearbetningstid för att hantera PHP-skript.
• Det är ett standardval för att optimera PHP-applikationer och fungerar utan att du behöver ändra applikationens kod.

Syftet med Memcached

Memcached är en teknik för att cachea applikationsdata (t.ex. databasfrågor, API-anrop eller sessionsdata) i RAM-minne.

• Den används för att minska belastningen på databaser eller andra lagringssystem genom att tillhandahålla snabba svar från cache.
• Användningsområde: Bra för att lagra data som ofta begärs av en applikation, såsom resultat från dyra databasfrågor eller externa API-anrop.

När ska du använda Memcached?

• När din applikation utför många repetitiva databasfrågor eller hämtar samma data från externa källor.
• Om du vill dela cachedata mellan flera servrar i en distribuerad miljö.
• När du behöver tillfällig lagring av stora mängder data som inte behöver vara persistent.

Jämförelse: Opcode Caching vs. Memcached

När ska man använda vad?

Använd Opcode Caching om:

• Du kör en PHP-applikation och vill förbättra laddningstiden för skript.
• Applikationen har många dynamiska PHP-sidor som används ofta.
• Du vill ha en enkel optimering utan att ändra applikationens logik.

Använd Memcached om:

• Din applikation gör många repetitiva databasfrågor eller hämtar data från API:er.
• Du har en distribuerad applikation som kräver delad data mellan servrar.
• Du vill optimera datalagret för snabbare svarstider.

Kombinera båda för maximal prestanda

För många PHP-baserade applikationer kan både opcode caching och Memcached användas samtidigt:

1. Opcode Caching: Minskar serverns bearbetningstid genom att optimera PHP-kodens exekvering.
2. Memcached: Minskar belastningen på databaser och andra långsammare datakällor genom att lagra ofta använd data i RAM.

Tillsammans bidrar de till en snabbare, mer skalbar och mer effektiv applikation!

För att kontrollera om din webbserver har stöd för opcode cache (t.ex. OPcache), kan du använda flera olika metoder beroende på vilken tillgång du har till servern. Här är några steg du kan följa:

1. Kontrollera via phpinfo()

Skapa en fil, till exempel phpinfo.php, i din webbserverrot:

<?php
phpinfo();
?>

Öppna filen i din webbläsare (t.ex. http://din-domän/phpinfo.php).

Sök efter en sektion med rubriken OPcache:

Om OPcache är aktiverat ser du detaljer om dess konfiguration, till exempel:

opcache.enable => On => On
opcache.memory_consumption => 128 => 128
opcache.max_accelerated_files => 10000 => 10000

Om det inte finns någon OPcache-sektion betyder det att OPcache inte är aktiverat eller installerat.

2. Kontrollera via kommandoraden (CLI)

Om du har tillgång till kommandoraden på servern kan du använda följande kommando:

php -i | grep "opcache"

Detta ger en lista över OPcache-inställningar om det är installerat och aktiverat.

• Om du ser något som opcache.enable => On, så är OPcache aktiverat.
• Om inga resultat visas kan OPcache behöva aktiveras eller installeras.

3. Kontrollera PHP-konfigurationsfilen (php.ini)

Om du har tillgång till serverns PHP-konfigurationsfiler kan du kontrollera om OPcache är aktiverat i php.ini:

Leta efter följande rader:

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000

Om dessa rader saknas, lägg till dem och starta om webbservern för att aktivera OPcache.

4. Kontrollera via PHP-skript

Skapa ett skript för att kontrollera om OPcache är aktivt:

<?php
if (function_exists('opcache_get_status')) {
    $status = opcache_get_status();
    if ($status && $status['opcache_enabled']) {
        echo "OPcache är aktiverat.";
    } else {
        echo "OPcache är inte aktiverat.";
    }
} else {
    echo "OPcache är inte installerat.";
}
?>

Spara skriptet som en PHP-fil (t.ex. check_opcache.php) och kör det via din webbläsare.

5. Vad gör du om OPcache inte är aktiverat?

• Installera OPcache: På många servrar kan OPcache installeras via ett paket, t.ex. för Ubuntu/Debian: sudo apt-get install php-opcache
• Aktivera OPcache: Om det redan är installerat men inte aktiverat, se till att lägga till och justera inställningarna i php.ini och starta om din webbserver.
• Kontakta webbhotell: Om du inte har root-åtkomst, kontakta din leverantör och be dem aktivera OPcache för din PHP-miljö.

Med dessa steg kan du enkelt kontrollera om din server har stöd för opcode cache och aktivera det om det inte redan är aktiverat!

Våra web-servrar erbjuder inbyggd server-side caching som en del av vår infrastruktur. Då är det rimligt att fråga sig om ett separat cache-plugin verkligen behövs.

Det finns webbhotell som menar att cache-plugins är överflödiga eftersom servern redan hanterar cachning.Men räcker det verkligen i praktiken?

Vad är server-side cache?

När en förfrågan når en server måste WordPress köra en mängd PHP-skript och MySQL-frågor.

Varje gång du öppnar en sida eller ett inlägg måste minst 27 MySQL-frågor köras. 27 är standardantalet frågor – men det kan vara 50 eller 100 beroende på vilket tema du använder och hur många plugins som är installerade. Varje fråga kan ta några millisekunder att bearbeta, beroende på frågans komplexitet och mängden data i databasen.

När man summerar alla dessa PHP- och MySQL-exekveringar kan TTFB (Time to First Byte) landa på runt en sekund – eller till och med mer.

Server-side caching eliminerar denna process genom att lagra kopior av det genererade HTML-innehållet på disk eller i minnet. Detta minskar TTFB och minskar belastningen på serverresurserna, eftersom servern endast behöver leverera den redan genererade filen.

Våra web-servrar erbjuder APCu/Redis/Memcached/Memcache och dessutom OPCache, vilket vi kommer till senare.

Om du cachar HTML-sidor via Cloudflare räknas det tekniskt sett också som en form av server-side caching.

Vad gör cache-plugins som server-side caching inte klarar av?

De flesta cache-plugins genererar statiska HTML-sidor på liknande sätt som server-side caching. Men cache-plugins erbjuder dessutom flera front-end-optimeringar som servern i sig inte hanterar.

Här är några exempel:

• Generering av critical path CSS – Förbättrar FCP (First Contentful Paint), vilket numera är en rankingfaktor i Googles sökresultat.
• Fördröjd inläsning av JavaScript och CSS – Eliminerar render-blocking resurser genom att ladda dem asynkront.
• Minifiering av CSS och JavaScript – Minskar filstorleken och därmed laddningstiden.
• Lazy loading – Fördröjer inläsning av bilder, videor, inbäddat innehåll m.m. tills de syns i vyporten.

Det finns många fler funktioner beroende på vilket cache-plugin du använder.

Så, behöver man ett cache-plugin även om server-side caching redan finns? Svaret är: JA!

Server-side caching är utmärkt för att avlasta servern och minska TTFB, men det räcker inte hela vägen när det gäller prestandaoptimering ur ett front-end-perspektiv. Ett bra cache-plugin kan göra skillnad när det gäller användarupplevelse och Core Web Vitals.

Jag rekommenderar FlyingPress för cachning, då det kombinerar kraftfull sidcachning med avancerade optimeringsfunktioner som lazy loading, preloading, minifiering, critical CSS och mycket mer – allt med låg påverkan på serverresurserna.

Om du redan har server-side caching via ditt webbhotell – grymt. Men komplettera det med ett välkonfigurerat cache-plugin för att maximera både hastighet och användarupplevelse.

Notera också att det behövs plugins för att aktivera server-side cachning för hemsidan, dock med ett undantag.

OPCache

Läs mer om OPCache i denna artikel Vad är OPcache?. Denna är aktiverad på våra webbservrar och behöver ingen plugin för att den skall användas.

Jämförelse mellan olika plugins

Här kommer en tekniskt inriktad jämförelse mellan FlyingPress, WP Rocket, Surge och W3 Total Cache, med fokus på prestanda, funktionalitet och användarvänlighet:

⚙️ 1. FlyingPress

+ Fördelar:

• Allt-i-ett-lösning med modern kodbas och hög prestanda.
• Generering av Critical CSS (per sida), lazy loading, preloading, minifiering, defer av JS/CSS.
• Inbyggt stöd för font-display: swap, image optimization och cache invalidation.
• Extremt lätt att konfigurera – kräver minimalt med teknisk kunskap.
• Fungerar väl tillsammans med server-side caching och CDN som Cloudflare eller Bunny.net.

– Nackdelar:

• Premiumplugin – ingen gratisversion.
• Inte lika modulärt som W3TC om du vill ha granular kontroll.

Passar bäst för: Prestandafokuserade WordPress-sajter som vill ha kraftfull optimering utan krångel.

⚙️ 2. WP Rocket

+ Fördelar:

• Välkänt, moget plugin med stort community.
• Enkel att använda – bra UI.
• Bra stöd för cache, preloading, minifiering, delay JS execution, m.m.
• Integrerar fint med CDN, inklusive Cloudflare.

– Nackdelar:

• Premium – ingen gratisversion.
• Saknar vissa avancerade optimeringsfunktioner som bildoptimering (kräver tillägg).
• Critical CSS är globalt, inte per sida (inte lika exakt som FlyingPress).

Passar bäst för: Användare som vill ha en välpolerad, stabil lösning och som inte har extremt avancerade behov.

⚙️ 3. Surge

⚠️ Endast relevant för statiska WordPress-sajter.

+ Fördelar:

• Superlätt plugin, utvecklat av WordPress core contributors.
• Ger extremt låg TTFB via inbyggd full page static cache direkt i WordPress.
• Kräver nästan ingen konfiguration – installera och kör.

– Nackdelar:

• Ingen CSS/JS-optimering, inget stöd för lazy loading, preloading eller liknande.
• Ingen kontroll över cache-uppdatering.
• Inte lämpligt för dynamiska sajter med inloggade användare eller WooCommerce.

Passar bäst för: Bloggar eller statiska innehållssajter där man prioriterar snabbhet med minimal overhead.

⚙️ 4. W3 Total Cache (W3TC)

+ Fördelar:

• Extremt konfigurerbart – stödjer object cache, page cache, browser cache, CDN, fragment caching, etc.
• Kan integreras med Redis, Memcached, APCu.
• Stöd för både disk och RAM-baserad cache.
• Har en bra guide för vilka inställningar som är bäst för just denna site.
• Gratis

– Nackdelar:

• Många funktioner överlappar med vad hosting-leverantörer redan hanterar (t.ex. via server-side caching).
• Frontend-optimeringar (CSS/JS minifiering etc.) är inte lika kraftfulla eller moderna som i FlyingPress eller WP Rocket.

Passar bäst för: Den som inte vill betala för typ FlyingPress får här en plugin som hanterar alla aspekter på cachning. Behövs inga flera plugins om man väljer denna. Passar både den teknisk avancerade liksom nybörjaren.

Sammanfattning

Vilken plugin skall jag använda för att komplettera flyingpress så att jag får object cache också?

Bra fråga! FlyingPress hanterar frontend-optimering (HTML, CSS, JS, bilder, lazy loading osv), men object cache – alltså caching av databasfrågor och PHP-objekt – kräver en separat lösning.

Här är de bästa alternativen för object cache som fungerar perfekt tillsammans med FlyingPress:

✅ 1. Object Cache Pro (premium)

Rekommenderas starkt för Redis-baserad object cache.

• Byggd för Redis – supersnabb, stabil och har stöd för taggar, preloading, metrics m.m.
• Integreras väl med WooCommerce, Multisite och andra tunga WordPress-installationer.
• Ger debugging & statistik via WordPress admin.
• Kräver Redis-server (kan köras lokalt eller via t.ex. Redis på Docker).

✅ 2. Redis Object Cache (gratis)

Open source, officiellt plugin från teamet bakom Redis Object Cache.

• Enkel att installera och konfigurera.
• Klarar tunga sajter bra, men saknar avancerad funktionalitet (ingen statistik eller taggar).
• Kompatibel med FlyingPress, WooCommerce och Multisite.

Sammanfattning

Vår rekommendation

Är ni beredd att betala då är Flying Press absolut bäst. Utöver denna behöver man en plugin för Object Cache enligt ovan. Vilken är en fråga för plånboken.

Notera att W3TC inte kan användas i kombination med FlyingPress, eftersom de båda försöker göra frontend-optimering – det blir konflikt.

Annars är  gratis-versionen av W3 Total Cache det bästa alternativet. Det är komplett och enkelt att ställa in med sin interaktiva Setup Guide. Välj den metod, ingen/disk/redis/memcached/APC, som W3TC rekommenderar när ni kör Setup Guide.

Notera dock att cachning kan ställa till det, t.ex. vid staging. Det är därför bra att försöka minimera användningen av cache. Ser man att det bara ger en minimal förbättring på några procent, då är det bättre att låta det vara ocachat.

Referenser

• best-wordpress-cache-plugins/
• Do I need a Cache Plugin with Server Side Cache (FastCGI)?
•  

Vad innebär opcache.validate_timestamps?

opcache.validate_timestamps är en konfigurationsinställning i PHP OPcache som styr hur OPcache hanterar tidsstämplar för cachelagrade PHP-skript. Det avgör om OPcache ska kontrollera om det underliggande PHP-skriptet har ändrats på filsystemet sedan det cachelagrades.

Funktion och innebörd

• Om värdet är 1 (standard):
  • OPcache validerar tidsstämplar för de cachelagrade filerna. Det innebär att OPcache kontrollerar om den cachelagrade filens "Last Modified"-tidsstämpel matchar den aktuella filen på disken varje gång filen ska användas.
  • Om filen har ändrats på disken (nyare tidsstämpel) rensas den gamla versionen från cachen och den nya versionen läses in och cachelagras.
  • Detta är användbart under utveckling eller om skript ändras ofta.
• Om värdet är 0:
  • OPcache validerar inte tidsstämplar. När en fil är cachelagrad används den versionen tills servern (eller PHP-FPM-processen) startas om, eller tills OPcache töms manuellt.
  • Detta kan ge bättre prestanda eftersom OPcache inte behöver kontrollera filens tidsstämpel.
  • Används vanligtvis i produktionsmiljöer där koden sällan ändras.

Konfigurationsinställning

Syntax i php.ini:

opcache.validate_timestamps=1

Justering via runtime (vid behov):

ini_set('opcache.validate_timestamps', '1');

Relaterade inställningar

• opcache.revalidate_freq:
  • Styr hur ofta (i sekunder) OPcache kontrollerar tidsstämplar för cachelagrade filer, om opcache.validate_timestamps är aktiverat.
  • Standardvärde är 2, vilket betyder att OPcache kontrollerar filerna varannan sekund.

  opcache.revalidate_freq=2

• opcache.enable:
  • Om OPcache är aktiverat överhuvudtaget.

  opcache.enable=1

När ska man använda vad?

• Utvecklingsmiljö:

  Använd opcache.validate_timestamps=1 så att dina ändringar i PHP-kod direkt reflekteras utan att du behöver tömma OPcache manuellt.

• Produktionsmiljö:

  Använd opcache.validate_timestamps=0 för att maximera prestanda. Se till att du tömmer OPcache eller startar om tjänsten när du rullar ut nya kodändringar.

Så tömmer du OPcache på en webbserver som använder Apache och PHP

1. Använd PHP:s inbyggda funktioner

PHP tillhandahåller funktioner för att rensa OPcache manuellt:

Exempel:

<?php
// Rensa OPcache
if (function_exists('opcache_reset')) {
    opcache_reset();
    echo "OPcache cleared.";
} else {
    echo "OPcache is not enabled.";
}
?>
    

Hur man använder:

1. Lägg filen på din webbserver (t.ex. i rotkatalogen för din webbplats).
2. Gå till filen i din webbläsare, exempelvis: http://example.com/clear_opcache.php.
3. När du laddar sidan töms OPcache.

Obs! Efter att ha använt filen, ta bort den för att förhindra obehörig åtkomst.

2. Använd kommandoraden

Om du har tillgång till kommandoraden på din server kan du tömma OPcache med hjälp av PHP CLI:

Exempel:

php -r "if (function_exists('opcache_reset')) { opcache_reset(); echo 'OPcache cleared.'; } else { echo 'OPcache is not enabled.'; }"
    

3. Genom att starta om Apache

Om du inte kan använda funktionerna ovan kan du rensa OPcache genom att starta om Apache. När Apache startar om rensas OPcache automatiskt.

Exempel:

sudo systemctl restart apache2
    

Eller, om du använder en äldre version av Apache:

sudo service apache2 restart
    

4. Ändra OPcache-inställningar tillfälligt

Om du inte vill använda skript kan du ställa in följande i din PHP-konfigurationsfil (t.ex. php.ini eller en Apache-konfigurationsfil som php.conf):

Exempel:

opcache.enable=0
    

1. Starta om Apache:

   sudo systemctl restart apache2

2. Ändra tillbaka inställningen till:

   opcache.enable=1

3. Starta om Apache igen.

5. Kontrollera att OPcache tömts

Du kan bekräfta att OPcache är tömd genom att använda ett OPcache-statusverktyg som opcache-gui eller genom att skapa ett skript som visar dess status:

Exempel:

<?php
// Visa OPcache-status
if (function_exists('opcache_get_status')) {
    print_r(opcache_get_status());
} else {
    echo "OPcache is not enabled.";
}
?>
    

Lär dig allt om de olika cachetyperna som finns tillgängliga för PHP, webbplatser och WordPress i synnerhet.

Zend Opcode, JIT & WP Object Cache

OPcache

OPcache förbättrar PHP-prestanda genom att arkivera förkompilerad skriptbytekod i delat minne, vilket eliminerar behovet för PHP att ladda och tolka skript vid varje begäran. Det finns också en särskild buffert för att lagra oföränderliga strängar så att de kan återanvändas av sina pekare för alla förekomster av samma sträng.

JIT

JIT kan ge prestandaförbättringar genom att kompilera och lagra de fullständiga eller ofta anropade delarna av en PHP-applikation som CPU-maskinkod och köra den direkt, vilket kringgår Zend VM och dess processoverhead.

WP Objekt Cache

WordPress Object Cache används för att spara på anrop till databasen. Objektcachen lagrar alla cachedata i minnet och gör cacheinnehållet tillgängligt med hjälp av en nyckel, som används för att namnge och senare hämta cacheinnehållet.

WP Object Cache är en flyktig cache som endast är giltig för den aktuella begäran.

Beständig objektcache (persistent)

Beständiga cacheminnen lagrar cachelagrade data i en beständig lagring så att de kan återanvändas flera gånger utan att uppdatera ursprungliga data. Det är tekniskt möjligt att använda en databas för lagring, men minneslagring är det enda effektiva alternativet.

APCu-cache

APCu (APC User Cache) är en cachelösning på användarnivå för PHP som cachar data i serverns minne. APCu är den snabbaste beständiga objektcachen som finns tillgänglig. Det är den enda cachen som kan lagra objekt utan serialisering.

Redis Cache

Redis är en snabb databas i minnet som använder serverns delade minne. Om du har flera WordPress installerade på ett delat värdkonto delar alla dessa installationer samma minne. OBS, detta innebär att alla användare på en webbserver kan se all data som ligger i redis. Man behöver därför vara noga med att inte känslig data lagras där, t.ex. sessions-data.

Lagring av icke-skalära data i en databas kräver serialisering, vilket är ett extra steg när du lagrar/hämtar data. Därför är Redis långsammare än APCu men snabbare än ingen cache. Redis kan nås via TCP/IP- eller UNIX-socket – vilket är den snabbare av de två.

Memcached Cache

Memcached är ett minnesinternt nyckel/värde-lager för små bitar av godtyckliga data (strängar, objekt) från resultat av databasanrop, API-anrop eller sidrendering.

Lagring av icke-skalära data i en databas kräver serialisering, vilket är ett extra steg när du lagrar/hämtar data. Därför är Memcached långsammare än APCu men snabbare än ingen cache. Memcached kan nås via TCP/IP- eller UNIX-socket – vilket är den snabbare av de två.

Webbläsarcache och nätverk för innehållsleverans (CDN)

Webbläsarens cache

För att förkorta sidinläsningstiderna cachelagrar webbläsare det mesta av innehållet som visas på en webbsida och sparar en kopia av webbsidans innehåll på enhetens hårddisk. På så sätt, nästa gång användaren laddar sidan, är det mesta av innehållet redan lagrat lokalt och sidan kommer att laddas mycket snabbare.

Cachelagring i webbläsaren är aktiverat som standard, men kan förbättras med hjälp av cachedirektiv på servern. Inställningarna kan antingen ställas in i webbserverkonfigurationen eller i .htaccess-filen (Apache-webbservern).

CDN

Ett CDN (Content Delivery Network) är en distribuerad grupp servrar som cachelagrar innehåll nära slutanvändare.

Ett CDN krävs inte för små statiska webbplatser med en lokal användarbas, men kan drastiskt förbättra laddningstiderna för en global användarbas, eftersom CDN ger lägre latens för varje begäran.

Sammanfattning

Ja, det fungerar. Använd följande konfiguration för ddclient:

# Configuration file for ddclient generated by debconf
# /etc/ddclient.conf
protocol=dyndns1 \
use=web, web=http://checkip.dyndns.org/ \
server=ic.etableraweb.com \
login=none \
password='xxxxxxxxxxxxxxxxxxxxfd9' \
hemma.exempel.se

där password är ert token, se https://faq.webbmotell.se/content/2/20/sv/hur-anvaender-jag-dyndns.html?highlight=dyndns

OPcache är en PHP-opcode cache, vilket innebär att det lagrar resultatet av kompilerade PHP-skript i minnet, så att PHP-tolkaren inte behöver läsa och tolka filerna från början varje gång de körs.

Med andra ord: OPcache “kompilerar” dina PHP-filer en gång och återanvänder bytekoden, vilket ger snabbare exekvering och mindre CPU-belastning.

⚙️ Hur fungerar OPcache i praktiken?

1. En användare begär en PHP-sida (t.ex. index.php).
2. PHP-tolkaren kompilerar filen till opcodes (bytekod).
3. Istället för att kompilera varje gång, lagrar OPcache denna bytekod i RAM.
4. Vid nästa förfrågan återanvänds den redan kompilerade versionen.

Detta sker helt i bakgrunden och transparent för både användare och utvecklare – men ger ofta en stor prestandaskillnad, särskilt på sidor med mycket PHP-logik.

Hur aktiverar man OPcache?

OPcache är aktiverat som standard på våra servrar och används som standar.

För att se om det är aktivt kan du köra:

php -i | grep opcache

Eller skapa en PHP-fil med phpinfo();.

<?php
phpinfo();

Hur förhåller sig OPcache till Apache, Redis och Memcached?

De fyller alltså olika roller i prestandastacken:

• OPcache → effektiv PHP-körning
• Redis/Memcached → snabb åtkomst till dynamisk data (t.ex. WordPress-transients)
• Server-side cache (FastCGI/Varnish) → caching av HTML-output
• Browser cache / CDN / Cache-plugins → ytterligare lager längre ut i kedjan

När gör OPcache mest nytta?

• Sajter med många PHP-requests (WordPress, WooCommerce, Laravel etc)
• Sajter med delad kodbas men mycket trafik (t.ex. multisite)
• Hostingmiljöer där CPU är flaskhals
• Där man inte ändrar kod ofta (undantag: utvecklingsmiljöer)

Pat Meenan (skaparen av WebPageTest) definierade Speed Index som ett mätvärde för hur snabbt innehåll blir visuellt synligt för användaren när en webbsida laddas.

Vad är Speed Index?

• Det mäter hur snabbt innehåll syns på skärmen, inte bara när sidan är helt laddad.
• Ett lägre värde är bättre.
• Det mäts i millisekunder (ms), så ett Speed Index på 500 betyder att det tog 0,5 sekunder för att visa det mesta av sidan visuellt.

Bra och dåliga värden (grovt förenklat):

Så är 500 bra?

Ja, 500 är riktigt bra!

Det innebär att huvudinnehållet blev synligt på bara en halv sekund. En sådan sida upplevs som mycket snabb av användaren.

Här är en snabb jämförelse mellan Speed Index och andra viktiga Core Web Vitals, så du får en helhetsbild av sidans prestanda:

Speed Index

• Mäter: Hur snabbt innehållet blir synligt (visuellt).
• Bra värde: < 1 000 ms
• Ditt värde: 500 ms → ✅ Mycket bra

Largest Contentful Paint (LCP)

• Mäter: När det största synliga elementet (bild, rubrik, etc.) är inläst.
• Bra värde: < 2,5 sekunder
• Tips för förbättring: Optimera bilder, använd lazy loading, snabb hosting.

⛔ First Input Delay (FID) (snart ersatt av INP)

• Mäter: Hur snabbt sidan reagerar på första användarinteraktionen.
• Bra värde: < 100 ms
• Ersätts av: Interaction to Next Paint (INP) – mäter allmän interaktivitet över hela sidan.

Cumulative Layout Shift (CLS)

• Mäter: Visuell stabilitet – hoppar saker runt när sidan laddas?
• Bra värde: < 0.1
• Tips: Sätt höjd/bredd på bilder, reservera plats för element som laddas in senare.

Produktsida: https://registrera-doman.se/webbhotell-webbmotell.php

WebbMotell med ett M

Vår Premium plan, som kan uppgraderas, är något utöver det vanliga. Ni får en helt egen server för er själv. Ni konkurrerar inte med någon annan om CPU och minne, allt är ert! Och detta till ett pris som motsvarar ett vanligt webbhotell. Vad mer som motsvarar ett eget webbhotell är att ni inte behöver bekymra er om tekniken alls, vi sköter allt, ni sköter era hemsidor med kontrollpanelerna och vi tar hand om resten.

Ni betalar bara för den support ni själv behöver, ni betalar inte för support som andra behöver. På så sätt kan vi erbjuda webbhotell med ett M, hotell till budgetpris.

Vi erbjuder också två instegskonton, Start och Standard, från 99 kr/år. Dessa är vanliga webbhotellkonton där ni delar resurser som CPU och minne/RAM med andra kunder.

Säker hemsida med SSL

Säkerhet blir allt viktigare och fokus på detta blir allt större. Google, Bing och många andra, uppmuntrar hemsidor till att vara krypterade. Detta oberoende av vad hemsidan innehåller, även om det är hemsidor som bara läses, ingen information skickas till dem. För att kryptera en hemsida behöver man skaffa ett certifikat och sedan med hjälp av sin webbhotellleverantör installera detta. Man behöver också en egen dedikerade IP adress, något som blir allt svårare då dessa sedan länge har börjat ta slut. Detta är en omständlig process, som också måste repeteras varje år när certifikatet behöver förnyas.

Tecknar ni webbhotell med oss ingår SSL, utan kostnad och utan krångel. Era sidor krypteras och Google respektive Bing blir glad. Era sidor kommer i varje fall inte straffas av dem pga av att de inte är krypterade. Vill ni installera egna certifikat, på traditionellt vis, stödjer vi naturligtvis det också.

Ultrasäker E-Post

E-post idag är i princip en värdehandling. Ofta används e-post för att bekräfta vem man är, en sort av id-legmitation. E-post används också ofta för inloggning till viktiga konton, där man har tillgångar. Det är därför nu för tiden av största vikt att man skyddar sin e-post,läs mer om Ultrasäker E-Post här.

Vi erbjuder ultrasäker e-post som alternativ helt kostnadsfritt för samtliga våra webbhotellplaner. Med vår ultrasäkra e-post går det bara att läsa och skicka e-post genom att logga in till en webmailportal med 2-faktors autentisering, på samma sätt som t.ex. Gmail och Hotmail. Även om ert lösenord till ert e-postkonto skulle komma på vift kan ingen komma åt er e-post. Priset man får betala är att man bara kan använda webmail för att läsa och skicka sin e-post, man måste använda en webbläsare, det går inte att använda de inbyggda e-postklienterna som finns på telefoner och datorer.

Weebly

Vi erbjuder världens nog mest använda och antagligen bästa webbyggare Weebly helt gratis med alla hotellplaner. Med denna version kan ni enkelt börja bygga er hemsida, behöver ni mer funktioner kan ni enkelt uppgradera. Den största fördelen med att använda Weebly genom oss är att hemsidan ni skapar med Weebly, den publiserar på ert webbhotellkonto hos oss. Ni kan då vara säker på att er hemsida finns inom EU och att vårt support har full kontroll över er hemsida, med t.ex. backup.

Weeblys kraftfulla webbplatsbyggare med dra och släpp-funktioner samt guider hjälper er att nå målet snabbare utan att någon kodning krävs.

Weeblys dra och släpp-funktioner gör det lätt att skapa en kraftfull, professionell webbplats utan att ha några tekniska kunskaper. Mer än 40 miljoner entreprenörer och småföretag har redan använt Weebly för att bygga upp sin närvaro på nätet med en webbplats, blogg eller butik.

Läs mer om vårt Weebly-erbjudande här.

Massor av appar

Med Installatron kan ni enkelt installera, uppgradera och avinstallera massor av mycket kraftfulla program som finns på Internet. Med dessa program kan ni bygga er hemsida, utan att behöva någon kunskap om html, php osv.

Genom Installatron kan ni enkelt installera portalprogramvaror, shoppingsystem, forum, supportsystem, bloggar, gästböcker och mycket mycket mer. Med dessa programvaror går det t.ex. att bygga upp ett komplett företag med ett kundssystem, med varukorgssystem, med supportsystem osv.

Är det en Blogg ni behöver? Ni installerar då WordPress enkelt med Installatron. Det är så enkelt att installera att vem som helt kan göra det och behöver ni hjälp hjälper vi er med det.

Läs mer om Installatron här.

Oöverträffad prestanda - Servrar optimerade för php drivna hemsidor

Vår server-miljö är optimerad för prestanda. Dels för att vi använder bästa möjliga hårdvara och dels för att vi är noga med att inte placera för många kunder på varje server. Våra servrar har aldrig en last större än 1. Vi övervakar detta noga och uppgraderar servrar snabbt när det behövs. Det är oerhört viktigt för oss att våra kunder upplever sina hemsidor som snabba. Det är överordnat det mesta, det är en del av vår affärsidé.

Många använder i dag php för sina hemsidor. Exempel på hemsidor som använder php är de som använder WordPress och Joomla. php är dynamisk, vilket innebär att servern måste göra ett antal beräkningar för varje sida som visas. Detta tar tid och kan göra hemsidan långsam.

Våra servrar är optimerade för hemsidor byggda med php, vi använder Apache med event-mpm och php-fpm. Vi erbjuder emellertid Nginx (Engine X) till våra Premium planer, för hemsidor som har oerhört många besökare och då behöver extra prestanda.

När skall jag då välja Nginx istället för Apache? Ja, idag är det inte helt självklart då Apache i stor utsträckning mitigerat sina tidigare tillkortakommanden. Har man en dynamisk sida, t.ex. WordPress, då är det absolut inte säkert att Nginx är snabbare än Apache med event-mpm och php-fpm. Nginx kan vara snabbare för statiska sidor. Är man inloggad som användare i WordPress, då är defintivt inte nginx snabbare. Nginx är främst ett alternativ om man har många, väldigt väldigt, många besökare till sin hemsida. Nginx gör inte en hemsida snabbare för få besökare, men kan gör det om man har väldigt väldigt många besökare. Har man få besökare till sin hemsida, typ några tusen per dag, då upplevs absolut ingen skillnad alls. Hursomhaver, för den som vet vad den vill erbjuder vi som sagt också Nginx.

Väljer ni Premium kontot får ni tillgång till en helt egen Redis. Ni kan bland annat använda denna för WordPress och då få en osannolikt snabb WordPress hemsida. WordPress har utmärkt stöd för Redis, bland annat genom Redis Object Cache plugin. Superenkel att installera från WordPress admin sida.

Säkerhetskopiering med stöd för GDPR

Hanterar ni personlig information? Eller ännu värre, känslig personlig information? Gör ni det ställer GDPR hårda krav på att ni har kontroll över er information, vart data lagras, vem som kan se den.

Vi erbjuder säkerhetskopiering som klarar av dessa hårda krav. Med vår GDPR backup krypteras all data och data lagras aldrig utanför EU eller utanför EU jurisdiktion. Ni kan också välja om ni inte vill att er data skall säkerhetskopieras över huvud taget, varken hemsida eller e-post. I ISPConfig finns utmärkta verktyg för att själv hantera sin säkerhetskopiering.