Salut,
Je génère un rapport HTML avec des graphiques générés par GD2 qui
sera lancé par un "cron" (actuellement sous windows je lance par
"php.exe monscript.php")
pour tester la fonctionnalité j'utilise ce script :
ob_start();
$img=ImageCreateFromPng("img/test.png");
ImagePng($img,NULL);
$data=ob_get_contents();
ob_end_clean();
addIMG($data); //cette fonction ajoute l'image encodée en base64
au mail
avec le navigateur ça marche (youpi!)
mais en lançant dans une fenêtre de commande j'ai l'erreur
Fatal error: Call to undefined function ImageCreateFromPng() in C:
\wamp\www\mail.php on line 140
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine Polatouche
Salut, Bonjour,
Je génère un rapport HTML avec des graphiques générés par GD2 qui sera lancé par un "cron" (actuellement sous windows je lance par "php.exe monscript.php")
<snip>
avec le navigateur ça marche (youpi!) mais en lançant dans une fenêtre de commande j'ai l'erreur
Fatal error: Call to undefined function ImageCreateFromPng() in C: wampwwwmail.php on line 140
Comme si la bibliothèque GD n'était pas disponible. C'est normal ? Il y a quelque chose à faire ?
Est-ce que tu utilise le même executable php dans les deux cas? Ajoute un phpinfo() pour voir quel php.ini est utilisé dans l'un et l'autre cas. Ca peut-être une cause...
Salut,
Bonjour,
Je génère un rapport HTML avec des graphiques générés par GD2 qui
sera lancé par un "cron" (actuellement sous windows je lance par
"php.exe monscript.php")
<snip>
avec le navigateur ça marche (youpi!)
mais en lançant dans une fenêtre de commande j'ai l'erreur
Fatal error: Call to undefined function ImageCreateFromPng() in C:
wampwwwmail.php on line 140
Comme si la bibliothèque GD n'était pas disponible.
C'est normal ? Il y a quelque chose à faire ?
Est-ce que tu utilise le même executable php dans les deux cas?
Ajoute un phpinfo() pour voir quel php.ini est utilisé dans l'un et
l'autre cas. Ca peut-être une cause...
Je génère un rapport HTML avec des graphiques générés par GD2 qui sera lancé par un "cron" (actuellement sous windows je lance par "php.exe monscript.php")
<snip>
avec le navigateur ça marche (youpi!) mais en lançant dans une fenêtre de commande j'ai l'erreur
Fatal error: Call to undefined function ImageCreateFromPng() in C: wampwwwmail.php on line 140
Comme si la bibliothèque GD n'était pas disponible. C'est normal ? Il y a quelque chose à faire ?
Est-ce que tu utilise le même executable php dans les deux cas? Ajoute un phpinfo() pour voir quel php.ini est utilisé dans l'un et l'autre cas. Ca peut-être une cause...
Olivier Miakinen
Je génère un rapport HTML avec des graphiques générés par GD2 qui sera lancé par un "cron" (actuellement sous windows je lance par "php.exe monscript.php")
[...]
Fatal error: Call to undefined function ImageCreateFromPng() in C: wampwwwmail.php on line 140
Comme si la bibliothèque GD n'était pas disponible.
Les paramètres de lancement en ligne de commande sont-ils les mêmes que depuis le serveur web ? Le php.ini est-il trouvé au même endroit ? Ou à deux endroits différents mais avec le même contenu ?
Je te suggère d'essayer le script suivant au lieu de celui qui appelle une fonction de GD :
Je génère un rapport HTML avec des graphiques générés par GD2 qui
sera lancé par un "cron" (actuellement sous windows je lance par
"php.exe monscript.php")
[...]
Fatal error: Call to undefined function ImageCreateFromPng() in C:
wampwwwmail.php on line 140
Comme si la bibliothèque GD n'était pas disponible.
Les paramètres de lancement en ligne de commande sont-ils les mêmes que
depuis le serveur web ? Le php.ini est-il trouvé au même endroit ? Ou à
deux endroits différents mais avec le même contenu ?
Je te suggère d'essayer le script suivant au lieu de celui qui appelle
une fonction de GD :
Je génère un rapport HTML avec des graphiques générés par GD2 qui sera lancé par un "cron" (actuellement sous windows je lance par "php.exe monscript.php")
[...]
Fatal error: Call to undefined function ImageCreateFromPng() in C: wampwwwmail.php on line 140
Comme si la bibliothèque GD n'était pas disponible.
Les paramètres de lancement en ligne de commande sont-ils les mêmes que depuis le serveur web ? Le php.ini est-il trouvé au même endroit ? Ou à deux endroits différents mais avec le même contenu ?
Je te suggère d'essayer le script suivant au lieu de celui qui appelle une fonction de GD :
Antoine Polatouche , le mar. 12 févr. 2008 07:52:21, écrivait ceci:
Salut, (je répond aussi à Olivier)
Est-ce que tu utilise le même executable php dans les deux cas? Ajoute un phpinfo() pour voir quel php.ini est utilisé dans l'un et l'autre cas. Ca peut-être une cause...
En effet, il y a 2 php.ini. Un dans .apache2bin et un dans .php l'interface wampmanager pointe dans celui d'apache et php dans l'autre. Au niveau configuration c'est un vrai bordel... je vais tout mettre à plat et uniformiser tout ça...
Merci à tous les 2 pour la piste en tout cas.
Antoine Polatouche <antoine@galacsys.com>, le mar. 12 févr. 2008
07:52:21, écrivait ceci:
Salut,
(je répond aussi à Olivier)
Est-ce que tu utilise le même executable php dans les deux cas?
Ajoute un phpinfo() pour voir quel php.ini est utilisé dans l'un et
l'autre cas. Ca peut-être une cause...
En effet, il y a 2 php.ini. Un dans .apache2bin et un dans .php
l'interface wampmanager pointe dans celui d'apache et php dans l'autre.
Au niveau configuration c'est un vrai bordel... je vais tout mettre à
plat et uniformiser tout ça...
Antoine Polatouche , le mar. 12 févr. 2008 07:52:21, écrivait ceci:
Salut, (je répond aussi à Olivier)
Est-ce que tu utilise le même executable php dans les deux cas? Ajoute un phpinfo() pour voir quel php.ini est utilisé dans l'un et l'autre cas. Ca peut-être une cause...
En effet, il y a 2 php.ini. Un dans .apache2bin et un dans .php l'interface wampmanager pointe dans celui d'apache et php dans l'autre. Au niveau configuration c'est un vrai bordel... je vais tout mettre à plat et uniformiser tout ça...
Merci à tous les 2 pour la piste en tout cas.
Gilles RONSIN
Gilles RONSIN , le mar. 12 févr. 2008 09:53:19, écrivait ceci:
Pour info : j'ai créé une jonction pour que le php.ini du répertoire php pointe sur le php.ini du répertoire appache2bin et tout roule. Il ne me reste plus qu'à réussir à générer mes graphiques. C'est le plus dûr à cause des fonctions asynchrones qui font que mes graphiques ne sont pas encore dessinés quand je devrait les traiter. Merci pour vos coups de main.
Gilles RONSIN <nomail@please.invalid>, le mar. 12 févr. 2008
09:53:19, écrivait ceci:
Pour info :
j'ai créé une jonction pour que le php.ini du répertoire php pointe sur
le php.ini du répertoire appache2bin
et tout roule.
Il ne me reste plus qu'à réussir à générer mes graphiques. C'est le
plus dûr à cause des fonctions asynchrones qui font que mes graphiques
ne sont pas encore dessinés quand je devrait les traiter.
Merci pour vos coups de main.
Gilles RONSIN , le mar. 12 févr. 2008 09:53:19, écrivait ceci:
Pour info : j'ai créé une jonction pour que le php.ini du répertoire php pointe sur le php.ini du répertoire appache2bin et tout roule. Il ne me reste plus qu'à réussir à générer mes graphiques. C'est le plus dûr à cause des fonctions asynchrones qui font que mes graphiques ne sont pas encore dessinés quand je devrait les traiter. Merci pour vos coups de main.
Mickaël Wolff
Au niveau configuration c'est un vrai bordel... je vais tout mettre à plat et uniformiser tout ça...
Pour quelqu'un qui travail sous MS Windows, ça ne m'étonne pas d'entendre ça. S'il y a deux fichiers de configuration, c'est qu'il y a une raison.
Je travaille classiquement avec des distribution Debian GNU/Linux ou dérivé. PHP est disponible sous forme de paquets. Chez moi sont installés php-bin, php-cgi et libapache2-mod-php5. Pour chacun de ces paquets, un fichier de configuration existe :
C'est fait ainsi parce que certaines options de configuration de PHP ne sont pas forcément pertinentes pour une exécution en ligne de commande ou en module PHP. Par exemple, quel est l'intérêt pour la version module Apache PHP de charger le module PHP GTK+ ? Les applications CLI doivent-elles partager le même fichier de log des erreurs que le module Apache ?
Aussi je te conseille de revenir en arrière, et à considérer que le PHP en ligne de commande n'est pas exactement le même que le PHP chargé en module. Il doit bien y avoir une option dans le package que tu as installé pour pouvoir configurer le PHP dans chacune de ces utilisations.
Au niveau configuration c'est un vrai bordel... je vais tout mettre à
plat et uniformiser tout ça...
Pour quelqu'un qui travail sous MS Windows, ça ne m'étonne pas
d'entendre ça. S'il y a deux fichiers de configuration, c'est qu'il y a
une raison.
Je travaille classiquement avec des distribution Debian GNU/Linux ou
dérivé. PHP est disponible sous forme de paquets. Chez moi sont
installés php-bin, php-cgi et libapache2-mod-php5. Pour chacun de ces
paquets, un fichier de configuration existe :
C'est fait ainsi parce que certaines options de configuration de PHP
ne sont pas forcément pertinentes pour une exécution en ligne de
commande ou en module PHP. Par exemple, quel est l'intérêt pour la
version module Apache PHP de charger le module PHP GTK+ ? Les
applications CLI doivent-elles partager le même fichier de log des
erreurs que le module Apache ?
Aussi je te conseille de revenir en arrière, et à considérer que le
PHP en ligne de commande n'est pas exactement le même que le PHP chargé
en module. Il doit bien y avoir une option dans le package que tu as
installé pour pouvoir configurer le PHP dans chacune de ces utilisations.
Au niveau configuration c'est un vrai bordel... je vais tout mettre à plat et uniformiser tout ça...
Pour quelqu'un qui travail sous MS Windows, ça ne m'étonne pas d'entendre ça. S'il y a deux fichiers de configuration, c'est qu'il y a une raison.
Je travaille classiquement avec des distribution Debian GNU/Linux ou dérivé. PHP est disponible sous forme de paquets. Chez moi sont installés php-bin, php-cgi et libapache2-mod-php5. Pour chacun de ces paquets, un fichier de configuration existe :
C'est fait ainsi parce que certaines options de configuration de PHP ne sont pas forcément pertinentes pour une exécution en ligne de commande ou en module PHP. Par exemple, quel est l'intérêt pour la version module Apache PHP de charger le module PHP GTK+ ? Les applications CLI doivent-elles partager le même fichier de log des erreurs que le module Apache ?
Aussi je te conseille de revenir en arrière, et à considérer que le PHP en ligne de commande n'est pas exactement le même que le PHP chargé en module. Il doit bien y avoir une option dans le package que tu as installé pour pouvoir configurer le PHP dans chacune de ces utilisations.
Pour quelqu'un qui travail sous MS Windows, ça ne m'étonne pas d'entendre ça. S'il y a deux fichiers de configuration, c'est qu'il y a une raison.
Je ne travaille pas que sous Windows (la plupart du temps je n'ai même pas d'OS). Mais j'utilise les outils qui me sont fournis par mon employeur.
Je travaille classiquement avec des distribution Debian GNU/Linux ou dérivé. PHP est disponible sous forme de paquets. Chez moi sont installés php-bin, php-cgi et libapache2-mod-php5. Pour chacun de ces paquets, un fichier de configuration existe :
Les hébergements de mes serveurs (que l'on gérait jusqu'à présent sous diverses versions de NT) seront bientôt assurés par des pro qui utilisent des versions de Linux pro (avec licence). Ce que je ne connais pas de tout. Aussi toute information est la bienvenue.
C'est fait ainsi parce que certaines options de configuration de PHP ne sont pas forcément pertinentes pour une exécution en ligne de commande ou en module PHP. Par exemple, quel est l'intérêt pour la version module Apache PHP de charger le module PHP GTK+ ? Les applications CLI doivent-elles partager le même fichier de log des erreurs que le module Apache ?
Tu as certainement raison. Il faudrait que je passe du temps pour éplucher les différentes configurations et les ajuster en fonction de mes besoins. D'autant plus que lorsque je n'aurais plus la maitrise des configurations, il me sera difficile de gérer à distance des paramètres que je ne connais pas.
Aussi je te conseille de revenir en arrière, et à considérer que le PHP en ligne de commande n'est pas exactement le même que le PHP chargé en module. Il doit bien y avoir une option dans le package que tu as installé pour pouvoir configurer le PHP dans chacune de ces utilisations.
Oui. Celà dit j'ai besoin de tester le fonctionnement des scripts, en faisant comme j'ai fait, j'ai juste permis de valider l'algorithme qui me permet d'obtenir le résultat escompté. Les réglages sur les serveurs définitifs ne m'incomberont plus.
En espérant être lu malgré mon approche ^^;
Bien sûr, puisque c'est constructif. J'ai tellement de choses à apprendre et tellement peu de temps à y consacrer...
Pour quelqu'un qui travail sous MS Windows, ça ne m'étonne pas
d'entendre ça. S'il y a deux fichiers de configuration, c'est
qu'il y a une raison.
Je ne travaille pas que sous Windows (la plupart du temps je n'ai même
pas d'OS). Mais j'utilise les outils qui me sont fournis par mon
employeur.
Je travaille classiquement avec des distribution Debian
GNU/Linux ou
dérivé. PHP est disponible sous forme de paquets. Chez moi sont
installés php-bin, php-cgi et libapache2-mod-php5. Pour chacun de
ces paquets, un fichier de configuration existe :
Les hébergements de mes serveurs (que l'on gérait jusqu'à présent sous
diverses versions de NT) seront bientôt assurés par des pro qui
utilisent des versions de Linux pro (avec licence). Ce que je ne
connais pas de tout. Aussi toute information est la bienvenue.
C'est fait ainsi parce que certaines options de configuration de
PHP
ne sont pas forcément pertinentes pour une exécution en ligne de
commande ou en module PHP. Par exemple, quel est l'intérêt pour la
version module Apache PHP de charger le module PHP GTK+ ? Les
applications CLI doivent-elles partager le même fichier de log des
erreurs que le module Apache ?
Tu as certainement raison. Il faudrait que je passe du temps pour
éplucher les différentes configurations et les ajuster en fonction de
mes besoins. D'autant plus que lorsque je n'aurais plus la maitrise des
configurations, il me sera difficile de gérer à distance des paramètres
que je ne connais pas.
Aussi je te conseille de revenir en arrière, et à considérer que
le
PHP en ligne de commande n'est pas exactement le même que le PHP
chargé en module. Il doit bien y avoir une option dans le package
que tu as installé pour pouvoir configurer le PHP dans chacune de
ces utilisations.
Oui. Celà dit j'ai besoin de tester le fonctionnement des scripts, en
faisant comme j'ai fait, j'ai juste permis de valider l'algorithme qui
me permet d'obtenir le résultat escompté. Les réglages sur les serveurs
définitifs ne m'incomberont plus.
En espérant être lu malgré mon approche ^^;
Bien sûr, puisque c'est constructif. J'ai tellement de choses à
apprendre et tellement peu de temps à y consacrer...
Pour quelqu'un qui travail sous MS Windows, ça ne m'étonne pas d'entendre ça. S'il y a deux fichiers de configuration, c'est qu'il y a une raison.
Je ne travaille pas que sous Windows (la plupart du temps je n'ai même pas d'OS). Mais j'utilise les outils qui me sont fournis par mon employeur.
Je travaille classiquement avec des distribution Debian GNU/Linux ou dérivé. PHP est disponible sous forme de paquets. Chez moi sont installés php-bin, php-cgi et libapache2-mod-php5. Pour chacun de ces paquets, un fichier de configuration existe :
Les hébergements de mes serveurs (que l'on gérait jusqu'à présent sous diverses versions de NT) seront bientôt assurés par des pro qui utilisent des versions de Linux pro (avec licence). Ce que je ne connais pas de tout. Aussi toute information est la bienvenue.
C'est fait ainsi parce que certaines options de configuration de PHP ne sont pas forcément pertinentes pour une exécution en ligne de commande ou en module PHP. Par exemple, quel est l'intérêt pour la version module Apache PHP de charger le module PHP GTK+ ? Les applications CLI doivent-elles partager le même fichier de log des erreurs que le module Apache ?
Tu as certainement raison. Il faudrait que je passe du temps pour éplucher les différentes configurations et les ajuster en fonction de mes besoins. D'autant plus que lorsque je n'aurais plus la maitrise des configurations, il me sera difficile de gérer à distance des paramètres que je ne connais pas.
Aussi je te conseille de revenir en arrière, et à considérer que le PHP en ligne de commande n'est pas exactement le même que le PHP chargé en module. Il doit bien y avoir une option dans le package que tu as installé pour pouvoir configurer le PHP dans chacune de ces utilisations.
Oui. Celà dit j'ai besoin de tester le fonctionnement des scripts, en faisant comme j'ai fait, j'ai juste permis de valider l'algorithme qui me permet d'obtenir le résultat escompté. Les réglages sur les serveurs définitifs ne m'incomberont plus.
En espérant être lu malgré mon approche ^^;
Bien sûr, puisque c'est constructif. J'ai tellement de choses à apprendre et tellement peu de temps à y consacrer...
