Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #17249 > unrolled thread

Problem validating user and hashed value in db

Back to article view | Back to comp.lang.php

Contents

  Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-10 12:46 -0800
    Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-10 22:39 -0500
      Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-10 19:51 -0800
        Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-10 23:28 -0500
          Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-10 22:32 -0800
            Re: Problem validating user and hashed value in db "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-11 12:47 +0100
              Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-11 09:07 -0500
                Re: Problem validating user and hashed value in db "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-11 15:37 +0100
                  Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-11 15:40 -0500
                  Re: Problem validating user and hashed value in db Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-11 23:18 +0100
                    Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-12 07:32 -0800
                      Re: Problem validating user and hashed value in db "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-12 17:23 +0100
                        Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-12 10:18 -0800
                          Re: Problem validating user and hashed value in db "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-12 19:36 +0100
                            Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-12 11:12 -0800
                              Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-12 12:05 -0800
                                Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-12 15:20 -0500
                                  Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-12 13:51 -0800
                                    Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-12 17:00 -0500
                                  Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-12 13:53 -0800
                                    Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-12 17:02 -0500
                                      Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-13 07:16 -0800
                                        Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-13 10:39 -0500
                                          Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-13 09:06 -0800
                                            Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-13 12:58 -0500
                                              Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-13 10:30 -0800
                                                Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-13 13:57 -0500
                                                  Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-13 13:29 -0800
                                                    Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-13 16:57 -0500
                                                      Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-13 14:23 -0800
                                                        Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-14 13:03 -0500
                                                Re: Problem validating user and hashed value in db "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-13 20:02 +0100
                                                  Re: Problem validating user and hashed value in db Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-13 21:35 +0100
                                                    Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-13 16:24 -0500
                                                      Re: Problem validating user and hashed value in db Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 02:37 +0000
                                                        Re: Problem validating user and hashed value in db wart2ww <fcc@bmi.net> - 2017-01-13 19:20 -0800
                                                        Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-14 12:57 -0500
                                                        Re: Problem validating user and hashed value in db Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-14 19:47 +0100
                                                          Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-14 14:00 -0500
                            Re: Problem validating user and hashed value in db Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-13 16:27 +0100
                              Re: Problem validating user and hashed value in db "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-13 16:39 +0100
            Re: Problem validating user and hashed value in db Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-11 09:22 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#17273

On 1/12/2017 4:53 PM, wart2ww wrote:
> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
>> On 1/12/2017 3:05 PM, wart2ww wrote:
>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
>>>
>>> For clarification, I am not outputting any html to the page before the header.
>>>
>>
>> You don't have to be outputting any HTML before the header - ANYTHING,
>> including a simple space, output before the header call will cause this
>> message.  It includes the output from print_r() or var_dump(), and that
>> is expected when you're debugging.
>>
>> Look for other errors in the log.  There probably is at least one before
>> this one.
>>
> 
> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
> 

No problem, we do our best to help those who are trying to help
themselves.

Doing your homework for you is another story, though :).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17274

On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
> On 1/12/2017 4:53 PM, wart2ww wrote:
> > On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
> >> On 1/12/2017 3:05 PM, wart2ww wrote:
> >>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
> >>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
> >>>
> >>> For clarification, I am not outputting any html to the page before the header.
> >>>
> >>
> >> You don't have to be outputting any HTML before the header - ANYTHING,
> >> including a simple space, output before the header call will cause this
> >> message.  It includes the output from print_r() or var_dump(), and that
> >> is expected when you're debugging.
> >>
> >> Look for other errors in the log.  There probably is at least one before
> >> this one.
> >>
> > 
> > I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
> > 
> 
> No problem, we do our best to help those who are trying to help
> themselves.
> 
> Doing your homework for you is another story, though :).
> 
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:

echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...

Thanks for your help and have a great New Year.

[toc] | [prev] | [next] | [standalone]

#17277

On 1/13/2017 10:16 AM, wart2ww wrote:
> On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
>> On 1/12/2017 4:53 PM, wart2ww wrote:
>>> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
>>>> On 1/12/2017 3:05 PM, wart2ww wrote:
>>>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
>>>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
>>>>>
>>>>> For clarification, I am not outputting any html to the page before the header.
>>>>>
>>>>
>>>> You don't have to be outputting any HTML before the header - ANYTHING,
>>>> including a simple space, output before the header call will cause this
>>>> message.  It includes the output from print_r() or var_dump(), and that
>>>> is expected when you're debugging.
>>>>
>>>> Look for other errors in the log.  There probably is at least one before
>>>> this one.
>>>>
>>>
>>> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
>>>
>>
>> No problem, we do our best to help those who are trying to help
>> themselves.
>>
>> Doing your homework for you is another story, though :).
>>
>> -- 
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> jstucklex@attglobal.net
>> ==================
> 
> I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:
> 
> echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...
> 
> Thanks for your help and have a great New Year.
> 

That's a meta redirect, which works, although in a different way.
header() works fine - I use it all the time.  You just have to ensure
you output NOTHING - NOT EVEN WHITE SPACE - before the call to header().

For instance - even a blank line at the top of your script will output a
newline character.  The first characters in your script MUST be <?PHP
and you can't use UTF-8 or any other charset which has a BOM.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17278

On Friday, January 13, 2017 at 7:39:23 AM UTC-8, Jerry Stuckle wrote:
> On 1/13/2017 10:16 AM, wart2ww wrote:
> > On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
> >> On 1/12/2017 4:53 PM, wart2ww wrote:
> >>> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
> >>>> On 1/12/2017 3:05 PM, wart2ww wrote:
> >>>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
> >>>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
> >>>>>
> >>>>> For clarification, I am not outputting any html to the page before the header.
> >>>>>
> >>>>
> >>>> You don't have to be outputting any HTML before the header - ANYTHING,
> >>>> including a simple space, output before the header call will cause this
> >>>> message.  It includes the output from print_r() or var_dump(), and that
> >>>> is expected when you're debugging.
> >>>>
> >>>> Look for other errors in the log.  There probably is at least one before
> >>>> this one.
> >>>>
> >>>
> >>> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
> >>>
> >>
> >> No problem, we do our best to help those who are trying to help
> >> themselves.
> >>
> >> Doing your homework for you is another story, though :).
> >>
> >> -- 
> >> ==================
> >> Remove the "x" from my email address
> >> Jerry Stuckle
> >> jstucklex@attglobal.net
> >> ==================
> > 
> > I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:
> > 
> > echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...
> > 
> > Thanks for your help and have a great New Year.
> > 
> 
> That's a meta redirect, which works, although in a different way.
> header() works fine - I use it all the time.  You just have to ensure
> you output NOTHING - NOT EVEN WHITE SPACE - before the call to header().
> 
> For instance - even a blank line at the top of your script will output a
> newline character.  The first characters in your script MUST be <?PHP
> and you can't use UTF-8 or any other charset which has a BOM.
> 
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

I moved the entire if..verify...block and put it in a php block and it still didn't work. I assumed that is what you meant about no output before the header code. Is there any way you can provide an example of how to make this work? I After 2 1/2 days of research and your comments I am not comprehending what I am doing wrong. If I have a visual example I should be able to understand it and the logic. Thanks again.

[toc] | [prev] | [next] | [standalone]

#17279

On 1/13/2017 12:06 PM, wart2ww wrote:
> On Friday, January 13, 2017 at 7:39:23 AM UTC-8, Jerry Stuckle wrote:
>> On 1/13/2017 10:16 AM, wart2ww wrote:
>>> On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
>>>> On 1/12/2017 4:53 PM, wart2ww wrote:
>>>>> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
>>>>>> On 1/12/2017 3:05 PM, wart2ww wrote:
>>>>>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
>>>>>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
>>>>>>>
>>>>>>> For clarification, I am not outputting any html to the page before the header.
>>>>>>>
>>>>>>
>>>>>> You don't have to be outputting any HTML before the header - ANYTHING,
>>>>>> including a simple space, output before the header call will cause this
>>>>>> message.  It includes the output from print_r() or var_dump(), and that
>>>>>> is expected when you're debugging.
>>>>>>
>>>>>> Look for other errors in the log.  There probably is at least one before
>>>>>> this one.
>>>>>>
>>>>>
>>>>> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
>>>>>
>>>>
>>>> No problem, we do our best to help those who are trying to help
>>>> themselves.
>>>>
>>>> Doing your homework for you is another story, though :).
>>>>
>>>> -- 
>>>> ==================
>>>> Remove the "x" from my email address
>>>> Jerry Stuckle
>>>> jstucklex@attglobal.net
>>>> ==================
>>>
>>> I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:
>>>
>>> echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...
>>>
>>> Thanks for your help and have a great New Year.
>>>
>>
>> That's a meta redirect, which works, although in a different way.
>> header() works fine - I use it all the time.  You just have to ensure
>> you output NOTHING - NOT EVEN WHITE SPACE - before the call to header().
>>
>> For instance - even a blank line at the top of your script will output a
>> newline character.  The first characters in your script MUST be <?PHP
>> and you can't use UTF-8 or any other charset which has a BOM.
>>
>> -- 
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> jstucklex@attglobal.net
>> ==================
> 
> I moved the entire if..verify...block and put it in a php block and it still didn't work. I assumed that is what you meant about no output before the header code. Is there any way you can provide an example of how to make this work? I After 2 1/2 days of research and your comments I am not comprehending what I am doing wrong. If I have a visual example I should be able to understand it and the logic. Thanks again.
> 

No, I mean exactly what I said.  You cannot output ANYTHING before the
call to header.  This includes statements such as DOCTYPE, but it also
includes white space such as spaces, new (blank) lines, BOMs (used with
certain charsets) or anything else.

The fact you're getting the message indicates you are outputting
something before the header call.  You should also have a message
indicating what line on which file is generating the output.

Look for ANYWHERE your code outputs ANYTHING.  And this isn't a PHP
restriction - it's how HTTP works.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17280

On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
> On 1/13/2017 12:06 PM, wart2ww wrote:
> > On Friday, January 13, 2017 at 7:39:23 AM UTC-8, Jerry Stuckle wrote:
> >> On 1/13/2017 10:16 AM, wart2ww wrote:
> >>> On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
> >>>> On 1/12/2017 4:53 PM, wart2ww wrote:
> >>>>> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
> >>>>>> On 1/12/2017 3:05 PM, wart2ww wrote:
> >>>>>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
> >>>>>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
> >>>>>>>
> >>>>>>> For clarification, I am not outputting any html to the page before the header.
> >>>>>>>
> >>>>>>
> >>>>>> You don't have to be outputting any HTML before the header - ANYTHING,
> >>>>>> including a simple space, output before the header call will cause this
> >>>>>> message.  It includes the output from print_r() or var_dump(), and that
> >>>>>> is expected when you're debugging.
> >>>>>>
> >>>>>> Look for other errors in the log.  There probably is at least one before
> >>>>>> this one.
> >>>>>>
> >>>>>
> >>>>> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
> >>>>>
> >>>>
> >>>> No problem, we do our best to help those who are trying to help
> >>>> themselves.
> >>>>
> >>>> Doing your homework for you is another story, though :).
> >>>>
> >>>> -- 
> >>>> ==================
> >>>> Remove the "x" from my email address
> >>>> Jerry Stuckle
> >>>> jstucklex@attglobal.net
> >>>> ==================
> >>>
> >>> I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:
> >>>
> >>> echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...
> >>>
> >>> Thanks for your help and have a great New Year.
> >>>
> >>
> >> That's a meta redirect, which works, although in a different way.
> >> header() works fine - I use it all the time.  You just have to ensure
> >> you output NOTHING - NOT EVEN WHITE SPACE - before the call to header().
> >>
> >> For instance - even a blank line at the top of your script will output a
> >> newline character.  The first characters in your script MUST be <?PHP
> >> and you can't use UTF-8 or any other charset which has a BOM.
> >>
> >> -- 
> >> ==================
> >> Remove the "x" from my email address
> >> Jerry Stuckle
> >> jstucklex@attglobal.net
> >> ==================
> > 
> > I moved the entire if..verify...block and put it in a php block and it still didn't work. I assumed that is what you meant about no output before the header code. Is there any way you can provide an example of how to make this work? I After 2 1/2 days of research and your comments I am not comprehending what I am doing wrong. If I have a visual example I should be able to understand it and the logic. Thanks again.
> > 
> 
> No, I mean exactly what I said.  You cannot output ANYTHING before the
> call to header.  This includes statements such as DOCTYPE, but it also
> includes white space such as spaces, new (blank) lines, BOMs (used with
> certain charsets) or anything else.
> 
> The fact you're getting the message indicates you are outputting
> something before the header call.  You should also have a message
> indicating what line on which file is generating the output.
> 
> Look for ANYWHERE your code outputs ANYTHING.  And this isn't a PHP
> restriction - it's how HTTP works.
> 
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

I will keep trying. FYI, I did put the php block at the top of the page above any html (before the doctype declaration, made sure there were not spaces before the php block and even put the entire header code on one line with no spaces then with some spaces in the statement. Still no success so that what confuses me. I won't bug you any more but I really do appreciate your help.

[toc] | [prev] | [next] | [standalone]

#17281

On 1/13/2017 1:30 PM, wart2ww wrote:
> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
>> On 1/13/2017 12:06 PM, wart2ww wrote:
>>> On Friday, January 13, 2017 at 7:39:23 AM UTC-8, Jerry Stuckle wrote:
>>>> On 1/13/2017 10:16 AM, wart2ww wrote:
>>>>> On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
>>>>>> On 1/12/2017 4:53 PM, wart2ww wrote:
>>>>>>> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
>>>>>>>> On 1/12/2017 3:05 PM, wart2ww wrote:
>>>>>>>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
>>>>>>>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
>>>>>>>>>
>>>>>>>>> For clarification, I am not outputting any html to the page before the header.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You don't have to be outputting any HTML before the header - ANYTHING,
>>>>>>>> including a simple space, output before the header call will cause this
>>>>>>>> message.  It includes the output from print_r() or var_dump(), and that
>>>>>>>> is expected when you're debugging.
>>>>>>>>
>>>>>>>> Look for other errors in the log.  There probably is at least one before
>>>>>>>> this one.
>>>>>>>>
>>>>>>>
>>>>>>> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
>>>>>>>
>>>>>>
>>>>>> No problem, we do our best to help those who are trying to help
>>>>>> themselves.
>>>>>>
>>>>>> Doing your homework for you is another story, though :).
>>>>>>
>>>>>> -- 
>>>>>> ==================
>>>>>> Remove the "x" from my email address
>>>>>> Jerry Stuckle
>>>>>> jstucklex@attglobal.net
>>>>>> ==================
>>>>>
>>>>> I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:
>>>>>
>>>>> echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...
>>>>>
>>>>> Thanks for your help and have a great New Year.
>>>>>
>>>>
>>>> That's a meta redirect, which works, although in a different way.
>>>> header() works fine - I use it all the time.  You just have to ensure
>>>> you output NOTHING - NOT EVEN WHITE SPACE - before the call to header().
>>>>
>>>> For instance - even a blank line at the top of your script will output a
>>>> newline character.  The first characters in your script MUST be <?PHP
>>>> and you can't use UTF-8 or any other charset which has a BOM.
>>>>
>>>> -- 
>>>> ==================
>>>> Remove the "x" from my email address
>>>> Jerry Stuckle
>>>> jstucklex@attglobal.net
>>>> ==================
>>>
>>> I moved the entire if..verify...block and put it in a php block and it still didn't work. I assumed that is what you meant about no output before the header code. Is there any way you can provide an example of how to make this work? I After 2 1/2 days of research and your comments I am not comprehending what I am doing wrong. If I have a visual example I should be able to understand it and the logic. Thanks again.
>>>
>>
>> No, I mean exactly what I said.  You cannot output ANYTHING before the
>> call to header.  This includes statements such as DOCTYPE, but it also
>> includes white space such as spaces, new (blank) lines, BOMs (used with
>> certain charsets) or anything else.
>>
>> The fact you're getting the message indicates you are outputting
>> something before the header call.  You should also have a message
>> indicating what line on which file is generating the output.
>>
>> Look for ANYWHERE your code outputs ANYTHING.  And this isn't a PHP
>> restriction - it's how HTTP works.
>>
>> -- 
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> jstucklex@attglobal.net
>> ==================
> 
> I will keep trying. FYI, I did put the php block at the top of the page above any html (before the doctype declaration, made sure there were not spaces before the php block and even put the entire header code on one line with no spaces then with some spaces in the statement. Still no success so that what confuses me. I won't bug you any more but I really do appreciate your help.
> 

OK, that's a good start.  But any white space in the PHP block that is
not printed (i.e in an echo or similar statement) won't cause a problem.

But what are you using for an editor, and what charset is it using?  If
you're on Windows, what happens when you open the file in notepad?  If
on Linux, use vim to open it.  Some editors will add a BOM at the
beginning if you're not using ASCII, and the BOM will not show up in the
editor.

Additionally, are you including any files in your script?  Those can
cause this problem, also.

And finally - when you look at your log, it should say something like
"output was started at line xxx in file yyy" (I forget the exact
message).  This should point you at the culprit.

BTW - nice looking site :)

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17285

On Friday, January 13, 2017 at 10:57:29 AM UTC-8, Jerry Stuckle wrote:
> On 1/13/2017 1:30 PM, wart2ww wrote:
> > On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
> >> On 1/13/2017 12:06 PM, wart2ww wrote:
> >>> On Friday, January 13, 2017 at 7:39:23 AM UTC-8, Jerry Stuckle wrote:
> >>>> On 1/13/2017 10:16 AM, wart2ww wrote:
> >>>>> On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
> >>>>>> On 1/12/2017 4:53 PM, wart2ww wrote:
> >>>>>>> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
> >>>>>>>> On 1/12/2017 3:05 PM, wart2ww wrote:
> >>>>>>>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
> >>>>>>>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
> >>>>>>>>>
> >>>>>>>>> For clarification, I am not outputting any html to the page before the header.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> You don't have to be outputting any HTML before the header - ANYTHING,
> >>>>>>>> including a simple space, output before the header call will cause this
> >>>>>>>> message.  It includes the output from print_r() or var_dump(), and that
> >>>>>>>> is expected when you're debugging.
> >>>>>>>>
> >>>>>>>> Look for other errors in the log.  There probably is at least one before
> >>>>>>>> this one.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
> >>>>>>>
> >>>>>>
> >>>>>> No problem, we do our best to help those who are trying to help
> >>>>>> themselves.
> >>>>>>
> >>>>>> Doing your homework for you is another story, though :).
> >>>>>>
> >>>>>> -- 
> >>>>>> ==================
> >>>>>> Remove the "x" from my email address
> >>>>>> Jerry Stuckle
> >>>>>> jstucklex@attglobal.net
> >>>>>> ==================
> >>>>>
> >>>>> I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:
> >>>>>
> >>>>> echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...
> >>>>>
> >>>>> Thanks for your help and have a great New Year.
> >>>>>
> >>>>
> >>>> That's a meta redirect, which works, although in a different way.
> >>>> header() works fine - I use it all the time.  You just have to ensure
> >>>> you output NOTHING - NOT EVEN WHITE SPACE - before the call to header().
> >>>>
> >>>> For instance - even a blank line at the top of your script will output a
> >>>> newline character.  The first characters in your script MUST be <?PHP
> >>>> and you can't use UTF-8 or any other charset which has a BOM.
> >>>>
> >>>> -- 
> >>>> ==================
> >>>> Remove the "x" from my email address
> >>>> Jerry Stuckle
> >>>> jstucklex@attglobal.net
> >>>> ==================
> >>>
> >>> I moved the entire if..verify...block and put it in a php block and it still didn't work. I assumed that is what you meant about no output before the header code. Is there any way you can provide an example of how to make this work? I After 2 1/2 days of research and your comments I am not comprehending what I am doing wrong. If I have a visual example I should be able to understand it and the logic. Thanks again.
> >>>
> >>
> >> No, I mean exactly what I said.  You cannot output ANYTHING before the
> >> call to header.  This includes statements such as DOCTYPE, but it also
> >> includes white space such as spaces, new (blank) lines, BOMs (used with
> >> certain charsets) or anything else.
> >>
> >> The fact you're getting the message indicates you are outputting
> >> something before the header call.  You should also have a message
> >> indicating what line on which file is generating the output.
> >>
> >> Look for ANYWHERE your code outputs ANYTHING.  And this isn't a PHP
> >> restriction - it's how HTTP works.
> >>
> >> -- 
> >> ==================
> >> Remove the "x" from my email address
> >> Jerry Stuckle
> >> jstucklex@attglobal.net
> >> ==================
> > 
> > I will keep trying. FYI, I did put the php block at the top of the page above any html (before the doctype declaration, made sure there were not spaces before the php block and even put the entire header code on one line with no spaces then with some spaces in the statement. Still no success so that what confuses me. I won't bug you any more but I really do appreciate your help.
> > 
> 
> OK, that's a good start.  But any white space in the PHP block that is
> not printed (i.e in an echo or similar statement) won't cause a problem.
> 
> But what are you using for an editor, and what charset is it using?  If
> you're on Windows, what happens when you open the file in notepad?  If
> on Linux, use vim to open it.  Some editors will add a BOM at the
> beginning if you're not using ASCII, and the BOM will not show up in the
> editor.
> 
> Additionally, are you including any files in your script?  Those can
> cause this problem, also.
> 
> And finally - when you look at your log, it should say something like
> "output was started at line xxx in file yyy" (I forget the exact
> message).  This should point you at the culprit.
> 
> BTW - nice looking site :)
> 
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

Thank you for the compliment on the site. In answer to your questions, I am using Notepad++ as my editor and not there is not other files in the script I have. Thanks for the heads up on the error message to look for.

[toc] | [prev] | [next] | [standalone]

#17286

On 1/13/2017 4:29 PM, wart2ww wrote:
> On Friday, January 13, 2017 at 10:57:29 AM UTC-8, Jerry Stuckle wrote:
>> On 1/13/2017 1:30 PM, wart2ww wrote:
>>> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
>>>> On 1/13/2017 12:06 PM, wart2ww wrote:
>>>>> On Friday, January 13, 2017 at 7:39:23 AM UTC-8, Jerry Stuckle wrote:
>>>>>> On 1/13/2017 10:16 AM, wart2ww wrote:
>>>>>>> On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
>>>>>>>> On 1/12/2017 4:53 PM, wart2ww wrote:
>>>>>>>>> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
>>>>>>>>>> On 1/12/2017 3:05 PM, wart2ww wrote:
>>>>>>>>>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
>>>>>>>>>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
>>>>>>>>>>>
>>>>>>>>>>> For clarification, I am not outputting any html to the page before the header.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You don't have to be outputting any HTML before the header - ANYTHING,
>>>>>>>>>> including a simple space, output before the header call will cause this
>>>>>>>>>> message.  It includes the output from print_r() or var_dump(), and that
>>>>>>>>>> is expected when you're debugging.
>>>>>>>>>>
>>>>>>>>>> Look for other errors in the log.  There probably is at least one before
>>>>>>>>>> this one.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No problem, we do our best to help those who are trying to help
>>>>>>>> themselves.
>>>>>>>>
>>>>>>>> Doing your homework for you is another story, though :).
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> ==================
>>>>>>>> Remove the "x" from my email address
>>>>>>>> Jerry Stuckle
>>>>>>>> jstucklex@attglobal.net
>>>>>>>> ==================
>>>>>>>
>>>>>>> I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:
>>>>>>>
>>>>>>> echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...
>>>>>>>
>>>>>>> Thanks for your help and have a great New Year.
>>>>>>>
>>>>>>
>>>>>> That's a meta redirect, which works, although in a different way.
>>>>>> header() works fine - I use it all the time.  You just have to ensure
>>>>>> you output NOTHING - NOT EVEN WHITE SPACE - before the call to header().
>>>>>>
>>>>>> For instance - even a blank line at the top of your script will output a
>>>>>> newline character.  The first characters in your script MUST be <?PHP
>>>>>> and you can't use UTF-8 or any other charset which has a BOM.
>>>>>>
>>>>>
>>>>> I moved the entire if..verify...block and put it in a php block and it still didn't work. I assumed that is what you meant about no output before the header code. Is there any way you can provide an example of how to make this work? I After 2 1/2 days of research and your comments I am not comprehending what I am doing wrong. If I have a visual example I should be able to understand it and the logic. Thanks again.
>>>>>
>>>>
>>>> No, I mean exactly what I said.  You cannot output ANYTHING before the
>>>> call to header.  This includes statements such as DOCTYPE, but it also
>>>> includes white space such as spaces, new (blank) lines, BOMs (used with
>>>> certain charsets) or anything else.
>>>>
>>>> The fact you're getting the message indicates you are outputting
>>>> something before the header call.  You should also have a message
>>>> indicating what line on which file is generating the output.
>>>>
>>>> Look for ANYWHERE your code outputs ANYTHING.  And this isn't a PHP
>>>> restriction - it's how HTTP works.
>>>>
>>> I will keep trying. FYI, I did put the php block at the top of the page above any html (before the doctype declaration, made sure there were not spaces before the php block and even put the entire header code on one line with no spaces then with some spaces in the statement. Still no success so that what confuses me. I won't bug you any more but I really do appreciate your help.
>>>
>>
>> OK, that's a good start.  But any white space in the PHP block that is
>> not printed (i.e in an echo or similar statement) won't cause a problem.
>>
>> But what are you using for an editor, and what charset is it using?  If
>> you're on Windows, what happens when you open the file in notepad?  If
>> on Linux, use vim to open it.  Some editors will add a BOM at the
>> beginning if you're not using ASCII, and the BOM will not show up in the
>> editor.
>>
>> Additionally, are you including any files in your script?  Those can
>> cause this problem, also.
>>
>> And finally - when you look at your log, it should say something like
>> "output was started at line xxx in file yyy" (I forget the exact
>> message).  This should point you at the culprit.
>>
>> BTW - nice looking site :)
>>
> 
> Thank you for the compliment on the site. In answer to your questions, I am using Notepad++ as my editor and not there is not other files in the script I have. Thanks for the heads up on the error message to look for.
> 

In that case the BOM is most probably your problem.  What do you have
for an encoding?  And what do you get if you bring the file up in
Notepad (not Notepad++)?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17287

On Friday, January 13, 2017 at 1:57:02 PM UTC-8, Jerry Stuckle wrote:
> On 1/13/2017 4:29 PM, wart2ww wrote:
> > On Friday, January 13, 2017 at 10:57:29 AM UTC-8, Jerry Stuckle wrote:
> >> On 1/13/2017 1:30 PM, wart2ww wrote:
> >>> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
> >>>> On 1/13/2017 12:06 PM, wart2ww wrote:
> >>>>> On Friday, January 13, 2017 at 7:39:23 AM UTC-8, Jerry Stuckle wrote:
> >>>>>> On 1/13/2017 10:16 AM, wart2ww wrote:
> >>>>>>> On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
> >>>>>>>> On 1/12/2017 4:53 PM, wart2ww wrote:
> >>>>>>>>> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
> >>>>>>>>>> On 1/12/2017 3:05 PM, wart2ww wrote:
> >>>>>>>>>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
> >>>>>>>>>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
> >>>>>>>>>>>
> >>>>>>>>>>> For clarification, I am not outputting any html to the page before the header.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> You don't have to be outputting any HTML before the header - ANYTHING,
> >>>>>>>>>> including a simple space, output before the header call will cause this
> >>>>>>>>>> message.  It includes the output from print_r() or var_dump(), and that
> >>>>>>>>>> is expected when you're debugging.
> >>>>>>>>>>
> >>>>>>>>>> Look for other errors in the log.  There probably is at least one before
> >>>>>>>>>> this one.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> No problem, we do our best to help those who are trying to help
> >>>>>>>> themselves.
> >>>>>>>>
> >>>>>>>> Doing your homework for you is another story, though :).
> >>>>>>>>
> >>>>>>>> -- 
> >>>>>>>> ==================
> >>>>>>>> Remove the "x" from my email address
> >>>>>>>> Jerry Stuckle
> >>>>>>>> jstucklex@attglobal.net
> >>>>>>>> ==================
> >>>>>>>
> >>>>>>> I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:
> >>>>>>>
> >>>>>>> echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...
> >>>>>>>
> >>>>>>> Thanks for your help and have a great New Year.
> >>>>>>>
> >>>>>>
> >>>>>> That's a meta redirect, which works, although in a different way.
> >>>>>> header() works fine - I use it all the time.  You just have to ensure
> >>>>>> you output NOTHING - NOT EVEN WHITE SPACE - before the call to header().
> >>>>>>
> >>>>>> For instance - even a blank line at the top of your script will output a
> >>>>>> newline character.  The first characters in your script MUST be <?PHP
> >>>>>> and you can't use UTF-8 or any other charset which has a BOM.
> >>>>>>
> >>>>>
> >>>>> I moved the entire if..verify...block and put it in a php block and it still didn't work. I assumed that is what you meant about no output before the header code. Is there any way you can provide an example of how to make this work? I After 2 1/2 days of research and your comments I am not comprehending what I am doing wrong. If I have a visual example I should be able to understand it and the logic. Thanks again.
> >>>>>
> >>>>
> >>>> No, I mean exactly what I said.  You cannot output ANYTHING before the
> >>>> call to header.  This includes statements such as DOCTYPE, but it also
> >>>> includes white space such as spaces, new (blank) lines, BOMs (used with
> >>>> certain charsets) or anything else.
> >>>>
> >>>> The fact you're getting the message indicates you are outputting
> >>>> something before the header call.  You should also have a message
> >>>> indicating what line on which file is generating the output.
> >>>>
> >>>> Look for ANYWHERE your code outputs ANYTHING.  And this isn't a PHP
> >>>> restriction - it's how HTTP works.
> >>>>
> >>> I will keep trying. FYI, I did put the php block at the top of the page above any html (before the doctype declaration, made sure there were not spaces before the php block and even put the entire header code on one line with no spaces then with some spaces in the statement. Still no success so that what confuses me. I won't bug you any more but I really do appreciate your help.
> >>>
> >>
> >> OK, that's a good start.  But any white space in the PHP block that is
> >> not printed (i.e in an echo or similar statement) won't cause a problem.
> >>
> >> But what are you using for an editor, and what charset is it using?  If
> >> you're on Windows, what happens when you open the file in notepad?  If
> >> on Linux, use vim to open it.  Some editors will add a BOM at the
> >> beginning if you're not using ASCII, and the BOM will not show up in the
> >> editor.
> >>
> >> Additionally, are you including any files in your script?  Those can
> >> cause this problem, also.
> >>
> >> And finally - when you look at your log, it should say something like
> >> "output was started at line xxx in file yyy" (I forget the exact
> >> message).  This should point you at the culprit.
> >>
> >> BTW - nice looking site :)
> >>
> > 
> > Thank you for the compliment on the site. In answer to your questions, I am using Notepad++ as my editor and not there is not other files in the script I have. Thanks for the heads up on the error message to look for.
> > 
> 
> In that case the BOM is most probably your problem.  What do you have
> for an encoding?  And what do you get if you bring the file up in
> Notepad (not Notepad++)?
> 
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

I am using utf-8 (<meta charset="utf-8">). Opened in Notepad and there are no additional spaces or characters. Notepad++ is a true text editor and I have been using it now for about 4 years.

[toc] | [prev] | [next] | [standalone]

#17291

On 1/13/2017 5:23 PM, wart2ww wrote:
> On Friday, January 13, 2017 at 1:57:02 PM UTC-8, Jerry Stuckle wrote:
>> On 1/13/2017 4:29 PM, wart2ww wrote:
>>> On Friday, January 13, 2017 at 10:57:29 AM UTC-8, Jerry Stuckle wrote:
>>>> On 1/13/2017 1:30 PM, wart2ww wrote:
>>>>> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
>>>>>> On 1/13/2017 12:06 PM, wart2ww wrote:
>>>>>>> On Friday, January 13, 2017 at 7:39:23 AM UTC-8, Jerry Stuckle wrote:
>>>>>>>> On 1/13/2017 10:16 AM, wart2ww wrote:
>>>>>>>>> On Thursday, January 12, 2017 at 2:01:38 PM UTC-8, Jerry Stuckle wrote:
>>>>>>>>>> On 1/12/2017 4:53 PM, wart2ww wrote:
>>>>>>>>>>> On Thursday, January 12, 2017 at 12:20:22 PM UTC-8, Jerry Stuckle wrote:
>>>>>>>>>>>> On 1/12/2017 3:05 PM, wart2ww wrote:
>>>>>>>>>>>>> On Thursday, January 12, 2017 at 11:12:15 AM UTC-8, wart2ww wrote:
>>>>>>>>>>>>>> Well, that was not it. I modified the main menu's option to open the file directly and still have the same problem. What I then did was remove the header call and echoed out a message and it works great. So, finally narrowed it down to the header call. Is there another way to open an html document on the host site?
>>>>>>>>>>>>>
>>>>>>>>>>>>> For clarification, I am not outputting any html to the page before the header.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You don't have to be outputting any HTML before the header - ANYTHING,
>>>>>>>>>>>> including a simple space, output before the header call will cause this
>>>>>>>>>>>> message.  It includes the output from print_r() or var_dump(), and that
>>>>>>>>>>>> is expected when you're debugging.
>>>>>>>>>>>>
>>>>>>>>>>>> Look for other errors in the log.  There probably is at least one before
>>>>>>>>>>>> this one.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No problem, we do our best to help those who are trying to help
>>>>>>>>>> themselves.
>>>>>>>>>>
>>>>>>>>>> Doing your homework for you is another story, though :).
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> ==================
>>>>>>>>>> Remove the "x" from my email address
>>>>>>>>>> Jerry Stuckle
>>>>>>>>>> jstucklex@attglobal.net
>>>>>>>>>> ==================
>>>>>>>>>
>>>>>>>>> I could not get the header(location line to work and I tried everything. Researching for more options I found one that works. Here it is:
>>>>>>>>>
>>>>>>>>> echo "<meta http-equiv=\"refresh\" content=\"0;URL=http://www.wwchoralsociety...
>>>>>>>>>
>>>>>>>>> Thanks for your help and have a great New Year.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's a meta redirect, which works, although in a different way.
>>>>>>>> header() works fine - I use it all the time.  You just have to ensure
>>>>>>>> you output NOTHING - NOT EVEN WHITE SPACE - before the call to header().
>>>>>>>>
>>>>>>>> For instance - even a blank line at the top of your script will output a
>>>>>>>> newline character.  The first characters in your script MUST be <?PHP
>>>>>>>> and you can't use UTF-8 or any other charset which has a BOM.
>>>>>>>>
>>>>>>>
>>>>>>> I moved the entire if..verify...block and put it in a php block and it still didn't work. I assumed that is what you meant about no output before the header code. Is there any way you can provide an example of how to make this work? I After 2 1/2 days of research and your comments I am not comprehending what I am doing wrong. If I have a visual example I should be able to understand it and the logic. Thanks again.
>>>>>>>
>>>>>>
>>>>>> No, I mean exactly what I said.  You cannot output ANYTHING before the
>>>>>> call to header.  This includes statements such as DOCTYPE, but it also
>>>>>> includes white space such as spaces, new (blank) lines, BOMs (used with
>>>>>> certain charsets) or anything else.
>>>>>>
>>>>>> The fact you're getting the message indicates you are outputting
>>>>>> something before the header call.  You should also have a message
>>>>>> indicating what line on which file is generating the output.
>>>>>>
>>>>>> Look for ANYWHERE your code outputs ANYTHING.  And this isn't a PHP
>>>>>> restriction - it's how HTTP works.
>>>>>>
>>>>> I will keep trying. FYI, I did put the php block at the top of the page above any html (before the doctype declaration, made sure there were not spaces before the php block and even put the entire header code on one line with no spaces then with some spaces in the statement. Still no success so that what confuses me. I won't bug you any more but I really do appreciate your help.
>>>>>
>>>>
>>>> OK, that's a good start.  But any white space in the PHP block that is
>>>> not printed (i.e in an echo or similar statement) won't cause a problem.
>>>>
>>>> But what are you using for an editor, and what charset is it using?  If
>>>> you're on Windows, what happens when you open the file in notepad?  If
>>>> on Linux, use vim to open it.  Some editors will add a BOM at the
>>>> beginning if you're not using ASCII, and the BOM will not show up in the
>>>> editor.
>>>>
>>>> Additionally, are you including any files in your script?  Those can
>>>> cause this problem, also.
>>>>
>>>> And finally - when you look at your log, it should say something like
>>>> "output was started at line xxx in file yyy" (I forget the exact
>>>> message).  This should point you at the culprit.
>>>>
>>>> BTW - nice looking site :)
>>>>
>>>
>>> Thank you for the compliment on the site. In answer to your questions, I am using Notepad++ as my editor and not there is not other files in the script I have. Thanks for the heads up on the error message to look for.
>>>
>>
>> In that case the BOM is most probably your problem.  What do you have
>> for an encoding?  And what do you get if you bring the file up in
>> Notepad (not Notepad++)?
>>
> 
> I am using utf-8 (<meta charset="utf-8">). Opened in Notepad and there are no additional spaces or characters. Notepad++ is a true text editor and I have been using it now for about 4 years.
> 

Yes, but Notepad+ can use all kinds of charsets - including UTF-8 with
BOM.  When using it, I always use ANSI.  You have to be very careful,
because the BOM will not show up in a BOM-aware editor, but will cause
problems on your page.  When I do use Notepad++, I always set it to ANSI
charset (but I use Eclipse for most of my editing nowadays).

So we're back to your error log.  Where does the error message say the
output started?  It gives a filename and line number.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17282

On 13.01.2017 at 19:30, wart2ww wrote:

> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
>
>> The fact you're getting the message indicates you are outputting
>> something before the header call.  You should also have a message
>> indicating what line on which file is generating the output.
> 
> I will keep trying. FYI, I did put the php block at the top of the page above any html (before the doctype declaration, made sure there were not spaces before the php block and even put the entire header code on one line with no spaces then with some spaces in the statement. Still no success so that what confuses me. I won't bug you any more but I really do appreciate your help.

As Jerry had written, the message you get is something like

  "Cannot send headers; headers already sent in <filename>, line
   <lineno> in <filename>:<lineno>"

The last <filename> and <lineno> indicate the place of the header()
call, the first <filename> and <lineno> indicate where the output started.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#17283

Christoph M. Becker wrote:

> On 13.01.2017 at 19:30, wart2ww wrote:
>> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
>>> The fact you're getting the message indicates you are outputting
>>> something before the header call.  You should also have a message
>>> indicating what line on which file is generating the output.
>>
>> I will keep trying. FYI, I did put the php block at the top of the page
>> above any html (before the doctype declaration, made sure there were not
>> spaces before the php block and even put the entire header code on one
>> line with no spaces then with some spaces in the statement. Still no
>> success so that what confuses me. I won't bug you any more but I really
>> do appreciate your help.
>
> As Jerry had written, the message you get is something like
>
>   "Cannot send headers; headers already sent in <filename>, line
>    <lineno> in <filename>:<lineno>"
>
> The last <filename> and <lineno> indicate the place of the header()
> call, the first <filename> and <lineno> indicate where the output started.

Another common reason for this problem is that the used source code editor
prepends an (if supported, invisible) byte order mark (BOM; usually, for
UTF-8 encoded source code).  AFAIK, the BOM can be shown with a hex editor
(or equivalent, like “cat -A”), or an unsupporting text editor (rare these
days) only.

For example, the first octets of PHP source code with an UTF-8 BOM can look
in a hex editor [here: Pascal 'Pixel' Rigaux’ hexedit(1)] as follows:

| 00000000   EF BB BF 3C 3F 70 68 70 …      ...<?php…

An editor that does not support UTF-8 could display “” for the BOM,
because those are the characters at the code points 0xEF, 0xBB, and 0xBF in
ISO/IEC-8859-1 (“Latin alphabet no. 1” or “Latin-1”) for short, and
Windows-1252/CP-1252 (”Western”).

<https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout>

For PHP source code, the source code editor has to be configured so that
it does not prepend a BOM, or another editor has to be used for final
storage; otherwise it is impossible to avoid the warning and the problem.

<https://en.wikipedia.org/wiki/Byte_order_mark>

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#17284

On 1/13/2017 3:35 PM, the well-known troll Thomas 'Pointed Head' Lahn wrote:
> Christoph M. Becker wrote:
> 
>> On 13.01.2017 at 19:30, wart2ww wrote:
>>> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
>>>> The fact you're getting the message indicates you are outputting
>>>> something before the header call.  You should also have a message
>>>> indicating what line on which file is generating the output.
>>>
>>> I will keep trying. FYI, I did put the php block at the top of the page
>>> above any html (before the doctype declaration, made sure there were not
>>> spaces before the php block and even put the entire header code on one
>>> line with no spaces then with some spaces in the statement. Still no
>>> success so that what confuses me. I won't bug you any more but I really
>>> do appreciate your help.
>>
>> As Jerry had written, the message you get is something like
>>
>>   "Cannot send headers; headers already sent in <filename>, line
>>    <lineno> in <filename>:<lineno>"
>>
>> The last <filename> and <lineno> indicate the place of the header()
>> call, the first <filename> and <lineno> indicate where the output started.
> 
> Another common reason for this problem is that the used source code editor
> prepends an (if supported, invisible) byte order mark (BOM; usually, for
> UTF-8 encoded source code).  AFAIK, the BOM can be shown with a hex editor
> (or equivalent, like “cat -A”), or an unsupporting text editor (rare these
> days) only.
> 
> For example, the first octets of PHP source code with an UTF-8 BOM can look
> in a hex editor [here: Pascal 'Pixel' Rigaux’ hexedit(1)] as follows:
> 
> | 00000000   EF BB BF 3C 3F 70 68 70 …      ...<?php…
> 
> An editor that does not support UTF-8 could display “” for the BOM,
> because those are the characters at the code points 0xEF, 0xBB, and 0xBF in
> ISO/IEC-8859-1 (“Latin alphabet no. 1” or “Latin-1”) for short, and
> Windows-1252/CP-1252 (”Western”).
> 
> <https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout>
> 
> For PHP source code, the source code editor has to be configured so that
> it does not prepend a BOM, or another editor has to be used for final
> storage; otherwise it is impossible to avoid the warning and the problem.
> 
> <https://en.wikipedia.org/wiki/Byte_order_mark>
> 

Which I mentioned a couple of days ago.  Do you ever post something
original?  I didn't think so.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17288

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 1/13/2017 3:35 PM, the well-known troll Thomas 'Pointed Head' Lahn wrote:
>> Christoph M. Becker wrote:
>> 
>>> On 13.01.2017 at 19:30, wart2ww wrote:
>>>> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
>>>>> The fact you're getting the message indicates you are outputting
>>>>> something before the header call.  You should also have a message
>>>>> indicating what line on which file is generating the output.
>>>>
>>>> I will keep trying. FYI, I did put the php block at the top of the page
>>>> above any html (before the doctype declaration, made sure there were not
>>>> spaces before the php block and even put the entire header code on one
>>>> line with no spaces then with some spaces in the statement. Still no
>>>> success so that what confuses me. I won't bug you any more but I really
>>>> do appreciate your help.
>>>
>>> As Jerry had written, the message you get is something like
>>>
>>>   "Cannot send headers; headers already sent in <filename>, line
>>>    <lineno> in <filename>:<lineno>"
>>>
>>> The last <filename> and <lineno> indicate the place of the header()
>>> call, the first <filename> and <lineno> indicate where the output started.
>> 
>> Another common reason for this problem is that the used source code editor
>> prepends an (if supported, invisible) byte order mark (BOM; usually, for
>> UTF-8 encoded source code).  AFAIK, the BOM can be shown with a hex editor
>> (or equivalent, like “cat -A”), or an unsupporting text editor (rare these
>> days) only.
>> 
>> For example, the first octets of PHP source code with an UTF-8 BOM can look
>> in a hex editor [here: Pascal 'Pixel' Rigaux’ hexedit(1)] as follows:
>> 
>> | 00000000   EF BB BF 3C 3F 70 68 70 …      ...<?php…
>> 
>> An editor that does not support UTF-8 could display “” for the BOM,
>> because those are the characters at the code points 0xEF, 0xBB, and 0xBF in
>> ISO/IEC-8859-1 (“Latin alphabet no. 1” or “Latin-1”) for short, and
>> Windows-1252/CP-1252 (”Western”).
>> 
>> <https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout>
>> 
>> For PHP source code, the source code editor has to be configured so that
>> it does not prepend a BOM, or another editor has to be used for final
>> storage; otherwise it is impossible to avoid the warning and the problem.
>> 
>> <https://en.wikipedia.org/wiki/Byte_order_mark>
>
> Which I mentioned a couple of days ago.  Do you ever post something
> original?

Thomas Lahn and I hardly see eye to eye on anything, but his post
clearly contains original material: an possible explanation of how this
may have come about (the editor); some advice on further debugging the
issue (a hex editor or cat -A); and he clears up a misconception the OP
might have taken from your remark that "you can't use UTF-8 or any other
charset which has a BOM".

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17289

On Friday, January 13, 2017 at 6:37:42 PM UTC-8, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
> > On 1/13/2017 3:35 PM, the well-known troll Thomas 'Pointed Head' Lahn wrote:
> >> Christoph M. Becker wrote:
> >> 
> >>> On 13.01.2017 at 19:30, wart2ww wrote:
> >>>> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
> >>>>> The fact you're getting the message indicates you are outputting
> >>>>> something before the header call.  You should also have a message
> >>>>> indicating what line on which file is generating the output.
> >>>>
> >>>> I will keep trying. FYI, I did put the php block at the top of the page
> >>>> above any html (before the doctype declaration, made sure there were not
> >>>> spaces before the php block and even put the entire header code on one
> >>>> line with no spaces then with some spaces in the statement. Still no
> >>>> success so that what confuses me. I won't bug you any more but I really
> >>>> do appreciate your help.
> >>>
> >>> As Jerry had written, the message you get is something like
> >>>
> >>>   "Cannot send headers; headers already sent in <filename>, line
> >>>    <lineno> in <filename>:<lineno>"
> >>>
> >>> The last <filename> and <lineno> indicate the place of the header()
> >>> call, the first <filename> and <lineno> indicate where the output started.
> >> 
> >> Another common reason for this problem is that the used source code editor
> >> prepends an (if supported, invisible) byte order mark (BOM; usually, for
> >> UTF-8 encoded source code).  AFAIK, the BOM can be shown with a hex editor
> >> (or equivalent, like “cat -A”), or an unsupporting text editor (rare these
> >> days) only.
> >> 
> >> For example, the first octets of PHP source code with an UTF-8 BOM can look
> >> in a hex editor [here: Pascal 'Pixel' Rigaux’ hexedit(1)] as follows:
> >> 
> >> | 00000000   EF BB BF 3C 3F 70 68 70 …      ...<?php…
> >> 
> >> An editor that does not support UTF-8 could display “” for the BOM,
> >> because those are the characters at the code points 0xEF, 0xBB, and 0xBF in
> >> ISO/IEC-8859-1 (“Latin alphabet no. 1” or “Latin-1”) for short, and
> >> Windows-1252/CP-1252 (”Western”).
> >> 
> >> <https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout>
> >> 
> >> For PHP source code, the source code editor has to be configured so that
> >> it does not prepend a BOM, or another editor has to be used for final
> >> storage; otherwise it is impossible to avoid the warning and the problem.
> >> 
> >> <https://en.wikipedia.org/wiki/Byte_order_mark>
> >
> > Which I mentioned a couple of days ago.  Do you ever post something
> > original?
> 
> Thomas Lahn and I hardly see eye to eye on anything, but his post
> clearly contains original material: an possible explanation of how this
> may have come about (the editor); some advice on further debugging the
> issue (a hex editor or cat -A); and he clears up a misconception the OP
> might have taken from your remark that "you can't use UTF-8 or any other
> charset which has a BOM".
> 
> -- 
> Ben.

I learn so much when I am trying to learn something new. I had never heard of BOM before in any of my studies or videos on web design. Now I can research the subject, evaluate the code in Brackets or a hex editor. Thank you everyone for your help. I think we should probably put this all to rest now. Unless someone else has input, of course.

[toc] | [prev] | [next] | [standalone]

#17290

On 1/13/2017 9:37 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 1/13/2017 3:35 PM, the well-known troll Thomas 'Pointed Head' Lahn wrote:
>>> Christoph M. Becker wrote:
>>>
>>>> On 13.01.2017 at 19:30, wart2ww wrote:
>>>>> On Friday, January 13, 2017 at 9:58:27 AM UTC-8, Jerry Stuckle wrote:
>>>>>> The fact you're getting the message indicates you are outputting
>>>>>> something before the header call.  You should also have a message
>>>>>> indicating what line on which file is generating the output.
>>>>>
>>>>> I will keep trying. FYI, I did put the php block at the top of the page
>>>>> above any html (before the doctype declaration, made sure there were not
>>>>> spaces before the php block and even put the entire header code on one
>>>>> line with no spaces then with some spaces in the statement. Still no
>>>>> success so that what confuses me. I won't bug you any more but I really
>>>>> do appreciate your help.
>>>>
>>>> As Jerry had written, the message you get is something like
>>>>
>>>>   "Cannot send headers; headers already sent in <filename>, line
>>>>    <lineno> in <filename>:<lineno>"
>>>>
>>>> The last <filename> and <lineno> indicate the place of the header()
>>>> call, the first <filename> and <lineno> indicate where the output started.
>>>
>>> Another common reason for this problem is that the used source code editor
>>> prepends an (if supported, invisible) byte order mark (BOM; usually, for
>>> UTF-8 encoded source code).  AFAIK, the BOM can be shown with a hex editor
>>> (or equivalent, like “cat -A”), or an unsupporting text editor (rare these
>>> days) only.
>>>
>>> For example, the first octets of PHP source code with an UTF-8 BOM can look
>>> in a hex editor [here: Pascal 'Pixel' Rigaux’ hexedit(1)] as follows:
>>>
>>> | 00000000   EF BB BF 3C 3F 70 68 70 …      ...<?php…
>>>
>>> An editor that does not support UTF-8 could display “” for the BOM,
>>> because those are the characters at the code points 0xEF, 0xBB, and 0xBF in
>>> ISO/IEC-8859-1 (“Latin alphabet no. 1” or “Latin-1”) for short, and
>>> Windows-1252/CP-1252 (”Western”).
>>>
>>> <https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout>
>>>
>>> For PHP source code, the source code editor has to be configured so that
>>> it does not prepend a BOM, or another editor has to be used for final
>>> storage; otherwise it is impossible to avoid the warning and the problem.
>>>
>>> <https://en.wikipedia.org/wiki/Byte_order_mark>
>>
>> Which I mentioned a couple of days ago.  Do you ever post something
>> original?
> 
> Thomas Lahn and I hardly see eye to eye on anything, but his post
> clearly contains original material: an possible explanation of how this
> may have come about (the editor); some advice on further debugging the
> issue (a hex editor or cat -A); and he clears up a misconception the OP
> might have taken from your remark that "you can't use UTF-8 or any other
> charset which has a BOM".
> 

Sorry, Ben, he said nothing that hasn't been said before in this thread.
 All he did was cut/paste an actual BOM from somewhere else.  But the
actual values are immaterial.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17293

Ben Bacarisse wrote:

> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> On 1/13/2017 3:35 PM, the well-known troll Thomas 'Pointed Head' Lahn
>> wrote:
>>> For PHP source code, the source code editor has to be configured so that
>>> it does not prepend a BOM, or another editor has to be used for final
>>> storage; otherwise it is impossible to avoid the warning and the
>>> problem.
>>>
>>> <https://en.wikipedia.org/wiki/Byte_order_mark>
>> Which I mentioned a couple of days ago.  Do you ever post something
>> original?
>
> […] he clears up a misconception the OP might have taken from your remark
> that "you can't use UTF-8 or any other charset which has a BOM".

Pure coincidence.  The angry old man – and I am being polite here – is still
under the misconception that I am reading, let alone seeing, his postings
containing only smattering, if that (except in quotations like this) when
actually I have much better things to do.

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#17294

On 1/14/2017 1:47 PM, the well-know troll Thomas 'Pointed Head' Lahn wrote:
> Ben Bacarisse wrote:
> 
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>> On 1/13/2017 3:35 PM, the well-known troll Thomas 'Pointed Head' Lahn
>>> wrote:
>>>> For PHP source code, the source code editor has to be configured so that
>>>> it does not prepend a BOM, or another editor has to be used for final
>>>> storage; otherwise it is impossible to avoid the warning and the
>>>> problem.
>>>>
>>>> <https://en.wikipedia.org/wiki/Byte_order_mark>
>>> Which I mentioned a couple of days ago.  Do you ever post something
>>> original?
>>
>> […] he clears up a misconception the OP might have taken from your remark
>> that "you can't use UTF-8 or any other charset which has a BOM".
> 
> Pure coincidence.  The angry old man – and I am being polite here – is still
> under the misconception that I am reading, let alone seeing, his postings
> containing only smattering, if that (except in quotations like this) when
> actually I have much better things to do.
> 

LOL, Pointed Head thinks I'm an "angry old man".  Older, yes.  But not
at all angry.  Just calling a troll a troll, that's all.  And Pointed
Head is a well-known troll in multiple newsgroups - no matter what he
tries to claim.  And he never does post anything original that is of
merit.  Just copying what others post and bitching when someone doesn't
conform to HIS standards.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17275

Christoph M. Becker wrote:

> On 12.01.2017 at 19:18, wart2ww wrote:
>> I did check [the error log] and got the following error message: PHP
>> Warning:  Cannot modify header information - headers already sent by
>> (output started at......
>> 
>> The sites main menu contains an option to open the same page as the php
>> codes header('location'....
>> 
>> Can that be the problem?
> 
> If an header is supposed to be sent, but isn't, that certainly could
> cause all kinds of issues.  Instead of wondering whether this very issue
> is caused by the failing header call, I suggest you fix it, and then
> check whether the other issue still persists. :-)

Regarding the fix: the problem may not be obvious, neither may be the fix.

As the warning says, the header() call fails because output has already been 
sent (and so implicitly at least the default “Content-Type: text/html” 
header _field_ – it’s the *P*HP *H*ypertext *P*reprocessor).  For example,

  <?php

  echo 42;
  header('Content-Type: text/plain', true);

will echo “42” but not send the specified Content-Type header _field_.  

Likewise,

  <?php

  echo 42;
  header('Location: …', false, 302);

will not cause redirection.  This has to do with the structure of an 
Internet message (see RFC 5322) that an HTTP response is (see RFC 7230);
the one caused by the premature “echo” statement above is at least

-----------8<----------
Content-Type: text/html

42
-----------8<----------

There is no way that more header fields can be sent at this point, because 
it is an output *stream*, and we have already output a part of the message 
body.

A common reason for this warning is when one does not follow the 
recommendation in the PHP-FIG PSR-2 Coding Style Guide to not write the “?>” 
at the end of files that contain only PHP code (I would extend that 
recommendation to files that *end with* PHP code). [1]  Because then any 
whitespace that follows *is* output, too.  If, for example, you have 
configured your editor to add a newline when saving the file (or it does 
that without asking), you will cause PHP to generate output; not so if you 
omit the “?>”.

Another common reason are error messages or warnings being output before 
header(), but we might be able to exclude that here as error messages are 
going into the error log.

[1] <http://www.php-fig.org/psr/psr-2/#files>

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web