Re: [PHP] Differences
Am 04.10.12 02:48, schrieb David McGlone: Hi everyone, I have been playing around with some code the list helped me with a while back and I'm not grasping the concept between return and echo and the PHP manual doesn't answer this, unless I'm missing something. There is an example at the very bottom of PHP's return manual, but it's confusing. Basically there is only difference, they have nothing in common. http://de.php.net/echo echo --- Output one or more strings http://de.php.net/return If called from within a function, the /return/ statement immediately ends execution of the current function, and returns its argument as the value of the function call. /return/ will also end the execution of an eval() http://de.php.net/manual/en/function.eval.php statement or script file. signature.asc Description: OpenPGP digital signature
RE: [PHP] Differences
Hi everyone, I have been playing around with some code the list helped me
with a while back and I'm not grasping the concept between return and echo
and the PHP manual doesn't answer this, unless I'm missing something. There
is an example at the very bottom of PHP's return manual, but it's
confusing.
So now I'm left wondering why return will only give me the first result in
an array, but echo will give me all the results of the array. Using stuart's
example he had sent me a while back I've messed around with it and modified
it to better understand it:
function filename($prefix)
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
return $filename;
}
}
echo completeImageFilename($row['MLS_No']);
With the above code I only get the first image of each picture name, but
when I change return to echo, it groups and displays all the pics that have
the same picture name.
--
David M.
The first loop and return is all you will get.
Put the information into an array and return the array once the array is
built.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences
Hi David,
A return statement will immediately halt execution of the current
function and return to where it was called.
In your case, the foreach loop will execute once and find a return
statement, and thus halting execution of the function and returning only
the first filename.
echo() is simply another function call (except it's a language construct
and not a function) and will not halt execution as return does.
What you want to do is something like:
$filenames = array();
foreach ($matches as $filename) {
$filenames[] = $filename;
}
return $filenames; // this is now an array containing all the filenames
But this is rather unneccesary, as $matches already is an array and
contains everything you need. Thus all you have to do is:
return $matches;
Which in turn can be shortened to:
function filename($prefix)
{
return glob('images/property_pics/'. $prefix .'*');
}
Happy Thursday!
Timmy
On 2012-10-04 02:48, David McGlone wrote:
Hi everyone, I have been playing around with some code the list helped me with
a while back and I'm not grasping the concept between return and echo and the
PHP manual doesn't answer this, unless I'm missing something. There is an
example at the very bottom of PHP's return manual, but it's confusing.
So now I'm left wondering why return will only give me the first result in an
array, but echo will give me all the results of the array. Using stuart's
example he had sent me a while back I've messed around with it and modified it
to better understand it:
function filename($prefix)
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
return $filename;
}
}
echo completeImageFilename($row['MLS_No']);
With the above code I only get the first image of each picture name, but when I
change return to echo, it groups and displays all the pics that have the same
picture name.
--
David M.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Differences
function filename($prefix)
{
$array_to_return = array();
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
$array_to_return[] = $filename;
}
return $array_to_return;
}
If this better explains it.
The first return will stop the process you need to put the information into
an array and then return the array outside of the foreach loop.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences
On Wednesday, October 03, 2012 08:55:29 PM admin wrote:
Hi everyone, I have been playing around with some code the list helped me
with a while back and I'm not grasping the concept between return and echo
and the PHP manual doesn't answer this, unless I'm missing something. There
is an example at the very bottom of PHP's return manual, but it's
confusing.
So now I'm left wondering why return will only give me the first result in
an array, but echo will give me all the results of the array. Using stuart's
example he had sent me a while back I've messed around with it and modified
it to better understand it:
function filename($prefix)
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
return $filename;
}
}
echo completeImageFilename($row['MLS_No']);
With the above code I only get the first image of each picture name, but
when I change return to echo, it groups and displays all the pics that have
the same picture name.
--
David M.
The first loop and return is all you will get.
Put the information into an array and return the array once the array is
built.
I think I understand what your saying, but what I don't understand is that
when I leave the current code intact and replace return $filename with echo
$filename in the function, all the images display. Is this intended behavior
between return and echo or is it just bad code on my part?
--
David M.
Re: [PHP] Differences
All of the images are displaying because you're simply instructing the function
to print out each file found with your call to glob(). The glob() function
returns an indexed array containing files found in the path you specified, or
an empty array if no files were found or false if glob() failed. When I say
print I'm referring to you using the echo language construct, however, print
is also another language construct.
Therefore using echo in your function allows the foreach loop to continue
iterating through the array of files returned by glob(). Replacing that echo
with the return, the function ones one iteration in the foreach loop and stops,
returning that value. In your case, the function is returning index 0 of the
array returned by glob().
Make more sense?
David McGlone da...@dmcentral.net wrote:
On Wednesday, October 03, 2012 08:55:29 PM admin wrote:
Hi everyone, I have been playing around with some code the list
helped me
with a while back and I'm not grasping the concept between return and
echo
and the PHP manual doesn't answer this, unless I'm missing something.
There
is an example at the very bottom of PHP's return manual, but it's
confusing.
So now I'm left wondering why return will only give me the first
result in
an array, but echo will give me all the results of the array. Using
stuart's
example he had sent me a while back I've messed around with it and
modified
it to better understand it:
function filename($prefix)
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
return $filename;
}
}
echo completeImageFilename($row['MLS_No']);
With the above code I only get the first image of each picture name,
but
when I change return to echo, it groups and displays all the pics
that have
the same picture name.
--
David M.
The first loop and return is all you will get.
Put the information into an array and return the array once the array
is
built.
I think I understand what your saying, but what I don't understand is
that
when I leave the current code intact and replace return $filename with
echo
$filename in the function, all the images display. Is this intended
behavior
between return and echo or is it just bad code on my part?
--
David M.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [PHP] Differences
On Thursday, October 04, 2012 03:01:12 AM Timmy Sjöstedt wrote:
Hi David,
A return statement will immediately halt execution of the current
function and return to where it was called.
In your case, the foreach loop will execute once and find a return
statement, and thus halting execution of the function and returning only
the first filename.
echo() is simply another function call (except it's a language construct
and not a function) and will not halt execution as return does.
That's what I was looking for.
What you want to do is something like:
$filenames = array();
foreach ($matches as $filename) {
$filenames[] = $filename;
}
return $filenames; // this is now an array containing all the filenames
I see where I wasn't thinking correctly. I thought that $filename had already
contained all the results.
But this is rather unneccesary, as $matches already is an array and
contains everything you need. Thus all you have to do is:
return $matches;
I had thought this also, and tried this but didn't get any results. probably
because I did something wrong somewhere else and didn't realize it.
Which in turn can be shortened to:
function filename($prefix)
{
return glob('images/property_pics/'. $prefix .'*');
}
I'll mess around with this and see what I can learn..
David M.
Happy Thursday!
Timmy
On 2012-10-04 02:48, David McGlone wrote:
Hi everyone, I have been playing around with some code the list helped me
with a while back and I'm not grasping the concept between return and
echo and the PHP manual doesn't answer this, unless I'm missing
something. There is an example at the very bottom of PHP's return manual,
but it's confusing.
So now I'm left wondering why return will only give me the first result in
an array, but echo will give me all the results of the array. Using
stuart's example he had sent me a while back I've messed around with it
and modified it to better understand it:
function filename($prefix)
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
return $filename;
}
}
echo completeImageFilename($row['MLS_No']);
With the above code I only get the first image of each picture name, but
when I change return to echo, it groups and displays all the pics that
have the same picture name.
--
David M.
--
David M.
Re: [PHP] Differences
On Wednesday, October 03, 2012 10:01:50 PM James wrote:
All of the images are displaying because you're simply instructing the
function to print out each file found with your call to glob(). The glob()
function returns an indexed array containing files found in the path you
specified, or an empty array if no files were found or false if glob()
failed. When I say print I'm referring to you using the echo language
construct, however, print is also another language construct.
Therefore using echo in your function allows the foreach loop to continue
iterating through the array of files returned by glob(). Replacing that
echo with the return, the function ones one iteration in the foreach loop
and stops, returning that value. In your case, the function is returning
index 0 of the array returned by glob().
Make more sense?
Absolutely. I also think I learned that return can also work like echo if the
code is written correctly.
David McGlone da...@dmcentral.net wrote:
On Wednesday, October 03, 2012 08:55:29 PM admin wrote:
Hi everyone, I have been playing around with some code the list
helped me
with a while back and I'm not grasping the concept between return and
echo
and the PHP manual doesn't answer this, unless I'm missing something.
There
is an example at the very bottom of PHP's return manual, but it's
confusing.
So now I'm left wondering why return will only give me the first
result in
an array, but echo will give me all the results of the array. Using
stuart's
example he had sent me a while back I've messed around with it and
modified
it to better understand it:
function filename($prefix)
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
return $filename;
}
}
echo completeImageFilename($row['MLS_No']);
With the above code I only get the first image of each picture name,
but
when I change return to echo, it groups and displays all the pics
that have
the same picture name.
--
David M.
The first loop and return is all you will get.
Put the information into an array and return the array once the array
is
built.
I think I understand what your saying, but what I don't understand is
that
when I leave the current code intact and replace return $filename with
echo
$filename in the function, all the images display. Is this intended
behavior
between return and echo or is it just bad code on my part?
David M.
--
David M.
Re: [PHP] Differences
On Wed, Oct 3, 2012 at 9:01 PM, James ja...@nixsecurity.org wrote:
All of the images are displaying because you're simply instructing the
function to print out each file found with your call to glob(). The glob()
function returns an indexed array containing files found in the path you
specified, or an empty array if no files were found or false if glob()
failed. When I say print I'm referring to you using the echo language
construct, however, print is also another language construct.
Therefore using echo in your function allows the foreach loop to continue
iterating through the array of files returned by glob(). Replacing that echo
with the return, the function ones one iteration in the foreach loop and
stops, returning that value. In your case, the function is returning index 0
of the array returned by glob().
Make more sense?
David McGlone da...@dmcentral.net wrote:
On Wednesday, October 03, 2012 08:55:29 PM admin wrote:
Hi everyone, I have been playing around with some code the list
helped me
with a while back and I'm not grasping the concept between return and
echo
and the PHP manual doesn't answer this, unless I'm missing something.
There
is an example at the very bottom of PHP's return manual, but it's
confusing.
So now I'm left wondering why return will only give me the first
result in
an array, but echo will give me all the results of the array. Using
stuart's
example he had sent me a while back I've messed around with it and
modified
it to better understand it:
function filename($prefix)
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
return $filename;
}
}
echo completeImageFilename($row['MLS_No']);
With the above code I only get the first image of each picture name,
but
when I change return to echo, it groups and displays all the pics
that have
the same picture name.
--
David M.
The first loop and return is all you will get.
Put the information into an array and return the array once the array
is
built.
I think I understand what your saying, but what I don't understand is
that
when I leave the current code intact and replace return $filename with
echo
$filename in the function, all the images display. Is this intended
behavior
between return and echo or is it just bad code on my part?
--
David M.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
echo and return are not analogous items at all in PHP. They don't do
the same thing because their purpose is to do two entirely different
things.
For purposes of this discussion, the important bit about return is here:
If called from within a function, the return statement immediately
ends execution of the current function, and returns its argument as
the value of the function call. [1]
The concept comes from making a call to a function and then returning
from it, where you will use the value that is returned.
echo, on the other hand, is about *displaying* values:
echo — Output one or more strings [2]
Let me try a bogus analogy:
A friend gives you a dollar to buy a soda from the machine. You take
the dollar, go over to the soda machine and get the soda.
In the case of return, you hand your friend the soda.
In the case of echo, you drink the soda.
Perhaps an example that is out of the context you are looking at might help:
Example 1:
==
function testreturn () {
for ($i = 0 ; $i 10 ; $i++ ) { // this will begin a loop where the
variable $i will start at value 0, and increase in value each time
through the loop by 1, stopping after $i is equal to 9.
return $1; // this will short circuit the loop and the enclosing
function, or the php script if called from the global context. In
other words, it *ends* the loop *and* function right there, sending
the value of $i (0 in this case) back to the calling function or
context.
}
}
Example 2:
=
function testecho () {
// Again, our for statement:
for ($i = 0 ; $i 10 ; $i++) {
echo $i; // this will emit the current value of $i to standard
output. when it is done, the loop continues
}
}
Here, there is no return from the function, nothing is passed back to
the calling function or context.
Let's take a look at your code again:
function completeImageFilename($prefix)
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
return $filename;
}
}
echo completeImageFilename($row['MLS_No']);
When your loop contains nothing but the return $filename, it doesn't
matter how many entries are in your array, you are telling the
function to return with the first one in the array, no matter what.
If you modify it thusly:
function completeImageFilename($prefix)
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
echo $filename; // here you are telling it to send the value of
$filename to standard output
}
// there is no return
Re: [PHP] Differences
On Wed, Oct 3, 2012 at 9:57 PM, David McGlone da...@dmcentral.net wrote: Absolutely. I also think I learned that return can also work like echo if the code is written correctly. No, no, no. Return does NOT do the same thing as echo, nor vice versa. If you do try to make things work this way you are doing things incorrectly. If you do try to make things work this way and it actually works, you have gotten lucky, but are still doing it incorrectly. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences
On Wed, Oct 3, 2012 at 10:03 PM, tamouse mailing lists
tamouse.li...@gmail.com wrote:
On Wed, Oct 3, 2012 at 9:57 PM, David McGlone da...@dmcentral.net wrote:
Absolutely. I also think I learned that return can also work like echo if the
code is written correctly.
No, no, no. Return does NOT do the same thing as echo, nor vice versa.
If you do try to make things work this way you are doing things
incorrectly. If you do try to make things work this way and it
actually works, you have gotten lucky, but are still doing it
incorrectly.
Let's try another example, based on your code:
Example 1: using return
===
function completeImageFilename($prefix) //correcting function name
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
return $filename;
}
}
echo This is the complete image file name:
.completeImageFilename($row['MLS_No']) . PHP_EOL;
You will get one line of output with the text from the echo statement
and the first filename that matches.
Example 2: using echo
=
function completeImageFilename($prefix) //correcting function name
{
$matches = glob('images/property_pics/'.$prefix.'*');
foreach($matches as $filename){
echo This is the file name from inside completeImageFilename: .
$filename . PHP_EOL;
}
}
echo This is the complete image file name:
.completeImageFilename($row['MLS_No']) . PHP_EOL;
You will get several lines of output for each filename that matches
with the text from the echo statement inside the function, then one
more line that will contain *just* the text from the final echo
statement:
This is the file name from inside completeImageFilename:
images/property_pics/151136.jpg
This is the file name from inside completeImageFilename:
images/property_pics/151137.jpg
This is the file name from inside completeImageFilename:
images/property_pics/151138.jpg
This is the file name from inside completeImageFilename:
images/property_pics/151139.jpg
This is the complete image file name:
(the file names are bogus and just made up by me to illustrate)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences
On 10/3/12 9:57 PM, David McGlone wrote:
Absolutely. I also think I learned that return can also work like echo if the
code is written correctly.
Echo and return are two completely different things in PHP. Echo is used
for printing a value out in a document -- for instance, as follows, in
the midst of a chunk of HTML:
table
trtdName:/tdtd?php echo $name; ?/tdtr
trtdEmail:/tdtd?php echo $email; ?/td/tr
/table
In the above example, echo is being used to output the value specified
in the variable $name or $email (which would have been previously set)
It can also be used to print the return value of a function. Return, in
and of itself, does not print anything; it is used to ascribe a
particular value to an instance of a function.
So for instance, if you have a function:
function getEmail() {
$name = 'johnsmith';
$email = $name . '@sample.com';
return $email;
}
then any called instance of the function getEmail() will, in a sense,
have the value of the return statement (in a sense, the code inside the
function runs and *returns* a value in place of itself).
So
$variable = getEmail();
//variable is now equal to 'johnsm...@sample.com'
You could then echo this value, if you wanted to.
echo getEmail(); //prints the value returned by getEmail()
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers
From: Matijn Woudt tijn...@gmail.commailto:tijn...@gmail.com Date: Wednesday, May 23, 2012 3:59 PM To: a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk Cc: Jeff Gates gat...@si.edumailto:gat...@si.edu, php-general@lists.php.netmailto:php-general@lists.php.net php-general@lists.php.netmailto:php-general@lists.php.net Subject: Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers On Wed, May 23, 2012 at 9:35 PM, Ashley Sheridan a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk wrote: On Wed, 2012-05-23 at 20:54 +0200, Matijn Woudt wrote: On Tue, May 22, 2012 at 8:15 PM, Gates, Jeff gat...@si.edumailto:gat...@si.edu wrote: Can anyone tell me what differences I might encounter by working with PHP on a Unix server verses working with PHP on a Windows server. We use Windows production servers here but many of us would like to get more LAMP environments. So, I'm wondering if I can use the hive mind here to get a sense of the pros and cons of each platform. Thanks. Jeff Apart from all other suggestions, one of the most common errors are because of different php.ini settings. If you can keep those settings (mostly) equal, there will not be that many errors. - Matijn I would say that's not limited to the distinction between Windows and Linux but any server. I've seen what appears to be an identical setup (same version of PHP, MySQL, etc) fail only because of a small setting in the php.ini file, just because the default was slightly different on the second system; both were running Linux. Yes, ofcourse, that comment was meant for any two systems. - Matijn Well, let me also add a related question: what types of problems might I encounter if I was trying to set up a Drupal or Wordpress instance on a Windows server running PHP as opposed to a Unix server? Jeff -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers
On Thu, May 31, 2012 at 3:29 PM, Gates, Jeff gat...@si.edu wrote: From: Matijn Woudt tijn...@gmail.commailto:tijn...@gmail.com Date: Wednesday, May 23, 2012 3:59 PM To: a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk Cc: Jeff Gates gat...@si.edumailto:gat...@si.edu, php-general@lists.php.netmailto:php-general@lists.php.net php-general@lists.php.netmailto:php-general@lists.php.net Subject: Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers On Wed, May 23, 2012 at 9:35 PM, Ashley Sheridan a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk wrote: On Wed, 2012-05-23 at 20:54 +0200, Matijn Woudt wrote: On Tue, May 22, 2012 at 8:15 PM, Gates, Jeff gat...@si.edumailto:gat...@si.edu wrote: Can anyone tell me what differences I might encounter by working with PHP on a Unix server verses working with PHP on a Windows server. We use Windows production servers here but many of us would like to get more LAMP environments. So, I'm wondering if I can use the hive mind here to get a sense of the pros and cons of each platform. Thanks. Jeff Apart from all other suggestions, one of the most common errors are because of different php.ini settings. If you can keep those settings (mostly) equal, there will not be that many errors. - Matijn I would say that's not limited to the distinction between Windows and Linux but any server. I've seen what appears to be an identical setup (same version of PHP, MySQL, etc) fail only because of a small setting in the php.ini file, just because the default was slightly different on the second system; both were running Linux. Yes, ofcourse, that comment was meant for any two systems. - Matijn Well, let me also add a related question: what types of problems might I encounter if I was trying to set up a Drupal or Wordpress instance on a Windows server running PHP as opposed to a Unix server? Jeff You might need to change a few basic configuration options (paths, database, etc) inside Drupal/Wordpress/.., but otherwise those are perfectly compatible on Windows Linux. - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers
On Thu, May 31, 2012 at 9:38 AM, Matijn Woudt tijn...@gmail.com wrote: On Thu, May 31, 2012 at 3:29 PM, Gates, Jeff gat...@si.edu wrote: From: Matijn Woudt tijn...@gmail.commailto:tijn...@gmail.com Date: Wednesday, May 23, 2012 3:59 PM To: a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk Cc: Jeff Gates gat...@si.edumailto:gat...@si.edu, php-general@lists.php.netmailto:php-general@lists.php.net php-general@lists.php.netmailto:php-general@lists.php.net Subject: Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers On Wed, May 23, 2012 at 9:35 PM, Ashley Sheridan a...@ashleysheridan.co.ukmailto:a...@ashleysheridan.co.uk wrote: On Wed, 2012-05-23 at 20:54 +0200, Matijn Woudt wrote: On Tue, May 22, 2012 at 8:15 PM, Gates, Jeff gat...@si.edumailto:gat...@si.edu wrote: Can anyone tell me what differences I might encounter by working with PHP on a Unix server verses working with PHP on a Windows server. We use Windows production servers here but many of us would like to get more LAMP environments. So, I'm wondering if I can use the hive mind here to get a sense of the pros and cons of each platform. Thanks. Jeff Apart from all other suggestions, one of the most common errors are because of different php.ini settings. If you can keep those settings (mostly) equal, there will not be that many errors. - Matijn I would say that's not limited to the distinction between Windows and Linux but any server. I've seen what appears to be an identical setup (same version of PHP, MySQL, etc) fail only because of a small setting in the php.ini file, just because the default was slightly different on the second system; both were running Linux. Yes, ofcourse, that comment was meant for any two systems. - Matijn Well, let me also add a related question: what types of problems might I encounter if I was trying to set up a Drupal or Wordpress instance on a Windows server running PHP as opposed to a Unix server? Jeff You might need to change a few basic configuration options (paths, database, etc) inside Drupal/Wordpress/.., but otherwise those are perfectly compatible on Windows Linux. - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Why not install virtualbox or something similar and install a flavor of linux and use that to do your dev on? It more closely mimics what will be the operating environment and would lead to less hassles -- Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers
On 22/05/2012 19:15, Gates, Jeff wrote: Can anyone tell me what differences I might encounter by working with PHP on a Unix server verses working with PHP on a Windows server. We use Windows production servers here but many of us would like to get more LAMP environments. So, I'm wondering if I can use the hive mind here to get a sense of the pros and cons of each platform. Thanks. Jeff In addition to Ashley's response, server variables can be populated with different values on PHP/Apache/Linux versus PHP/IIS/Windows. This can be a particular issue if you're writing 404 handlers or anything that relies on query strings. In particular you need to test and check for differences between Apache and IIS in how the REQUEST_URI, QUERY_STRING, URL, and ORIG_PATH_INFO variables are populated depending on whether your script is being called directly or as a 404 handler. When redirecting due to a 404 or some other redirect or error IIS will populate some variables with values like this /404.php?404;http://www.server.com:80/blah.php?v=1t=2; whereas Apache will populate the same variable with /blah.php?v=1t=2 in the same situation. This means the query string needs to be parsed differently. You need to test for your own usage scenarios. -- MarkR PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers
On 22/05/2012 19:32, Ashley Sheridan wrote: After that, you have file permissions. In Unix, you have file, owner and group permissions; Windows has read/write permissions and I believe on newer versions you can get something similar to what Unix/Linux has had for the last however many years but I'm not 100% sure on that one. Just to clarify on this point, Windows (or rather NTFS) permissions use full ACLs and so, for each file system object, any number of users and/or groups can have any number of allow or deny permissions assigned to them for a range of activities (e.g. read, write, append, delete, create, execute, traverse, read/write attributes, read/write permissions, etc.). There's a good article here that begins to explain it: 'Understanding Windows NTFS Permissions' http://www.windowsecurity.com/articles/Understanding-Windows-NTFS-Permissions.html NTFS ACLs are similar to (not not identical to) Posix Access Control Lists that are available for Linux and Unixes. -- MarkR PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers
On Tue, May 22, 2012 at 8:15 PM, Gates, Jeff gat...@si.edu wrote: Can anyone tell me what differences I might encounter by working with PHP on a Unix server verses working with PHP on a Windows server. We use Windows production servers here but many of us would like to get more LAMP environments. So, I'm wondering if I can use the hive mind here to get a sense of the pros and cons of each platform. Thanks. Jeff Apart from all other suggestions, one of the most common errors are because of different php.ini settings. If you can keep those settings (mostly) equal, there will not be that many errors. - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers
On Wed, 2012-05-23 at 20:54 +0200, Matijn Woudt wrote: On Tue, May 22, 2012 at 8:15 PM, Gates, Jeff gat...@si.edu wrote: Can anyone tell me what differences I might encounter by working with PHP on a Unix server verses working with PHP on a Windows server. We use Windows production servers here but many of us would like to get more LAMP environments. So, I'm wondering if I can use the hive mind here to get a sense of the pros and cons of each platform. Thanks. Jeff Apart from all other suggestions, one of the most common errors are because of different php.ini settings. If you can keep those settings (mostly) equal, there will not be that many errors. - Matijn I would say that's not limited to the distinction between Windows and Linux but any server. I've seen what appears to be an identical setup (same version of PHP, MySQL, etc) fail only because of a small setting in the php.ini file, just because the default was slightly different on the second system; both were running Linux. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers
On Wed, May 23, 2012 at 9:35 PM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: ** On Wed, 2012-05-23 at 20:54 +0200, Matijn Woudt wrote: On Tue, May 22, 2012 at 8:15 PM, Gates, Jeff gat...@si.edu wrote: Can anyone tell me what differences I might encounter by working with PHP on a Unix server verses working with PHP on a Windows server. We use Windows production servers here but many of us would like to get more LAMP environments. So, I'm wondering if I can use the hive mind here to get a sense of the pros and cons of each platform. Thanks. Jeff Apart from all other suggestions, one of the most common errors are because of different php.ini settings. If you can keep those settings (mostly) equal, there will not be that many errors. - Matijn I would say that's not limited to the distinction between Windows and Linux but any server. I've seen what appears to be an identical setup (same version of PHP, MySQL, etc) fail only because of a small setting in the php.ini file, just because the default was slightly different on the second system; both were running Linux. Yes, ofcourse, that comment was meant for any two systems. - Matijn
Re: [PHP] Differences between PHP on LAMP and PHP on Windows Servers
On Tue, 2012-05-22 at 14:15 -0400, Gates, Jeff wrote: Can anyone tell me what differences I might encounter by working with PHP on a Unix server verses working with PHP on a Windows server. We use Windows production servers here but many of us would like to get more LAMP environments. So, I'm wondering if I can use the hive mind here to get a sense of the pros and cons of each platform. Thanks. Jeff The first difference I'd point out is things like filenames and paths. *nix systems are case sensitive, so script.php and Script.php are two totally different files which can happily exist within the same directory, whereas on a Windows system this isn't true. This can affect anything from front-end assets (images, CSS, Javascript files, etc) to PHP includes and even MySQL tables depending on how the database is configured (it tends to create database files based on the name of the DB and it's tables) Also, the path separator is different. Unix/Linux uses a forward slash and Windows uses a back-slash. While these can be interchanged quite often without the world imploding, sometimes they just refuse to, so it's best to ensure you're using the right one for the script. PHP has several constants defined to help you which change depending on the system PHP is currently being run on, you can find out more about them at http://php.net/manual/en/dir.constants.php After that, you have file permissions. In Unix, you have file, owner and group permissions; Windows has read/write permissions and I believe on newer versions you can get something similar to what Unix/Linux has had for the last however many years but I'm not 100% sure on that one. There are differences with setting up PHP to send emails. On Windows I believe you have to use SMTP, but on Linux you tend to use the internal sendmail with the choice of SMTP if you wish. In the main, I'd say that you want your production servers to mirror the live ones as closely as possible. There have been plenty of times where I've moved a script to a different machine and things have stopped working because of a different version of PHP or MySQL was installed, and you run the risk further if the OS is different too. When you're on a deadline, the last thing you want is to have to debug something that you know works just fine! -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] differences in between these env. variables
On Jan 29, 2012, at 7:01 PM, Adam Richardson wrote: On Sun, Jan 29, 2012 at 11:38 AM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Jan 27, 2012, at 12:45 PM, Adam Richardson wrote: On Fri, Jan 27, 2012 at 12:09 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote: Is there ever a case where SCRIPT_NAME does not equal PHP_SELF? Was this every answered? I would like to know. Cheers, tedd Yep, can be different: http://stackoverflow.com/questions/279966/php-self-vs-path-info-vs-script-name-vs-request-uri Adam I should have been more clear -- I understand: [PHP_SELF] = /test.php/foo/bar [SCRIPT_NAME] = /test.php/ by practice is different. I should have used basename() in my question. The main point I was trying to get was which one is more secure and not subject to cross-site scripting or other such security issues? IOW, if you had to bet your life on it, which would be most secure in reporting an accurate basename()? That's an interesting question. Because $_SERVER['SCRIPT_NAME'] doesn't include path info appended to the get request, it greatly limits the attack surface, so I try to use it when I can. However, there are times when you want the ability to pass in additional path info (e.g., pretty urls), and that makes $_SERVER['PHP_SELF'] quite useful. In terms of securely using $_SERVER['PHP_SELF'], the one thing I don't ever recommend is trying to sanitize input (this view is in stark contrast to some of the resources online that detail how to safely use $_SERVER['PHP_SELF'] through a combination of techniques including sanitization.) I suggest that any time script receives that doesn't meet its expectations, the script should throw away the data and kindly communicate to the user that they'll have to try the request again with valid data. To use $_SERVER['PHP_SELF'] safely, the most important thing is context. In order for an XSS attack to succeed, it has to sneak in data that is structurally meaningful in the context of its use. If the web page outputs $_SERVER['PHP_SELF'] in an href such as the one below, then a double quote (or any of its possible encodings which buggily sneak through older browsers, but modern browsers seem to have corrected many of these issues) must be escaped: // if a double quote comes through PHP_SELF here and is not escaped, we're in trouble // https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes a href=?php echo $_SERVER['PHP_SELF']; ?Link back to this page/a So, in the above case, I would first filter the PHP_SELF value through a regex that establishes a whitelist of valid values and/or characters (if you know all the possible paths of your app ahead of time, make sure there's a match; if you know that the path info only includes letters a-z, make sure there are they are the only characters you allow; etc.), and then for valid input, escape the output using htmlspeciachars(). NOTE: Developers who fail don't use quotes on attributes would have to be much more careful and escape several other characters in the above example. That all said, if PHP_SELF was being echoed out into a script tag, the above technique would be insufficient to protect against XSS, as the content of the script tag has many more structurally meaningful characters that have to be watched for and escaped. So, it really varies by the context of use. I'd use SCRIPT_NAME where I don't need the path info (but I'd still likely whitelist it's possible values and escape it's output.) And, if I needed the path info, I'd whitelist the possible PHP_SELF values and then escape the output according to the context. That all said, if my life depended on security of the app, I'd probably be very slow to put up any web pages, as the amount of testing and auditing I'd want to perform would be on the scale of years ;) Adam Adam: Thank you for your most thoughtful answer -- it was very informative. I won't be using echo $_SERVER['PHP_SELF']; for any forms or links. Cheers, tedd. _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] differences in between these env. variables
On Jan 27, 2012, at 12:45 PM, Adam Richardson wrote: On Fri, Jan 27, 2012 at 12:09 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote: Is there ever a case where SCRIPT_NAME does not equal PHP_SELF? Was this every answered? I would like to know. Cheers, tedd Yep, can be different: http://stackoverflow.com/questions/279966/php-self-vs-path-info-vs-script-name-vs-request-uri Adam I should have been more clear -- I understand: [PHP_SELF] = /test.php/foo/bar [SCRIPT_NAME] = /test.php/ by practice is different. I should have used basename() in my question. The main point I was trying to get was which one is more secure and not subject to cross-site scripting or other such security issues? IOW, if you had to bet your life on it, which would be most secure in reporting an accurate basename()? Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] differences in between these env. variables
On Sun, Jan 29, 2012 at 5:38 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Jan 27, 2012, at 12:45 PM, Adam Richardson wrote: On Fri, Jan 27, 2012 at 12:09 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote: Is there ever a case where SCRIPT_NAME does not equal PHP_SELF? Was this every answered? I would like to know. Cheers, tedd Yep, can be different: http://stackoverflow.com/questions/279966/php-self-vs-path-info-vs-script-name-vs-request-uri Adam I should have been more clear -- I understand: [PHP_SELF] = /test.php/foo/bar [SCRIPT_NAME] = /test.php/ by practice is different. I should have used basename() in my question. The main point I was trying to get was which one is more secure and not subject to cross-site scripting or other such security issues? IOW, if you had to bet your life on it, which would be most secure in reporting an accurate basename()? Cheers, tedd I don't think basename() makes much sense here, does it? basename($_SERVER['PHP_SELF']) would give bar on your first example. To answer your question about XSS or other security issues, it all depends on how you use the info afterwards. - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] differences in between these env. variables
On Sun, Jan 29, 2012 at 11:38 AM, Tedd Sperling tedd.sperl...@gmail.comwrote: On Jan 27, 2012, at 12:45 PM, Adam Richardson wrote: On Fri, Jan 27, 2012 at 12:09 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote: Is there ever a case where SCRIPT_NAME does not equal PHP_SELF? Was this every answered? I would like to know. Cheers, tedd Yep, can be different: http://stackoverflow.com/questions/279966/php-self-vs-path-info-vs-script-name-vs-request-uri Adam I should have been more clear -- I understand: [PHP_SELF] = /test.php/foo/bar [SCRIPT_NAME] = /test.php/ by practice is different. I should have used basename() in my question. The main point I was trying to get was which one is more secure and not subject to cross-site scripting or other such security issues? IOW, if you had to bet your life on it, which would be most secure in reporting an accurate basename()? That's an interesting question. Because $_SERVER['SCRIPT_NAME'] doesn't include path info appended to the get request, it greatly limits the attack surface, so I try to use it when I can. However, there are times when you want the ability to pass in additional path info (e.g., pretty urls), and that makes $_SERVER['PHP_SELF'] quite useful. In terms of securely using $_SERVER['PHP_SELF'], the one thing I don't ever recommend is trying to sanitize input (this view is in stark contrast to some of the resources online that detail how to safely use $_SERVER['PHP_SELF'] through a combination of techniques including sanitization.) I suggest that any time script receives that doesn't meet its expectations, the script should throw away the data and kindly communicate to the user that they'll have to try the request again with valid data. To use $_SERVER['PHP_SELF'] safely, the most important thing is context. In order for an XSS attack to succeed, it has to sneak in data that is structurally meaningful in the context of its use. If the web page outputs $_SERVER['PHP_SELF'] in an href such as the one below, then a double quote (or any of its possible encodings which buggily sneak through older browsers, but modern browsers seem to have corrected many of these issues) must be escaped: // if a double quote comes through PHP_SELF here and is not escaped, we're in trouble // https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes a href=?php echo $_SERVER['PHP_SELF']; ?Link back to this page/a So, in the above case, I would first filter the PHP_SELF value through a regex that establishes a whitelist of valid values and/or characters (if you know all the possible paths of your app ahead of time, make sure there's a match; if you know that the path info only includes letters a-z, make sure there are they are the only characters you allow; etc.), and then for valid input, escape the output using htmlspeciachars(). NOTE: Developers who fail don't use quotes on attributes would have to be much more careful and escape several other characters in the above example. That all said, if PHP_SELF was being echoed out into a script tag, the above technique would be insufficient to protect against XSS, as the content of the script tag has many more structurally meaningful characters that have to be watched for and escaped. So, it really varies by the context of use. I'd use SCRIPT_NAME where I don't need the path info (but I'd still likely whitelist it's possible values and escape it's output.) And, if I needed the path info, I'd whitelist the possible PHP_SELF values and then escape the output according to the context. That all said, if my life depended on security of the app, I'd probably be very slow to put up any web pages, as the amount of testing and auditing I'd want to perform would be on the scale of years ;) Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] differences in between these env. variables
On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote: Is there ever a case where SCRIPT_NAME does not equal PHP_SELF? Was this every answered? I would like to know. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] differences in between these env. variables
On Fri, Jan 27, 2012 at 6:09 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote: Is there ever a case where SCRIPT_NAME does not equal PHP_SELF? Was this every answered? I would like to know. Cheers, tedd I don't think it was answered, but I'll answer now. Yes, there is a difference. At [1] you'll find a script that prints both SCRIPT_NAME and PHP_SELF. For most of the time, the output will be the same. But now, try the url at [2], and you'll see that it returns /dev/test/envvars.php for SCRIPT_NAME, and /dev/test/envvars.php/a/b/c for PHP_SELF. I hope this clears things up a bit. - Matijn [1] http://tijnema.myftp.org/dev/test/envvars.php [2] http://tijnema.myftp.org/dev/test/envvars.php/a/b/c -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] differences in between these env. variables
-Original Message- From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] Sent: Friday, January 27, 2012 12:09 PM To: php-general. List Subject: Re: [PHP] differences in between these env. variables On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote: Is there ever a case where SCRIPT_NAME does not equal PHP_SELF? Was this every answered? I would like to know. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Ted I show on the 11 Jan there was 2 answers. I'll extend your example. We now have a RewriteRule in apache like this: RewriteRule ^files/?$ /directory/file.php [L,QSA] Which will rewrite /files/... -- /directory/file.php REQUEST_URI now contains how it was called by the browser, '/files/something.php' SCRIPT_NAME returns path to script (/directory/file.php), set by the SAPI (apache, ..). PHP_SELF returns also the path to script (/directory/file.php), but set by PHP self. I don't have any ORIG_PATH_INFO on my Ubuntu box, so be careful about this one. Recommended: Depends on which you need. I prefer PHP_SELF over SCRIPT_NAME, but that's more personal choice. Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] differences in between these env. variables
On Fri, Jan 27, 2012 at 12:09 PM, Tedd Sperling tedd.sperl...@gmail.comwrote: On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote: Is there ever a case where SCRIPT_NAME does not equal PHP_SELF? Was this every answered? I would like to know. Cheers, tedd Yep, can be different: http://stackoverflow.com/questions/279966/php-self-vs-path-info-vs-script-name-vs-request-uri Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] differences in between these env. variables
On Thu, Jan 12, 2012 at 12:26 AM, Haluk Karamete halukkaram...@gmail.com wrote: I've grouped these env variables, each group returns the same values is there a difference? which ones do you use? which ones should I not use for the purposes listed below You can find the answers here: http://nl3.php.net/manual/en/reserved.variables.server.php I'll try to answer them in short group1 SCRIPT_FILENAME vs PATH_TRANSLATED where both return D:\Hosting\5291100\html\directory\file.php purpose: get the full file path to the php script SCRIPT_FILENAME can be a relative path, PATH_TRANSLATED is the full path. This is only true if run from CLI. On my Ubuntu box I don't even have PATH_TRANSLATED, so SCRIPT_FILENAME is recommended. group2 REMOTE_ADDR vs REMOTE_HOST where both return same IP purpose: get the visitor's ip REMOTE_HOST is not necessary always IP, if PHP succeeds to do a reverse lookup (ie. get name for this ip), than REMOTE_HOST contains a name instead of ip. You need to set a config option for this, though. Recommended: REMOTE_ADDR, it matches what you need, doesn't need config, and REMOTE_HOST doesn't even work for all hosts. group3 REQUEST_URI vs SCRIPT_NAME vs URL vs ORIG_PATH_INFO vs PHP_SELF which all return /directory/file.php purpose: get the virtual url to the php script I'll extend your example. We now have a RewriteRule in apache like this: RewriteRule ^files/?$ /directory/file.php [L,QSA] Which will rewrite /files/... -- /directory/file.php REQUEST_URI now contains how it was called by the browser, '/files/something.php' SCRIPT_NAME returns path to script (/directory/file.php), set by the SAPI (apache, ..). PHP_SELF returns also the path to script (/directory/file.php), but set by PHP self. I don't have any ORIG_PATH_INFO on my Ubuntu box, so be careful about this one. Recommended: Depends on which you need. I prefer PHP_SELF over SCRIPT_NAME, but that's more personal choice. Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] differences in between these env. variables
On Wed, Jan 11, 2012 at 5:49 PM, Matijn Woudt tijn...@gmail.com wrote: On Thu, Jan 12, 2012 at 12:26 AM, Haluk Karamete halukkaram...@gmail.com wrote: I've grouped these env variables, each group returns the same values is there a difference? which ones do you use? which ones should I not use for the purposes listed below You can find the answers here: http://nl3.php.net/manual/en/reserved.variables.server.php I'll try to answer them in short group1 SCRIPT_FILENAME vs PATH_TRANSLATED where both return D:\Hosting\5291100\html\directory\file.php purpose: get the full file path to the php script SCRIPT_FILENAME can be a relative path, PATH_TRANSLATED is the full path. This is only true if run from CLI. On my Ubuntu box I don't even have PATH_TRANSLATED, so SCRIPT_FILENAME is recommended. group2 REMOTE_ADDR vs REMOTE_HOST where both return same IP purpose: get the visitor's ip REMOTE_HOST is not necessary always IP, if PHP succeeds to do a reverse lookup (ie. get name for this ip), than REMOTE_HOST contains a name instead of ip. You need to set a config option for this, though. Recommended: REMOTE_ADDR, it matches what you need, doesn't need config, and REMOTE_HOST doesn't even work for all hosts. group3 REQUEST_URI vs SCRIPT_NAME vs URL vs ORIG_PATH_INFO vs PHP_SELF which all return /directory/file.php purpose: get the virtual url to the php script I'll extend your example. We now have a RewriteRule in apache like this: RewriteRule ^files/?$ /directory/file.php [L,QSA] Which will rewrite /files/... -- /directory/file.php REQUEST_URI now contains how it was called by the browser, '/files/something.php' SCRIPT_NAME returns path to script (/directory/file.php), set by the SAPI (apache, ..). PHP_SELF returns also the path to script (/directory/file.php), but set by PHP self. I don't have any ORIG_PATH_INFO on my Ubuntu box, so be careful about this one. Recommended: Depends on which you need. I prefer PHP_SELF over SCRIPT_NAME, but that's more personal choice. Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Is there ever a case where SCRIPT_NAME does not equal PHP_SELF? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences with imap_headerinfo() between PHP 4.3.11 and 4.4.0?
Richard Lynch [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Wrapping ob_start() / ob_get_contents() / ob_end_clean() around the IMAP calls MIGHT let you catch the output and throw it away... That is a good idea, I will give that a shot. Thanks, Mike -- Mike Walsh - mike_walsh at mindspring.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences with imap_headerinfo() between PHP 4.3.11 and 4.4.0?
Wrapping ob_start() / ob_get_contents() / ob_end_clean() around the IMAP calls MIGHT let you catch the output and throw it away... On Mon, August 15, 2005 11:07 am, Mike Walsh wrote: I have an application which uses imap_headerinfo() to query an NNTP server and display some information as part of a web application. I am seeing a difference between 4.3.11 and 4.4.0 when the e-mail address in the article contains a spam block. I get the following notice: Notice: (null)(): Unterminated mailbox: [EMAIL PROTECTED] (errflg=3) in Unknown on line 0 Notice: (null)(): Must use comma to separate addresses: somedomain(dot.dot)com (errflg=3) in Unknown on line 0 I am unable to suppress the notice either with error_reporting() or the @ operator. Anyone else seeing anything similar? Any idea how to suppress the Notice? The oddly formed e-mail address isn't something I use so I don't really care how it is formatted but the IMAP library seems care enough to generate the notices. Thanks, Mike -- Mike Walsh - mike_walsh at mindspring dot com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences in arrays
How about:
if ( is_array($_SESSION['schools'] ) ) {
foreach($_SESSION['schools'] as $h) {
If($h!=){ //First added line
$query = INSERT INTO Prof_Schools (ProfID, School)
VALUES ('$LID', '$h');
$res6 = run_query($query);
echo $query;
} //End added line
}
}
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences in arrays
--- Mike Smith [EMAIL PROTECTED] wrote:
How about:
if ( is_array($_SESSION['schools'] ) ) {
foreach($_SESSION['schools'] as $h) {
If($h!=){ //First added line
$query = INSERT INTO Prof_Schools (ProfID, School)
VALUES ('$LID', '$h');
$res6 = run_query($query);
echo $query;
} //End added line
}
}
Yes, I did that and it works correctly now. I was
tryin g to better understand why the difference in the
behaviour.
Stuart
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences in arrays
Yes, I did that and it works correctly now. I was tryin g to better understand why the difference in the behaviour. Stuart The first array is created by selecting individual elements from a muli-select list (My multi-select is a little hazy, but I think it's something like...) select multiple optionOne/option (Selected) optionTwo/option optionThree/option (Selected) optionFour/option /select ...would create a 2 element array. The second array is created by the rendered objects. I'm guessing you created text fields like: input type=text name=schools[] input type=text name=schools[] input type=text name=schools[] ...That creates an array with 3 values, empty until the user types something, upon POST (or GET) of the form. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Differences in arrays
To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm On 02 December 2004 10:26, Stuart Felenstein wrote: I have arrays set up in a user form. One type is from a multi-select list. [] I have 3 textfield elements all named school[] [] 2- Why would the second array behave differently then the first ? Because you're using different input types. A multi-select list sends exactly one value (array element) for each value selected, so you will always get exactly the same number of array elements as there were items selected (including possibly none). Each text element sends its value (hence an array element) unconditionally, because each is treated separately -- there's no grouping of like-named boxes for textboxes like there is for radio buttons. This means you'll always see 3 school[] elements, even if some are empty. Note that this makes it possible for (say) boxes 1 and 2 to be empty, but box 3 contain a value, or boxes 1 and 3 to contain values but box 3 be empty -- you may need to adjust your code to allow for this! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences in arrays
1-I guess I need a way to make sure in the foreach that when the first empty element is reached the loop dies. Just to be sure you understand: You should really not die when you hit a blank. You should just SKIP it and process the rest. A user *might* choose to fill in the first and third text box INPUTs, and #2 would be blank. But they'd (rightly) expect you to process #3. 2- Why would the second array behave differently then the first ? It's not you. It's the way HTTP protocol was set up, not really planning for complicated forms with arrays and such-like. PHP using arrays (and other languages doing what they do) are mostly work-arounds of the short-comings of the HTTP protocol. It would be nice if the HTTP protocol had planned this out a bit better, and INPUT, SELECT MUTIPLE, CHECKBOX, and RADIO all behaved in a more rational/similar manner. OTOH, if you make them too much the same, you'd probably end up having to do more work for the simple forms. So it goes. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between echoing the output gradually or returning it.
Eduard Duran i Rosich wrote: Hi, I just wanted to know what are the main pros and cons between echoing the output some PHP script as it process the data and returning the whole output to echo it at once. I find the second way to be useful when I want to add a header() line without concerning former output. However, is that way slower or has any other inconvenience? If you decide to output everything at the end, it will seem that there is no responce from the server for pages that take longer to build. Some impatient visitors will try refresh buttons, thus adding more load to the server. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between echoing the output gradually or returning it.
On Wed, 22 Sep 2004 22:10:07 +, Eduard Duran i Rosich [EMAIL PROTECTED] wrote: I just wanted to know what are the main pros and cons between echoing the output some PHP script as it process the data and returning the whole output to echo it at once. I find the second way to be useful when I want to add a header() line without concerning former output. However, is that way slower or has any other inconvenience? I always build up the HTML and output it at the end. That way I can optimize it, removing all the line breaks and tabs. I always use output compression so it helps two-fold. Of course I can't do that in every situation, it messes with line breaks in textarea fields for instance. There are two buffering mechanisms at work when you make a page request. The web server sending the data and the web client receiving the data. You can control the former to some extent with PHP's output buffering functions. I have always found it problematic at best to try and control the web client's internal buffering. In addition, if you output a table tag, some browsers will not render the table or the entire page until the closing /table is received. Which way is faster depends on what the script does more than how you output it. Try it both ways, bench it, and then you'll know for sure. -- Greg Donald http://gdconsultants.com/ http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between echoing the output gradually or returning it.
* Thus wrote Marek Kilimajer: Eduard Duran i Rosich wrote: Hi, I just wanted to know what are the main pros and cons between echoing the output some PHP script as it process the data and returning the whole output to echo it at once. I find the second way to be useful when I want to add a header() line without concerning former output. However, is that way slower or has any other inconvenience? If you decide to output everything at the end, it will seem that there is no responce from the server for pages that take longer to build. Some impatient visitors will try refresh buttons, thus adding more load to the server. To add to this, there is also memory usage. If you build up your output in a buffer before sending it you are basically doubling the required memory needed to send the output. My philosophy is to send the data as soon as possible with as little memory consumed, a general layout of script i'll create is something like: ?php // authenticate if needed // redirect if needed // determain simple information like, title of page, etc. /* the above stuff shouldn't take any significant amount of time */ ? !DOCTYPE... html head title?php echo $page_title?/title ... div id=leftnav ?php // generate left nav ? /div div id=content ?php // generate content ? /div ?php // any stuff to be done here ? imo, If your logic requires you to redirect at the end of generating a page, your logic needs to be reworked. Curt -- The above comments may offend you. flame at will. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences in old php/apach. to new php/apach. cookie process?
Sorry, but this problem hasn´t been solved yet, It drives me crazy. At 12.04.2002 17:41, I wrote: Hi Folks, Does anybody know if there are differences in cookieprocessing between A.Suse 2.2.14-SMP/apache 1.3.12 / PHP 3.0.16 and B.Suse 2.4.9 /apache 1.3.20 / PHP 4.0.6 I have moved working pages from A to B, and now (Win)Opera 6.01 will not accept cookies from the, formerly working, pages. I have CookieTracking on on both machines. The apache-cookie is sent and set from both machines. But my php-routines (which sends the fitting cookie to the dif. browsers) work different. Someone had same problems? Maybe I forgot something in httpd.conf on B ? Any suggestions? TIA Oliver -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences in old php/apach. to new php/apach. cookieprocess?
Um, have you search the manual at all I did two quick searches, and found some good hints... it may not be your problem, but, it's a good starting point, before asking questions. I started with setcookie(): In PHP 3, multiple calls to setcookie() in the same script will be performed in reverse order. If you are trying todelete one cookie before inserting another you should put the insert before the delete. In PHP 4, multiple calls to setcookie() are performed in the order called. http://www.php.net/manual/en/function.setcookie.php I also did a search on the manual for cookies and the first result was a page discussing the migration of php3 php4, in specific, how cookies work differently. http://www.php.net/manual/ro/migration4.cookies.php Wow! Isn't the manual a wonderful resource :P Justin French Creative Director http://Indent.com.au on 14/04/02 6:54 PM, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: Sorry, but this problem hasn´t been solved yet, It drives me crazy. At 12.04.2002 17:41, I wrote: Hi Folks, Does anybody know if there are differences in cookieprocessing between A.Suse 2.2.14-SMP/apache 1.3.12 / PHP 3.0.16 and B.Suse 2.4.9 /apache 1.3.20 / PHP 4.0.6 I have moved working pages from A to B, and now (Win)Opera 6.01 will not accept cookies from the, formerly working, pages. I have CookieTracking on on both machines. The apache-cookie is sent and set from both machines. But my php-routines (which sends the fitting cookie to the dif. browsers) work different. Someone had same problems? Maybe I forgot something in httpd.conf on B ? Any suggestions? TIA Oliver -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP, ASP, JSP
On Wednesday, February 6, 2002, at 10:14 PM, Ben Clumeck wrote: I know there must be a tone of articles on the subject. Can anyone give me brief advantages and disadvantages between the 3 languages. Is there something that one language specifically does that another doesn't? Could PHP be used for online banking? Usually banks use JSP or ASP, why don't banks use PHP? Is there security issues? Because they're fools. I admit to being biased. Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP, ASP, JSP
Tyler Longren wrote: PHP could be used for online banking. Banks use ASP because there is software already written in ASP for what they need. If that were the case it wouldn't take months of time with dozens of people working on projects to get the barely functional. The software banks use at the ASP level is almost always going to be custom written for them inhouse or outsourced. There aren't standard ASP banking packages. The software on the backend to connect to their legacy systems, perhaps, but there's still going to be much custom integration work. There's no real major time savings between an ASP-proficient person developing a project and a PHP-proficient person developing a project. Also, they use it because it's from Microsoft. Getting warmer. :) Generally, in larger institutions, the people making the technology decisions aren't the same people who have to implement them, so whether or not it's better to use CF or PHP or JSP or ASP, they simply go 'MS' because of the name recognition. I'm not completely discounting issues of inhouse talent, legacy integration issues, etc., but at the end of the day, PHP, ASP, CF, JSP, Perl and others do a couple things: 1. Take information from a browser 2. Process it - usually with database calls 3. Present other information back To say that one technology is vastly superior to another is just silly. Some have neat hooks/shortcuts, some are faster at execution, some are better with memory, some have price benefits, but there's nothing from the list above that you can do with one that you can't do with another. Michael Kimsal http://www.tapinternet.com/php PHP Training Courses -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Differences between PHP, ASP, JSP
PHP could be used for online banking. Banks use ASP because there is software already written in ASP for what they need. Also, they use it because it's from Microsoft. Tyler - Original Message - From: Ben Clumeck [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 06, 2002 9:14 PM Subject: [PHP] Differences between PHP, ASP, JSP I know there must be a tone of articles on the subject. Can anyone give me brief advantages and disadvantages between the 3 languages. Is there something that one language specifically does that another doesn't? Could PHP be used for online banking? Usually banks use JSP or ASP, why don't banks use PHP? Is there security issues? Thanks, Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
