Bonjour,

Le plugin externalLinks est ton ami :)

De ce que je vois, c'est la ligne 203 de ton style.css qui pose problème, notamment le font Genericons qui n'est pas ignoré chez moi.

:after, :before {vertical-align:middle;/* font: normal 100%/1 'Genericons'; */display: inline-block;-webkit-font-smoothing: antialiased;-moz-osx-font-smoothing: grayscale;}

Si tu as l'occasion de retester avec la nightly à venir, je suis preneur de tes retours...

oui. Ce qu'il faut savoir c'est que le ta fonction renvoit du code php qui sera compilé dans une page php à part.
Si tu fais ton affichage directement dans ta fonction, il sera fait avant l'inclusion de la page php, et donc ton var_dump se fera probablement en début de page générée.

$_ctx n'existe pas quand tu es dans ta fonction, il faut que tu retournes tout le code php :

public static function form($attr, $content)
    {
    	return '<?php
        $_ctx =& $GLOBALS[\'_ctx\'];
        $_ctx->formData->content = json_decode($_ctx->formData->form_fields)->fields; 
         foreach ($_ctx->formData->content as $f): ?>'.$content.'<?php endforeach; ?>';
    }

Il suffit que tes balises génèrent le code php qui va bien :
<tpl:Form>...</tplForm> génère :

<?php foreach ($_ctx->form as $f): ?>.$content.<?php endforeach; ?>

et ton {{tpl:FormItemLabel}} génère :

  <?php echo $f['label']; ?>

En mode "php", OVH sépare ses serveurs en 2 parties : des serveurs dédiés au traitement de php, et des serveurs dédiés à la fourniture de fichiers statique. Manque de bol, le admin/index.php?pf=... est un traitement php qui récupère un fichier statique. Pour une raison que seul OVH maîtrise, cela signifie que les serveurs php doivent aller requêter les serveurs fournissant les fichiers statiques, et visiblement ce n'est pas *du tout* optimisé de ce point de vue là chez eux...

Le mode phpcgi, ces "optimisations" sont absentes, et bizarrement ça fonctionne mieux.

Le problème est exactement le même pour la génération des miniatures par exemple (récupération d'un fichier statique pour le traiter).

Et je suppose qu'en plus de ton simple commentaire sur le blog de dotclear, tu as fait un rapport détaillé pour dire quels étaient les bugs ?

Si tu dis à ton, garagiste "ça marche pas" sans plus de détails, il risque de bien se marrer, et te facturer plein de réparations qui n'ont pas lieu d'être...

Désolé, notre boule de cristal est cassée, on a du mal a deviner les bugs...

C'est malheureusement un problème récurrent chez eux. Dès lors qu'un script php cherche à délivrer un fichier qu'il lit sur le disque, ça devient très lent. Je ne vois pas vraiment de contournements à ce problème :/

Hello Stefan,

Many thanks for your contribution. You can send them directly to contact@doclear.net

C'est un bug identifié, et corrigé pour la prochaine version.

cf. http://forum.dotclear.org/viewtopic.php … 29#p334229 si tu veux patcher en attendant

C'est effectivement un bug de la 2.8, il a été corrigé sur la version de dev.

En attendant la 2.8.1, remplace le fichier inc/core/class.dc.core.php par celui-là

tu peux essayer de faire un

ALTER TABLE dc_post 
    PARTITION BY HASH(blog_id)
    PARTITIONS 10

(à essayer sur un site de dev avant, hein)

En théorie cela ne change que les rouages internes de mysql, c'est censé être transparent pour l'appli...