Archives de
Auteur/autrice : Edouard

suEXEC et les liens symboliques

suEXEC et les liens symboliques

Je suis chez OVH depuis bientôt 4,5 ans. J’apprécie leur fiabilité, par contre j’ai toujours été un peu déçu par la documentation. En fait, OVH c’est un peu le Free de l’hébergement : c’est top quand ça marche, après c’est un peu plus compliqué… Pour finir sur OVH, car ce n’est pas l’objet de ce billet, j’ai le sentiment d’un changement de stratégie commercial qui me fait douter sur la pérennité de mon abonnement chez eux.

Revenons-en à nos moutons. OVH implémente suEXEC sur ses hébergements mutualisés (sûrement à leur sauce). La documentation de suEXEC n’est pas des plus claire et elle a toujours manqué d’exemple. Enfin, on trouve encore moins d’information sur le site d’OVH.

Ce billet présente divers tests afin de mieux comprendre ce qu’on peut faire et ne pas faire quand suEXEC est activé.

Lire la suite Lire la suite

Ajouter des vidéo à vos billets

Ajouter des vidéo à vos billets

À en croire la littérature, rien n’est plus simple et pourtant… Vous trouverez ici un état de l’art et quelques informations que j’ai moi-même eu du mal à trouver pour résoudre certains dysfonctionnements.

De façon plus précise, cet article répondra peut-être à vos questions si :

  • vous souhaitez mettre en oeuvre uniquement les fonctionnalités d’HTML5 (par exemple pas de flash)
  • vous voulez une compatibilité maximale en terme de navigateur et plate-forme (iPad compris)
  • votre site utilise potentiellement SSL

Lire la suite Lire la suite

Télechargements multiples de média sous WordPress

Télechargements multiples de média sous WordPress

À l’heure où j’écris ces lignes, WordPress est en version 3.2.1 et vient avec un outil Flash pour permettre le téléchargement multiple de fichiers. Seulement voilà, ça ne marche pas souvent et en terme de message d’erreur ce n’est pas très causant. Quand on utilise son moteur de recherche favori pour voir de quoi il retourne, on se rend compte qu’on n’est pas seul.

Dans mon cas, après un peu de recherche, j’ai réussi à en trouver l’origine. L’activation du SSL pour accéder à l’interface d’administration. Attendu que je me promène souvent et que je n’ai qu’une confiance limitée dans les réseaux WiFi que j’utilise, sécuriser l’accès à la plate-forme d’administration ne me semble pas du luxe, mais là, plus de téléchargement multiple via Flash.

Rapidement, j’ai trouvé un premier contournement à travers le plug-in « No SSL Flash Upload« . Il permet de contourner SSL pour le téléchargement. Ce n’est pas une panacée, en particulier vos données de cookie de connexion sont transmises en clair, mais bon… c’est déjà moins pire que de crier son mot de passe sur tous les toits. Et puis honnêtement, faire une centaine d’upload par mois à la main, c’est aussi un peu lourd. Bilan, le rapport avantages sur inconvénients(risques) me semblait plutôt favorable.

Jusqu’à ce que je mette en place un site privé sous SSL avec une authentification HTTP en entrée. Et là, plus de téléchargement multiple à nouveau. Grrr !!!

J’étais un peu désespéré jusqu’à ce que je tombe sur le plug-in « Upload Media by Zip« . Ce plug-in se base sur la forme standard de téléchargement de média pour WordPress (pas la version Flash). La contrainte est de devoir envoyer un fichier zip de tous vos médias. Dans mon cas, que j’utilise 7zip ou la fonction « Créer une archive compressée » du Mac, tout fonctionne sans problème. En plus, tout reste chiffré, puisqu’il n’y a pas de contournement du SSL. Seul bémol : pour le moment, il faut aller modifier certaines lignes du code du plug-in selon la configuration de votre serveur. Ce n’est pas difficile, mais ça peut paraître rédhibitoire pour certains.

Partager des instances wordpress sans activer le multisite

Partager des instances wordpress sans activer le multisite

Hébergé chez OVH, je cherchais à mettre en place plusieurs instances WordPress avec différents droits d’accès, mais pointant sur un même moteur pour simplifier les mises à jour. J’ai commencé par regarder du côté de la fonction multisite de WordPress 3 et je dois reconnaitre que j’ai eu un peu peur du côté usine à gaz de la chose en comparaison de la simplicité de ce que je voulais faire, en plus il fallait aller toucher au *.mon-domaine.com et je n’en avais pas trop envie.

Bilan, j’ai utilisé les outils à disposition (réduits au minimum chez OVH : du FTP et le manager qui permet de créer des sous-domaines) et des fonctionnalités historiques et simples de WordPress. Je dispose mainenant de 3 instances selon l’architecture suivante :

  • www.e-gaulue.com et e-gaulue.com qui correspondent à mon blog principal
  • family.e-gaulue.com qui correspond à un site à accès restreint sur la base d’une authentification HTTP au dessus d’un criptage SSL
  • test.e-gaulue.com que j’utilise pour mes tests de plugins…

Tous partagent un seul et unique moteur WordPress.

Lire la suite Lire la suite

Faire touner une application Java « ppc » (JDiskReport) sous OS X Lion

Faire touner une application Java « ppc » (JDiskReport) sous OS X Lion


Lion ne supporte plus rosetta. Or, comme je suis un utilisateur de JDiskReport pour visualiser l’utilisation de mon disque et que celui-ci vient avec un java (JavaApplicationStub) compilé pour PowerPC, l’application a été marquée comme non compatible. Un peu hallucinant pour une application Java.

Qu’à cela ne tienne, le contournement est simple. Si vous avez installé Java pour Lion, vous devriez trouver un fichier JavaApplicationStub quelque part par là :
/System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub.

Copiez-le en lieu et place de celui qui figure dans le package. À partir d’ici, c’est presque bon, sauf que le système a semble-t-il gardé en mémoire que l’application n’était pas compatible Lion. A partir de là, je ne me souviens plus trop de ce que j’ai fait, mais je dirais a priori que renommer l’application, l’exécuter, puis revenir au nom d’origine doit faire le « job ».

C’est bien entendu valable pour d’autres applications que JDiskReport.

Un long silence

Un long silence

Combien de temps ? Presque deux ans et demi depuis le dernier message. Qu’il était prétentieux de penser pouvoir tenir un blog en parallèle d’un travail très prenant et de l’arrivée de 3 enfants.

Voici donc un blog remis à jour, en principe plus sûr… mais, vous savez, c’est de l’informatique. Il tourne sur un thème « twentyten » modifié. Le module multilang ne fonctionne plus, j’y travaillerai peut-être, mais c’est encore une tâche qu’il ne faut pas sous-estimée.

Vous trouverez également une nouvelle zone « family » destinée aux amis de la famille. Ceux qui souhaitent y accéder et n’ont pas encore d’identifiant peuvent me contacter.

Plusieurs articles sont déjà en préparation. Donc à très bientôt.

Zdmultilang v1.2.2 est sorti

Zdmultilang v1.2.2 est sorti

Une nouvelle version de zdmultilang est sortie. Pour plus d’info, allez voir sur son site officiel.

J’ai regardé les modifications qui ne remettent pas en cause le travail que j’avais fait pour gérer les widgets. J’ai toutefois fait un diff des 2 versions et je peux fournir un nouveau fichier : zd_multilang avec support multilingue des widgets.

Il doit permettre une installation sur une v.1.2.2 et inférieur de zdmultilang.

Travail autour du plugin zdmultilang

Travail autour du plugin zdmultilang

Après avoir testé plusieurs plugins multilingues pour wordpress (xLanguage, qTranslate et gengo), je me suis arrêté sur zdmultilang.

Ce dernier correspondait à ce que je recherchais : la possibilité de gérer les traductions pratiquement comme de nouvelles pages/articles mais avec une relation particulière avec la source. Par ailleurs, afin de respecter au mieux l’esprit plugin, je cherchais aussi quelque chose qui laisse la plate-forme directement opérationnelle en cas de désactivation.

Les seuls points qui manquaient par rapport à mon usage tournaient autour de la gestion des widgets. Je me suis donc attelé à ajouter cette fonctionnalité que je décris ici.

La normalisation des widgets

WordPress utilise toujours le même schéma pour le stockage des données de widgets : il s’agit d’un tableau associatif nom du paramètre/valeur qui est enregistré dans la table wp_option de la base à travers les fonctions get_option et update_option. Aussi dans un premier temps, j’ai remis au format le widget zd_multilang pour se conformer à ce standard.

Vers des options par langue

Zdmultilang gère déjà des options par langue : blogname et blogdescription dans la table wp_zd_ml_langs. Néanmoins, si nous souhaitons gérer les paramètres de widget par langue nous allons devoir changer d’architecture. Mon choix a été de créer une table wp_zd_ml_options dont la structure se base sur la table wp_options où j’ai ajouté un champ LanguageID. Cette table contiendra toutes les options dont je souhaite conserver une version spécifique par langue. J’en ai profité pour y mettre blogname et blogdescription, cet emplacement me semblant désormais plus légitime.

Comment construire dynamiquement les hooks pour nos widgets ?

Comme indiqué plus haut, les paramètres des widgets sont stockés dans la table wp_options. Afin de rester au plus proche de l’architecture WordPress, il m’a semblé judicieux d’associer des fonctions aux hooks pre_option_... et pre_update_option_...... correspond au nom du widget. L’utilisation des hooks « pre » permet de sortir des fonctions initiales get_option ou update_option presque immédiatement. Cela nécessite par contre de réécrire des fonctions analogues dans le plugin. Par souci d’homogénéité, presque toutes les fonctions d’accès aux options ont été réécrites : get_option, update_option, add_option, load_alloptions. Elles l’ont été en s’inspirant des fonctions WordPress initiales afin de tirer parti des outils de cache alloption et notoption évitant autant de requêtes vers la base de données. Ceci est d’autant plus utile dans notre cas que tous les widgets n’ont pas de paramètres, or comme nous ne pouvons le savoir à l’avance nous sommes obligés de créer des hooks pour tous les widgets enregistrés (voir plus quand leur dénomination ne suit pas la nomenclature WordPress). Si un widget n’a pas de paramètre, on ressortira alors très vite des fonctions que nous avons réécrites sans solliciter plus la base de données que les fonctions initiales.

Ensuite, il reste à associer ces fonctions aux hooks. Pour cela nous parcourons le tableau de hachage $wp_registered_widgets et pour chaque widget enregistré nous construisons dynamiquement une fonction triviale qui pointera vers les fonctions réécrites dont il est question plus haut.

foreach($wp_registered_widgets as $widget_name => $widget) {
	$funcname = 'zd_multilang_get_option_'.$widget['classname'];
	$function = "function $funcname".'() {
			$option=str_replace("zd_multilang_get_option_","",__FUNCTION__);
			return zd_multilang_get_option($option);
			}');
	eval($function);
	add_filter('pre_option_'.$widget['classname'], $funcname);
}

Notons qu’une fois tous ces hooks installés, on peut relancer la commande wp_widgets_init() qui réinitialise tous les widgets. Cependant, cette fois-ci, compte tenu des filtres installés, on ira chercher les paramètres dans notre table wp_zd_ml_options. Ça tombe bien : c’était notre objectif.

Comment conserver nos « sidebars » par langue ?

Les colonnes latérales s’enregistrent dans les thèmes.A priori, nous ne savons pas combien il y en a. L’idée est de conserver dans une option supplémentaire un équivalant de l’option sidebars_widgets qui contient les informations sur le contenu des colonnes latérales. Notre option contiendra les informations de nb de sidebars dans le thème x nb de langues gérées par zd_multilangue. Ensuite, il s’agira de reconstruire à la volée le résultat que WordPress s’attend à trouver en fonction du contexte (lecture simple ou paramètrage des widgets).

Comment permettre l’enregistrement des informations de widget pour les utilisateurs ?
À l’origine je souhaitais faire un écran de configuration des widgets par langue un peu comme zdmultilang gère les catégories, les étiquettes… Cependant, la gestion des widgets par WordPress (wp-adminwidgets.php) est loin d’être évidente (possibilité de javascript ou non, récupération des données de modification dans la même page que la présentation…). Aussi, j’ai fini par me résigner à ajouter un sélecteur de langue à la page traditionnelle d’administration des widgets. Là encore, les hooks mis à disposition par WordPress ne sont pas des plus pratiques, mais on finit toutefois par y arriver.
Copie d'écran du sélecteur de langue dans le gestionnaire de widget
Comment tester ces modifications du plugin ?
Vous pouvez accéder à mon code en suivant ce lien : zd_multilang avec support des widgets en multilingue, mais attention il est fourni avec le statut : it works for me. Par ailleurs, vous risquez de perdre vos données blogname et blogdescription par langue si vous décidez de revenir à une version antérieure.

N’hésitez pas toutefois à laisser vos commentaires.

De retour sur la Toile

De retour sur la Toile

Chers amis, si vous saviez comme je suis heureux de vous retrouver. Pourquoi un tel silence ? L’envie de me mettre au blog a germé dans mon précédent travail où je bénéficiais d’un peu plus de temps pour m’intéresser à ces choses là. En plus de cela, l’arrivée de Lucile a bien changé la donne.

Et puis, il fallait que je me sente à l’aise avec l’outil. Cela passait par une maîtrise de WordPress. Nous partions de loin : un WordPress installé à la va-vite basé sur un style récupéré sur le net (clean-cut de mémoire) légèrement modifieé. Assez vite, je me suis senti contraint par la pagination et le manque d’un outil de traduction pour pouvoir écrire des billets très techniques en informatique à la fois en français et en anglais. J’ai essayé de regarder directement ce que l’on pouvait faire avec des idées simples mais qui ne répondaient pas véritablement à mon besoin et et puis un soir, tard, un peu au hasard je suis tombé sur zdmultilang.

Il correspondait bien à ce que je voulais faire mais il manquait quelques éléments rédhibitoires pour moi (en particulier la gestion des widgets). J’ai passé une bonne partie de mes soirées de Noël sur le sujet et je suis parvenu à quelque chose de satisfaisant le 11 janvier 2009.

Quelques jours après, s’en suis donc cette reprise. Rappelez-vous, c’était hier : mon premier blog.

Copie d'écran de mon premier blog

Bienvenue à Lucile

Bienvenue à Lucile

Alors que je créais ce blog, j’espérais pouvoir écrire un article toutes les 2 à 3 semaines et puis Lucile est arrivée le 30 septembre 2007.

Pour fêter ça, Rémi, son ainé, a décidé de changer l’heure du réveil à 6 h… Aussi, l’ensemble a donné lieu à 2 mois plus difficiles que je ne l’imaginais mais bon… Ils le méritent bien.

Aujourd’hui Lucile fait ses nuits depuis une semaine, Rémi se réveille à nouveau vers 7 h. Certes, il n’y a pas encore de nuit parfaite où il n’est pas nécessaire de se réveiller pour aller voir soit l’un soit l’autre mais on y tend !