Ce dont vous avez besoin

Configurer votre compte Amazon S3

Configurer Amazon S3 for WordPress

- Host name settings : cliquez cette option si vous voulez que l'adresse de vos images soit sous la forme images.nightangel.fr et non images.nightangel.fr.s3.amazonsomething.com. Toutefois, si vous optez pour cette option, il vous faudra mettre en place un CNAME sur votre domaine : nous verrons ça plus bas. - File Uploads : cochez cette case si vous voulez que tous les médias déjà envoyés sur WordPress soient copiés sur votre compte S3. Le plugin vous donne la possibilité de choisir un stockage sur votre serveur ou sur votre compte Amazon. - Expires Header : mise en cache des fichiers. - File Permissions : vous devez absolument vérifier les permissions sinon vos images ne seront pas accessibles au public. En effet, par défaut les fichiers envoyés sur votre compte Amazon S3 sont privés. Cette option vous évitera de devoir gérer les permissions de chaque nouveau fichier envoyé.

Facultatif : Virtual Host par CNAME

images.nightangel.fr. CNAME images.nightangel.fr.s3.amazonaws.com.

La version 3.0 de WordPress devrait faire son apparition au printemps et je sais que c'est avec impatience qu'un certain nombre d'utilisateurs attendent cette évolution. Pour l'instant le développement avance plutôt bien et il reste moins de 500 "bugs" à corriger alors que plus de 180 corrections sont déjà effectuées. L'état d'avancement se situe donc aux alentours de 30% et une mise à jour vers la 2.9.2 devrait être proposée ce mois-ci. La principale évolution de cette V3 réside dans le fait qu'elle supportera le multi-blogs (plusieurs blogs sur une seule installation) sans recourir à WordPress Mu. La version 2.9.x de Mu sera donc la dernière puisque WordPress Mu laissera le champ libre à WordPress 3.0 dès sa sortie.

La fonction get_author_template() est présente dans le fichier wp-includes/theme.php depuis assez longtemps (à compter de la v1.5 si je ne me trompe), elle a récemment été modifiée par westi (Changeset 12915) dans le cadre de la version 3. Alors tout ça c'est bien beau mais qu'apporte cette modification ?

Vous allez désormais pouvoir utiliser des fichiers de thème du type author-username.php ou author-id.php ; comme il est déjà possible de le faire avec les fichiers de thème des catégories : category-id.php. Concrètement, le fichier qui va gérer la "fiche-utilisateur" de "daffyduck" sera author-daffyduck.php ou author-14.php (si l'identifiant de l'utilisateur est 14). Vous allez ainsi pouvoir "designer" (ou "skinner") spécifiquement la "fiche" (ou "profil") de tel ou tel utilisateur. A noter que si vous utilisez le "username" dans le nom du fichier, il faudra bien prendre la valeur du champ "user_nicename" de la base de données ; et non la valeur du champ "user_login". Voilà et si vous voulez deux screenshots d'une partie de l'admin de la v3, c'est par ici que ça se passe.

Après de longs mois de développement, la version 2.9 (appelée Carmen McRae) de WordPress vient d'arriver dans les bacs et j'y vais donc de mon petit billet. J'avais déjà présenté rapidement les principales nouveautés mais je souhaite revenir plus précisément sur la fonction the_post_thumbnail();. Fonction que je n'ai pas encore eu le temps de documenter que ce soit dans le Codex US ou dans le Codex FR. Je vais donc remédier à ce manque ici avant de compléter la documentation officielle. Tout ce qu'il faut savoir sur la fonction the_post_thumbnail(); se trouve donc ci-dessous. N'attendez pas la version 3.0 (qui sortira théoriquement au printemps) pour vous mettre à la page !

Depuis WordPress 2.9, vous pouvez attribuer une (ou plusieurs) miniature(s) à un article. Pour afficher cette miniature, vous devez utiliser la toute nouvelle fonction the_post_thumbnail(); dans le fichier de thème de votre choix. Il est bien sûr possible d'utiliser la fonction brute comme je viens de la donner ou de lui passer des arguments pour modifier l'apparence de la miniature, son positionnement, sa taille, etc...

Déclarer que le thème supporte/utilise la fonction the_post_thumbnail();

Afin de pouvoir utiliser la fonction the_post_thumbnail(); dans vos fichiers de thème, il faut ajouter une ligne au fichier functions.php :

Appeler la miniature dans votre fichier de thème

Bon là rien de très compliqué, on ajoute cette ligne au fichier de thème et la miniature s'affiche :

Modifier sa taille d'affichage

Il est possible de passer 3 formats d'images à la fonction.

// the thumbnail
the_post_thumbnail('thumbnail'); 
 
// medium resolution
the_post_thumbnail('medium');
 
// large resolution
the_post_thumbnail('large');

Ces formats d'images sont directement liés à ceux que vous avez paramétré dans l'administration de votre blog (Réglages -> Médias).

Modifier son positionnement et appliquer une classe CSS

Il est possible d'attribuer une classe à la fonction afin que la photo soit alignée comme vous le souhaitez.

//  Photo alignée à gauche
the_post_thumbnail('thumbnail', array('class' => 'alignleft'));
 
//  Photo alignée à droite
the_post_thumbnail('thumbnail', array('class' => 'alignright'));
 
//  Photo centrée
the_post_thumbnail('thumbnail', array('class' => 'aligncenter'));
 
// Photo alignée à droite + classe personnalisée
the_post_thumbnail('thumbnail', array('class' => 'alignright ma_propre_classe'));

Afficher les miniatures dans un tableau

Les miniatures peuvent être affichées sous la forme d'un "tableau" en contrôlant leur taille.

// Miniature recadrée à 100x100 pixels
the_post_thumbnail(array(100,100), array('class' => 'alignleft'));

Les proportions (largeur/hauteur) de l'image sont toujours conservées, même si l'on spécifie d'autres valeurs. Dans le cas présent, si l'image originale fait 150x50 pixels, elle sera redimensionnée à 100x33 pixels.

Appeler les dimensions fournies dans l'administration...

Les concepteurs de thèmes peuvent rencontrer un problème puisqu'il ne peuvent pas prévoir à l'avance les valeurs qui seront définies par l'utilisateur. Une façon d'aborder ce problème étant d'interroger les valeurs pour les différentes tailles :

// Largeur des miniatures
get_option('thumbnail_size_w');
 
// Hauteur des miniatures
get_option('thumbnail_size_h');
 
// Largeur maximale de la taille moyenne
get_option('medium_size_w');

// Hauteur maximale de la taille moyenne
get_option('medium_size_h');
 
// Largeur maximale de la grande taille
get_option('large_size_w');

// Hauteur maximale de la grande taille
get_option('large_size_h');
 
//  Si la fonction retourne "1" comme valeur, le recadrage est activé aux dimensions exactes, sinon "0" et le recadrage (crop) est désactivé.
get_option('thumbnail_crop')

Modifier ces dimensions

 'alignleft')); /* On affiche la miniature avec ces nouvelles valeurs */
?>

Démonstration par l'exemple...

Concrètement, si la taille de la miniature excède 150x150 pixels et si le recadrage (crop) est activé, la miniature doit être recadrée à 150x150 pixels. Si la miniature n'excède pas 150x150 pixels alors on utilise la taille d'origine de la miniature.

 150 && get_option('thumbnail_crop') == 1) {
    the_post_thumbnail(array(150,150));
}else{
    the_post_thumbnail('thumbnail');
}
?>

Dernière précision !

Ne pas abuser de ce système car l'affichage d'une miniature génère deux requêtes vers la base de données.

J'aime pas Noël !

Autant se le dire tout de suite, WordPress 2.9 ne sortira pas dans l'heure qui vient. Je viens de jeter un coup d'oeil à la roadmap, l'équipe avance vite, même de plus en plus rapidement ces derniers jours. Sur plus de 495 tickets, 447 (90%) sont désormais clôturés et 49 (10%) sont toujours actifs. Toute l'équipe fait son possible pour sortir cette v2.9 assez rapidement, la seule chose de sûre étant qu'elle sera "dans les bacs" cette année et probablement dans la quinzaine qui arrive. En attendant, pendant que les Lead Developers (Matt, Ryan, Andrew, Peter et Mark) sont en train de se la couler douce à la WordCamp de Orlando, moi j'y vais de mon petit billet pour vous détailler les principales nouveautés qu'apportera cette version. Je vais jute évoquer les nouveautés que je juge pertinentes et en aucun cas les corrections et optimisations qui sont pourtant très nombreuses. Ready to go ?

Dans WordPress 2.9 Il y aura deux nouveaux filtres pour ajuster les extraits (the_excerpt). Jusqu'à maintenant, la fonction the_excerpt(); coupait à un maximum de 55 mots et ajoutait un [...]. Ces filtres sont paramétrables dans WordPress 2.9. Pour modifier les valeurs de ces filtres, il vous suffit de paramétrer deux fonctions dans le fichier functions.php de votre thème :

// Nombre de mots avant coupure
function new_excerpt_length($length) {
	return 40;
}
add_filter('excerpt_length', 'new_excerpt_length');
 
// Texte de la coupure
function new_excerpt_more($more) {
	return '...';
}
add_filter('excerpt_more', 'new_excerpt_more');

La v2.9 sera dotée d'un éditeur d'images. Il sera aisément possible de couper/cropper/rogner une image, la faire pivoter, etc... Je ne pense pas qu'il soit utile d'en dire davantage, tout étant dit ici.

Depuis l'administration de WordPress, lors de la rédaction d'un billet, vous allez pouvoir joindre une (ou plusieurs) image(s) principale(s) à ce billet ; ou plutôt une miniature. Les développeurs de thèmes pourront ensuite "appeler" cette miniature dans le fichier (de thème) de leur choix : généralement index.php mais pourquoi pas archives.php, etc...

Possibilité d'attacher plusieurs miniatures et affichage aléatoire.

Pour gérer cette miniature depuis votre thème, 4 nouvelles fonctions sont ajoutées :

La fonction has_post_image(); permet de vérifier s'il y a une miniature de rattachée à tel billet. On l'utilisera typiquement de cette manière :

	Afficher la miniature

La fonction get_post_image_id(); permet de récupérer l'identifiant (id) de la miniature.

La fonction the_post_image(); génère automatiquement les balises HTML pour afficher directement la miniature. Si on couple cette fonction avec has_post_image(); (vue plus haut), cela nous donne...

Cette fonction peut recevoir la taille de la miniature comme argument...

Il est aussi possible d'appliquer une classe (CSS) à notre miniature...

 'alignleft' ) ); ?>

La fonction get_the_post_image(); récupère l'url de la miniature, libre à vous de l'imbriquer à l'intérieur de balises img par exemple.

A noter que vous pouvez "vérifier" que la version de WordPress sur laquelle sera installé le thème supporte cette fonctionnalité. Pour cela une petite édition du fichier functions.php...

if ( function_exists( 'add_theme_support' ) )
	add_theme_support( 'post-thumbnails' );

WordPress 2.9 vous offre la possibilité de mettre à jour tous vos plugins, qui ont une mise à jour disponible, en une seule étape. Rien d'autre à ajouter à ce niveau là même si je n'ai jamais été très fan de ces mises à jour automatiques.

Un script de réparation de la base de données est désormais intégré à WordPress 2.9. Pour l'activer il suffit d'ajouter ceci au fichier wp-config.php :

define('WP_ALLOW_REPAIR', true);

Mettre false à la place de true pour désactiver ce script. Ce dernier (s'il est activé) peut être appelé "de l'extérieur" à l'adresse : http://example.com/wp-admin/maint/repair.php. N'attendez pas trop de miracles de ce côté là car le script ne fait qu'utiliser les instructions SQL ANALYZE TABLE, REPARI TABLE et OPTIMIZE TABLE.

Cette version 2.9 se voit dotée d'une poubelle qui vous évitera, peut être comme moi, d'avoir des tonnes de billets en "brouillon". Une fois dans la poubelle, un billet peut en sortir pour repasser en brouillon ou être supprimé définitivement : une poubelle quoi ! Attention tout de même car cette poubelle dispose d'une fonction de délestage. Sauf précision inverse, le contenu de la poubelle est supprimé après 30 jours. Alors il est bien sûr possible de modifier ce délai (réduction à 10 jours par exemple) en ajoutant la ligne suivante dans le fichier functions.php :

define( 'EMPTY_TRASH_DAYS', 10 );

Pour désactiver cette suppression automatique :

define( 'EMPTY_TRASH_DAYS', 0 );

Ouf... je pense que le tour est fait même si j'ai du oublier quelques trucs en chemin. L'impasse a volontairement été faite sur les liens (url) et les plugins canoniques (Canonical). Si je n'ai souhaité en dire davantage sur l'utilisation de l'attribut rel=canonical de la balise html "a", c'est parce qu'il s'agit d'un sujet qui fait débat, tant au sein de la communauté que de l'équipe de dev, et qui n'est toujours pas tranché à l'heure actuelle. Pour conclure je dirais que cette version apporte donc un flot de nouveautés non négligeables : bonne évolution ! Ceux qui s'attendaient à mieux peuvent toujours se joindre à nous ou prendre leur mal en patience et attendre 2010 pour la version 3.0. Bon blogging à tous !

PS : WordPress 2.9 beta 2 pèse 2.5Mo en version compressée (.zip) et 9.5Mo après décompression.

Cela fait maintenant plusieurs années que je publie du contenu sur différentes plates-formes de blogs et j'ai souvent été confronté à des problèmes typographiques. Je suis conscient d'avoir un problème d'ordre maladif entre l'orthographe et la typographie mais bon... chacun ses manies après tout ! Par ailleurs, dans le même ordre d'idée, et malgré ce billet dédié à l'intégration des smilies, je suis en train de revoir ma position puisque mon utilisation de ces derniers s'amenuise et tend peut être à disparaître. Mêler conjugaison et smilies ne me paraît pas toujours évident, mais ceci est un autre débat. Donc, revenons-en à nos moutons notre bonne vieille typographie et plus particulièrement aux guillemets et aux espaces insécables, qui de nos jours, pourraient même faire retourner Gutenberg dans sa tombe. Avec PHP SmartyPants Typographer, ne laissons pas WordPress prendre librement toutes les libertés typographiques qui lui conviennent : un guillemet («) n'a pourtant aucun rapport avec un guillemet-apostrophe double culbuté (“) ; mais allez savoir...

PHP SmartyPants Typographer

L'installation du plugin PHP SmartyPants Typographer vous permettra d'avoir une typographie bien meilleure. Un tiret court n'est pas un tiret long, les guillemets typographiques imposent des espaces insécables, etc... Pour en savoir davantage sur le plugin et sa méthode d'installation, je vous invite à découvrir le site officiel.

Guillemets

Sous Mac OS X (clavier français) Alt-7 et Alt Maj-7 donnent les guillemets français, Alt-3 et Alt-Maj-3 donnent les guillemets anglais.

Je ne vais bien sûr pas faire l'apologie des guillemets, ce serait bien trop long et moins évident qu'il n'y paraît. Juste un petit mot pour rappeler qu'en français, on emploie les guillemets typographiques ou français (« »), séparés de l’expression qu’ils mettent en exergue par une espace insécable (fine si possible). A priori, selon certains typographes, les guillemets anglais ( “ ” ) peuvent être employés, sans espace insécable, comme guillemets de second niveau et, en troisième niveau, on peut utiliser des apostrophes directement accolées à l’expression. Cependant en troisième niveau, l’usage de l’italique est préférable.

Espace et espace insécable fine

Pour les espaces, c'est un peu moins compliqué, encore que... Il existe deux espaces (certains diront trois, mais moi je dis deux) : une espace et une espace insécable fine. Oui oui on peut dire une espace. L'espace fine est tout simplement plus courte que l'espace traditionnelle. Elle est généralement insécable, c'est à dire qu'elle ne peut pas disparaître au profit d'un retour à la ligne par exemple. Vous imaginez bien "1 000 €" avec le "1" sur une ligne et le "000 €" sur une autre ? Non non, là il faut une espace insécable fine ! Et donc pour faire une espace insécable fine sous Mac OS X, il suffit de combiner les touches Alt + barre d'espacement. Sous Windows, je crois que c'est Maj + Ctrl + barre d'espacement ; mais à vérifier...

Un peu de lecture...

PS : Bien que le développement ne soit pas terminé, il est désormais possible de retrouver tous les billets du blog sous forme de calendrier : lien tout en bas à droite de la page d'accueil, au niveau du système de pagination.

Lorsque vous avez un blog et que vous jouez un peu avec, il vous prendra rapidement l'idée d'en avoir plusieurs cyp Un blog perso, un blog pro, et peut être même un blog "de test", et le tout probablement sur plusieurs domaines. Quand il s'agit de mettre à jour tous ces blogs (toutes vos installations de Wordpress), cela demande tout de suite beaucoup de travail et donc de temps :mad: Il serait tout de suite beaucoup plus facile de réaliser ces opérations de maintenance, si vous n'aviez qu'une seule et même installation de WordPress mais plusieurs bases de données connectées à cette même installation :roll: Voici donc comment avoir un WordPress multi-utilisateurs, ou plutôt multi-domaines si vous préférez. Cela n'est pas difficile à mettre en place, il suffit de suivre le guide : ACTION! :D

Choisir plusieurs domaines ou sous-domaines...

Nous allons donc avoir une seule installation de WordPress qui va supporter plusieurs domaines ou plusieurs sous-domaines. Il serait également possible de mixer les deux mais ne compliquons pas. Pour l'instant nous supposons que votre installation va supporter (ou accueillir) les domaines : www.domain1.com et www.domain2.com.

Installer WordPress (facultatif)

Vous installez une seule fois WordPress comme vous le feriez classiquement pour un seul site/domaine. Il s'agit bien sûr de l'installation qui va accueillir vos différents domaines. Cette opération est facultative puisque la modification suivante peut tout à fait être effectuée sur une installation existante.

Créer les autres bases de données

Comme vous avez un WordPress d'installé, vous avez déjà une base de données. Il va vous falloir autant d'autres bases de données que de noms de domaines supplémentaires. WordPress a besoin de vous pour créer une base de données vide. Si vous pointez sur un domaine dont la base n'est pas encore créé, WordPress va vous en informer et vous demander de sélectionner une base de données. Lorsque la base (vide) est trouvée, vous aurez l'écran de configuration.

Modifier le fichier "wp-config.php", ici la magie s'opère !

Dans le fichier de configuration wp-config.php on va déterminer quel domaine "appelle" l'installation et utiliser telle ou telle base de données en conséquence.

Il faut bien sûr remplacer domaine1 et domaine2 par vos domaines et database1 et database2 par les bases de données qui doivent être respectivement utilisées.

Nous supposons ici que toutes vos bases se trouvent sur le même serveur de bases de données ('DB_HOST') et que le même utilisateur ('DB_USER' et 'DB_PASSWORD') a les privilèges nécessaires sur ces mêmes bases. Si tel n'est pas le cas, libre à vous de modifier le script à votre guise. Par exemple :

Pour finir...

Pour être sûr que rien ne se mélange, vous devez effectuer une dernière modification dans le panneau d'administration de chaque domaine. Rendez-vous dans "Réglages" ("Options" en anglais) -> "Divers" ("Miscellaneous" en anglais) et changer le contenu du champ "Stocker les fichiers envoyés dans ce dossier" par wp-content/uploads/domaine. Remplacez bien sûr "domaine" par le nom de domaine correspondant. Cette modification évite que tous les fichiers que vous allez envoyer (uploader) ne soient stockés dans le même répertoire (uploads) alors qu'ils proviennent finalement de "différents blogs".

Informations complémentaires...

Cette méthode vaut ce qu'elle vaut mais elle a quand même le mérite d'exister. Il existe cependant d'autres méthodes plus ou moins performantes (souvent moins) et plus ou moins complexes (souvent plus). Disons que vous avez sous les yeux une méthode que j'ai testé, qui est "light" et relativement accessible. Au delà de ça il est toujours possible d'imaginer X autres solutions. On pourrait par exemple tout stocker dans une base de données mais ne compliquons pas les choses, il s'agit d'un tuto ! Quoiqu'il en soit, si ces autres méthodes vous intéressent, je propose aussi de lire Host multiple WP sites on one installation de LobsterMan et How to: multiple blogs, one Wordpress installation de Martijn Stegink. Si vous souhaitez comprendre un peu ce que font ces lignes de code, la documentation PHP pourrait également vous être utile.

Comme d'habitude, si vous avez besoin d'aide, des questions, des remarques, des suggestions ou juste envie de vous suicider, le système de commentaires est fait pour ça :razz:

Certains le savent déjà, d'autres non, et ça ne changera probablement pas leur vie, mais je suis notamment développeur WordPress. Je vais parler ici du côté communautaire et non lucratif de cette plate-forme. D'ailleurs il faudra que je revienne sur cet aspect lors d'un prochain billet car OUI il y a moyen de gagner de l'argent avec un CMS : c'est dit! Etant impliqué dans ce projet auquel j'accorde beaucoup de temps, je vais donc naturellement tenter de vous présenter succinctement WordPress et surtout ce que je fais au sein de cette communauté qui ne cesse de s'accroître.

WordPress qu'est ce que c'est ?

Je ne compte pas vous copier/coller une définition issue de fr.wikipedia.org ou de fr.wordpress.org. D'une part parce que les termes techniques employés dans la première n'intéressent finalement pas grand monde et d'autre part, parce que le jargon marketing de la seconde ne correspond pas à l'esprit de mon blog. Je vais donc y aller de ma petite définition à la truelle...

Et un p'tit historique succinct pour le côté familial...

Pourquoi WordPress ?

J'ai commencé à "bloguer" il y a une dizaine d'années, époque où ce terme n'existait pas :arrow: A vrai dire je n'avais pas même conscience de ce que je faisais, aucune plate-forme n'était prévue à cet effet et j'avais donc codé mon blog site personnel "à la main". C'était en 1998, j'avais tout codé en statique (HTML4) et ce n'est que deux ans plus tard (2000) que mon blog "fait maison" a reçu son ultime modification avec ma première intégration d'une base MySQL 3.23.19 -> capture d'écran ! :shock: Le XXIe siècle m'a fait découvrir le phénomène du blog et j'ai alors migré mon site perso vers la seule plate-forme (française qui plus est) digne de ce nom à l'époque : Dotclear 0.9/1.2 (développé par Olivier Meunier) :W Malgré son excellente qualité pour l'époque, trop impatient d'attendre la V2 (sortie en 2008), j'ai (honteusement?) switché sur WordPress 2.0.4 en 2006. Il n'y avait pas d'autres solutions (ou elles étaient à leurs balbutiements) et c'est donc il y a près de 3 ans que l'aventure WordPress a commencé pour moi :eek2: Bien qu'à l'heure actuelle les projets les plus proches soient certainement Drupal, Movable Type et TextPattern ; je ne compte pas en changer.

Qu'est ce que j'y fais concrètement ?

L'esprit communautaire du projet et le fait que mes contributions ne soient pas (directement) rémunérées, me permet une grande flexibilité notamment par rapport à mon boulot et à ma vie privée :nickel: Quand je n'ai pas énormément de temps et que je ne suis pas d'humeur à "bouffer du code", j'effectue généralement un travail de traduction (anglais->français) du Codex (centre de documentation) -> mon profil et mes contributions :cool: C'est tout récent mais il m'arrive également (Merci Valentin) de présenter des plugins sur geekeries.fr -> Dernier article en date. Parfois je communique mes idées d'évolution au reste de l'équipe, mais ça reste très marginal car je préfère agir (coder) que parler (proposer) -> ma dernière proposition :oops: Bien qu'ayant aidé au développement de plusieurs plugins par l'intermédiaire de forums de supports, je ne suis l'auteur exclusif d'aucun : j'ai horreur de venir "coller des verrues" (à mes yeux, plugins=verrues) sur un code :evil: Surtout que la plupart du temps, on peut se passer de plugin, en procédant à une "intégration native" du code, dans les fichiers de thèmes (par l'intermédiaire des marqueurs de modèles et des marqueurs conditionnels), et plus particulièrement dans le fichier functions.php (par l'intermédiaire des fonctions de référence). Je suis également testeur (devenir testeur?), je discute des différentes versions (nightly, alpha&beta) et je rapporte des bugs sur le trac. Et sinon je développe WordPress, c'est bien la tache la plus "lourde" ! Je consulte d'abord le trac (histoire de ne pas être complètement à l'ouest), je télécharge le SVN et vas-y développe -> tester des patchs, appliquer des patchs, etc...

Et puis voilà !

Pour finir, je viens d'actualiser une documentation assez complète que j'avais rédigé il y a plusieurs mois : Protéger votre WordPress du grand méchant loup. Il faudrait que je trouve le temps de la traduire en anglais et d'en faire un fichier pdf mais... ultérieurement ! Voilà, je pense avoir tout dit à propos de mon implication dans le projet WordPress :razz: Pour les personnes désireuses de découvrir WordPress, je ne peux que les encourager à lire cette publication du Codex français : Nouveau sur WordPress - Où commencer ? :roll: Pour l'instant, les développeurs ne trouveront leur bonheur que dans le Codex Anglophone car, malgré une importante mobilisation des traducteurs, la déclinaison française est loin d'être aussi riche que son équivalent US : ça arrive, ça arrive! cyp Sinon pour ce qui est des projets au sein de la communauté, ça fait quelques temps que l'idée d'organiser un WordCamp fait son chemin mais rien de bien concret pour l'instant.

1 – Script PHP nécessaire à la génération des miniatures…

Récupérer le script php TimThumb écrit par Tim McDaniels et Darren Hoyt. Mettez le dans un fichier timthumb.php que vous chargerez dans le répertoire /wp-content/themes/votre_theme/ de votre installation WordPress.

A noter que les 3 variables (‘CACHE_SIZE’, ‘CACHE_CLEAR’ et ‘VERSION’) situées au début du script peuvent être modifiées, le script est bien documenté à ce niveau. Prenons les devants en indiquant dès maintenant que ce script va vous permettre (après édition du fichier functions.php) d’utiliser la fonction de génération des miniatures :

Lorsque vous allez appeler cette fonction dans votre fichier de thème (dans le cas présent, index.php), vous pourrez, au besoin, lui “passer” 4 arguments (w, h, zc et q) afin d’obtenir le type de miniature qui vous convient le mieux.

w: largeur de la miniature
h: hauteur de la miniature
zc: zoom crop (0 or 1)
q: qualité de la miniature (compression : 75% par défaut, maxi 100%)

2 – Déclarer à votre thème la fonction qui va permettre l’extraction de la première image de l’article…

Editer (ou créer s’il n’existe pas) le fichier functions.php dans le répertoire de votre thème : /wp-content/themes/votre_theme/functions.php pour y ajouter :

/i', $post->post_content, $matches);
  $first_img = $matches [1] [0];
  if(empty($first_img)){ //Defines a default image
    $first_img = "/images/default.jpg";
  }
  return $first_img;
}
?>

Je n’ai pas jugé utile de commenter la fonction php ci-dessus. En effet elle va simplement “lire” le billet concerné et trouver la première image qui le compose par simple détection de la première balise HTML :

Quand la fonction catch_that_image(); sera appelée (dans le fichier ci-dessous), elle ne fera que remonter le contenu de l’attribut “src” de la balise HTML “img” ; autrement dit l’adresse/url de l’image.

A noter que c’est le fichier image default.jpg qui sera chargé dans le cas où il n’y aurait pas d’image dans le billet concerné. Pensez donc bien à mettre un fichier default.jpg dans le répertoire images de votre thème. Si l’emplacement, le nom ou l’extension du fichier ne vous conviennent pas, vous pouvez toujours modifier la variable $first_img de la fonction.

3 – Modification de la page d’accueil (index.php) pour récupérer les premières images et générer les miniatures

Voici à quoi ressemble mon fichier de thème index.php situé dans le répertoire de thème /wp-content/theme/votre_theme/index.php

A noter que j’ai volontairement retiré tous les balisages de mise en forme qui sont assez peu pertinents dans le présent tutorial : juste l’essentiel.

J’affiche volontairement une bonne partie du code afin de vous montrer de quelle manière je compte ($count) les billets afin d’avoir un rendu différent pour mon article le plus récent et pour les 8 qui suivent. En réalité, pour la stricte génération des miniatures, seule la ligne suivante nous intéresse…

Dans l’état actuel des choses, les 8 miniatures générées sur ma page d’accueil mesurent donc 172 pixels de hauteur (h=172 ci-dessus) et 250 pixels de largeur (w=250 ci-dessus). L’argument zc=1 permet justement de recadrer l’image dans le cas où elle ne puisse se redimensionner aux valeurs indiquées sans déformation. L’attribut q n’est pas utilisé, je conserve sa valeur par défaut, à savoir une compression .jpg à 75%.

4 – Mise en cache des miniatures pour un chargement plus rapide (facultatif)

Le script timthumb.php utilisé plus haut permet de conserver (mettre en cache) les miniatures qu’il génère dans un répertoire. Ce répertoire doit s’appeler cache et se situer au même niveau que le fichier timthumb.php. Vous devez bien sûr mettre les droits nécessaires en écriture sur ce répertoire “cache” : CHMOD. Pour déplacer le répertoire cache, vous pouvez éditer la ligne 68 (environ) du fichier timbthumb.php :

$cache_dir = './cache';

Informations complémentaires…

Bien que je déteste utiliser des plugins, les personnes moins “expérimentées” pourront obtenir un résultat relativement proche par le biais du plugin Image Extractor développé par Michele Gobbi. A noter que ce plugin permet uniquement de récupérer la première image d’un billet et non de générer une miniature, etc… Bref c’est l’alternative à-la-rache par rapport à la solution exposée ci-dessus. Si vous avez des remarques (précisions, correction, etc) ou besoin d’aide, le système de commentaires est fait pour vous… :nickel:

Cela fait maintenant plusieurs années que j'utilise WordPress parce que Dotclear ça pue et depuis quelques temps, j'ai envie de rédiger un article traitant de la sécurité de cet outil de blogging devenu CMS. Et comme j'avais envie bah... je l'ai fait :lol: Bien que ce CMS voit sa sécurité améliorée de version en version, cette dernière ne se limitant pas au code source, j'ai jugé nécessaire de vous faire part de quelques petites "bidouilles" qui permettront à votre blog de ne pas se faire vulgairement poutrer par un zombie. C'est récemment arrivé au blog de Bastien et demandez-lui, ça fait mal :mad: Je vous souhaite une excellente lecture de cet article d'une vingtaine de pages que j'ai mis un certain temps à rédiger...

Version actualisée le Mardi 11 Août 2009 !

Toutes les modifications évoquées dans la suite de cet article permettent de sécuriser votre installation de WordPress et ces dernières sont généralement applicables à la plupart des versions. Cependant quelques modifications ne pourront être effectuées sur des versions trop obsolètes de WordPress. Dans ce cas là je vais faire en sorte de préciser dans quel cas il est possible (ou non) d'appliquer telle ou telle modification. A noter que j'ai tout de même personnellement testé l'ensemble de ces modifications sur la version 2.8.4 qui supporte de facto ce qui suit. Si à la suite de cette lecture vous avez des questions, je reste à votre disposition par l'intermédiaire du système de commentaires ou du formulaire de contact.

- Mettre à jour WordPress, - Utiliser le protocole HTTPS, - Renommer votre compte administrateur, - Bien choisir votre mot de passe, - Vérifier les autorisations des répertoires (CHMOD), - Changer le préfixe des tables, - Limiter l'accès à des répertoires, - Empêcher le listage des répertoires, - Refuser l'accès à des adresses ip, - Protéger le fichier wp-config.php, - Aller plus loin avec les .htaccess, - Masquer le générateur et la version de WordPress, - Empêcher les robots d'indexer des répertoires, - Effectuer régulièrement des sauvegardes, - Les 4 clés du fichier wp-config.php, - Déplacer et/ou renommer le répertoire wp-content, - Renommer/déplacer/cacher le répertoire wp-admin, - Limiter le nombre de tentatives d'identification, - Interdire l'accès aux logiciels de blogging, - Protéger son identification des "keyloggers" (enregistreurs de frappe), - Mot de passe à usage unique, - Cacher les erreurs d'identification, - Méfiez-vous de votre boîte mail, - Liens complémentaires et sources d'inspiration.

Il y a quelques jours j’ai installé un WordPress version 2.3.1 et j’ai constaté la disparition de l’éditeur visuel de billets TinyMCE. Bon moi perso j’édite mes articles en mode “Code” alors ça ne me pose pas trop de problèmes mais bon. Un truc qui marche pas comme ça, ça m’énerve sévère. Surtout qu’il y a plusieurs WordPress qui sont installés sur la machine et je ne rencontre le problème que sur celui là. Ce n’est apparemment pas directement lié à la version puisque d’autres WordPress 2.3.1 fonctionnent. Après plusieurs recherches il s’avère que le problème vient apparemment de la compression gzip qui doit être mal gérée par le système. J’ai donc trouvé la solution sans vraiment pouvoir expliquer l’origine exacte du problème (j’suis un teigneux LOL). Donc si votre TinyMCE disparait bah… (Vidéo de sebabakart en fin d’article, y’a du lourd !)

Il faut éditer le fichier suivant qui se trouve sur votre FTP : /wp-includes/js/tinymce/tiny_mce_gzip.php

Après il faut vous rendre aux alentours de la ligne numéro 83 afin de trouver ce bout de code :

// Check if it supports gzip
if (isset($_SERVER['HTTP_ACCEPT_ENCODING']))
$encodings = explode(',', strtolower(preg_replace("/s+/", "", $_SERVER['HTTP_ACCEPT_ENCODING'])));

if ((in_array('gzip', $encodings) || in_array('x-gzip', $encodings) ||
isset($_SERVER['---------------'])) && function_exists('ob_gzhandler')
&& !ini_get('zlib.output_compression') && ini_get('output_handler') != 'ob_gzhandler') {
$enc = in_array('x-gzip', $encodings) ? "x-gzip" : "gzip";
$supportsGzip = true;
}

Il faut remplacer (vers la ligne 89) :

$supportsGzip = true;

par :

$supportsGzip = false;

On enregistre le fichier et on le charge sur le FTP à la place du tiny_mce_gzip.php original :razz:

Voilà comment on arrive à passer du temps sur une petite connerie de m…. :evil:

PS : Il avait ingurgité une quantité assez impressionnante d’alcool le bougre :???: