php-general Digest 22 Mar 2010 14:33:01 -0000 Issue 6653
Topics (messages 303083 through 303087):
Re: web sniffer
303083 by: Auke van Slooten
Re: PHP SMTP Mailers
303084 by: Auke van Slooten
303085 by: Michael A. Peters
another question on setting include paths for a project
303086 by: Robert P. J. Day
303087 by: Richard Quadling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Jochen Schultz wrote:
Btw., when you use file_get_contets, is there a good way to tell the
script to stop recieving the file after let's say 2 seconds - just in
case the server is not reachable - to avoid using fsockopen?
http://nl.php.net/manual/en/context.http.php
specifically:
timeout float
Read timeout in seconds, specified by a float (e.g. 10.5).
By default the default_socket_timeout php.ini setting is used.
used with http://nl.php.net/manual/en/function.stream-context-create.php
regards,
Auke van Slooten
Muze
--- End Message ---
--- Begin Message ---
King Coffee wrote:
Hi,
I'm executing a third-parity standard PHP application on a Windows IIS 7
shared hosting server.
I need to convert, or use, a SMTP mailer service. I found two SMTP PHP
scripts - I think may work.
The sourceforge.net PHPMailer project and the pear.php.net (Mail,
Net_SMTP) project.
Can any body please help me choose one and probably give a code snip of
useage?
Currently, I'm leaning forward the PHPMailer, with little to base the
decision on.
Hi,
I'd take a look at http://www.phpguru.org/static/smtp.html
It doesn't make the mistake of muddling the differnece between the
message envelope and the message body, so you can set the recipients
directly and different from the messages to/cc/bcc headers. It has a
fairly sane design, based on the smtp protocol. And finally it uses
exceptions in a sane way. Oh, and its a fairly small and straightforward
piece of code, easy to include in any application.
There's one problem in it when using it for bulk-mail. If you add many
recipients and one of them is incorrect, it will fail the entire message.
It's not free for commercial use, but the one-time license fee is more
than worth it.
regards,
Auke van Slooten
Muze
(And no, I'm not affiliated with the author, just a happy customer).
--- End Message ---
--- Begin Message ---
King Coffee wrote:
Hi,
I'm executing a third-parity standard PHP application on a Windows IIS 7
shared hosting server.
I need to convert, or use, a SMTP mailer service. I found two SMTP PHP
scripts - I think may work.
The sourceforge.net PHPMailer project and the pear.php.net (Mail,
Net_SMTP) project.
Can any body please help me choose one and probably give a code snip of
useage?
Currently, I'm leaning forward the PHPMailer, with little to base the
decision on.
Thanks in advanced,
King Coffee
I use phpmailer and find it to be painless and consistent.
I extend the class and call the extended class:
<?php
require("class.phpmailer.php");
class MyMailer extends PHPMailer {
// Set default variables for all new objects
var $From = "zon...@shastaherps.org";
var $FromName = "Lampro P. Eltis";
var $ReplyTo = "mpet...@mac.com";
var $Host = "localhost";
var $Mailer = "smtp"; // Alternative to IsSMTP()
var $WordWrap = 75;
}
?>
Then when I want to use it -
$mail = new MyMailer();
$mail->Subject = "Some Subject";
$mail->Body = "Some content";
if($mail->Send()) {
// it was successfully sent, code on success here
} else {
// there was an error, error code here
}
I never send HTML mail or attachments or bulk mail, but I believe it is
capable of doing them quite easily.
Tip: Whatever solution you use, set the wordwrap to something that works
well on an 80 char display. Some clients do not autowrap unwrapped
messages and other clients wrap for display but when replying, it
doesn't wrap.
I use 75 because it gives a little room for the "> " that accompanies a
reply.
--- End Message ---
--- Begin Message ---
to recap regarding an earlier question i asked regarding extending
include paths, i have an existing project (call it "proj" currently
all under a top-level directory also named "proj") which can be SVN
checked out anywhere under a user's home directory. so in my case, i
might have my svn working copy under, say,
/home/rpjday/stuff/work/proj/, and all proj-related content under
that.
at the moment, there are some subdirs under proj/ like "common" and
"utils" and "debug", and all includes or requires throughout the
working copy are currently and awkwardly of the form:
include '../../proj/utils/somescript.php';
in short, every script that needs to include another one somewhere
else in the code structure sadly needs to know its precise relative
location.
my proposal is to get rid of most of that by:
1) having developers set a single env var PROJ_DIR in their login
session, reflecting wherever the heck they checked out their
working copy to, then ...
2) having said developers uniformly extend their directly callable PHP
scripts with something at the very top like:
set_include_path(getenv('PROJ_DIR') . PATH_SEPARATOR . get_include_path());
not only will that let them simplify their command-line callable
scripts to say just:
include 'utils/somescript.php';
also, as i read it, that newly-extended include path percolates down
through all PHP scripts invoked directly or indirectly from this one,
right? so while i could add that set_include_path() to every single
PHP script everywhere in the code base, it's really only necessary to
add it to those PHP scripts that people intend to *invoke* directly --
every other script will pick it up automatically as it's called, is
that correct? (did i phrase that meaningfully?)
that was part one.
the new additional complication is that some of those PHP scripts
will manually construct HTTP POST requests and ship those requests off
to PHP scripts that live under a public_html/ directory, whose
scripts might *also* want to include some of those very same utils/ or
common/ scripts but that modified include path will, of course, not
carry across a POST request, so what's the standard way to similarly
modify the include path of the scripts on the server end?
(unsurprisingly, all those "server-side" PHP scripts are also part
of the entire SVN checkout just so i can keep everything in the same
place for testing.)
so how can i have those "server-side" scripts extend their search
path based on, perhaps, the same environment variable?
thoughts?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
--- End Message ---
--- Begin Message ---
On 22 March 2010 14:18, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>
> to recap regarding an earlier question i asked regarding extending
> include paths, i have an existing project (call it "proj" currently
> all under a top-level directory also named "proj") which can be SVN
> checked out anywhere under a user's home directory. so in my case, i
> might have my svn working copy under, say,
> /home/rpjday/stuff/work/proj/, and all proj-related content under
> that.
>
> at the moment, there are some subdirs under proj/ like "common" and
> "utils" and "debug", and all includes or requires throughout the
> working copy are currently and awkwardly of the form:
>
> include '../../proj/utils/somescript.php';
>
> in short, every script that needs to include another one somewhere
> else in the code structure sadly needs to know its precise relative
> location.
>
> my proposal is to get rid of most of that by:
>
> 1) having developers set a single env var PROJ_DIR in their login
> session, reflecting wherever the heck they checked out their
> working copy to, then ...
> 2) having said developers uniformly extend their directly callable PHP
> scripts with something at the very top like:
>
> set_include_path(getenv('PROJ_DIR') . PATH_SEPARATOR . get_include_path());
>
> not only will that let them simplify their command-line callable
> scripts to say just:
>
> include 'utils/somescript.php';
>
> also, as i read it, that newly-extended include path percolates down
> through all PHP scripts invoked directly or indirectly from this one,
> right? so while i could add that set_include_path() to every single
> PHP script everywhere in the code base, it's really only necessary to
> add it to those PHP scripts that people intend to *invoke* directly --
> every other script will pick it up automatically as it's called, is
> that correct? (did i phrase that meaningfully?)
>
> that was part one.
>
> the new additional complication is that some of those PHP scripts
> will manually construct HTTP POST requests and ship those requests off
> to PHP scripts that live under a public_html/ directory, whose
> scripts might *also* want to include some of those very same utils/ or
> common/ scripts but that modified include path will, of course, not
> carry across a POST request, so what's the standard way to similarly
> modify the include path of the scripts on the server end?
>
> (unsurprisingly, all those "server-side" PHP scripts are also part
> of the entire SVN checkout just so i can keep everything in the same
> place for testing.)
>
> so how can i have those "server-side" scripts extend their search
> path based on, perhaps, the same environment variable?
>
> thoughts?
>
> rday
> --
>
> ========================================================================
> Robert P. J. Day Waterloo, Ontario, CANADA
>
> Linux Consulting, Training and Kernel Pedantry.
>
> Web page: http://crashcourse.ca
> Twitter: http://twitter.com/rpjday
> ========================================================================
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Depending upon what is being included, an autoloader could help here.
The main payoffs for autoloading are reduced memory footprint (class
are loaded JIT) and no need for each class to know exactly where the
other classes are.
So, your main page needs to load the autoloader and the autoloader
handles the loading of the classes.
No need to change the include_path setting.
--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--- End Message ---
