Hop, un petit aide-mémoire à propos du plugin WP-Table Reloaded pour WordPress sur un serveur avec patch suhosin.
Sur des gros tableaux, impossible de faire la moindre mise à jour en live du tableau, car le patch suhosin limite (c’est son rôle) la taille de certains formulaires, longueurs de noms de variables etc, ou alors, il tronque certains tableaux.
Seul l’import initial se passe bien. Ensuite, c’est la galère.

La solution ?

Il faut régler suhosin plus finement (et non pas le désactiver comme recommandent beaucoup de personnes pour dégager le problème vite fait mal fait).

Pour connaître précisément votre config suhosin sur un site donné, vous pouvez utiliser un appel à phpinfo() en PHP.

Ensuite, sur un site ayant des tableaux de 1500 lignes, j’ai dû, à force d’alertes suhosin dans /var/log/user.log, modifier ces valeurs dans mon VirtualHost :

php_value suhosin.post.max_array_index_length 0
php_value suhosin.get.max_array_index_length 0
php_value suhosin.request.max_array_index_length 0
php_value suhosin.post.max_vars 0
php_value suhosin.get.max_vars 0
php_value suhosin.request.max_vars 0
php_value suhosin.post.max_name_length 0
php_value suhosin.get.max_vars 0
php_value suhosin.request.max_vars 0
php_value suhosin.memory_limit 512M

C’est une première étape qui permet de voir si ça règle bien le problème. Ensuite, il faut affiner pour ne pas tolérer de l’illimité (0), mais des valeurs réalistes.
Il restait un dernier blocage à 1000 lignes, cette fois la conf de base PHP, j’ai modifié ceci puis affiné :
php_value max_input_vars 10000

Un reload Apache et le tour était joué.

Ca se passe comme d’habitude pour un plugin bien fait sous WordPress :
- Téléchargez le zip dans /votre/serveur/wp-content/plugins/
- Dézippez la chose, ça crée un sous-répertoire wptouch dans « plugins »
- Rendez-vous dans la page d’administration de WordPress, section plugins, pour l’activer. C’est-tout-ça-marche.

Il y a des options, notamment pour l’intégration de pubs Ad-Sense. Je n’ai pas cherché, les sites sur lesquels je l’ai activé s’en passeront très bien.

Un must !

Sur certains sites que j’ai créés sous WordPress, j’utilise certains plugins assez géniaux, comme NextGen-Gallery pour des galeries de photos faciles et jolies et aussi wp-table (et maintenant wp-table-reloaded) pour gérer des tableaux facilement et sans pondre un code bancal (sans compter les fonctions d’import depuis fichiers CSV, tri par colonne etc)

Sur un de mes sites, j’ai hésité à passer en 2.8 suite à une remarque lue par rapport à NextGen-Gallery indiquant qu’on risquait de péter une limite mémoire. Je n’ai donc pas encore testé (manque de temps histoire d’éviter le gros downtime sur le site…)
C’est sur wp-table que j’ai eu un problème, je vous en fais part car la solution est triviale, alors que le problème est de taille.

Lorsqu’on cherche un plug-in pour gérer les tables facilement, sous wordpress, on tombe en premier lieu sur un plug-in nommé wp-table. Si on ne fait pas gaffe, on ne voit pas qu’il est validé pour WordPress 2.3 max… Bon, à part ça, jusqu’à wordpress 2.7 (et même 2.8 bleeding edge), ça tourne bien.
Mais en 2.8 officielle, ça tourne de manière bancale : les tables sont bien intégrées (bonnes balises dans le code) lorsqu’on les voit dans un article. Mais si on les voit en naviguant dans les « catégories » ou « tags » d’article, les balises HTML/CSS ne sont pas positionnées. Résultat, un tableau dégueulasse, du ligne à ligne sans aucune mise en page.

Grosso-modo : le code appelant les vues par catégories et par tags a dû fortement changer et le plug-in n’est pas inséré où il faut en 2.8…

Panique : il faut vite trouver un plug-in correct et exporter/réimporter tout. L’horreur en perspective.
En recherchant cette fois un plug-in potable en 2.8 p our les tables, on tombe sur « wp-table Reloaded » valide en 2.8. Tiens tiens…
C’est carrément extra : après l’installation (wget+unzip+activate, comme d’hab), le menu d’import trouve tout seul les tables crées par le vieux wp-table dont il semble être issu. Vu le nom, remarquez, ça semble presque logique.
Résultat, à part une réindexation des numéros de tables (on recommence à 1) et la balise « table » entre crochets qui change un peu (donc tous les « posts » et « pages » à modifier un peu), le boulot est vite torché.
Reste que le CSS par défaut des tables me semble un peu light.
Le tri par colonne existe toujours, mais il nécessite un plugin JQuery. Je ne l’ai pas encore mis en place, mais ça ne semble pas compliqué.

Si vous connaissez mieux comme plug-ins de galerie photos et de gestion de tables, n’hésitez pas à en faire part. Les notations sur la page de plug-ins de WordPress sont assez légères (en général plusieurs dizaines de votes pour des dizaines de milliers de download), il est donc difficile parfois de voir si un plug-in tient la route ou pas…

Bloggez bien.

Dans les dernières versions, on voit des options pour protéger par mot de passe un article (ou une page). Mais ça s’arrête là, mais ça peut suffire dans bien des cas.
J’avais besoin de monter un site rapidement avec quelques pages statiques et des news, facilement éditables. WordPress convenait donc, mais dans un contexte entreprise, il fallait priver l’intégralité de l’accès.
En cherchant un peu, on trouve donc 2 plug-ins parfaits pour ça.
Voici ce retour d’expérience : installer WordPress avec authentification LDAP et contenu complètement privé (members-only).

Installation

Je suis parti sur une version SVN (la 2.6.2) car elle permet d’utiliser des plug-ins récents, qui ne fonctionnent pas pour ma version “stable” Debian (2.0.x). J’ai donc tout fait à la main, je vous résume ceci.

Préparation de la base MySQL

En console mysql, vous taperez par exemple :

CREATE DATABASE wordpress;
CREATE USER ‘wpadmin’@'localhost’ IDENTIFIED BY ‘mon_passwd’;
GRANT ALL ON wordpress.* TO ‘wpadmin’@'localhost’;

Ceci vous crée la base vide et un utilisateur d’administration.

Installation et configuration de l’application

Je schématise, côté OS et téléchargement de l’application :

mkdir /srv/www/wordpress
cd /srv/www/wordpress
svn co http://svn.automattic.com/wordpress/trunk/

Vous éditerez alors votre fichier /srv/www/wordpress/trunk/wp-config.php pour y renseigner au moins les champs suivants :

define(’DB_NAME’, ‘wordpress’);
define(’DB_USER’, ‘wpadmin’);
define(’DB_PASSWORD’, ‘mon_passwd’);
define(’DB_HOST’, ‘localhost’);

Vous ajouterez la conf Apache qui va bien (VirtualHost ou non), avec au moins ceci :

< Directory> # sans l'espace
    Options FollowSymLinks
    AllowOverride Limit Options FileInfo
    DirectoryIndex index.php
< /Directory> # sans l'espace

Du classique, je ne détaille pas trop, je me concentre sur WordPress, pas Apache2.

Lancement de l’installeur

Ensuite, vous irez sur http://votre_site/votre_blog/wp-admin/install.php pour lancer l’installation en 2/3 clics.
Vous voilà avec un wordpress tout vide et opérationnel.
Je passe sur le tour du propriétaire, j’enchaîne directement sur le choix et l’installation des plug-ins qui vont bien.

Les plug-in LDAP

Il y en a plusieurs, plus ou moins suivi, plus ou moins compatibles avec votre version de WordPress. J’ai trouvé sur le site notamment celui-ci (wpDirAuth) compatible avec plein de LDAP, notamment OpenLDAP.
Après 2 heures de galère, on apprend que la version officielle sur ce site (1.2) n’est pas compatible avec WordPress 2.6+.
Vous utiliserez donc la version 1.3 disponible ici.
L’installation est classique, en gros :

cd /srv/www/wordpress/trunk/wp-content/plugins
wget http://www.royal.wednet.edu/~ayearout/wpDirAuth-1.3.zip
unzip wpDirAuth-1.3.zip

Puis activation du plugin dans l’interface d’administration de WordPress. Classique. Son paramétrage ressemble à ceci, très complet :

Plug-in “members-only”

Enfin, ce plug-in permet de faire en sorte qu’il faille être connecté pour accéder au moindre contenu. Par défaut, vous êtes donc redirigé vers la page d’authentification.

Et voilà le travail