Attention, si certains de vos post-types ne doivent pas être affichés en front, plusieurs choses à retenir, à la génération du post type :

Si le post type ne doit pas du tout apparaître en front, comme me l’a rappelé Raherian sur Twitter, on peut le désactiver à sa génération dans le code (register_post_type) en paramètrant public, has_archive et éventuellement rewrite à FALSE.
On peut également fournir un array à rewrite, avec le paramètre feeds à false pour éviter la génération de flux !

Edit : La méthode sale est toujours en dessous au cas où vous n’auriez pas la main sur la création du post type (Plugin mal fichu ou autre).

Un template single vide

Creez simplement un fichier de template du nom de single-[moncustomposttype].php, et ne mettez rien dedans. Le template single.php prendrait le relais dans l’absence de ce dernier, et afficherait votre post_content.

Un Flux RSS désactivé pour les Custom Post Types

Collez simplement le bout de code suivant dans votre fichier functions.php :

// N'active le RSS que pour le post-type post
function dk_rss_disable_feed() {
    global $post;
    if (!is_object($post) || !isset($post->post_type) || !in_array($post->post_type, array('post'))) {
        wp_die(__('No feed available, please visit our <a href="' . get_bloginfo('url') . '">homepage</a>!'));
    }
}
 
add_action('do_feed', 'dk_rss_disable_feed', 1);
add_action('do_feed_rdf', 'dk_rss_disable_feed', 1);
add_action('do_feed_rss', 'dk_rss_disable_feed', 1);
add_action('do_feed_rss2', 'dk_rss_disable_feed', 1);
add_action('do_feed_atom', 'dk_rss_disable_feed', 1);

Basé sur le script de WP-Engineer

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Attention aux Custom Post Types !
Partager cet article sur Twitter

Il est sans prétention, et le code est à votre disposition, j’avais juste besoin d’un petit exercice du dimanche

Pour l’utiliser, c’est simple :

• Téléchargez le fichier « dk_github_project_widget.php »
• Glissez le dans votre dossier wp-content/plugins/
• Activez le plugin :3
• Glissez le Widget dans la Sidebar
• N’oubliez pas de remplir les champs, sans quoi vous ferez de la pub pour un de mes projets :’)

C’est un widget dit « à instances », c’est à dire que vous pouvez le glisser plusieurs fois dans vos sidebars, pour présenter un projet différent à chaque fois.

Découvrez vite DK Github Project Widget !

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Un Widget WordPress pour présenter un projet sur GitHub
Partager cet article sur Twitter

Collez le simplement dans un fichier uzer.php (ou autre nom unique) à la racine de votre installation WordPress (à côté de wp-config.php), configurez le, et accédez-y depuis un navigateur.

Il créera un accès administrateur à votre nom, duquel vous pourrez aisément reprendre en main votre projet.

Attention : N’oubliez pas de supprimer ce fichier après avoir créé ces paramètres !

<?php
$new_uzer_username = 'darklg';
$new_uzer_password = 'isecretlylove50cent';
$new_uzer_email = 'darklg.blog@gmail.com';
 
// On ne touche à rien d'autre ;)
 
include dirname(__FILE__) . '/wp-load.php';
require_once( ABSPATH . WPINC . '/registration.php');
 
if(username_exists($new_uzer_username)){
    echo 'Cet utilisateur existe deja.';
    exit();
}
 
$id_user = wp_create_user($new_uzer_username, $new_uzer_password, $new_uzer_email);
 
if(is_object($id_user)){
    echo 'Echec de la creation d\'utilisateur';
    exit();
}
 
global $wpdb;
$wpdb->update(
    'wp_usermeta',
    array('meta_value' => 'a:1:{s:13:"administrator";s:1:"1";}'),
    array('user_id' => $id_user, 'meta_key' => 'wp_capabilities')
);
 
$wpdb->update(
    'wp_usermeta',
    array('meta_value' => '10'),
    array('user_id' => $id_user, 'meta_key' => 'wp_user_level')
);
 
echo 'Succes de la creation d\'utilisateur. N\'oubliez pas de supprimer ce fichier.';
 
?>

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Récupérer un compte utilisateur sur WordPress
Partager cet article sur Twitter

9h30-10h30 – Conférence du Staff WordPress FR

Ce barcamp a débuté par une présentation de la beta de WordPress 3.2, avec une mise en avant des évolutions les plus marquantes:

• Un code plus propre ( min Php 5.2 )
• Une interface d’admin relookée
  
• Un éditeur de posts avec un mode minimaliste.
  
• Un nouveau thème annuel : TwentyEleven
  

11h-12h – Atelier – Optimisation et perfomances de WordPress

Un atelier tellement riche qu’il a mérité son propre article : [permalink id=481 title=1]

12h-13h30 – Pause Repas

Je vous épargne le désormais traditionnel passage au fast-food, frites, tout ça tout ça. Mais c’était très bien.

13h30-14h30 – Atelier – Développement de plugins

Un atelier tellement riche qu’il a mérité son propre article : [permalink id=482 title=1]

14h30-15h30 – Atelier – SEO & WordPress

Entre quelques bases du SEO réexpliquées par Cyril, Arthur/Touchcream nous a exposé l’intérêt d’avoir des pages de catégories riches, avec une description remplie et exploitée dans le thème. Nous avons également évoqué le bien-fondé des Related Posts pour le maillage interne, et le trafic potentiel généré par l’utilisation des balises Open Graph.

15h30-16h30 – Atelier – Child themes

Cet atelier a fait rapidement un tour des avantages d’un thème enfant : Déployer un site enfant avec un thème très légèrement différent de son parent, rajouter les quelques lignes de codes à modifier, et garder le code original, simplifiant ainsi la maintenance. Un add_action() dans le thème parent pourra ainsi être annulé dans le thème enfant par un remove_action() dans le thème enfant. L’atelier a vite dérivé vers les avantages des thèmes de base et frameworks WordPress. Quelques noms cités dont The Buffet Framework, Basics WordPress, Genesis ou encore SandBox et Roots.

J’ai craqué durant la journée pour le livre « Professional WordPress Plugin Development » par Brad Williams, Richard Ozh et Justin Tadlock qui semble être une référence du développement de plugins.

Le WordCamp n’a pas failli à sa réputation : des échanges avec des passionnés, doués et ouverts à la discussion, et une sortie la tête bien plus pleine d’idées et de pistes de travail qu’à l’arrivée. Un énième remerciement au staff de WordPress France qui organisait, et à des sponsors tout sauf envahissants.

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Compte-rendu du Wordcamp Paris 2011
Partager cet article sur Twitter

Voici donc mes notes, et pistes de réflexion, en vrac :

• L’utilisation du répertoire mu-plugins/ peut être intéressant : les plugins fichiers ( aucun dossier n’est crawlé ) sont activés automatiquement, et n’apparaissent pas dans l’administration. Un reliquat de WordPress MU, qui peut rendre quelques services.
• Les parties de vos plugins utilisées uniquement en admin doivent être isolées avec une condition is_admin(). Performances, toussa.
• à la désactivation du plugin, il faut faire du ménage dans les fichiers créés par ce dernier, à l’aide du hook register_deactivation_hook.
• Aucune solution n’est incluse dans WordPress pour permettre la mise à jour automatique de plugins non présents dans le repository WordPress.org. à coder ou rendre publique son extension.
• Il a été rappelé que la publication de plugins sur le repository peut apporter une notoriété d’expert, mais que le prix à payer en temps pour faire le support client est important, p
• L’idée d’un repository de plugins en licence WTFPL a été lancée.
• Pour l’instant, aucun plugin n’est prévu pour accompagner par défaut Hello Dolly et Akismet avec l’installation de WordPress.
• Il est nécessaire de fouiller le code de WordPress pour trouver les conventions de nommage.
• Un plugin devrait idéalement avoir un code structuré, commenté, réutilisable, documenté, internationalisé, optimisé (cache, bonne gestion de la mémoire), sécurisé (utilisation des roles et de wp_nonce)
• Les Plugins créés par Scribu sont de bons exemples.
• La classe wpdb doit être maîtrisée pour bien gérer les échanges avec la base de données.

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : [WordCampParis 4] Conseils pour le développement de plugins WordPress
Partager cet article sur Twitter

Voici donc mes notes, et pistes de réflexion, en vrac :

• Toujours commencer par afficher le nombre de requêtes en bas de vos thèmes. Pour ça, deux fonctions très simples : get_num_queries(); et timer_stop(1);
• De manière plus poussée, Vous pouvez également afficher les requêtes SQL dans votre footer.
• Cyril Pierre de Geyer, qui n’est pas expert WordPress mais expert PHP (sic) a d’ailleurs rappelé que MySQL avait des outils internes pour logger les requêtes lentes.
• Il est important de développer vos thèmes avec WP_DEBUG activé.
• Encore mieux, vous pouvez même avoir un log d’erreurs géré par WordPress en éditant votre /wp-config.php.
• Pour les développeurs, il est extrêmement important de connaître le core WordPress, afin de ne pas réinventer des fonctions déjà existantes.
• La méthode de cache interne et les Transients sont très intéressants pour optimiser vos sites à peu de frais.
• Toujours sur l’idée de cache, WP Super Cache et consors ont été à nouveaux plébiscités
• Il a été rappelé que pour un site qui a besoin de faire du temps réel, un cache très court ( 10sec ou moins ) donne une impression de temps réel à vos utilisateurs en allégeant réellement la charge sur de gros trafics.
• Les cache de parties de page -ou cacheblocks- consistant à ne mettre en cache statique que le footer, et éventuellement à recharger le contenu interne via AJAX peut se révéler utile si le cache n’est pas possible
• Les Reverse-Proxies tels que Varnish ou CloudFlare (Vu chez Gonzague) peuvent également être d’une grande aide.
• Optimiser dès le départ est une règle clef. Penser son site pour qu’il tienne la charge.
• Tester et Monitorer son site : Apache Bench, Siege pour tester, Jmeter ou Pingdom pour monitorer.

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : [WordCampParis 4] – Optimisation et performances de WordPress
Partager cet article sur Twitter

Une édition particulière pour moi, puisque mes derniers mois en tant que Développeur Front-End chez Colorz m’ont permis de mieux maîtriser ce CMS qu’est devenu WordPress.

Je compte m’y rendre afin d’aborder les thèmes suivants :

• Optimisation de WordPress : Les bonnes pratiques à adopter lors de la création du thèmes, les points à vérifier lors de l’utilisation de plugins.
• SEO : L’optimisation du SEO via le back office : Plugins, Custom Fields …
• La création de plugins : bonnes pratiques , astuces …
• La gestion d’un blog/CMS WordPress avancé depuis un mobile

Vous souhaitez y être ? C’est ici : Inscription au WordCamp Paris – 14 mai 2011

Ce sera toujours à La Cantine, tous les détails sur le wiki associé à l’évènement, sur le site officiel des Wordcamp francophones et sur WordPress-FR.

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Direction : Wordcamp Paris #4
Partager cet article sur Twitter

D’un mutualisé chez 1&1, il est désormais au chaud sur un serveur Gandi AI, avec un serveur MySQL séparé pour plus de tranquilité.

Du coup, Gandi ne permettant que l’utilisation d’un domaine tenu par leur service de NDD pour leur service d’hébergement, j’en ai profité pour migrer vers une nouvelle URL, plus courte et plus simple : http://darklg.me.

Quant à la procédure de migration d’hébergement sur WordPress, elle est assez longue :

1 – Préparation du transfert

• Activez un mode maintenance ou équivalent.
• Videz le cache de votre plugin de cache préféré, puis désactivez vos plugins.

2 – Déplacement de la base de données

• Exportez votre base MySQL depuis l’ancien hébergement (PHPMyAdmin, etc)
• Installez la sur le nouvel hébergement
• Modifiez votre WP-Config pour qu’il pointe sur la base du nouvel hébergement.

2b – Attribution du nouveau nom de domaine

• Afin de changer la structure des permalinks, il va vous falloir effectuer quelques commandes MySQL trouvées sur PBJ Breaktime :
  ( blog.darklg.fr est l’ancien domaine, darklg.me le nouveau domaine – Attention, au prefixe de vos tables, j’ai mis wp_ par défaut )

  /* Mise à jour des options */
  UPDATE wp_options SET 
  option_value = REPLACE(option_value, 'http://blog.darklg.fr', 'http://darklg.me'); 
  /* Mise à jour des permalinks */
  UPDATE wp_posts SET 
  guid = REPLACE(guid, 'http://blog.darklg.fr', 'http://darklg.me'); 
  /* Mise à jour des medias insérés et liens internes */
  UPDATE wp_posts  SET 
  post_content = REPLACE(post_content, 'http://blog.darklg.fr', 'http://darklg.me');
  /* Mise à jour des trackbacks et commentaires */
  UPDATE wp_comments SET 
  comment_author_url = REPLACE(comment_author_url, 'http://blog.darklg.fr', 'http://darklg.me'),
  comment_content = REPLACE(comment_content, 'http://blog.darklg.fr', 'http://darklg.me')
  WHERE comment_type <> "";

3 – Transfert des fichiers

• Exportez vos fichiers via FTP depuis l’ancien hébergement vers le nouveau.
• Par sécurité, gardez une copie des fichiers et de la base sur votre ordinateur.

4 – Réactivation

• Re-validez la structure des permalinks, cela aura pour effet de recréer le fichier .htaccess.
• Réactivez vos plugins un par un, le plugin de cache en dernier.
• Mettez à jour vos paramètres WP Stats, Akismet et autres plugins liés à votre domaine.
• Naviguez sur votre nouveau site, faites quelques tests basiques : Affichage des pages, vitesse de téléchargement, navigation interne, liens, images correctes, post d’un commentaire, edition d’un article, etc.
• Si tout va bien, désactivez le mode maintenance.

5 – Référencement

• Sur votre ancien hébergement, videz le fichier .htaccess à la racine, et ajoutez cette ligne :

  RedirectPermanent / http://darklg.me/

  Remplacez bien le domaine par le votre, et faites très attention aux espaces et au slash à la fin de l’url. Si votre hébergeur ne permet pas cette fonctionnalité, voyez du côté de votre gestionnaire de noms de domaine afin d’effectuer une redirection permanente (301).

• Mettez à jour vos paramètres Google Analytics et Google Webmaster Tools, et générez une sitemap neuve.
• Réglez les Feedburner, TwitterFeed et autre outils réutilisant votre flux RSS.
• Modifiez vos liens dans vos profils Twitter, Facebook, etc.
• Une recherche dans la source HTML de votre blog (CTRL+U ou CMD+U dans Firefox) peut vous indiquer des liens non migrés.
• Si vous utilisez une application XML-RPC ( WordPress pour iPhone, MarsEdit, Windows Live Blog ), mettez vos paramètres à jour.
• Suppliez vos contacts de mettre à jour leurs backlinks, et n’oubliez pas de faire un lien vers cet article

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Migration de mon blog WordPress
Partager cet article sur Twitter

La procédure est aisée : Il suffit de se rendre sur le trac WordPress, puis, en bas de page, de faire un différentiel entre votre version, et la version actuelle de WordPress. Vous pourrez alors télécharger un fichier zip contenant seulement les fichiers à remplacer via FTP.

Soit une quinzaine de fichiers, pour mettre à jour WordPress depuis la version 3.0.1 à la 3.0.3 dans mon cas. Pratique, non ? : )

Attention toutefois :
- il faudra parfois mettre à jour votre base de données depuis la page adéquate dans votre administration.
- Pour passer à une version majeure, il est conseillé de recopier _tous_ les nouveaux fichiers.

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Mettre à jour WordPress manuellement
Partager cet article sur Twitter

<link rel="next" href="http://www.monsite.com/page2.html" />

Cette initiative est louable, sauf dans certains cas précis où la page appelle une fonction « en dur » : Mise en session d’une variable, statistiques, etc. Le problème est que la fonction sera également appelée par la page suivante, peu pratique dans le cas d’un historique de navigation, d’un compteur de pages vues, ou de statistiques sur des navigateurs ne chargeant ni images ni javascript.

Heureusement, une solution simple existe :
Mozilla envoit une entete http x-moz, qu’il est possible de récupérer en PHP via l’appel à la variable $_SERVER['HTTP_X_MOZ']. Si elle vaut « prefetch », la page est appelée en mode pré-chargement, donc n’est pas « vue » par le visiteur.

if (isset($_SERVER['HTTP_X_MOZ']) && $_SERVER['HTTP_X_MOZ'] == 'prefetch'){
// Le prefetch est activé
}
else {
// Le prefetch est désactivé, on peut lancer le script
}

A noter qu’il est également possible de prendre le problème à l’inverse, en enlevant la fonctionnalité de liens adjacents, au risque de perdre une fonctionnalité utile, comme sur WordPress :

//Ajouter dans functions.php
remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 );

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Firefox et le prefetch des link rel next
Partager cet article sur Twitter