On Thu, Jun 12, 2008 at 1:31 PM, Gwoo <[EMAIL PROTECTED]> wrote:
> But since we have the component in the core, it's
> not going anywhere, and we are not going to include 3rd party
> libraries, can we do something to match those features without
> bloating Cake. My goal is for the Email component
On Jun 12, 8:22 am, "Jonathan Snook" <[EMAIL PROTECTED]> wrote:
> I would disagree with your assessment of the conversation.
Good.
> We're debating two key issues:
>
> 1. The quality and features of the email component as it stands today; and
>From the messages I read it was clear the current
> I have to say this thread is a little disappointing. Not because it
> takes a direct stab at knocking the code in the core, but rather that
> it shows a spirit that is more about "taking" than it is about
> "giving".
I would disagree with your assessment of the conversation.
We're debating two
I personally didn't mean any ill-will. When I first learned about
CakePHP, version 1.1 was the only option. I intended to use Cake in
the future. In the mean time, I knew I'd need to use email (as
Jonothan Snook already stated) and the vendor() function (of 1.1)
would have worked flawlessly for
I have to say this thread is a little disappointing. Not because it
takes a direct stab at knocking the code in the core, but rather that
it shows a spirit that is more about "taking" than it is about
"giving". I will never be ashamed to admit that something inside of
Cake is not perfect. The poin
> I suppose the book is being fair when it says "There is a lot that it
> doesn't do for you but it will get you started." Hmm, more like get
> you frustrated and ready to move on to a fully-featured working
> library. I will propose a 'diplomatic' amendment to the book.
I understand why you w
Hi Stephen,
phpMailer and SwiftMail are both LGPL and ZF is Open BSD, so I don't
think it's really an issue for most users.
In any case, if licensing was the problem, why not put a clear
'alert' label on the Cake component informing everyone that it only
really exists for licensing reasons. T
I think the thinking is that, by not including external solutions
wherever possible, it keeps the licensing clean, making it easier for
bigger companies to adopt for their own projects. The trouble with
including most external libraries is that they're GPLed, which tends
to mean that the entire so
Same here. I struggled with the Cake component but then put my trusty
phpMailer in vendors and bingo, my emails were soon flying again.
I now cannot see the point in Cake developers spending their time on
this Email component when there are such robust, fully-featured
solutions available to be '
While waiting for replys to this, I tried using the Pear mail script
as a Vendor and got it working within about 30 seconds! Thanks for the
replies, they have confirmed that it's probably best for now to stick
with a more mature mail system.
On Jun 10, 3:09 pm, BrendonKoz <[EMAIL PROTECTED]> wrot
You could also use the Zend framework's email classes as a vendor if
need be. Before the Cake email component was created, that was what
my original plan was for sending email. There are plenty of tutorials
on using the Zend Framework's email class. (Don't think of the Zend
Framework as a compe
> I am trying to use the new email component in cake 1.2, but am having
> problems using it with an authenticated SMTP server. I am getting the
> following error:
> 503 5.5.2 Send hello first
Not to knock the core developers but the email component still needs
some work, especially in support for
Why not just use an email component?
\n";
$headers .= 'X-Sender: <[EMAIL PROTECTED]>\n';
$headers .= 'X-Mailer: PHP\n';
$headers .= "Reply-To: ".$f_name." <".$f_email.">\n\n";
// Mail it
Hi All
I am trying to use the new email component in cake 1.2, but am having
problems using it with an authenticated SMTP server. I am getting the
following error:
503 5.5.2 Send hello first
How would I send the Hello using the component? FYI I can use Pear's
email script on the same SMTP server
14 matches
Mail list logo
