Desclaux.fr

Un petit truc pour sécuriser vos sites sous WordPress (utilisable avec d’autres CMS d’ailleurs) : il suffit d’ajouter un fichier .htaccess dans votre dossier admin : pour WordPress c’est donc dans wp-admin

Exemple .htaccess

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Access Control"
AuthType Basic
<LIMIT GET>
order deny,allow
deny from all
# whitelist home IP address
allow from mon.ip.per.so
# whitelist work IP address
allow from mon.ip.au.travail
</LIMIT>

Et bien sûr vous modifiez ce fichier pour mettre vos propres adresses IP…

Il arrive parfois qu’on veuille créer son propre paquet .deb à partir du dépot des sources (par exemple quand on souhaite utiliser une version très récente et pour laquelle la version binaire installable n’existe pas encore…)

C’est très simple si on fait tout dans l’ordre

1. Télécharger les fichiers sources de votre programme (pour notre exemple il s’agira de drupal6 même s’il existe bien un paquet binaire installable…)
   1. drupal6_6.14-1.orig.tar.gz
   2. drupal6_6.14-1.diff.gz
   3. drupal6_6.14-1.dsc
2. Décompresser le drupal6_6.14.orig.tar.gz
3. Décompresser le drupal6_6.14.diff.gz
4. Vous aurez probablement besoin d’installer quelques outils si c’est votre première construction de paquet :
   1. sudo apt-get install dpatch
   2. sudo apt-get install fakeroot
5. Lancer la commande : patch -p1 < xxx.diff
6. Déplacer le dossier debian créé à l’étape précédente dans le dossier créé à l’étape 2 (celui qui contient les sources du *.orig.tar.gz, pour cet exemple il s’agit de drupal-6.14) : mv debian drupal-6.14
7. Déplacer vous dans le sources : cd drupal-6.14
8. Vous devrez probablement rendre le script debian/rules executable… : chmod +x debian/rules
9. Lancer la commande : dpkg-buildpackage -rfakeroot -uc -b
10. C’est terminé ! Il ne reste plus qu’à installer votre paquet fraichement compilé. Pour notre exemple ça donnera donc :
    1. cd ..
    2. sudo dpkg -i drupal6-6.14_all.deb

Vous connaissez maintenant la marche à suivre…

Programmer c’est fun et excitant mais de temps en temps un jeu c’est bien pour se relaxer ! Alors j’en profite pour vous conseiller l’excellentissime « World Of Goo » … Pour 13 euros 50 (20 dollars) vous pourrez jouer pendant des heures pour résoudre les énigmes de ce « puzzle électronique ». Franchement ça les vaut largement, c’est plutôt original même si le concept de type « casse-tête » est classique et on retrouve enfin le plaisir d’un jeu qui mise sur l’intérêt et le coté ludique plutôt que tirer sur tout ce qui bouge… Les niveaux ne sont pas trop faciles et requièrent autant de « doigté » que de réflexion et on devient vite accro ! En plus les développeurs ont choisi de ne pas protéger le jeux contre la copie et de proposer pour le prix de la licence le téléchargement pour Windows, Mac et surtout Linux (en 32 et 64 bits) !! Essayez la démo et si vous aimez, soutenez cette initiative en achetant ce jeu !

Si vous utilisez WordPress et le plugin WPML pour gérer un site en multi-langue vous avez surement constaté que l’utilisation du moteur de recherche de WordPress affichera alors la liste des résultats pour la langue par défaut… et pas pour la langue actuellement utilisée par votre visiteur.

Pour améliorer cela voici un petit patch… Ce n’est pas très clean mais ça fonctionne (je vous laisse optimiser cela pour utiliser, par exemple, une surcharge de fonction plutôt qu’une modification directe des fichiers standards de WordPress (qui seront écrasés lors d’une mise à jour…)

Modification du fichier wp-includes/general-template.php au niveau de la fonction get_bloginfo

case 'short_language':
  $output = get_locale();
  $short_language = explode("_", $output);
  $output = $short_language[0];
break;

Et ensuite au niveau de votre thème (par exemple iNove dans le fichier wp-content/themes/inove/templates/header.php) :

il suffit de modifier le formulaire comme ceci :

<form action="<?php bloginfo('home'); ?>/<?php bloginfo('short_language'); ?>/"
      method="get">

Amusez vous bien avec WordPress et WPML !

ps : au passage vous pouvez aussi modifier les liens title/home pour ne pas changer de langue quand on clic sur le logo

<h1 id="title">
  <a href="<?php bloginfo('url'); ?>/<?php bloginfo('short_language'); ?>/">
    <?php bloginfo('name'); ?>
  </a>
</h1>

et pour le fil d’ariane…

<a title="<?php _e('Home', 'inove'); ?>"
   href="<?php echo get_settings('home'); ?>/<?php bloginfo('short_language'); ?>/">
  <?php _e('Home', 'inove'); ?>
</a>

L’idée de départ vient de la lecture de cette conversation…

Si, comme moi, vous utilisez WPtouch pour gérer l’affichage de votre site en mode « iPhone »… je vous invite à utiliser le fichier de traduction que j’ai réalisé.

Il vous suffit d’ajouter le code suivant au début du fichier wptouch.php sous la ligne
define( 'WPTOUCH_PROWL_APPNAME', 'WPtouch');

/** l10n */
function wptouch_plugin_localization(){
  load_plugin_textdomain('wptouch', false, 'wptouch/locale');
}
add_action ('init', 'wptouch_plugin_localization');

Et de décompresser le fichier de traduction pour WPtouch 1.9.16 dans un dossier wptouch/locale

Vous devriez alors avoir l’aborescence suivante :

./wptouch/locale
./wptouch/locale/wptouch-fr_FR.mo
./wptouch/locale/wptouch-fr_FR.po

C’est tout !

L’interface utilisateur et administrateur de WPtouch sera alors traduite en français.

L’utilisation de ce « kit » est libre, n’hésitez pas à l’améliorer et à me faire part de vos commentaires !

Lire aussi :

• Bug
• Commentaire 27

La distribution Ubuntu 9.10 vient de sortir !

Au lieu dépenser de l’argent inutilement dans Windows Seven… et si vous passiez à Linux

Qui dit WebApp pour iPhone dit WebKit. Et derrière ce mot barbare se cache en fait quelques images au format PNG, une feuille de style CSS et une page de Javascript, le tout optimisé pour donner le look d’une application native pour iPhone à la moindre petite page web.

Oui mais voila… La guerre des WebKit fait rage ! Au commencement fût iUI, puis vint iWebKit et enfin WebApp.net (pourquoi choisir un pareil nom pour une librairie qui n’a strictement rien à voir avec le framework .Net Microsoft ? Si ce n’est pour surfer sur le hype de ce mot… pfff).

Je teste tous ces webkit depuis 1 mois dans le cadre de ma petite application iMedia (j’ai raccourci le nom initial iMediaLibrary). Et le constat au bout d’un mois c’est qu’aucun de ces webkit ne me convient.

Tous ont de qualités et des défauts. iWebKit est riche et bien documenté. iUI gère bien l’effet « slide » et a relativement peu de bugs. WebApp.Net est un peu un compromis entre les 2 mais c’est celui que j’ai le moins testé donc difficile de me prononcer définitivement.

Qu’on ne s’y trompe pas, derrière ces propos lapidaires j’ai beaucoup d’admiration pour tout ce travail et je suis impressionné par le niveau de ressemblance qu’une application web peut avoir avec une application native iPhone avec ces kits.

Mais au final, la principale frustration c’est de se dire que tous ces projets espèrent atteindre le même objectif… et qu’il serait beaucoup plus efficace de féderer tous ces efforts au sein d’un unique projet plutôt que disperser cette énergie.

Visiblement le syndrôme NIH (Not Invented Here) fait encore des ravages et je vais probablement contribuer à l’étendre en essayant de créer mon propre webkit pour essayer de faire une synthèse des bonnes idées qu’on trouve dans les webkits précédemment cités.

yaiWebKit : Yet Another iPhone Web Kit (en attendant de trouver mieux )

C’est donc le nom du projet que je commence à mener conjointement avec iMedia. Si cela vous interesse ou si vous participez déjà à un projet de WebKit pour iPhone, n’hésitez pas à me contacter !

Le principe de base sera de reproduire aussi fidèlement que possible l’interface graphique et le comportement natif d’une application iPhone… et de n’ajouter une fonctionnalité que lorsque la version courante comporte zéro bug… Autant dire que je ne suis pas prêt d’avoir un webkit aussi riche que iWebKit Mais comme le but à court terme est de fournir une librairie pour iMedia et pas plus, ce n’est pas forcément très grave.

A suivre…