L’apparence de ce dernier ne change pas beaucoup, étant donné que j’ai toujours aussi peu de compétences en design, mais c’est sous le capot que beaucoup de changements se sont produits.

Principaux changements

• Les fichiers du thème sont versionnés sur Git. Pratique pour le déploiement, pour les backups, et pour garder une trace de son évolution.
• Les commentaires n’ont plus de nofollow. Je vais probablement regretter la vague de spams, mais tant mieux pour les commentateurs.
• Le thème est en responsive web design. Donc enfin un vrai thème mobile
• Beaucoup moins de plugins derrière. Donc plus de WP-Page Navi, WP-Similar, et donc de meilleures performances.
• Le code derrière est plus solide, et mieux rangé.

Le changement le plus significatif pour moi est le départ sur une nouvelle base propre, qui me permettra tôt ou tard de publier le code de ce thème, et d’y apporter des modifications intéressantes !

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Darklg Blog fait peau neuve
Partager cet article sur Twitter

Ces sites ont un défaut qui m’a été rappelé l’autre jour, quand PlaceKitten est tombé hors ligne, et que mes intégrations ont été déshabillées d’un coup. Aucun moyen de monétiser (Bannieres sur le site, bof, insertion de marques dans les images, bof), donc une durée de vie limitée en cas de succès soudain et d’absence de sponsors.

J’ai donc mis en place un petit script permettant d’installer votre propre service de placeholders sur votre serveur/machine, afin d’éviter les soucis liés à l’utilisation d’un service externe, tels que le ralentissement de vos sites locaux, le manque de fiabilité, etc.

Ce Script doit être dézippé/cloné sur votre serveur/hébergement utilisant Apache & PHP, avec mod_rewrite et GD activés. Plus qu’à le lancer, glisser des images en JPG dans le sous-dossier images/ et c’est parti !

PlaceHugger est un script en PHP, disponible sur GitHub

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Obtenez vos images PlaceHolders avec PlaceHugger !
Partager cet article sur Twitter

Heureusement, des hacks existent pour permettre de gérer l’opacité d’une couleur sous Internet Explorer, pour un background. Des filters avec aRGB, demandant une certaine structure, un recalcul des valeurs, un niveau d’opacité en hexadécimal.

Lors d’une petite pause dans mon travail chez Colorz, j’ai monté GiveMeRGBA un outil rapide permettant, en fournissant uniquement la couleur en hexadécimal, et le pourcentage d’opacité, de générer tout le code nécessaire pour avoir un fond semi-transparent sur la plupart des navigateurs (dont Internet Explorer 7 et plus). C’est un script sans prétention, disponible sur Github et ouvert à tout commentaire.

Testez directement GiveMeRGBA

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Générez du RGBa compatible Internet Explorer avec GiveMeRGBA !
Partager cet article sur Twitter

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

• Arrêter les services
• Arrêter le programme MAMP
• Renommer le dossier MAMP dans /Applications/ en MAMP_precedent
• Lancer le fichier d’installation fraîchement téléchargé
• Suivant, suivant, Accepter de vendre son âme parce qu’on ne lit pas les conditions d’utilisation, suivant …
• Ouvrir les dossiers MAMP et MAMP_precedent
• Copier le contenu du sous-dossier /htdocs vers MAMP (Si vous l’utilisez)
• Copier le contenu du sous-dossier /db/mysql vers MAMP (Sauf les sous-dossiers mysql/, performance_schema/ et le fichier mysql_upgrade_info)
• Copier le fichier /conf/apache/httpd.conf vers MAMP (Idéalement, faire un diff pour voir ce qui a changé dans la nouvelle version)
• Copier le fichier /bin/php/[Votre version]/conf/php.ini vers MAMP (Idéalement, faire un diff pour voir ce qui a changé dans la nouvelle version)
• Copier mon sous-dossier /vhosts (Je ne mets pas les vhosts dans le httpd.conf)
• Relancer MAMP, la MaJ est terminée !

Merci beaucoup à Kyle D. Skrinak, qui a publié sa méthode, et m’a bien aidé pour trouver comment mettre à jour MAMP.

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

• Contenu créé : ( content, etc )
• Propriété display
• Positionnement ( z-index, position, top )
• Modèle de boîte ( height, margin, border … )
• Transformations et transitions
• Typographie
• Décoration

L’ordre recommandé par l’auteur peut être adapté à ses goûts / à la méthode de son entreprise, mais l’essentiel reste là : regrouper les propriétés par type, afin de mieux relire son code, trouver directement un bug, et tous les avantages d’une convention de codage.

Ainsi, dans la lignée des petits scripts qui font mouche, comme img2datauri, voici CSSLisible, un simple script en PHP pour réorganiser vos CSS, disponible sur GitHub.

Le principe est simple, on télécharge, on fork ou on clone le code dans son dossier www ou htdocs de MAMP/LAMP/WAMP, et on y accède depuis son navigateur.

L’interface sobre, et sans CSS, ô ironie, vous permet de coller un bout de code à nettoyer, pour obtenir en retour un code réorganisé, et trié dans l’ordre de priorité des priorités. Il s’agit d’une base de travail à faire évoluer, l’algorithme de tri étant très primaire.

Testez directement CSSLisible

Je suis évidemment ouvert à tous retours

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Réorganisez vos propriétés CSS avec CSSLisible
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

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

Malheureusement, VirtualBox (et probablement d’autres logiciels de virtualisation) « bloque » l’accès à votre fichier hosts original, et ne reconnaissent donc pas un nom de domaine défini en local, sur votre machine (type http:/darklg.dev ou http:/monsite.local). Donc impossible d’accéder à un MAMP / WAMP / LAMP situé au dessus de votre machine virtuelle.

Il va donc falloir faire pointer votre domaine personnalisé vers votre machine originale, dans la machine virtuelle.

Ouvrons les yeux à Virtualbox

Ouvrez le fichier hosts dans votre machine virtuelle, avec si possible, un éditeur lancé en mode administrateur / avec possibilité d’enregistrer un fichier protégé ( Textmate, Notepad++, Vi, etc ) :

Sur Windows C:\WINDOWS\system32\drivers\etc\hosts
Sur UNIX (Mac/Linux) /etc/hosts

Dans ce fichier hosts, vous pourrez rajouter vos noms de domaines personnalisés, à condition de le faire pointer sur la bonne adresse IP :
127.0.0.1 localhost # on ne touche pas à ça
10.0.2.2 darklg.dev
10.0.2.2 monsite.local

Sauvegardez, videz votre cache DNS, en executant ces commandes dans votre terminal :
Sur Windows ipconfig /flushdns
Sur Linuske /etc/rc.d/init.d/nscd restart
Sur Mac OS X dscacheutil -flushcache
Sur Mac OS X 10.6 lookupd -flushcache

Pratique pour pouvoir passer de superbes après-midi ensoleillées enfermé face à ce P*t**n d’Internet Explorer 6 de b*rd*l de m*rd* : )

Merci au site SandHillCreative pour l’info originale

Un article publié sur Darklg Blog © 2012
Lien vers l'article original : Accéder à MAMP depuis Virtualbox
Partager cet article sur Twitter