php-general Digest 18 Oct 2012 09:12:47 -0000 Issue 8012
Topics (messages 319500 through 319509):
Re: Serving an image
319500 by: Wouter van Vliet / Interpotential
Send php Mail not working in MAMP (non pro version)
319501 by: Dave
319504 by: Jim Lucas
319507 by: Dave
Re: Wrong time being displayed by PHP!
319502 by: Richard S. Crawford
319503 by: Daniel Brown
319505 by: Geoff Shang
319509 by: Ford, Mike
Re: foreach
319506 by: Larry Garfield
319508 by: tamouse mailing lists
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 ---
>
> What is the diference between using imagecreatefrompng() and readfile()?
> Any performance improvement?
>
>
If you don't do any image minipulation, I would recommend readfile indeed.
The differences being that imagecreatefrompng load the image into memory,
ready to change it (overlay, rotate, crop, colours, .. anything), and
readfile just sends whatever file you point it to back to the browser (or
other output).
Then again, if you all you're doing is sending an image to the browser;
then why not do a redirect - or simply refer to the image directly?
Wouter
--- End Message ---
--- Begin Message ---
Hi all,
MAC LION 10.7.4 & latest MAMP (non pro version)
I've tried various things - but php send mail not working in MAMP (non
pro version)
... mail ( string $to , string $subject , string $message [, string
$additional_headers [, string $additional_parameters ]] )
the same script works on a hosted server...
tried this but not working...
viewtopic.php?f=2&t=10722
seems like I need to add more data - somewhere in php.ini or the php
sendmail script.... like authentication info of mailhost and user /
pass and port etc....
maybe setting data here? --- [, string $additional_headers [, string
$additional_parameters ]] - i don't know how..
I also posted this at mamp forum but there does not seem much action there...
http://forum.mamp.info/viewtopic.php?f=2&t=37583&p=53515#p53515
--
Thanks - Dave
--- End Message ---
--- Begin Message ---
On 10/17/2012 09:52 AM, Dave wrote:
Hi all,
MAC LION 10.7.4& latest MAMP (non pro version)
I've tried various things - but php send mail not working in MAMP (non
pro version)
... mail ( string $to , string $subject , string $message [, string
$additional_headers [, string $additional_parameters ]] )
the same script works on a hosted server...
tried this but not working...
viewtopic.php?f=2&t=10722
seems like I need to add more data - somewhere in php.ini or the php
sendmail script.... like authentication info of mailhost and user /
pass and port etc....
maybe setting data here? --- [, string $additional_headers [, string
$additional_parameters ]] - i don't know how..
I also posted this at mamp forum but there does not seem much action there...
http://forum.mamp.info/viewtopic.php?f=2&t=37583&p=53515#p53515
First off, make sure that sendmail is installed and functioning.
Make sure, if you happen to have install postfix as well, that it has
replaced your sendmail.
Then, from the cli, as your apache/php user, try sending an email using
sendmail.
# sendmail -v y...@email.com
testing
.
...
Did it work?
More then likely your php/apache process does not know where sendmail is
or does not have permission to use it.
Check in your php.ini file and see what is set as the sendmail_path
Mine is set like this:
; For Unix only. You may supply arguments as well (default: "sendmail
-t -i").
;sendmail_path =
As a standard user on my linux box I get this
[jlucas@jim ~]$ which sendmail
/usr/bin/which: no sendmail in (...)
But as root, I get this
[root@jim ~]# which sendmail
/usr/sbin/sendmail
So, make sure your apache&php user can see and execute sendmail
--
Jim Lucas
http://www.cmsws.com/
http://www.cmsws.com/examples/
--- End Message ---
--- Begin Message ---
>
> Make sure, if you happen to have install postfix as well, that it has
> replaced your sendmail.
>
> Then, from the cli, as your apache/php user, try sending an email using
> sendmail.
>
> # sendmail -v y...@email.com
> testing
> .
>
Thanks a lot Jim for the help...
sorry this is getting a bit above me... if you mean use the terminal I
have a friend that can help me soon try to change user to apache/php
user (not sure how yet) and test this
> ...
>
> Did it work?
>
> More then likely your php/apache process does not know where sendmail is or
> does not have permission to use it.
>
> Check in your php.ini file and see what is set as the sendmail_path
>
> Mine is set like this:
>
> ; For Unix only. You may supply arguments as well (default: "sendmail -t
> -i").
> ;sendmail_path =
>
> As a standard user on my linux box I get this
>
> [jlucas@jim ~]$ which sendmail
> /usr/bin/which: no sendmail in (...)
>
> But as root, I get this
> [root@jim ~]# which sendmail
> /usr/sbin/sendmail
>
> So, make sure your apache&php user can see and execute sendmail
>
> --
> Jim Lucas
>
Ji Jim,
in the mamp php.ini file I had set like the demo to:
[mail function]
; For Win32 only.
;SMTP = localhost - these commented out as described
;smtp_port = 25 - these commented out as described
; For Win32 only.
;sendmail_from = m...@example.com
; For Unix only. You may supply arguments as well (default: "sendmail -t -i").
sendmail_path =/usr/sbin/sendmail -t -i -f m...@site.com
--
>
> First off, make sure that sendmail is installed and functioning.
I am not using sendmail that I know of. I didn't install anything -
just the basic NON PRO MAMP
Also I did not install postfix.
and I am using the basic php function mail()
--
Thanks - Dave
--- End Message ---
--- Begin Message ---
On Tue, Oct 16, 2012 at 3:16 PM, Daniel Brown <danbr...@php.net> wrote:
> >> With regard to debugging your issue, it's extremely unlikely that
> >> it's PHP's fault, since no one else has the same issue. However, it
> >> does indeed sound as though there's a configuration mismatch or a bad
> >> setting of the system clock (as suggested earlier by myself and
> >> others). What's the output when you run the code below?
> >>
> >> <?php
> >>
> >> if (php_sapi_name() == 'cli') {
> >> define('NL',PHP_EOL);
> >> } else {
> >> define('NL','<br/>'.PHP_EOL);
> >> }
> >>
> >> echo date_default_timezone_get().NL;
> >>
> >> echo date('r').NL;
> >>
> >> echo gmdate('r').NL;
> >>
> >> echo time().' ('.date('Z').')'.NL;
> >>
> >> echo trim(`date`).NL;
> >>
> >> ?>
> >
> >
> > This is the output:
> >
> > America/Los_Angeles
> > Tue, 16 Oct 2012 17:22:09 -0400
> > Tue, 16 Oct 2012 21:22:09 +0000
> > 1350422529 (-14400)
> > Tue Oct 16 17:22:09 EDT 2012
>
> Is this a shared server, Rich? As shown, the admin configured the
> timezone of the machine to be EDT and set the clock right, but php.ini must
> be set to PDT. You can easily override this with a local php.ini file, an
> .htaccess directive, or by placing date_default_timezone_set() near the top
> of the code.
You can see the current output of the above code here:
http://projectbench.extensiondlc.net
I've confirmed that the server is set to PDT. The value of date.timezone in
php.ini is "America/Los_Angeles", which should be (currently) -8 hours from
UTC, but it looks like the PDT offset is only set to -4. Does that even
make sense?
--
Sláinte,
Richard S. Crawford (rich...@underpope.com)
http://www.underpope.com
Publisher and Editor in Chief, Daikaijuzine (http://www.daikaijuzine.com)
--- End Message ---
--- Begin Message ---
On Wed, Oct 17, 2012 at 2:28 PM, Richard S. Crawford
<rscrawf...@mossroot.com> wrote:
>
> You can see the current output of the above code here:
>
> http://projectbench.extensiondlc.net
>
> I've confirmed that the server is set to PDT. The value of date.timezone in
> php.ini is "America/Los_Angeles", which should be (currently) -8 hours from
> UTC, but it looks like the PDT offset is only set to -4. Does that even make
> sense?
Yes, `date` at the command line is showing it, and sure, the
timezone is showing as PDT on both ends, but it's also using -0400 for
the timezone. In any case, this is something your administrator needs
to handle, and isn't something with PHP or your code, from the looks
of it.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
On Wed, 17 Oct 2012, Richard S. Crawford wrote:
I've confirmed that the server is set to PDT. The value of date.timezone in
php.ini is "America/Los_Angeles", which should be (currently) -8 hours from
UTC, but it looks like the PDT offset is only set to -4. Does that even
make sense?
Actually, PDT is UTC minus 7, not 8. But that's not the point.
I know people are pointing at a configuration issue, and it may well be.
But the fact that PHP seems to have the correct idea for what UTC is
suggests that perhaps either PHP or the (presumably) C routines that it
uses may be at least contributing to this.
This is not the first time I've seen strangeness with default timezones,
and I guess there's a reason why using them generates a warning. Best to
deliberately set your timezone. Now if it still does it when you actually
set it to America/Los_Angeles then we've got a bigger problem.
Geoff.
--- End Message ---
--- Begin Message ---
> From: underp...@gmail.com [mailto:underp...@gmail.com] On Behalf Of
> Richard S. Crawford
> Sent: 17 October 2012 19:29
> To: PHP-General
>
> You can see the current output of the above code here:
>
> http://projectbench.extensiondlc.net
Can I ask what the fix for this was? Because that URL is currently
showing the following for me:
02:09:27 am America/Los_Angeles
America/Los_Angeles
Thu, 18 Oct 2012 02:09:27 -0700
Thu, 18 Oct 2012 09:09:27 +0000
1350551367 (-25200)
Thu Oct 18 02:09:27 PDT 2012
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS, LS1 3HE, United Kingdom
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--- End Message ---
--- Begin Message ---
On 10/17/12 10:17 AM, Matijn Woudt wrote:
On Wed, Oct 17, 2012 at 1:25 AM, Larry Garfield <la...@garfieldtech.com> wrote:
For the love of god, please stop using ext/mysql (aka the mysql_*
functions). It's insecure and slow and lacks features.
Instead, use PDO, and bind your parameters. As a nice bonus, the result
from a PDO-based query is not a raw resource but an iteratable object, which
means you can foreach() it.
http://php.net/manual/en/book.pdo.php
$conn = new PDO(...);
$result = $conn->query("SELECT * FROM items");
foreach ($result as $record) {
// Do something with each record here.
}
--Larry Garfield
Yes, the mysql extension is deprecated, but what's wrong with mysqli?
mysqli has the advantage that you don't need to keep a database handle
floating around, but you can just use mysqli_query everywhere.
When having multiple files and classes, it's terrible to pass $db to
each function/class, and I hate to use the global keyword.
just use while($record = $result->fetch_array()) instead of
foreach($result as $record)
And you mention ext/mysql is slow, well don't know about that, but PDO
is a bit slower than mysqli atleast.
I quote from [1]:
"For inserts, there was no significant difference between MySQLi and
PDO (prepared statements or not). For selects, MySQLi was about 2.5%
faster for non-prepared statements and about 6.7% faster for prepared
statements. "
- Matijn
[1] http://jnrbsn.com/2010/06/mysqli-vs-pdo-benchmarks
Nothing is wrong with mysqli per se. It's up to date and secure, and
certainly better than ext/mysql. I recommend PDO over mysqli because:
1) PHP-engine-level global state (ie, not specifying a connection) is
the source of most (although not quite all) evil. Really, that way lies
pain once you get into anything reasonably complicated and want to be
able to test it properly.
2) PDO is installed by default on virtually every PHP system in the
world. ext/mysqli has never been part of the default build of PHP, and
many to most web hosts don't have it installed.
3) mysqli's API is a bizarre hybrid of procedural and OO that confuses
the heck out of me. PDO's is far from perfect, but is more consistent
and cleanly OO from the get-go.
I skipped mysqli entirely and went straight to PDO when it became available.
--Larry Garfield
--- End Message ---
--- Begin Message ---
On Wed, Oct 17, 2012 at 6:07 PM, Larry Garfield <la...@garfieldtech.com> wrote:
> Nothing is wrong with mysqli per se. It's up to date and secure, and
> certainly better than ext/mysql. I recommend PDO over mysqli because:
>
> 1) PHP-engine-level global state (ie, not specifying a connection) is the
> source of most (although not quite all) evil. Really, that way lies pain
> once you get into anything reasonably complicated and want to be able to
> test it properly.
I don't have a clue what you are saying here.
> 2) PDO is installed by default on virtually every PHP system in the world.
> ext/mysqli has never been part of the default build of PHP, and many to most
> web hosts don't have it installed.
Do you have any reasonable data on this? Where do you get this notion
that it's not installed on many to most web hosts? Every distro I've
encountered has it built in to the version installed (ubuntu, debian,
centos, fedora, os/x, gentoo, funtoo, and many i've forgotten).
You are correct that you must specify --with-mysqli in the configure
command if you build php from source.
> 3) mysqli's API is a bizarre hybrid of procedural and OO that confuses the
> heck out of me. PDO's is far from perfect, but is more consistent and
> cleanly OO from the get-go.
Err...ah...err -- mysqli is not a hybrid. It offers both OO and
procedural, but you only use one or the other. If you mix them
together in the same script/app, you could be looking for a lot of
trouble.
> I skipped mysqli entirely and went straight to PDO when it became available.
This might be the source of your bias.
That said, I use PDO now all the time.
--- End Message ---
