Archives de
Catégorie : Informatique

Sujets informatiques.

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.

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.