Redimensionarea imaginilor folosind PHP si GD este foarte utila din doua motive:

1. dimensiunea imaginilor este chiar dimensiunea asteptata, adica imaginile nu trebuie redimensionate fortat de catre browser si la calitatea la care browserul poate sa o faca,
2. imaginea ocupa mai putin spatiu pe disk si implicit la transfer, rezultand in pagini mai rapide.

De obicei redimensionarea se face in doua moduri, redimensionare si afisare pe ecran sau redimensionare si salvare pe disk.

Metoda de a redimensiona si afisa pe ecran nu este foarte populara si exista niste motive bune pentru asta. In primul rand ca sa redimenionezi in functie de trebuinta o imagine inseamna sa ai deja pe server o imagine la dimensiunea initiala, de multe ori aceasta imagine unica ocupa mai mult spatiu pe disc decat doua imagini redimensionate (imagine mare si thumnail). De asemenea redimensionarea unei imagini de fiecare data cand este nevoie consuma foarte multe resurse de sistem, daca memoria nu este dezalocata corespunzator scriptul poate sa ramana fara memorie de lucru inainte de a se termina executia acestuia.

A doua metoda, cu salvare pe disk, este mult mai populara, avanjaul principal este ca imaginile redimensionate chiar exista pe disk, nu este nevoie redimensionarea acestora de fiecare data cand se ruleaza scriptul.

Redimensionarea se face in 4 pasi:

1. incarcarea imaginii de redimensionat
2. calcularea dimensiunii finale
3. redimensionarea propriuzisa
4. afisarea/salvarea pe disk a imaginii

Incarcarea imaginii de redimensionat:

 1// locatia unde se afla imaginea, presupunem ca imaginea exista acolo
 2$url = 'picture.jpg';
 3
 4// extragem informatile legate de imagine
 5$img_info = getimagesize($url);
 6
 7// in functie de tipul imaginii se va incarca imaginea
 8switch($img_info[2]) {
 9	// tipul jpeg
10	case IMAGETYPE_JPEG:
11		$imagine = imagecreatefromjpeg($url);
12	break;
13	// tipul gif
14	case IMAGETYPE_GIF:
15		$imagine = imagecreatefromgif($url);
16	break;
17	// tipul png
18	case IMAGETYPE_PNG:
19		$imagine = imagecreatefrompng($url);
20	break;
21	// tipul bmp
22	case IMAGETYPE_BMP:
23		$imagine = imagecreatefromwbmp($url);
24	break;
25}

Practic in codul de mai sus se vor extrage informatile legate de imagine apoi se va incarca imaginea propriuzisa in memorie.

Nota In functie de rezolutia si calitatea imaginii scriptul poate sa ramana fara memorie la incarcarea imaginii. Nu va bazati pe faptul ca pe disk imaginea ocupa sub 1MB!

Functia getimagesize intoarce un array cu informatile legate de imagine, eventual rulati un var_dump($img_info); ca sa vedeti cam ce informatii sunt disponibile.

In functie de tipul imaginii aceasta se va incarca in memorie folosind functia corespunzatoare, in cazul de mai sus va fi imagecreatefromjpeg();

Calcularea dimensiunii finale:

Calculul dimensiunii finale se rezuma de cele mai multe ori la geometrie. Mai jos voi prezenta calculul cand imaginea este redimensionata in functie de latura maxima:

 1// latura maxima a imaginii finale
 2$max = 200;
 3
 4// latimea
 5$x = $img_info[0];
 6
 7// inaltimea
 8$y = $img_info[1];
 9
10// aflarea laturei cu dimensiunea maxima
11$latMax = max($x, $y);
12
13if($latMax == $x) { // cazul cand latimea este maxima
14   // se calculeaza proportional inaltimea si se rotunjeste
15   $y2 = round($y*$max/$x);
16   // latimea va fi latura maxima
17   $x2 = $max;
18} elseif($latMax == $y) { // cazul cand inaltimea este maxima
19   // se calculeaza proportional latimea si se rotunjeste
20   $x2 = round($x*$max/$y);
21   // inaltimea va fi latura maxima
22   $y2 = $max;
23}

Acum in $x si $y sunt dimensiunile originale ale imaginii, iar in $x2 si $y2 dimensiunile pentru imaginea redimensionata.

Redimensionarea propriuzisa:

1// construim imaginea care va rezulta
2$img_finala = imagecreatetruecolor($x2, $y2);
3
4// redimensionam imaginea
5imagecopyresampled($img_finala, $imagine, 0, 0, 0, 0, $x2, $y2, $x, $y);
6
7// dezalocam imaginea initiala
8imagedestroy($imagine);

Mai multe despre imagecopyresample(); in manual.

Afisarea/salvarea pe disk a imaginii
In cazul in care se doreste salvarea imaginii pe disk:

1// locatia unde va fi salvata
2$destinatie = 'new-picture.jpg';
3
4// salvarea imaginii pe disk la noua destinatie
5imagejpeg($img_finala, $destinatie);

In cazul in care se doreste doar afisarea pe ecran a imaginii:

1// se afisaza headerul corespunzator pentru tipul imaginii
2header('Content-Type: image/jpeg');
3
4// se afisaza continutul imaginii in browser
5imagejpeg($img_finala);

In functie de tipul imaginii salvate se pot folosi si alte functii sau headere. Dar pentru exemplul curent cam asta e tot.

Nota Nu uitati ca trebuie sa aveti drepturi de scriere pe folderul unde salvati imaginea.

M-am gandit multa vreme daca sa scriu acest blog sau nu, dar azi m-am decis ca este mai degraba necesar.

Sa luam o retea de cartier, majoritatea au urmatoarea reteta:

• se ia una bucata persoana cu initiativa (sau doar putin nebun)
• se gaseste primul vecin interesat
• se trage cablu pana la vecin, eventual din switch-ul propriu de pe birou
• se face reclama si se face rost si de alti clienti
• se repeta pasul 3

Lipseste ceva? In mod sigur, MONITORIZAREA!

De cele mai multe ori furnizorii mici, sau chiar subretelele care apartin unei firme mari care nu au fost complet asimilate nu au un sistem de monitorizare. Rezultatul? Nimeni nu stie ca TU nu ai net. De fapt cel mai probabil ei vor afla ca nu ai net daca mai raman si alti vecini fara conexiune si unul din ei are mai multa initiativa si suna. Daca mai multi vecini raman fara net si prefera sa astepte sa se repare singura problema, iar in acest timp nu fac decat sa injure ISP-ul nu se va rezolva nimic prea curand.

Sa nu va ganditi ca daca este o firma mare problema se rezolva mai repede de la sine, de fapt o firma mare nu monitorizeaza fiecare client, monitorizeaza doar (unele) echipamente importante, restul pur si simplu nu se pot monitoriza constant, iar cand se pun toate cifrele pe hartie totul incepe sa aiba o logica.

Acum cateva saptamani am vorbit cu cineva care avea o conexiunea deosebit de proasta. Evident nu a sunat nicaieri sa semnaleze acest lucru, iar atunci cand a facut-o, BUM, totul a fost ok in urmatoarea ora.

De ce oare lumea ezita sa faca lucrul asta? De asta exista serviciul acesta, ca sa fie folosit! Nu ezita, suna un reprezentant al ISP-ului tau azi! Iar daca nu rezolva problema intr-o perioada de timp rezonabila… poate este timpul sa schimbi ISP-ul.

Ca tot postam zilele trecute legat de incompatibilitati cu adevarat enervante, zilele trecute am descoperit un bug care l-am plantat cu succes de mai bine de un an jumatate.

Aveam niste campuri, respectiv:

1<input id="cos1" name="cos20" type="text" />
2<input id="cos2" name="cos19" type="text" />
3<input id="cos3" name="cos18" type="text" />
4--------
5<input id="cos10" name="cos11" type="text" />
6<input id="cos11" name="cos10" type="text" />

Ideea era ca atunci cand trebuie sa verific din JavaScript sa o fac folosind un for() iar din PHP folosind numele.

Codul JavaScript arata cam asa:

1for(var i=1; i<=coshmax; i++)
2{
3     element = document.getElementById("cos"+i).value;
4     if(element>0 && !isNaN(element))
5           faCeva();
6}

Pana aici totul bine, am testat aplicatia de nenumarat ori si nu a fost nici o problema.

Pana acum cateva zile cand am primit o reclamatie ca exista o problema pe la ultimele optiuni, respectiv asta se traduce prin ultimele variabile. Am inceput sa testez in Internet Explorer pentru ca acesta era deschis, apoi am testat si in FireFox ca sa urmaresc codul JavaScript si surpriza… in FireFox mergea fara probleme.

Am pierdut aproape jumatate de ora holbandu-ma si punand alert()-uri ca sa inteleg ce se petrece, apoi am realizat: Internet Explorer nu face mare diferenta intre id si name.

Problema era ca atunci cand apelam id-ul cos10 primeam valoarea de la id=”cos10″, cand testam cos11 primeam valoarea de la name=”cos11″. Rezultatul: nu mai testam ultima variabila nicioada.

Evident solutia a fost simpla, am redenumit id-urile ca sa nu mai existe artibute name si id cu aceeasi valoare.

Cazul acesta nu a fost foarte “trist” pentru ca am rasit bug-ul si am putut sa trec mai departe la ce faceam, dar daca eram la final de program dupa o zi agitata cred ca rezultatul era cu totul altul.

Problema este cu atat mai ciudata cu cat daca uiti sa redenumesti un element poti sa te trezesti cu un bug de toata frumusetea, respectiv daca in loc sa dai la un element name ii dai id, o sa mearga in Internet Explorer si… cam atat, de ex:

1<input type="text" id="variabila" />

in Internet Explorer va fi trimis foarte frumos ca orice alta variabila, iar in alte browsere cum ar fi FireFox evident… nu!

Si dupa ce ca bug-ul asta era foarte greu de remarcat oricum nu aparea decat in cateva cazuri speciale, motiv pentru care a si stat linistit un an jumatate.

Acum ceva vreme m-am lovit de un scenariu care pe cat este de bizar pe atat este de realist. Pe un anumit server a unei anumite mare companie de cablu se afla site-ul unei anumite companii. Pana aici nimic nou, dar cand incercam sa urc fisiere cu file managerul site-ului fisierele nu se puteau urca. Pe scurt problema era ca user-ul Apache si user-ul de FTP nu aveau aceleasi drepturi. Stand si analizand problema pana la urma nu este o idee rea si cu toate astea, eu cum fac cu fisierelele? Solutia era simpla, fisierele pur si simplu trebuiau urcate prin ftp.

In primul rand am realizat in acel moment ca este o idee buna realizarea unei clase de abstractizare pentru operatiile cu fisiere, dar nu voi vorbi despre asta, voi incerca doar sa schitez operatiile principale cu fisiere, oricum este un secenariu putin bizar dupa parerea mea.

Dupa ce am rasfoit putin manualul am vazut si cam de ce este nevoie.

In primul rand avem nevoie de o conexiune FTP:

 1// conectarea la server-ul ftp
 2$ftp = ftp_connect("ftp.example.com") or die("nu se conecteaza la server");
 3
 4// face login-ul propriuzis
 5$login_result = ftp_login($ftp, FTP_USER, FTP_PASS) or die("nu face log-in");
 6
 7// aici vor fi operatiile
 8
 9// se inchide conexiunea la server
10ftp_close($ftp);

Copiere
Fata de metoda “traditionala” cand copierea era facuta simplu cu functii precum copy() sau move_uploaded_file(), prin ftp trebuie sa mai luam in calcul directorul unde se face aceasta:

1// schimbam locatia in directorul destinatie
2ftp_chdir($ftp, 'director/destinatie/');
3
4// se copiaza fisierul care a fost urcat pe server in mod binar
5ftp_put($ftp, 'fisier-destinatie.tip', $_FILES['fisier']['tmp_name'] ,
6   FTP_BINARY) or die("nu copiaza");

Ceva mai mult parametri dar destul de direct. In exemplul de mai sus am folosit un fisier care a fost urcat printr-un formular POST. Iar dupa cum se poate vedea mie imi place sa folosesc “or die()” in loc de if(), dar in productie nu este cea mai buna idee.

Modificare drepturi
Se face folosind o functie similara cu chmod():

1ftp_chmod($ftp, 0644, 'fisier.tip') or die("eroare in schimbarea drepturilor");

Destul de simplu, nu? Fata de chmod() practic mai apare si conexiunea.
Redenumire
Ca si mai devreme foarte similara cu rename():

1ftp_rename($ftp, 'nume_vechi.tip', 'nume_nou.tip')
2     or die("eroare la redenumire");

Crearea de foldere
Similar cu mkdir():

1ftp_mkdir($ftp, 'director') or die("eroare creare director");

Stergere
Foarte similar cu unlink():

1ftp_delete($ftp, 'fisier') or die("eroare la stergere");

Concluzionand functile sunt foarte similare cu cele de baza, iar cu ajutorul lor se pot face relativ usor clase de abstractizare.

PS: Am mai gasit un scenariu pentru care e interesanta folositea unei astfel de abordari, daca exista fisiere intr-un director pe server si trebuie modificate drepturile acestora doar pentru fisiere specifice, de exemplu intr-un director cu poze.

Povestea incepe pe la inceputul Internetului, atunci cand WWW era inca la inceput, conexiunea se facea prin linii telefonice incete iar Mosaic facea furori. Dar a trecut mult timp de atunci, acum problema generala e cum sa faci o pagina web sa se miste ca o aplicatie Desktop si sa arate ca nimic altceva vazut pana acum. Dar cum unicitatea este doar o problema de timp iar aplicatile web nu vor ajunge niciodata cu adevarat aplicatii desktop nu are rost sa vorbesc despre asta.

Problema este ca o data cu dezolvarea Web-ului tehnologiile au inceput sa fie confilctuale, iar cand spun asta nu ma refer la lucruri cum ar fi ca Microsoft nu a implementat in Internet Explorer sau ca

are margin in Internet Explorer iar in FireFox nu, ma refer la lucruri cu adevarat enervante, cum ar fi incompatibilitatile intre DOM din JavaScript si cel din JScript de la Microsoft. Unul din site-urile care mi se par bizar de incompatibile cu Internet Explorer este site-ul Ubuntu.

Ubuntu.com in Internet Explorer

Ubuntu.com in FireFox

Cand esti o distributie de renume cum e Ubuntu e usor de inteles de ce nu te preocupa compatibilitatea cu IE dar asta nu se aplica si in general. Nu poti pur si simplu sa te duci la un client si sa-i explici ca pe tine nu te intereseaza compatibilitatea cu un anumit browser pentru ca numarul clientiilor va scadea in mod dramatic. Acesta este si unul dintre motivele pentru care nuprea poti sa faci design sau programare JavaScript in linux, cel putin nu lucruri complexe fara sa testezi in Internet Explorer, cel putin partial.

Din pacate se pare ca nici versiuniile Internet Explorer nu sunt tocmai compatibile intre ele, iar cum in acest moment cel mai folosit browser (in Romania) este Internet Explorer 6, urmat la mica distanta de Firefox 3 si Internet Explorer 7, la construirea unui site trebuie luate in calcul toate cele 3 versiuni.

Problema cea mai mare este ca Web-ul acum nu mai este doar pentru sisteme Desktop si eventual cateva Laptop-uri de ultima generatie cum era cu ani in urma, acum exista sisteme cu diverse sisteme de operare, dispozitive mobile etc. De exemplu eu am pe telefonul mobil (HTC Touch Diamond) doua browsere in mod implicit, Internet Explorer si Opera 9.5 pentru mobil, diferentele sunt foarte mari si cu parere de rau Internet Explorer pentru mobil este deosebit de slab! Ca webdeveloper trebuie sa iei in calcul marea majoritate a dispozitivelor de pe piata, nu poti ignora un segment de piata si in special dispozitive de lux, acel segment de piata este foarte important pentru oricine.

Din fericire toate aceste probleme se rezuma de cele mai multe ori la compatibilitatea dintre diferite versiuni de Internet Explorer si celelalte browsere care sunt in general surprinzator de compatibile intre ele. De exemplu eu testez aplicatile in general doar in Internet Explorer si FireFox pentru ca in general daca se comporta similar in cele doua se vor comporta similar si in Opera, Safari, Chrome si altele.

Sa speram ca o data cu Internet Explorer 8 se vor mai reduce din problemele de incompatibilitate si pe segmentul de piata detinut de Microsoft si o data cu asta Internetul va redeveni nu doar pentru toata lumea ci si pentru toate browserele.