FS Data

FS Data - webbhotell, domännamn, e-post, servrar

Flytta från Drupal till WordPress

Under påskhelgen som var så utförde jag en flytt, eller migrering, från Drupal till WordPress. Innan flytten funderade jag mycket kring hur svårt det skulle vara, om det ens var möjligt. Med facit i hand så var det enklare än förväntat. Tänkte därför berätta lite kort om detta, om fler vill göra detsamma.

Varför ska man då flytta från Drupal till WordPress?

Flytta från Drupal till WordPressDrupal är ett riktigt bra CMS. Den har en stor användarbas med många olika tillägg och teman. Personligen har jag dock större kunskap om WordPress och detta var en Drupal 6-sida som hade behövt uppgraderas till Drupal 7, vilket är ett rätt så stort projekt i sig. Därav denna migrering.

Flytten skedde mellan Drupal 6.2.6 och WordPress 3.5.1. Dessa instruktioner kan fungera med andra versioner av Drupal och WordPress, men det kan inte garanteras (t ex pga förändrad tabellstruktur, ändrade fältnamn osv). Som alltid, när man gör sådana här saker, se till att du har ordentlig backup på allt.

Så flyttar man från Drupal till WordPress

1. Börja med att exportera den fullständiga databasen för Drupal-sidan och ladda ner den till din dator. Det gör man enklast via t ex phpMyAdmin och dess exportfunktion (kör bara en standardexport). Om det är en stor Drupal-sida så kan det här ta en stund.

2. Installera sedan den nya WordPress-sidan. Om du har ett webbhotellspaket hos FS Data så kan du följa dessa enkla instruktioner: FS Data manualer, Installera WordPress på ditt webbhotell.

3. Skapa därefter ytterligare en MySQL-databas. Det är till denna databas som vi ska importera den tidigare exporterade databasen från Drupal. Instruktioner för hur man skapar en databas hos FS Data finns här: FS Data manualer, Skapa MySQL-databas.

4. Nu är det dags att importera den tidigare exporterade databasen. Om databasexporten är större än 25 MB så bör man använda en fristående MySQL-klient istället för phpMyAdmin. Jag använder Mac OS X och kan rekommendera den kostnadsfria MySQL-klienten Sequel Pro. Anslut mot den nyligen skapade (och tomma) MySQL-databasen och importera den exporterade Drupal-databasen. Detta kan likaså ta en stund att genomföra.

5. När importen är klar så är det dags att köra ett antal SQL-kommandon. Dessa kommandon är anpassade för en WordPress-databas med namnet ”u1234567_a” och en (importerad) Drupal-databas med namnet ”u1234567_d”, så man behöver givetvis anpassa detta efter namnen på sina motsvarande databaser. Förslagsvis att man använder en separat MySQL-klient även för att köra dessa SQL-kommandon.

Vi börjar med att rensa WordPress-databasen från de inlägg/kommentarer som ingår i en ny WordPress-installation.

TRUNCATE TABLE u1234567_a.wp_comments;
TRUNCATE TABLE u1234567_a.wp_links;
TRUNCATE TABLE u1234567_a.wp_postmeta;
TRUNCATE TABLE u1234567_a.wp_posts;
TRUNCATE TABLE u1234567_a.wp_term_relationships;
TRUNCATE TABLE u1234567_a.wp_term_taxonomy;
TRUNCATE TABLE u1234567_a.wp_terms;

Därefter är det dags att importera lite kategorier från Drupal-databasen till WordPress-databasen. Notera att WordPress kräver unika kategorinamn, till skillnad från Drupal. Om du har flera kategorier med samma namn i Drupal så behöver dessa döpas om innan importen.

INSERT INTO u1234567_a.wp_terms (term_id, `name`, slug, term_group)
SELECT
d.tid, d.name, REPLACE(LOWER(d.name), ' ', '-'), 0
FROM u1234567_d.term_data d
INNER JOIN u1234567_d.term_hierarchy h
USING(tid)
;

INSERT INTO u1234567_a.wp_term_taxonomy (term_id, taxonomy, description, parent)
SELECT
d.tid `term_id`,
'category' `taxonomy`,
d.description `description`,
h.parent `parent`
FROM u1234567_d.term_data d
INNER JOIN u1234567_d.term_hierarchy h
USING(tid)
;

Sedan importerar vi alla sidor från Drupal-databasen till WordPress-databasen.

INSERT INTO
u1234567_a.wp_posts (id, post_date, post_content, post_title,
post_excerpt, post_name, post_modified)
SELECT DISTINCT
n.nid, FROM_UNIXTIME(created), body, n.title,
teaser,
REPLACE(REPLACE(REPLACE(REPLACE(LOWER(n.title),' ', '-'),'.', '-'),',', '-'),'+', '-'),
FROM_UNIXTIME(changed)
FROM u1234567_d.node n, u1234567_d.node_revisions r
WHERE n.vid = r.vid

Samt kopplar dessa inlägg/sidor till rätt kategorier.

INSERT INTO u1234567_a.wp_term_relationships (object_id, term_taxonomy_id)
SELECT nid, tid FROM u1234567_d.term_node;

UPDATE wp_term_taxonomy tt
SET `count` = (
SELECT COUNT(tr.object_id)
FROM wp_term_relationships tr
WHERE tr.term_taxonomy_id = tt.term_taxonomy_id
);

Vi importerar även kommentarer och döljer eventuella dolda kommentarer.

INSERT INTO u1234567_a.wp_comments (comment_post_ID, comment_date, comment_content, comment_parent, comment_author, comment_author_email, comment_author_url, comment_approved)
SELECT nid, FROM_UNIXTIME(timestamp), comment, thread, name, mail, homepage, status FROM u1234567_d.comments;

UPDATE `wp_posts` SET `comment_count` = (SELECT COUNT(`comment_post_id`) FROM `wp_comments` WHERE `wp_posts`.`id` = `wp_comments`.`comment_post_id`);

Sedan ordnar vi lite radbrytningar i de importerade inläggen/sidorna.

UPDATE u1234567_a.wp_posts SET post_content = REPLACE(post_content, '', '');

För att till sist ändra sökvägen till samtliga bilder för våra importerade inlägg/sidor.

UPDATE u1234567_a.wp_posts SET post_content = REPLACE(post_content, '"/sites/default/files/', '"/wp-content/uploads/sites/8old/');

UPDATE u1234567_a.wp_posts SET post_content = REPLACE(post_content, 'http://www.exempel.se/sites/default/files/', '/wp-content/uploads/sites/8old/');

Ersätt http://www.exempel.se ovan med adressen till den tidigare Drupal-sidan. Sökvägen till filerna i Drupal kan även behöva anpassas. Sedan är vi klara med våra SQL-kommandon.

Om man vill importera de tidigare användarna från Drupal-databasen till WordPress-databasen så kan man följa instruktionerna i slutet av detta blogginlägg: Migration from Drupal to WordPress. I mitt fall så gjorde jag inte det, utan samtliga inlägg/sidor kopplades till min enda WordPress-användare (som skapades när jag installerade WordPress).

6. Några saker kvarstår innan vi är helt klara med flytten. Först så behöver vi hämta samtliga bilder från Drupal-sidan och lägga upp dem i WordPress. Det gör man genom att logga in mot den gamla Drupal-sidan via FTP/SFTP och hämta ner samtliga bilder under /sites/default/files/ (standardsökvägen för Drupal-sidor, kan behöva anpassas). Dessa laddar man sedan upp mot den nya WordPress-sidan under /wp-content/uploads/sites/8old/ (skapa old-mappen). Detta innebär dock att bilderna inte hamnar i WordPress inbyggda mediahantering.

7. När vi importerade sidorna från Drupal, med ovan angivna SQL-kommandon, så skapades de som inlägg i WordPress. Om man vill att de istället ska vara sidor i WordPress så kan man installera/aktivera följande WordPress-tillägg: Post Type Switcher. Med det tillägget installerat så är det bara att redigera valfritt inlägg och ändra ”Post Type” till Page för att ändra inlägget till en vanlig sida.

Mycket svårare än så här är det inte att flytta en sida från Drupal till WordPress.

Utöver ovanstående saker så behöver man givetvis ställa in permalänkarna på din nya WordPress-sida, skapa användare, välja ett tema och strukturera upp sina sidor/inlägg osv. För en normalstor sida tar det inte mer än någon timme eller två. Därefter är det WordPress för hela slanten som gäller!

Lämna gärna en kommentar om du har några frågor eller om du flyttar från Drupal till WordPress med denna guide.

Uppdatera er hemsida – eller bli hackade!

– Vad är den vanligaste orsaken till att en hemsida blir hackad? Att den är dåligt uppdaterad.

Precis som datorer behöver säkerhetsuppdateringar så behöver även hemsidor uppdateras regelbundet. Skillnaden mellan datorer och hemsidor är dock att hemsidorna alltid, dygnet runt och året om, är uppkopplade. Det innebär att de är ännu mer utsatta för attacker och säkerhetshål. Ändå uppdateras hemsidor mer sällan än datorer.

Många av våra kunder använder färdiga hemsidelösningar, såsom WordPress, Joomla! och Drupal. Det är riktigt bra, med tanke på de många och bra möjligheter som dessa lösningar erbjuder. Men det finns även en baksida till detta.

När det uppstår säkerhetshål i färdiga hemsidelösningar så dyker det även upp program som utnyttjar dessa säkerhetshål och hackar hemsidor som är sårbara (dvs, dåligt uppdaterade). Dessa program är väldigt vanliga – ja, faktum är att de arbetar automatiskt och oavbrutet över hela nätet.

När en hemsida blir hackad så märks det oftast inte till en början. Hemsidan fylls dock allt eftersom med illasinnat material (länkar och program). Många hackade sidor utnyttjas även för att skicka ut spam. Med tiden blir hemsidan långsammare, fungerar allt sämre och kan även blockeras i Google (Google svartlistar hackade sidor). En hackad hemsida hjälper nämligen till att hacka ännu fler hemsidor.

Om man har ett företag som är beroende av sin hemsida så kan man drabbas väldigt hårt av en hackad hemsida. I värsta fall kan man förlora hela sin verksamhet.

Hur vanligt är det då att hemsidor hackas? Ja, våra tekniker hjälper i genomsnitt 5 kunder/vecka som har fått sina hemsidor hackade. Det är då kunder som har upptäckt att deras hemsidor är hackade. Mörkertalet är sannolikt stort.

Hur uppdaterar man då sin hemsida? Här är instruktioner för de mest populära hemsidelösningarna hos våra kunder:

– Uppdatera WordPress

WordPress uppdateras enklast direkt via dess administrationsgränssnitt (wp-admin). Under Adminpanel > Uppdateringar kan man hitta och installera tillgängliga uppdateringar för WordPress samt dess tillägg och teman.

För mer om säkerhet i WordPress, läs gärna vårt tidigare inlägg Guide till en säkrare och snabbare WordPress-sida. Där visar vi t ex hur man kan få e-post när uppdateringar är tillgängliga för WordPress.

– Uppdatera Joomla!

Joomla! har historiskt sett varit lite svårare att uppdatera. Men från version 2.5, som släpptes i början av 2012, har även Joomla! fått enkla funktioner för uppdatering av system och tillägg. Dessa är tillgängliga direkt vid inloggning i administrationsgränssnittet.

– Uppdatera Drupal

Drupal är lite mer komplicerat att uppdatera. Det finns inbyggda funktioner för att få information om när uppdateringar är tillgängligar, både via administrationsgränssnittet (under Reports > Available updates) och via e-post.

Uppdateringen av Drupal behöver dock utföras manuellt och här är bra instruktioner för detta: Update your Drupal site from one minor 7.x version to another minor 7.x version

Avslutningsvis, tänk på att det inte bara räcker med att uppdatera det huvudsakliga systemet utan att man även måste hålla tillägg, moduler och teman uppdaterade. Det är faktiskt vanligare att säkerhetshål uppstår i olika tillägg än i själva systemet. Så håll extra koll på detta och installera inga tillägg som inte faktiskt används på hemsidan.

Om ni har en hemsida hos oss, som har blivit hackad, så kan våra tekniker givetvis hjälpa till att återställa en tidigare backup av er hemsida. Trots detta så brukar en hackad hemsida ändå innebära en hel del extra arbete även för berörda kunder.

Det bästa är helt enkelt att hålla sin hemsida uppdaterad, så att man slipper få den hackad.

Framtidens webbhotell: en rapport från WHD

Förra veckan var ett gäng från FS Data på World Hosting Days (WHD) i Tyskland. Det är världens största mässa för webbhotell och serverleverantörer, med ett hundratal utställare och 3-4 000 besökare från hela världen. Dagarna var långa med såväl föreläsningar och produktpresentationer som sociala aktiviteter och umgänge.

Det var ett väldigt lyckat, intressant och givande besök. WHD arrangeras en gång om året, i anknytning till den stora nöjesparken Europa Park. För att komma till den stora mässhallen så fick man åka med en monorail genom nöjesparken. Om ni vill se fler bilder från WHD, kika då gärna på vårt fotoalbum från besöket på Facebook.

Bortsett från den gigantiska nöjesparken, vårt romerskt inspirerade hotell och de rejäla ölfesterna så gav WHD oss många arbets- och framtidsrelaterade intryck. Vi tänkte dela med oss av detta till er, för att se vad ni tror och tycker om framtidens webbhotell.

När det gäller framtidens webbhotell, de närmaste 5-10 åren, så såg vi främst två huvudsakliga trender på WHD:

Molnet

Det har inte varit möjligt att besöka en IT-mässa eller läsa en IT-tidning de senaste åren utan att bombarderas av uttrycket ”molnet” (kolla t ex http://molnmolnmoln.se som räknar antalet gånger som IDG.se just nu innehåller detta uttryck).

Men molnet har börjat gå från något luddigt, med många olika meningar och innebörder, till ett desto mer samlat och standardiserat uttryck. Om man, väldigt enkelt, ska förklara ”molnet” så är det tekniskt och geografiskt obegränsade datorresurser, som hanteras via valfria gränssnitt på en ”du betalar för det du använder”-basis.

En viktig detalj i molnet, som hittills tyvärr har förbisetts, är standardiseringar. Dagens befintliga molntjänster saknar en standardiserad plattform/struktur. Det innebär rent konkret att det är väldigt svårt, om inte omöjligt i vissa fall, att byta från en molntjänst till en annan.

Nu finns det sedan 1 1/2 år tillbaka ett initiativ för att skapa standardiseringar för molnet, som även presenterades på WHD. Detta projekt heter OpenStack och bland de företag som är involverade här märks bl a Dell, Intel och NASA. OpenStack är fortfarande ett väldigt ungt projekt, men det lovar gott för framtiden.

En molntjänst som dock lyser med sin frånvaro i standardiseringssammanhang, det är världens största molntjänst: Amazon AWS. Med närmare en halv miljon servrar i sitt globala moln så är detta ytterst beklagligt. Amazon gör många saker rätt med molnet, men i det här fallet så agerar de väldigt fel.

Amazons molntjänst anses av många vara den främsta utmanaren till de traditionella webbhotell- och servertjänsterna. Det finns inget företag inom vår bransch som har möjlighet att mäta sig med dem rent tekniskt och infrastrukturmässigt sett. Företaget OnApp presenterade dock en potentiell lösning för detta på WHD.

OnApp håller nämligen på att introducera en lösning som gör det möjligt för webbhotell att distribuera datalagringen åt sina kunder till datahallar över hela världen. Genom att använda deras tjänster kan man erbjuda sina kunder en molntjänst, samtidigt som man köper och säljer resurser från andra webbhotell som också använder OnApp.

Även om ett ”riktigt moln” förutsätter att man inte är geografiskt begränsad så var diskussionerna om lokala molntjänster många på WHD. Med lokala molntjänster avses molntjänster som marknadsförs och säljs med fokus på ett visst område/land. Efterfrågan på detta ökar, inte minst med tanke på alla datalagringsdirektiv och lagar som vi har sett den senaste tiden.

Fördelen med en lokal molntjänst, jämfört med en större internationell motsvarighet, är möjligheterna till bättre anpassad service och support. Man kan jämföra detta med e-posttjänster. Även om det finns enorma internationella e-posttjänster såsom Gmail och Hotmail så väljer merparten av alla kunder ändå att använda en lokal tjänst (dvs, ett webbhotell i sitt eget land).

Mer eller mindre alla leverantörer av lösningar för webbhotell och servertjänster erbjuder numera någon form av molnfunktionalitet. Oavsett om man, såsom FS Data, har en egenutvecklad kontrollpanel/system eller köper in en färdig lösning så är molnet rätt väg framåt.

Vi har sedan en längre tid tillbaka likaså arbetat åt detta håll. Att få många av våra teorier och tankar om molnet bekräftade på WHD var givetvis väldigt trevligt och vi ser fram emot att få visa mer konkreta exempel på våra egna molntjänster här framöver.

Applikationer

Den andra stora ”snackisen” på WHD, det var applikationer. Vår bransch går alltmer från det traditionella upplägget med att erbjuda utrymme, trafik och funktioner till att erbjuda färdiga applikationer. Till detta räknas öppna lösningar såsom WordPress, Drupal och Joomla! samt färdiga tjänster såsom Google Apps, Office 365 och Dropbox.

Det här är ingen nyhet för oss, utan något som vi har sett (och arbetat med) en längre tid. Rent konkret så handlar det om att vi som webbhotell behöver börja erbjuda våra kunder de tjänster och lösningar som de faktiskt vill ha, istället för att tvinga kunderna att anpassa sig efter våra paketlösningar.

Morgondagens webbhotellskunder nöjer sig inte heller med att enbart använda en tjänst för hemsida och e-post. De vill få möjlighet att samarbeta bättre, att ta backup på egen data, att hantera allt fler tjänster på nätet inom sin egen organisation osv.

Dagens traditionella webbhotell och serverleverantörer måste anpassa sig efter detta. Vi behöver alla se över våra tjänster, komplettera vårt utbud, möta våra kunders önskemål och ta del av de möjligheter som alla dessa nya applikationer kan erbjuda.

I takt med att webben blir allt mer applikations-fokuserad så skiftar även fokus för många hackare. Istället för att utnyttja säkerhetshål i traditionella användarmiljöer (lokala operativsystem och program) så ser vi allt fler attacker mot webbaserade applikationer. Uppskattningsvis 75 % av alla hemsidor är idag sårbara med säkerhetshål.

När en hemsida hackas så märks det många gånger inte direkt heller. Hackarna tar kontroll över hemsidorna, sprider farlig kod till dess besökare och kan likaså bidra till att (hackade) hemsidor plockas bort från olika sökmotorer. Faktum är att 6 000 hackade hemsidor blockeras av Google varje dag.

För att stävja och motverka detta så har det dykt upp ett flertal leverantörer som erbjuder säkerhetsskydd för hemsidor. De övervakar hemsidorna och kan både ta bort farlig kod samt informera hemsideägarna om hackade sidor. Det är enkelt uttryckt ett virusskydd för hemsidor. Detta är en utveckling som vi kommer att fortsätta följa väldigt nära här på FS Data.

Webbhotell är specialiserade på att erbjuda stabila, säkra och snabba tjänster med effektiv support och service. När vi nu börjar integrera alla dessa olika specialiserade applikationer, då kommer nästa stora revolution inom webbhotellsbransch att ske.

Övrigt

WHD hade, av förklarliga skäl, ett rätt så stort teknikfokus. AMD var t ex på plats och passade på att lansera en helt ny serverprocessor. Intel var snabba med att svara att 9 av 10 servrar runt om i världen innehåller Intel-processorer. Dell, HP, Fujitsu, IBM mfl visade alla upp olika nya servermodeller och konfigurationer.

Ett flertal leverantörer av kontrollpaneler och system för webbhotell var där. Parallels lanserade en ny version av Plesk, som erbjuder stöd för både Linux och Windows (vilket vår kontrollpanel Waff har haft länge), Atomia berättade om sina erfarenheter med DNSSEC, CloudLinux demonstrerade den ideala PHP-konfigurationen för webbhotell (som vi likaså har haft länge) osv.

För oss som är ena riktiga webbhotell- och domännamnsnördar så var World Hosting Days en riktigt härlig upplevelse. Även om vi redan har bra koll på (och arbetar med) mycket av det som presenterades så var det ändå skönt att få en bekräftelse om att vi är på rätt väg.

Framtiden för oss webbhotell må vara full av moln, men för våra kunder kommer det bli allt enklare att dra nytta av de många olika möjligheter som Internet erbjuder! 🙂

Avslutningsvis

Vad tror ni, som webbhotellskund (men även våra branschkollegor) om denna framtid? Lämna gärna en kommentar!

Utfasning av PHP 4

FS Data var ett av de första svenska webbhotellen att erbjuda stöd för PHP 5. Redan i november 2005 fick våra kunder möjlighet att själva välja mellan PHP 5 och PHP 4, via vår egenutvecklade kontrollpanel Waff. Även om merparten av våra kunder idag använder PHP 5 så har vi fortsatt erbjuda stöd för PHP 4, ända tills nu.

PHP 4 utvecklas, sedan flera år tillbaka, inte längre. Underhållet har likaså upphört och det är därför dags för oss att ta bort PHP 4 från våra webbhotellsservrar. Detta för att vi ska kunna säkerställa en så snabb, stabil och säker miljö för våra kunder.

Senast till den 27:e april 2012 så kommer vi att fasa ut PHP 4.

Som kund hos oss är det enkelt att byta från PHP 4 till PHP 5. Logga bara in i kontrollpanelen och byt PHP-version under ”Hemsida” > ”PHP”. Om man känner sig osäker, eller vill få hjälp med detta, så är det bara att kontakta vår kundtjänst. Uppgraderingen är givetvis helt kostnadsfri.

Vi rekommenderar alla kunder, som fortfarande använder PHP 4, att uppgradera till PHP 5 snarast möjligt. Om man använder en egenutvecklad lösning så finns det en guide till hur man migrerar från PHP 4 till PHP 5.

Om man använder färdiga lösningar såsom WordPress, Joomla eller Drupal så bör man uppgradera även dessa. Information om hur man går tillväga finns på hemsidan för respektive lösning. Här är länkar till de tre nämnda:

 

Därför fungerar PHP bäst hos FS Data

PHP, eller PHP: Hypertext Preprocessor, är det mest populära programmeringsspråket på Internet. Sidor som Facebook och Wikipedia är utvecklade i PHP och över 77 % av alla webbservrar erbjuder idag stöd för PHP. Trots detta kan PHP vara riktigt svårt att administrera och säkra upp, särskilt i delade servermiljöer (servrar med flera kunder på).

Med PHP kan man utföra väldigt komplicerade saker, väldigt enkelt. Och därigenom även enkelt orsaka problem, om PHP inte är korrekt uppsatt. Som standard körs t ex PHP med samma användare som webbservermjukvaran (vanligtvis Apache), vilket – i en delad miljö – innebär att man har tillgång till alla (!) hemsidor på servern ifråga.

Det här är dock inget som berör våra webbhotellskunder.

Hos oss körs nämligen PHP med respektive kund som användare, genom en egenutvecklad lösning som vi introducerade redan för 7 år sedan. Det var innan lösningar såsom suphp, php-fpm osv var allmänt kända.

Vi har givetvis fortsatt att utveckla detta och kan därför erbjuda en av marknadens mest snabba och säkra PHP-lösningar idag.

Det är mycket tack vare vår egenutvecklade lösning som vi har möjlighet att erbjuda stöd för PHP 4, 5.2, 5.3 och 5.4, ända ner på katalognivå. Av samma orsak har vi även stöd för fler PHP-moduler än de flesta andra webbhotell, vilket denna phpinfo-sida tydligt visar.

Eller på ren svenska: PHP fungerar bäst hos FS Data. 😉

En liten uppdatering av PHP:

När vi introducerade vår PHP-lösning så existerade inte färdiga lösningar såsom WordPress, Drupal, Joomla osv. Dessa PHP-baserade lösningar hanterar t ex felmeddelanden på ett annat sätt än vad som tidigare var praxis (att inte hantera dem alls).

För att förbättra vårt stöd för sådana här färdiga lösningar, så kommer vi utföra en liten förändring i PHP i början av nästa vecka. Då behöver man inte längre anpassa .htaccess för korrekt felhantering i WordPress hos oss. Dessa färdiga lösningar kommer då att fungera ”out of the box” hos oss.

Förändringen sker natten mellan söndag-måndag. Våra kunders PHP-baserade hemsidor/lösningar påverkas inte av detta. Vi vill dock ändå informera er tydligt. Om man har anpassat sin .htaccess-fil, enligt tidigare instruktioner, så kommer allt ändå att fortsätta fungera. PHP-direktiven php_flag och php_value kommer likaså få ett korrekt beteende i underkataloger.

Lämna gärna en kommentar eller kontakta vår kundtjänst om ni har några frågor eller funderingar om detta.