Problema apare atunci cand utilizatorul intra pe un domeniu si trebuie redirectionat care acelasi nume de domeniu, pastrand variabilele GET dar adaugand www.

Solutia mea se bazeaza pe functia header si variabilele globale din $_SERVER:

 1// retinem adresa pentru a lucra mai usor cu ea
 2// va fi 'www.exemple.org' sau 'exemple.org'
 3$host = $_SERVER['HTTP_HOST'];
 4
 5// verificam daca primele 4 caractere sunt 'www.'
 6// '.' este important pentru numele de domeniu care incep cu 'www'
 7if(substr($host, 0, 4) !== 'www.') {
 8     // anuntam browserul ca pagina a fost mutata
 9     header('HTTP/1.1 301 Moved Permanently'); 
10
11     // introducem noua locatie
12     // in $_SERVER['REQUEST_URI'] se afla variabilele
13     header('Location: http://www.' . $host . $_SERVER['REQUEST_URI']);
14
15     // iesim din pagina
16     exit();
17}

Din pricina headerului 301 motoarele de cautare nu vor indexa pagina fara www.

PS: codul de mai sus trebuie sa fie primul lucru care il afisaza pagina!

Ieri a fost lansat oficial PHP 5.3! Aceasta versiune aduce cele mai multe schimbari de la versiune 5 pana acum, iar PHP 5.0 a fost lansat acum aproape 5 ani.

Pe langa noile facilitati pe care le aduce versiunea (despre care am mai discutat), sper ca acum se va grabi si finalizarea lui PHP6, care in principiu o sa fie aproape PHP5.3+Unicode.

De asemenea pe pagina PHP-GTK un anunt spune:

Rumours of PHP-GTK’s death have been greatly exaggerated! The project is very much still alive, but we’re waiting for PHP 5.3 to come out, and also some work needs to be done on the Cairo extension before a new release can be made. This should be completed soon. This release will come with support for GTK+ 2.14 and 2.16, Cairo, and PHP 5.3.

Din noutatile aduse, una dintre facilitatile care eu ma intreb in ce masura va prinde este PHAR. Aceasta permite crearea de “arhive” a fisierelor php, intr-un mod inspirat din Java unde se foloseste JAR. Accesarea arhivelor se face print-un stream (phar), deci teoretic se poate distribui o intreaga aplicatie PHP intr-un singur fisier, fara a fi nevoie de extensia PHAR sa fie instalata.

Se pare ca de curand Google a lansat niste “Sfaturi de optimizare pentru PHP“.

Unul din “sfaturile” facute de Google este:

Sometimes PHP novices attempt to make their code “cleaner” by copying predefined variables to variables with shorter names before working with them. What this actually results in is doubled memory consumption, and therefore, slow scripts. In the following example, imagine if a malicious user had inserted 512KB worth of characters into a textarea field. This would result in 1MB of memory being used!

$description = strip_tags($_POST['description']);<br /> echo $description;

Exemplul mi se pare unul destul de slab, ce este mai interesant este raspunsul lui Gwynne Raskind ca reprezentant PHP:

The Zend Engine at the core of PHP 4 and 5 uses a technique known as
“copy-on-write” memory management. This means that no matter how many
times you assign the value of a variable to another variable, the data
is not copied until you change it.

Sa fie un lucru clar, Google nu foloseste PHP ca unul din limbajele de programare principale, cum fac cei de la Yahoo! sau Facebook, deci nu sunt implicati direct in optimizare.

Problema de fapt cu aceste “trucuri” de care este plin Internet-ul este ca acum vin si de la Google, lucru care o sa asigure vizibilitatea si din pacate este un articol slab va deveni un articol de referinta pentru multi.

Se pare ca PHP 5.3 aproape a fost lansat azi. Dar pana la urma lansarea a fost amanata pentru data de 30.06.

Cum am mai spus si intr-un post anterior, PHP 5.3 este o versiunea destul de importanta aducand multe facilitati noi, care din pacate nu au putut fi lansate ca PHP 6, aceasta din urma avand (cand va ajunge sa fie lansata) suport pentru Unicode.

Mai multe despre facilitatile aduse de PHP 5.3 in:  “PHP 5.3 ce aduce nou?“.

Cred ca asta este un moment bun sa va verificati app-urile pentru compatibilitate.

PEAR si PECL sunt depozite de extensii pentru PHP. In aceste depozite se gasesc practic toate extensile mai importante care se folosesc cu PHP.

De ce nu ai folosi extensii care totusi se regasesc in cele doua depozite? Pentru ca limitarea cea mai mare si mai importanta este serverul pe care va rula aplicatia.

Majoritatea site-urilor mici si medii au hosting de tip share (adica pe acelasi server sunt gazduite mai multe domenii). Pentru ca hosting-ul este share atunci in momentul in care se face o schimbare pe server toate site-urile vor “beneficia” de ea (cel putin teoretic).

Si de aici apar problemele, nu poti fi niciodata sigur ca aplicatia pe care o dezvolti va ajunge pe un server care are o anumita extensie. Iar chiar daca unii o sa te lase sa instalezi extensii sau chiar le vor instala ei la cerere, mereu va exista problema celor care refuza sa faca asta sau chiar te pun pe tine sa o instalezi pe propria raspundere (da, am intalnit si asta).

Evident nu ar trebui excluse toate extensile, dar cele care nu sunt tocmai “populare” ar trebui totusi evitate.

Partea buna este ca multe extensii sunt facute chiar in PHP, deci ele nu mai trebuie complilate, activate etc., acestea pot fi direct incluse si folosite.

Un alt avantaj al PHP este si ca nu duce lipsa de resurse, de exemplu pentru clase PHP exista www.phpclasses.org o resursa foarte buna, unde se gasesc clase pentru orice ai visat sau nu ai indraznit sa visezi.

Din pacate totusi unele extensii pur si simplu nu se pot inlocui, de exemplu GD. M-am trezit zilele trecuta ca serverul pe care lucram nu are GD iar eu nu pot sa fac nimic altceva decat sa astept sa se sesizeze cineva.

Concluzia, ai grija ce folosesti daca sti ca nu vei controla serverul pe care va ajunge aplicatia ta…