php-general Digest 1 Nov 2005 15:15:32 -0000 Issue 3769
Topics (messages 224895 through 224907):
Re: php mail function vs smtp server
224895 by: Richard Lynch
224896 by: Richard Lynch
PDF permissions problems
224897 by: Jeremy Reynolds
224898 by: Jay Blanchard
Re: Type of form element
224899 by: Marcus Bointon
224900 by: Chris Shiflett
224905 by: Marcus Bointon
224906 by: Chris Shiflett
LDAP Paged Search
224901 by: Claudio
Anyone know where 5.1 RC1 has gone?
224902 by: Richard Davey
224903 by: Thilo Raufeisen
Re: Problem with Regexp
224904 by: Yannick Mortier
Managing files on the client
224907 by: dcook
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On Mon, October 31, 2005 4:10 am, Clive wrote:
> does anyone know whats better/uses less resource etc:
>
> If I run a loop to send a 1000 emails, should I use php's mail
> fucntions
> or send directly to the servers smtp server.
SMTP
PHP's mail() function was never designed for high-volume email.
It fires up a different process of sendmail for EACH email.
This is NOT cheap, nor efficient.
mail() is convenient. It is not efficient.
Use mail() for quickie one-off emails.
Use something else for mass email.
There are classes/packages you can use to make this painless.
http://phpclasses.org has at least one that gets used/recommended a lot.
--
Like Music?
http://l-i-e.com/artists.htm
--- End Message ---
--- Begin Message ---
On Mon, October 31, 2005 5:22 am, Paul Waring wrote:
> On Mon, Oct 31, 2005 at 12:56:01PM +0200, Clive wrote:
>> Thanks I actually want to send 24 000 emails with 2 meg attachments.
Woof.
mail() is DEFINITELY the wrong answer!
Firing up an SMTP connection and spewing 24,000 emails with 2 meg
attachments at it is *ALSO* a wrong answer, almost for sure.
You will probably have a very unhappy SysAdmin behind that SMTP
server, and odds are really really really good they'll have a long
line of VERY unhappy SysAdmins behind them.
You can pretty much count on being labeled (hopefully mis-labeled) as
a spammer almost immediately.
2 meg attachments are your first biggest problem. Lose them. Include
a link to whatever it is for the user to download the 2 meg at their
leisure. This is non-negotiable. You WILL regret the 2 meg
attachment long before the 24,000th user gets it.
Queue up the emails and send them out over a controlled time.
If there's ANY question that somebody might not want this email, don't
send it. Get them to opt-in first, if you haven't already.
--
Like Music?
http://l-i-e.com/artists.htm
--- End Message ---
--- Begin Message ---
I'm trying to write a FDF file into a directory outside of the
webserver. I keep getting errors such as:
Warning: fopen(/x/x/FDF/FLQual.fdf): failed to open stream:
Permission denied in /Library/WebServer/Documents/x/x/FLCorpQual.php
on line 36
Can someone give me a quick lesson in permissions? For example, as
long as the director I want to write into has read permissions, I'm
ok, right? But what if that director is inside another directory
that doesn't have read permissions? And does it matter that I'm
writing from a PHP page that's within the Web Directory out into a
director that's not within the Web Directory? I'm using absolute
paths.
Jeremy
--- End Message ---
--- Begin Message ---
[snip]
I'm trying to write a FDF file into a directory outside of the
webserver. I keep getting errors such as:
Warning: fopen(/x/x/FDF/FLQual.fdf): failed to open stream:
Permission denied in /Library/WebServer/Documents/x/x/FLCorpQual.php
on line 36
Can someone give me a quick lesson in permissions? For example, as
long as the director I want to write into has read permissions, I'm
ok, right? But what if that director is inside another directory
that doesn't have read permissions? And does it matter that I'm
writing from a PHP page that's within the Web Directory out into a
director that's not within the Web Directory? I'm using absolute
paths.
[/snip]
I typed "lesson on directory permissions" in Google, and it was amazing.
In the case that you are talking about the 'person' that the web server is
running as must have write permissions to a directory where it is trying to
write things.
--- End Message ---
--- Begin Message ---
On 31 Oct 2005, at 17:55, Richard Lynch wrote:
You're wrong.
No. You're just missing what I'm on about. I'll agree it's very dull.
isset() does not, under any circumstances, create an index nor a
variable.
Quite right; I never said it did.
Its entire purpose *IS* to tell you if something has been set to a
value.
That's why it's CALLED "isSet"
But that's not the question you're using isset to answer. You just
want to know if something exists - you probably don't even care what
its value is.
Take apart this operation:
$a = isset($myarray['a']);
Implicit in this simple line is a 'hidden' step which is to look up
the index 'a' in $myarray to get its value before testing if it is
set or not. The issue I have is that that step's existence is being
overlooked. That line could also be written:
$a = !is_null($myarray['a']);
Either way, if $myarray['a'] does not exist, its value will be
regarded as null (and as such, isset and !is_null would give correct
results as a consequence of this convenient side-effect), but I would
also fully expect to receive an undefined index notice as you have
explicitly looked up an array index that does not exist. If you used
other functions the same way you're using isset, you would see
nothing wrong with this:
$myarray = array();
print $myarray['a'];
but I would hope that you would have a problem with that. Why treat
isset differently?
Marcus
--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
[EMAIL PROTECTED] | http://www.synchromedia.co.uk
--- End Message ---
--- Begin Message ---
Marcus Bointon wrote:
But that's not the question you're using isset to answer. You just
want to know if something exists - you probably don't even care
what its value is.
I think this is where some (most?) of the misunderstanding originates.
Testing to see whether something exists is exactly what isset() does. I
don't find Richard's use of the function inappropriate.
I would also fully expect to receive an undefined index notice as
you have explicitly looked up an array index that does not exist.
Wouldn't it seem like a bug if a function intended to check whether a
variable is set generates a notice when you test a variable that isn't?
Your example seems no different than this:
$foo = isset($bar);
If $bar is not set, this code is still fine, as it should be.
$myarray = array();
print $myarray['a'];
This is not the same case, else I could rewrite my above example as:
echo $bar;
If $bar is not set, then this does generate a notice, as it should.
To summarize, I see nothing wrong with your way of using
array_key_exists(), but I don't think you can claim Richard's use of
isset() is inappropriate. His method is "safer" in cases where the array
itself is not set, and your method is "safer" when an element's value is
NULL. Neither of these cases ever exist with $_GET, $_POST, etc.,
because they are always set, and they only contain strings. Therefore,
there's no debate to be won here. :-)
As I mentioned earlier, your argument about the social aspects of this
(such as the benefit of consistency gained by always using
array_key_exists()) is perfectly valid.
Hope that helps.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
--- End Message ---
--- Begin Message ---
On 31 Oct 2005, at 21:11, Chris Shiflett wrote:
I think this is where some (most?) of the misunderstanding
originates. Testing to see whether something exists is exactly what
isset() does.
No. Given $myarray['a'] = NULL, isset($myarray[a']) returns false.
You're saying that therefore, $myarray['a'] does not exist, which is
clearly untrue. Testing to see whether something has a value is
exactly what isset does, not whether it exists. In many cases it
comes down to the same thing (because if it doesn't exist it can't
have a value), but they are definitely not identical.
Wouldn't it seem like a bug if a function intended to check whether
a variable is set generates a notice when you test a variable that
isn't?
Since we're on such thin ice, you need to tread carefully - first you
said it's for "testing to see whether something exists", but now you
describe it as "a function intended to check whether a variable is
set". Which is it? They are not the same thing. Here's an experiment
to distinguish which it is - it may come as quite a surprise:
var_dump(isset($bar));
echo $bar;
$bar = NULL;
var_dump(isset($bar));
echo $bar;
bool(false)
PHP Notice: Undefined variable: bar in /test.php on line 3
Notice: Undefined variable: bar in /test.php on line 3
bool(false)
Holy Smoke! isset quite definitely CANNOT tell you if a variable does
not exist - though PHP clearly knows as the second echo did not
generate an error! If it returns true then it does definitely both
exist and has a value (which is useful and why you can use isset as
you do), but if it returns false you really have no idea if the var
exists or not. So what can you use instead? Is there no direct
equivalent of array_key_exists for variables? I did discover that
array_key_exists('bar', get_defined_vars()) works, but though at
least it's definitive, I don't think I could face using that
everywhere ;^)
To summarize, I see nothing wrong with your way of using
array_key_exists(), but I don't think you can claim Richard's use
of isset() is inappropriate. His method is "safer" in cases where
the array itself is not set, and your method is "safer" when an
element's value is NULL. Neither of these cases ever exist with
$_GET, $_POST, etc., because they are always set, and they only
contain strings. Therefore, there's no debate to be won here. :-)
Of course isset has a valid place - array_key_exists cannot replicate
what it does (it doesn't know about values), so they can play
together nicely - for example I'd consider this pretty robust:
if (isset($_SESSION) and is_array($_SESSION) and array_key_exists
('myvar', $_SESSION)) ...
If you get past that you can be absolutely certain that $_SESSION
['myvar'] exists, regardless of its value, and there is no
opportunity to trigger an error, whereas if you said:
if (isset($_SESSION) and is_array($_SESSION) and isset($_SESSION
['myvar'])) ...
you could still be wrong. The merest possibility of being wrong is a
bad thing in code. Why not use marginally different syntax and be
absolutely sure?
Yesterday I encountered an error in a large commercial php script and
it turned out that it was looking in $_SERVER['SERVER_NAME'] which
was there but set to NULL for some reason, and their test with isset
was failing. So it's not just academic and I'm not making it up -
this problem does happen for real.
All this over such a little thing - imagine if we had a whole
language to worry about! Oh wait...
Marcus
--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
[EMAIL PROTECTED] | http://www.synchromedia.co.uk
--- End Message ---
--- Begin Message ---
Marcus Bointon wrote:
Given $myarray['a'] = NULL, isset($myarray[a']) returns false.
Yes, I think we've established that.
I'm sure Richard and I were both well aware of this fact, but just in
case we weren't, I think we can safely assume we are by now. :-)
You're saying that therefore, $myarray['a'] does not exist
Well, I have the same opinion that isset() does - if a variable is set
to NULL, it may as well not be set. I understand and appreciate the way
PHP works and frequently rely upon its friendly behavior. If I really
care to know whether something is NULL (which I rarely do), I can always
use is_null(). Of course, none of this applies to the present topic,
because NULL is not a string.
In previous replies, I've provided methods that you can use to
distinguish between NULL, the empty string, 0, etc. There's also a table
at the top of this cheat sheet that you might find helpful:
http://www.blueshoes.org/en/developer/php_cheat_sheet
(Notice that is_null() and isset() are boolean opposites.)
Hope that helps.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
--- End Message ---
--- Begin Message ---
Hi Folks!
This is my first email to "php-general", and first of all I wish to thank
the developers for their GREAT work! :-)
Well, I don't mean to waste your time, so here follow my question.
I've stared using PHP some months ago, and my last application is an "LDAP
Administration Tool" for IBM ITDS server. It run on AIX and Linux, and I'm
trying to extend it to manage Active Directory too.
The problem is that A.D. only support "Paged search": it gives back the
first N results (N=1000 in my case) each time. There is a particular way
to perform searches that handles this kind of replies, it is usually based
on a cookie that's exchanged between client and server so that the client
can obtain a "cursor" of where the search is arrived, and continue it
until the results are completed.
I've tried to Google-search to see if someone else already had this
problem and I found that, while PERL resolve it, PHP does not provide a
solution. So I decided to subscribe this list, maybe someone here knows
how to resolve this problem?
Thanks in advance!
Claudio
--- End Message ---
--- Begin Message ---
Hi,
PHP 5.1 RC1 was on the site two days ago, but has since been
removed. I can see it in Googles cache, and snapshots are in CVS,
but no Release Candidate. Does this mean an RC2 is imminent? :)
Cheers,
Rich
--
Zend Certified Engineer
http://www.launchcode.co.uk
--- End Message ---
--- Begin Message ---
Hi,
RC4 is available since last Friday.
Take a look here http://downloads.php.net/ilia/
Richard Davey wrote:
> Hi,
>
> PHP 5.1 RC1 was on the site two days ago, but has since been
> removed. I can see it in Googles cache, and snapshots are in CVS,
> but no Release Candidate. Does this mean an RC2 is imminent? :)
>
> Cheers,
>
> Rich
--- End Message ---
--- Begin Message ---
Richard Heyes schrieb:
Yannick Mortier wrote:
Hello,
I have the string:
<tr><td><img src="http://www.runescape.com/img/hiscores/attack.gif";
valign="bottom" width=16 height=16 /></td><td> </td><td><a
href="hiscoreuser.cgi?username=zezima&category=1"
class=c>Attack</a></td><td align="right">4</td><td
align="right">99</td><td align="right">53,156,556</td></tr>
and I apply preg_match_all:
preg_match_all("/(<tr><td><img
src=\"http:\/\/www.runescape.com\/img\/hiscores\/attack.gif\"
valign=\"bottom\" width=16 height=16 \/><\/td><td> <\/td><td><a
href=\"hiscoreuser.cgi\?username=)([\w])+(&category=1\"
class=c>Attack<\/a><\/td><td align=\"right\">)([1-9])+(<\/td><td
align=\"right\">)([1-9])+(<\/td><td
align=\"right\">)([1-9,])+(<\/td><\/tr>)/",$seite,$attack);
...
But I would expect to get
[2] => Array
(
[0] => zezima
)
[6] => Array
(
[0] => 99
)
[8] => Array
(
[0] => 53,156,556 )
Instead of the values above.
Can you explain me how I can get those values?
Try something like:
preg_match_all('#username=([^&]+).+<td align="right">\d+</td><td
align="right">(\d+)</td><td align="right">([\d, ]+)</td>#i', $seite,
$matches);
print_r($matches);
Not tested - might need tweaking.
Now it works! I still use mine, but i put the + directly after the
closing bracket:
([\d]+) instead of ([\d])+
Thanks a lot for your help! I looked at your reg exp and saw this.
Yannick Mortier
--- End Message ---
--- Begin Message ---
Hello all:
Using opendir() references directories on the server. Is there a similar
function for referencing directoies on the client (browser) side?
-dc
--- End Message ---
![http://www.runescape.com/img/hiscores/attack.gif"](http://www.runescape.com/img/hiscores/attack.gif"){kind=link}