Archive for the ‘Software’ Category

Der er i øjeblikket mange der taler om et botnet der på nuværende tidspunkt skulle være i gang med at brute force sig adgang til WordPress sites overalt. Der skulle efter sigende være tale om et angreb fra op til 90.000 forskellige kilder.

Om et sådan angreb er i gang eller ej skal jeg ikke kunne sige, men det har tilsyneladende fået rigtig mange WordPressbrugere til at genoverveje deres nuværende sikkerhedsniveau, så noget positivt er der da kommet ud af det lige meget hvad.

Jeg ser mange der diskuterer problemet og mulige løsninger, hvilket igen er positivt, men der er mange der ikke har helt styr på hvad der er godt og skidt, og evt. hvorfor, så jeg vil her prøve at give mit bud på nogle overvejelser man bør gøre sig inden man hovedløst kaster sig ud i installation af tilfældige sikkerhedsplugins.

En række supportere på det officielle WordPress support forum har sammen lavet en side på WordPress codex med tips og tricks til at sikre sig mod angrebet, så hvis du vil have den korte version på engelsk kan den findes her. Jeg vil gå lidt mere i dybden og forsøge at forklare det hele på dansk.

Hvad sker der egentlig?

For god ordens skyld vil jeg lige starte med at forklare det egentlige problem, så vi allesammen snakker om de samme ting, og for at give en idé om de overvejelser man bør gøre sig.

Botnets? What?

Det omtalte angreb stammer fra et stort botnet. Et botnet er et antal computere der, for det meste uden at ejeren ved det, bliver brugt af tredjepart til andre formål end hvad ejeren af computeren havde til hensigt.

I dette tilfælde handler det efter sigende om at bagmændende bag botnettet prøver at tiltvinge sig kontrol over flere computere, for på den måde at udvide deres botnet. De gør det ved at “brute force” sig administratoradgang til maskiner der kører websites bygget på WordPressplatformen. Hvis det lykkedes dem at få adgang til et WordPress-site gør de så dette site til en del af deres botnet, og på den måde vil angrebet vokse hver gang det lykkedes dem at overtage et WordPress-site.

Hvad så med det “brute forcing”?

Brute forcing handler om at tiltvinge sig adgang ved “brute force”, altså rå magt. Det foregår ved de simpelthen prøver at logge ind som adminbrugeren, ved at prøve mere eller mere tilfældige passwords, i teorien kan man jo gætte alle passwords hvis man har uendelige forsøg og god tålmodighed. Da der er tale om et automatisk angreb er det ikke noget der koster bagmændende noget tid, og de har derfor rigeligt med tålmodighed.

Men hvad kan jeg gøre ved det?

For det første skal du tage dine normale forholdsregler. Sørg ALTID for at holde WordPress fuldt opdateret. Det samme gælder alle installerede plugins og temaer. Dette er ikke specielt for det nuværende angreb, men alt software er usikkert på den ene eller anden måde. Folkene bag WordPress arbejder hårdt for at lukke alle sikkerhedshuller der bliver fundet så hurtigt så muligt, så sørg for altid at være opdateret. Sørg desuden for at slå alle plugins fra du ikke bruger. Som nævnt er intet software 100% sikkert, så en tommelfingerregel er at jo mindre software du har jo bedre.

Mht. det nuværende angreb er der selvfølgelig nogle ekstra ting du kan gøre.

Tag backup af alt!

En backup sikrer dig selvfølgelig ikke imod angreb udefra. Men hvis du skulle være uheldig enten at blive offer for angrebet, eller at få ødelagt dit site i et forsøg på at sikre det er det altså noget rarere at have end up-to-date backup, end at skulle starte helt forfra. Sørg altså for at tage backup af både selvesitet (via. FTP) og databasen (f.eks. via phpmyadmin), gerne lige nu, inden du forsøger at øge din sikkerhed.

Selve backupprocessen er afhængig af hvor du har dit website liggende, så der kan jeg ikke være så behjælpelig, men der findes som sædvanlig en række forslag på WordPress Codex.

Skift navnet på din adminbruger

Det igangværende angreb udnytter tilsyneladende at WordPress i gamle dage automatisk oprettede en administratorbruger med brugernavnet. Fra version 3.0 og frem har det været muligt selv at bestemme dette brugernavn, men det er ikke alle der har ændret det. En ændring af dette brugernavn vil gøre det sværere at brute force sig adgang til dit site, da angriberne så både skal finde brugernavn og password, i stedet for kun password.

Hvis du har en administratorbruger med brugernavnet admin kan det ændres forholdsvist enkelt med et plugin, eller ved et par manuelle skridt:

  1. Login som din administratorbruger
  2. I adminpanelet gå til “Brugere” -> “Tilføj ny”
  3. Opret en ny bruger, sæt brugerens rolle til administrator (med et ordentlig password!)
  4. Log ud.
  5. Log ind med din nyoprettede administratorbruger.
  6. I adminpanelet gå til “Brugere” -> “Alle brugere”.
  7. Hold musen hen over admin-brugeren, og tryk på det “slet”-link der kommer frem.

Hvis du oplever at du ikke kan slette admin-brugeren så dobbeltcheck lige at du har logget ind med din nyoprettede bruger, og ikke stadig er logget ind som adminbrugere (ja, vi kan alle lave trykfejl :-)).

Brug ordentlige passwords

Dette er vel nok det vigtigste punkt på listen, og desværre nok også det mest besværlige at gøre ordentligt. Sørg altid for at bruge ordentlige passwords der ikke er lige til at gætte. Som sagt foregår det nuværende angreb som et brute force angreb, hvor de prøver sig at gætte sig til dit password, dette vil normalt foregå på en af to måder.

Enten kan man prøve fra en ende af, med “a” som password, derefter “b”, når alle muligheder er opbrugt prøver man så med to bogstaver, “aa”. Dette kan selvsagt tage lang tid, men hvis dit password f.eks. er “asdf” tager det altså ikke lang tid.

En anden metode er at tage udgangspunkt i en ordbog. I stedet for at prøve alle kombinationer af tal og bogstaver nøjes man med ord fra en prædefineret liste af ord. Disse liste vil ofte også indeholde ofte brugte afarter af ord, hvor f.eks bogstaver er udskiftet med tal. Dette betyder at hverken “password” eller “p4ssw0rd” er særlig gode passwords.

Der er skrevet rigtig, rigtig, rigtig, meget om hvordan man gør sine passwords sikre. WordPress Codex nævner også nogle gode forholdsregler man kan forholde sig til. Der henvises desuden til nogle services der kan hjælpe med at generere og huske gode passwords. De væsentligste ting må være:

  • Lad være med at bruge personlige oplysninger, såsom dit navn, din fødselsdag eller lignende offentlige oplysninger.
  • Lad være med at bruge ord fra ordbogen.
  • Længere passwords er generelt bedre passwords.
  • Brug en blanding af store og små bogstaver, tal og tegn

Men husk altid på de ovenstående metoder der bruges til at gætte passwords. 5up3rM4nRul3z43v3r (superman rules forever) er altså ikke nødvendigvis et godt password, da det stadig er en sammensætning af ord der garanteret vil stå i enhver password breaking ordbog.
Gode passwords vil oftest (altid?) være svære at huske. En metode til at gøre det lettere er at bruge en passwordmanager, et program eller en service til at huske dine passwords for dig. Jeg bruger selv LastPass som gør at jeg har et meget stærkt password som jeg skal huske. Dette masterpassword giver så adgang til alle mine passwords til diverse websites. Det betyder at jeg kan bruge services til at generere tilfældige passwords (eller, ihvertfald tilfældige nok), uden selv at skulle huske alle disse passwords, eller nedskrive dem på papirer som jeg kan smide væk.

Bloker adgang til din loginside

Da det igangværende angreb forsøger at få adgang administratorinterfacet på WordPress sites via den normale loginmetode, er en mulighed for øget beskyttelse at begrænse adgangen til adminpanelet. De to mest brugte metoder til dette er:

  • Password-beskyt adminpanelet
  • Bloker adgang til filen på IP-niveau

Fælles for de to metoder er at de kan fungere på et af to niveauer. Det kan enten gøres via. WordPress selv, eller det kan gøres direkte på serverniveau. Om man bruger den ene eller anden metode kan umiddelbart virke ligegyldigt, men jeg vil gerne lige understrege hvorfor det gør en forskel.

WordPress er skrevet i PHP, som bl.a. bruges til at skabe dynamiske hjemmesider. Jeg har andetsteds skrevet lidt om forskellen på statiske og dynamiske hjemmsider (læs afsnittene om statiske og dynamiske hjemmesider, resten af artiklen er ikke relevant for dette emne). Men det betyder at hver gang sikkerheden bliver håndteret i WordPress skal serveren have hele WordPress i gang med at arbejde for først at finde ud af om en bruger skal have adgang til en ressource. Samme sikkerhed kan ofte klares på serverniveau, hvilket betyder meget mindre arbejde for serveren, da en evt. angriber vil blive forment adgang allerede inden WordPress bliver sat i gang.

Password-beskyt adminpanelet

Passwordbeskyttelse kan som nævnt foregå både på server- og på WordPressniveau. Passwordbeskyttelse på WordPressniveau foregår via. WordPress eget loginsystem, det er en beskyttelse vi snakkede om tidligere med ændring af adminbrugernavn, og brug af gode passwords.

Passwordbeskyttelsen kan dog også flyttes ned på serverniveau med HTTP authentication. Dette vil resultere i at når du tilgår din WordPress loginside vil du først møde en popup hvor du skal skrive brugernavn og password, og derefter vil du møde den normale WordPress loginside. Dette er selvfølgelig en afvejning af sikkerhed vs. convenience da det kan virke lidt irriterende at skulle logge ind to gange. Hvis du vælger denne metode skal du selvfølgelig huske ikke at bruge samme brugernavn/passwordkombination til begge lag af beskyttelse. WordPress Codex har selvfølgelig også instruktioner til hvordan du opsætter HTTP authentication, både på Apache og Nginx servere.

Bloker adgangen på IP-niveau

En anden metode er at blokere adgangen til WordPress-loginformen ud fra forespørgerens IP-adresse. Hvis du ved at du har en fast IP-adresse og at du vil have den samme adresse lige så længe som du har din WordPressside kan du selvfølgelig lave en opsætning der kun giver den ene IP-adresse adgang til din loginside, men det er de færreste forundt (og nu er ikke tidspunktet til en IPv6-diskussion).

Et alternativ, som vil være mere relevant for de fleste, er kun at tillade en IP-adresse X antal loginforsøg, før denne blokeres. Dette kan gøres på WordPressniveau vha. et plugin som WordFence (tak til Kasper Bergholt for anbefaling af pluginet, der tilsyneladende også kan mange andre lækre ting), men igen har vi problemet med at hele WordPresspakken skal startes op, før der kan tages stilling til om en bruger skal have adgang eller ej. Dette er dog noget mere besværligt, og nok ikke noget alle og enhver bare bør kaste sig ud i, men en guide til opsætning af af rate-limiting på Apache kan findes her. Hvis man vil opsætte rate limiting i .htaccess, kræver det dog at man kører Apache med mod_security 2.7.3 eller senere.

Et problem med denne tilgang til det igangværende angreb er at angrebet som forklaret udføres af et botnet der arbejder fra mere end 90.000 forskellige IP-adresser (med mulighed for udvidelse, hvis de får succes). Det betyder at de potentielt kan fortsætte angrebet fra en ny IP, hvis en af adresserne bliver spærret. Dog må der altid være en form for ressource cost tilknyttet hvis angrebet skal flyttes til en ny afsender, da der skal holdes styr på hvor langt hver angriber er nået i ordbogen. Så jo flere lag af sikkerhed du kan opsætte, jo sværere bliver det for angriberen.

Opsummering

Så for at opsummere hvad jeg mener du bør gøre for at højne din WordPress-sikkerhed generelt, og imod det måske igangværende angreb er:

  1. Hold WordPress opdateret, inkl.
    • WordPress core
    • Alle installerede plugins
    • Alle installerede temaer
  2. Tag backup. Om ikke andet for at gøre det lettere at komme tilbage på benene hvis uheldet skulle være ude.
  3. Lad være med at have en adminbruger med navnet admin.
  4. Brug ordentlige passwords. Brug evt. en passwordmanager.
  5. Passwordbeskyt din loginside.
  6. Bloker adgangen for IP-adresser der prøver at gætte dit password.

Hvis i har andre gode råd til beskyttelse af WordPress hører jeg selvfølgelig også gerne om det i kommentarfeltet nedenfor, så vi kan få spredt ordet om ordentlig sikkerhed (At lade være med at bruge WordPress godtages ikke som et godt råd, så hvis det er din mission, så spar dig selv besværet og lad være med at skrive det her).

Drupal er et stort og komplekst system. Der er mange ting man skal sætte sig ind i for at forstå, og kunne arbejde med det. Dette indlæg vil være en oversigt over en del af Drupals terminologi, og en række vigtige koncepter vil blive opsummeret. Dette er mere en huskeliste, end en introduktion, så forvent ikke at det lærer dig alt om Drupal, men hvis du er i gang med at lære Drupal kan det forhåbentlig hjælpe til at forstå nogle af koncepterne bedre.

For at gøre det hele lidt sjovere har nogle af termerne flere forskellige betydninger i Drupal, så det gælder om at holde tunge lige i munden.

Entity
  • Drupals fundamentale klasse til indholdstyper.
Node
  • Basistypen for det meste indhold i Drupal.
  • Et indholdselement, f.eks. et blogindlæg.
Content type
  • En definition af en type indhold, f.eks. billede, eller blogindlæg. Nedarver fra Node.
Page
  • En content type til statisk indhold
  • En display type. En page kan definere hvordan indholdet på en side skal struktureres.
Block
  • Et mindre, selvstændigt element på en page. En block kan f.eks indeholde en statisk tekst såsom en copyright disclaimer, eller funktionalitet i form at et søgefelt eller en loginformular.
View
  • Et view definerer et dataudtræk fra en database. Views kan inkluderes på andre sider og f.eks vise nyeste indlæg eller lignende.
Field
  • Et field er et datafelt tilknyttet en contenttype. Det kan f.eks. være et tekst-felt til nodens brødtekst, eller et datofelt der fortæller hvornår en node er offentliggjort.
Template
  • En template er en skabelonsfil. Det er en PHP-fil der beskriver hvordan sider skal opbygges. Templates kan både være meget generelle, såsom node.tpl.php, men kan overskrives af mere specifikke templates, såsom node-type.tpl.php.
    Region
    • En region er en underdel af en template.
    Theme
    • Et theme beskriver et websites udseende. Det består af en række templatefiler, css-filer og PHP-filer hvor Drupals theme_ funktioner overskrives.
    Taxonomy
    • Taxonomies bruger til at styre kategoriseringen af indhold på et website
    Vocabulary
    • Et vocabulary, eller et ordforråd, er en kategori af de tags der bruges til at kategorisere indhold på et website.
    Term
    • En term er selve det tag der bruges til at kategorisere indhold på et website. Tags er hierarkiske, dvs. de kan have andre termer som parents og childrens.

    Forskellige content typer kan få tildelt ordforråd. Hvis du f.eks. driver en webshop der sælger tøj, kan man lave et ordforråd der hedder farver. Der kan så laves en content type der hedder “trøjer”, der linkes til ordforrådet “farver”. En trøje node, vil så kunne tagges med farver fra ordforrådet, alt efter hvilke farve trøjen findes i. Hvis trøjer også er linket til et ordforråd kalder “størrelser” vil man f.eks. hurtigt og enkelt kunne søge efter ting som “røde trøjer i størrelse XL”.

    Jeg er stadig ny til Drupal, så dette er de beskrivelser jeg er kommet frem til indtil videre. De fleste burde være nogenlunde på rette spor, men jeg kan ikke garantere validiteten af alle ovenstående beskrivelser. Hvis du har indspark eller rettelser hører jeg meget gerne om det, så jeg, og andre der evt. læser med, kan blive lidt klogere.

    Den foregående weekend valgte jeg at bruge alt min tid sammen med 470 andre spilinteresserede mennesker på Aalborg Universitet i København. Dette foregik i regi af dette års Nordic Game Jam, et weekendprojekt hvor en masse spilinteresserede mødes, og bruger en weekend på at lave et spil. Normalt er der fokus på computerspil, men i år var konceptet udvidet til også at indeholde en analogt spor.

    Årets tema var grotesk. Det var et ret spændende tema, da det er et koncept de fleste har en klar forestilling om hvad betyder, men når man begynder at dykke lidt ned i ordets definition og oprindelse viser det sig at være et noget bredere koncept end hvad man tænker over til daglig. Det dannede grundlag for nogle spændende diskussioner om hvordan konceptet skulle forstås, og hvordan denne forståelse kunne udtrykkes i spil.

    Jeg var selv på det digitale spor, hvor jeg i en gruppe bestående af 6 (plus 1/3 lydmand), hvor vi til sammen lavede spillet MonsterMash.

    Det var sjovt at prøve at deltage i et arrangement med så mange mennesker med en fælles interesse. Der var mange sjove folk imellem, og man endte hurtigt i nogle sjove og interessante diskussioner når man faldt i snak med mere eller mindre tilfældige mennesker man mødte i elevatoren, i køen til maden, eller i rygerområdet.

    Udover en sjov weekend betyder jammets afslutning også at jeg kan krydse første element af på min liste af mål for 2013.

    Deltage i enten en (gerne flere) hacker eller startup weekend, f.eks. Startup Weekend eller Hack4DK hvis der bliver holdt et lignende arrangement i år.

    Jeg synes dog stadig godt om jam-konceptet, så jeg håber stadig på at nå med til noget som Startup Weekend.

    Til sidst vil jeg gerne anbefale Nordic Game Jam til alle med interesse for udvikling af computerspil, også selvom det bare er noget du synes lyder sjovt. Jeg mødte selv op uden nogensinde at have arbejdet på computerspil før, så man behøver ikke at vide alting på forhånd, man bliver overrasket over hvor mange forskellige skills der kan bruges på sådan et udviklingshold:

    • Projektledelse
    • Ide generering / brainstorming (hvilket mest bare kræver en smule fantasi, og evnen til at sætte to idéer sammen til en ny idé)
    • Tegner/grafiker
    • Programmør
    • Historiefortæller/tekstskriver
    • Ukulelespiller (men venligst lad være med at gøre det i fælleslokalerne hvor du generer 30 andre der prøver at koncentrere sig!)
    • Ølkøber og kaffehenter (nogen skal jo sørge for at holdet holder sammen)

    Så der er plads til alle, og det er bare et spørgsmål om at tage afsted og deltage.

    Arrangørerne har desuden samlet en oversigt over alle tilmeldte spil, de fleste af spillene har vist mulighed for at man kan downloade dem eller spille dem online. Find alle spillene her.

    Update: Vi har tilsyneladende også fået en smule presseomtale for vores spil, MonsterMash fra indie game sitet Indie Statik. Sejt!

    Den 31. Oktober 2006 kl 21:06 blev det første indlæg posted på det danske Ubuntu supportforum. Det var den spæde start på et forum der siden har udviklet sig meget.

    Forummet har pt. over 5000 brugere, og i dag nåede de endnu en milepæl. Der er dags dato blevet skrevet ikke mindre end 100.000 indlæg! Det må jo betyde at de har gjort et eller andet rigtigt.

    Tillykke til de mange aktive brugere, og ikke mindst de dygtige supportere! Godt gået, og held og lykke med de næste 100.000! :-)

    I sidste uge lancere min arbejdsplads en konkurrence hvor man kan vinde en skiferie. For at sprede ordet valgte vi bl.a. at dele konkurrencen på Facebook. I forbindelse med Facebookdelen rendte jeg ind i et par problemer som jeg havde svært ved at finde dokumenteret online. Konkurrencen blev oprettet som en facebook page app, som den ses her.

    Facebooksiden

    Facebooksiden i sig selv var ikke et stort problem. Jeg lavede en app på Facebook Developers siden. Dette giver en række muligheder, bl.a. muligheden for at vælge hvordan din app skal integreres med Facebook.

    For at kunne bruge applikationen som et element på en Facebook page, vælges “page tab”. Teknisk fungerer det ved at du selv hoster din app, som en almindelig html side, der så indlejres på din Facebook Page, i en iframe. En page tab har 4 indstillinger:

    • Page Tab Name – Den navn din app skal have i page menuen
    • Page Tab URL – Den side Facebook skal integrere i sin iframe
    • Secure Page Tab URL – En HTTPS-version af den side der skal vises på Facebook
    • Page Tab Edit URL – Link til din app’s admin modul. Jeg skippede dette, da mit projekt ikke havde behov for customization

    I følge Facebook selv har mere end 9.6mio brugere valgt kun at kunne tilgå Facebook via https. Hvis du ikke har tilføjet en HTTPS-version af din app vil alle de mennesker hverken kunne se eller bruge din app.

    Et af de problemer jeg kæmpede mest med, var at gøre det muligt for folk at dele appen med deres venner. Ikke fordi det var svært rent kodemæssigt, men jeg fandt ud af at det kræver at appen udover at være oprettet som ‘page tab’ som forklaret ovenfor, også kræver at den er lavet som en normal ‘app on facebook’ (se billede ovenfor). Når du vælger ‘app on facebook’ får du 2 indstillingsmuligheder. Canvas URL, og Secure Canvas URL. Et Facebook app canvas fungerer på samme måde som en Facebook page tab, bortset fra at det er en selvstændig app, og ikke tilknyttet en page. Da jeg ikke havde brug for en selvstændig app valgte jeg at lave mine canvas URLs pege på en tom side, der kun bestod af et JavaScript redirect, til min page tab.

    Selve appen

    Da opsætningen var på plads var der bare tilbage at lave selve appen. Det sker som nævnt tidligere vha. html, css og javascript, og der er altså ikke meget magi her. For at få adgang til Facebooks funktionalitet, skal Facebook SDK’et loades.

    Linjen:

    js.src = d.location.protocol + "//connect.facebook.net/en_US/all.js";
    

    kan bruges til at styre hvilket sprog Facebooks ting skal vises på. Tilgængelige sprog kan findes i Facebook’s Locale XML.

    Nu er der adgang til Facebooks funktionalitet via. Javascript. I dette projekt blev det brug til 2 ting. Først skal der være mulighed for at folk kan dele appen med deres venner:

    function tellafriend() {
    	FB.ui({
    		method: 'apprequests',
    		message: 'Hvilken besked skal folk sende til deres venner?',
    		title: 'Overskrift.'
    	}, function (response) {
    		poststory();
    	});
    }
    

    Den sidste del:

    function (response) {
    	poststory();
    }
    

    Sørger selvfølgelig for at funktionen poststory() kaldes så snart folk har valgt hvem af deres venner de gerne vil dele appen med. Det er også muligt at trykke cancel og på den måde ikke dele med nogen, poststory() vil dog stadig blive kaldt.
    Formålet med poststory() er at lade folk poste et link til appen på deres egen væg:

    function poststory() {
    	FB.ui({
    		method: 'feed',
    		name: 'Overskrift på vægopslaget',
    		link: 'Link der skal deles',
    		picture: 'link til billede der skal inkluderes på opslaget',
    		caption: 'Billedetekst.',
    		description: 'Brødtekst på indlægget'
    	}, function(response) {
    		redirectuser();
    	});
    }
    

    Efter poststory() kaldes funktionen redirectuser(), som vha. et normalt Javascript redirect videresender brugeren til vores egen konkurrenceside.

    Jeg håber indlægget kan hjælpe med at komme udenom nogen af de små fælder jeg selv rendte ind i :-)
    Husk i forbindelse med konkurrencer at overholde Facebook’s egne regler for konkurrencer. Ellers kan det blive en kort fornøjelse. Kasper Blom har skrevet en god kort opsummering af konkurrencereglerne.

    Som jeg nævnte i forrige indlæg havde vi en diskussion efter sidste weekends WordCamp, vedrørende WordPress Danmark, og hvad folk i communitiet mener der kan gøres for at forbedre WordPress Danmark.

    Som nævnt har jeg meldt mig som tovholder på oversættelsesteamet. Ikke i den forstand at jeg skal have hånd i hanke med hvad der oversættes og hvordan, slet ikke, men i den forstand at jeg skal se på mulighederne for at gøre det lettere at finde plugins og temaer der er oversat til dansk, samt gøre det lettere for folk at bidrage til oversættelserne.

    Jeg har ikke alle de rigtige svar, men jeg har selvfølgelig gjort mig nogle tanker om hvad der evt. kunne gøres.

    1. Gøre det lettere hjælpe
    2. Gøre det let at tilføje projekter til førnævnte GlotPress, så folk med interesse i et specifikt plugin eller let kan komme i gang med at oversætte netop det
    3. Gøre det muligt at søge efter oversatte plugins

    Første punkt kunne evt. klares ved at opsætte en GlotPress installation på wp-danmark.dk, for at samle oversættelsesindsatsen, samt færdige oversættelser et sted. Det behøver selvfølgelig ikke nødvendigvis være GlotPress, men det kunne være et fornuftigt valgt, da det er anbefalede værktøj, og det bygger på BackPress, som er en fælles kodebase for WordPress relaterede projekter.

    Andet punkt kan hjælpes på vej ved evt. ved at se på muligheden for at kunne trække filer til oversættelse direkte fra WordPress.org’s plugin og theme repository, og evt. gøre det let for oversættere at tilføje nye projekter, til det software der blev diskuteret i punkt 1.

    Hvis de ovenstående 2 punkter bliver en succes, vil det selvfølgelig betyde at vi med tiden “automatisk” får opbygget en pæn samling oversatte plugins. Derudover vil det være relevant at kunne hooke ind i søgefunktionen på WordPress.org, for her i gennem at få adgang til de oversatte plugins og themes der allerede findes.
    Der er pt. ingen officielt dokumentation til WordPress.org søge API’et, men der kan findes nogle små optegnelser hos DD32. Desuden kan der jo søges både i plugins og themes direkte fra WordPress admin interfacet, hvilket betyder at findes fungerende kode i WordPress, som der kan rodes i.

    Har du andre forslag til hvordan det kan gøres lettere at finde danske plugins og themes, eller hvordan det kan gøres lettere for folk at hjælpe med at oversætte? Eller har du lyst til at hjælpe med at implementere ovenstående? Smid en kommentar herunder, eller endnu bedre, deltag i debatten på WordPress Danmark’s udviklingsblog.

    WordCamp er som jeg har nævnt før på bloggen, vel overstået. Så nu må det være på tide at komme tilbage i den samme gamle rille, og lade WordPress være WordPress.. eller hvad?

    Man kunne også vælge noget andet.
    Efter søndagens WordCamp var vi en gruppe mennesker der satte os ned, for at prøve at danne os et overblik over hvor WordPress Danmark står i dag, og hvor vi gerne ser det bevæge sig hen af i fremtiden. Det blev til en række foreløbige mål, de har allesammen hjemmesiden som udgangspunkt, men forhåbentlig kan den øgede aktivitet skabe noget opmærksomhed omkring projektet, der så senere kan brede sig til flere kanaler.

    Hovedpunkterne for WordPress DK hjemmesiden var:

    • Siden med bureauer skal erstattes, eller med enkeltpersoner der arbejder professionelt med WordPress, så det bliver lettere at finde folk med de rigtige kompetencer.
    • Gæstebloggere – For at skabe mere liv på hjemmesiden, skal det gøres lettere for folk med noget på hjerte, at få lov til at udgive gæsteblogindlæg på wp-danmark.dk
    • WordPress Planet – Der er mange danskere der allerede blogger på dansk om WordPress på deres egne blogs. De skal have mulighed for at tilmelde deres blogfeed til en feed aggregator, der samle danske blogindlæg om WordPress et fælles sted
    • Danske oversættelser af plugins – Det skal være lettere for folk at finde WordPress plugins der er oversat til dansk, samt at hjælpe med at oversætte plugins.
    • ShowCases – WordPress kan stort set alt hvad du skal bruge, og det kan se godt ud mens det gør det. Der skal samles nogle gode eksempler på hvorfor WordPress ikke længere bare er blogging software.
    • Accessibility var et populært emne under hele WordCamp. Da så mange af deltagerne mente at det var så vigtigt, og at det bestemt er muligt at opnå med WordPress, synes jeg bare det er med at komme i gang og få det bevist. Det er jo ingen skam at fremstå som et godt eksempel :-)
    • Forummet virker pt. som den mest aktive del af sitet. Det er godt. Men det indeholder pt. et stort arkiv af gammelt materiale, noget nyt, noget outdated, noget glemt noget tabt, og noget der måske aldrig igen skal beskues af menneskeøjne. Vi skal finde ud af hvad vi gør med det forum. Er udviklingen gået så hurtigt at de gamle indlæg er outdated og bare kan smides væk, eller er der værdi i at få det struktureret, samlet og måske opdateret? og hvem skal i så fald gøre det?

    Ja, der er nok at tage sig til, og der skulle være arbejde nok til alle, så hvis du har en interesse i et af ovenstående emner, eller har andre forslag til hvordan vi kan udbrede WordPress i Danmark, så hop forbi den nye smarte udviklingsblog, og giv dit input!

    Jeg har selv meldt mig som tovholder på oversættelsesholdet, og jeg vil i et senere indlæg komme ind på hvad jeg har af idéer til emnet.

    Som nævnt i går, da jeg omtalte WordCamp 2011 – dag 2, var det sidste foredrag på WordCamp andendagen, en række små præsentationer af forskellige deltageres egne WordPress projekter.

    Tovholder for præsentationerne var Kåre Mulvad fra dejliglama.dk, som desuden lagde ud med et af arrangementets mest interessante foredrag.
    Kåre arbejde i dejliglama.dk med professionel udvikling af WordPress sites. Han fremviste en lang række projekter han har arbejdet på i tidens løb, og fortalte lidt om hvordan han havde udnyttet mulighederne i WordPress til at nå frem til en løsning.
    Theis’ udgangspunkt var hvad han beskrev to vinkler til webudvikling:

    • Nørder vi med sitet, for at få lov til at lave koden?
    • Nørder vi med koden for at få lov til at lave sitet?

    Hans pointe her var at han var tilhænger af en pragmatisk tilgang hvor fokus var et site med den funktionalitet kunden skulle bruge, og ikke tilføje funktionalitet for funktionalitetens skyld.
    De vigtigste ting jeg fik med fra foredraget til videre brug var en række anbefalinger til plugins, som Kåre havde gode erfaringer med.

    Han anbefalede desuden WPMU dev, som et godt sted at købe plugins, og bogen Digging Into WordPress. Desuden ville han gerne slå et slag for brugen af Google Fonts, hvis man vil bruge specielle fonts på sine sites.
    Kåres noter kan findes på .

    Efter Kåres foredrag kom en række af de andre deltagere, som tidligere nævnt, på banen med en række af deres egne WordPress projekter.
    Først var det Lisa Risager der viste to projekter, med hvert sit fokus. I det første projekt vist Lisa hvordan man kan bruge jQuery Masonry til at lave et tile-baseret plugin på StrikOgKod.dk. I det andet projekt brugte hun WordPress indlæggenes featured images, til designet på Trashaid.

    Efter Linda valgte Kåre lidt for sjov at vise et Theis’ projekt Theis.pro, som er et lille site Theis havde siddet og strikket sammen på en times tid i løbet af dagen.

    Anden person på banen var Helge Larsen. Han har lavet et WordPress plugin, hvor man via shortcodes kan håndtere sin database fra WordPress’ front-end.

    Tredje person var Ask Hybel som åbenbart står bag et projekt jeg har fulgt et stykke tid, netop blågårdsgade.dk.
    Asks udgangspunkt er at han ikke er programmør, men havde en række idéer til hvad hans site skulle kunne, nogle tanker han har ført ud i livet vha. en række plugins, samt kode han har tyvstjålet fra forskellige steder på internettet. Ask så nærmere WordPress som en ramme der kunne underbygge hans projekt, i stedet for at se WordPress som selve projektet.
    Jeg kan godt lide Asks idé om at kaste sig ud i tingene, og forkorte afstanden fra tanke og til handling. Det er selvfølgelig ikke den rigtige strategi på alle projekter, men der er alt for mange projekter der aldrig bliver til andet end pæne ord, pga. manglende action.
    Ud over de tekniske overvejelser fortalte Ask hvordan han fokuserede på at udlicitere så meget af arbejdet som muligt, både ved at få butiksejere og brugere af gaden til at bidrage indhold, men også ved at lave en række mashups med data fra forskellige steder på nettet.

    Fjerde person var Linda Kristiansen der viste en håndfuld sites. Ligesom Ask var Linda glad for WordPress da hun kan bruge det nærmest som et byggesæt, hvor hun med minimal kontakt med den bagvedliggende teknik, nærmest kan trække-og-slippe byggekloder op i en bunke, til et fungerende site. Hun viste sit site Radikale.nu, der vha. FeedWordPress fungerer som en feed aggregator for en række forskellige radikale politikeres blogs.
    To af Lindas hjertebørn var accessability og usability, og hendes præsentation af et endnu ikke offentliggjort site til blinde og svagtsynede startede en spændende debat om usability i WordPress.

    Arrangementets sidste præsentation blev forestået af Knut Nägele der præsenterede hans projekt herald.dk som er en feed aggregator der samler nyheder fra en række danske nyhedssites.

    Som nævnt har jeg brugt denne weekend på årets WordCamp Danmark. Jeg skrev i går om WordCamp Danmark, første dag.

    Dette indlæg vil omhandle de fleste af mine oplevelser på andendagen. På anden dagen skete der et par interessante ting ud over foredragene og jeg har derfor valgt at fordele andendagen over flere indlæg, men mere om det senere, dette indlæg handler om foredragene.

    Da der var 2 aflyste foredrag, var der nogle ændringer i programmet, så dette er altså ikke retvisende for dagen.

    Dagens første foredrag var Thomas Clausen, som på første dagen fortalte om webshops. I dag fortalte han om et emne der kom op flere gange i løbet af førstedagen, nemlig custom post types, og taxonomies.
    Foredraget startede med en introduktion til custom post types og taxonomies. Det var en god introduktion, der fik slået nogle definitioner og forskelle ordentligt på plads. Et hovedtema som Thomas kom tilbage til flere gange, var WordPress’ template hierarchy, og hvordan WordPress finder ud af hvilken template der skal bruges, baseret på hvilken post type man arbejder med.
    Det var et rigtig godt foredrag, der fik slået en række definitioner på plads som jeg synes har manglet lidt. Desuden førte foredraget til en rigtig god debat, og en række længere diskussioner. Det var godt, og slidesne kan findes på SlideShare.

    Andet foredrag var Mark Gazel, hovedmanden bag WordPress Danmark, samt hovedforcen bag årets WordCamp (Mange tak!), der snakkede om WordPress Danmark, før, nu og i fremtiden.
    Mark startede med lidt forhistorie om hvordan WordPress Danmark opstod, samt forløbet op til at han pludselig, uventet, havde fået overdraget ansvaret for hele foreningen. Dette endte ud me en kort opsummering af hvad der er sket siden WordPress meetup’et (lækkert ord!) tidligere på året.
    Herefter kom han lidt ind på oversættelse af WordPress, og plugins til dansk, hvordan det ofte foregår, samt noget om hvorfor det er vigtigt.
    Den sidste del af Mark’s foredrag handlede om hans tanker vedrørende WordPress Danmark hjemmesiden, både hvordan det så ud nu, og hvad han håbede at se fremover. Dette ledte til endnu en rigtig god debat, denne gang om foreningens hjemmeside, og hvad den evt. kunne bruges til. Desuden spawnede foredraget en arbejdsgruppe, der sidst på eftermiddagen satte sig sammen, og snakkede om hvad der skulle ske fremover, samt hvordan vi skulle nå frem til dette. Mere om det i et senere indlæg. Mark’s slides findes som resten online.

    Det tredje foredrag blev forestået af Mikkel Breum, der snakkede om WordPress themes, og funktionalitet.
    En af Mikkels hovedpointer var at themes var meget mere end et pænt design. Langt de fleste theme indeholder også en del teknisk funktionalitet, både i form af indlejret speciel kode, men også i form af inkluderede plugins og tilgængelige shortcodes og custom post types. Dette kan bl.a. give nogle problemer hvis man skifter theme, da man pludselig kan stå med manglende funktionalitet, eller endda manglende blogindlæg, da man har mistet en post type.
    Mikkel argumenterede for hvorfor plugins bør installeres ordentligt, i stedet for at indlejres i et theme, hvilket jeg synes er rigtig fornuftigt. Jeg synes generelt at det er en god idé som udvikler, at benytte et MVC design pattern, eller en afart heraf, når man udvikler. Selv brugte Mikkel et projekt ved navn TGM Plugin Activation, til at lade sine themes installere de plugins han bruger direkte i WordPress intallationen, det er et projekt jeg selv skal have kigget mere på.
    Til sidste var han en smule inde på parent og child themes, og opfordrede spirende WordPress designere til at sætte sig ind i WordPress’ Theme Review Guidelines, og evt. give en hånd med på Theme Review holdet.
    I løbet af foredraget nævnte Mikkel bl.a. ThemeForest, WpCandy og Theme.fm som gode steder at finde themes.

    Det sidste foredrag bestod hovedsageligt af at folk præsenterede forskellige WordPress projekter de havde arbejdet på, og snakkede om hvilke plugins og teknikker de havde fokuseret på i projektforløbet, samt hvad tankerne bag projektet har bestået af. Der var rigtig mange spændende projekter, så mange at jeg mener disse fortjener et indlæg for sig selv.

    Alt i alt var det en rigtig god weekend, med masser af inspirerende foredrag, og endnu flere inspirerende mennesker. Mange tak til alle deltagende, og især til Mark, for at få det hele op at stå! I løbet af dagen blev nævnt rigtig mange forskellige ressourcer, og Thomas Gam har samlet en liste med mange af dem.

    Var du med? Hvad var dine indtryk af erfaringer af arrangementet, og de forskellige foredrag?

    Edit: Jeg har tilføjet de resterende slides.

    Det var som tidligere nævnt ikke min plan at deltage i dette års WordCamp, men da Lars Bachmann var så rar at trække min kommentar som vinderen af en af hans 2 udloddede billetter, var det jo bare om at komme afsted (alt andet ville da også være uhøfligt).

    Det jeg personligt fandt mest interessant på første dag, var de mange rare mennesker, der alle var friske på en god samtale om diverse webprojekter, samt hvordan vi hver især bruger WordPress eller andre platforme. Men der var også et rigtigt spændende WordCamp program, med oplæg jeg gerne vil knytte nogle noter til.

    Første oplæg var WebMatrosen (fedt navn, egentlig) Oliver Nielsen, der snakkede om brug af videoer online. I starten var jeg ikke helt imponeret, både fordi jeg ikke er voldsomt interesseret i videoredigering, men også fordi det virkede som om at oplægget ikke ville bestå af andet end fremvisning af diverse billeder og videoer. Det ændrede sig heldigvis hurtigt, og førte til Oliver’s tilgang til brug af video online, samt en introduktion til de virkemidler han fokuserer på når han arbejder med videoproduktion, det kunne opsummeres i forkortelsen SUCCES(S), som står for (frit efter min hukommelse):

    • Simplicity
    • Unexpectedness
    • Concreteness
    • Credibility
    • Emotions
    • Stories

    Som man kan lære mere om i bogen Made to Stick. Oliver’s slides findes på SlideShare

    Andet oplæg blev forestået af Thomas Clausen fra Designgrotten, som talte om brugen af WordPress som e-commerce platform (hans slides findes på slideshare). Det blev hurtigt til en diskussion om hvilken e-commerce platform der er den bedste, en god debat som jeg tror kunne være interessant at have, men jeg synes det var lidt synd da det ikke var et godt tidspunkt til debatten i mine øjne. Noget jeg fandt rigtigt interessant ved Thomas’ oplæg var hans eksempler på plugins han selv brugte, og nævnte som det vigtigste WooCommerce.
    Desuden fortalte Thomas om den He-man model han selv arbejder efter:

    1. Handling
    2. Entusiasme
    3. Mål
    4. Aftaler
    5. Niche

    Tredje oplæg var Joen Asmussen, der i dagens anledning havde valgt at tage bukser på, på trods af titlen “Bukser ikke påkrævet”.
    Joen arbejder til dagligt hos Automattic, som er firmaet bag WordPress. Han fortalte bl.a. om hvordan det er at arbejde for Automattic, og hvordan de arbejder og får virksomheden til at hænge sammen, på trods af at medarbejderne er spredt ud over hele kloden, og sjældent mødes in person. Endnu et godt oplæg, og slidesne er tilgængelige online.

    Dagens sidste oplæg stod Lisa Risager for. Lisa snakkede om at personalisere WordPress. Det handlede om theming, og fordele og ulemper ved at lave sine egne themes vs. at benytte eller tilpasse andres themes. Desuden blev der snakket en del om fordele og ulemper ved brugen af plugins, vs. at definere de funktioner man skal bruge i WordPress’ functions file. Oplægget virkede desværre nogen gange som om det var en genopfriskning fokuseret på folk der allerede havde arbejdet med emnerne, nærmere end en introduktion til folk der gerne ville i gang, men overordnet set synes jeg der var et ok fokus, og det var generelt en fint oplæg, med nogle rigtig gode diskussioner. Lisas slides kan desuden findes på SlideShare.

    Alt i alt synes jeg det var en rigtig god første dag, og jeg glæder mig meget til dag 2!

    Da der var et oplæg om brug af video, er der selvfølgelig også blevet optaget i løbet af dagen, og så vidt jeg ved er planen at optagelser fra alle oplæg kommer online på et tidspunkt.

    Edit: Indlægget er nu opdateret med links til de manglende slides.