Come molti prima di me, sto scrivendo uno script PHP per fare qualche immagine in miniatura. La sceneggiatura ha ottenuto la certificazione WOMM (funziona sulla mia macchina), ma quando la trasferisco sul mio host (1 & 1 Basic), c'è un problema: le immagini sopra un certo file non possono essere elaborate. Ho spostato tutte le operazioni sul filesystem, per essere certo che non si tratti di un problema di latenza POST. Ecco il codice rilevante:imagecreatefromjpeg sta terminando silenziosamente gli script
function cropAndResizeImage($imageLocation)
{
//
// Just to be certain
//
ini_set('display_errors','on');
error_reporting(E_ALL);
ini_set('memory_limit','128M');
ini_set('max_execution_time','300');
$image_info = getimagesize($imageLocation);
$image_width = $image_info[0];
$image_height = $image_info[1];
$image_type = $image_info[2];
switch ($image_type)
{
// snip...
case IMAGETYPE_JPEG:
$image = imagecreatefromjpeg($imageLocation);
break;
default:
break;
}
// snip...
}
Usando i miei poteri mistici di println debugging, sono stato in grado di determinare che imagecreatefromjpeg non restituisce; in effetti, lo script si arresta completamente quando arriva ad esso. Alcuni dati:
- Questo è correlato alla dimensione del file. Le immagini inferiori a 1 MB sembrano essere a posto (verificate a campione), ma le immagini misurano circa 3 MB. Non capisco quale sia il taglio preciso, però.
- Questo non è dovuto ai timeout del server;
wgetrestituisce in < 1 s su immagini da 3 MB, significativamente più lunghe su immagini "opportunamente piccole" (che indicano l'assenza di elaborazione di immagini di grandi dimensioni). - La preimpostazione della chiamata di funzione con
@per eliminare gli errori non ha alcun effetto. Ciò corrisponde al fatto che lo script non sta generando un errore, ma sta semplicemente terminando silenziosamente questa chiamata di funzione.
Se dovessi indovinare, ci può essere qualche parametro GD che io non sapere (o avere accesso a) che limita le dimensioni dei file di input su server 1 & 1 di — config ipotesi variabile è dovuto al Infatti, si blocca immediatamente, e non appare (euristicamente) per fare un effettivo caricamento o calcoli sull'immagine.
Qualche suggerimento? Grazie per l'aiuto.
Update (per gentile concessione @Darryl's commenti): chiamate a phpinfo indicano che PHP sta aggiornando correttamente le variabili max_execution_time e memory_limit. Questo non significa necessariamente che queste risorse vengano assegnate, semplicemente perché sembrano funzionare come previsto.
Aggiornamento 2: seguito alcuni riferimenti da Google, ho provato l'ottimizzazione del JPEG (ridotto in termini di qualità da 3MB a 200KB) senza fortuna, quindi non è un problema di immagini dimensione del file. Ho quindi provato a ridurre il numero di pixel dell'immagine originale 3888x2592, e la prima dimensione di successo è 1400x2592 (1401x e 1402x entrambi risultano in semi-pars e errori che indicano "JPEG malformato", che non ha molto senso a meno che l'intera immagine non viene caricato). Riducendo ulteriormente a 1300x2592, posso istanziare l'immagine di anteprima 400x300 che sto effettivamente cercando; a 1400x2592, la chiamata imagecreatetruecolor che sto utilizzando per occuparsi di tale attività non riesce in modo silenzioso nello stesso modo di imagecreatefromjpeg.
Per quanto riguarda il motivo, sono un po 'incerto. 1400 * 2592 == 3,5 MB non dà nulla di particolarmente significativo, ma devo immaginare che questo è un limite al numero di pixel che GD + PHP elaborerà.
Ehi Darryl-- Sono stato davvero sorpreso di capirlo, ma 1 & 1 * appare * per consentire l'impostazione di questi parametri. Almeno, quando li ho impostati ed eseguito phpinfo(), tutto si presenta come previsto. È possibile che abbiano un sistema di controllo secondario? – kyle