Petit truc très utile si jamais vous disposiez d’un serveur mutualisé hébergeant plusieurs sites et que vous souhaitiez – par exemple – augmenter le POST_MAX_SIZE pour un de vos clients afin de lui permettre de téléverser des photos de haute qualité via l’admin de WordPress.

–

À la racine de votre dossier public, ajoutez un .htaccess contenant :

suPHP_ConfigPath /home/public_html/

et au même endroit, un fichier nommé php.ini contenant les configs à surpasser (override), par exemple:

upload_max_filesize=10M
post_max_size=10M
max_execution_time=200
max_input_time=200

–

MÀJ : Merci au collègue Éric qui me souligne au passage la nécessité d’avoir installé le module suPHP pour que cette astuce fonctionne.

Vous le savez sûrement, WordPress s’amuse souvent à modifier certains caractères de vos textes par des entités html/unicode ou même d’autres caractères qu’ils juge équivalents. C’est pire encore si vous êtes un adepte du copier/coller pour remplir le formulaire de publication.

C’est surtout vrai pour les apostrophes…

Pour régler ça une fois pour toutes il vous suffit d’ajouter ces quelques lignes au fichier functions.php de votre thème :

// IMPORTANT : j'ai dû 'casser' les entités avec un espace pour qu'elles s'affichent correctement
// n'oubliez donc pas de les enlever pour que le script fonctionne (ex: & #2019 devient &#2019)

function cleanApostrophes($content)
{
	$content = str_replace(array("'","`","’", "& 146;", "& #2019;", "& #8217;", "& apos;", "& amp;apos;","& #039;"), "'", $content);
	return $content;
}
add_filter('the_title', 'cleanApostrophes');
add_filter('the_content', 'cleanApostrophes');
add_filter('the_excerpt', 'cleanApostrophes');

Avec ça, ciao bye pour les apostrophes étranges et les conversions douteuses dans les titres (the_title), le contenu (the_content) et les résumés (the_excerpt).

Évidemment vous pouvez modifier la fonction à votre gré pour ajouter d’autres règles de remplacement…

Je suis tombé sur ça ce matin.

http://fr.html5boilerplate.com/

Vraiment intéressant comme base d’expérimentation pour HTML5.

Vivement des temps libres pour que je puisse m’amuser avec ça un peu…

–

AJOUT :

Y a aussi le pendant mobile de ce truc.

http://html5boilerplate.com/mobile/

Vraiment incroyable!

Voici un petit bout de code très utile que j’ai développé afin de permettre très simplement de gérer des billets s’affichant sur plusieurs colonnes via l’interface de WordPress.

Pour ce faire, j’ai choisi d’utiliser à mon avantage le séparateur d’introduction, à savoir la balise <!–more–> qui s’insère facilement en cliquant sur le bouton de l’éditeur.

Ainsi, le script suivant permet de détourner son utilisation pour enrober chaque élément de contenu séparé par <!–more–> d’un DIV permettant ultimement d’afficher le tout sur plusieurs colonnes.

Lire la suite »

Bon! Après je ne sais pas combien d’heures passées à chercher une solution, voilà comment j’ai réussi – ridiculement simplement – à corriger un bug qui semble affecter beaucoup d’utilisateurs d’une version de Windows 64 bits (Vista ou Seven).

Le problème en question faisait en sorte qu’à chaque fois que j’essayais de mettre à jour iTunes et Quicktime, je me retrouvais avec ce message d’erreur :

Cependant, Windows Installer fonctionne sans aucun problème pour tous les types d’installation. Donc pour installer iTunes, je n’avais pas d’autre solution que de faire une image de mon filesystem, formater l’ordi et réinstaller Windows. Je réussissais donc à avoir la dernière version d’iTunes sur une « fresh install » mais rien d’autre. VRAIMENT frustrant…

Or j’ai tout essayé pour corriger ce problème. TOUT.

J’ai testé au moins 50 solutions suggérées çà et là sur divers forum sans succès… jusqu’à ce que je tombe sur ce billet qui m’a littéralement sauvé la vie. Voici donc comment faire pour régler ce fâcheux problème :

1) Du menu DÉMARRER, exécutez « regedit »

2) Naviguez jusqu’à  :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msiserver

3) Vous devriez voir quelque chose ressemblant à ça :

4) Faites une sauvegarde de votre base de registre (juste au cas)

5) Cliquez sur la clé « WOW64″ et attribuez-lui la valeur 0 plutôt que 1

6) Redémarrez l’ordi

7) Lancez l’installation d’iTunes (avec succès!)

… bonne vie!

Voici comment – après quelques heures de bidouillage – j’ai pu arriver à intégrer correctement le bouton Facebook Like dans le flux d’activités de BuddyPress.

Ce qu’il faut savoir c’est que le loop de BP nous renvoie un tableau assez volumineux contenant toutes les entrées du flux d’activités sans égard à son type (à moins que l’utilisateur ait fait sélectionné une méthode de tri).

Ainsi, chaque type (mise à jour, inscription à un groupe, publication sur un forum, etc.) a sa propre façon de gérer ses URLs et cette dernière n’est malheureusement pas passée en argument dans le Loop : il faut donc la construire.

Le bout de code qui suit ajoutera automatiquement le iFrame de vote pour Facebook à la droite des boutons de réponse en se suppléant au marqueur do_action(‘bp_activity_entry_meta’); présent dans le thème par défaut à l’endroit souhaité.

Vous remarquerez que personnellement, j’ai choisi d’exclure du processus (en ne leur attribuant pas d’URL) les types tels que : joined_group, new_member, friendship_accepted, et friendship_created pour une raison évidente : on s’en fou de signaler notre intérêt (like) pour ces éléments!!

Voici donc quoi ajouter dans le fichier functions.php de votre thème BuddyPress :

<?php
/*
 * FACEBOOK LIKE
 *   ajouter le bouton Facebook Like dans le flux des activités
 *   utilise le listener 'bp_activity_entry_meta' du thème par défaut de BP
*/

add_action( 'bp_activity_entry_meta' , 'facebookLikeActivity');
function facebookLikeActivity()
{
	global $bp,$activities_template;
	// si objet inexistant
	if(!is_object($activities_template)) return;
	// current ID
	$id = $activities_template->current_activity;
	// trouver le bon lien
	switch($activities_template->activities[$id]->type) {
		case 'activity_update' :
			$link = $activities_template->activities[$id]->primary_link;
			$link .= 'activity/' . $activities_template->activities[$id]->id.'/';
			break;		
		case 'new_forum_topic' :
		case 'new_blog_comment' :
		case 'new_blog_post' :
		case 'new_forum_post' :
			$link = $activities_template->activities[$id]->primary_link;
			break;
		case 'created_group' :
			preg_match_all('/href="([^"]*)"/i', $activities_template->activities[$id]->action, $matches);
			$link = $matches[1][1];
			break;
		case 'joined_group' :
		case 'new_member' :
		case 'friendship_accepted' :
		case 'friendship_created ':
		default :
			$link = NULL;
			break;
	}
	//ajouter le bouton
	if($link) : ?>
        <iframe src="http://www.facebook.com/plugins/like.php?href=<?php echo urlencode($link); ?>&amp;layout=button_count&amp;show_faces=false&amp;width=90&amp;action=like&amp;colorscheme=light&amp;height=21" scrolling="no" frameborder="0" style="position:relative;top:7px;border:none; overflow:hidden; width:90px; height:21px;" allowTransparency="true"></iframe>
    <?php endif;
}
?>

Voici un petit bout de code jQuery bien utile pour convertir tout lien pointant vers une image à une miniature de celle-ci pointant vers l’originale. Très utile pour un blogue ou un forum!

//set image max width
imgMaxWidth = 150;
//define regex pattern to detect images
regexImg = /^http:\/\/(.)+\.(jpg|jpeg|gif|png)$/gi;
//parse links
$('DIV.activity a').each(function(){
	//if a link points to an image
	if($(this).attr('href').match(regexImg)) {
		//add classes
		$(this).addClass('fetchedImgLink');
		//edit target
		$(this).attr('target', '_blank');
		//show image instead of text
		$(this).html("< img class='fetchedImg' src='" + $(this).attr('href') + "' />");
		//check for size
		var currentImg = $(this).find('img');
		var iw = currentImg.width();
		var ih = currentImg.height();
		var ratio = (ih!=0) ? iw/ih : 1;
		//resize if needed
		if(iw > imgMaxWidth) {
			currentImg.width(imgMaxWidth);
			currentImg.height(ih - ((iw-imgMaxWidth) / ratio));
		}
	}
});

J’expérimente Buddypress depuis quelques jours avec les configurations suivantes :

• WordPress single install 2.9.2
• Buddypress 1.2.3
• Buddypress Multilingual 1.0.0
• Sitepress Multilingual WPML 1.7.3

Le but est donc d’avoir un environnement multilingue (via WPML) pour Buddypress sur une installation unique de WP (et non WPMU). Le problème? C’est que ça ne fonctionne pas. En tout cas, ça ne fonctionne pas bien puisque les URLs ne sont pas réécrites correctement pour faire passer le paramètre de langue.

J’ai trouvé sur le forum officiel de WPML que leur traduction, avec le plugin Buddypress Multilingual servant de pont avec le CMS, ne fonctionne que si Buddypress est installé sur la version WPMU (multi-users) de WordPress, et qu’ils ne prévoient pas de soutenir la compatibilité pour la single install considérant qu’en version 3.0, WordPress intègrera les composantes multi-utilisateurs.

Alors en attendant on fait quoi?

Un peu de javascript…

Voici donc ma recette pour – temporairement, le temps que WP 3.o émerge en mai prochain – forcer l’insertion du paramètre de langue dans toutes les URLs d’un site tournant sous Buddypress.

1) Il faut s’assurer que le plugin WPML est configuré de sorte que le paramètre de langue soit passé en query string, du genre : http://monsite.com/buddypress/article?lang=en et non la formule par défaut.

2) Ensuite on ajoute ce bout de code nécessitant jQuery :

//set image max width
imgMaxWidth = 150;
//define regex pattern to detect images
regexImg = /^http:\/\/(.)+\.(jpg|jpeg|gif|png)$/gi;
//parse links
$('DIV.activity a').each(function(){
	//if a link points to an image
	if($(this).attr('href').match(regexImg)) {
		//add classes
		$(this).addClass('fetchedImgLink');
		//edit target
		$(this).attr('target', '_blank');
		//show image instead of text
		$(this).html('');
		//check for size
		var currentImg = $(this).find('img');
		var iw = currentImg.width();
		var ih = currentImg.height();
		var ratio = (ih!=0) ? iw/ih : 1;
		//resize if needed
		if(iw > imgMaxWidth) {
			currentImg.width(imgMaxWidth);
			currentImg.height(ih - ((iw-imgMaxWidth) / ratio));
		}
	}
});

Ce que ce code fait, c’est qu’il détecte si on est dans une version linguistique autre que celle par défaut (donc on a un paramètre de langue initialement). Si tel est le cas, le paramètre est ajouté à chaque lien de la page, mais pas à ceux de la boîte de sélection de langue de WPML (DIV#lang_sel).

Et ça dépanne, en attendant.

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?