Új hozzászólás Aktív témák
-
cucka
addikt
Ezért alacsony a presztízse a php fejlesztésnek. Könnyen tanulható nyelv, nulla tudással össze lehet gányolni egy weboldalt, ezért ez a szoftverfejlesztő szakma pöcegödre . (De komolyan, nem hiszem, hogy van még egy olyan programozási nyelv, amelyből ennyire sok fogalmatlan hülye képes megélni)
A #4007-es hozzászólásnál meg elfelejtettem odaírni, hogy a te megoldásodban rossz a szuperglobálok sorrendje, a linkelt kódban ott a helyes sorrendű és teljes lista. (Meg még egy hasznos kód, ahol a kikapcsolt register_globals-t emulálja)
[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #4012 üzenetére
Ez most ilyen default értéket ad, mert a hu és en nyelvekhez nyúlkálsz a legtöbbször, és ha mégis másik nyelvre van szükséged, akkor lekérdezed adatbázisból, de egyébként nincs rá szükség?
A kódban található osztályok nem tudnak olyat, hogy default érték, de bele lehet építeni.
Ha megfigyeled, a kimásolt kódban a my_language osztályt példányosítom be, amelynek nincs szüksége semmilyen adatbázisra, működik anélkül is. Nyilván ekkor kézzel kell hozzáadni a lehetséges nyelveket (vagyis az add_language metódust használva)
A my_db_language osztály annyival tud többet, hogy ki tudja olvasni az adatbázisból a lehetséges nyelvek listáját. Ha megnézed, akkor ugyanazt az add_language metódust használja, mint amit az első példában kézzel hívtam meg.Amúgy ezek csak példa osztályok, az elv a fontos. A my_language képes rá, hogy nyilvántartsa a nyelvek listáját, oda-vissza fordítson szöveges azonosító és numerikus azonosító között. A my_db_language ennek a leszármazottja, egy plusz funkcióval, be tudja olvasni a nyelvek listáját az adott táblából/mezőnevekből.
(Amúgy nagyon hasonló a saját language osztályom is, csak az ki van bővítve néhány funkcióval)[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #4017 üzenetére
Eddig nem igazán értettem, hogy ha nem adatbázisból szeded, akkor mégis honnan, ha csak egy osztályod van...
Nem értem, mit nem értesz . Ott a kód, nézd meg, hogy melyik függvény mit csinál, direkt egyszerű példát írtam, összesen 1 darab származtatás van benne, ami oop.Így viszont pont a rugalmasságát veszti el a dolog, ha kézzel kell hozzáadni, nem?
A kód végén ott van 3 darab példa arra, hogy hogyan lehet használni ezeket az osztályokat különféle helyzetekben. A kommenteket nem dísznek írtam a kódba, hanem hogy elolvasd .És a gyakorlatban ezt a kézzel való hozzáadást hogy kell elképzelni?
Úgy, ahogy az első példában van.[ Szerkesztve ]
-
-
-
cucka
addikt
válasz Sk8erPeter #4038 üzenetére
Inkább az Appserv-et javaslom. Ugyanaz a next-next telepítő, csak nincs benne semmi egyedi cucc, pontosan olyan, mint ha kézzel külön-külön raknád fel a programokat. Ez azért jó, mert kb. ugyanolyan környezetet kapsz, mint az éles rendszereken, nincs telepakolva a Wamp saját szemetével.
(Már végigzongoráztam párszor az apache-php-mysql telepítést külön-külön, mindent beállítva, nekem ennyi elég is volt belőle, ezért kerestem olyan csomagot, ami megcsinálja helyettem)[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #4040 üzenetére
A "WAMP saját szemete" nem hinném, hogy túl sok kárt okozna a gépben, nem fosta tele a registry-t sem, azért szerintem ezt nem kell ennyire túlparázni
Nem parázom túl, csak a wamp-hoz hozzáadott tartalom abszolút fölösleges.mert nem szöveges fájlokban kell kutakodni a megfelelő beállítások után, hanem van egy kellemes grafikus felület a Tálcán
Mondjuk három havonta egyszer fordul elő, hogy beletúrjak valamibe. A másik, hogy hozzá tartozik a fejlesztői ismeretekhez, hogy bele tudj túrni abba a kemény 2 fileba.Nem értem, a WAMP miért lenne rosszabb az Appserv-nél, a WAMP is ugyanúgy az éles környezetet pakolja fel, csak biztosít hozzá még egy plusz felületet, amin a beállítások elérhetők.
Semmi baj nincs vele, csak ha egy mód van rá, akkor tartózkodom azoktól a programoktól, amik szükségtelen szeméttel pakolják tele a gépet. -
cucka
addikt
válasz DerStauner #4042 üzenetére
Kapsz.
A wamp neve betűszó: windows+apache+mysql+php. -
cucka
addikt
válasz Gergello #4052 üzenetére
Nem értem a problémát.
Mysql csatlakozásnál meg kell adni a gép hostnevét, ahova szeretnél csatlakozni. Ha ugyanazon a gépen van, mint amin a szkripted fut, akkor localhost-ként lehet rá hivatkozni, különben meg az adatbázis szervert futtató gép hostneve kerül oda.
Általában a rendszergazdák letiltják, hogy bármilyen külső gépről csak úgy csatlakozni lehessen az adatbázishoz. Szerintem kérdezd meg a rendszergazdától, hogy engdélyezett-e, és ha igen, akkor milyen hostnéven lehet elérni az adatbázist a távoli gépen. -
cucka
addikt
Image resize függvénnyel nem oldható meg, mert (ahogy a neve is mondja), az azt tudja, hogy a képet átméretezi.
Ha vízjel szerűen szeretnéd rárakni a képet, akkor nézd meg az imagecopyresampled függvényt. Ha rajzolgatni szeretnél rá, akkor arra is megvannak a megfelelő függvények, válogass. [link]A transzparens hátterű png alatt nem tudom, mit értesz, igazából ilyen fogalom nincs. A transzparens png úgy működik, hogy a 24 bitnyi rgb információ mellett minden képpontnak van egy 8 bites "alpha channel"-je, ami gyakorlatilag azt jelenti, hogy képpontonként 256-os skálán állíthatod be az áttetszőséget. Ha olyan képet szeretnél készíteni, ami lekerekített és a "kerete" áttetsző, akkor megoldható, lásd imagealphablenging() függvény.
-
cucka
addikt
Akkor az a feladatod, hogy rajzolsz egy fehér, lekerekített keretet, aminek a közepe lyukas. Van egy képed, egy kereted, ezeket kell összekombinálni imagecopyresampled vagy imagecopymerge függvénnyel.
Ugyanaz a feladat, mint ha vízjelezni szeretnéd a képet, csak itt a vízjel az az előre megrajzolt lekerekített keret. -
cucka
addikt
válasz RoyalFlush #4060 üzenetére
Gondolom a "php4 24 óra alatt" c. könyvből tanulsz .
-
cucka
addikt
válasz rebugra #4066 üzenetére
if ($_POST["submit"]=="Küldés") {
Itt például lehet probléma a karakterkódolással. Igazából ilyet soha nem csinálunk, mert ha a html-ben átírod a gomb feliratát, akkor máris működésképtelenné tetted a scriptet.A levél pedig azért néz ki furcsán, mert utf8-as kódolással küldöd, de a levél fejlécében ez nincs beállítva, a levelezőprogram pedig ennek hiányában iso 8859-x kódolással próbálja megjeleníteni.
Javaslom, hogy a korábban említett levélküldő osztályok közül használd valamelyiket, mert nem annyira egyszerű feladat simán csak mail függvénnyel megoldani. -
cucka
addikt
válasz Sk8erPeter #4079 üzenetére
Az általad keresett megoldás egyszerűbb, mint gondolnád. Amikor feldolgozod az űrlapon elküldött adatokat, azzal kezded, hogy kiszeded ismét az adatbázisból a kiválasztott kategóriákat, és kész is, megvannak a korábbi elemek. Ezután rakod össze a delete/insert lekérdezéseidet, amivel módosítod a kategória hozzárendelést.
Amúgy én az általad írt 3. megoldást használnám, pusztán azért, mert egyszerű és átlátható. A kategóriába rendezés viszonylag ritka esemény, kevés adatod van, így gyorsaságban rendben van ez a megoldás is.
tegyük fel, hogy mondjuk csak egyetlen helyről kiszedem a pipát, akkor az összes hozzárendelést törli, és adhatja hozzá újra az összeset, ez felesleges munka
Ha mindig csak a szükséges módosításokat szeretnéd elvégezni az adatbázison, az meg neked felesleges munka .ráadásul mi van, ha megszakad valamiért a folyamat, akkor elvesztek az addigi hozzárendelések
Ez nehéz kérdés. Általában ilyen akkor történik, ha valami komoly hardveres/szoftveres gond van a szerverrel. Nem nagyon tudsz tenni ellene semmit, de szerencsére nem is nagyon szokott ilyesmi előfordulni.
(Nyilván, egy banki rendszernél erre is fel kell készülni, de most nem erről van szó )[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #4081 üzenetére
Vagyis így a hozzászólás végére eljutottam arra a következtetésre, hogy lehet, hogy semmivel nem lenne erőforrás-igényesebb az, ha mindent törölnék, és mindent újra hozzáadnék
Na látod..vajon melyik működik gyorsabban, a MySQL törlő és hozzáadó műveletei, vagy a PHP összehasonlítgatásai, majd egy MySQL-törlés illetve -hozzáadás...
Esetedben mindkettő megfelelően gyors, azt válaszd, amelyikkel kevesebb a munka. Semmi értelme vadászni a századmásodperceket.Nyilván, ha olyan rendszered van, ahol a táblában több millió sor van és viszonylag gyakran nézegetik, akkor az a cél, hogy minél kevesebb és minél gyorsabb lekérdezésed legyen, de nálad most gondolom nem ez áll fenn. Általában egy nagy terhelésű rendszeren az adatbázis i/o a szűk keresztmetszet, nem pedig a processzor sebessége. Kis terhelésnél annyira minimális a különbség, hogy nem érdemes túl sokat foglalkozni a kérdéssel.
-
cucka
addikt
válasz Sk8erPeter #4084 üzenetére
A GET-ben a gombra vonatkozó érték pusztán annyi információt hordoz, hogy elküldték-e az űrlapot vagy sem.
- Ha csak egy gombod van, akkor a legegyszerűbb, hogy nem adsz neki nevet, az űrlapba pedig beleraksz egy hidden mezőt, ami átveszi a gomb funkcióját.
- Javascript-el submit-olod a form-ot, ilyenkor az elküldéshez használt gomb bármi lehet, nem is kell része legyen az űrlapnak.Itt nincs semmilyen nagy trükk, amiről még ne hallottál volna .
-
cucka
addikt
válasz Sk8erPeter #4089 üzenetére
Csak azért, mert érdekelne, az egyes módszerek, függvények felhasználástól függően vajon nagyjából mennyi erőforrást (memóriahasználat, prociigény) igényelnek.
Microtime-al tudsz időt mérni, memory_get_usage-el tudsz memóriahasználatot mérni. Esetleg felrakhatod a zend szervert, ott kapsz pl. profile-ozási lehetőséget.ezért akárhányszor frissítek a böngészőben, a microtime() függvény mindig más eredményt ad...
Rossz végén fogod meg a kérdést. Ha gyorsítani szeretnél egy rendszeren, akkor először azt kell meghatározni, hogy hol lassú és hogy miért, ezután pedig kitalálni, hogy egyáltalán tudsz-e rajta gyorsítani és ha igen, akkor hogyan.
Ha a rendszered nem lassú, megfelel a sebességi követelményeknek, akkor nem kell gyorsítani rajta. (Pontosabban lehet, csak senki nem fogja neked kifizetni)
A valóságban úgy néz ki a dolog, hogy van egy rendszer, ami normális sebességgel működik, kivéve 1-2 műveletet/erőforrást. Ezeket hívjuk bottleneck-eknek. Ha gyorsítani kell a rendszeren, akkor ezeket kell megtalálni és ezeknél kell kitalálni, hogy mitől lassú. Weboldalnál szinte mindig egy lassú lekérdezés lesz a bűnös, ha ez megvan, akkor lehet elemezni, hogy mivel gyorsítod fel. Tehát ha lassú egy rendszer, akkor nem attól lassú, mert mysql helyett mysqli-t használsz, vagy fordítva. -
cucka
addikt
válasz Sk8erPeter #4100 üzenetére
hogy egymás utáni mysql_query-ket hajtottam végre, az a kódban meg elég csúful mutat, sokkal szebb, ha konkatenálom egy sztringbe a lekérdezéseket, majd egymás után végrehajtom MySQLi-függvényekkel, ahogy írtam.
Nem tudom, mitől szebb. Ha arra van szükséged, hogy 2 query-t lefuttass egymás után, akkor azt le kell futtatni egymás után, miért csúnya ez?Meg egyébként még nem dolgozom komoly cégnél, mint honlapszerkesztő
Annak idején az első munkámat úgy kaptam meg, hogy lóf*szt se értettem az egészhez. Konkrétan javascript-et az első, beugró feladatomnál írtam először .mik azok a megoldások, amik a lehető legkisebb erőforrást igénylik, és a leggyorsabb megjelenítést eredményezik.
A valóságban ennél sokkal fontosabb, hogy olyan megoldásokat alkalmazz, amelyek részedről igénylik a legkevesebb erőforrást. Senki sem fog fizetni azért, mert megspóroltál 0.3% processzoridőt, vagy hogy 0.2 másodperc helyett 0.13 alatt jön be a weboldal. -
cucka
addikt
ez normális dolog?
Persze hogy normális, különben nem működnének a session-ök .
Ha két külön session-t szeretnél a két php-ban használni, akkor adj nekik egyedi nevet a session_name() függvénnyel.A legjobb lenne hackelés helyett átírni mindent $_POST, $_GET és $_SESSION verzióra, igaz?
Igen. -
cucka
addikt
válasz Sk8erPeter #4108 üzenetére
Számomra utóbbi áttekinthetőbb... Szerinted?
Az első verzió jobb. Nem minden query ilyen rövid, ezen kívül úgy lehet normálisan kommentezni a kódot. Azt az or die.. részt pedig amúgy sem használom sehol, tehát nem rontja a látványt. -
cucka
addikt
válasz egyjotakaro2 #4114 üzenetére
Ott a google link, ott az első találat.
Ha ennyire nem akarod megoldani a problémádat, akkor miért fárasztasz ezzel másokat? Nem fogja senki a fejedbe önteni a tudást, ha nem tudsz megtalálni és elolvasni egy tutorialt/leírást a neten, akkor keress egy szakembert, aki megoldja helyetted. -
cucka
addikt
válasz egyjotakaro2 #4116 üzenetére
php chat free
Rákattintottál egyáltalán a #4111-ben található link-re? -
cucka
addikt
válasz egyjotakaro2 #4119 üzenetére
Warning: require_once(/phpfreechat-1.2/src/../i18n/en_US/main.php) [function.require-once]: failed to open stream: No such file or directory in /phpfreechat-1.2/src/pfci18n.class.php on line 65
Azt mondja, hogy van egy file (ott az elérési útvonala), amit nem talál a rendszer. Első körben nézd meg, hogy ott van-e a file, ahol keresi. Valószínűleg telepítésnél/beállításnál rosszul adtál meg valamilyen elérési útvonalat.
Amúgy meg azzal érdemes tisztában lenni, hogy a weboldal készítés egy szakma, tehát ehhez érteni kell. Egy ilyen php-s chat-nek nem célja, hogy akár a titkárnő is fel tudja telepíteni és be tudja állítani, tehát ha így állsz hozzá, akkor nincs sok esélyed.[ Szerkesztve ]
-
cucka
addikt
válasz egyjotakaro2 #4123 üzenetére
Ha a php azt mondja, hogy nem találja a file-t, akkor az azért van, mert nincs ott a file, ezt nem tudom jobban elmagyarázni.
Amúgy a require_once a /phpfreechat-1.2/src/../i18n/en_US/main.php file-t keresi, de azt erősen kétlem, hogy erre az útvonalra telepítetted volna, tehát valamelyik beállítás rossz. (Az útvonal a linux filerendszer gyökerében található phpfreechat mappára mutat, ami nyilván nem létezik)
-
cucka
addikt
válasz egyjotakaro2 #4129 üzenetére
Arról van szó, hogy azt kérdezi, a szerver filerendszerében milyen könyvtárba szeretnéd telepíteni. Ez nem egyezik meg a webes elérési útvonallal, sokszor a kettőnek nincs sok köze egymáshoz.
-
cucka
addikt
válasz fordfairlane #4137 üzenetére
Mi az a pdo?
-
cucka
addikt
válasz egyjotakaro2 #4142 üzenetére
Mit? Én csak egy képet látok, amin azt írja, hogy nálam nem fog működni.
Az a kérdés, hogy lehet-e látogatószámlálót írni, vagy kirakni a pontos időt php-ban? Természetesen lehet. -
cucka
addikt
válasz Sk8erPeter #4145 üzenetére
Mondjuk ha már itt tartunk, akkor a pontos időt felesleges kiírni
(#4141) DeltaPower
Jópofa, de mennyire használható a valóságban (pl. a bind-elések)? Továbbá felmerül a kérdés, hogy nem túl lassú? -
cucka
addikt
válasz raczger #4151 üzenetére
Igen, lehet.
A reguláris kifejezésed nem jó, a []-n belül a - speciális karakternek számít, ha azt szeretnéd, hogy arra match-eljen, akkor zárd le egy \-el. (Bár erre magadtól is rájöhetsz, ugyanis a példádban használod is speciális karakterként)Továbbá a [^0-9a-z_-] -val van még egy baj: itt mire is akarod ráilleszteni a mintát? Mert eszerint sem betűkre, sem pedig számjegyekre nem fog illeszkedni, másfajta karakterrel viszont ritkán találkozunk url-ben..
A visszahivatkozásnál pedig a $1 az első lehetséges hivatkozást fogja jelenteni. Ha te a taglista utáni szöveget akarod kinyerni, akkor arra $2-vel hivatkozhatsz. (Vagy a .*-ot nem rakod zárójelbe, amúgy is fölösleges)
A reguláris kifejezésed végét pedig zárd le egy $-al, hogy mindenképp a teljes url-re match-eljen.
[ Szerkesztve ]
-
cucka
addikt
válasz Orb1337 #4156 üzenetére
Azon fáradozom, hogy Javában megszerzett OOP tudásomat "átültessem" PHP-ra is.
Hát izé, ne várj sokat a php-s oop-tőlA kérdésem az lenne, ha több classból álló problémát kellene megoldanom, azt egy osztalyok.php fájlban hozzam létre?
Van rá lehetőség, [link]
Röviden annyi, hogy írsz egy __autoload nevű függvényt. Ha a php semmilyen módon nem tudja megtalálni a hivatkozott osztály nevét, akkor meghívja ezt a függvényt, paraméterként átadja a keresett osztály nevét, aztán oldd megPéldául ha a /var/www/weboldal_neve/classes mappában vannak az osztályaid és class_valami.php nevű file-okban találhatók, akkor valami hasonlót kell írni:
function __autoload($class_name){
require_once('/var/www/weboldal_neve/classes/class_'.$class_name.'.php');
}A lényeg, hogy olyan módon kell elhelyezd/elnevezd az osztályaid file-jait, hogy osztálynév alapján automatikusan be tudd include-olni. Ezt a php a script minden futásakor végigzongorázza, tehát ha az autoload bonyolult (pl. egy adott könyvtárban rekurzívan keres), akkor a már megtalált osztályok neveit cache-eld file-ba.
-
cucka
addikt
válasz raczger #4159 üzenetére
Amúgy erősen javaslom, hogy értsd is meg, mit csinál a .htaccess file-od.
Például a ^taglista/(.*)$ reguláris kifejezés (ezt írtam pár hsz-el előtt) match-elni fog bármilyen url-re, ami úgy kezdődik, hogy "taglista/". Tehát nem csak a taglista/raczger-re, hanem a "taglista/konyvtarnev/valami/asd?param1=val1" url-re is. Ezt php-ból le kell kezelned, különben ez egy biztonsági lyuk lesz a rendszeredben. -
-
cucka
addikt
válasz Sk8erPeter #4350 üzenetére
Hát ki az az állat, aki URL-ben vagy POST-ban elküldött SID alapján elfogad egy belépési kísérletet?
Mert ugye a felhasználónál cookie-ban tárolt SID az sokkal megbízhatóbb adat.. -
cucka
addikt
válasz 8nemesis8 #4425 üzenetére
A header-en kívül nincs valami amivel lehet frissíteni az oldalt!?
Nincs. Igazából a header-el sem tudod frissíteni az oldalt.
A folyamat úgy működik, hogy ha a felhasználó lekér egy oldalt, akkor a kérés eljut a szerverhez, a szerver pedig valamit csinál, majd visszaküld a felhasználónak valamilyen adatot http protokollon keresztül.Egy php oldal esetén a szerveren az elküldött adat a php kód kimenete lesz. A header() függvénnyel a http adatcsomagok fejlécét tudod módosítani, ezért is hívják header-nek . A szerver oldalon a http fejléc akkor jön létre, amikor a script-ed először kiír valamit a kimenetre (ugyanis a http fejléc mindig meg kell előzze a http adatokat), ezért van az, hogy az első kiírás után a header-t már nem lehet használni. (És ugyanezért nem lehet használni a setcookie-t sem azután, hogy kiírtál valamit, mert a sütikkel kapcsolatos teendők is a http fejlécben találhatók. És ezért nem lehet általában session-t indítani kiírás után, mert az szintén egy cookie létrehozását jelenti)
-
cucka
addikt
válasz 8nemesis8 #4427 üzenetére
Általában véve a php kódot úgy kell megírni, hogy először van az alkalmazáslogika (bármilyen művelet, amit a script-nek el kell végezni) és csak ezután jön a kiírás rész, amikor legyártod a html-t. Ez utóbbinál már semmiféle alkalmazáslogika nincs.
Ha valamilyen sablon rendszert használsz (pl. smarty), akkor gyakorlatilag nincs is más lehetőséged, rá vagy kényszerítve a fent említett két folyamat különválasztására. -
cucka
addikt
Az implode() függvény az a mysql_real_escape_string() függvény része, vagy használható önállóan is?
Nem létezik ez a fogalom, hogy egy függvény egy másiknak a része. Valószínűleg nem érted a strukturált programozás alapjait és nem tudod, hogy a korábban kapott programkódod mit csinál pontosan.
A mysql_real_escape_string arra való, hogy a paraméterében található string-ben lezárja a speciális karaktereket.
Az implode arra való, hogy egy tömb elemeit egy string-ben felsorolja.pl.
$tomb=array('alma', 'korte', 'barack');
print implode('/', $tomb);
Azt fogja kiírni, hogy "alma/korte/barack".Hogy neked mire van szükséged, azt nem tudom, mint ahogy azt sem, hogy a $_POST[termek1] micsoda.
[ Szerkesztve ]
-
cucka
addikt
válasz Balint133 #4504 üzenetére
Természetesen webmestertől meg lehet kérdezni, de ezt nem nagyon szokták bekapcsolgatni.
Általában ssh tunnel-t adnak erre a célra.Ezzel a stringgel azt kéne csinálni, hogy minden betűt és vesszőt, írásjelet mindent kiszedni belőle, csak a számok maradjanak vissza.
$szamok=preg_replace('/\D/','',$str);
[ Szerkesztve ]
-
cucka
addikt
válasz scott_free #4573 üzenetére
Na látom még senkinek nem tűnt fel egy apróság, ezért beleszólok én is.
Egy dolog a weboldalad karakterkódolása és egy teljesen más dolog a php programod által elküldött email karakterkódolása. A weboldalad karakterkódolásának tulajdonképpen semmi köze az email küldéséhez.Ahhoz, hogy egy weboldalról a megfelelő karakterkódolásban kapd meg az adatokat, a következőkre figyelj:
- a weboldalad szövege megfelelő karakterkódolású legyen
- a <head> részben töltsd ki a karakterkódolást
- előfordulhat, hogy a http header-ben is be kell állítsd a karakterkódolást (szerverfüggő)A levél küldéséhez pedig javaslom, hogy használj valamilyen előre megírt osztályt, mondjuk a phpmailer-t. Ott megadod a karakterkódolást és kész vagy, minden mást elintéz neked az osztály.
Amúgy ha nem akarod szivatni magad, akkor az adatbázisodnál, a honlapodnál és a php szkripted minden eleménél ugyanazt a karakterkódolást használd. (Lehetőleg utf8-at)
-
cucka
addikt
válasz Sk8erPeter #4577 üzenetére
Ez most lehet, hogy csak számomra tűnik ellentmondásosnak.
Pedig nem ellentmondásos, csak lehet, nem fogalmaztam elég világosanA levélküldés és a weboldal karakterkódolása között elvileg nincs kapcsolat. Érted, írhatsz olyan php scriptet, ami semmiféle weboldalt nem gyárt, mégis küldi a levelet.
A jelen esetben viszont a levél tartalma a weboldalon található form-ból jön, na itt már nem mindegy a weboldal kódolása. A böngészők olyan kódolással fogják küldeni az űrlapra felvitt adatokat, amilyen kódolást megadtál a honlapodnál.Szép dolog az előre megírt osztályok használata, de tulajdonképpen jó lenne rábírni, hogy rendesen működjön saját módszerrel is, abból lehet tanulni, ha Te írod meg.
Ez esetben meg lehet nézni a phpmailer forráskódját, hogy lásd, milyen header-öket állít be a levélhez. Azért nem érdemes vele tökölni, mert a levelezőprogramok eltérően viselkednek, tehát megkíméled magad egy csomó fölösleges problémától. Például van olyan levelezőprogram, ami hibásan jeleníti meg a levél tárgyát, ha az utf8-as kódolású és ékezetes karaktereket is tartalmaz. Lehet tökölni azzal, hogy kitalálod, hogyan kell kódolni az email header-jében a subject sorokat ahhoz, hogy minden levelezőprogramnak jó legyen, csak nem látom értelmét, ugyanis a probléma már meg van oldva, ingyenes, lehet használni, ha érdekel, hogy hogyan működik, akkor ott a kód, meg lehet nézni, stb.Amúgy meg elég nehézkes dolog a levelezést tesztelni. Van rengeteg levelezőprogram, ott vannak a különféle verziójú outlook-ok, az összes webes levelezőrendszer, senkinek nincs arra ideje, hogy ezeken mind végigzongorázza, hogy vajon jó-e az a levélküldő kód, amit írt. Elég nagy probléma szokott azzal is lenni, ha az ügyfél szépen formázott, weboldal-szerű html levelet szeretne kiküldeni, mert minden egyes levelezőprogramnak vagy weboldalnak megvannak a saját maga hülyeségei.
-
cucka
addikt
válasz scott_free #4580 üzenetére
Gyors válasz: levélküldéshez használj phpmailer-t, az megoldja.
-
cucka
addikt
Aha, és ha mondjuk listázni szeretném a liciteket, akkor minden egyes esetben végigzongorázza a rendszer a több tíz/százezer terméket? A termékek/licitek listázása pedig elég gyakori egy ilyen oldalon. Ennél sokkal jobb az éjféli ütemezett feladat, ami amúgy nem feltétlenül lassú, tekintve hogy nem kell az összes liciten végigmenni, csak amelyik aktív státuszú és éppen lejárt az érvényessége.
-
cucka
addikt
válasz Louloudaki #4604 üzenetére
Szerintem valamit félreértelmeztél.
A session-t a php kezeli, nem kell semmit elküldj cookie-ban a felhasználónak (főleg nem md5 hash-t). Az egyetlen dolog, amit felül kell bírálj, az az, hogy a session-ban található adatokat hol tárolod. Alapértelmezésként ezek file-ként vannak tárolva, ezt kell átírd.
A php.net-en a session_set_save_handler() dokumentációjánál ott a legelső példaprogram, ahol felüldefiniálja ezeket, gyakorlatilag ezt a példa kódot kell átírd úgy, hogy ne file-ba mentsen, hanem adatbázisba.
A session id-je mindig egyedi, ezzel tudod azonosítani a session-t, ezt használhatod az adatbázisos tárolásnál is.