Vad är en patch? Steg för steg guide hur du själv gör en till Drupal

En patch kan jämföras med ett plåster med en unik passform för ett unikt skrubbsår. Patchen bygger man för att fixa något som man tycker är fel i en modul (core eller contrib) som man använder. Då man listat ut hur man kan fixa den kan man först applicera den på sin egen sajt, och sedan dela den med communityn så att alla kan få nytta av den. Passar väl rätt bra ihop med public service eller hur?

Min första patch skapade jag förra veckan. Vi använder Redirect modulen för att hantera namnbyten på artiklar. Om en artikel byter namn på vår sajt ändras nämligen också adressen till artikeln, och om artikeln då redan hunnit delas i social medier så skulle besökare den vägen inte hitta artikeln utan redirect modulen.

Problemet uppstår ifall artikeln först döps till ”Kalle Anka är bäst!”, sedan döps om till ”Kalle Anka bäst!”. Då skapas en hänvisning från ”Kalle Anka är bäst!” till ”Kalle Anka bäst!”. Om man sedan döper om artikeln till ”Kalle Anka är bäst!” döps artikeln om, och det finns redan en hänvisning som pekar på ”Kalle Anka är bäst!”. En infinite loop har skapats, då besökaren skickas runt i en cirkel utan att någonsin kunna stanna (Sajten märker dock av felet och bryter loopen, men besökaren kan inte läsa artikeln).

Det felmeddelande som visades var inte särskilt tydligt för en icke tekniskt kunnig. Där stod ”Oops, looks like this request tried to create an infinite loop. We do not allow such things here. We are a professional website!”.

Jag tänkte jag skulle översätta det till något tydligare, samt inkludera ett lösningsförslag åt den som skapade felet. Jag kunde dock inte göra det, för översättningsfunktionen kunde inte hitta meningen i fråga. Jag bestämde mig för att kolla på modulens kod, och kunde där konstatera att t() översättningsfunktionen saknades. Dessutom visades felet som ett grönt statusmeddelande. Jag ville ändra det till ett gult eller rött varningsmeddelande.

Genom en sökning på ”create Drupal patch” hittade jag en manual för att skapa en patch (Quick and simple patch). Man klarar sig med det som står på modulens ”versioner” sida, gör en patch för redirect. Följande Youtube video guidar dig genom git och drupal.org issue skapandet.

I korthet gjorde jag följande:

  1. Ändrade på min local dev version av redirect modulen för att kolla om jag överhuvudtaget kunde fixa problemet
  2. Installerade en ren version av Drupal 7.x (min local dev är så modifierad att det är bäst att testa och skapa patchen från en så ren install som möjligt
  3. Installerade git_deploy som behövs för att generera all info som behövs till patchen
  4. Installerade dev versionen av redirect (git clone av dev branch) och pathauto som behövdes för att testa den ändrade koden
  5. Gjorde ändringarna i filen
  6. Gå till modulens mapp med CMD, kör git status. Du ser då ett meddelande om att filen du ändrat har ändrats.
  7. Kör git diff > [description]-[issue-number]-[comment-number].patch (du kan testa att döpa den till vad som helst, för att se att det fungerar. Filen finns sedan i modulens mapp) Fortsätt sedan med följande steg och döp sedan om testfilen du skapade eller kör kommandot en gång till.
  8. Gick till drupal.org och redirect modulen och skapade en ny issue. Där beskrev jag problemet och hur jag tänkt lösa det. Ta issue nummern från url:en efter att du sparat din issue, och döp patchen enligt namngivningskonventionen. I mitt fall blev det missing_t_function-1903228-1.patch
  9. Skriv en kommentar och bifoga patchen, ändra status till needs review
  10. Vänta på att någon av upprätthållarna kollar på din patch och bifogar den först till dev branchen och sedan till den stabila versionen
  11. Om du inte kan vänta kan du också ta patchen i bruk bara på din egen sajt i väntan på att den blir tillgänglig via modulen
  12. Patchen denna bloggpost handlar om blev infogad i dev branchen efter en vecka

Här kan du läsa issuen jag skapade för patchen:
#1903228 – Missing t() function in drupal_set_message

Morr, den lever!

I skrivande stund närmar vi oss situationen då Buu-klubbens julkalender börjar vara packad och klar för 2012 (jo, jobbet fortsätter även om kalendern är publicerad). Kalendern på webben utsätts för höga förväntningar varje år även om resurseringen kan variera. Det handlar ju trots allt om en av de mest populära tjänsterna hos svenska.yle.fi.

Projektet i sin helhet består av otaliga delar, och man kunde säket skriva tiotals blogginlägg (eller noveller) ur alla möjliga synvinklar. Jag tänkte dock i korthet presentera den arbetsprocess som ligger bakom de animationer och grafik som utgör webbkalendern med några enkla exempel.

Kalendern är, liksom Buu-sajten överlag väldigt starkt präglad av en viss grafisk stil. Den grafiska stilen i sin tur är en kombination av “buu-världen” och det man ser i papperskalendern.

Papperskalendern beställer vi (förutom konceptplaneringen som sköts av oss) av underleverantörer och den är ett stort projekt för sig, men också en väldigt viktig del av det som är kalendern på webben. Den lägger definitivt en av grunstenarna för webbkalenderns utseende gällande såväl figurer som omgivning.

Vi har även i år samarbetat med Johanna Sjöström som är den duktiga grafikern bakom en stor del av grafiken på buu.yle.fi.

Vektorgrafik

Eftersom webbkalendern är byggd i Flash är vektorgrafik ett måste. Då papperskalendern illustreras fullständigt som vektor ger detta oss många möjligheter att utnyttja den månsidigt också på webben, och eliminera massor av onödigt arbete.

Symbiosen mellan Adobe Illustrator och Flash är oslagbar i denna process. I all sin enkelhet kan det handla om snabba och smidiga överföringar av objekt från det ena programmet till det andra. Editerings- och exporteringsmöjligheterna i vardera program ger oss alla tänkbara verktyg att jobba med. Figurer, omgivning och element av alla tänkbara slag kan flyttas, editeras, modifieras och framför allt överföras till Flash för att animeras precis så som vi vill, och känslan av att det handlar om en och samma helhet kvarstår.

Som exempel kan vi nämna spefiguren Morr. Morr, som är en av huvudfilurerna i julkalendern 2012, ritas i Adobe Illustrator av grafikern utgående från samma figur i TV-produktionen. AI-filen godkänns och skickas sedan till oss. Det är därefter hur enkelt som helst för mig att plocka spelfiguren in i Flash och väcka den till liv.

Spelfigurer i Adobe Illustrator.
Spelfigurerna i Adobe Illustrator.

Flash

Buu-klubbens webbsida är byggd helt och hållet i Flash. Vad betyder det då? Det betyder vektorgrafik, ActionScript, timeline-animationer, tweens och hela faderullan. Ja, egentligen är Adobe Flash en produkt som man kan producera lite vad som helst med, vad gäller grafik och animering.

Flash ger i animeringsväg 2 möjligheter, som absolut inte utesluter varann. Man kan animera med hjälp av ActionScript, eller använda sig av timeline-animering. Julkalendern utnyttjar båda. Med ActionScript byggs också de egentliga spelmotorerna som ligger bakom allting. Personligen fattar jag inte ett dyft av kod, så det är timeline hela vägen för mig.

För att fortsätta med exemplet Morr, utnyttjar jag bland annat olika tweens och bone-tool för att rätt snabbt och enkelt åstadkomma en figur som springer, hoppar, blinkar med ögonen, vickar på tårna, viftar med handen och med svansen. Allt detta utan att behöva göra några märkbara ingrepp på den grafik som Johanna försett oss med.

Hoppande Morr animeras i Adobe Flash.
Morr animeras i Adobe Flash.

ActionScript sköter som sagt också en stor del av animationerna. Som exempel kan nämnas hinderbanorna i årets kalender. De byggdes så att jag ritade alla grafiska element som behövs i Flash, delade upp dem i olika scener och skickade sedan iväg .fla-filen till vår kodare som kodade ihop allting till fungerande spel. Med ActionScript definieras de olika grafiska elementens beteenden.

Från skiss till färdig hinderbana.
Från skiss till färdig hinderbana.

Detta var alltså ett ganska kort och koncist exempel på hur vi jobbar när vi skapar delar av Buu-klubbens julkalender. Hoppas ni gillar kalendern både i pappers- och webbformat!

Funderingar kring framtiden med eller utan Flash i ett senare inlägg.
God Jul!

///Johan, grafiker på svenska.yle.fi

Prestanda downtime och cache servers

Såhär med facit på handen och en vecka efter lanseringen av den nya http://svenska.yle.fi sajten är vi en hel del erfarenheter rikare vad gäller infrastruktur och server hantering som görs i samarbete med en extern partner.

Vår Drupal delar servers och databasservers med andra på Yle vilket har både positiva och negativa följder. En av de positiva sakerna är definitivt att vi har ett bättre avtal gällande support och till det negativa hör att vi delar server resurser med andra. Delar man på resurserna så är det klart att en publikation som kräver mycket resurser av infran påverkar alla andra och det är en grej som även vår Drupal lidit av under den här veckan. Då det blir som värst så är det svårt att uppdatera sidan men trots det har vi på grund av vår cache server Varnish kunnat serva användarna så gott som utan avbrott men med långa laddningstider.

Varnish är en underbar serversofta som gör allt så mycket bättre och den skulle vara helt lysande om det inte skulle vara för en fatal bugg. Den bugg som helt klart finns i Varnish v2.x och v3 och som flera specialister kollat på är att den helt enkelt inte klarar av att fungera rätt med Round Robbin regler för belastningshantering utan i praktiken styr all trafik till en server trots att man har flera konfigurerade. Det innebär att man ex bara har 50% av den server effekt man borde ha och då stöter man snabbt på problem som påverkar alla de som servas av den helheten. Även vår nya Drupal blev offer för det  på fredagen 27.4. Det varade tills vår samarbetspartner hittade ett sätt att implementera en extra belastningshanterare mellan Varnish och Apache servrarna.

En till sak man kan konstatera nu när Varnish även servar alla våra gamla sajter förutom Buu, X3M, Vetamix är att laddningstiderna på de gamla sidorna förkortats avsevärt med upp till 50% i bästa fall och med 10% i genomsnitt.

Länge leve Varnish!

I väntan på att få flytta till nya servrar så fortsätter vi optimera.

/KS

Versionshantering till nytta och nöje

Inget utvecklingsprojekt borde vara utan ett system för versionskontroll, inte ens om man är den enda som jobbar på sitt projekt. Och när man är många som jobbar med samma projekt så är det idag nästan omöjligt att göra det på ett vettigt sätt utan att stöda sig på någon form versionering.

Vad får man då för besväret av att vara tvungen att börja bokföra vad och hur man lägger in kod i sitt projekt? Jo, inte minst en möjlighet till att gå tillbaka och ångra saker som gått sönder eller som någon av misstag skrivit över. Eftersom varje ändring i varje fil sparas så kan man enkelt gå tillbaka i filens historia och kolla vad som ändrat, när något ändrat och vem som gått och ändrat. Och när det uppenbarar sig nya och oväntade buggar i sajten så är det en lättare att felsöka den genom att kolla upp vilka ändringar som gjorts i historiken.

När vi började med projektet i oktober så stod valet mellan Subversion, som vi alla kände från förr och det nyare och modernare Git som för de flesta av oss var ett system vi kände till, men som knappt någon av oss hade använt från tidigare. Git har ändå så pass många fördelar framom Subversion att vi valde att använda det. Den främsta fördelen som Git har är att det är ett decentraliserat system, dvs att man inte är lika beroende av en central server för alla versionerna, utan hela projektets alla filers alla versioner finns hela tiden tillgängligt också på din egna hårddisk, och på en centralt ställe som alla i teamet har tillgång till, det som i git kallas origin-repositoriet. Den andra stora fördelen med Git är att det är enklare att jobba på flera utvecklingsspår (såkallade branches) samtidigt.

En liten del av projektets git-logg.

Fram tills vi publicerade den slutna betan så klarade vi oss ändå bra med en huvudsaklig master-branch som vi alla sparade våra ändringar till. Nu, i och med att vi har en sajt som i det närmaste kan räknas att vara i produktion så behöver ändå lite mer kontroll över vad som läggs ut på produktionsservern. För att göra det lättare att ha koll på just det så använder vi nu två huvudsakliga branchar; master-branchen och dev-branchen. Nu sker alltså det huvusakliga utvecklingsarbetet i dev-branchen och endast färdiga och testade helheter ska sparas in i master-branchen. På det sättet så försöker vi minimera att det smyger in fel som kan ta ner sajten eller orsakar annan otrivsel för redaktörer och besökare.

Det är ändå inte helt problemfritt att jobba med många branches, framförallt blir det väldigt viktigt att se till att man är i den rätta branchen då man hämtar in och sparar ny kod, de första dagarna med flera branches gick åt att lära sig att hålla reda på var man var, och vart man höll på att spara sitt material, men redan nu känns det naturligt och enkelt att jobba med flera utvecklingsspår.

En historik som sträcker sig tillbaka till projektets början ger också fina möjligheter att visualisera hur projektet vuxit sig fram från starten i oktober fram tills idag: