Sziasztok,
Alant van egy php szkriptem, ami egy db pdf-et készítene/fűzne össze több db feltöltött ps/pdf fájlból, de a gyakorlatban nem igazán működik jól.
A gond az, hogy >3M méretű feltöltött fájlból csak akkor késziti el a pdf-et, ha a https://localhost/pdfservice.php fájlból hívom meg (azaz a helyi gépről).
Ha egy távoli gépről, a https://www.foo.bar/pdfservice.php-ként érem el, akkor valamiért csak 3M feltöltött fájlméret alatt működik; egyébként pedig még hibaüzenetet sem kapok, csak a böngésző timeout-ol.
Nem tudom, hogy valóban a szkript-e a hibás, de az egyetlen hibaüzenet amit bárhol is találok, az szkript hibára utal:
[Mon Feb 19 22:44:25 2007] [error] [client 196.227.41.83] PHP Notice: Use of undefined constant name - assumed 'name' in /srv /www-ssl/htdocs/pdfdownload.php on line 31, referer: https://www.foo.bar/pdfservice.php [Mon Feb 19 22:44:32 2007] [error] [client 196.227.41.83] PHP Warning: unlink("/tmp/phpbnoI5F" ) [function.unlink]: No such file or directory in /srv/www-ssl/htdocs/pdfdownload.php on line 59, referer: https://w ww.foo.bar/pdfservice.php
A furcsa csak az, hogy ez a hibaüzenet (legalábbis az első) akkor is ott van, amikor elkészül a pdf. Nem magyarázza meg azt sem, hogy a localhost-on miért működik rendesen a pdf készítő php szkript.
Mindenesetre; segítenétek debugolni ezt a szkriptet, úgy hogy
a) a fenti hibák megszűnjenek
b) kapjak valami visszajelzést arról, hogy miért nem készül el a pdf, mert jelenleg az ie csak egy "timeout" üzenetet ad, az Opera még azt se, csak vár az idők végezetéig.
Ime a szkript:
function print_message ($s) { die ('Hiba!' . $s . ''); } // Check that a file was uploaded $fajlok=""; if (!count ($_FILES)) print_message ('Nem toltottel fel egy fajlt sem!'); while(list($key,$value) = each($_FILES[infile][name])) { if(!empty($value)){ // this will check if any blank field is entered if ($_FILES[infile][error][$key] || !eregi ("application/(postscript|pdf)$",$_FILES['infile']['type'][$key])){ print_message ('Sikertelen fajl feltoltes, vagy nem megfelelo tipusu feltoltott fajl!'); } $tmpfajlok .= '"' . $_FILES[infile][tmp_name][$key] . '" '; $mergedtmpfajl = $_FILES[infile][tmp_name][$key]; $fajlnev = $_FILES[infile][name][$key]; } } // Try running it through Ghostscript exec ('/usr/bin/gs -sDEVICE=pdfwrite -r200 -sOutputFile=' . $mergedtmpfajl . '.pdf -dNOPAUSE -dBATCH ' . $tmpfajlok, $a, $n); if ($n) print_message ('Unable to convert file. Please ensure that you have used the proper format and try again.'); // First, output headers that tell the browser the type of the file // we are outputting, how long it is and how we want it displayed // The Content-Disposition header also allows us to specify a filename header ('Content-Type: application/pdf'); header ('Content-Disposition: attachment; filename="' . $fajlnev . '.pdf"'); header ('Content-Length: ' . filesize ($mergedtmpfajl . '.pdf')); // Dump the PDF file and delete it from the PHP folder readfile ($mergedtmpfajl . '.pdf'); unlink ($tmpfajlok);
A teljesség kedvéért szívesen feltölteném a pdfservice.php-t is, ami a fájlokat feltölti, de úgy látom, a fórum motorja értelmezi a parancsait, és megjeleníti a form jeleníti meg a forrása helyett, úgyhogy ezt most inkább mellőzném.
Vagy van esetleg valamilyen tag, ami közé php forráskódot tudnék ide beszúrni?
- 2092 megtekintés
Hozzászólások
Nézd meg ezeket a php.ini -ben
max_execution_time
memory_limit
max_input_time
___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)
- A hozzászóláshoz be kell jelentkezni
ha már arra jársz, upload_max_filesize
- A hozzászóláshoz be kell jelentkezni
Azt írta, hogy azzal nincs baj, mert már korábban feltöltötték a fájlokat, szóval a feltölthető max. fájlméret jelen esetben nem kavar bele, nem?
___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)
- A hozzászóláshoz be kell jelentkezni
Pontosan: a dolognak ezt a részét már ellenőriztem, és nem találtam semmi hibát. Úgyhogy csak kínomban gyanakszom a php szkriptre :-(((
Szóval ez a helyzet:
a) >20M feltöltése távoli gépről: kb. 2 perc múlva timeout a bögészőben
b) >20M feltöltése helyből (https://localhost/..) + 720s sleep a php szkriptben: kb. 15 perc múlva jön le a kész a pdf.
Nem értem: ha timeout, akkor miért csak a távoli elérésnél lép fel?
A logokban pedig semmi sincs a timeout-ról; sőt, az egyetlen hiba amit találok, csak az a php hiba, amit itt is közöltem.
Szóval lehet, hogy nem php hiba, de azokat a paramétereket amiket írtatok, mind beírtam valahová a /etc/apache2 könyvtár ezer konfig fájljába (a max. az lehet, hogy nem jó helyre) :-(((
De: ha az apache van félrekonfigurálva (ami nincs kizárva), akkor miért működik rendesen a https://localhost/-al ?
---
Mondjon le!
- A hozzászóláshoz be kell jelentkezni
Nézd meg a phpinfo() kimenetét. Az elején látni fogod, hogy melyik könyvtárba keresné a php.ini -t. A php -t és az apache -ot csomagból tetted fel vagy fordítgattad?
Az apache konfigjába hiába írod a php beállításait, hacsak nem php_admin_flag vagy php_admin_values -sel adod meg őket.
___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)
- A hozzászóláshoz be kell jelentkezni
"Nézd meg a phpinfo() kimenetét. "
A phpinfo() parancs nekem egy interaktiv promptot ad. Hogyan tudom megnézni a kimenetét? Vagy valamelyik logfájlban kellene lennie?
"csomagból tetted fel vagy fordítgattad"
A legfrissebb elérhető verziókat töltettem le és telepítettem a "smart"-al valamelyik SuSE 10.1 repository-ból.
"Az apache konfigjába hiába írod a php beállításait"
A php konfigjában vannak:
#>grep -i -R -E "(max_execution_time|memory_limit|max_input_time|upload_max_filesize|requestbody)" /etc/php5/* /etc/apache2/*
/etc/php5/apache2/php.ini:max_execution_time = 1200 ; Maximum execution time of each script, in seconds
/etc/php5/apache2/php.ini:max_input_time = 2400 ; Maximum amount of time each script may spend parsing request data
/etc/php5/apache2/php.ini:memory_limit = 40M ; Maximum amount of memory a script may consume (8MB)
/etc/php5/apache2/php.ini:upload_max_filesize = 30M
/etc/php5/cli/php.ini:;max_execution_time = 30 ; Maximum execution time of each script, in seconds
/etc/php5/cli/php.ini:max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
/etc/php5/cli/php.ini:memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
/etc/php5/cli/php.ini:upload_max_filesize = 2M
/etc/apache2/conf.d/php5.conf:LimitRequestBody 35000000
/etc/apache2/httpd.conf:LimitRequestBody 35000000
---
Mondjon le!
- A hozzászóláshoz be kell jelentkezni
Na, ezek itt nem a legjobbak szerintem:
etc/php5/cli/php.ini:;max_execution_time = 30 ; Maximum execution time of each script, in seconds
/etc/php5/cli/php.ini:max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
/etc/php5/cli/php.ini:memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
/etc/php5/cli/php.ini:upload_max_filesize = 2M
A phpinfo() egy függvény. Írd be egy php fájlba és nyisd meg a böngészővel az oldalt a webszerveren keresztül.
___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)
- A hozzászóláshoz be kell jelentkezni
Igen, de közben rájöttem hogyan kell használni a phpinfo()-t, és kiderült, hogy ahogy eddig is gondoltam, a /etc/php5/apache2/php.ini-t használja a rendszer.
(Hogy akkor a /etc/php5/cli/php.ini mire jó, azt csak sejtem: talán a konzoli php szkript futtatáskor kell?)
Mindenesetre: itt most webes elérésről van szó, azaz csak a /etc/php5/apache2/php.ini játszik; abban pedig a jó értékek vannak...
Ja, nézegetem itt a phpinfo-t, és azt látom, hogy az eddig itt említetteken túl még egy "post_max_size" értéket is megadtam (szintén 30M).
Szerfelett bosszantó, hogy látszólag minden a helyén, és bizonyos (de a használat szempontjából döntő) esetekben mégsem működik ez a dolog :-(((
Amúgy kb 2 héttel ezelőtt jó volt, szerintem ugyanezzel az apache+php verzióval; csak azóta tönkrement a rendszer vinyóm, és most meg nem tudom újraépiteni ezt a szolgáltatást...
Szerinted működne, ha az akkori mentésből teljes egészében felülirnám a mostani /etc/apache2 és /etc/php5 könyvtáraimat? Mert az egyes konfig fájlok egyenkénti cseréje nem nagyon jött be.
---
Mondjon le!
- A hozzászóláshoz be kell jelentkezni
Ha ugyan azt az apache és php verziót használsz és az új rendszer kialakítása is ugyan olyan, mint a régi, akkor próbáld meg a felülírást, bár nem tudom... Legalább a php.ini -t az első körben.
Igen, ami a cli könyvtárban van, az a konzolból kiadott php parancs futtatásakor érvényes.
Safe_mode be van kapcsolva?Amire érdemes még figyelni: open_basedir safe_mode_include_path (vagy valami nagyon hasonló).
___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)
- A hozzászóláshoz be kell jelentkezni
Volna egy kérdésem:
Ha a "fájlfeltöltő" weblapot ezen a cimen éred el: https://www.foo.bar/pdfservice.php; de abban a form-on ez van: "action=pdfdownload.php", akkor szerinted a 443-as, vagy a 80-as portról próbálja majd a böngésződ (helyesebben a proxy szerver) elérni a pdfdownload.php-t?
Most fixen beirtam az űrlapra: "action=https://www.foo.bar/pdfdownload.php", és a firefox nem timeout-olt, pedig külső proxy-n át ment vagy 15 percen át a konverzió, és a két feltöltött fájl is volt vagy 10M.
Most akkor vagy megtaláltam a hiba okát, vagy azt igazoltam újra, hogy a pdf készítőm firefox kompatibilis. (Az ie-vel meg opera-val meg ugye nem, mert azokkal az utóbbi időben egy sikeres próbálkozásom sem volt :-().
Holnap kiderül. Mindenesetre elég szkeptikus vagyok, mert ez a verzió ugyan megmagyarázná, hogy miért tudtam a localhost-ról konvertálni (ott elérhető a 80-as port, az oif-en meg a tűzfal tiltja), viszont azt nem magyarázza meg, hogy a kis fájlokat miért tudtam mégis kintről is konvertálni.
---
Mondjon le!
- A hozzászóláshoz be kell jelentkezni
Izgalmas dolog ez az informatika :).
Elvileg ha azt az oldalt https -en keresztül hívtad meg, amin a form van, akkor nem kell(ene) az action -ben a https://www.foo.bar/pdfdownload.php. De, mondom elvileg. Én soha nem használom egy domain -en belül az abszolult hivatkozást még formnál sem. Nekem eddig ilyen problémám nem volt.
Majd írd meg holnap az eredményt, mert engem is érdekel a végkifejlet.
___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)
- A hozzászóláshoz be kell jelentkezni
Sziasztok!
Remélem jó helyre írok, igyekeztem.
Az a problémám, hogy valamiért nem mükszik rendesen a php-m.
Csomagból lett fordítva, de ezt még nem én telepítettem.
A problémám: szerettem volna feltenni PHPMyAdmin(PMA)-t és SquillerMail(SM)-t is, de mind a kettővel gondok vannak. A SM és a PMA is bejönnek, de bizonyos oldalak nem. PL Van most egy levelem ott amit én küldtem, azt meg tudom nézni, de a bejövő leveleimet nem, és írni sem tudok. Amikor ezeket szeretném csinálni akkor egyszerűen nem jelenik meg semmi a képernyőn, de hibaüzenet sem. Próbálok logokat keresni még, de gondoltam írok ide is, mert lehet, hogy ez egy ált. probléma.
Köszönöm a segítséget előre is.
Üdv / budacsik
- A hozzászóláshoz be kell jelentkezni
error_reporting("E_ALL");
Ha meg php.confban van beállítva a némaság akkor
debug.php:
<?php
error_reporting("E_ALL");
include("index.php");
?>
- A hozzászóláshoz be kell jelentkezni
Szia!
Megnéztem a php.ini-ben ezek a sorok vannak ami ide tartozik:
;error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
;error_reporting = E_ALL & ~E_NOTICE
;error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
; error_reporting(0) around the eval().
Egy ugye "aktív" sor köztük. Ennek nem kellene akkor beszédesebnek lennie szerinted?
vagy tegyek be egy ilyen sort?
error_reporting = E_ALL
??
Ezt nem írtam, de hátha fontos lehet: PHP Version 5.0.5
Meg nem tudom ez mit jelent, de a phpinfo (<?php phpinfo(); ?>) ezt mutatja nékem: error_reporting 2039 2039
Ez mond még neked valamit?
Többet nem tudok segíteni egyelőre, de keresek még ...
- A hozzászóláshoz be kell jelentkezni
display_errors legyen on ha látni akarod a hibákat.
Nálam a vtiger halt meg minden különösebb ok nélkül php 5-tel, mert egy funkcióval bővült amit nem engedett újradeklarálni. Merhogy pont úgy nevezték el a vtigerben az egyik funkciót hogy timedate, ha jól emlékszem. De ez esetben nem hiszem hogy erről van szó. A debug.php-n át nézve az index.php-t (vagy amit akarsz) látszik a hiba ha nem tudod átírni a php.init akkor is.
ui: error_reporting: http://hu2.php.net/error_reporting
- A hozzászóláshoz be kell jelentkezni
hát, nem sikerüt sehogy kicsalnom error-t, bekapcsoltam az error_log opciót is, de fájlba se loggol, a display-re sem. Lehet olyan probléma keletkezik amikor nem is keletkezik log.
Hosszasan nézegettem a SM-t és végül is csak a Compose és a reply opciók nem működnek, tehát amikor üzenetet szerkesztenék.
Senki másnak nem volt ilyen problémája?
- A hozzászóláshoz be kell jelentkezni
Na jó, azóta sem jöttem rá. Azon gondolkozom, hogy feltenném csomagból (yast) a php4-et. Csak nem tudom mit csináljak a mostani forrásból feltett php-val?! Hagyajam ahol van a csomagból települt felülírja?
Meg azt nem tudom, hogy az apache-al akar e valamit település közben, nem lenne jó a virtual domain-eket elcs...ni.
Amikor telepítenék egy "portált" akkor is van egy olyan része, hogy "Recommended PHP Settings".
Itt azt írja ha a Session AutoStart = OFF, hogy
Ha jelentkezik a WhiteScreenOfDeath jelenség akkor próbáljam ezt ON-ra állítani. Ha ON-ra állítom akkor is ez van
- A hozzászóláshoz be kell jelentkezni
Szerintem ez okozza, mivel ezek itt helytelenek:
$fajlnev = $_FILES[infile][name][$key];
Mivel minden alfanumerikus indexet aposztrofálni _kell_! Némely PHP beveszi, de néhány nem... Én is szívtam már meg ezzel.... Elég változatos hibákat eredményez..
Helyesen:
$fajlnev = $_FILES['infile']['name'][$key];
Az összes ilyet írd át így!
Üdv!
Szerk: A magyarázata pedig az,hogy nem indexként, hanem konstansként érzékeli az indexet az aposztrof hiány miatt.
- A hozzászóláshoz be kell jelentkezni
Régi a téma, és közben megoldódott: kiderült, hogy a hálózati kapcsolattal volt a baj; egy másik telephely isa proxiján keresztül állandóan timeoutolt a kapcsolat.
Felraktam ide helybe egy squid-et, és azon át ismét jól működik.
Azaz a szkript hibátlan (csak a HUP fórum motor egy kicsit "elferdítette" a kódot, amit beillesztettem ide.)
---
Mondjon le!
- A hozzászóláshoz be kell jelentkezni
Nem ferditi az el, csak rendes tagek koze kell berakni: http://hup.hu/filter/tips
- A hozzászóláshoz be kell jelentkezni
Ha meg tag-ek közé raktam 2 km széles lett az oldal.
A több sorra tördeléssel meg lusta voltam tökölni :-(
---
Mondjon le!
- A hozzászóláshoz be kell jelentkezni
Nem figyeltem az idopontot. sry
- A hozzászóláshoz be kell jelentkezni