Új hozzászólás Aktív témák
-
DNReNTi
őstag
Egy kis kieg:
Fake SMTP-nek én a PaperCut-ot használom, korábban már linkeltem a topikban, amilyen egyszerű annyira király. Pontosan annyit tud amennyire az embernek szüksége van, alap esetben konfigurálni sem szükséges.Nem elég ha pl. a honlapom gyökérkönyvtárába kicsomagolom a githubról letöltött phpmailer.zipet, majd pl. az index.html oldalának a legtetejére behúzom az PHPMailer example fájlt php tagek közé, és ott szépen módosítgatom? Vagy erre mindenképp hozzak létre egy külön php fájlt?
Először is: amíg az index.html, az HTML és nem PHP - tehát index.php - addig teljesen okafogyott bármit belehúzni. Magyarul, most, hogy webszervert használsz és PHP-t tanulsz, itt az ideje elfelejteni a html kiterjesztést.
Másodszor: A PHPMailernek van saját autoloader-e.
Így használd:
require_once('/phpmailer_eleresi_utja/PHPMailerAutoload.php');
Ezt követően már használhatod az osztályt. Pl:
$mailer = new PHPMailer();
Így a $mailer egy PHPMailer objektum lesz (vagy ha úgy tetszik egy példány). Hogy ezzel a továbbiakban mit kezdj, abban segít a saját doksijabut without you, my life is incomplete, my days are absolutely gray
-
DNReNTi
őstag
XAMPP-ot sosem használtam, még csak nem is láttam, de ötletek:
Nem e felejtetted az index.php mellett az index.html-t? Apache konfigtól függően, lehet a html kiterjesztés az elsődleges. Készíts egy teljesen különálló php fájlt, pl : test.php, abba írd bele a helloworld példát. A print(); helyett használj echo();-t.
Tehát:
test.php:
<?php
echo 'Hello World!';
?>Ha ez sem jól működik, tuti a szerverrel nem oké valami. Így persze a böngészőben a fájlra hivatkozz, teszem azt: localhost/project/test.php.
but without you, my life is incomplete, my days are absolutely gray
-
#17128
Sk8erPeter
nagyúr
adam_
#17122
Sk8erPeter
nagyúr
"Ez alapján próbálkozom perpill.."
Ez nagyon durva.
És te ezt képes vagy hallgatni anélkül, hogy 1 perc után inkább le akarnád tépni a füledet? (én inkább azt választottam, hogy kilőttem a francba, egyébként még egy tákolmány is, amit összehoz)Látom a többi közben nagyjából megoldódott.
(#17127):
Ezt úgy illik, hogy a feldolgozás külön fájlban történik, nem ugyanott, ahol a megjelenítéshez tartozó dolgok."A form validálását is majd egybekötöm a submit button lenyomásával (ezt majd később JS-el megoldom)"
A validálást először SZERVEROLDALON írjuk meg, és csak UTÁNA kliensoldalon! A szerveroldali kódodban egy darab ellenőrzés sincsen, amíg ez nincs kész, addig tovább se lépj, először ezt oldd meg.A PHP-s hibák kijelzése be van állítva a php.ini-ben a fejlesztői gépen? Fejlesztés során mindig a legtöbb hibát kiíró hibabeállítás legyen meg, élesben kell csak elrejteni a hibákat, és azokat inkább naplózni.
Az alapján, amiket írtál, még azt sem tudhatjuk, hogy egyáltalán melyik kódsornál akadt el. Ezt tisztességes debuggolással illik kideríteni, de legalább akkor itt-ott kiíratásokkal derítsd már ki, melyik résznél van a probléma.Sk8erPeter
-
#17130
Sk8erPeter
nagyúr
adam_
#17129
Sk8erPeter
nagyúr
Na pont ez egy tökéletes példa arra, hogy miért is egy rakás szar még mindig a w3schools, ahhoz képest, hogy sokan azt hiszik, ez a webfejlesztők referenciáinak alfája és omegája, miközben tele van okádmány példakódokkal, rossz praktikákkal.
Egy külön szekciót szentel annak, hogy elmagyarázza, miért csinálja ezt:
<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
ahelyett, befejezné a szerencsétlenkedését, és ennyit írna:
<form method="post" action="">
üresen hagyva az action-attribútum értékét, ha már önmagára akarja irányítani a formot... Kész, probléma megoldva...
De még véletlenül sem hívja fel a figyelmet, hogy amúgy nem igazán üdvös megoldás nem szétválasztani a megjelenítéshez tartozó kódot a kapott adatok feldolgozásához tartozó kódtól...
Az input fieldeknél meg még véletlenül se használna labelt az accessibility és könnyebb kezelhetőség jegyében (pl. labelre kattintva ugorjon bele a mezőbe, ezt a böngészők támogatják, ha a label tartalmazza az általa felcímkézett elemet, vagy össze van kapcsolva egy for attribútum segítségével), nem használ placeholdert, mert ugyan miért is lenne HTML5, töketlenkedik azzal, hogy egyesével adogatja át a $_POST tömbben szereplő változókat az indexszel azonos nevű változóknak validálás után, ahelyett, hogy jóval általánosabb és szebb módon oldaná meg, és így tovább... nem értem, miért nem tudják az embereket spagettikód írása helyett végre valami jóra is tanítani.
Szóval látom, a w3fools.com-nak sajnos még mindig van relevanciája."Itt találtam egy pár funkciót ami a hibakijelzésekre vonatkozik, igazából vakvilágban tapogatódzom, segítenél, hogy pontosan mely fájlokat kell a php.ini-ben bekapcsolni ahhoz, hogy kijelezze a php-s hibákat is?"
Jó helyen tapogatózol, de itt nem "fájlokat" kapcsolsz be (ezt nem is tudtam értelmezni), hanem opciókat állítgatsz be (a php.ini egy konfigurációs fájl).Hibajelzésekre:
PHP 5.4.0 fölötti változatoknál:
error_reporting=E_ALL
display_errors=On
PHP 5.4.0-nál régebbi esetén:
error_reporting=E_ALL|E_STRICT
display_errors=On"Majd ezt követően a debuggolás történhet pl. etc. Firebuggal, konzolon keresztül? (Perpill ugye ott nem ír ki semmit sem)."
Húha, itt alapvető fogalmi tévedések vannak. A kliensoldalnak semmi köze a szerveroldalhoz, attól még, mert kommunikálnak, azok fejlesztése, debuggolása, lehetőségei is totálisan eltérnek. Bármilyen böngészőbeli webfejlesztő panelen csak akkor látnád ezeket a hibákat, ha JavaScripttel kiíratnád őket explicite valahogy a konzolra (ez már a gányolás kategória).
Ezért kell megtanulni rendesen debuggolni, de ez egyelőre sztem még nehézkes lenne neked, gondolom most kezded tanulni a PHP-t."Tehát pl. hozzak létre egy contatform.php és külön csak abba legyen a kontaktformhoz tartozó php kód?"
Egy olyan fájlról beszélek, aminek elküldöd az űrlap adatait (ezt a fájlnevet az action-attribútumban adod meg), és aminek a megjelenítéshez semmi köze, nincs benne az űrlap kiírásáért felelős kód, stb. Megkapod az adatokat, validálod őket, gondolva az esetleges csúnyabácsikra, kezdesz az adatokkal valamit (jelen esetben küldesz egy mailt), aztán visszairányítod az egészet abba a fájlba (header() segítségével), amiből kiindultál (vagy valahova átirányítod a júzert, ahol jelzed neki, hogy milyen ügyes volt, és sikeresen elküldte a cuccát). Itt a feldolgozó fájlban a különböző, másik oldalon kiírt adatokat el lehet tárolni $_SESSION-változókban, de ha ez egyelőre magas, akkor maradj az eredeti megoldásodnál, amikor önmagára irányítod az űrlap adatait (üres action-attribútummal).
Vagy ha valakinek van türelme elmagyarázni, akkor az remek. Most látom, így is qrva sokat írtam. [ Szerkesztve ]
Sk8erPeter
-
DNReNTi
őstag
Megpróbálom leegyszerűsíteni neked, amit Péter írt.
1. Különüljön el egymástól az űrlap (már ami megjelenik), és a fájl ami az onnan érkezett adatokat kezeli. MVC level egy. Konkrét példaként:
form_view.php - ebben a fájlban van amit a felhasználó lát, a HTML form.
form_controller.php - ebben a fájlban kezeled majd a felvitt adatokat.A form.php-d az alábbi módon fog adatokat küldeni a form_controller.php-nek:
<form method="post" action="form_controller.php"></form>2. MINDIG, de tényleg mindig, le KELL ellenőrizni a kapott adatokat. Hiába a HTML required attribútum, hiába a JS, ezek mind megkerülhetőek. A szerver oldal nem.
Példa: Az email küldő űrlapodon kötelező megadni nevet, e-mail címet, és persze az üzenetet. Az adatok meglétét (és megfelelőségét) a form_controller.php-ban le kell csekkolni, különben nem kívánt, nem várt hibákra léphetsz.3. Kijavítanám Brian-t a hibajelzésekkel kapcsolatban:
Helyesen: ini_set('display_errors', '1');"Vagy hol az a határ, "amit még jó ha tud" az ember PHP-s alapskillként, ha Frontendbe képzeli el a jövőjét? És mi az ami már általánosságban a Backendes kollégákra vár?"
Szerintem továbbra sem lehet ennyire szigorúan határt húzni a kettő közzé. Ez kéz a kézben van, nincs egyik a másik nélkül.but without you, my life is incomplete, my days are absolutely gray
-
#17134
fordfairlane
veterán
adam_
#17127
-
DNReNTi
őstag
Most lehet hülyeséget írok, és ki sem próbáltam, sőt ráadásul végig se mentem a kottán, de sztem az operátorod rossz, illetve az egyből szemet szúrt.
Mindenhol így szerepel:
$m - > akarmi...
Na de (szerintem) helyesen:
$m -> akarmi
Tehát nincs szóköz.A kis apróságra pedig:
$m -> Subject = 'A tárgy az lesz amit itt beállítasz';
Lehet az egy változó is, beírt szöveg is (mint ahogy én is beírtam), vagy konkatenálhatsz is statikus szöveget változóval. Pl:
$m -> Subject = 'Kapcsolatfelvétel: ' . $felado_neve;Szerk: typo
[ Szerkesztve ]
but without you, my life is incomplete, my days are absolutely gray
-
#17182
Sk8erPeter
nagyúr
adam_
#17175
Sk8erPeter
nagyúr
1. a $mail->ErrorInfo-ból bővebb hibaüzenetet is ki tudsz nyerni, pakold ezt az errors tömbödbe fejlesztés erejéig, az éles kódban pedig az ilyesmit illik inkább naplózni, és nem a felhasználó tudtára adni mindenféle "belső" hibaüzenetet (mert rosszindulatú emberke számára minden információ jól jöhet).
2. javaslom, hogy használd ki, hogy a PHPMailer (is) képes inkább kivétel eldobására hiba esetén, azt pedig szépen el tudod kapni egy phpmailerException formájában, sokkal szebb és áttekinthetőbb megoldást eredményez, el tudod vele kerülni a csúnya if-else blokkokat:
http://phpmailer.worxware.com/index.php?pg=exampleamail
https://github.com/Synchro/PHPMailer/blob/master/examples/exceptions.phps
Szerk.: egyébként itt az exceptionök engedélyezéséhez a kulcs csak annyi, hogy true paraméterrel inicializálod a PHPMailert:
//Create a new PHPMailer instance
//Passing true to the constructor enables the use of exceptions for error handling
$mail = new PHPMailer(true);[ Szerkesztve ]
Sk8erPeter
-
#17183
fordfairlane
veterán
adam_
#17181
fordfairlane
veterán
Hotmailnél amikor teszteltem 25ös porttal szintén nem ment.
Nem tudom, hogyan tesztelsz, de ha otthoni gépről, akkor sanszos, hogy a szolgáltatód nem engedi ki a 25-ös portra irányuló packeteket. Ez főleg a mailbotok ellen van.
Egyébként valamelyik héten, nem is olyan rég, felraktam egy XAMPP csomagot az itthoni gépemre, és teszteltem néhány dolgot. A kódban szerepelt a mail() függvény is, és lefutott, hibát, notice-t vagy warningot sem írt ki, de persze nem küldte el az emailt. Aztán valamelyik napra rá véletlenül, ahogy nézegettem a XAMPP könyvtárszerkezetét, hogy hova mit hova pakol, véletlenül megtaláltam ezeket az emaileket egy könyvtárban, textfájlok formájában. Ne kérdezd, hogy melyik verzió, és melyik könyvtár volt, mert már nem emlékszem, de az biztos, hogy default XAMPP telepítés volt, semmiféle email küldést nem állítgattam.
x gon' give it to ya
Tehát:
És te ezt képes vagy hallgatni anélkül, hogy 1 perc után inkább le akarnád tépni a füledet? 
De még véletlenül sem hívja fel a figyelmet, hogy amúgy nem igazán üdvös megoldás nem szétválasztani a megjelenítéshez tartozó kódot a kapott adatok feldolgozásához tartozó kódtól...
