Voilà que je me bute à un problème : réussir à attacher à la fenêtre de Safari un menu de navigation rappelant une application iPhone.

Rien de plus facile avec la propriété CSS position:fixed; n’est-ce pas?

Eh bien non justement. Et pourquoi donc?

Parce qu’Apple, dans sa version mobile de Safari uniquement, a décidé de ne pas supporter cette propriété question d’empêcher quiconque (moi en particulier) de faire un site mobile qui ressemblerait trop à une Application.

Autre solution : créer deux zones (#content et #footer) qui se partagent la fenêtre du iPhone (320×240). On positionne le #footer collé au bas, le #content prend le reste de la hauteur et on lui ajoute un overflow:auto; pour permettre la navigation dans le conteneur principal. Rien de plus simple encore une fois, mais est-ce que ça fonctionne?

NON PLUS!

Encore une fois, notre ami Safari Mobile empêche la navigation à l’intérieur d’un DIV avec overflow:auto; autrement qu’en utilisant ses 2 doigts pour faire le défilement. Pratique et intuitif non? D’ailleurs je gage vous ne le saviez même pas…

Mon prochain test sera de passer par un IFRAME, mais vous vous doutez certainement que je n’en ai pas du tout envie de m’aventurer là-dedans…

–

Comme solution alternative existe cependant ce script très intéressant que j’ai déniché et qui émule les actions de navigation en javascript. Toutefois ce dernier donne une expérience utilisateur plutôt désagréable et très saccadée.

–

Il y a toutefois un peu de lumière au bout du tunnel avec jQTouch, une librairie HTML5 reprenant toutes les animations et interfaces propre au iPhone dans une version compatible avec le webkit mobile.

Reste à voir si ça marchera correctement.

Mais dans l’intervalle Apple, je suis extrêmement déçu.

Voilà une excellente nouvelle que cette annonce à l’effet que BuddyPress pourra maintenant rouler comme un plugin de Wordpress, et n’aura plus (nécessairement) besoin de Wordpress MU.

J’ai toujours été extrêmement septique à l’endroit de MU – dont on annonce déjà la mort lors du passage en version 3.0 de WP – et de savoir qu’on pourra utiliser les fonctionnalités incroyable de BuddyPress sur une installation simple m’emballe.

Amis développeurs, avez-vous eu l’occasion de le tester un peu?

J’aime toujours les trouvailles de Smasing Magazine et celle-ci ne fait pas exception à la règle.

Voici donc une série d’images vectorielles pour agrémenter vos designs pour la période des fêtes.

Les chanceux qui auront pour tâche de réaliser la carte de Noël du bureau auront donc l’air un peu plus brillants et/ou un tantinet moins crevés lors de la conception.

–

Voici en bonus quelques références pertinentes pour :

• créer un sapin de Noël dans Illustrator
• créer un (autre) sapin de Noël, mais dans Photoshop cette fois

Et finalement, voici 60 tutoriels pour créer des éléments de design du temps des Fêtes.

Le thème P2 de Wordpress – qui émule l’interface d’un hybride Twitter/Facebook imaginaire – vient enfin d’être corrigé de [la plupart de] ses nombreuses faiblesses.

La principale lacune était au niveau de son intégration à un environnement déjà existant. Jadis, un site voulant l’utiliser devait s’en contenter puisque sa surcharge de scripts et la lourdeur de son code le rendait VRAIMENT trop complexe/long/impossible à extraire et à insérer dans un autre thème. Impossible donc de se créer une section « P2″ fonctionnant parallèlement à un blogue traditionnel évoluant sur la même installation de Wordpress. C’est maintenant corrigé :

We also decided to go a step further and rework P2 so that it could easily be used as a parent theme and extended with child themes. This will allow theme designers to create awesome new theme designs without having to duplicate all of the existing P2 features.

De plus, de nouvelles options s’offrent à nous au niveau de la personnalisation du thème via l’admin de Wordpress, de même que la venue de nouveaux types attribuables au contenu qu’on y envoie : status, billet de blogue, citation ou lien externe. Pas bête!

Je ne penserais pas renvoyer ce blogue sur P2, mais pour se monter une sorte de HUB SOCIAL, ça m’apparait être vraiment une avenue à considérer…

- Merci à Carl pour le tuyau.

Y a du beau, très beau thème ici…

Merci encore, Smashing Magazine!

Voici une petite astuce qui vient bien compléter mon script pour raccourcir une URL avec l’API de http://bit.ly.

Tout ceci part avec l’API de Tweetmeme cette fois, laquelle permet d’obtenir le nombre de fois qu’un billet de votre blogue a été affiché sur Twitter soit en insérant leur nom dans le tweet (@tweetmeme) ou encore en ayant passé par http://bit.ly pour raccourcir l’URL (les deux entités partagent leurs données).

Il suffit tout simplement de récupérer les données XML issues de cette ressource : http://api.tweetmeme.com/url_info?url=##votre-URL##, ce qui renvoie quelque chose ressemblant à ceci :

<result>
	<status>success</status>
	<story>
		<title>Google Wave : et si… / Publicité | Gérant d'estrade</title>
		<url>http://www.estrade.ca/blogue/web/reseaux-sociaux/google-wave-et-si.html</url>
		<media_type>news</media_type>
		<created_at>2009-11-09 20:34:54</created_at>
		<url_count>1</url_count>
		<tm_link>http://tweetmeme.com/story/264195236</tm_link>
		<comment_count>0</comment_count>
		<excerpt>
			Sur mon blogue : Google Wave : et si… http://bit.ly/10xaQW
		</excerpt>
	</story>
</result>

Pour le récupérer très simplement (avec PHP 5) vous pouvez utiliser cette fonction, à ajouter dans la page functions.php de votre thème :

function tweetCount($url) {
	$fichier = file_get_contents("http://api.tweetmeme.com/url_info?url=".$url);
	$xml = new SimpleXmlElement($fichier);
 	echo 'Ce billet a <a href="'.$xml->story->tm_link.'" target="_blank">'.$xml->story->url_count.' tweets</a>!';
}

Ensuite dans votre thème – probablement dans la page single.php pour affecter uniquement les billets – ajoutez un simple appel à la fonction en passant votre permalien en paramètre :

tweetCount($post->permalink);

Ceci affichera le nombre de tweets contenant l’URL en même temps qu’un lien pour les consulter.

Un petit truc bien utile découvert aujourd’hui pour modifier les informations utilisées dans vos fils RSS de Wordpress.

En fait, je n’ai jamais compris pourquoi on ne pouvait pas modifier le format des fils RSS avec une page d’un thème et que tout était bien ancré dans le coeur de WP ( dans /wp-includes/feed-rss2.php)… mais bon, j’ai constaté que c’était presque aussi simple de le faire avec un hook dans le fichier functions.php de votre thème préféré.

Pour ce faire, il suffit d’ajouter les fonctions de modification suivantes pour chacun des éléments à modifier :

function nouveau_titre_RSS() {
	$txt = get_the_title();
	return $txt . ' / estrade.ca';
}
function nouveau_texte_RSS() {
	$txt = get_the_excerpt();
	return $txt . '<br /><br />Plus de nouvelles sur <a href="http://estrade.ca/">estrade.ca</a>';
}

Ensuite, vous appelez ces filtres et les appliquez aux routines d’affichage du fil RSS :

add_filter('the_excerpt_rss', 'nouveau_texte_RSS');
add_filter('the_title_rss', 'nouveau_titre_RSS');

Dans cet exemple, on ne fait qu’ajouter un peu de texte aux éléments TITLE et DESCRIPTION d’un fil RSS… mais vous voyez un peu tout ce qui peut être possible de faire avec ça!

Voici un truc tout simple pour créer autant de barres latérales (sidebars) que vous le souhaitez, afin de les équiper de widgets et les afficher dans diverses sections.

Ça devient très utile quand, par exemple, on veut créer une sidebar différente pour une page d’accueil (index.php), une page d’accueil de catégorie (archive.php) et un article seul (single.php).

Tout d’abord, il faut initialiser les barres latérales. Dans le fichier functions.php ajoutez :

if ( function_exists('register_sidebar') ) {
	register_sidebar(array(
		'name' => 'Droite - Accueil',
		'before_widget' => '<div id="%1$s" class="widgetContainer %2$s">',
		'after_widget' => '</div>',
		'before_title' => '<h3 class="widgetTitle">',
		'after_title' => '</h3>'
	));
	register_sidebar(array(
		'name' => 'Droite - Billet',
		'before_widget' => '<div id="%1$s" class="widgetContainer %2$s">',
		'after_widget' => '</div>',
		'before_title' => '<h3 class="widgetTitle">',
		'after_title' => '</h3>'
	));
	register_sidebar(array(
		'name' => 'Droite - Categorie',
		'before_widget' => '<div id="%1$s" class="widgetContainer %2$s">',
		'after_widget' => '</div>',
		'before_title' => '<h3 class="widgetTitle">',
		'after_title' => '</h3>'
	));
}

Vous verrez donc à ce moment les trois barres latérales apparaître dans le panneau d’administration, sous Apparence / Widgets.

Par la suite, il suffit d’inclure la bonne barre latérale dans le bon contexte. Pour ce faire, créez – si ce n’est pas déjà fait – un fichier sidebar.php contenant ceci :

if(is_home()) {
	//accueil
	if (function_exists('dynamic_sidebar')) dynamic_sidebar('Droite - Accueil');			
} elseif( is_category('nom-categorie') ) {
	//catégorie spécifique
	if (function_exists('dynamic_sidebar')) dynamic_sidebar('Droite - Categorie');
} elseif( is_single() ) {
	//dans un billet
	if (function_exists('dynamic_sidebar')) dynamic_sidebar('Droite - Billet');
}

Je profite de cette tribune pour vous poser une question :

Avez-vous déjà trouvé (ou mieux, réalisé) des études de cas ou études comparatives traitant de mise en cache pour un blogue roulant sous Wordpress?

Je viens d’installer WP Super Cache sur quelques sites à fort trafic, la réponse côté serveur semble très bonne, mais je ne sais pas si cette solution est la plus optimale possible. Il y a tant d’alternatives (à commencer par DB Cache qui m’intrigue, ou encore W3 Total Cache qui paraît toutefois un peu instable) que je peine à me brancher définitivement.

Aussi, ces plugins comportent nombre de configurations (mise en cache de toutes les pages, uniquement pour les visiteurs non-connectés, définition de zones dynamiques, etc.) et je voulais chercher à savoir si des configurations optimales existent pour maximiser le bien-être de la machine autant que du visiteur.

Alors?

Une idée? Un témoignage? Une référence?

Voici un petit tutoriel pour expliquer comment – très simplement – mettre une page dynamique en cache pour en accélérer l’affichage et limiter les ressources côté serveur (apache et mysql).

Premièrement, suffit de créer deux fonctions. La première – debut_cache() – testera l’existence d’un fichier cache récent pour l’affichier, ou initialisera le buffer et débutera la mise en cache du contenu. La deuxième – fin_cache() – prend le contenu mis dans le buffer et va, suivant le besoin, écrire un fichier statique avec le contenu généré par le serveur qui sera alors repris par les requêtes suivants jusqu’à son expiration.

function debut_cache()
{
	global $cachedFile;
	if(CACHE > 0) {
		if (!isset($_POST) || count($_POST) == 0) {
			$hash = md5(serialize($_GET) . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']);
			$filename = basename($_SERVER['PHP_SELF'] . '.' . $_SERVER['HTTP_HOST'] . '.' . $hash . '.html');
			if (file_exists(CACHE_DIR . $filename) AND (time() - filemtime(CACHE_DIR. $filename)) < CACHE) {
				readfile(CACHE_DIR . $filename);
				exit();
			} else {
				$cachedFile = CACHE_DIR . $filename;
				ob_start();
			}
		} else $cachedFile = false;
	}
}
function fin_cache()
{
	global $cachedFile;
	if((CACHE > 0) AND $cachedFile) {
		$hoststr= getenv("HOSTNAME");
		$host = explode (".", $hoststr);
		$page = ob_get_contents();
		$page .= '<!-- Page mise en cache @ ' . date('Y-m-d H:i:s') . ' -->';
		ob_end_flush();
		if ($file = fopen($cachedFile, 'w')) {
    			fwrite($file, $page);
    			fclose($file);
    		}
	}
}

Juste avant de faire l’appel, il importe de définir deux variables (des constantes globales dans cet exemple).

//temps pour le cache (secondes)... 0 pour annuler la cache
define('CACHE', 60*15);  //15 min

//dossier de cache
define('CACHE_DIR', '/www/cache/');

Ensuite, on se lance :

//lancer la mise en cache
debut_cache();
//---------------------------------------------
//afficher normalement votre page ici
//elle sera mise dans le buffer
//---------------------------------------------

//afficher le contenu (du buffer ou du fichier mis en cache)
fin_cache();