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

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)

PHPSidan startades av mig och Björn Enochsson i högstadiet (2002) som ett roligt projekt, främst för att jag ville lära mig PHP bättre. På den tiden höll jag på med ASP (Classic) och hade precis börjat titta på PHP. Namnet PHPSidan kommer ifrån den kända ASPsidan.

I början driftade jag PHPSidan på en server som jag hade hemma hos mina föräldrar i Orsa, efter ett tag så växte sidan sig allt för stor för att jag skulle vilja drifta den på en ostabil 0.5 Mbit/s -lina. Därefter fick vi sponsring från lite olika håll innan vi till slut hamnade hos Loopia.

Så, vad hände sen?

Väldigt mycket (de första åren), sen blev det mindre och mindre tid över till PHPSidan från både mitt och Björns håll. Om jag inte minns fel så var det 2006 vi släppte PHPSidan version 6, därefter gjorde vi många försök för att få klart en helt ny version som skulle passa våra (och hela webbens) nya behov bättre. Men på grund av tidsbristen så blev aldrig den nya versionen riktigt klar.

En av mina personliga anledningar till att PHPSidan aldrig färdigsställdes, var att jag blev mer och mer övertygad om att de engelska resurserna som fanns (finns) är så mycket bättre än det vi kan publicera. Därför kände jag aldrig det personliga behovet av att göra allt det som de gjorde, fast på svenska.

Nu då?

Efter en lång tids velande så tog vi beslutet att lägga ner PHPSidan. Besökarantalet på sidan har sakta men säkert dalat. Jag bestämde att jag inte ville att någon skulle ta över PHPSidan och driva vidare den. En av anledningarna till det beslutet är att domänen fortfarande används aktivt av mig. Att låta någon ta över en viss ”del” av domänen, men att jag får behålla någon slags kontroll över eposten kändes inte riktigt rätt mot den personen, den personen skulle nog aldrig kunna satsa 110% på PHPSidan utan fullständig kontroll över domänen.

Jag antar att jag samtidigt på något sätt ville att PHPSidan v7 skulle göras på ”mitt” sätt.

PHPSidan har betytt enormt mycket för mig personligen, jag har fått vänner som jag fortfarande har kontakt med och träffar aktivt. Jag har fått höra från många andra att PHPSidan har betytt väldigt mycket och fått dem att börja med programmering.

Strax innan nedläggningen så startade några på PHPSidan upp PHP Sverige, jag hoppas att många hittar dit och att de gör något riktigt bra av den sidan. Några andra webbplatser ni kan besöka ifall för PHP-relaterade ämnen är W3sidan och PHPportalen. Det är fortfarande aktivitet på IRC-kanalen #phpsidan på Quakenet ifall ni känner för att prata med någon av oss.

Summan av kardemumman

Tack för denna tid allihop, hoppas vi hörs på andra diskussionsforum och om inte annat så hör gärna av er till mig för att snacka webb. Stort tack till Loopia för att ni har tagit hand om oss så länge!

Nostalgitripp

Här kan vi se olika utseenden som PHPSidan haft under åren som gått. Ni kan även se några av de tidiga konceptbilderna på version 7.

Uppdatering 2010-08-23

Jag får en del frågor där folk vill ha tillgång till artiklarna och scripten som fanns på PHPSidan för att publicera dessa på sin egen webbplats. Detta går tyvärr inte, eftersom personerna som skrev artiklarna och laddade upp scripten gjorde detta till PHPSidan, jag har ingen rätt att distribuera dessa vidare.

En irriterande sak med många tillägg är hur deras Javascript läggs till, en bra tumregel är att alltid ladda Javascript i sidfoten. För att åstadkomma detta så ska det sista argumentet i wp_enqueue_script vara satt till true.

Så om ni har tid över kan ni försöka uppmärksamma tilläggsutvecklarna som inte gör på detta sätt på problemet.

Ett litet bekymmer som brukar uppstå är även att tillägg som är beroende av jQuery tvingar detta att ladda i sidhuvudet (innan wp_head() ), detta kan du komma runt genom att göra ett litet ”fulhack” i din functions.php.

// May have to be changed in future depending on jquerys directory
if (!is_admin())
    wp_enqueue_script('jquery', get_option( 'siteurl' ).'/wp-includes/js/jquery/jquery.js','','',true);

Vi är tvungna att se till att jQuery laddas som vanligt i administrationen, därav is_admin().

I övrigt så är WordPress ganska smidigt att jobba med (så länge du inte försöker göra saker WordPress inte riktigt är tänkt för), akta dig för att aktivera för mycket tillägg bara. Det kan bli en hel del anslutningar för att hämta diverse Javascript och CSS-filer.

För de Javascript och CSS ni lägger till själv kan jag iaf rekommendera WP-JS och WP-CSS för att slå ihop och komprimera dessa.