Browser-caching av CSS-filer oppstår fra tid til annen, og derfor hender det man slenger på noen spørrestrenger i URL-en for å få nettleserne til å oppdatere til siste versjon.
For eksempel vil http://example.com/style.css bli til http://example.com/style.css?ver=123456789.
Dette problemet har jeg nylig hatt i WordPress, men å legge til en «ver»-streng i URL-en til hoved-CSS-filen er ikke all verden med jobb. Bare se her:
Åpne, eventuelt opprett, filen functions.php i ditt tema.
Mustasjen er i anmarsj, og ikke bare i ansiktet til hipstere. Mustache er et rammeverk for templates, eller maler, som også er tilgjengelig i Javascript. Det tillater deg enkelt og greit å definere strenger med HTML og forskjellige tagger for å representere variabler. Veldig greit om du er glad i å bruke massevis av $('foo').append('lang HTML-kode her').
Enda bedre er det selvfølgelig når man bare kan laste inn templates med AJAX og dermed kunne ha et lite lager med templates liggende. Mustache støtter i tillegg seksjoner, og med rett bruk kan du faktisk klare deg med en enkelt fil.
WordPress sin editor er ikke så veldig snill når det kommer til å lime inn kildekode direkte i den, med mindre du bruker den rene HTML-editoren. Så fort du bytter tilbake til visuell-editor, blir blant annet < og > byttet ut med HTML-entiteter for disse tegnene, noe som gjør det relativt vanskelig å legge ut ren kildekode.
Men! Det er alltid et innstikk som fikser problemet. I dette tilfellet prøvde jeg først Creyon, men problemet vedvarte. Før jeg så fant et innlegg i WordPress sin Codex, som viste til en løsning brukt på wordpress.com og som finnes som et eget tillegg: Syntax Highlighter Evolved. All kode limt inn mellom kodesnuttene blir ikke påvirket av TinyMCEs tåpelige omformattering.
Har laget en enkel parser opp mot 1881 sitt søk på nett og som henter ut navn, adresse og sted. Det fungerer også å søke på navn, men den er ikke idiotsikker 😉
Oppdatering: har fikset PHP-versjonen så den ikke avhenger av mitt privatmekkede HTTP-bibliotek.
Jeg har lenge irritert meg over at WordPress gjør om vanlige anførselstegn (") og apostrofer (') til idiotiske "curly quotes", eller enkle og doblegrav og akutt aksenttegn. Det egner seg spesielt dårlig når man har en blogg som dette med mange kommandoer som blir sitert, og man regner med at folk kopierer og limer inn i terminalen sin, som igjen ikke vil fungere på grunn av dette.
Lag en enkel og fin sideliste i flersidede innlegg
Den siste tiden har jeg fundert på å legge ut en liten test av en bærbar datamaskin, men jeg følte at bloggen manglet en vesentlig ting – støtte for flere sider i det enkelte innlegg.
Etter en liten runde med Google, fant jeg fort ut at dette er støttet av motoren, men ikke alt var så flott som jeg ville ha det.
Bruken er enkel. Man redigerer HTML-en for innlegget sitt og legger inn en <!--nextpage--> (uten mellomrom her, altså!) hvor man vil ha et sideskille. I motsetning til <!--more-->-taggen, kan man bruke <!--nextpage--> flere ganger.
En annen løsning er hurtigtasten alt+shift+p, mens en tredje løsning er å redigere wp-admin/includes/post.php, søke opp «wp_more» og legge til «wp_page» i $mce_buttons-arrayet.
Funksjonen wp_link_pages(), som ser ut til å være den eneste funksjonen tilknyttet dette, lager bare en veldig enkel liste med sidene, men du kan for eksempel ikke få den ut som en HTML-liste (<ol>/<ul>). I tillegg var det ikke mulig å titulere sidene. Kort oppsummert var ikke støtten så alt for god, så jeg endte opp med å lage noe selv.
Jeg laget en funksjon kalt wp_post_page_list() i functions.php som gir deg en fin organisert liste (<ol>) om innlegget har flere sider. Den tar også utgangspunkt i at det eksisterer et <h[1-6]>-element rett etter <!--nextpage-->-deleren, som da blir benyttet som sidetittel.
I bruk er den enkel: <?phpecho wp_post_page_list(); ?>
Man kan også få en egen knapp i editoren for å skille, altså lage sider. Denne vil havne ved siden av knappen som brukes til å lage et såkalt «mer-skille», også brukt til ingress/utdrag. Hvordan man gjør dette, finner du på neste side. Kildekoden for funksjonen wp_post_page_list() er på siste side 🙂
Noen har kanskje fått det med seg fra før av, men jeg gjentar gjerne. I lang lang tid har jeg irritert meg over blant annet treg innlogging i Sparebank 1 sin nettbankløsning fra Firefox, samt en ikke-tilstedeværende støtte i Google Chrome.
Etter en del feilsøking i det siste, har jeg kommet frem til at dette skyldes bruk av den utdaterte <applet>-taggen for å laste inn BankID-appleten. Jeg har nylig informert Sparebank 1 om dette, og forhåpentligvis får de byttet om og tatt i bruk <object>-taggen i stedet. Inntil videre kan man benytte seg av en flott utvidelse til Google Chrome / Chromium, tilfeldigvis utviklet av undertegnede.
Utvikling av utvidelsen førte til tider til massivt hårtap, spesielt når bruk av JavaScript-rammeverk viste seg å være umulig grunnet restriksjoner på <applet>-elementet i DOM. Dette førte til at alt måtte skrives med native JavaScript, og en del, la meg kalle de "fiffige", løsninger ble brukt. Blant annet regex-parsing av ren HTML for å hente ut attributter. I tillegg til at den beholder alle attributter og eventuelle underelementer av typen <param>, legger den til attributten «type», med verdien «application/x-java-applet».
Uansett, den fungerer i nettbanken til Sparebank 1. Den er skrevet generisk, så den bør fungere på andre nettsider òg, men dette er en tidlig utgave og er neppe 100% feilsikker. Forhåpentligvis skaper den ikke problemer på andre sider som fremdeles bruker <applet>-taggen (dessverre er det en del).
Oppdatering: om noen er interessert i å se hvor lite kode som hadde vært nødvendig ved bruk av jQuery, er dette å finne her. Det fungerte i en periode og på enkelte sider, men ikke hos Sparebank 1.
I dag fant jeg ut at jeg liker å se hva slags "klienter", eller kilde, folk twitrer fra. For øyeblikket bruker jeg en Widget i Opera som jeg synes er veldig kjekk og oversiktelig for Twitter-bruk, så jeg bare måtte hacke inn støtte for dette.
Kort fortalt har jeg da lagt til en sjekkboks i innstillingene som gjør at du kan slå dette av og på. Den er standard PÅ.
Jeg har for tiden gjort mitt for å prøve og promotere bloggen min hver gang jeg poster nytt innlegg. Blant annet har jeg fått opp lenker på artikler hos Dagbldet ved hjelp av Twingly, delt lenker på Twitter og på Facebook.
I kveld kom jeg til å ta en kikk innom serverside.no og deres pagerank-sjekker. "N/A". Hva i alle? Det fikk meg til å tenke på at WordPress faktisk ikke slenger på meta-tagger selv, og plugins må til for å ordne denne biffen. Installasjon av "All in one SEO pack" og "Google Sitemap XML generator" gjorde biffen. Ikke det, jeg har registrert siden hos Google og fått den inn under Webmaster Tools for lenge siden.
Så, nå får vi se, da. Kanskje går pageranken opp etter hvert. I'll keep you posted.