Har lagt ut en liten men nyttig uppdatering av Related-Images. Man kan numera få ut den genererade bildens höjd och bredd samt beskrivning och caption. De senare två kan användas för att sätta egna bildtexter. Tyvärr sitter bildtexter direkt på bilden i WordPress, vilket gör att alla placeringar av samma bild får samma bildtext. En annan lite skum grej är att WP-Super-cache inte verkar släppa cachen då man uppdaterar media, en ändring i en bildtext kan därmed släpa lite.

Måste bara visa detta, dels för att det är kul och dels för att det är intressant. @Jocke Jardenberg twittrade en rad om min WordPress-plugin för en dag sedan, ”Lite cool WP-plugin av @fosseus”. Detta resulterade omedelbart i en peak på min sajt, tydligare Jardenbergeffekt än så blir svår att hitta, ett tack är på sin plats.

Bildhanteringen i WordPress lämnar en del övrigt att önska. Den är förvisso väldigt smidig och klart förbättrad på senare tid men ibland vill man helt enkelt inte ha alla bilder mitt i sina poster.

För den som vill lägga en bild över rubriken blir det lite trixande och samma trixande blir det om man vill göra en så enkel grej som att använda en bild till förstasidan och en annan bild till artikelsidan.

Efter att ha irriterat mig lite på detta har jag helt enkelt gjort en plugin som fixar det hela. Det brukar ju vara den enklaste lösningen.

Allt är väldigt enkelt. Ladda hem Related Images, lägg i plugin-mappen och aktivera. På sidan där du skriver en post finns nu en låda med ett sökfält . Där söker du bland bilderna i ditt media-arkiv och då du hittar en bild väljer du position, och sparar.

För att få ut bilden på sidan använder du en template tag. Den behöver ligga innanför the_loop och fyra parametrar finns tillgängliga.

Första parametern är positionen och i version 1.0 finns det fyra olika placeringar att välja bland, andra är bildens maxbredd och tredje är bildens maxhöjd. En fjärde parameter kan skickas med och det är en css-klass som då läggs på bilden.

related_image('left_firstpage', '200', '200');
related_image('right_firstpage', '200', '200');
related_image('top_firstpage', '500', '200');
related_image('top_article_firstpage', '500', '200');

Sådär,  nu kan du placera template-taggen och därmed bilderna helt fritt och utanför själva posten. Självklar kan man fortfarande använda traditionella inlinebilder i kombination med de relaterade.

SDS-koncernen har tagit första steget för att implementera sitt nya kalenderbygge som körs på WordPress. Wp är kanske mest känt som bloggplattform men fungerar, som jag tidigare varit inne på, alldeles utmärkt även som ramverk för att bygga helt andra typer av webbapplikationer. En av fördelarna är att man i WordPress får ett välkänt och omtyckt backend som även erbjuder ett starkt API.

Tanken var att bygga en central kalender där all data låg på ett och samma ställe för att man sedan skulle kunna skapa fristående ”frontar” som kunde pressentera kalenderhändelser. Dessa frontar skulle kunna ha olika utseende, olika innehåll och svara på olika domäner. Sydsvenskan.se skulle ha sig egen front, och Ystadsallehanda sin osv. Inmatningen skulle ske från flera olika redaktioner och även externt.

De olika tidningarna kommer att ha varsin mer permanent kalender och enkelt kunna sätt upp tillfälliga vid behov (tex Konstrundan-kalendern) dessutom ville man ha en export av kalenderdata från WordPress direkt till tidningssidan som ligger i InDesign. Slutligen ville man ha ett API för att på ett enkelt sätt kunna koppla på externa aktörer samt enkelt bygga formulär för att låta användarna kunna mata in egna händelser.

Lösningen blev att installera en nätverksversion av wp, låta rootbloggen hålla i all kalenderdata och därefter låta front-bloggarna kunna hämta ut data ur rootbloggen och lista ut. Inte helt standard men det fungerar kalas, inte minst tack vare <?php switch_to_blog($new_blog) ?> som gör jobbet bra.

En egen post_type blev grunden för en händelse och till den kopplades sedan kategorier och taggar. Metadata hamnade där den brukar hamna (på vant wp-vis) men i de fall vi behövde göra extremt snabba uppslag lagrades metadata istället i en egen index-tabell. Ett index från GSA eller Sorl hade säkert fungerat lika bra.

Alla sajter i kalender-installation delar alltså på ett antal tabeller, taggar, kategorier osv. Därefter kan redaktören konfigurera vilka områden (kommuner) som ska vara tillgänglig via en given front, välja ett tema och köra ut en kalender. Exporter till InDesign tas ut på liknande sätt och kan skickas direkt in på de olika tidningarnas pappers-sidor.

Wp sköter hela backend som är ganska default förutom någon extra tabell. Utlistningen av händelser i fronten fick dock byggas om rejält då gamla fina ”the_loop” har dåligt stöd för att hämta data från en annan sajt än den man befinner sig på. För att få upp anständiga svarstider från den egna index-tabellen har vi lagt ett memecached-lager ovanpå alltihop, och allra längst ut tar Akamai hand om eventuella trafiktoppar.

http://kalender.kristianstadsbladet.se är först ut.

Drop Zone är en plugin som skapar ”droppbara” ytor på en WordPress-sajt. På dessa ytor kan man sedan dra och släppa vanliga wp-poster som ”fastnar” och skapar puffar (ursäkta tidnings-språket) med rubrik, valbar ingress och tumnagel. Nytt i version 1.3 är stöd för wp-super-cache, uppstädning av JavaScript:en (tack Peo Bondesson) samt att ”before_title” och ”after_title” nu stödjs fullt ut.

Laddar hem det gör du enklast här direkt från WordPress.org.

För att kunna köra Drop Zone behövs php5 och en modern webbläsare eftersom pluginen använder html5 native drag/drop. Installerar gör du som vanligt, lägg drop-zone-mappen direkt i wp-content/plugins/ och aktivera.

Därefter drar du ut valfritt antal ytor under ”Utseende/Widgets” i ditt backend, som i sin tur skapar de droppbara ytorna på din sajts frontend, och droppa poster kan den som är inloggad göra. Här finns en lite mer utförlig förklaring.

Behöver jag säga att detta är den bästa versionen någonsin?

Många vill använda ajax-requests i sina pluginer eller templates och det finns flera olika sätt att göra detta på. Här kommer några ganska konkreta tips som kan vara bra att ha i bagaget då man ska implementera ajax på wordpress. För att det ska fungera behöver du köra php5 och wp3.1.

Wp behöver en ”ajaxurl” för att köra en request så vi inleder med att skapa en sådan. Man ser ganska ofta hårdkodade varianter men det är både bättre och säkrare att använda <?php wp_localize_script( $handle, $object_name, $l10n ); ?>. Kanske känns det lite märkligt men som dokumentationen och som wphardcore.com tipsar om så kan metoden deklarera javascriptvariabler med ett namespace, vilket är exakt vad vi vill göra.

wp_localize_script('mitt-ajax-handle','MittNamespace', array(
	'ajaxurl' => admin_url('admin-ajax.php'),
	'nonce' => wp_create_nonce('min-nonce')
	)
);

Detta genererar följande kod i din template, förutsatt att du använder <?php wp_head(); ?> på ett korrekt sätt. Som man ser är detta ett javascriptobjekt som det går utmärkt att använda för att köra dina ajax-requests. Dessutom får du en korrekt nonce som gör att dina requests blir säkrare. Någon som man alltid bör tänka på. En nonce är enkelt förklarat en sifferrad som gör att du kan validera huruvida ett request körs från din sajt eller inte.

/* <![CDATA[ */
var MittNamespace = {
	ajaxurl: "http://www.dinsajt.se/wp-admin/admin-ajax.php",
	nonce: "125088c92dasd4c"
};
/* ]]> */

Därefter behöver du registrera en ajax-action och dessutom tala om vilken metod som ska köras. Det gör du via följande action hook.

add_action('wp_ajax_nopriv_min-ajax', 'min_metod');
add_action('wp_ajax_min-ajax', 'min_metod');

Wp erbjuder två varianter för detta, en då man har en hook för inloggade, och en för oinloggade, vill man kunna erbjuda ajax för alla användare får man snällt registrera in samma metod två gånger. Vi behöver även skriva metoden (eller funktionen) som ska köras då ett ajax-request till vår action "min-ajax" kommer. Där kan du fånga data med $_POST eller $_GET som vanligt. Men det vikitiga är att först kolla efter vår nonce och därefter verifiera. Glöm inte att avsluta metoden med en "die();" utan den kör wp din request fel.

function min_metod() {
	$nonce = $_POST['nonce'];
	if (!wp_verify_nonce($nonce, 'min-nonce')){
		die();
	}
	// Din kod här....
	die();
}

Nu behöver du bara lägg till lite javascript för att skapa ett ajax-request. Som vanligt skriver du javascript i en separat fil (.js), lägger den i pluginmappen eller templatemappen och inkluderar den med hjälp av följande rad. Efter som jag vill använda jquery för mitt resuest passar jag på att inkludera även det. Beroende på när requestet ska köras få du trigga det, med "click" eller annat, men underfär såhär fångar du nonce och ajaxurl.

wp_enqueue_script('min_js', WP_PLUGIN_URL.'/min-plugin/min_js.js', array('jquery'));
jQuery(document).ready(function() {
	jQuery.post(MittNamespace.ajaxurl, { action : 'min-ajax', nonce : MittNamespace.nonce}, function(data) {
	// returnera
	});
});

Ajax är trevligt att arbeta med och wp har bra inbyggt stöd för att skapa dynamiska sajter. Men se till att säkra upp alla dina requests med en nonce, det har du mycket att villa på.