TOP 5(+1) nyíltforrású PDF generátor könyvtár PHP nyelven
A PDF fájlok automatikus létrehozása az egyik legfontosabb eleme a webáruházaknak. Miért épp a webáruházakat hozom fel példaként? Mert ott tudom bemutatni a legéletszerűbb felhasználási módokat a PDF-ek generálására. Először is nézzünk pár példát, mire használható.
Teljes bejegyzés
2018 december 31-ével megszűnik a PHP 5.x támogatása
Jelenleg a csapból is az folyik, hogy veszélyben van a weboldalak 62%-a. Mit is jelent ez? A PHP 5-ös verziójának megszűnik a támogatása, ami annyit tesz, hogy onnantól kezdve nem kap frissítéseket. Nagyjából úgy kell elképzelni, mint mikor a Microsoft kijelentette, hogy megszűnik a Windows XP támogatása.
Teljes bejegyzés
Singleton Design - PHP - Hogyan használjuk?
A Singleton Pattern egy Design minta, amit azért használunk, hogy egy adott osztályt ne tudjunk bizonyos esetekben újra inicializálni. Ez annyit jelent, hogy ha egy osztályt implementálunk Singletonként, akkor ez az osztály nem fog kétszer létezni, tehát újra inicializáláskor már a meglévő osztályt fogjuk visszakapni, így nem fog dupla vagy akár tripla helyet elfoglalni. A legjobb alkalmazási területei például beállítások kezelése vagy a már említett Registry.
Minden webaplikációnak vannak olyan területei, amiket többször több helyen is (például: beépülő modulokban, külső könyvtárakban) használunk. Ha minden alkalommal, mikor szükségünk van egy osztályra újrainicializáljuk, rengeteg felesleges memóriát fogunk felemészteni. Hogy ezt kivédjük, biztosnak kell lennünk, hogy az osztályunk csak egyszer létezik és globálisan elérhető. Elsőként le kell tiltanunk, hogy az osztály kivülről inicializálható legyen, így a konstruktort priváttá kell tennünk.
Teljes bejegyzés
Registry Design - PHP - Miért kedveltem meg?
Eddig a blog főleg kisebb dolgokról szólt, css trükkökről, sitebuild megoldásokról, kisebb-nagyobb php problémákról. Most megpróbálok olyan dolgokat is leírni, amik kicsit mélyebben belenyúlnak a PHP világába, hiszen mindig azt hangoztatom, hogy nem vagyok egy túl erős sitebuilder, mégis a blogom nagyobb része erről szól.
Tehát a mai téma: Registry Design Pattern
Amikor nagyobb projecteken dolgozol gyakran szembesülhetsz egy problémával, ugyanazt az osztályt kell használnod másik osztályokon belül. Legjobb példa erre az adatbázis osztály. Használod felhasználók kezelésekor, termékek, cikkek lekérdezésekor, szóval szinte bárhol. Ha a kódod objektum orientált, és minden feladat a saját osztályában foglal helyet, akkor általában mindig azzal kezded az osztályt, hogy:
public function __construct(){
$this->db=new DataBase();
}
Vagy másik általános megoldás, hogy globális változókban tárolod az osztályt, így mindenhol elérhetővé válik. Bármelyik megoldást is használod, rossz. Ha minden alkalommal újra inicializálod az adatbázis osztályt, akkor baromi sok memóriát fogsz elhasználni.
Teljes bejegyzés
A cache probléma végleges megoldása
Közel 3 hete foglalkoztam a blogon utoljára a kérdéssel, mi legyen a cache-sel. Akkor csak körvonalakban volt meg, hogy mit szeretnék, közben teljesen rendet raktam a káoszban. Első fő kérdés, hogyan tároljam az értékeket. Két lehetőségem volt, serialize vagy json_encode. Ezután végeztem egy mérést, hogy melyik a gyorsabb. A tesztnél fontos volt, hogy a letárolás és visszaolvasás együttes sebessége legyen gyorsabb. Így végül a serialize - unserialize páros nyerte a versenyt.
Ezután felvetettem a kérdést, hogy letároljam-e a teljes HTML kimenetet. Ökörség lett volna ezt is szerializálni, úgyhogy ez a lépés kimaradt, helyette kapott a cache egy bővítést, így képes letárolni a teljes HTMLt is. Ezen még majd módosítani kell kicsit, de jelenleg teljesen tökéletesen végzi a dolgát.
Teljes bejegyzés
Kérések feldolgozása - avagy a Router Class
Egy dinamikus oldalnál elengedhetetlen, hogy valahogyan feldolgozzuk a kéréseket. Bevett szokás, hogy a .htaccess fileban a nem létező mappákra és file-okra csinálunk egy átirányítást az index.php-ra. Ezután millió és egy különböző megoldás van arra, hogyan dolgozzuk fel a kapott információt.
Jelenlegi módszerAmit most használok, full egyszerű, amit már leírtam a Harc a cache-sel 1. részben. Ennek lényege, hogy adatbázisban a menüpontoknak 3 különböző értéke lehet: type, file és link. Tehát bejön a kérés a szerverhez, majd egy függvény mindenképpen kiveszi a linkből a nem oda illő karaktereket, ékezetmentesít, és minden nem megfelelő karaktert --re cserél. Ezután feldarabolja az URL-t a / jelek mentén. Az első mindig a feldolgozó egység neve. Ezt keresi meg az adatbázisban.
Teljes bejegyzés
Harc a cache-sel - 1. rész
Egy új programot készítek szabadidőmben, ami már most - a tervezési fázisban - is nagyon bonyolultnak ígérkezik. Legalább van benne egy kis kihívás. Első körben megpróbáltam egy létező kód újraírását, bővítését, de rájöttem, hogy a saját logikám alapján gyorsabban fogok haladni. Sajnos, mire megszokok egy új logikát, addig rengeteg idő elmegy, ami nem frankó. Tehát marad a saját logika.
Alapként a jelenlegi motoromat akarom használni, csak kicsit tehermentesíteném az adatbázist. A jelenlegi motor működési elve tök egyszerű, van egy xy_menus tábla az adatbázisban, minden menüpontnak 3 vezérlőoszlopa:
- file
- type
- link
A slug alapján lekérdezi az adatbázisból a megfelelő menüponthoz tartozó értékeket, majd megnézi, hogy van-e link érték. Ha talál a mezőben valamit, akkor automatikusan átirinyítja a felhasználót a linkre. A type mezőt hasonló tartalmak, pl szöveges tartalmak betöltésére használja, így ha ebben a mezőben mondjuk text-content értéket talál, akkor automatikusan betölti a szöveges tartalmat. Majd végül, ha a másik két mező üres, mepróbálja betölteni az adott filet.
Ez eddig szép is, de ami emögött van, arra nagyon nem vagyok büszke... Felesleges körökkel fut a program, rengeteg olyan feladatot végez el, amit nem kellene. Így most csak a logikát akarom megtartani, a sallangot kihajigálom és újratervezem a működést.
Teljes bejegyzés
Harc a cache-sel - 2. rész
Az első részben már nagyjából kifejtettem a koncepciót. Tehát, van egy alap file alapú cache. Kiválasztottam a tárolás formátumát, már csak néhány kérdésem maradt. Ezeket próbálom most összerakni, hogy a végén a teljes rendszert ki tudjam szolgálni cache-ből.
Második mérkőzés - mit és hogyan tároljak?Elsőre a kérdés lehet kicsit hülyén hangzik, de megpróbálom kifejteni, min töröm a fejem. Tehát azt már tudom, hogy az adatbázis lekérdezéseket egyszerűen le tudom tárolni fileba, így az időigényesebb lekérdezések eredményét is egyszerűen adatbázis nélkül vissza tudom kérdezni.
Teljes bejegyzés
PHPMailer - Karakterkódolás
Ha PHPMailerben a feladó vagy a levél kódolása nem megfelelő, elég csúnya eredményeket kapunk. Még a nagyobb cégeknél is sokszor előfordul, hogy a kiküldött levél nagyon gáz. Ha nem megfelelően kódoljuk az emailt, akkor teljes lesz a káosz.
Fontos, hogy maga a generáló php fájl is ugyanolyan kódolásban legyen, mint amilyenben a kiküldött emailünk lesz. Ma már szerintem alap, hogy mindenhol UTF-8 kódolást használunk, nekem a program fel sem ajánlja, hogy más kódolásban hozzam létre a fileokat.
Másik fontos dolog, ha az emailben szereplő adatokat adatbázisból kérdezzük le, akkor az adatbázis kapcsolatot és az adatbázisokat is érdemes ugyanúgy UTF-8 kódolással létrehozni.
Teljes bejegyzés
This is my fault
Jogos a cím, közel 2 órája szenvedek azzal, hogy működjön egy script… vagyis működik, csak hibásan… Életemben nem gondoltam volna, hogy egy ilyen apróság ki tud tolni velem… :)
Már egy ideje PDO-t használok, de még mindig vannak kiaknázatlan kérdések. Így én arra fogtam, hogy valamit rosszul kötöttem össze, és a program emiatt hülye. De nem.
Teljes bejegyzés
Képek méretezése, vágása, arányosítása PHP-ben
Sokunknak okozhatnak problémát a túl nagy képek, a nem megfelelő méretarány vagy egy kép előnézeti képének létrehozása. Nekem is fejtörést okozott régebben, hogy hogyan vágjak egy 100×100-as képet, vagy hogyan csináljak egyszerű előnézeti képeket. Ekkor akadtam rá erre a scriptre. Azóta a programjaim nagy részében benn van. Igaz sokat fejlődött.
A fent említett problémára találtam a következő scriptet, mely megoldja a gondjainkat. A program képes képeket méretezni, vágni és arányosítani is. Méretezhetünk vele szélességre, magasságra, fix méretre. Vághatunk vele előre meghatározott dimenzióban, és százalékos értékben arányosíthatjuk is a képünket. A kapott eredményt menthetjük vagy megjeleníthetjük. Tehát mindent tud, amit egy kép kezeléséhez tudnia kell.
Teljes bejegyzés
MySQLi/MySQL és a PHP 5.5
A legutolsó upgrade alkalmával frissült az Apache és a PHP is a gépemen. Kubuntut használok, így jelenleg a 13.10-es került a gépre. Épp egy régi project javításán dolgoztam, mikor megtörtént a frissítés, felkerült a PHP 5.5
Régebben olvastam, hogy ki fog kerülni a mysql a PHP-ból, de ezt az információt valahogy teljesen félretettem. Most mikor felfrissítettem a rendszert, visszaállítgattam a virtuális hostokat, és beállítottam az apache-ot, folytatni akartam a munkát. Egy baromi aranyos üzenet várt a hibakezelőmben:
Unknown error type: [8192] mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead Error on line 14 in file /home/leoamros/public_html/xy_domain.hu/engine/core.php
"Hupsz. Ez meg mi?" Felkiáltás előtt még végig futott az agyamban, hogy minden jól lett-e beállítva. Persze, hisz ez már ilyenkor rutin feladat. Újra olvasva a hibaüzenetet, beugrott a régebbi cikk, hogy ki fog kerülni a mysql, helyette a mysqli vagy a PDO lesz.
Teljes bejegyzés
301-es átirányítás PHP header() segítségével
Az oldalaink folyamatosan változnak, bejegyzéseket törlünk, nevezünk át. Ekkor jön jól a 301-es átirányítás.
Nagyobb oldalak, blogok, fórumok esetében sűrűn előfodul, hogy egy-egy bejegyzést, hírt vagy hozzászólást törlünk, inaktiválunk vagy átnevezünk. Ilyenkor, ha nem akarjuk, hogy felhasználóink és a google barátunk is egy hiba üzenettel, esetleg egy üres oldallal találkozzon, kénytelenek vagyunk a nem létező tartalmat egy létezőre irányítani.
Régebben felmerült bennem az öltet, ha már az admin felületem úgyis naplózza mikor mit teszek az oldalon, lehet jobban járnék, ha ezt felhasználnám erre a célra. Csinálnék egy scriptet, ami ha egy halott linket talál, azonnal képes eldönteni, hogy hová irányítsa a felhasználót. Ha a link törölve lett, ésszerű, ha egy szinttel feljebb irányítom a látogatókat, de ha átneveztem akkor simán dobjon az új linkre.
Teljes bejegyzés
Egész szám ellenőrzés és az is_int?
Sokszor lehet szükségünk egész szám ellenőrzésre. Ha biztonságos programot készítünk és például adatbázisban tárolt id-val dolgozunk, ellenőriznünk kell, hogy a kapott paraméter biztosan jó-e. Persze ez csak egy példa, de belegondolva rengeteg helyen használható.
Tudom vannak beépített int ellenőrző függvények a phpban, de ezek "nem jól működnek" :) pár teszt:
var_dump(is_int(23)); //bool true
var_dump(is_int("23")); //bool false
var_dump(is_int(23.5)); //bool false
var_dump(is_int(true)); //bool false
Tehát maga az is_int függvény nem tudja kezelni a stringként kapott int értéket… ez annyiból gáz hogy pl egy POST vagy GET kezelésnél automatikusan stringként kapsz értéket.
Teljes bejegyzés
E-mail cím ellenőrzés PHP-val
Sokan szembesülünk a problémával, hogy a felhasználók helytelenül írják be az e-mail címüket. Sajnos a mai rohanó világban előfordul, hogy elütünk egy-egy karaktert. Az email címnél ez igen súlyos gond, hisz nem érkezik értesítés, nem kapunk aktiváló linket. Ilyenkor a megrendelő megoldást vár a programozótól. Építsünk be annyi ellenőrzést, amennyit csak tudunk. Már lassan ott jár a dolog, hogy olvassuk is el helyette.
Tehát keressünk megoldást erre a problémára. A legegyszerűbb, amit sokan használnak, hogy egy regex-et húznak a beírt mail címre, és ha jónak tűnik, mehet tovább. De ez szerintem érezzük, hogy kevés lesz. Lássuk mit tehetünk.
Teljes bejegyzés