Ett problem som jag haft väldigt länge är att jag kört många olika WordPress-installationer för relativt små projekt. Det är inte alls särskilt roligt att underhålla alla dessa installationer, dvs att hålla kärnan och tillägg uppdaterade. I ett tidigare projekt så skapade Tedde Lundgren ett tillägg som tillät oss att koppla flera olika domäner (inte begränsat till subdomäner) till en installation.

Jag är medveten om att det finns liknande tillägg som exempelvis WordPress MU Domain Mapping. Det som skiljde Teddes version från denna var att vi fick tillgång till gruppering av domäner, så vi kan köra separata utvecklingsdomäner. Tillägget är för övrigt en riktig lättviktare och innehåller endast det som behövs, dvs inte bloatat. Tedde har planer på att släppa tillägget öppet senare i sommar.

Screenshot Domain Mapper

Mjukvara och tjänster som används

• Nginx – Webbserver
• Apache- Webbserver
• PHP + APC – APC används för cachning
• Memcached – Memcached används för cachning
• WordPress + W3 Total Cache – Publiceringsverktyg samt W3 Total Cache för att cacha
• Ruby + Capistrano – Capistrano är en samling Rubyscript som används för att enkelt deploya till drift/utvecklingsserver
• Git + GitHub – Git är versionshantering av källkod, GitHub är en tjänst för att samarbeta med andra utvecklare

Webbserver

Wikipedia skriver följande angående Nginx:

Nginx quickly delivers static content with efficient use of system resources. It can deploy dynamic HTTP content on a network using FastCGI handlers for scripts, and can serve as a very capable software load balancer.^[2]

Med detta som grund så valde jag att använda Nginx som webbserver (@port 80) för att servera allt statiskt material (JavaScript, CSS och bilder), för att sedan proxy:a alla andra anrop vidare till Apache (@port 81).

Cachning och WordPress

Genom att använda Memcached, APC i kombination med W3 Total Cache så har jag fått ner laddningstiden i WordPress oerhört mycket. Ett problem som jag tyvärr upplever för tillfället är att administrationen i WordPress 3.1.3 är väldigt trög, det verkar vara ett känt problem som många inte upplevde i 3.0.x-branchen. Vi får se ifall det fixas i 3.2 som borde lanseras inom en snar framtid.

GitHub och Capistrano

Versionshantera, snälla! Även ifall du är den enda i projektet… På GitHub har jag samlat all kod jag använder i mina projekt. Jag har ett betalkonto som tillåter mig att ha 10 privata repositories och en medarbetare på dessa. All utveckling sker lokalt (på exempelvis http://hassis.dev) och när jag är nöjd så laddar jag upp på GitHub och den jag arbetar med laddar ner det lokalt och tittar över det. När vi sedan är överens om att det går att släppa publikt så kör vi ut allt genom Capistrano.

Capistrano förutsätter att man har tillgång till SSH och använder sig av publika nycklar för att autentisera sig mot servern.

Slutsats

Detta är tänkt som en genomgång vad jag använder för verktyg när jag utvecklar. Vill ni se lite exempel på källkod så får ni gärna säga till.

Stötte för någon vecka på ett nytt problem för min del. Det handlade om att jag skulle skapa ett plugin som används i multi-site. Jag har jobbat relativt lite med Multi-Sites och problemet var att tabellerna inte skapades för alla ”siterna” som fanns i nätverket.

Källkod

register_activation_hook(__FILE__, 'hass_vote_activate');
 
function hass_vote_activate() {
	global $wpdb;
 
	if (function_exists('is_multisite') && is_multisite()) {
		if (isset($_GET['networkwide']) && ($_GET['networkwide'] == 1)) {
			$old_blog = $wpdb->blogid;
 
			$blogids = $wpdb->get_col($wpdb->prepare("SELECT blog_id FROM $wpdb->blogs"));
			foreach ($blogids as $blog_id) {
				switch_to_blog($blog_id);
				_hass_vote_activate();
			}
			switch_to_blog($old_blog);
 
			return;
		}	
	} 
	_hass_vote_activate();		
}
 
function _hass_vote_activate() {
	global $wpdb;
 
	$table_name = $wpdb->prefix . 'yourtable';
 
	if ($wpdb->get_var("SHOW TABLES LIKE '$table_name'") != $table_name) {
		$sql = "CREATE TABLE " . $table_name . " (
			id mediumint(9) NOT NULL AUTO_INCREMENT,
     			dateadded bigint(11) DEFAULT '0' NOT NULL,
     			subject VARCHAR(255) NOT NULL,
	  		UNIQUE KEY id (id)
	  	);";
 
		require_once(ABSPATH . 'wp-admin/includes/upgrade.php');
  		dbDelta($sql);
	}
}

Ovanstående kod vandrar igenom alla dina siter som är uppsatta i nätverket och kör aktiveringsfunktionen för dessa.

Koden ovan raderar inte tabellerna vid inaktivering, det skapar heller inte tabellerna för nya siter som aktiveras i nätverket. Du får i sådana fall använda följande actions:

add_action( 'wpmu_new_blog', 'your_function_activation_on_new_blog'); 		// For new site
register_deactivation_hook( __FILE__, 'your_deactivation_function' );		// For deactivation

Den 23-24 oktober går Sveriges första WordCamp av stapeln. Platsen är Tekniska muséet i Stockholm, och dit kommer vi för att lära av varandra samt ha trevligt – allt i skön WordPress-anda.

Jag deltog i en tävling av Binero och lyckades knipa en biljett till WordCamp Stockholm den kommande helgen (23-24 oktober).

Ser ni mig där så tveka inte att säga hej!

Uppdatering 2010-10-21

P.g.a. lite oplanerade studier så har jag idag tvingats avboka min biljett på WordCamp. Vi ses nästa år istället!

Tillägget

Så, vad är det jag vill göra, jag vill identifiera besökarens webbläsare och om det är en mobil så ska den ”on-the-fly” byta till mitt mobila tema. Jag vill sedan ha ett sätt att kunna hoppa mellan den mobila och vanliga webbplatsen.

All kod finns i en Gist på GitHub (mycket anpassad för mina behov) för hur jag löst detta. Jag skapade ett plugin som tog hand om det hela. Om mitt vanliga tema heter ‘xc1-test’, så kommer jag att kolla ifall temat ‘xc1-test-mobile’ existerar.

WordPress ger oss möjligheten att ladda in ett separat tema med hjälp av filtret ‘stylesheet’, så vi gör en kontroll ifall temat finns (och efterfrågas) och i sådana fall hoppar vi över till det.

Temat

Temat xc1-test-mobile innehåller inte så mycket annat än exempelkod från jQTouchs lösning, så det är inte mycket nytt under solen där.

Det som inte är så vackert just nu är hur sidor och inlägg hämtas ifrån WordPress, jQTouch hämtar enbart statiska filer, därför har jag fått lov att lägga till .html i slutet på mina sidor. Poster däremot får man lov att ändra manuellt permalänk-inställningen i administrationen så den har .html på slutet. Detta kommer jag nog ändra och skriva om AJAX-hämtningen manuellt, men detta var mest för att få allting att fungera i ett inledande skede.

Temats filer single.php och page.php ska inte innehålla get_header() och get_footer().

Jag kan sedan hoppa mellan de två olika versionerna genom querystringen ?xc1-layout=mobile och ?xc1-layout=default.

Menyer

Något som är riktigt fint i WordPress 3 är att jag kan skapa en separat meny (i menyhanteraren) för den mobila versionen och använda den i detta mobila tema, då kan jag skapa separata mobilversioner av de sidor som jag vill ha tillgängliga ifrån mobilen.

Slutord

Jag har tittat mycket på hur andra har löst detta, jag kommer skriva mer om detta när jag känner mig nöjd med lösningen, ge gärna kommentarer på hur ni löst detta.

Systemet listar ett antal frågor som du som besökare kan ”rösta upp”, sedan visar man de populäraste frågorna och lite annat. Varje fråga har en egen landningssida, exempelvis /fraga/10 (där 10 är id:t på frågan). Landningssidan och listningen av frågorna definieras av shortcodes i sidor, exempelvis: [poll_show_single] och [poll_list].

På sidan som innehåller [poll_show_single], i det här fallet är det sidan ‘fraga’, vill jag ha möjlighet att sätta frågans rubrik som ny titel (via filtret wp_title).

Det går tyvärr inte att ändra titeln inifrån shortcoden, utan man får identifiera vilken sida som shortcoden finns på och sen sätta titeln separat. Detta kan du göra på följande sätt:

function locate_shortcode ($shortcode) {
  global $wpdb;
 
  $search = ((!empty($search))?" OR ":"")."post_content LIKE '%$shortcode%'";
 
  $query = "SELECT ID,post_title,post_name,post_content FROM $wpdb->posts WHERE $search AND post_type='page'";
  $result = $wpdb->get_results($query);
 
  return array('id' => $result[0]->ID, 'title' => $result[0]->post_title, 'name' => $result[0]->post_name, 'uri' => get_page_uri($result[0]->ID) );
}

Sedan läser du av den:

$pollSingle = locate_shortcode( 'poll_show_single' );  
$pollSingleURI = $pollSingle['uri'];

Då får jag fram vilken sida som innehåller shortcoden för att visa en enskild fråga, därefter kan jag haka in mig på filtret ‘wp’ och sätta titeln:

add_filter('wp', 'titles' );

I titels() kollar vi sedan upp om vi står på rätt sida (den som finns i $pollSingleURI) och jämför den med $wp_query->query['pagename']:

function titles() {
  global $wp_query, $wpdb, $newTitle, $pollSingleURI;
 
  // Single poll
  if ($wp_query->query['pagename'] == $pollSingleURI) {
    if (preg_match("/\d+\/?$/", $wp_query->query['page'])) {
      $pollID = str_replace('/', '', $wp_query->query['page']);
      $result = $wpdb->get_results( sprintf("SELECT subject FROM %spoll WHERE id = %d LIMIT 1", $wpdb->prefix, $wpdb->escape($pollID) ) );
 
      // Set title
      $newTitle = esc_html($result[0]->subject);
      add_filter('wp_title', 'frontend_set_title' , 10, 2 );
    }
  }
}

Ovanstående SQL-fråga hämtar just nu frågans titel, men detta ändrar du givetvis till det du vill ha som titel.

Och eftersom PHP fortfarande har lite problem med closures/anonyma funktioner så måste titeln sättas separat:

function frontend_set_title($title, $separator) {
  global $newTitle;
  return esc_html($newTitle)." ".$separator;
}

Allt är ryckt ur en klass för att lättare kunna visa hur det fungerar, därav alla globala variabler *urk*. Denna metod kräver inga ”rewrites” eller ”template redirect intercepts”.

Kod:

add_filter('attachment_fields_to_edit', 'enable_media_id', 10, 2);
function enable_media_id( $form_fields, $post ) {
    $form_fields["enable-media-id"] = array("label" => "MediaID", "input" => "html", "html" => "<p>".$post->ID."</p>");
 
    return $form_fields;
}

Bild på hur det kommer se ut:

(Jag såg idag att någon hade önskat denna funktionaliteten på WordPress.org -> Ideas)

Jag nämnde i mitt senaste inlägg kring Shopp att en alpha-version skulle dyka upp ganska kort efter att det postades. Den har dykt upp för ganska länge sedan och det ser riktigt bra ut, det som har fått mycket fokus är baksidan, alltså källkoden, det gör att det inte är några jättestora förändringar utseendemässigt. Det är förvisso lite enklare att hitta i orderdetaljerna och en andra småsaker.

Något som jag trivs riktigt bra med är hanteringen av betalningsmodulerna, jag var med Jonathan Davis (huvudutvecklare) en kväll och vi gjorde i ordning Payson-modulen så den är kompatibel med 1.1. Jisses vilken skillnad i kod jämfört med den tidigare versionen 1.0.x.

Momssatser för specifika kategorier är även det möjligt, men det är lite finputsning på det kvar innan den fungerar klockrent.

Så, när kommer den?

Det som just nu tar tid är QA-delen, att se till att allting funkar. Det har varit lite dåligt med testning från min egen sida, men jag räknar med att sätta igång ordentligt någon gång under nästa vecka. Det nämndes i en videointervju med Jonathan att de siktade på slutet av juni, men det är flytande.

Payson-betalningsmodul

Det finns en betalningsmodul för Payson att köpa som tillägg i Shopp. Jag är inte ansvarig för utvecklingen av den, det sköter Ingenesis Ltd (företaget bakom Shopp), däremot så har jag hjälpt till i utvecklingen.

Det har även kommit till min kännedom att det finns ex. rabatter inte fungerar fullt ut, vi får se ifall Ingenesis Ltd väljer att åtgärda dessa innan 1.1 (se mer nedan).

Svenska översättningen

Jag underhåller och uppdaterar för närvarande den svenska översättningen av Shopp. Hittar ni någon översättning som inte stämmer eller någon som saknas någonstans i systemet, [intlink id="8" type="page"]kontakta mig[/intlink] så ska jag försöka ordna det.

Shopp 1.1

Jag är med i beta-teamet för Shopp, det innebär att jag hjälper till att hitta buggar och kan lägga in förslag på nya funktioner. Det var tänkt att det skulle bli en 1.0.18 av Shopp,  men den idén har slopats och de kommer att satsa på 1.1 Jag vet inte när 1.0.18 kommer. Förhoppningsvis dyker en alpha-version upp ganska kort (~1 vecka).

Några av nyheterna i 1.1

• Ny hantering av betalningsmoduler/fraktmoduler
  Systemet som finns just nu för att skriva egna betalningslösningar/fraktmoduler är rent ut sagt obegripligt. Det kommer att ändras till det bättre och förhoppningsvis bli riktigt bra!
• Moms
  Just nu finns det inga möjligheter att sätta specifik moms på vissa produkter, det kommer förhoppningsvis att komma med i 1.1
• Sessionshantering
  I dagsläget är det ganska rörigt att hålla koll på sessioner som skapas i Shopp och WordPress. Drömmen vore ifall WordPress implementerade ett eget system som andra tillägg kan ”hooka” in sig på, men jag har inte sett något om det på deras tidsplan.

Ni kan läsa tidsplanen i sin helhet på Shopps webbplats: Beta_Team:Roadmap

WYSIWYG

Snarare: WYSIWTF (What You See Is WTF). Den ursprungliga idén med editorn var att förhindra att folk la in komplexa HTML-stycken, men just nu begränsar den alldeles för mycket. Den fungerar för den vanliga användaren, men så fort jag försöker göra något utöver det vanliga får jag ta till lite knep och knåp för att få det att fungera.

Standardinstallationen

Då WordPress är en så pass populär mjukvara så gör det att många WordPress-installationer blir mål vid en eventuell säkerhetslucka. Om denna säkerhetslucka utnyttjar något som ingår i standardinstallationen (ex: databasprefix eller administratörskontot) så är många illa ute.

Saker jag gör vid en nyinstallation:

• Ändrar databasprefixet
• Byter administratörskontots användarnamn
• Flyttar ut wp-config.php utanför WordPress-katalogen (oåtkomlig)
• Ser till att rättigheterna på katalogerna stämmer
• (Tema) Tar bort WordPress versionsnummer i head-taggen.

Jag skulle även gärna vilja byta ut alla hänvisningar till WordPress-kataloger på webbplatsen (ex: wp-content), just nu är det för mycket meck för att detta ska vara hållbart. Mycket av ovanstående saker borde användaren tvingas göra vid installationen (möjligt att detta försämrar WordPress ”välkänt” korta installationstid).

Sidhantering och menylistning

Just nu är sidhanteringen ohållbar, för att få menyobjekt att hamna i den ordning jag vill utan att hålla koll på prioriteten så krävs ett tillägg som ex. pageMash.

Det finns heller ingen chans att utesluta sidor i administrationen utan det görs manuellt via wp_list_pages() eller ett plugin som Page Lists Plus (där jag även kan vilja vilket namn som ska synas i menyn).

Javascript

Bättre möjligheter för att få kontroll över vilka Javascript och stilmallar som köas. Jag skulle vilja ha möjlighet att bunta ihop dessa till en fil. Mycket av ansvaret för att köa filer ligger på tilläggsutvecklare, många lägger in dessa manuellt utan att köa dem.

Några småsaker

• Det finns ingen möjlighet till intern länkning. Ex: RB Internal Links
• ”Custom fields” – bättre möjligheter för att lätt kunna skapa olika typer av mallar där fördefinerade fält enkelt kan fyllas i (dålig förklaring?).
• Page vs Posts – Blir alldeles för krångligt så fort jag försöker kombinera två loopar, suck…

Sammanfattning

Jag hoppas att många av dessa saker ordnas i WordPress 3.0, det mesta av detta går att lösa genom att använda tredjeparts-tillägg. Jag tror att dessa saker skulle gå att lägga in i kärnan utan att göra den bloatad eller att krångla till det för mycket för slutanvändaren.

Trots ovanstående ”brister” så gillar jag WordPress och projektet utvecklas åt rätt håll känns det som.

(Ovanstående lista är skriven med fokus på WordPress som CMS, inte bloggverktyg)