Arkitektur

Valet av en stabil arkitektur som skalar horisontellt är kritiskt. I fredags hade vi en session kring arkitektur och kom fram till följande förslag:

1. Längst fram två lastbalanserare, Linux LVS som monitoreras och styrs via Heartbeat.

2. Sedan 4 st cachar av typen Varnish. Varnish lastbalanserar mellan fyra WP-maskiner med Pen.

3. 4 st WP-maskiner (utan admin) står för leveransen utåt. WP-Admin ligger på två separata maskiner (för redundans) som inte exponeras utåt. Memchached körs där det finns minne över.

4. HyperDB kopplar ihop WP med MySQL-klustret som består av 2 st MySQL-Mastrar för skrivning (för redundans – ej prestanda) och 2 st MySQL-slavar för läsning.

På så sätt kan ytterligare maskiner läggas till i varje led genom horisontell skalning: Varnish (knappast troligt, 4 är mer än nog), WordPress eller Mysql-slavar för läsning.

Annonser

Jobba flera på samma artikel

En av de största utmaningarna för WordPress är att flera redaktörer ska kunna jobba på samma artikel samtidigt. Inte i samma block men väl i olika delar. Det händer ofta och särskilt vid live-rapporteringar. En reporter skriver och uppdaterar texten i artikeln. Ettaredaktören skruvar på puffen som ligger på ettan och uppdaterar rubriken. En tredje redaktör lägger till bilder allt eftersom det kommer in.

Det här har vi inte hittat någon lösning på och är ett krav för att kunna använda WordPress hela vägen. Några idéer?

Bättre snabbtangenter för WordPress

Interfacenavigering med krav på mus är en fiende till  effektivt och hållbart arbetsflöde. WordPress kommer med en grunduppsättning av snabbtangenter som kan aktiveras på användarnivå – men uppsättningen är tyvärr anpassad för den genomsnittlige bloggaren (moderera kommentarer) och inte för den redaktionella medarbetaren (hoppa mellan textfält i textredigeraren) .

Det borde dock vara en smal sak att sätta upp snabbtangenter anpassade för en redaktion med grymma jQuery-pluginen shortcuts.js.

Uppdatering:
En enkel plugin för kortkommandon till Spara, Publicera och Förhandsgranska heter MindValley Shortcut Framework och den verkar fungera bra.

Säkerhet

För att stärka upp säkerheten och tajta till vem som gör vad finns det några saker som behöver åtgärdas:

1. Under Personliga Inställningar aktiveras Använd alltid HTTPS när du besöker administrationssidor. Måste så klart vara ikryssad för alla. Info här.

2. Tillåt bara administration och inlägg från vissa IP-adresser. Går att styra på webbservern genom att begränsa access till /wp-admin/ och i källkoden eller i Varnish. Eller varför inte alla tre?

3. Byt namn på /wp-login.php /wp-admin/

Här finns en artikel med fler förslag http://www.wpbeginner.com/wp-tutorials/11-vital-tips-and-hacks-to-protect-your-wordpress-admin-area/

 

En till http://codex.wordpress.org/Hardening_WordPress

Fler tips?

WordPress—vän av ordning?

Eftersom jag till vardags har båda fötterna i Java™-världen är jag förhållandevis bortskämd när det kommer till utvecklingsverktyg. Jag är alltså ganska peppad på att få någon sorts Continuous Integration att fungera med mina PHP-projekt/Wordpress-plugins. CI är ganska ointressant utan enhetstester, och det finns som tur är flera ramverk för enhetstestning i PHP, det som verkar vanligast är PHPUnit (SimpleTest kan vara ett annat alternativ), som dessutom fungerar bra tillsammans med Selenium.

För att mocka WordPress-funktionalitet—något som man kanske vill göra när man bygger WP-plugins—finns ramverket Mockpress för de av oss som gillar sådant.

Möjligheterna till att utnyttja enhets- och integrationstester är alltså goda (och bra ursäkter till inte göra det är sällsynta), och glädjande nog finns det både verktyg för statisk kodanalys för PHP, och åtminstone en CI-server som kan köra både tester och kodanalys—Jenkins. Sebastian Bergmann har en utmärkt guide för att använda Jenkins för PHP-projekt och ett strålande verktyg, PPW, som förenklar processen att komma igång.

Avslutningsvis kan man konstatera att eftersom ett plugin eller theme i WordPress väsentligen är en katalog i ${wp-root}/wp-content/{plugins|themes}/ borde det vara både möjligt och rimligt att ha en hantering av versioner och releaser som inte är av typen ”vilda västern”.

Tjena alla WordPress diggare

Jag har under veckans gång fokuserat på hur man bygger teman till wordpress och skulle vilja slå ett slag för en bra bok i ämnet. Det saknas ju inte tutorials och dokumentation runt  worpress men jag skulle endå vilja rekomendera följande bok.

https://i1.wp.com/sitepointstatic.com/images/books/covers-92x116-bg/wordpress1.png
http://www.sitepoint.com/books/wordpress1/

Det kan ju vara ganska skönt att ha en bok ibland även om man tillbringar större delen av sin vaktna tid på Internet (där allt finns). Denna bok läser man ut på några kvällar och beskriver hur man skapar säljande teman till worpress. Boken har ett freelance fokus, och beskriver alla steg i utveklandet av ett tema, allt från palneringsstadiet till marknadsföring. Boken ger en bra inblick och förståelse av WP’s temasystem samt en inblick i WP communityt kring temautveckling.

Boken har insirerat mig till att komma igång med att bygga smarta teman till Aftonbladets Wp sajter, att sitta brevid Christian Bolstad i några veckor har ju också varit en källa till outtömlig kunskap och inspiration.

Jag gillar för övrigt sitepoint och många av deras andra böcker och guidlines. Jag har följt dom och varit ett fan sedan de gav ut denna banbrytande bok 2003.

http://www.amazon.com/HTML-Utopia-Designing-Without-Tables/dp/0957921829

Om ni skulle stötapå mig på stranden i sommar är det troligt att jag sitter i skuggan och läser någon av följande böcker i denna fyrklöver

https://i2.wp.com/sitepointstatic.com/images/books/htmlcss1/3dcover-flat.png  https://i2.wp.com/sitepointstatic.com/images/books/covers-92x116-bg/cloud1.png  https://i0.wp.com/sitepointstatic.com/images/books/covers-92x116-bg/design2.png  https://i1.wp.com/sitepointstatic.com/images/books/covers-92x116-bg/wordpress1.png

Skala WordPress – fixa databasen

En vanligt fråga är om det ens är möjligt att bygga en webbplats i Aftonbladets storlek i WordPress. När den dyker upp känns det bra att peka på WordPress.com. Med dess 25 miljoner bloggar och en halv miljard dagliga sidvisningar kan den väl ses som en kapabel installation. Att 400.000 inlägg och lika många kommentarer postas varje dag visar ju även att det är ett CMS som pallar med konstanta inserts.

Men varför finns det då en myt om att WordPress skalar dåligt?

Ett misstag som många gör är att utgå från en egenhostad standardinstallation med slumpvis valda plugins från WordPress rika pluginkatalog. En installation som inte är förberedd för hög last och som dessutom använder sig av tilläggskod som lika gärna kan vara skriven av en glad amatör som en ingenjör kommer naturligtvis att stå pall särskilt länge för en stor besöksvolym.

Som standard skeppas WordPress förberedd för en LAMP-installation på ett vanligt webhotell – målet är det ska vara väldigt låg tröskel för nyfikna. Den berömda 5-minutersinstallationen är en nycklarna till WordPress enorma framgång.

Så, vad kan den med ambitioner göra för att nå framgång med en större installation? Förutom hygienfaktorer som snabba diskar, kraftiga processorer och feta linor finns det mycket att göra. LAMP i CGI-läge är smidigt och välbekant för många – men har oftast för mycket overhead. Automattic själva kör med proprietära Litespeed, som inte bara är ruggigt snabbt utan även är kompatibelt med en mängd Apachemoduler. Jag väljer ofta en lösning med Nginx och fastcgi. För den som enkelt och snabbt vill prova något nytt rekommenderas LowendVPS’ fantastiska bootstrapping-script – med några kommandon får du en komplett NAMP-miljö uppconfad för WordPress.

Även i WordPress-stacken finns mycket att göra:

Ett vanligt prestandaproblem beror på allt för dynamiska permalänkar:  /%postname%/ som permalänkmall må vara snyggt och piffigt men innebär också onödigt hög belastning i vid var anrop eftersom wp först måste lista ut vad sidan innehåller för att kunna servera rätt sorts innehåll. Använd till exempel /artikel/ som bas för tidningsartiklar (eller varför inte klassikern /%year%/%monthnum%/%day%/%postname%/ ?).

Eftersom WordPress API är väldigt tillåtande är det även möjligt att snabbt slänga ihop ett tema eller plugin och sedan sprida det vidare till världen. Hastighetsoptimering eller certifieringar är inget krav för att publicera sina alster i de officella tema- och pluginkatalogerna.

Plocka fram dina pluggar och teman. Kavla upp ärmarna:

  • Se till att alla plugins gör eventuella SQL-anrop genom $wpdb-objektet – egnabryggda lösningar med mysql_connect() är inte bara onödigt, det förhindrar caching och lastfördelning.
  • Se till att alla frågor som inte måste vara realtids-fräsha cachas via WP_Object_cache eller Transients API:et (du vill antagligen använda det senare eftersom det garanterar att data sparas och faller tillbaka till mysql-lagring om andra möjligheter saknas).
  • Installera memcached på så många maskiner som möjligt och kicka igång Memcached Object Cache som ser till att WordPress objectcache använder snabbt ram i stället för dyra dbfrågor.
  • Välj ut en cache-plugin som lirar bra med dina databasfrågor. En favorit på senare tid är  DB Cache Reloaded Fix  som inte bloatad med system för sidcachning (som jag ändå inte använder).
När grundjobbet är avklarat är det dags att förbereda installationen för en större mängd frågor. Det först är att byta ut standardklassen för databasfrågor mot HyperDB – ett databasmodul på steroider utvecklad för WordPress.com. Med stöd för replikering och partitionering är det är nu möjligt att klustra upp installationen ordentligt och fördela sqlfrågorna över en mängd servrar.
Nästa steg är att se dynamiska sidor och frontend-cachar, men det är en bloggpost för sig.