ugrás a tartalomhoz

Módszerek email küldésre

iddqd · 2013. Dec. 21. (Szo), 15.08
Sziasztok,

Tudnátok segíteni, milyen megoldásokkal érdemes az email küldést megoldani php alól? Foglalás/kapcsolatfelvétel rendszer jelleggel. Egyenlőre alacsony forgalommal, de ha ez később változik viszonylag rugalmasan lehessen hozzá alkalmazkodni.
Köszi
‹ Melyik függvények kellenek adatbázisba mentéskor és kiíratáskor? Codeigniterrel 2014 elején? ›
 ■
1

Ez így túl általános. Ha

Hidvégi Gábor · 2013. Dec. 21. (Szo), 15.31
Ez így túl általános. Ha foglalás esetén visszajelzést szeretnél küldeni, ahhoz akár elég lehet a mail() függvény is.
2

Igazad van bocs, nem jól

iddqd · 2013. Dec. 21. (Szo), 15.58
Igazad van bocs, nem jól fogalmaztam! Én vagyok a küldő fél, rajtam keresztül kellene lehet kapcsolatot felvenni, foglalni, egyeztetni ilyesmi.
3

Ez nem sokkal több információ

Hidvégi Gábor · 2013. Dec. 21. (Szo), 16.12
Ez nem sokkal több információ : ) Egyszerre egy félnek küldesz levelet, vagy esetleg kell listákat is kezelni? A válaszleveleket saját felületen szeretnéd kezelni, vagy szoftvert (outlook, gmail) használsz?
4

Tehát, az oldalon megjelenő

iddqd · 2013. Dec. 21. (Szo), 16.37
Tehát, az oldalon megjelenő partnerekkel kellene felvenni a kapcsolatot ( ez lehet időpont egyeztetés, információ kérés stb), egy email formájában. Erre szolgál egy form, minden egyes partner, bemutatkozó oldalán. Egyszerre egy email, a választ az adott partner intézi a maga módján.
5

Érdemes kipróbálnod a

Hidvégi Gábor · 2013. Dec. 21. (Szo), 22.35
Érdemes kipróbálnod a PHPMailert, az mindent tud (utf-8, csatolmányok).
6

Bocsi, de pont erre lesz elég

Pepita · 2013. Dec. 21. (Szo), 22.56
neki a mail(), mert egyszerre egy űrlap, egy mail, gondolom még sima plain/text, nem is HTML. Ellapoztam, nem biztos, hogy jól idézek:
A választ az ügyfél intézi.
Tehát ugyanaz kb, mint itt a kapcsolatfelvételi űrlap Júzerekhez kötötten. Egyszerűbb a legegyszerűbb.

Azért valami captcha-t tegyél rá, plusz arra érdemes figyelni, hogy a szolgáltatód mennyi e-mailt enged adott időintervallumban, van-e ilyen korlátozás, mert ha van, a forgalom növekedtével bajban lehetsz, amin a PHPMailer sem tud segíteni, akkor szükséged lesz egy SMTP szerverre is.
7

Hja, pont ezért kéne eleve

bamegakapa · 2013. Dec. 22. (V), 00.34
Hja, pont ezért kéne eleve phpmailer vagy swiftmailer. Könnyebb átdrótozni smtpre, ráadásul csomó macerát elintéz.
8

Először én is a mail()-t

Hidvégi Gábor · 2013. Dec. 22. (V), 09.46
Először én is a mail()-t írtam bele a fenti válaszba, de aztán azért vettem ki, mert ha (nagy valószínűséggel) utf-8-at használ vagy csatolni szeretne bármit, akkor fölösleges újra feltalálnia a spanyolviaszt.
9

Igazából mindegy,

Pepita · 2013. Dec. 22. (V), 12.25
utf-8 nemigazán gond, csatolni meg nem akar.

Én a CodeIgniter Email osztályát használom, azzal gyakorlatilag bárhogy tudok e-mailt küldeni, csatolással, kisnyulakkal együtt is.
Ezért jó egy jó keretrendszert használni; de legyen a PHPMailer, ha később bővíteni kell, tényleg jobb, csak a jelenlegi kicsi feladatra bőven elég mail() is, azért javasoltam, hogy ne bonyolítsa.

Majd eldönti, ennyiből most már el fogja tudni... :)
10

A kérdés már csak az, hogy a

bamegakapa · 2013. Dec. 22. (V), 13.39
A kérdés már csak az, hogy a PHPMailerrel (bár ezt nem ismerem, SwiftMailert használtam mindig, de gondolom nincs nagy különbség) bonyolítja, vagy a mail függvénnyel ;).
11

PHP-ből nincs egyszerűbb

Pepita · 2013. Dec. 22. (V), 20.25
a mail()-nél, de ne keverjünk már ennyire... :)
20

Mindketto megoldja a

blacksonic · 2014. Jan. 7. (K), 11.59
Mindketto megoldja a problemat de,
egy nagy kulonbseg van a SwiftMailer es PHPMailer kozott:
ha lattal mar ocsmany es erthetetlen kodot szorozd meg 10zel es megkapod a PHPMailer kodjat
egyetlen elonye hogy egy fajlban van minden megvalositva :D
12

Köszönöm a válaszokat! Nekem

iddqd · 2014. Jan. 6. (H), 11.20
Köszönöm a válaszokat! Nekem akkor nagyjából az jött le, hogy ha számítok később növekvő forgalomra akkor érdemes, már most előre gondolkodni és ( pl ) phpmailert használni. @pepita: én is CI -vel dolgozok és jelenleg az email class intézi, természetesen capthca van hozzá.
13

a legjobban akkor jársz, ha

szabo.b.gabor · 2014. Jan. 6. (H), 11.31
a legjobban akkor jársz, ha belegondolsz, hogy miket kell megvalósítania a levélküldő rendszerednek (tárgy, tartalom, címzettek beállításai, valamint küldés) és erre készítesz egy osztályt, ami mondjuk adott esetben phpMailer segítségével (akár azt kibővítve, vagy annak egy példányát használva) megvalósítja azt.

így ha később amikor már millió levelet küldesz és rájössz, hogy neked valami külső szolgáltatót kell mégis használnod (pl mailchimp), akkor csak ezt az osztályodat kell átírni a megfelelő módon egy helyen, és nem a levelet küldő kódjaidat átalakítani.

szerintem.
14

Az említett CodeIgniter

Pepita · 2014. Jan. 6. (H), 13.35
Email class-a támogadja az SMTP protokollt is, mindössze egy config fájlban kell megadnod a hozzáférést.
CodeIgniter's robust Email Class supports the following features:

Multiple Protocols: Mail, Sendmail, and SMTP
Multiple recipients
CC and BCCs
HTML or Plaintext email
Attachments
Word wrapping
Priorities
BCC Batch Mode, enabling large email lists to be broken into small BCC batches.
Email Debugging tools

Szerintem ennyit elég tudnia egy profi e-mail küldő osztálynak, és ehhez nem kell semmilyen további külső eszköz (az SMTP szervert leszámítva).
Ha CI-t használ, teljesen felesleges további 3rd party cuccokkal bajlódnia ehhez, és mindehhez (ez vélemény, nem reklám) a CI core-ja 1,3 MB. Nagyon sok ilyen "apró" segítség van benne - na nem mondom, hogy mindet használom is, de az Email class helyett eszembe nem jutna mást használni.

Szerk: ettől függetlenül azt mindenképp javaslom iddqd-nek az osztály átnyálazását (system\libraries\Email.php), hogy teljesen tisztában legyen a dologgal, de sajátot írni felesleges.
Ja, és legközelebb számomra az egy plusz infó lenne bárkitől is, ha jelzi a keretrendszert amit használ, nekem úgy sokkal könnyebb válaszolni, de gondolom másoknak is.
15

és ehhez nem kell semmilyen

Hidvégi Gábor · 2014. Jan. 6. (H), 13.35
és ehhez nem kell semmilyen további külső eszköz
Nem véletlenül írtam az elején, hogy kicsit több információ szükséges ahhoz, hogy segíteni tudjunk.
16

Igen, ezért

Pepita · 2014. Jan. 6. (H), 13.42
tettem hozzá én is a keretrendszert, idáig azt hittem 0-ról írja, és lám...
Szóval neki nem kell végülis semmi, némi manual-olvasáson kívül. :)
17

Rendben, akkor meg fog

iddqd · 2014. Jan. 6. (H), 17.05
Rendben, akkor meg fog felelni teljesen a CI natív email class, max smtp-vel. Bocs a pontatlanságért, teljesen igazatok van, ez kimaradt. Legközelebb pontosabb leszek. Köszönöm a válaszokat!
18

használd a natív CI-t de fedd

szabo.b.gabor · 2014. Jan. 7. (K), 10.01
használd a natív CI-t de fedd el egy általános osztállyal. a lényeg, ahol e-mail objektumokat hozol létre, ne a CI e-mail objektumát példányosítsd, hanem a sajátodat, hogy ha ne adj isten mégsem lenne jó a CI e-mail ojjektum, akkor könnyen tudj váltani.

ha bővíteni kell a funkciókat, akkor bővíted az általános osztályt is a CI funkcióival kiegészítve (ha az támogatja). ha mondjuk queue-ba akarod tenni a leveleket, akkor elég a saját osztályodban megvalósítani.

használd a CI osztályt, de ne direktbe.
19

Elolvastad a doksit?

Pepita · 2014. Jan. 7. (K), 11.58
Felesleges elfednie, nem is ő példányosít, van külön Loader class, amivel a CI osztályait betölti, a példányosítás ezekben van megoldva. És támogatja nagy mennyiségű email kiküldését is, felesleges bármit is akasztani rá, legalábbis eddig én nem találkoztam olyan feladattal, amit ne tudnék megoldani vele.
Kár bonyolítani egy egyszerű gyors rendszert.
21

Próbáltad megérteni amit mondok?

szabo.b.gabor · 2014. Jan. 7. (K), 13.59
nem használok CI-t, nem olvastam a doksit. nem erről szólt az egész.

dev rendszeren ha tesztelsz véletlenül se küldjön ki senkinek semmilyen e-mailt, hanem a címzettet cserélje le az előre beállított teszt cím(ek)re.

lássuk.

..ráadásul oda van írva az elejére, ha változás van, viszonylag rugalmasan lehessen hozzá alkalmazkodni..
22

Meg is értettem :)

Pepita · 2014. Jan. 7. (K), 18.37
A CI egésze nagyon egyszerűen configolható, ha elég okosan írod a saját szoftvered. Egyetlen config változóval megoldod, hogy minden e-mail egy helyre menjen, aztán élesben átállítod... Épp azért, mert én használok CI-t, mondom, hogy felesleges fölétenni másik osztályt. :)

Felhasználhatod akár az index.php elején definiált ENVIRONMENT konstanst is, hogy eldöntsd: melyik e-mail configgal menjenek a levelek. (Lehetséges értékek: 'development', 'testing', 'production'.)

Írsz két configot a devre és az élesre, a helyén a konstans fvnyében választasz és jónapot.
..ráadásul oda van írva az elejére, ha változás van, viszonylag rugalmasan lehessen hozzá alkalmazkodni..
Ha meg van a configod, ugyanazt bármi más 3rd party cuccnál is használhatod, a CI Email class-t meg kihagyod. De nem hiszem, hogy volna olyan dolog, amit pl. a PHPMailer tud, a CI meg nem...

Szerintem mielőtt tovább vitáznánk erről, ismerd meg jobban a CI-t; én épp azért bírom nagyon, mert szükségtelenek az ilyen trükközések / elfedések, emellett nagyon kicsi, nagyon gyors fw. És ha nagyon muszáj, akkor belenyúlok a core-ba, de eddig nem volt rá szükségem a "hiányzó" PHPDoc-okon (kódkiegészítéshez) kívül (van benne, de Komodo Edithez kicsit több is kellett).

Szerk.: ha külön osztállyal elfedné, annak egyetlen fv-e lenne...
23

ENVIRONMENT

iddqd · 2014. Jan. 8. (Sze), 13.22
Ezt a config megoldást használom én is.
27

Helyes

Pepita · 2014. Jan. 9. (Cs), 01.34
Jól teszed.
28

de van jobb megoldás is

szabo.b.gabor · 2014. Jan. 9. (Cs), 09.58
pl csinálsz egy config fájlt, amit nem raksz be verziókezelés alá. tudod, hogy milyen mezők vannak benne, szépen minden környezetben feltöltöd a környezet saját adataival és azt használod.

így nem kell minden környezet hozzáférési adatait tárolni a config fájlban, és nem kell minden fejlesztőnek még plusz egy ENV értéket és if ágat felvenni, ha épp nem tud, vagy akar ugyanolyan beállításokat használni, mint te a fejlesztéskor.

szóval jó az csak mégsem annyira.
33

De, jó az

Pepita · 2014. Jan. 9. (Cs), 15.12
Az egész CI "szemlélete" ilyen, igazából akkor teszed jól, ha ezt az if ágat a config betöltésével kiteszed egy helper fv-be. Az ENVIRONMENT constans pedig a CI része, mint írtam.

Ha a másik fejlesztő másik env-configot akar, akkor átírja a megfelelő config fájlt - ez a legegyszerűbb.
35

+1

bamegakapa · 2014. Jan. 9. (Cs), 16.00
Egy minta config fájlt persze be lehet rakni a verziókezelés alá.

Szerintem elég nagy hiba minden környezeten tárolni az összes környezet adatait.
32

ha külön osztállyal elfedné,

Endyl · 2014. Jan. 9. (Cs), 13.20
ha külön osztállyal elfedné, annak egyetlen fv-e lenne...


Ha külön osztállyal (netán interface-szel) elfedné, annak inkább annyi függvénye lenne, amennyit az alkalmazás (és nem a konkrét levél küldésének implementációja) megkövetel. Már csak azért is jó lenne elfedni, mert miért érdekelje az alkalmazást, hogy a levélküldés hogyan van megvalósítva? Számára mindegy, hogy a levélküldés menete
$this->load->library('email');
// ...
$this->email->send();
vagy
$message = Swift_Message::newInstance();
// ...
$result = $mailer->send($message);
Az alkalmazást csak az kéne érdekelje, hogy mit és milyen adatokkal küld.

De nem hiszem, hogy volna olyan dolog, amit pl. a PHPMailer tud, a CI meg nem...

vs.
Szerintem mielőtt tovább vitáznánk erről, ismerd meg jobban a CI-t;

:)

A SwiftMailer (amit szintén ajánlottak, és amiről tudok nyilatkozni, lévén ezt szoktam használni, a PHPMailert meg nem) például az itteni doksit átnézve és a CI kódjába belepillantva bizony tud többet. De ha nincs is szükség ezekre a többletfunkciókra, az alkalmazás oldaláról akkor is célszerűbb, ha csak annyit látunk, amennyi az alkalmazásnak számít. Így aztán, ha később más emailező rendszert kell használni a követlemények megváltozása miatt a levelek küldéséhez, akkor elég egy, központi helyen módosítani azt.

Továbbá nem hiszem, hogy OOP környezetben az implementációs részletek elfedése az alkalmazáslogika elől trükközésnek számítana, hanem inkább célnak.

Nyilván, ha csak egy, jól behatárolt helyen szerepel a levélküldés, akkor kár elfedni (illetve tekinthető elfedettnek). Viszont ha kezd szaporodni a $this->load->library('email'); használata, akkor célszerű elgondolkozni a rejtésen.
34

Hát, talán...

Pepita · 2014. Jan. 9. (Cs), 15.27
ha kezd szaporodni a $this->load->library('email'); használata, akkor célszerű elgondolkozni a rejtésen.
Talán ebben van némi igazság, de én többnyire ha máshol küldök emailt (tehát mondjuk újabb $this->load->library('email');), annak mások a paraméterei is, más a sablonja, stb. Ezek fölé egy mindegyiket kezelni tudó osztályt írni, majd a meghatározott helyeken helyesen használni ezt az elfedő osztályt - szerintem nem éri meg, több a munka vele.
Akkor lehet ennek létjogosultsága, ha sok helyen küldesz közel azonos paraméterekkel levelet, de akkor az alkalmazáslogikában is van egy kis baj szerintem.

Azt hiszem nagyon túlrészleteztük már a témát, a kérdező rég megkapta a válaszát...
37

[…] ha máshol küldök emailt

Endyl · 2014. Jan. 9. (Cs), 16.36
[…] ha máshol küldök emailt […], annak mások a paraméterei is, más a sablonja, stb.
Az email tartalmának renderelése más tészta, nem nagyon kell köze legyen a küldés technikai megvalósításához, így nem is kell az ezt elfedő absztrakciónak ezt kezelnie.
24

használd a natív CI-t de fedd

Hidvégi Gábor · 2014. Jan. 8. (Sze), 13.28
használd a natív CI-t de fedd el egy általános osztállyal
Ezt nem teljesen értem. A CodeIgniter eleve egy keretrendszer, ami elfedi a részleteket, miért kéne efölé még egy külön osztályréteget húzni?
25

tfh CI-ben így kell levelet

szabo.b.gabor · 2014. Jan. 8. (Sze), 16.28
tfh CI-ben így kell levelet küldeni.
$mail = new CIMail();
$mail->setSubject('teszt');
$mail->setBody('Jani');
$mail->addRecipient('abc##kukac##def.hu');
$mail->send();
ha a kódban mondjuk 20 helyről küld e-mailt és ezt leírja 20-szor, akkor bajban lesz, ha később rájön, hogy neki mégsem jó a CIMail implementáció, mert vagy át kell írnia mind a 20 helyen a kódot, vagy bele kell gányolnia a CI forrásába. ezek közül egyik sem kellemes..

hát ezért érdemes elfedni.

de a CI valahogy így csinálja
$this->load('email');
//..
$this->email->addRecipient('abc##kukac##def.hu');
$this->email->send();
aztán, hogy a $this->load('email') tud-e úgy működni CI-ben, hogy egy egész más osztályt használjon, nem tudom. gondolom igen (nem érdekel amúgy).
26

Olyat nem tud

Pepita · 2014. Jan. 9. (Cs), 01.33
aztán, hogy a $this->load('email') tud-e úgy működni CI-ben, hogy egy egész más osztályt használjon, nem tudom.
Ilyet csak akkor tud, ha a core-ban cseréled le az osztályt.
Olyat tud - de nem illik -, hogy $this->load->library('Email');..., ezzel a saját felhasználói osztályodat hívod meg. De a doksi felhívja a figyelmet a névütközések kerülésére, nyilván azért, hogy a core egységes maradjon. Azt nem tudom - még sosem próbáltam -, hogy egyáltalán betölt e fenntartott nevű saját osztályt, lehet, hogy nem.
29

oh..

szabo.b.gabor · 2014. Jan. 9. (Cs), 10.00
hát akkor semmikép sem érdemes elfedni..
30

30

szabo.b.gabor · 2014. Jan. 9. (Cs), 10.00
megvan a 30 hozzászólás, átléptük a flame flag-et :D
31

Vannak emberek, akiket nem

szjanihu · 2014. Jan. 9. (Cs), 10.25
Vannak emberek, akiket nem lehet meggyőzni dolgokról :)
36

Köszi, így már világos.

Hidvégi Gábor · 2014. Jan. 9. (Cs), 16.02
Köszi, így már világos.
38

Az egész koncepció rossz,

szjanihu · 2014. Jan. 9. (Cs), 19.09
Az egész koncepció rossz, mivel a CIMail stateful objektum, ezért egy DIC-ből, vagy akármi hasonló konténerből kikérni buta dolog. Ráadásul az, hogy van send() metódusa, egy csomó elvet megsért. De lendüljünk túl ezen.

Most nem egy minden szempontból jó, de mindenképp egy jobb megoldást vázolok:

Készíteni egy osztályt, ami tárolja az email összes adatát

class Email
{
    private $sender;
    private $recipients;
    // etc.
}
Interfész a küldéshez

interface EmailSender
{
    public function send(Email $email);
}
Konkrét implementáció

class CIEmailSender implements EmailSender
{
    public function send(Email $email)
    {
        $ciEmail = //instantiate CodeIgniter Email class
        $ciEmail->from($email->getFrom());
        // etc.
        $ciEmail->send();
    }
}
A következő előnyökkel jár ez:
  • Az Email példányokat perzisztálni lehet, ha esetleg szükség lenne rá, így könnyen újraküldhető egy levél.
  • Email küldés egy, azaz egy helyen van, az osztályon kívül senki se tudja, hogy CI Email van használva.
  • Épp ezért később bármikor könnyen lecserélhető, csak a konfigurációt kell átírni, meglévő kódot nem kell módosítani. Persze ez csak DI konténerrel működik.
39

szabo.b.gabor pont ugyanezt

Hidvégi Gábor · 2014. Jan. 10. (P), 10.13
szabo.b.gabor pont ugyanezt írta le, hogy így kéne megvalósítani.
40

de ő még az e-mailt és az

szabo.b.gabor · 2014. Jan. 10. (P), 12.37
de ő még az e-mailt és az e-mail küldést is külön szedte..