Ha valmilyen okból a domainnevünk megváltozik de szeretnénk a keresorobotokat es a latogatoinkat atiranyitani az uj domainra akkor is ha a regit probaljak megnyitni akkor a 301 -es atiranyitasra van szuksegunk. Ennek a lenyege hogy egy “Moved permanently” http fejlecet kuld el a bongeszonek es atiranyitja az uj domainre.

Továbbolvas…

Sokan hasznaljak email cimek vedelmere a harvester robotok ellen az email cim ASCII kodolasu kiiratasat. Egy parsoros php koddal ezt konnyeden megvalosithatjuk.
Amire szuksegunk lesz az az ord() fuggveny ami a parameterkent atadott karakter ASCII kodjat adja nekunk vissza. Ahhoz hogy ezt a bongeszo meg is ertse at kell alakitanunk a kodot, vagyis csak ele kell raknunk egy “&” es “#” jelet illetve egy “;” karakterrel lezarni.
Lassuk akkor a kodot:

$string = 'test@test.com';
$ascii = null;
for($a = 0;$a < strlen($string);$a++){
  $ascii .= '&#'.ord(substr($string,$a)).';';
}
 
echo $ascii;

Amint lathato a stringen vegigmegyunk karakterenkent egy ciklussal es igy egyesevel kicsereljuk a karaktereket ASCII megfelelojukre. A fenti par sor eleg eroforras igenyes ezert csinjan banjunk vele.
Itt megnezhettek egy mukodo demot: Demo

Használat közben észrevettem, hogy ha több címet adok meg(5-10),  akkor néhány esetben nem jön meg a geocode válasz és ezért nem rakja ki a markereket a script. Ezt javítottam, és kicsit egyszerűsítettem a kódot. Az új verzióhoz más konfig változót kell megadni.

Elég gyakran használom a Google Maps API-t és csináltam hozzá egy úgynevezett ‘wrapper’ függvénycsomagot ami megkönnyíti az API egyszerűbb funkcióinak használatát. Ennek használatával nincs más dolgunk mint egy konfigurációs változónak(ami egy JSON objektum) megadni az értékeket és meghívni a függvényt.

Lássunk tehát egy egyszerű példát. Az API működéséhez szükségünk lesz egy API kódra, amit itt lehet igényelni : api key. Semmi más nem kell hozzá csak egy regisztrált Google fiók(email, stb). Miután megvan az API key-ünk, az alábbi sorokkal(a noscript tagok nélkül) betöltjük az API fájlt az oldalunkra:

Továbbolvas…

A heten bejelentettek hogy 2014-ig tamogatni fogjak az IE6-ot,pedig tobb webes ceg is szeretne ha a bongeszo eltunne a piacrol. Az ok az hogy az IE6 az Xp operacios rendszer resze melyet szinten 2014-ig tamogatnak es ezert a Microsoft azzal ervel hogy nem tehetik meg hogy nem tamogatjak egy reszet egy tamogatott operacios rendszernek.
Ezzel teljesen egyetertek. Igazuk van.
A gondom csak az hogy nem latom a tamogatas miben merul ki. Esetleg ujabb biztonsagi frissitesek hogy betomjek a tobb eves biztonsagi lukakat?
Mivel a webfejlesztes rohamosan fejlodik(itt a html5,css3),es igeny van egyre jobb teljesitmenyu weboldlakra en esszerunek tartanam,ha “tamogatas”-kent irnanank az IE6-hoz egy patch-et amivel kepes lenne tamogatni a transparens png-ket,kicsit jobban ertelmezne a css szabvanyokat(tokeletesseget nem varok toluk), es normalisan mukodnenek benne a modern javascript megoldasok.
A html es css csak az egyik fele a dolognak,mert pl az itt felvazolt modszerrel megolhato hogy egy lebutitott valtozatat mutatja az oldalnak a bongeszo,de a javascript az nehezebb dio. Mivel az utobbi evekben nagyot fejlodott a js kihasznalasa en ugy gondolom haraosan megint lesz js verziofrissites is,amit persze az IE6 nem fog tamogatni.
Szoval megertem en hogy szeretnek tamogatni, de akkor ne csak beszeljenek rola hanem tegyenek is valamit.

Elofurdul hogy olyan tarhelyre kell fejleszteni ahol nincsen klasszikus adatbazis,de szuksegunk lenne ra. Van aki ilyenkor fajl-ban tarolja a szukseges adatokat de en azt nem tartom tul gyors es jo megoldasnak, foleg hogy php5 ota alapbol rendelkezesunkre all az sqlite is.
Továbbolvas…

Altalaban validalasra a regexp fuggvenyeket hasznaljak az emberek,pedig van egyszerubb modja is a validalasnak. Ket beepitett php kiterjesztest fogok bemutatni amivel konnyeden tudunk validalni.
Az elso a php filters kiterjesztes. A kiterjesztessel nem csak validalni tudunk hanem az adatok megtisztisat is konnyeden elvegezhetjuk.

Továbbolvas…