Új hozzászólás Aktív témák
-
Brown ügynök
senior tag
Pár embert talán érdekel: megjelent a Symfony2 beta.
Különvélemény: A legjobb dolog amit beletehettek az a doctrine 2. Az egyedekkel való operálás, automatikus függvénygenerálás, a platformfüggetlen lekérdezések hihetetlen kényelmesek! A Twig sem rossz, valóban átláthatóbbá teszik a kódot. Személy szerint maradtam a PHP-nál mert először ezt szeretném minél jobban elsajátítani. Viszont akik designer-kel dolgoznak együtt azoknak hasznos lehet.A Form-okról nem beszélve. Annyi előre generált mezőt raktak bele, hogy még sok is.
-
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.
-
Alukard
senior tag
válasz
Sk8erPeter #6696 üzenetére
Nem kapcsoltam ki, ezért is idegesített, de nem az, hogy van, hanem az, hogy nem tudtam megoldani...
Kérdeztem, voltak segítőkészek és a probléma megoldódottViszont a baj a gányolós projektemmel az az, hogy gyakorlatilag a korábban megmutatott függvények tömegével van működtetve, és biztos vagyok benne, hogy nem a legjobb megoldást választottam...
Mennyi előnyöm származhatna abból, ha egy mások által megírt framework-öt szednék elő és annak a segítségével írnám meg?
-
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. -
Alukard
senior tag
válasz
fordfairlane #6687 üzenetére
Köszönöm a hozzászólásokat és a segítséget!
Áttanulmányozom és megtanulom, hogy hogyan ne gányoljak kezdőként (annyira)
Minden nap tanulok valami újat
-
fordfairlane
veterán
válasz
Sk8erPeter #6692 üzenetére
a és sűrűn használhatod ilyen alapon a @ (kukac) jelet is a hibák elnyomására,
Nem, a kukac jelet a kollegám szokta használni.
Egyébként ja, megtanultam. Az élet megtanít olyan dolgokra, amikre nem is gondoltál zöldfülűként.
Bár ezt a mondatot "Esetleg kikapcsolni a notice-ok kijelzését." már csak fricskának raktam be.
-
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!Visszatérő téma...
-
PazsitZ
addikt
válasz
fordfairlane #6687 üzenetére
Esetleg kikapcsolni a notice-ok kijelzését.
A problémát nem oldja meg, bár vannak elvetemültek, akiket megnyugtat, hogy lám volt hiba, nincs hiba. -
D@ni88
addikt
include_once('/includes/Swift-4.0.6/lib/swift_required.php');
$mail = Swift_Mailer::newInstance(Swift_SmtpTransport::newInstance());
$message = Swift_Message::newInstance()
->setFrom('sender@example.com')
->setTo('címzett5@gmail.com', 'Foo')
->setSubject('test message')
->setBody('<b>html</b> body.', 'text/html')
->addPart('plain body', 'text/plain');
//->attach($pdf_file_name, 'csatolt_file.pdf', 'application/pdf');
Swift_Mailer::newInstance(Swift_SmtpTransport::newInstance())
->send($message);Ezzel mi a gond? nem megy ki az email...
-
fordfairlane
veterán
A koncepció abban a tekintetben nem rossz, hogy elmozdulást jelent az egységbezárás irányába, bár nagyon kezdetleges formában. Én erre egy osztályt írnék, a connect/disconnectet pedig metódussal valósítanám meg, nem paraméterrel. De úgy is jó, ahogy te írod, főleg, ha a $connection-t használni akarja menet közben is a lekérdezéseknél.
Mindenesetre a notice problémát leggyorsabban static változódefinícióval lehet megoldani. Esetleg kikapcsolni a notice-ok kijelzését.
-
cucka
addikt
válasz
fordfairlane #6685 üzenetére
Igazából az egész koncepció rossz, mármint hogy egy függvény kezeli a connect-et és a disconnect-et is. Ha normálisan kéne megírni, akkor erre két függvény kell:
function db_connect($host, $user, $pass); - ez visszatér a connection resource-al
function db_disconnect($conn_res); - ez pedig lekapcsolódik -
fordfairlane
veterán
A függvény ha jól látom, azt csinálja, hogy kapcsolódik egy adatbázishoz, tehát a hozzászólásoddal ellentétben nem az a feladata, hogy kezelje egy korábbi $connection változót, hanem hogy létrehozzon egyet.
A függvény kezeli a kapcsolódást és a kapcsolódás zárását is, a probléma, hogy a kapcsolódás resource-t átmeneti változóban tárolja. Ezt vagy globálisan kell tárolni, vagy függvény local scope-ban, static változóként.
-
cucka
addikt
válasz
PazsitZ #6683 üzenetére
A függvény ha jól látom, azt csinálja, hogy kapcsolódik egy adatbázishoz, tehát a hozzászólásoddal ellentétben nem az a feladata, hogy kezelje egy korábbi $connection változót, hanem hogy létrehozzon egyet.
Ilyen esetben a jó megoldás, hogy a függvény visszatér a létrejött kapcsolat resource-ával, vagy false-al, ha nem sikerült neki. Vagyis parasztosan: a végére kell egy return $connection sor -
PazsitZ
addikt
Önmagában az is kevés.
Vagy globális változóként kellene használni a $connection-t vagy máshogy kezelni a dolgot.
Mivel egyik hívásnál ("conn") létrejön a kapcsolat, de a $connection változó a fgv lefuttatása után megszűnik.
Az újabb hívásnál ("kill") újra belépünk a fgv-be, de a $connection nem hogy nem egy resource, hanem definiálatlan változó. -
cucka
addikt
válasz
Alukard #6681 üzenetére
A kódod lényegében így néz ki:
if (valamilyen feltétel){
létrehozom a connection változót
} else {
használom a connection változót
}A notice-t az else ágban kapod, ahol szeretnéd használni azt a változót, amit az if egy másik ágában hoznál létre (de oda be se lép a programod, ugye, ezért a feltételes mód). A javaslat, hogy a mysql_connect-et hozd ki az if elé.
-
Alukard
senior tag
Kezdek kiakadni egy notice-on...
function connectSQL($dordie) {
$sql_user = " ";
$sql_pass = " ";
$sql_db = " ";
$sql_host = "localhost";
if ($dordie == "conn") {
$connection = mysql_connect("$sql_host","$sql_user","$sql_pass");
if (!$connection) {
echo "Nem sikerül csatlakozni az adatbázishoz.";
}
mysql_select_db($sql_db, $connection);
mysql_query("SET CHARACTER SET 'utf8'");
mysql_query("SET COLLATION_CONNECTION = 'utf8_general_ci'");
mysql_query("SET character_set_results = 'utf8'");
mysql_query("SET character_set_server = 'utf8'");
mysql_query("SET character_set_client = 'utf8'");
}
elseif ($dordie == "kill") {
mysql_close($connection);
}
else {
echo "connectSQL érvénytelen paraméter";
}
}A legfisebb XAMPP fut a gépemen php 5.3.5-el és ezt a hibát kapom :
Notice: Undefined variable: connection in C:\xampp\htdocs\core\db_connect.php on line 26
Warning: mysql_close() expects parameter 1 to be resource, null given in C:\xampp\htdocs\core\db_connect.php on line 26
a "kill" részben lévő $connectionnal van a baja, csak nem értem miért
-
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. -
cucka
addikt
válasz
Sk8erPeter #6672 üzenetére
És én szerinted mit mondtam? Ugyanezt.
Oké, figyelmetlen voltam, bocsánatMert néztem a forráskódot, és TUDOM, hogy nincs lekezelve...
Csak ötlet volt, írtam, hogy nem volt előttem a forráskód. Amúgy simán lehet, hogy egyszerűen csak szar a phpmailer forrása. Ingyenes szoftver, szóval nincs kinél reklamálni.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...
Attól függ, hogy mire használod egy adott projektben a kivételeket. Lehet vezérlési struktúraként is használni, meg lehet tényleg csak akkor elővenni őket, ha fatális módon elhányja magát a kód. Feltételezem, ezért opcionális a kivételek dobálása a phpmailer-nél. -
D@ni88
addikt
válasz
Tele von Zsinór #6677 üzenetére
közben rájöttem hogy az strstr is működik if-be. de azért köszi
-
Tele von Zsinór
őstag
-
D@ni88
addikt
válasz
Tele von Zsinór #6675 üzenetére
nem arra kellene hogy ott elvágja a sort, hanem egy olyan függvényre amely pl boolen-t ad vissza, vagy megszámolja hányszor van benne.
Az strstr() ha jól láttam akkor ott vágja le a stringet, ahol ez szerepel, tehát ez nem jó -
D@ni88
addikt
valaki tud olyan függvényt, amivel meg tudom határozni, hogy egy szó szerepel-e egy stringben?
-
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... -
cucka
addikt
válasz
Sk8erPeter #6669 üzenetére
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
Belefér, ez nem olyan nagy baj.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
Igen, meg lehet oldani, gondolom nem akarták felsorolni az összes lehetséges encoding típust és azok variációit (utf8 vs. utf-8). A karakterkódolás csak egy string, amit a levél header részébe illeszt a phpmailer, ezért nincs ellenőrzés.miért férek hozzá kívülről az ErrorInfo-hoz?
Errorinfo protected (v. private) kéne legyen és kéne mellé írni egy getErrorInfo()-t. 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)Lehet, hogy a függvénybe ugrálásnak nagyobb az overheadje
Igen, de annyira azért nem nagy. (Az overhead-et az adja, hogy létre kell jöjjön a call stack, ami a függvény hívása után fel kell szabaduljon)Egyébként gondolom Te is így példányosítod a PHPMailert:
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) -
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
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?) -
lesaux
veterán
válasz
Sk8erPeter #6661 üzenetére
A PHPMailernek adtam meg az adatokat, így volt a legegyszerűbb. Az ékezetes betűket egyszerűen kihagyja. Az összes oldal iso-8859-2 kódolású. Mindjárt utánanézek.
Szerk.: nem is volt nehéz:
$mail->charSet = "iso-8859-2"; -
cucka
addikt
válasz
Alukard #6662 üzenetére
a lényeg, hogy egy olyan megoldást keresek aminek a segítségével adatbázisból ki lehet szedni és megjeleníteni egy többszintes menüt, úgy, hogy minden a helyén is van...
Miért nem írod meg magadnak? Gyakorlatilag egy fát kell felépíts, majd írni egy függvényt, ami rekurzívan végigszalad rajta, ez fogja kiírni a menüt. Persze, ha gyorsan kell és nem szeretnél php programozással foglalkozni, akkor felejtős, egyébként viszont megéri egyszer jól megcsinálni, ez pont egy olyan feladat, amire lehet újrafelhasználható kódot írni és mellette viszonylag érdekes is.
-
Alukard
senior tag
válasz
Sk8erPeter #6659 üzenetére
Köszönöm, 90%-át ismertem, viszont sajnos nem voltam elég pontos...
A menühöz a linkek (név, url, sorrend) adatbázisban vannak tárolva, szóval a lehetőségek eléggé korlátozottak... a lényeg, hogy egy olyan megoldást keresek aminek a segítségével adatbázisból ki lehet szedni és megjeleníteni egy többszintes menüt, úgy, hogy minden a helyén is van... -
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.
-
lesaux
veterán
El sem hiszem! Megkaptam a cirkusz utáni első levelemet PHP fájlból. Nem állítanám, hogy szopásmentes volt az ügymenet, amíg megkértem az SMTP szervert, hogy a 2225-ös porton küldje, vagy amíg rájöttem, hogy aposztrófok közé kell rakni a bejelentkezési nevet és a jelszót, de megvan végre. Már csak a kódolással kell valamit kezdeni, ugyanis nincsenek ékezetek, de arra nem hajnali negyed kettőkor fogok ráguglizni.
Mindenkinek, aki ilyen sokat foglalkozott a problémámmal, nagyon köszönöm! -
Sk8erPeter
nagyúr
válasz
Alukard #6658 üzenetére
Pl. ezek közül válogass.
De ez nem PHP-kérdés. -
Alukard
senior tag
Üdv Megint
Esetleg nem tud valaki egyszerű megoldást egy 2-3 szintes menü létrehozására?
Fő kat
>Alkat
>Alkat
>>AlAlkat
>>AlAlkat
>Alkat
Főkat
Főkat -
biker
nagyúr
azt nem tudom, akkor azon a serveren épp mit csináltak, a rendszergazda volt figyelmetlen, vagy mi, de jó 5 percig az index.php teljes forrása jött le, amig újra nem sikerült indítani az apacheot.
menet közben leállt a php modul, és futott tovább az apache. ezt ugye buffer underrunnal nem igazán lehet elérni, de elvileg lehetséges.
azt hiszem ultraweben volt. -
cucka
addikt
A php modult úgy lehet kiütni, ha szerkesztik az apache httpd.conf-ját, amihez általában root jog szükséges. Namost ha a hekker képes root joggal szerkesztgetni a szerveren a file-okat, akkor gyakorlatilag bármit megcsinálhat a gépen, tehát megette a fene az egészet.
Persze, ha tudsz valamilyen exploit-ról, amivel ezt el lehet érni root shell nélkül, akkor arra nagyon kíváncsi vagyok.
-
biker
nagyúr
A php file-t kívülről nem lehet elérni, mert a webszerver tudja, hogy az egy php file, így nem a php programkódot fogja visszaadni a felhasználónak, hanem lefuttatja php-val, és amit az kiír a standard kimenetre, na az megy a júzernek.
kivéve ha ügyesen kiütik a serveren a php modult, és azonnal kiprinteli a server a teljes forráskódot
láttam már ilyet.
-
cucka
addikt
De nem gáz ez, hogy ott van kódolatlanul?
Igen, gáz, ugyanakkor nem azA php file-t kívülről nem lehet elérni, mert a webszerver tudja, hogy az egy php file, így nem a php programkódot fogja visszaadni a felhasználónak, hanem lefuttatja php-val, és amit az kiír a standard kimenetre, na az megy a júzernek. Tehát nem gáz, hogy ott van kódolatlanul, valószínűleg egy másik file-ban az adatbázis jelszavad is ott lesz kódolatlanul
Annyiban gáz, hogy ha valaki hozzáfér a honlaphoz tartozó file-okhoz (pl. valahogy megszerzi az ftp jelszavadat), akkor látni fogja a jelszót is, bár ez esetben úgyis megette a fene az egészet, tehát szerintem ezen ne parázz
-
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; -
cucka
addikt
Az mx rekord a lanten.hu-hoz létezik, ezt sok helyen meg tudod nézni, pl. [link]
Phpmailer-el pedig tudsz küldeni simán (php mail-el) és smtp-vel is levelet. Az smtp-s levélküldésnél pontosan ugyanúgy be fog lépni az smtp szerverre a phpmailer, mint ahogy egy átlag levelezőprogram belép, amikor küldesz vele valamit. Ha megnézed a phpmailer kódját, a "PROPERTIES FOR SMTP "-re keress rá, ott lesz szépen dokumentálva az összes paraméter, amit az smtp-s levélküldéshez be lehet állítani. (Nem mindegyiket kell piszkálni, de nyilván hostnév vagy belépési adatok nélkül nem fog semmit küldeni sehova
)
-
lesaux
veterán
válasz
Sk8erPeter #6648 üzenetére
Írtam. Válaszoltak is:
Egyeztettem technikai kollégámmal és a tartós megoldást az jelentené, ha SMTP-vel küldené ki a leveleket. Ehhez az szükséges, hogy létrehoznak egy e-mail címet jelszóval, és azon keresztül küldik ki a leveleket.
Feladó nincsen megadva küldéskor, ezért nem tudja azonosítani a fogadó szerver és visszautasítja a levelet, ezért kapja a lenti hibaüzenetet.
Jól értem, ugye, hogy ez nem az, ami nekem kell? E-mailt tudok küldeni a t-online-os vagy a vipmailes címemről, de itt az kéne, hogy a szerver küldjön, ha megnyílik egy oldal vagy beleírnak a wendégkönyvbe.
A class.smtp.php fájl esetleg nem kínál erre megoldást? -
lesaux
veterán
válasz
Sk8erPeter #6646 üzenetére
Nos. Először is köszi a hosszú poszot.
Azt jól értelmezem, hogy a szerverre csak a class.phpmailer.php, class.pop3.php és a class.smtp.php fájlt kell feltölteni, ugye? Meg persze a $phpmailer_path-ban beállítani az útvonalat.
----
Jó, semmi, tárgytalan. Amíg ezeket gépeltem, meg is jött vagy öt levél a mailer daemontól, ugyanazzal a hibaüzenettel, hogy a kurva indamail visszadobta. Holnap írok a Gyümölcstárhelynek meg az Indamailnek.
Most még azon gondolkodom, hogy május 22-én jár le a domainregisztrációm, de eredetileg ápr. 22. lett volna, csak egy hónapot ajándékba kaptam. Na, én az MX rekordok lelkivilágához nem értek, de ha a domainemet meghosszabbították, ezt az MX-es cuccot pedig nem, és emiatt kerültem ki a pixisből, akkor goromba leszek.
Köszi mindenkinek az infókat meg a komplett PHP-forráskódot. -
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.)
-
lesaux
veterán
válasz
Sk8erPeter #6644 üzenetére
Ez szerepel a php fájlban:
[I]<?
$host = gethostbyaddr($_SERVER["REMOTE_ADDR"]);
$visitor_IP = $_SERVER['REMOTE_ADDR'];
$emailszoveg = "Új vendég nyitotta meg az oldalt!\nIP-je: $visitor_IP\nHostja: $host";
mail("le****(a)vipmail.hu", "Új látogató érkezett", "$emailszoveg", "From: www(a)lepesfalvi.hu");
?>[/I]De a from mezőben járt már minden. Köszi!
-
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.
-
lesaux
veterán
Köszönöm, amit írtatok. Nem mondom, hogy penge vagyok PHPMailerből, de lehet, hogy megpróbálom. Bár jobban örülnék, ha úgy működne az e-mail küldés, mint eddig.
Csak otthonról tudom majd bemásolni a forráskódot, addig türelmeteket kérem. -
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? -
lesaux
veterán
Köszönöm mindkét választ.
A PHPMailerhez nem értek, de ha jól látom, ez telepítős dolog, az nekem nem fog menni, én csak a tárhelyért meg a domainért fizetek.
A cucc a Gyümölcstárhelyen van, ami korábban Lanten volt, ez látszik a szerverneveken.
A le****(a)vipmail.hu-ra küldeném a levelet. (Az indamail meg a vipmail ugyanaz a cég. A domain a lepesfalvi.hu.)Bemásolom, hogy néz ki a visszapattanó e-mail:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
le****(a)vipmail.hu
SMTP error from remote mail server after MAIL FROM:<lepes***(a)gyimothy.lanten.hu>
SIZE=1603:
host mail29.indamail.hu [91.83.45.29]: 550 5.1.0 <lepes***(a)gyimothy.lanten.hu>
sender rejected. can't find a valid MX for sender domain / Sajnaljuk! Nem
beazonosithato valodi MX a kuldo domain-hez!
------ This is a copy of the message, including all the headers. ------
Return-path: <lepes***(a)gyimothy.lanten.hu>
Received: from lepes*** by gyimothy.lanten.hu with local (Exim 4.69)
(envelope-from <lepes***(a)gyimothy.lanten.hu>)
id 1QCRre-0002pa-EF
for le****(a)vipmail.hu; Wed, 20 Apr 2011 09:30:18 +0200
To: le****(a)vipmail.hu
Subject: Új bejegyzés a vendégkönyvbe
X-PHP-Script: lepesfalvi.hu/******.php for 78.92.118.198
From: admin(a)lepesfalvi.hu
Message-Id: <E1QCRre-0002pa-EF(a)gyimothy.lanten.hu>
Date: Wed, 20 Apr 2011 09:30:18 +0200
Új vendég írt a vendégkönyvbe!A PHP-ben hiába állítottam be az admin(a)lepesfalvi.hu címet a from mezőben, a fenti sorokból látszik, hogy a Lantentől érkezőnek tűnik a levél. (Lantenes címet is megadtam a from fieldben, az se ment el.)
Egyszerűen már nem tudom, mi a francot csináljak. Eddig évekig működött, két napja pedig hirtelen vége szakadt a levéláradatnak. (Ami érdekes, hogy ha nem a vipmailes címemre küldöm, hanem a t-online-osra, akkor egy pillanat alatt megérkezik. Ezek szerint a vipmail szigorúbb, mint a T csoport.) -
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. -
lesaux
veterán
Sziasztok!
Van nekem egy weboldalam, ami php mail függvénnyel e-mailt küld, ha megnyitjuk, illetve a vendégkönyvben is hasonló módon tud üzenni a látogató.
Egy ideje azonban az indamail visszapattintja a leveleket azzal a szöveggel, hogy can't find a valid MX for sender domain / Sajnaljuk! Nem beazonosithato valodi MX a kuldo domain-hez!Túrtam a netet, és a következőt találtam egy fórumon:
1. bejegyzed a nnn(.com,org, stb) domain-t, és beállítasz egy valós MX rekordot.
vagy
2. megváltoztatod a postfix álltal használt hostnevet egy valósra.Na most ezeket nem én kezelem, hanem a gyümölcstárhelyen van a weboldalam, de amúgy sem értem, mi a teendő. Hogy lehetne működésre bírni?
-
cucka
addikt
Valakinek esetleg van ötlete, hogy Budapesten egy multinál mennyit keres egy senior php fejlesztő?
-
D@ni88
addikt
válasz
Tele von Zsinór #6632 üzenetére
a generált query az sztem okés
Select * from adatbazis where tulajdonsag LIKE '%,2,%' OR tulajdonsag LIKE '%,3,%' OR tulajdonsag LIKE '%,4,%'
A fő ok igazából az lenne, hogy a lap első betöltésekor is lemegy az if(isset($_POST["lista"]))
feltételbe adott folyamat, így létrejön egy a lekérdezés önmagában ennyi lesz:Select * from adatbazis where
Pedig közöm nem volt még a submit gombhoz...
-
D@ni88
addikt
van egy multi selectem amiben ugye több paraméter is választható.
<?php
if (isset($_POST["lista"]))
{
$lek="Select * from adatbazis where ";
$temp=$_POST["lista"];
$i=1;
foreach ($temp as $ertek)
{
if($i!='1')
{
$lek.=" AND ";
}
$i++;
$lek.= " tulajdonsag LIKE '%,".$ertek.",%'";
}
}
$res=mysql_query($lek) or die ("Adatbázis hiba");
?>Szval olyan amint elküldi, lenyomja a user a submit gombot, akkor utána keressen adatbázisba.
a lista értékei így mentődnek le adatbázisba ,1,2,3,4,5,6,
Ugye a két számjegyes keveredés miatt.
De valamiért adatbázis hibát dob alapból. Valakinek ötlet?
Jah és a legjobb, le se kell nyomnom a submitot, egyből jelzi hogy adatbázis hiba, szval el sincs küldve -
PazsitZ
addikt
válasz
fordfairlane #6628 üzenetére
Elfogadom, hogy te nem így teszel, de:
Szerintem, notice-okat lekezelni sok esetben szükséges is, logikai és optimális hibakezelés, user felé történő interakció miatt.
Más esetben meg majd gyönyörű rejtett bugokat hozhat elő.Továbbá kétlem, hogy értékes időt nyersz egy-egy vizsgálat kihagyásával. Minimálisan igényel pluszt és könnyen elsajátítható, a normális kód írása, még ha sietsz is.
Egy változó inicializálás, isset, empty, egyéb vizsgálat nem igényel sem agyi kapacitást, sem túl sok gépelést.Én személy szerint utálom, ha megkapok egy oldalt és bekapcsolva a hibajelzést kilométeres üzenetek figyelnek.
Elhiszem, hogy 10 éve sikeresen programozol, de attól még nem lesz good practice -
fordfairlane
veterán
válasz
Sk8erPeter #6627 üzenetére
Félreértés ne essék, nem sértődtem meg, csak nincs kedvem vitatkozni ebben a témában. 10 éve programozok különféle weboldalakat PHP-ban, a saját bőrömön tapasztaltam meg, mik tudnak hirtelen prioritássá előlépni... Én is törekszem azokra, amiket leírtatok, de tudom nagyon jól, hogy a rögvalóság sokszor felülírja a dolgokat. Nem bátorítok senkit ilyenekre, csak mint lehetőséget említettem.
-
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.
-
fordfairlane
veterán
válasz
Tele von Zsinór #6624 üzenetére
Részemről lezártam a témát, mindenki annyit, és olyan mélyen notiszol, amennyire neki jólesik.
-
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. -
Tele von Zsinór
őstag
válasz
fordfairlane #6623 üzenetére
A notice az egyetlen dolog, ami jelzi: elgépeltél egy változónevet, tömbindexet, stb. Igenis legyen E_ALL|E_STRICT, csak prod környezetben nem kiiratva, hanem logolva és fejlesztőnek automatikusan küldve.
Inkább írok issetet n+1 alkalommal, mint egyszer kelljen keresnem egy ilyen elgépelést.
-
fordfairlane
veterán
válasz
Sk8erPeter #6621 üzenetére
Nem azt írtam, hogy ne foglalkozzon a notice-okkal, hanem ha zavarja őket, akkor kikapcsolhatja. Jelen esetben pl. az isset hiánya nem okoz működési problémákat, a noticeok viszont sokszor akadályozzák, hogy haladj a munkában, vagy épp bemutass valamit a megrendelőnek stb. Nem tartom olyan vészesnek, ha valaki, pláne a kockázatok ismeretében, kiiktatja őket.
-
Brown ügynök
senior tag
válasz
Sk8erPeter #6617 üzenetére
Szerk.: nyilván élesben működő oldalon ne legyenek bekapcsolva a notice-ok,
Én így értelmeztem fordfairlane tanácsát.
A tanácsaidhoz: Bocs, hogy nem ellenőriztem le a $_GET['id'] ahogy csak lehet, (Éppen ezért kértem segítséget). de amit mondtál abból nekem nem jött le a megoldás.
Fordfairlane elmondta, hogy kellene, most már tudom. Részemről lezárva.
-
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...
-
fordfairlane
veterán
válasz
Sk8erPeter #6619 üzenetére
Ismerem az elméletet, de próbálok gyakorlatias lenni. Az elmélethez való ragaszkodásból nem lehet megélni.
-
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.
-
fordfairlane
veterán
válasz
Sk8erPeter #6617 üzenetére
Azért remélem ez csak vicc akart lenni.
Egyáltalán nem viccnek szántam. Ha szorít az idő, és működik a program, miért gond, ha nem a képernyőre kerülnek is a sokadlagos jelentőségű figyelmeztetések?
-
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. -
Brown ügynök
senior tag
válasz
fordfairlane #6615 üzenetére
Erre volt szükségem.
Rendkívül hálás vagyok.
-
fordfairlane
veterán
válasz
Brown ügynök #6614 üzenetére
Isset-tel ez nem működne.
Ilyenre gondoltam:
elseif (isset($_GET["id"]) and $uri == '/blog/cikk'.$_GET["id"]) ...
-
Brown ügynök
senior tag
válasz
fordfairlane #6613 üzenetére
Na igen, de jelenleg nincs ennél jobb módszerem. Ha kicsit visszaolvasol, láthatod miért. Másképp nem tudok egy konkrét cikkre hivatkozni, csak ha hozzáfésülöm (.$_GET['id']-t) az url-hez. Isset-tel ez nem működne.
-
fordfairlane
veterán
válasz
Brown ügynök #6612 üzenetére
Ok, számomra sem volt 100%, hogy ez a probléma, örülök, hogy működik. Egyébként a notice-ok kikapcsolása inkább kerülőmódszer, jobb, ha bekapcsolva marad.
-
Brown ügynök
senior tag
válasz
fordfairlane #6610 üzenetére
Bocs, félreértettél, jó amit mondtál, köszönöm. Értelmezd úgy, hogy valóban lelkesedtem.
-
fordfairlane
veterán
válasz
Brown ügynök #6609 üzenetére
dupla
-
fordfairlane
veterán
válasz
Brown ügynök #6609 üzenetére
Akkor próbáld ki az isset használatát.
if(isset($_GET['id']) and .......)
A feltételvizsgálat balról jobbra értékelődik ki, ezért ha az első false, akkor tovább nem megy az értelmező. Ha a noticeok be vannak kapcsolva, akkor mielőtt valami nem egyértelműen deklarált változót használnál, pl. bejövő paramétert, mint get vagy post paraméter, vizsgálni kell a "létezését".
-
Brown ügynök
senior tag
válasz
fordfairlane #6608 üzenetére
kapcsolt ki a notice-ok kijelzését.
Jajj ne, ezt túl egyszerű.
Persze javasolták már ezt nekem, nem is tudom miért próbáltam másképp megoldani. Jól értetted, az id csak egy url-nél játszik.
@SK8erPeter: A beérkezett uri-kat vizsgálom, amelyik nem létezik megy a levesbe->404.
-
fordfairlane
veterán
válasz
Brown ügynök #6606 üzenetére
Jól értem, nem az a gond, hogy $_GET['id'] nincs minden egyes index.php meghíváskor? Mert akkor vagy rakj be egy isset($_GET['id']) feltételvizsgálatot a használata előtt, vagy kapcsolt ki a notice-ok kijelzését.
-
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. -
Brown ügynök
senior tag
.htacces: RewriteRule ^cikk(.*)$ index.php/.../file.php?id=$1 [L]
Hivatkozás: <a href="cikk'.$row['id'].'">
Útvonal:
elseif ($uri == '/blog/cikk'.$_GET["id"])
{ mutató_függvény($_GET['id']); }Mint mondtam, ez így működik. A gond azzal van, hogy másik kért url-nél, amelyben átadok paramétereket, szintén kéri az id-t. Lásd feljebb.
-
cucka
addikt
válasz
Brown ügynök #6604 üzenetére
Mi a kérdéses oldal címe (vagyis az url-je) és mi található a $uri változóban?
A $_GET['id']-ben csak akkor fogod megtalálni a keresett értéket, ha az url-ben van egy id nevű paraméter. (pl. oldalneve.hu?id=1 ) -
Brown ügynök
senior tag
válasz
Sk8erPeter #6603 üzenetére
Mysqli lekérdezéseket használok. A GET['id'] ennél az uri-nál átadódik:
elseif ($uri == '/blog/cikk'.$_GET["id"]) {
mutató_függvény($_GET['id']);
}Csakis ennél az uri-nál alkalmazom a házzfűzési módszert, minden más esetben isset-t használok. Itt azért kell ezt a módszert használnom, mert az egyes cikkeket id alapján kérem le az adatbázisból és az útvonalnál csak így lehet átadni az id-t. Ha van a hivatkozásra más módszer, akkor azt szívesen meghallgatom.
Ha egy másik útvonalnál is adok át változót, akkor azt írja ki, hogy ismeretlen index: id.
Példa egy másik útvonalra:
elseif ($uri == '/blog/upload' && isset($_POST['cim']) && ...) {
beillesztő_függvény(($_POST['cim']),...);
} -
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.
-
Brown ügynök
senior tag
Hátha valaki tudja: Miért hiányolja az oldal minden egyes adatbázissal kapcsolatos útvonalnál az id-t?
Az index.php-ban vannak az "útvonalak" amelyek alapján érhetőek el a tartalmak.
Hivatkozás: <a href="cikk'.$row['id'].'">
Útvonal:
elseif ($uri == '/blog/cikk'.$_GET["id"]) {
mutató_függvény($_GET['id']);
}Példa egy másik útvonalra:
elseif ($uri == '/blog/upload' && isset($_POST['cim']) && ...) {
beillesztő_függvény(($_POST['cim']),...);
}Tehát, bármely olyan útvonalnál, ahol adatbázissal kapcsolatos tevékenység van, hiányolja az id-t. (Undefined index id in index.php). Na most, az id-t csak egy útvonalnál használom - ugyanis az adott cikket csak így tudom megjeleníteni . Valakinek valami ötlet?
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy Z Fold6 / 256 GB / 12 GB RAM / 1év Garanciával / Gyári Független
- Samsung Galaxy Z Fold5 / 512 GB / 12 GB RAM / 1év Garanciával / Gyári Független
- Samsung Galaxy Z Flip6 / 256 GB / 12 GB RAM / 1év Garanciával / Gyári Független
- Apple iPhone 14 Pro Max / 256 GB / 88% akkumulátor / 1év Garanciával / Gyári Független
- Apple iPhone 15 Pro / 128 GB / 100% Akkumulátor / 1év Garanciával / Gyári Független
- AKCIÓ! Gigabyte A620M R5 7600 32GB DDR5 1TB SSD RX 6800 16GB Cooler Master CMP 510 Seasonic850W
- Bomba ár! Dell Latitude 5290 - i5-8GEN I 8GB I 256SSD I 12,5" HD I Cam I W11 I Garancia!
- Új ASROCK A520M PG Fèlkonfig - Ne hagyd ki! 0% THM-RE is!
- Gombászkönyvek egyben
- Telefon felvásárlás!! Xiaomi Redmi 9, Xiaomi Redmi 9AT, Xiaomi Redmi 10, Xiaomi Redmi 10 2022
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest