Images non trouvées dans mpdf: pb dns, curl?

Bonjour,

Sur un plugin wordpress de génération de pdf avec la bibliothèque mpdf, il apparait que les images ne sont plus trouvées, alors que cela fonctionnait bien quelques jours auparavant.

Le debug mpdf indique:

mPDF error: IMAGE Error (http://*/boutique/files/2014/09/logo-v3b.jpg): Could not find image file

alors que l’url affiche bien l’image (donc url bonne et image accessible)

Ce problème pourrait être lié à la mise à jour de wp, sauf que le mpdf n’a pas été modifié et que c’est bien d’un pb lié à mpdf qu’il s’agit, d’après le debug de mpdf.

D’après certains forums, il semblerait que la cause du pb puisse être que la résolution DNS du serveur par lui-même ne fonctionne pas; cependant un “dns_get_record” semble bien retourner les bonnes infos.

Des idées ?
merci d’avance

Bon, ben c’est pas la grande forme, apparemment!

J’ai progressé et confirme que c’est sans doute bien un pb lié au serveur ouvaton, lié à la résolution de nom probablement.
J’ai fait un script test en dehors de wordpress.
Si je mets une image dans mon domaine, j’ai le message d’erreur (voir plus haut)
Si je mets une image extérieure, le pdf est bien généré avec l’image correcte.

donc je passe un ticket sur l’assistance

source:

<?php //I: send the file inline to the browser. The plug-in is used if available. The name given by filename is used when one selects the "Save as" option on the link generating the PDF. //D: send to the browser and force a file download with the name given by filename. //F: save to a local file with the name given by filename (may include a path). //S: return the document as a string. filename is ignored. $output_mode='D'; ///alm // The library for generating HTML PDF files if (!include('../mpdf/mpdf.php')) { echo ('erreur'); } // Some PDF settings.. $mpdf = new mPDF('utf-8','A4','','',10,10,10,10,10,10); $mpdf->useOnlyCoreFonts = true; // false is default $mpdf->SetProtection(array('print')); $mpdf->SetDisplayMode('fullpage'); ///alm ob_start(); $mpdf->debug = true; $mpdf->showImageErrors=true; ?>

test mpdf

<?php

$output = ob_get_contents();
ob_end_clean();
//echo $output;
//exit();

// Do the trick!
$mpdf->WriteHTML($output);
//wlog(LOG,$output);

// Create filename.
$filename = ‹ test.pdf ›;

// create destination
if ($output_mode==‹ I › || $output_mode==‹ D ›) {
$dest = $filename;
} else {
$dest = $uploads_dir.’/’.$filename;
}

/// output
$mpdf->Output($dest, $output_mode);
exit();
?>

pb résolu grâce à Gurvan:
en réalité, les appels du type get_headers retournent un code d’erreur 412 sur ouvaton à cause d’une sécurisation web firewall, ce qui correspond à une requête mal formée
Array
(
[0] => HTTP/1.1 412 Precondition Failed
[1] => Server: Varnish
[2] => Content-Type: text/html; charset=utf-8
[3] => Accept-Ranges: bytes
[4] => Date: Thu, 16 Jul 2015 06:57:31 GMT
[5] => X-Varnish: 286365916
[6] => Age: 0
[7] => Via: 1.1 varnish
[8] => Connection: close
[9] => X-Cache: MISS
)

Il faut mettre un user_agent pour que la requête aboutisse correctement: un ini_set(‘user_agent’, ‘Mozilla/5.0’); fait l’affaire
A noter que toutes les requêtes faites par wordpress sont correctes (les classes http positionnent le user_agent).
Comme la bibliothèque mpdf ne passe pas par les classes wordpress et ne positionne pas le user_agent, et ne permet pas de le faire apparemment, l’erreur s’explique ainsi; ce qui ne s’explique pas, c’est pourquoi dans le contexte wordpress ça fonctionnait (ce qui sous-entendrait que le user_agent était positionné) avant et que ça ne fonctionne plus, j’ai cherché dans les sources wordpress, mais n’ai rien trouvé.
Pour résoudre le pb dans wordpress, j’ai trouvé de mettre dans les mu-plugins

global $wp_version;
ini_set(‘user_agent’,apply_filters( ‘http_headers_useragent’, ‘WordPress/’ . $wp_version . '; ’ . get_bloginfo( ‘url’ ) ));

ça règle le pb.