- Vodafone-ra áttért Digi Mobilosok
- iOS alkalmazások
- Redmi 13C - C-terv
- Samsung Galaxy S24 - nos, Exynos
- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Dimensity 8250-ként hasznosítja újra a Dimensity 8200-at a MediaTek
- Fotók, videók mobillal
- Samsung Galaxy A55 - új év, régi stratégia
- Xiaomi Mi 10T Pro - a házon belüli ellenfél
Hirdetés
-
Jövő év őszén jön a Mortal Kombat mozifilm folytatása
gp A folytatásban felbukkan végre Johnny Cage is, akit Karl Urban alakít majd.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
Bemutatta első táblagépét saját neve alatt a HMD
ma De ahogy arra számítani lehetett, ez is egy kétéves Nokia eszköz átnevezve.
Új hozzászólás Aktív témák
-
#6551
Sk8erPeter
nagyúr
biker
#6549
Sk8erPeter
nagyúr
A shuffle_assoc()-ot leszámítva teljes körű kódnak számít, működőképes (persze ha az eredeti angol2() fv.-t is kiveszed)...
DE az nem tűnt fel, hogy ilyenformán:
shuffle_assoc($Cimke);
a shuffle_assoc rohadtul nem változtat a $Cimke tömbön semmit?
A függvény egy tömbbel tér vissza, az meg így csak elvész az éterben.
Legfeljebb így működik:
$Cimke = shuffle_assoc($Cimke);(#6540) Speeedfire: neked is javaslom a fenti javítást.
(már ha nálad a shuffle_assoc() fv. nem referenciát kap paraméterként, ahol a $list tömbön végzel változtatásokat - pl. function shuffle_assoc(&$list) { ..... } )[ Szerkesztve ]
Sk8erPeter
-
#6554
Sk8erPeter
nagyúr
Speeedfire
#6553
Sk8erPeter
nagyúr
válasz
Speeedfire
#6553
üzenetére
Hát ha nem dob warningot vagy fatal errort, akkor lennie kéne ilyen függvényednek, aminek lehet, hogy referenciaként van átadva a tömb.
Sk8erPeter
-
#6562
Sk8erPeter
nagyúr
Speeedfire
#6559
Sk8erPeter
nagyúr
válasz
Speeedfire
#6559
üzenetére
"Nem szokták"
Kik nem szokták?
Nyilván van, aki átmeneti adatbázis-bejegyzést hoz létre ilyenkor, de én nem pazarlom ilyenekre az adatbázis korlátozott erőforrásait, épp ezért is használom legtöbbször a sessiont ilyen célra (is). Persze csak addig tárolom, ameddig nagyon szükséges - leginkább hiba esetén. A form adatait mindig külön feldolgozó fájlban dolgozom fel, és amennyiben ezt nem AJAX-szal oldom meg (azért úgy a szép, de működjön annál is, akinél ki van kapcsolva a JavaScript), akkor ha nincs hiba, eltárolom az adatokat adatbázisban, ha mégis hiba történt, a form adatait elmentem session-változókba, hogy a felhasználónak ne kelljen újra begépelnie az adatokat (szerintem ez elég fontos, engem is halálra idegesít, ha nem így oldják meg), majd visszairányítom a júzert az eredeti oldalra (ahonnan a formot elküldték), és ott a form megfelelő mezőibe kiíratom a session-változókban tárolt korábbi űrlapadatokat, majd ezután rögtön meg is szüntetem ezek tárolását (a formon már úgyis látszik, majd a felhasználó elküldi újból ugyanezeket az adatokat, ha nagyon akarja).
Érdemes ezeket az adatokat egy többdimenziós megoldással tárolni, hogy könnyű legyen őket megszüntetni is, valahogy így (egyszerű példa):
$_SESSION['form_data'] = array();
$_SESSION['form_data']['user_name'] = $_POST['user_name'];
$_SESSION['form_data']['user_address'] = $_POST['user_address'];
// ....
Ha meg akarod szüntetni az eltárolt formadatokat, elég ennyit csinálni:
unset($_SESSION['form_data']);Sk8erPeter
-
#6564
Sk8erPeter
nagyúr
Speeedfire
#6563
Sk8erPeter
nagyúr
válasz
Speeedfire
#6563
üzenetére
Abban az esetben nem is kell, ha
1.) a formok feldolgozását ugyanott végzed, ahol maga a form kiíratása van (tehát nem külön fájlban, így a POST adatokat egyből közvetlenül fel is tudod használni a formmezők kitöltésére - de ez szerintem gány megoldás),
2.) ha átmeneti adatbázis-bejegyzést hozol létre a felhasználó által megadott adatokkal, amit csak akkor hagysz meg, ha a felhasználó véglegesíti az adatokat (korlátozott lehet az adatbázisban elérhető kapcsolatok száma)
3.) vagy akkor, ha egyszerűen nem foglalkozol vele, hogy a felhasználónak ki kell-e töltenie újból az űrlap egyes mezőit, vagy sem
4.) ha bejelentkeztető űrlapról van szó, ahol pl. csak felhasználónév-jelszó párost kell kitölteni, itt nyilván az esetek többségében nem kell megjegyeztetni semmit
5.) biztos van olyan eset, ami most nem jut eszembe.DE érdemes bevetni a session képességeit ilyen esetekre is, igazából mi másra lenne használható, mint adatok átmeneti tárolására, akár egy egész session erejéig, vagy csak rövidebb időtartamra.
Nyilván formadatokat is csak addig tároljunk session-változókban, amíg nagyon szükséges.[ Szerkesztve ]
Sk8erPeter
-
#6566
Sk8erPeter
nagyúr
Tele von Zsinór
#6565
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6565
üzenetére
Ja, nyilván attól függ, hogy oldod meg. Nálad nem tudom, hogy van konkrétan, azt nem írtad.
Van egy formod, az elküldi a post adatokat egy másik fájlnak, ott meg hiba esetén megint ugyanúgy kiíratod a formot, meg az oldal többi részét, vagy hogyan?Amúgy az szerintem ultraronda megoldás, ami a Wordpress-motort használó weboldalak többségénél szokott lenni adott cikkhez történő hozzászólásnál fellépő hiba esetén, hogy dob neked egy hibaoldalt, egy pici keretben kiírva a hibaüzenetet, az oldal egyéb részei egyáltalán nem látszanak, és csak a böngészőben az eredeti oldalra való visszanavigálást követően tudod megfelelően módosítani a form kitöltését. (Persze egyes böngészőknél ilyenkor a visszanavigálásnál törlődik is az eredeti hsz., fasza.)
Sk8erPeter
-
#6568
Sk8erPeter
nagyúr
Tele von Zsinór
#6567
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6567
üzenetére
A felvázolt megoldásban nekem egyedül az nem szimpi (persze ízlés kérdése), hogy ugyanabban a fájlban történik a validálás, mint amiben a form kiíratása - én pont azért tértem át inkább arra, hogy még a validálás során is redirectelgetek (még ha nem is lenne feltétlenül muszáj/praktikus sessionben tárolni az adatokat, bár nem hiszem, hogy ezen múlnának a teljesítménybeli különbségek), mert nagyon zavar, amikor egy form elküldésekor F5 (frissítés) lenyomása hatására a böngésző visszakérdez (Opera általában nem teszi), hogy elküldje-e még egyszer a $_POST-adatokat. Engem ez legalábbis felhasználóként is zavar: ha bármi miatt úgy döntök, hogy frissíteni szeretnék, és nem probléma, ha elvesztem a begépelt adataimat, akkor hadd tegyem ezt visszakérdezés nélkül.
(Bár hozzáteszem, pl. Gmailnél el nem mentett levél elküldésekor, vagy szerver felé történő függőben lévő kérés megszakítási kísérlete esetén, vagy épp a stackoverflow oldalán történő hsz.-íráskor jól jön, hogy figyelmeztet, hogy még nem mentettem/küldtem el, amit akartam. DE ez szándékos és indokolt fejlesztőoldali dolog, nem a böngésző egyéni döntése, hogy most akkor jól figyelmeztesse a felhasználót, szerintem egészen más a kettő "hangulata". )Sok oldalon a keresőmezőkbe beírtakat is azonos oldalon dolgozzák fel, olyankor is sűrűn előfordul az F5-nyomkodásos probléma, az még zavaróbb, az ember adott esetben többször keres, mint amennyiszer mondjuk hozzászól adott oldalhoz, cikkhez, ilyenkor F5 nyomkodására mindig megakasztja a böngészést a figyelmeztető ablak a post-adatok újbólli elküldéséről.
Mostanában nagyon sokszor megpróbálom inkább AJAX-szal megoldani a dolgokat, mert az úgy szebb felhasználói szempontból, mint az egészoldalas frissülés - ráadásul akkor az F5-ös és redirectelős probléma egy része is megoldódhat, AJAX-os feldolgozásnál lehet egyből kiíratni is (máskor is lehet, de mint fentebb mondtam a Wordpress-es példát, nem túl szép a külön hibaoldal, majd visszanavigálási kényszer).
[ Szerkesztve ]
Sk8erPeter
-
#6570
Sk8erPeter
nagyúr
Tele von Zsinór
#6569
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6569
üzenetére
Igen, a keresés get-tel okés, ott nem para az esetleges frissítés, de még mindig vannak oldalak, ahol post-olják a keresőmezőben megadottakat (most hirtelen az ncore jut eszembe, ahol kifejezetten zavar). Meg ugye a get-tel történő kereséskor kapott cím lementhető, könyvjelzőzhető, átküldhető másnak, szóval ezer szempontból praktikusabb.
Az első felére reagálva: na, akkor úgy tűnik, félreértettem, sorry.
"a form actionja ugyanaz a file és függvény lesz" - innen elsőre úgy értelmeztem, hogy ugyanabba a fájlba irányítod vissza az adatokat, tehát ugyanott dolgozod fel.
"Ha invalid, vissza ugyanahhoz a view-hez, csak most már hibaüzenetek is vannak"
Ez hogy néz ki nálad a gyakorlatban?
Pl. van a foo.php fájl, amiben megtörténik a kiíratás (ezt a címet kérte le a júzer), és van egy formod:
<form action="bar.php" method="post" ..........>..........</form>
Ekkor az action szerinti bar.php fájlba irányítja át a formot. Itt csekkolod, hogy valid-e, ha nem, egyből kiíratod a formot? Mert akkor megint felmerül az F5-ös probléma. Vagy pedig van a foo.php fájl, és az action-ben is ugyanez a fájl található, és itt nézed meg a validitását? Igazából itt is felmerül az F5-ös para. A visszairányítós játéknál nyilván nincs ilyen probléma, de ott meg már elvész a post-olt adat (amennyiben nem mented sessionbe).Most hirtelen nem értem, hogyan éred el, hogy validálod az adatokat, fel tudod használni azonos kéréssel a $_POST tömb adatait (tehát a felhasználónak nem kell begépelnie újból azokat), kiíratod, nem mented el sessionbe a dolgokat, és még az F5-ös frissítgetős para sem merül fel?
[ Szerkesztve ]
Sk8erPeter
-
#6572
Sk8erPeter
nagyúr
Tele von Zsinór
#6571
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6571
üzenetére
Sejtettem, hogy ilyesmi, meg értem én az MVC-szemléletet nagyjából, csak azt hittem, hogy nálad mégsem fordul elő az említett F5-ös frissítgetős probléma, és az nem állt össze, hogy hogyan lehet, ha nem redirectelgetsz minden esetben.
(de ezek szerint a probléma fennáll)
Szerintem az én koncepcióm sem mond amúgy ellent az MVC-szemléletnek.Mostanság igyekszem én is nagyjából errefelé tendálni, meg teljesen OOP-szemléletre átállni, ami szerintem eléggé megkönnyíti a munkát az MVC-nél (én legalábbis nehezen tudom igazán elválasztani tőle), bár még bőven van mit tanulnom.
[ Szerkesztve ]
Sk8erPeter
-
#6574
Sk8erPeter
nagyúr
Tele von Zsinór
#6573
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6573
üzenetére
Az lesz.
Csak egy kis idő kellene hozzá. Mondjuk egyelőre élvezem azt, hogy mindent megírok magamtól, aztán majd úgyis jól rájövök a komolyabb keretrendszerek használatakor, hogy nem biztos, hogy sok értelme van mindent ab ovo megírni, ha már más úgyis megtette helyettem, mert akkor nekem csak a megfelelő függvényeket kell jól hívogatnom, és a megfelelő módosításokat elvégezni, aztán gyorsabban kész vagyok.Igen, én sem úgy értettem, hogy MVC-t csak OOP-szemlélettel lehet írni (ezért is csak azt írtam, hogy "eléggé megkönnyíti a munkát az MVC-nél"), de szerintem procedurálisan megírva azért sokkal önszívatósabb, nehezebb átlátni.
Mondjuk nem véletlenül találták ki az OOP-t, ha már hasonlít az emberi gondolkodás működéséhez, használjuk is ki.
Sk8erPeter
-
#6577
Sk8erPeter
nagyúr
klinnsy
#6575
Sk8erPeter
nagyúr
válasz
klinnsy
#6575
üzenetére
Jó, hát akkor használd a Programkód gombot (többek közt itt is leírtam, hogyan kell) a kódod kijelölése után, mert ilyen formázatlan, indentálatlan kódot kétlem, hogy bárki át fog nyálazni itt a topicban (hacsak nem rakja be mondjuk NetBeans-be vagy dobja be PHPBeautifierbe, stb, és autoformáz), én legalábbis biztosan nem. De persze előfordulhat, hogy valaki mégis veszi a fáradságot, de előbb inkább te tedd meg ugyanezt a kód megfelelő formázására.
Meg nem ártana, ha leírnád, te milyen körülmények közt próbáltad, mert a "Már néztem több gépről, nekem nem működött, mi lehet a baj?" mondatrészből számomra legalábbis nem derül ki. (Pl. egyáltalán működő webszerverrel próbáltad-e, te mit tapasztaltál, nálad mi történt, egyáltalán lefutott-e a PHP-kód, és így tovább...)Szerk.: csak belenézve a kódodba, számomra elég durván fájó kódrészletek vannak, pl. csak ez szúrt szemet:
echo "<tr><th><font color=ffffff size=2><div align=center>Válaszok</th><th><font color=ffffff size=2><div align=center>Szavazatok aránya</th><th><font color=ffffff size=2><div align=center>Szavazatok száma</th></tr>";
Eleve a <font> tag használata nagyon nem ajánlott ma már (CSS), na meg az attribútumok esetén eléggé ajánlott az idézőjelek használata, pl. align=center helyett align="center", de még jobb, inkább ezt az align attribútumot ne is használd.[ Szerkesztve ]
Sk8erPeter
-
#6579
Sk8erPeter
nagyúr
klinnsy
#6575
Sk8erPeter
nagyúr
válasz
klinnsy
#6575
üzenetére
Példa a kód utólagos formázására:
http://beta.phpformatter.com/
>> Format >> Copy to Clipboard
http://pastebin.com
>> Syntax Highlighting: PHP
>> Submit
>> Eredmény: [link]Mondjuk ez nem változtat a tényen, hogy ocsmány a kód.
A lényeget Tele von Zsinór kolléga leírta.Sk8erPeter
-
#6586
Sk8erPeter
nagyúr
Alukard
#6585
Sk8erPeter
nagyúr
válasz
Alukard
#6585
üzenetére
Ha már újratervezés, érdemes lehet megfontolni, hogy TIMESTAMP formában tárold az időpontot, az elég jól átlátható, könnyen kibányászható belőle az időpont (év-hónap-nap óra:perc:másodperc), meg beállítható úgy, hogy automatikusan frissüljön az aktuális időpontnak megfelelően, MySQL-nél:
CREATE TABLE `teszt_tabla` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`valami` VARCHAR( 256 ) NOT NULL DEFAULT 'blabla',
`timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_hungarian_ci;Vagy ha UPDATE-nél a `timestamp` = NOW() kódrészletet rakod bele a query-be (de mivel a fenti mutatott táblában a default a jelenlegi idő, ki is hagyható teljesen a kódból a timestamp beállítása).
Így talán egyszerűbb és átláthatóbb lehet a kódod, és ha nem PHP-ből kéred le az időt, hanem MySQL-ből, az nem valószínű, hogy túl sokáig foglalná az adatbázis esetleg korlátozott erőforrásait.Én mostanában legalábbis már így csinálom, gondolom mindkét gyakorlatra lehetne érveket felhozni. De a fentivel legalább semmiképp nem ronthatod el az időformátumot, meg nem kell babrálni annak a mezőnek a beállításával.
[ Szerkesztve ]
Sk8erPeter
-
#6589
Sk8erPeter
nagyúr
RedSign
#6588
Sk8erPeter
nagyúr
válasz
RedSign
#6588
üzenetére
"lehet, hogy PHP-ben pár karakterrel hosszabb a kód"
Már miért lenne hosszabb?
Pont azt mondtam, hogy így nyugodtan kihagyható az UPDATE esetén a kódból, hogy foglalkozz egyáltalán a dátum beállításával, vagyis PHP-oldalról nem kell lekérdezni az aktuális dátumot (pl. a date() függvény használatával), és ezt átadni az SQL-utasításnak - valamint SQL-ben sem kell mindig explicite odaírni a ´timestamp´=NOW() (ha ´timestamp´-nek nevezted el a mezőt) kódrészletet.
Magyarul így pont, hogy rövidül a kód (PHP-ben, SQL-ben sem foglalkozol a dátumbeállítgatással), ráadásul nem is felejted el beállítani a módosulást az időpontban, ha a default érték mindig az aktuális időpont.Sk8erPeter
-
#6591
Sk8erPeter
nagyúr
RedSign
#6590
Sk8erPeter
nagyúr
válasz
RedSign
#6590
üzenetére
Pont az imént volt szó róla.
>> [link]
kiegészítem, van még pl. a TIME() függvény is MySQL-ben, ami a konkrét időt szedi ki a time-ból vagy datetime-ból, a linken látható formában.
De itt találsz még rengeteg átalakító függvényt.
Érdemes már MySQL-ben átalakítva lekérdezni az eredményt, így annál kevesebbet kell majd átalakítgatni PHP-ból (persze úgy is lehet, de minek, ha megkaphatod nagyon gyorsan MySQL-ből is az eredményt formázva).Sk8erPeter
-
#6603
Sk8erPeter
nagyúr
Brown ügynök
#6602
Sk8erPeter
nagyúr
válasz
Brown ügynök
#6602
üzenetére
Nem ártana tudni, hogy egyáltalán hogyan nyered ki adatbázisból a dolgokat, a $row['id'] vajon létezhet-e, a lekérés eredményeként megkapod-e az id-t, asszociatív tömböt kapsz-e a lekérdezés során, egyáltalán konkrétan melyik sornál jelentkezik a hiba, biztos nem a $_GET['id']-val van-e baja (a $row['id']-ra dobja a hibát?!), ha a $_GET['id']-val, akkor valszeg nincs ilyen rész a lekért URL-ben, ha a $row['id']-val, akkor rossz a lekérdezésed, stb... Ezeket nem árt tisztázni, legalábbis szerintem így csak sötétben tapogatózás.
[ Szerkesztve ]
Sk8erPeter
-
#6607
Sk8erPeter
nagyúr
Brown ügynök
#6606
Sk8erPeter
nagyúr
válasz
Brown ügynök
#6606
üzenetére
Igazából most kb. ugyanazt írtad le, mint korábban...csak a lényegre nem válaszoltál.
A "másik kért url-nél" valszeg nincs beállítva a $_GET['id'], nem jó az átirányítás .htaccess-ből, vagy valami hasonló probléma van, mindenesetre ha a $_GET['id'] nem létezik, az 'id' indexen nyilván nem is fog elérni semmit a $_GET-ből, így kapsz egy notice-t.
Érdemes lenne inkább leellenőrizni minden esetben, hogy egyáltalán létezik-e a $_GET['id'] változó, be van-e állítva (isset), ezt átadni egy változónak, aminek minden esetben van valami ilyen default értéke - nem tudom, nálad hogy van megoldva, de lehetne egy alapértelmezett cikk, amire mutat, pl. cikk1, vagy cikk0, vagy csak simán cikk.
Példa:
$id = 0; // default érték, de úgy csináld meg, hogy stimmeljen, legyen alapértelmezett cím, amit ilyenkor megmutat
if( !empty($_GET['id']) ){ /// isset($_GET['id']) is lehetne, de így két legyet ütsz egy csapásra: ha nincs beállítva (!isset), ez az ág úgysem lesz igaz, ráadásul ellenőrzi, hogy nem üres-e; igazából ide még plusz ellenőrzéseket is illene betenni
$id = $_GET['id'];
}
if( $uri == ...........){
........
}
elseif ($uri == '/blog/cikk'.$id){
mutató_függvény($id);
}
.......Persze ez így nem igazán szép megoldás, hogy alapértelmezett cikk.$id útvonalat nyit meg, lehetne inkább pl. úgy megoldani, hogy amennyiben nincs beállítva a $_GET['id'] változó, akkor valami olyan oldalra irányít, ahonnan kiválaszthatja a felhasználó a kívánt cikket (esetleg hibaoldal, stb.).
Pl.
if( empty($_GET['id']) ){
mutatom_a_cikkeket_hogy_ott_valaszd_ki_fv( ); // ne legyen ekkora neve :D
}Így a korábbit csak azért írtam, hogy lásd, hogy a $_GET értékek meglétét MINDEN esetben ellenőrizni KELL, és annak megfelelően cselekedni, különben ha nincs beállítva (bármilyen probléma okán!), akkor NEM fog működni, legalábbis nem úgy, ahogy szeretnéd, és az ilyen lehetséges hibajelenségekre fel KELL készülni, hogy nagyjából minden hibalehetőséget kiszűrj. Ráadásul ellenőrzés nélkül közvetlenül átadni egy felhasználótól kapott adatot, a legrosszabb gyakorlat.
Remélem nem azt fogod most erre reagálni, hogy "de ez így akkor is működik, nem változtatok rajta".
Ha továbbra is fennáll a gond, akkor meg egy kicsit konkrétabb választ írj, ne ugyanazokat írd le másképp, amiket korábban.[ Szerkesztve ]
Sk8erPeter
-
#6617
Sk8erPeter
nagyúr
fordfairlane
#6608
Sk8erPeter
nagyúr
válasz
fordfairlane
#6608
üzenetére
"vagy kapcsolt ki a notice-ok kijelzését."
Azért remélem ez csak vicc akart lenni.(#6609) Brown ügynök: ez komoly? ennyit fogtál fel abból, amit írtam?
Úgy látszik, kár volt jártatnom a számat, mivel utána pont azért hálálkodtál, amiről én is beszéltem korábban, sebaj, ezek szerint semmit nem értettél meg abból, amiről vakerásztam.
[ Szerkesztve ]
Sk8erPeter
-
#6619
Sk8erPeter
nagyúr
fordfairlane
#6618
Sk8erPeter
nagyúr
válasz
fordfairlane
#6618
üzenetére
De az ilyen jellegű notice-okat az ember nem véletlenül kapja, az az egészséges, ha ilyenek nincsenek, főleg, ha egyszerűen megoldhatóak. Még hacsak notice-ról is van szó, nagyon sokszor vezetnek az ilyet okozó apróbb hibák is nagyobb problémákhoz hosszú távon (tapasztaltam).
Szerk.: nyilván élesben működő oldalon ne legyenek bekapcsolva a notice-ok, fejlesztésnél, debuggolásnál viszont szerintem mindenképp - hogy még akkor megoldd ezeket, amikor kell, vagyis amíg nem élesben próbálod ki.
[ Szerkesztve ]
Sk8erPeter
-
#6621
Sk8erPeter
nagyúr
fordfairlane
#6620
Sk8erPeter
nagyúr
válasz
fordfairlane
#6620
üzenetére
Nem csak az elméletről beszélek... pont hogy eléggé gyakorlatias dolog az, hogy leszarod a notice-okat, aztán majd nézel, hogy mégis mi a francért nem egészen úgy működik a kódod, ahogy elvárnád...
Sk8erPeter
-
#6625
Sk8erPeter
nagyúr
fordfairlane
#6623
Sk8erPeter
nagyúr
válasz
fordfairlane
#6623
üzenetére
"Jelen esetben pl. az isset hiánya nem okoz működési problémákat"
Csak rossz programozási gyakorlatot mutat be.
Pl. ha C-ben inicializálatlan változót próbálsz felhasználni, eléggé elszáll a progid (már ha a fordító nem jelez előre). (Ja, ez nem C, de szerintem azért vannak dolgok, amiket be kell tartani.)"a noticeok viszont sokszor akadályozzák, hogy haladj a munkában, vagy épp bemutass valamit a megrendelőnek stb."
Nem igazán értem, miért olyan nagy dolog kiiktatni a notice-okat. Eleve rossz a kód, ha ilyen előfordul benne, azt meg ki kell javítani. Legtöbbször ráadásul a notice-ok kiiktatása nem egy túl időigényes feladat, csak oda kell figyelni.(#6624) Tele von Zsinór:
"Igenis legyen E_ALL|E_STRICT, csak prod környezetben nem kiiratva, hanem logolva és fejlesztőnek automatikusan küldve."
Na ja, ez a legjobb megoldás, most már nekem is van egy hibakezelő osztályom, ami MINDEN hibát elkap, logol és elküld emailben nekem, hogy rögtön tudjak róla, és egyből tudjam javítani. Így a legjobb, nyilván a felhasználók 98%-a nem fogja jelezni a fejlesztőnek, hogy valami hibát tapasztalt az oldalon, screenshottal, hibajelenség leírásával kiegészítve, hanem egyszerűen másik menüpontra lép, vagy simán elhagyja az oldalt, mert elkezdi zavarni.
Az meg nem jó se a megrendelőnek, se a felhasználónak.Sk8erPeter
-
#6627
Sk8erPeter
nagyúr
fordfairlane
#6626
Sk8erPeter
nagyúr
válasz
fordfairlane
#6626
üzenetére
Nem kell megsértődni, ha nem ért veled egyet valaki.
Szakmai vitának van értelme.Sk8erPeter
-
#6637
Sk8erPeter
nagyúr
lesaux
#6636
Sk8erPeter
nagyúr
itt van egy ilyen:
"511 sorry, can't find a valid MX for sender domain (#5.1.1): You must provide a valid domain within the From address contained in the sender's mail envelope. The sender's domain is considered to be valid if the lookup for an MX record succeeds. If no valid MX record exists, then our email system will assume that no mail should be accepted for a domain that can not receive email."szóval mintha a küldő cím (From mező) nem lenne érvényes.
Amúgy javaslom a PHPMailer osztály használatát, nagyon kézenfekvő a használata, és kicsit használhatóbb, mint a sima mail() függvény.Sk8erPeter
-
#6642
Sk8erPeter
nagyúr
lesaux
#6639
Sk8erPeter
nagyúr
Nem, a PHPMailer nem "telepítős", hanem csak fel kell másolni tárhelyre a PHPMailer osztálynak a megfelelő fájlját (legyen pl. class.phpmailer.php
), az osztályt a megfelelő helyen include-olni, példányosítani, beállítgatni a különböző dolgokat (küldő, fogadó, tárgy, tartalom, stb., sokkal kézenfekvőbb, mint a sima mail() függvénnyel szarakodás) és használni, és ennyi. Itt van egy egyszerű példa.Furcsa, hogy a vipmail visszadobja. Most hirtelen annyit tudok mondani rá, hogy akkor ne arra küldd.
De hogy értelmesebben reagáljak, meg tudod mutatni, hogyan használod a mail() függvényt?[ Szerkesztve ]
Sk8erPeter
-
#6644
Sk8erPeter
nagyúr
lesaux
#6643
Sk8erPeter
nagyúr
Ha megmutatod, hogyan használod a mail függvényt (akár kicsillagozva is lehetnek persze az adatok), segítünk, hogyan ültesd át PHPMailerbe ugyanezt.
Igazából azért érdemes ilyen kicsit komplexebb levelezőrendszerbe átrakni (ott van még a SwiftMailer is, az is nagyon jó!), mert nagyon könnyű testreszabni, és a fejlesztői elég sok mindenre gondoltak, így megoldották az általánosan jellemző problémák nagy részét, amivel emiatt a levelezőosztályt felhasználóknak nem kell szenvedniük.Sk8erPeter
-
#6646
Sk8erPeter
nagyúr
lesaux
#6645
Sk8erPeter
nagyúr
Próbáld ki akkor a PHPMailerrel, töltsd le, majd másold a megfelelő helyre, amit majd beállítasz a $phpmailer_path változóban. Tehát ezt változtasd meg annak a helyére, ahova pakolod a fájlt!
Aztán másold be az alábbi függvényt annak a fájlnak az elejére, ahol a levélküldést szeretnéd csinálni (egy részt kikommenteztem benne, ami neked most valszeg nem kell, meg nálam definiálva van egy-két konstans egy konfigfájlban, de bennehagytam, hátha mégis szükség lesz SMTP-küldésre később). Függvénybe tettem, hogy ne kelljen mindenhol külön megírni:
/**
* send_email() - E-mail küldése (localhoston SMTP-vel)
* Kivétel: phpmailerException() levélküldési hiba esetén
* Exception(), ha nem létezik a fájl vagy nem elérhető
*
* @param string $to
* @param string $toName
* @param string $from
* @param string $fromName
* @param string $subject
* @param string $message
* @return none
*/
function send_email( $to, $toName, $from, $fromName, $subject, $message ) {
$phpmailer_path = $_SERVER['DOCUMENT_ROOT'].'/PHP/classes/class.phpmailer.php';
if(!file_exists($phpmailer_path)){
throw new Exception('Nem elérhető a PHPMailer osztály!');
}
//PHPMailer osztályt include-oljuk
require_once($phpmailer_path);
// példányosítjuk a PHPMailer osztályt, és jelezzük, hogy szeretnénk,
// ha kivételeket dobna (ne írja ki egyből a képernyőre a hibaüzeneteket)
$mail=new PHPMailer( true );
// karakterkészlet
$mail->CharSet = 'utf-8';
// feladó címe
$mail->From = $from;
// feladó neve
$mail->FromName = $fromName;
// címzett; címzett neve
$mail->AddAddress( $to, $toName );
// tárgy
$mail->Subject= $subject;
// levéltörzs
$basedir = $_SERVER['DOCUMENT_ROOT']; //pl. esetleges csatolandó képek miatt (így stimmel az elérési út)
$mail->MsgHTML($message, $basedir);
/*
//csak saját gépen küldjük SMTP-vel
if(IS_LOCALHOST){
$mail->Mailer = 'smtp';
$mail->SMTPAuth = 'true';
$mail->Host = SMTP_HOST;
$mail->Username = SMTP_USER;
$mail->Password = SMTP_PASS;
}
*/
// a levél elküldése
$mail->Send();
}Majd amikor magát a levélküldést szeretnéd végrehajtani, a sima mail() függvényed és a mostaniak HELYETT ezt tedd be:
$to = 'le****@vipmail.hu';
$toName = 'lesaux';
$from = 'nemtom@lepesfalvi.hu';
$fromName = 'Valaki János';
$subject = 'Új látogató érkezett';
$host = gethostbyaddr($_SERVER["REMOTE_ADDR"]);
$visitor_IP = $_SERVER['REMOTE_ADDR'];
$message = "Új vendég nyitotta meg az oldalt!\nIP-je: $visitor_IP\nHostja: $host";
// a levél elküldése
try { //kivétel, ha nem sikerült az elküldés...
send_email( $to, $toName, $from, $fromName, $subject, nl2br($message) );
} catch (Exception $e) {
echo ' Hiba a levélküldés során (log_errors()): '.$e->getMessage();
}Persze a hibaüzenetet nem muszáj echo-zni, ha naplózol, de azt már rádbízom.
Remélem így már működni fog! Ne felejtsd el a $phpmailer_path változót beállítani arra a helyre, ahova Te pakolod a class.phpmailer.php fájlt!
(Bár persze nem garancia az, hogy most a PHPMailer osztályt használod a klasszikus mail() függvény helyett, hogy most már elfogadja a leveledet a szerver, amire küldöd.
De legalább most már PHPMailer osztállyal küldesz levelet, amúgy is ajánlott inkább ilyen vagy ehhez hasonló levelezőosztállyal küldeni.)[ Szerkesztve ]
Sk8erPeter
-
#6652
Sk8erPeter
nagyúr
lesaux
#6651
Sk8erPeter
nagyúr
Fentebb van az e-mail-küldésre használható függvény, amit írtam neked.
Abban van az alábbi rész kikommentezve, ott szedd ki a kommentet (a /* nyitó és */ záró részt), majd az if(IS_LOCALHOST){ sort is, meg ennek a blokknak a záró kapcsos zárójelét ( } ), és hagyd bent az alábbi részt, úgy, hogy a megfelelő helyekre a saját adataidat írod (SMTP_HOST, SMTP_USER, SMTP_PASS konstansokat cseréld le a sajátodra):
//küldjük SMTP-vel
$mail->Mailer = 'smtp';
$mail->SMTPAuth = 'true';
$mail->Host = SMTP_HOST;
$mail->Username = SMTP_USER;
$mail->Password = SMTP_PASS;[ Szerkesztve ]
Sk8erPeter
-
#6659
Sk8erPeter
nagyúr
Alukard
#6658
Sk8erPeter
nagyúr
-
#6661
Sk8erPeter
nagyúr
lesaux
#6660
Sk8erPeter
nagyúr
Nincs mit. És végül melyik megoldást választottad?
PHPMailer vagy egyéb?Hogy érted, hogy nincsenek ékezetek? Krikszkrakszokat rak be helyette? A karakterkódolásnak stimmelnie kell, tehát a dokumentumnak, amiből küldöd, szintén UTF-8-nak kell lennie, ha a levelezőrendszert is arra állítottad. Vagy fordítva, a levelezőrendszert "hangold" a másik karakterkódolásra.
Sk8erPeter
-
#6669
Sk8erPeter
nagyúr
cucka
#6665
Sk8erPeter
nagyúr
Amúgy ez fura, azt nézem, hogy a PHPMailer osztályban (5.1) egyáltalán nincs is ellenőrzés arra vonatkozóan, hogy a felhasználó nem cseszte-e el a karakterkódolás bepötyögését, pl. egy karakterkódolás-beállító függvény formájában, ellenben rengeteg tagváltozó publikus, ami szerintem kicsit ellentmond a klasszikus OOP-elveknek (persze nem csak erről szól az OOP, de ha már lehet, egy helyen megvalósítjuk a változók beállításának megfelelő ellenőrzését is - egyből a beállításkor).
Ez már csak azért is szar, mert bármikor megcsinálhatnám, hogy tételezzük fel, úgy van példányosítva az osztály, hogy nem dobál kivételeket, de történik valami hiba, aztán én mondjuk ezt csinálom:
$mail->ErrorInfo = null;
vagy hasonlót - miért férek hozzá kívülről az ErrorInfo-hoz?
Nekem ez kicsit furcsa. Persze ennek semmi értelme, hogy én ezt csináljam, csak saját magamat szívatnám vele, de szerintem a lehetőség se legyen meg rá, hogy az ember ekkora baromságot csináljon, ha már OOP, és lehetne mondjuk protected (private nem lenne jó az esetleges leszármaztatás miatt).
Lehet, hogy a függvénybe ugrálásnak nagyobb az overheadje, de szerintem itt mondjuk nem számítana a különbség - így lehetne pl. egy setCharSet() metódus vagy valami hasonló, amiben elsőként ellenőrzi a függvény a kapott paramétert, hogy létezik-e egyáltalán olyan karakterkódolás, és amennyiben nem, akkor dobna egy kivételt (vagy beállítaná az ErrorInfo változót, és kiírná a hibát, ha úgy van beállítva (default)).(Egyébként gondolom Te is így példányosítod a PHPMailert:
$mail=new phpmailer( true );
hogy dobáljon kivételeket, nem?)[ Szerkesztve ]
Sk8erPeter
-
#6670
Sk8erPeter
nagyúr
Sk8erPeter
#6669
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6669
üzenetére
Ja igen, és a SetError() metódus protected, míg maga a tagváltozó ($ErrorInfo) nem, ez kissé egészségtelen koncepció szerintem.
A SetError helyesen protected, de magának a tagváltozónak is legfeljebb annak kéne lennie...Sk8erPeter
-
#6672
Sk8erPeter
nagyúr
cucka
#6671
Sk8erPeter
nagyúr
"Errorinfo protected (v. private) kéne legyen és kéne mellé írni egy getErrorInfo()-t."
És én szerinted mit mondtam? Ugyanezt.
"Vagy maradhat public, de akkor a __set-ben le kell kezelni azt az esetet, amikor kívülről piszkálják. (Egyébként simán elképzelhető, hogy le van kezelve, csak elkerülte a figyelmedet, nincs előttem a phpmailer forrása)"
Szerinted miért mondtam azt, amit mondtam? Mert néztem a forráskódot, és TUDOM, hogy nincs lekezelve... Azért nem kell eleve hülyének nézni az embert. Egyébként meg a "miért férek hozzá" költői kérdés volt...nyilván tudom, hogy ennek nem így kell lennie, pont erről magyaráztam, hogy szar a koncepció.
Az ErrorInfo-ra vonatkozó rész:
public $ErrorInfo = '';
Ennyi, ezt lehet beállítani a SetError() metódusban.
__set() mágikus függvényhasználat NINCS sehol (ezt sem kútfőből szedtem, hanem a forráskódot tanulmányozva jelentem ki...)
Van egy sima set() függvény, ami alatt van egy ilyen sor:
@todo Should this not be using __set() magic function?A karakterkódolási stringekről meg annyit, hogy ha már felsorolták szinte az összes MIME-típust is a _mime_types fv.-ben, akkor ez is belefért volna.
Persze ez nem számít igazán hibának."Igen, de az én kivételeim nem jelennek meg a képernyőn, hanem kapok róluk szépen formázott emailt (és ugyanez igaz a hibákra is)
"
Nálam is ugyanez a helyzet... Ez attól még nem mond ellent annak, hogy elegánsabb, ha kivételt dobál az osztály, és azt a megfelelő helyen elkapjuk, mintha kiszednénk a publikus ErrorInfo stringből a hibát, ha a Send false-szal tér vissza...Sk8erPeter
-
#6680
Sk8erPeter
nagyúr
cucka
#6679
Sk8erPeter
nagyúr
Ja persze, az nem is baj, hogy opcionális, azt speciel nem hibaként írtam (vagy nem úgy akartam).
Majd lehet, hogy megpróbálom jelezni a szerzők felé, hogy esetleg azt javíthatnák, hogy legyen egy getter metódusa a hibáknak, bár nem tudom, mennyire fogják figyelembe venni a véleményezést.Sk8erPeter
-
#6692
Sk8erPeter
nagyúr
fordfairlane
#6687
Sk8erPeter
nagyúr
válasz
fordfairlane
#6687
üzenetére
"Mindenesetre a notice problémát leggyorsabban static változódefinícióval lehet megoldani. Esetleg kikapcsolni a notice-ok kijelzését."
Ha tényleg ilyen megoldásokat alkalmazol, akkor látom keményen megtanultad az évek alatt, hogy hogyan lehet a legkörmönfontabban elnyomni a hibák kijelzését úgy, hogy lehetőleg ne zavarjon a fejlesztésben, ja és sűrűn használhatod ilyen alapon a @ (kukac) jelet is a hibák elnyomására, az biztos mindent megold!![;]](//cdn.rios.hu/dl/s/v1.gif)
Visszatérő téma...
Sk8erPeter
-
#6696
Sk8erPeter
nagyúr
Alukard
#6694
Sk8erPeter
nagyúr
válasz
Alukard
#6694
üzenetére
"megtanulom, hogy hogyan ne gányoljak kezdőként (annyira)"
Akkor első lépésként gyorsan felejtsd el azt a tanácsot, hogy kapcsold ki a notice-ok jelzését (fejlesztésnél NE kapcsold ki), és ahol nem nagyon-nagyon muszáj, ott ne használd a kukac jelet a hibaüzenetek elnyomására, hanem oldd meg másképp.Sk8erPeter
-
#6699
Sk8erPeter
nagyúr
Alukard
#6697
Sk8erPeter
nagyúr
válasz
Alukard
#6697
üzenetére
A korábban megmutatott függvényekkel nincs semmi baj, ha erre gondolsz, azok használati módjával van baj, ahogy cucka le is írta. Nyugodtan használd az ott szereplő függvényeket, csak jó sorrendben, jó helyen.
A saját kódok írogatásának előnye, hogy előbb-utóbb belédrögzül egy csomó minden, rengeteget lehet így tanulni - de persze sok buktató is van az elején. Plusz sok a gányolás. Azon a korszakon mindenki átesik. Mindkét módszernek van előnye, a másik előnyeit Tele von Zsinór előttem leírta.
Sk8erPeter
-
#6703
Sk8erPeter
nagyúr
D@ni88
#6701
Sk8erPeter
nagyúr
Kiegészítve Tele von Zsinór hozzászólását:
ha a form action attribútumánál a PHP_SELF-re szeretnél hivatkozni, akkor igazából tök felesleges kitölteni az action attribútumot, egyszerűen hagyd üresen, és kész. Ezzel a problémád meg is oldódott, és az oldalad kódja valid marad.
Megerősítésként lásd ezt is: [link]
Tehát ez működőképes:
<form action="" method="post">
<p><input type="submit" /></p>
</form>Sk8erPeter
-
#6715
Sk8erPeter
nagyúr
D@ni88
#6714
Sk8erPeter
nagyúr
Azzal van baja, hogy a $message változóhoz, ami akkor szerepelt először, hozzá akarod fűzni a $message változót, amiben még nyilvánvalóan nincs tartalom (a kiértékelés jobbról balra történik).
Valahogy így:
...
$message = "This is........" . $message . "\n\n";
A megoldás egész egyszerűen annyi, hogy azt a $message hozzáfűzést a 20. sorban szedd ki. A többi helyen maradhat.Ha csatolmányokat akarsz küldeni, javaslom, hogy használd erre a célra inkább a PHPMailert, SwiftMailert, stb...
Meg amúgy is... [ Szerkesztve ]
Sk8erPeter
-
#6730
Sk8erPeter
nagyúr
D@ni88
#6729
Sk8erPeter
nagyúr
[link]
"Essentially they are ZIP files that are full of XML files that when opened with the a proper application turn into a friendly word document."Kínál lehetséges .htaccess-es megoldást is a problémára.
AddType application/vnd.ms-word.document.macroEnabled.12 .docm
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.document docx
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx
AddType application/vnd.ms-powerpoint.template.macroEnabled.12 potm
AddType application/vnd.openxmlformats-officedocument.presentationml.template potx
AddType application/vnd.ms-powerpoint.addin.macroEnabled.12 ppam
AddType application/vnd.ms-powerpoint.slideshow.macroEnabled.12 ppsm
AddType application/vnd.openxmlformats-officedocument.presentationml.slideshow ppsx
AddType application/vnd.ms-powerpoint.presentation.macroEnabled.12 pptm
AddType application/vnd.openxmlformats-officedocument.presentationml.presentation pptx
AddType application/vnd.ms-excel.addin.macroEnabled.12 xlam
AddType application/vnd.ms-excel.sheet.binary.macroEnabled.12 xlsb
AddType application/vnd.ms-excel.sheet.macroEnabled.12 xlsm
AddType application/vnd.openxmlformats-officedocument.spreadsheetml.sheet xlsx
AddType application/vnd.ms-excel.template.macroEnabled.12 xltm
AddType application/vnd.openxmlformats-officedocument.spreadsheetml.template xltx[ Szerkesztve ]
Sk8erPeter
-
#6737
Sk8erPeter
nagyúr
Inv1sus
#6735
Sk8erPeter
nagyúr
válasz
Inv1sus
#6735
üzenetére
Adott oldal meghatározott tartalmának kiszedéséhez javaslom a DOMDocument osztály tanulmányozását. (többi, DOM-mal kapcsolatos osztály: [link])
Itt is elérhetők olyan függvények, mint JavaScriptben, hogy getElementById(), getElementsByTagName(), stb.
A dokumentációja php.net-en mondjuk elég gyenge, nekem elég sokat kellett tanulmányoznom a metódusok fejlécei fölött lévő kommentelt részeket, amik a dom.php-ben elérhetők voltak (pl. Komodo IDE-ben vagy phpDesignerben rámész, hogy ugorjon a metódus deklarációjára, és akkor beleugrik abba a fájlba, ahol ezek megtalálhatók).
Viszont nagyon hasznos, jól működik.Persze az input mezőből történő submitolást már JavaScripttel kéne elintézned.
[ Szerkesztve ]
Sk8erPeter
-
#6740
Sk8erPeter
nagyúr
Sk8erPeter
#6737
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6737
üzenetére
Itt korrigálnám magam:
"(pl. Komodo IDE-ben vagy phpDesignerben rámész, hogy ugorjon a metódus deklarációjára, és akkor beleugrik abba a fájlba, ahol ezek megtalálhatók)"
Rájöttem, hogy pl. a dom.php nevű fájl, ami tartalmazza az osztály- és metódusdeklarációkat, a Komodo IDE-n keresztül csak azért elérhető, mert az Eclipse a projektkönyvtárba legenerált egy .metadata nevű könyvtárat, amin belül a .plugins/org.eclipse.php.core/__language__/d112eb25/ könyvtár tartalmazza jópár PHP függvény, osztály, metódus, különböző nyelvi elemek deklarációját.
Elég furcsa nevű könyvtár, azt a generált azonosítót a végén hirtelen nem vágom, minek kell odapakolnia (mivel történhet esetleges ütközés vagy hasonló, ami szükségessé tenné).Ezt miért nem a /home/user könyvtárba generálja, vagy valami olyan helyre, ami bárhonnan elérhető (akár Windows-on belül is pl. Users\<user>\akármi\)? Mondjuk speciel ebben az esetben nem volt baj, mert a Komodo IDE kevesebb erőforrást zabál, mint az Eclipse, és ugyanez igaz a phpDesignerre is, így egy ideje ezeket használom az Eclipse és NetBeans helyett is, nem ártott, hogy ott van az a projektfájl.
De lehet, hogy csak valami tévedés következtében került bele pont a projektkönyvtárba, és nem valami ésszerűbb helyre, most nem nyomoztam utána.Ja, és amúgy ha a projektkönyvtárban nincs benne az említett fenti könyvtár (aminek mondjuk gondolom nyilván más neve is lehetne, a lényeg, hogy a projektkönyvtáron belül megtalálható legyen valahol), akkor a definícióra ugrás nem működik, helyette hibaüzenetet kapok Komodo IDE-ben:
"Cannot show definition: symbol is defined in the stdlib or in an API catalog. Would you like to open the online language help for this symbol?"
Ekkor a Yes-re kattintva csak a hivatalos php.net-es dokumentációt hozza elő, amiből hirtelen nehezebb kiigazodni, mint a metódusfejlécek fölötti kommentekből.[ Szerkesztve ]
Sk8erPeter
-
#6741
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Tudnátok linkelni JÓL BEVÁLT képkezelő osztályt? Tudjon arányos átméretezést és testreszabható vízjelezést (pl. kép melyik sarkába legyen pakolva vízjel, vagy hogyan is legyek egész pontos, lássa el logóval a képet), ezenfelül ne rontson a kép minőségén.
DE még jobb lenne, ha esetleg túl nagy méret esetén (azalatt NE) le tudna faragni a méretből mégis úgy, hogy kicsit butít a képen, hogy ne foglaljon el olyan rohadt nagy helyet (bár igaz, sok esetben az igazán nagy méretű képek jó nagy kiterjedésűek is, ha átméretezek, valószínűsíthetően a méret is jelentősen csökken - de nem mindig van így, mindegy, lényeg, hogy legyen valahogy megoldva).Lehet, hogy ez így egyszerre sok, nem tudom, én implementáltam ezekhez hasonló jellegű függvényeket (a 'butítós' módszert leszámítva) még jóval korábban, amikor azért a jelenlegihez képest is bőven voltak hiányosságaim (most is rengeteg van), és elég időigényes lenne újból, igényesen megírni, szépen osztályba szervezve, megfelelő hibakezeléssel (pl. dobjon kivételt).
Előre is köszönöm!
[ Szerkesztve ]
Sk8erPeter
-
#6743
Sk8erPeter
nagyúr
Frigo
#6742
Sk8erPeter
nagyúr
Hali!
Jaja, ez nagyon fasza LENNE, főleg a phMagick wrapper osztállyal, de sajnos a tárhelyen elég korlátozottak a lehetőségek, telepíteni nem lehet, és nyilván, maguktól ezt az osztályt nem telepítették...
Meg a phMagick-hez az exec() fv.-nek is engedélyezve kell lennie, mert ez elvileg rendszerhívásokat intéz.Tehát olyan megoldáshoz szeretnék folyamodni, amit nem kell telepíteni.
De azért köszi!Minden további ötletet szívesen várok!
Sk8erPeter
-
#6746
Sk8erPeter
nagyúr
Tele von Zsinór
#6744
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6744
üzenetére
Hali!
Köszi, ezt is mindenképp ki fogom próbálni!
De időközben keresgéltem, és rátaláltam az Asido-ra, amiről korábban soha nem hallottam, csak Google segítségével akadtam rá, de eddig nagyon tetszik, kézenfekvő a használata, de még ráadásul jól is működik (utóbbi már sajnos komolyan meglep, azok után, amennyi hibás képkezelő szkriptet próbáltam).
Direkt próbálgattam szélsőséges eseteket, hogy mondjuk kábé kétszer akkora képet választok vízjelnek, mint amekkora az eredeti kép, amire a vízjelet tenni szeretném, plusz átméretezem arányosan az eredeti képet, de akkor is jól működik, tehát fel van készítve az ilyen lehetséges hibákra. Ez eddig nagyon bejön, mert számtalan képmanipuláló osztályt próbálgattam már, de azoknál ez általában szarul volt megoldva. Belenézegettem a kódjába, elég összeszedettnek tűnik.
A hibakezelésnél mondjuk engem az zavar, hogy a trigger_error() függvényt használja, ami mondjuk jóval kevésbé kezelhető elegánsan, mintha mondjuk kivétel-kezeléssel lenne megoldva.
Ettől függetlenül eddig eléggé meggyőzőnek tűnik (persze nem teszteltem agyon, még csak pár példát néztem meg vele), plusz a honlapon lévő példakódokból is látszik, hogy elég sokféle esetre gondolt a készítője.
GD2, Magick Wand és Image Magick kezelésére is fel van készítve.Holnap a phpThumb-ot is kipróbálom.
Amúgy meglepő, mennyire befolyásolja az ember véleményét egy honlap: amikor megláttam ennek a phpThumb-nak a honlapját, hogy milyen ocsmány, valahogy nem jött meg a kedvem, hogy kipróbáljam.
Viszont van még egy ugyanilyen nevű, a PHP Thumb, aminek kifejezetten igényes a honlapja, ami valahogy eleve kíváncsivá teszi az embert, jól áttekinthető tutorialt mellékeltek hozzá, és a kódja szép és áttekinthető a doksi alapján.
Nálam jelenleg az volt a kizáró ok, amiért nem foglalkoztam vele, hogy asszem nem lehet vele vízjelezni, de egyébként nagyon tetszetős ez is.
Csak most sajnos nálam fontos szempont, hogy legyen megoldva a vízjelezés is, nem akarok szarakodni azzal, hogy ezt is meg kelljen írnom.Sk8erPeter
-
#6747
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
PDO-val kapcsolatos kérdésem lenne.
Van egy lekérdezésem, amiben az eredményeket növekvő vagy csökkenő sorrendben szeretném megjeleníteni, de úgy, hogy az 'ASC' vagy 'DESC' sztringet később szeretném belepasszírozni.
Valahogy az alábbi módon gondoltam, DE erre azt az eredményt adja, hogy rossz az SQL-szintaxis:$query_str = 'SELECT * FROM guestbook ORDER BY c_id :order ';
$order = (($this->ascending==true)?'ASC':'DESC');
$stmt = $this->dbh->prepare($query_str);
$stmt->bindValue(':order', $order, PDO::PARAM_STR);
$execution_result = $stmt->execute();Tehát mintha ebben az esetben ez az érték-hozzárendelés nem működne, csak akkor, amikor valamit egyenlővé teszek egy később megadott értékkel a lekérdezésben.
Lehet, hogy késő/korán van már, de most hirtelen nem jövök rá, hogyan is kellene ezt megoldani ehelyett, úgy, hogy ne kelljen a hagyományos csúnya sztringkonkatenálást alkalmazni.Köszi!
[ Szerkesztve ]
Sk8erPeter
Csak egy kis idő kellene hozzá. 
Amúgy is minek azt, csak megy vele az idő! 
De legalább most már PHPMailer osztállyal küldesz levelet, amúgy is ajánlott inkább ilyen vagy ehhez hasonló levelezőosztállyal küldeni.)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Új Lenovo Ideapad 5 Pro Bivaly Ultrabook -35% 14" RYZEN 5 6600HS 16/512 QHD+ 2,8K Radeon 2GB 90Hz
- Komplett épített pc eladó szükség esetén minden kiegészítővel
- Dell Precision 7530
- Yamaha MusicCast RX-A1070
- Prémium alkatrészek! RoG 3070 Ti Z590 11600K 1000 Watt Platinum Vízhűtés 32GB RAM 1TB NVME Garancia!
- Apple iPhone 14 Pro Max 128gb Black - Használt, függetlenen, akku 96%, Apple gari
- Akció! GIGABYTE AORUS 15P XC - 240Hz, i7 10870H, 16 GB RAM, RTX 3070 (130W, 8GB), 512 GB SSD
- Eredeti JBL Quantum One vezetékes gamer fejhallgató
- 9. Gen Gamer //i5-9400F//16GB DDR4//MSI GTX 1070 8GB GDDR5//256GB M.2 SSD//1TB HDD//550W PSU//
- Eredeti JBL Quantum 400 vezetékes gamer fejhallgató
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs