Utveckling

Den gången vi låste in oss en vecka för att bli bättre.

2018 är äntligen här och för oss på Angry Creative innebär årets första vecka hackvecka. Det betyder att vi låser in oss på kontoret och använder hela veckan till att fokusera på interna projekt och kompetensutvecklar för att bli ännu bättre. Vissa projekt kommer även att bidra till communityn genom att vi släpper dem som open source

Hur fungerar hackveckan?

Vi samlar kontinuerligt på oss olika idéer och funderingar kring plugins och funktionalitet i vårt arbete med WordPress och WooCommerce. Vi kommer på idéer för hur våra arbetsprocesser skulle kunna bli ännu bättre och smidigare. Det finns funderingar kring projekt vi skulle vilja utveckla, förenkla eller finputsa. Vi stöter på problem som vi vill kunna lösa på ett snyggare och bättre sätt.

Under denna hackveckan valde vi ut några av dessa tankar och idéer som vi samlat på oss sedan sist och gjorde dem till avgränsade projekt. Därefter fokuserade vi, gemensamt och i mindre grupperingar, våra ansträngningar på att lösa dessa. När veckan var slut hade vi fördjupat våra kunskaper samtidigt som vi har förbättrat våra produkter och tjänster. Vissa av dessa projekt och plugins behålls sedan internt för våra kunder och vissa projekt delas som open source med communityn.

Under denna hackvecka, den första för året, så har vi fokuserat på fyra huvudområden.

  • Bli löjligt mycket bättre på Enhetstester.
  • Vårt standard tema, Qala, som ligger till grund för alla våra projekt. Tack vare den stabila grund som Qala ger så sparar vi varje kund hundratals timmar i varje projekt.
  • Vår lösning för hur man smidigt kan arbeta med produkter över flera sajter i ett WooCommerce multisite-nätverk.
  • En lösning för att kunna koppla Bank-ID till kundinloggningar. På så sätt kan man vara 100% säker på att kunden är den som den uppger sig för att vara.

WordPress Meetup

Denna gång avslutas hackveckan med ett WordPress Meetupkontoret i Norrköping. Den här gången är temat Kulturfrågor inom organisationer som arbetar med utveckling eller Building better developers and developer organisations.

Kvällen inleds med en föreläsning på engelska från Bjørn Ensover Johansen – What does it take to be a REAL developer? Efter det talar vår egen Samuel Sapire om Kultur för snabbväxande utvecklarorganisationer. Kvällen avslutas med en paneldebatt. Vi ses väl där?

HTTPS blir affärskritiskt

Kryptering av trafiken mellan webbläsare och webbserver håller på att bli en hygienfaktor för sajtägare. Låt inte avsaknaden av https komma mellan dig och dina besökare.

Redan för två år sedan gick Google ut i ett ovanligt utspel om att https, eller kryptering av trafiken mellan webbserver och webbläsare, var en rankingsignal. Ingen viktig rankingsignal, eftersom den bara påverkar 1 procent av sökningarna i världen, men med tanke på den massiva volymen av sökningar som sker varje dag är en procent ganska mycket i absoluta tal.

Det är inte så ofta Google är så öppen kring sina rankingsignaler. De är tydliga med att innehåll och länkar är viktigast, sedan gjorde de en stor sak av att mobilanpassning är viktig för ranking i det mobila söket.

Men Google har ökat fokus på https genom att deras populära webbläsare Chrome i januari 2017 kommer att börja varna för sajter med inloggning eller kreditkortsbetalningar som osäkra om de saknar https.

–Idag markeras HTTP-anslutning med neutrala indikatorer, men detta speglar inte avsaknaden av säkerhet för HTTP-anslutningar. När du laddar en webbsida via HTTP så kan någon annan på nätverket se sidan eller manipulera den innan den visas för dig, skriver Google Security Blog.

I januari 2017 kommer Chrome att börja varna för sajter som kräver inloggning eller kreditkortsbetalningar som osäkra om de saknar https.

I januari 2017 kommer Chrome att börja varna för sajter som kräver inloggning eller kreditkortsbetalningar som osäkra om de saknar https.

I nästa steg kommer sajter med http-anslutning märkas som osäkra när användarna surfar med inkognito-läge. Tanken är att användare i inkognito-läge förväntar sig bättre integritet på nätet. Till slut kommer alla http-sidor flaggas som osäkra med en röd varningstriangel i adressfältet.

https 1

Nästa steg är att varna för alla sidor som saknar https.

När Google så tydligt kräver https-anslutningar från webbsajter är det knappast möjligt att vägra. Det är hög tid för alla sajtägare att snabbt skaffa sig https. Google har själva föregått med gott exempel genom att kryptera trafiken till alla sina tjänster.

För att kryptera sin webbsida krävs ett SSL-certifikat (Secure Sockets Layer). Ett SSL-certifikat är ett elektroniskt dokument som bekräftar din företagsidentitet och som gör det möjligt för webbservern att upprätta en säker krypterad anslutning till besökarnas webbläsare. Angry Creative fixar det för kunderna som ligger hostade i vårt hostingbolag Synotio.

Därför ska du kryptera webbtrafiken:

  • Bevisa för besökaren att sajten verkligen är den den påstår sig vara
  • Säkra att ingen utomstående har manipulerat datan på sajten
  • Se till att ingen utomstående kan avlyssna kommunikationen mellan webbservern och webbläsare

Bonnier pressar gränserna för WordPress

Bonnier Tidskrifter pressar gränserna för vad man kan göra med WordPress. Med hjälp av WordPress API tar en ny app bara ca 20 timmar att utveckla.

Bonnier Tidskrifter påbörjade migrationen från publiceringsverktyget Episerver till WordPress i december 2013 med hjälp av byrån Odd Alice som bistått med både arbete och strategisk rådgivning längs vägen. Med det handlade om mer än att byta ett publiceringsverktyg mot ett annat. Hela projektet kommer att vara klart under Q1 2017.

–WordPress är idag ett ramverk för webbapplikationer oavsett hur vi presenterar vårt innehåll. Genom att arbeta med WordPress API kan vi idag bygga en mobilapp för ett av våra varumärken på 20 timmar, säger Gabriel Sjölund, produktchef för digitala medier på Bonnier Tidskrifter.

Tidigare i år lanserade exempelvis Allt om mat en vin-app där alla nya viner på Systemet recenseras. Då fungerar WordPress som ett innehållsbibliotek som både sajter och appar hämtar sitt innehåll från.

– I princip skulle vi kunna välja ett annat system än WordPress för att presentera ett varumärke på webben. WordPress blir ett innehållsbibliotek oavsett digital kanal, säger Gabriel Sjölund.

Tidskriftsförlaget Bonnier Tidskrifter har idag alla sina viktigaste varumärken på WordPress. Och Angry Creative har vunnit förtroendet att vara ansvariga för all förvaltning av alla deras WordPress-installationer och kompletterar den vanliga produktionen som utförs av Bonniers byråpartners. Förvaltning betyder allt från test, driftsättning, utvecklingsprocesser, driftsäkring och hur man arbetar mellan alla olika steg i processen. Ett prestige-uppdrag som kommer utifrån Angry Creative processer och långa erfarenhet av att bygga och förvalta avancerade WordPress-projekt.

Bonnier Tidskrifters senaste projektet är en ny version av Veckorevyn som redan tidigare fanns på WordPress.

–Vi är rätt stolta över det vi har gjort. Det hade ju varit enklare att bygga en app som ett separat projekt, men genom att vi utnyttjar WordPress API blir varje ny app ett ganska litet projekt, säger Gabriel Sjölund.

När medieföretag vill göra temasajter väljer man ofta WordPress för att det är enkelt att berätta historier på WordPress. Gabriel nämner exempelvis tidningen Dagens Nyheters undersajt för att uppmärksamma att tioårsminnet av tsunamin i Sydostasien.

Mycket av funktionaliteten på sina varumärken som exempelvis recepthantering på Allt om mat har Bonnier utvecklat själva.

– Vi låter oss gärna inspireras av färdiga plugin men i slutändan utvecklar vi själva. Vi vill inte vara beroende av ett tredjeparts plugin.

Har ni även vidareutvecklat gränssnittet mot tidningarnas redaktörer?

–En av fördelarna med WordPress är att de flesta är bekant med deras gränssnitt. Även nyanställda har ofta arbetat med WordPress tidigare. Därför har vi gjort något med gränssnittet.

Finns det några nackdelar med WordPress?

–Eftersom det är världens populäraste publiceringsverktyg utsätts vi ständigt för intrångsförsök. Man måste tänka på säkerheten och välja rätt hosting som kan hålla koll på loggar.

Bonnier Tidskrifter har valt att göra WordPress till navet i hela deras affärsverksamhet. Här ser vi ett nytt sätt att arbeta där ramverket gör det möjligt att lägga ut produktionen av enskilda varumärken på många olika leverantörer. Med det ställer samtidigt höga krav på processer, förvaltning, tester och hosting. Snabb utveckling kräver säker förvaltning.

Enhetstestning i WordPress

TL; DR

Enhetstester är kod som testar att dina funktioner returnerar vad du har tänkt dig. Du har större nytta av detta ju mer komplext ditt projekt är.

Vad är enhetstester?

Du kanske redan har hört talas om enhetstester, eller t o m använt dem själv? Inte? Det borde du börja med!

Enhetstester är kod som testar kod. Närmare bestämt att de metoder man har skrivit returnerar det resultat man har tänkt sig. Framförallt har man nytta av det i mer komplexa projekt där en klass kan användas av flera andra klasser och ju mer generell klassen är, desto mer vältestad behöver den vara.

Enhetstestning i WordPress

I WordPress är testning lite speciell. Dels är flödet lite annorlunda i WordPress jämfört med många ramverk. I WordPress, liksom i Drupal och en del andra system, använder man sig t ex av hooks och filter, vilket leder till att det kan vara svårt att spåra flödena i koden. Dels är det svårt att testa vy-delen, såsom teman och visuella funktioner. I många frameworks finns det stöd för att testa vyer också, men i WordPress är vi hänvisade till Selenium-tester och liknande. Det finns helt enkelt ganska mycket kod som inte går att enhetstesta.

Verktyg

WordPress har dock ett bra stöd för enhetstester. Dels finns det enhetstester för alla core-funktioner, dels finns det verktyg för att enkelt sätta upp skelett till tester för egna projekt med hjälp av WP-CLI. Vi använder dessutom några ytterligare verktyg som hjälper oss med vårt testarbete.

  • Travis CI – Continous Integration innebär att man kontinuerligt bygger sitt system och kör de tester man har för att upptäcka problem. Frekvensen kan vara olika, men ofta är det en del av flödet när man committar sin kod. För publika projekt på github är Travis gratis att använda. Man kan även sätta upp en matris av browsers, WordPress-version och Php-version som man vill testa.
  • Scrutinizer – Detta verktyg hjälper till att öka kodkvalité genom att leta efter möjliga buggar och förslag till kodförbättringar.
  • CodeSniffer – I CodeSniffer kan man sätta upp regler för hur ens kodstandard ser ut, t ex om variabler ska använda CamelCase, eller om kodblock ska påbörjas på samma rad som föregående eller ny rad. Programmet hjälper en sedan att upptäcka om man man bryter mot dessa regler och kan även hjälpa till att laga e del av problemen.

Liksom nästan alla php-projekt använder sig WordPress av biblioteket PHPUnit. När man skriver sitt test så skapar man ett objekt av den klass man vill testa. Man skickar in olika parametrar och jämför sedan det resultat man får tillbaka med det resultat man förväntar sig. Det finns en stor uppsättning jämförelsemetoder, som assertTrue, assertEquals, assertException osv.

Vad man bör och inte bör testa

Vad ska man testa, då? Det finns några saker som kan vara lämpliga att testa.

  • Korrekta värden – Skicka in värden du förväntar dig att metoden kommer att få ta emot och jämför med vad den borde returnera. Om du har en metod som tar emot en sträng, så skicka in en sträng och se till att du får tillbaka rätt resultat.
  • Extremvärden – Vad händer om du skickar in flyttal till en metod som förväntar sig heltal? Vad händer om du skickar in en tom sträng i en metod?
  • Felhantering – Kontrollera vad som händer om man använder metoden på ett sätt den inte är byggd för, t ex om du skickar in parametrar med fel format (t ex sträng istället för tal) eller kanske fel antal parametrar.

I WordPress finns det en del specifika saker man kan testa.

  • Är mina Custom Post Types korrekt uppsatta och kan man skapa nya objekt med dem?
  • Är pluginets roller skapade och har de korrekta rättigheter?

Det ligger alltså ett stort ansvar på dig att skriva lämpliga tester, men precis som med vilken programmering som helst finns det alltid möjlighet att gå tillbaka och förbättra sina tester. Faktum är att det är ett bra sätt att jobba med buggar. När man upptäcker ett oönskat beteende skriver man ett nytt test som hanterar detta.

Saker som är mindre lämpliga att testa är t ex saker som WordPress testar själv. Det finns t ex ingen mening med att testa att WordPress core-funktioner gör det de ska eftersom alla stabila WordPress-versioner bygger med de tester som finns.

Fixtures

En sak som kan vara intressant att känna till är fixtures. Om ens metod använder sig av egna datastrukturer vill man ofta kunna kontrollera resultatet. Fixturer är ett sätt att kontrollera data genom att sätta upp färdiga data-objekt. På så sätt kan man alltid veta att ens data innehåller det man tror att de ska göra. Om du t ex vill kontrollera att din metod som hämtar alla bokningar mellan 5-10 april så kan du med en fast uppsättning data kontrollera att din metod fungerar som den ska. Värt att notera att stödet för fixturer i WordPress inte är så utbyggt, åtminstone inte än.

Synlighet

Ett problem med att testa metoder handlar om synlighet. Eftersom man skapar ett objekt av den klass man ska testa så kommer man inte åt klassens privata metoder. Det finns lite olika filosofier kring hur man ska hantera dessa. Många tycker att man inte ska testa privata metoder, men om man behöver så finns det en lösning som heter ReflectionClass. Med hjälp av den skapar man ett objekt av sin klass och byter helt enkelt temporärt synlighet på den.

image00

Exempel

För att börja med tester kan du använda WP-CLI för att sätta upp ett test-skelett.

wp scaffold plugin-tests coolstrings

Så här kan den skapade mappstrukturen se ut:

image02

I vår plugin har vi skapat två metoder, en för att generera strängar och en för att ta bort oönskade tecken ur den:

public function generateCoolString( $length = 20 ) {
	$seed = 'abcdefghijklmnopqrstuvwxyz'
			. 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
			. '0123456789!@#$%^&*()';

	$rand = '';
	$len = strlen( $seed ) - 1;
	for ( $i = 0; $i < 20; $i++ ) {
		$k = rand( 0, $len );
		$rand .= $seed[ $k ];
	}

	return $rand;
}

public function sanitizeCoolString( $string ) {
	$allowed_chars = 'aeiuAEIU';

	$result = '';
	for ( $i = 0; $i < strlen( $string ); $i++ ) {
		if ( strpos( $allowed_chars, $string[ $i ] ) !== FALSE ) {
			$result .= $string[ $i ];
		}
	}
	return $result;
}

Våra tester, som ligger i tests/test-cool-string.php, ser ut såhär:

public function test_generate_cool_string() {
	$cool_object = new CoolString();

	// Test some good values
	$test_values = [
		20,
		30,
		100
	];

	foreach ( $test_values as $value ) {
		$cool_string = $cool_object->generateCoolString( $value );

		$this->assertTrue( is_string( $cool_string ) );
		$this->assertEquals( strlen( $cool_string ), $value );
	}

	// Test some bad values
	$test_values = [
		-5,
		'kalle',
		null,
		false
	];

	foreach ( $test_values as $value ) {
		$cool_string = $cool_object->generateCoolString( $value );

		$this->assertFalse( $cool_string );
	}
}

public function test_sanitize_cool_string() {
	$cool_object = new CoolString();

	// Test some good values
	$test_values = [
		'V4A#Pa1OSzuJ&8q0Tr$^' => 'AaOu',
		'eEVLmrQuxjl$q0MGzwNs' => 'eEu',
		'wUZckBvr0T4xJMYo*POH' => 'UoO'
	];

	foreach ( $test_values as $key => $value ) {
		$cool_string_sanitized = $cool_object->sanitizeCoolString( $key );

		$this->assertTrue( is_string( $cool_string_sanitized ) );
		$this->assertEquals( $cool_string_sanitized, $value );
	}
}

Kör testerna genom att navigera till plugin-mappen och köra phpunit.

image03

Med hjälp av våra tester kan vi se att vi har gjort några fel i koden.

  1. Vi har hårdkodat hur lång strängen vi returnerar ska vara.
  2. Vi har råkat glömma att o/O ska vara godkända bokstäver.
  3. Vi hanterar inte felaktiga parametrar.

Med några ändringar i vår kod går testerna igenom:

public function generateCoolString( $length = 20 ) {
	if ( !is_numeric( $length ) || $length <= 0 ) {
		return false;
	}

	// [...]

	for ( $i = 0; $i < $length; $i++ ) {

	// [...]

public function sanitizeCoolString( $string ) {
	$allowed_chars = 'aeiouAEIOU';

	// [...]
}

Nu går våra tester igenom!

image01

TDD

Till sist, några ord om Test Driven Development, eller TDD. TDD är ett sätt att utveckla som utgår från att man först skriver sina tester, därefter kodar och refaktorerar tills testerna går igenom och upprepar i en cirkel.

En del belackare tycker att TDD tar för lång tid att använda, eftersom man även måste lägga tid på att skriva tester och inte bara på att implementera funktioner, medan förespråkarna anser att man snabbt sparar in den tiden i färre buggar.

WordPress lämpar sig bara delvis för TDD eftersom en betydande del av den kod man producerar inte kan testas.

Loggövervakning i realtid med Splunk

Eftersom vi säljer supportavtal där vi ansvarar för våra kunders webbplatser är det viktigt för oss att ständigt kunna ligga steget före, helst till den nivån där vi kan arbeta proaktivt och hindra allvarliga fel – innan de uppstår. Om någonting händer våra kunders webbplatser förväntas vi kunna svara på varför någonting har hänt, samt se till att det inte händer igen.

Det finns många anledningar till varför saker kan hända. Vi tar ofta över ansvaret för andras webbplatser och dessa kan ha en hel del kvalitetsbrister. En administratör med hög behörighet kan av misstag råkat klicka på fel knapp och på så sätt genomfört en stor förändring. Ett annat inte alltför ovanligt scenario är att webbplatsen är byggd kring färdiga tillägg som efter en tid stöter på kompabilitetsproblem med nyare versioner av WordPress. I vissa fall har vi till och med sett att utvecklare tar bort funktioner ur sina tillägg – vilket kan innebära att en administratör inte kan fullfölja sin arbetsuppgift.

För en organisation som har investerat mycket i sin webbplats är det därför viktigt att webbplatsen testas och övervakas noggrant. För att vara säker på att funktionaliteten fungerar behöver man en mängd olika verktyg. I denna artikel kommer jag att prata om ett av verktygen som vi använder för att säkerställa att saker fungerar – loggövervakning.

Vad är loggövervakning?

Loggövervakning så som vi använder det innebär att vi löpande importerar så mycket logghändelser som möjligt från våra kunders servrar kontinuerligt med ett verktyg som heter Splunk. En ren instans av Splunk innehåller endast rådata, men med hjälp av Splunks gränssnitt och scriptspråk kan vi göra sökningar på vissa typer av händelser. Vi kan sedan visualisera dessa händelser på en mängd olika sätt för att skapa oss en skräddarsydd ”Dashboard” som visar relevant information för just våra ändamål.

Att göra en sökning är mycket enkelt och intuitivt, och med ett par peka-klicka manövrar har man konstruerat en liten widget av sin sökning. Man kan sedan dra runt sina widgets i sin dashboard enkelt med simpel drag-och-släpp. Det finns även en förnämlig funktion för att smidigt och med peka-klicka låta mjukvaran ta fram komplexa regular expressions för att ta fram specifik data ur en komplex datamängd.

Vad kan man visa?

Splunk hjälper oss att visa information om varje server – diskstorlek, processorkraft, processer & användare utan att behöva göra några speciella inställningar. Genom att hämta hem loggfiler kan vi även få en mängd relevant information som berättar viktiga saker för oss gällande kvalité på kundens webbplats, såsom allvarliga fel i kod, bruteforce-attacker, felaktiga rättigheter mm. Det går till och med att förutsäga tendenser. Vad Splunk inte gör direkt är att visa WordPress-specifik information som kan vara relevant för oss. Då vi av prestandaskäl gärna inte vill sätta på debug (felsökningsläge) i en produktionsmiljö så finns det ingen loggdata att tillgå. Vi måste därför själva berätta för WordPress att – och vad – den skall logga. Detta gör vi genom att använda diverse tillägg.

Visa inloggningsförsök med WP fail2ban

En första åtgärd som kan vara bra att göra är att använda fail2ban tillsammans med WP fail2ban. Detta innebär att alla inloggningar som görs till WordPress automatiskt loggas i syslog (och därmed i Splunk).

splunk-search-wploginfail

Med hjälp av den data vi får till Splunk av WP fail2ban kan vi nu göra en enkel sökning för att få ut alla misslyckade inloggningsförsök:

Authentication failure for * from *

Detta visar antagligen en lång rad rådata. Detta är lite svårt att få översikt på, eftersom vi har många kunder. Därför vill vi göra detta till en kurva som visar tendens över tid. I denna kurva vill vi helst att varje maskin skall ha sin egen stapel. Genom att göra några tillägg till vår sökning kan vi få Splunk att göra sökningen så den visar förändring över tid.

Authentication failure for * from * | timechart count by host

Denna visualisering, översatt i dashboard widgets, ger oss något sådant här:

ac-inspector-fail2ban

Denna visualisering gjorde att vi enkelt kunde förvandla ”spiken” som man ser i statistiken till ett ärende: Vrid lite på fail2ban inställningarna för att minska antalet bruteforce-försök som inte stoppas av brandväggen till installationen (som då automatiskt appliceras även på WordPress)

Visa potentiella problem med Angry Creative Inspector

Vi har tillverkat ett eget tillägg (som för närvarande är en Alpha / Beta) Angry Creative Inspector, som berättar saker för Splunk som vi av erfarenhet vet kan vara viktiga.

Vi har sorterat in saker i tre sorters kategorier:

  • Notice
  • Warning
  • Error

En Notice är någonting som inte är någon fara – man kan kolla på detta när man hinner. En Warning är någonting som man antagligen vill fixa ganska snart. Ett Error-meddelande är någonting man vill titta på med omedelbar verkan.

För närvarande klarar AC Inspectorn att rapportera följande händelser:

  • Multisite kompatibel
  • Site aktivering / deaktivering (Multisite)
  • Plugin aktivering / deaktivering
  • Filrättigheter (Plugins & Uppladdningar)
  • Kollar om produktionsserver har fel konstanter (tex DISALLOW_FILE_MODS)

Här finns det mycket att göra och vi mottar med glädje hjälp att vidareutveckla pluginet. Några av våra mål är:

  • Tydligt genomgående format på loggar
  • Sanitetskontrollera filträd
  • En administratör ska kunna bestämma loggformat själv
  • En administratör ska kunna skapa en lista över kritiska plugins
  • En administratör ska kunna se i loggarna om sökmotorindexeringen blockeras

Hur gör vi då för att använda Angry Creative Inspector ihop med Splunk? Vi söker helt enkelt i Splunk på dess olika loggnivåer och visualiserar dessa i en dashboard. Detta är så vi har valt att göra det, eftersom ett litet fel kan trigga kanska många Notice/Warning/Error meddelanden. Vår sökning ser då ut ungefär såhär:

"[AC_Inspector]" "NOTICE" | timechart count by host

Lägger vi in den sökningen samt gör lite olika typer av datumbegränsningar för till exempel det senaste dygnet så får vi en dashboard i Splunk där vi mycket snabbt och smidigt kan se vad som händer i vår miljö utan att behöva gräva särskilt djupt i loggarna. Det innebär att vår dashboard i Splunk kanske ser ut ungefär såhär:

Splunk + AC Inspector

Slutsats

Sammanfattningsvis fungerar Splunk som ett utmärkt verktyg för att snabbt kunna felsöka och åtgärda problem som uppstår i våra WordPress installationer. Splunk löser problemet med HUR vi kan genomföra detta på ett bra sätt, och ersätter det med en större utmaning: att veta VAD man skall titta efter och visualisera.

Kulturverkstaden – ett stycke företagshistoria i ny förpackning

Kultur Samhälle Mediegestaltning (KSM) är en tvärvetenskaplig och tvärmedial enhet på Linköpings Universitet som jobbar väldigt mycket med bl.a. film- och ljudproduktion. Som en del av utbildningarna använder man sig av ett projekt- och filhanteringsverktyg som man valt att kalla ”Kulturverkstaden”. Systemet används av studenter så väl som lärare för dokumentation, projekthantering, filarkivering och publicering.

Sedan 2008 har undertecknad varit ansvarig för utveckling och drift av detta system, då genom egen firma som gick under namnet Samworks Development & Consulting. Design och formgivning ingick dock inte i det uppdraget och när universitetet år 2010 beslöt sig för att förnya utseendet på systemet föll lotten på en liten enskild firma som kallade sig Angry Creative. Resten är, som det heter, historia.

Det vi med berättelsen om denna historia försöker säga är att Kulturverkstaden alltid kommer en särskilt betydelse för oss. Vem vet vad det hade blivit av oss idag om det inte vore för detta första gemensamma uppdrag de tu egenföretagarna emellan?

Och det är med denna bakgrund som det känns särskilt bra för oss att idag kunna visa upp ett ännu nyare och modernare webbgränssnitt i Kulturverkstaden. Denna gång var det dock inte bara för att göra systemet mer estetiskt tilltalande, mest för att vi såg ett behov av ett ramverk för utformning och bearbetning av den stora mängden vyer och återkommande grafiska element. Det ramverk vi gillar bäst kallas Bootstrap.

Inte mindre än 53 unika vyer fick helt eller delvis omarbetas. Det var inte så litet jobb men i vår bedömning väl värt det i slutändan. Kolla gärna in vårt lilla filmklipp där vi visar upp delar av resultatet:

Så gjorde vi en sportevenemangs-applikation av WordPress

Svenska Grapplingligan (SGL) är Sveriges största turnering för submission wrestling-utövare i hela landet. Trots att grappling (submission wrestling) som sport inte funnits så många år i Sverige har den redan lockat till sig hundratals klubbar och tusentals utövare. Varje år arrangeras ett antal deltävlingar inom de sex regioner som man delat upp landet i för att slutligen avgöra mästarna för säsongen i en nationell final. Vårt uppdrag var att skapa en smidig webblösning för att registrera tävlingar och hantera anmälningar, matchlistor, matchresultat, ranking, m.m.

Varför WordPress?

Det vi direkt kunde konstatera var att det inte fanns något bra färdigt sportevenemangshanteringssystem(?) att använda sig av. Att skapa vår egen speciallösning såg vi därför som ofrånkomligt. Dock ville vi undvika återuppfinna hjulet för de mest grundläggande byggstenarna som databaslager, mallramverk, m.m. Med ett öppet CMS som WordPress får man dessutom ett väldokumenterat API och tillgången till miljoner färdigskrivna tillägg som ger ett ovärderligt mervärde.

Utmaningarna

  • Att ersätta WordPress vanliga administrationsverktyg (wp-admin) med rollanpassade och ändamålsenliga verktyg för tävlingarnas administratörer och deltagare.
  • Att stöpa om WordPress vanliga sätt att hantera användare för att koppla användare till tävlingar och dela upp dem efter säsong, region, klubb, viktklass, kön och erfarenhetsnivå.
  • Att utifrån sportens regelverk automatisera och förenkla förfarandet för att skapa matchlistor, registrera matchresultat samt beräkna poäng och ranking.

Vad är det för fel på WordPress administrationsverktyg?

Vi såg direkt det orimliga i att släppa in alla användare i WordPress administrationsverktyg med hänsyn till all information vi behövde ha kontroll över i programmeringen och de begränsade möjligheterna att anpassa administrationsverktygets gränssnitt och funktion. Istället bestämde vi oss för att plocka russinen ur kakan och bara tillgängliggöra den funktionalitet som användarna behöver med vårt eget rollanpassade webbgränssnitt.

Varför ändra på hur WordPress hanterar användare?

Att utöka vilka uppgifter som ska lagras om varje användare är en relativt smal sak för en någorlunda erfaren WordPress-utvecklare. Problemet är att vi dessutom ville kunna styra över användarinformationen i programmeringen och koppla den till våra egna informationstyper. Exempelvis att användaren ska vara den som uppger sitt kön och sin vikt i sin användarprofil medan vår programmeringslogik utifrån den informationen sätter korrekt viktklass. Ett annat exempel är att när användaren uppgett vilken klubb denne tillhör så ska systemet läsa ut vilken region användaren tillhör utifrån klubbens regionstillhörighet.

Resultatet

För att visa hur resultatet blev har vi valt att göra fem korta filmklipp; ett som visar hur administratören skapar ett tävlingsevenemang, ett som visar hur man registrerar en ny användare, ett som visar hur användaren anmäler sig till en tävling, ett som visar hur administratören för en tävling skapar matchlistor och till sist ett som visar hur administratören registrerar matchresultat.

Skapa tävling:

Registrera ny användare:

Anmälan till tävling:

Skapa matchlistor:

Registrera matchresultat:

Tekniska lösningarna

OBS! För dig som är lite mer tekniskt intresserad av våra lösningar tänkte jag här berätta lite mer om det, ni andra kan skippa denna bit utan att känna skam. 🙂

Som den erfarne webbutvecklaren kanske redan lagt märke till har vi varit flitiga användare av ramverket Bootstrap. Vidare har vi använt oss av en hel del jQuery och inte bara för visuella effekter. För att minska antalet klick och sidladdningar skapade vi vårt eget API för AJAX-anrop som hanterar att läsa så väl som skriva till databasen.

Vad gäller det som inte är lika synligt har vi en informationsarkitektur som ställer mycket speciella krav på funktionerna för att läsa och skriva till databasen. Till vår hjälp har vi använt oss mycket av ett tillägg som heter Taxonomy Metadata. Med det har vi kunnat utöka informationen kopplad till varje taxonomi och term för att bl.a. skapa relationer mellan informationstyper som annars varit omöjligt eller väldigt svårt.

Med en allt mer komplex informationsarkitektur får man dock vissa problem med WordPress standardfunktion för att iterera genom poster, även känd som ”The Loop”. Kort och gott; alltför många loopar i looparna gör så väl WordPress som utvecklare snurriga. Ett annat problem var WordPress sätt att koppla permalänkar till vilken sidmall som ska visas. Det slutade med att vi utökade WordPress permalänksystem och mallramverk för att helt ta kontrollen över vilka funktioner, variabler och sidmallar som ska laddas för vilken permalänk.

Med lite ”mörk programmerar-magi” fick vi till en funktion som läser en enkelt utformad YAML-fil för att sätta permalänk-regler och en funktion för att haka på sidmallar och funktioner på permalänksreglerna, allt detta innan WordPress uppfattat vilken permalänk som efterfrågas och vilken mall som ska laddas. Lösningen är dock utformad så pass att man fortfarande kan ladda vanliga WordPress-mallar som vanligt lika väl som man kan välja att helt åsidosätta dem. På detta sätt plockar vi verkligen russinen ur kakan vi kallar WordPress.

Sist men inte minst kan det vara värt att nämna att vi använt oss av ett tillägg som heter WordPress Social Login för att låta användare registrera sig och logga in med sitt facebook- eller googlekonto.

Sidan inlägget handlar om hittar du på adressen: http://grapplingligan.se

WordPress how-to: Simple image slider with Simple Fields

There are a numerous WordPress plugins for creating image sliders/galleries out there, but this isn’t yet another how-to for using any of those. Instead, we want to show you the power and versatility of a plugin called Simple Fields.

Imagine that you want to customize the look of one or more pages with an image slider. There are a thousand and one ways of doing this, but let’s narrow it down by saying that the editor wants to be able to create his/her own image slideshows and choose which set of images is to be displayed as a slideshow on which page. That still leaves us with quite a few ways of going about it; like plenty lines of code in your page template and/or the functions.php of your theme, or installing one of all the image slider/gallery plugins on WordPress.org.

Reinventing the wheel is perhaps useful for the beginner who wants to learn the inner workings of WordPress, everyone else usually goes for the first and best plugin that does the trick. However, with experience comes the understanding of avoiding the use of too many plugins. This is why we like Simple Fields. By utilizing the versatility of this plugin, we find ourselves in much less need of plugins for basic tasks like this.

First off, let’s set up a custom post type for our slideshows. Add the following to the functions.php of your theme:


register_post_type('slideshows', array(
    'label' => 'Slideshows',
    'show_ui' => true,
    'supports' => array('title'),
    'labels' => array (
        'name' => 'Slideshows',
        'singular_name' => 'Slideshow',
        'menu_name' => 'Slideshows'
    ),
) );

This creates a very basic custom post type which at this points has no content or attributes to edit besides the title. This because we intend to add and manage the content with our own custom fields instead of the standard content editor in wordpress. Although this can be done using the Simple Fields administration pages as described in the Simple Fields documentation, we’re going to show you how to do this in code.

What we want is a repeatable file upload field attached to our slideshow posts so that we can freely add as many images we like to the slideshow. To do this, we begin with registering a field group like this (still in the functions.php of your theme):


simple_fields_register_field_group('slideshow_images',
	array (
		'name' => 'Slideshow images',
		'description' => 'Add images to your slideshow here',
		'repeatable' => 1,
		'fields' => array(
			array('name' => 'Slideshow image',
				'slug' => 'slideshow_image',
				'description' => 'Select image',
				'type' => 'file'
			)
		)
	)
);

The next step is to connect the field group to our slideshows post type. Again add to the functions.php file of your theme:


simple_fields_register_post_connector('slideshow_images_connector',
	array (
		'name' => "Slideshow images connector",
		'field_groups' => array(
			array('name' => 'Slideshow images',
				'key' => 'slideshow_images',
				'context' => 'normal',
				'priority' => 'high')
		),
		'post_types' => array('slideshows'),
		'hide_editor' => 1
	)
);

The image field group is now associated with our slideshows post type, but there is one more thing we need to do in order to make the fields visible by default:


simple_fields_register_post_type_default('slideshow_images_connector', 'slideshows');

At this point, you should be able to go to your wordpress administrator pages, select edit or add a new slideshow and then see the repeatable file upload field that we just created. It should look something like this:

simple-fields-tutorial-screen-1

As you can see, we have all we need to create and manage slideshows as we see fit. Neat, huh?

However, it’s not time to lean back and enjoy just yet. We also need the ability to select which pages that should display which slideshow and then actually display the slideshows, right? No worries, Simple Fields gives us the tools to ease this part as well. How about adding a simple slideshow selector on the edit page? Start editing your functions.php file again and add the following:


simple_fields_register_field_group('slideshow_page_options',
	array (
		'name' => 'Slideshow options',
		'fields' => array(
			array('name' => 'Slideshow display',
				'slug' => 'slideshow_page_display',
				'description' => 'Choose a slideshow to display on this page',
				'type' => 'post',
				'type_post_options' => array("enabled_post_types" => array("slideshows"))
			)
		)
	)
);

simple_fields_register_post_connector('slideshow_page_connector',
	array (
		'name' => "Slideshow page connector",
		'field_groups' => array(
			array('name' => 'Slideshow options',
				'key' => 'slideshow_page_options',
				'context' => 'normal',
				'priority' => 'high')
		),
		'post_types' => array('page')
	)
);

simple_fields_register_post_type_default('slideshow_page_connector', 'page');

The above adds an extra field on your standard page editor pages where you can select a slideshow to associate with the page. Like this:

simple-fields-tutorial-screen-2

Now all that remains is retrieving the slideshow images in your page template and display them. You can of course use whatever markup you like to suit whichever way you want your images to display, but let me give you an example of code for your page template using the Flexslider jQuery plugin. For template tidiness, start with adding this to your functions.php:


function page_has_slider($theID) {
	$slider_id = simple_fields_get_post_value($theID, "Slideshow display", true);
	return ($slider_id) ? $slider_id : false;
}

function get_slider_images($slider) {
	if (empty($slider)) {
		return false;
	} else {
		if (is_numeric($slider)) {
			$post_key = "p";
		} else {
			$post_key = "post_name";
		}
		$slides = array();
		$slide_query = new WP_Query(array( "post_type" => "slideshows", $post_key => $slider));
		if ($slide_query->have_posts()) : while ( $slide_query->have_posts() ) : $slide_query->the_post();
			$img_attachments = simple_fields_get_post_group_values(get_the_ID(), "Slideshow images", true, 2);
			foreach($img_attachments as $image) {
				$slides[] = wp_get_attachment_image( $image["Slideshow image"], "slider-image");
			}
		endwhile; endif; wp_reset_query();
		return (!empty($slides)) ? $slides : false;
	}
}

One function to check if the page has a slideshow associated with it, another to retrieve the images of the slideshow. That’s all we need. Now take a look at how little code we need in the page template to display the images of the slideshow. Just put the following inside ”The Loop”:


<?php if ($slider = page_has_slider(get_the_ID())) { ?>
	<div class="flexslider">
		<ul class="slides">
		<?php
			$slides = get_slider_images($slider);
			foreach ($slides as $slide) {
				echo "<li>" . $slide . "</li>";
			} ?>
		</ul>
	</div>
<?php } ?>

Now is the time to lean back and enjoy! 🙂

For those who endured this far, we thank you for your time and hope you liked this little tutorial. We aim to write more so don’t forget to check us out once in a while. And as always, feedback is really appreciated so don’t hesitate to let us know what you think in the comments section below. Happy coding!