Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem validating user and hashed value in db

24 views
Skip to first unread message

wart2ww

unread,
Jan 10, 2017, 3:46:44 PM1/10/17
to
I have a form that only asks for a password. The valid password is encriypted using password_hash($userPW, PASSWORD_BCRYPT, [12]) and stored in the database.

The connection is valid and I get a confirmation that the connection has been made. However, when it comes to validating the userpw and the hashed value I get an error message. Below is the code and where the error is occuring. Being new, I am asking for help after 6 hours of working on this.

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Login</title>
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css">
</head>

<body>

<?php
// userpw entered by user for validation is 123abc
// $hashedPW is stored in the db
// $hashedPW = '$2y$10$fLAVp7OMvvKzXYKHPGJ7kucfj7HxJilnrsHXo/b1FLL44d.EoSe7e';

// test to see if submit button has been clicked
if(isset($_POST['submit'])) {
$userPW = trim($_POST['pass']);

$userQuery = $con->prepare("SELECT userpw FROM myPasswordDb");

$userQuery->execute([
'userPW'=> $userPW
]);

$pw = $userQuery->fetch(PDO::FETCH_OBJ);

$db_password = $pw->userPW; // error seems to be here - returns false

if(password_verify($userPW, $db_password)){
echo "<p class='bg-danger'>user verified</p>";
} else {
echo "<p class='bg-danger'>user not verified</p>";
}
}

?>


<form action="" method="post" autocomplete="off">

<label for="pass" style="margin-top: 30px; margin-left: 30px;">
Password
<input type="text" name="pass" style="margin-left: 10px;">
</label><br><br>

<input type="submit" name="submit">
</form>

</body>
</html>













Jerry Stuckle

unread,
Jan 10, 2017, 10:38:51 PM1/10/17
to
You didn't provide the MySQL table definition, so this is somewhat a
guess. But what's in $pw where you get the error? Try

print_r($pw);

That should help.

Also, be aware you aren't using any selection criteria, so every row in
the table will be retrieved. And since you didn't use ORDER BY, the
order of retrieval is not guaranteed. If you ever have more than one
row in the table, this will eventually cause you problems.

You didn't post the code for your password_verify function, so it's
unknown if you'll have a problem there or not.

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

wart2ww

unread,
Jan 10, 2017, 10:51:33 PM1/10/17
to
The table is only designed to have one field and one record so I didn't see the need for a WHERE clause.

I think the verify is included: password_verify($userPW, $db_password) I have done a print_r and $pw does return the value in the table. The problem is that the next statement($db_password = $pw->userPW; // error seems to be here - returns false) is where everything stops. Nothing happens after the FETCH statement. I hope that clears it up for you. If not, let me know. Thanks.

Jerry Stuckle

unread,
Jan 10, 2017, 11:28:10 PM1/10/17
to
So, what does print_r($pw) actually show? That is critical to the rest
of the code.

wart2ww

unread,
Jan 11, 2017, 1:32:50 AM1/11/17
to
Just ran the print_r and got nothing. In my attempts, at one point I did get the db table value but I am not now. Sorry for the confusion.

Christoph M. Becker

unread,
Jan 11, 2017, 6:47:54 AM1/11/17
to
> Just ran the print_r and got nothing. In my attempts, at one point I did get the db table value but I am not now. Sorry for the confusion.

Don't use print_r(), but rather var_dump().

--
Christoph M. Becker

Jerry Stuckle

unread,
Jan 11, 2017, 9:06:39 AM1/11/17
to
Either one works, Christoph. They just show the information in a
slightly different way.

Jerry Stuckle

unread,
Jan 11, 2017, 9:21:50 AM1/11/17
to
>>> The table is only designed to have one field and one record so I didn't see the need for a WHERE clause.
>>>
>>> I think the verify is included: password_verify($userPW, $db_password) I have done a print_r and $pw does return the value in the table. The problem is that the next statement($db_password = $pw->userPW; // error seems to be here - returns false) is where everything stops. Nothing happens after the FETCH statement. I hope that clears it up for you. If not, let me know. Thanks.
>>>
>>
>> So, what does print_r($pw) actually show? That is critical to the rest
>> of the code.
>>
>
> Just ran the print_r and got nothing. In my attempts, at one point I did get the db table value but I am not now. Sorry for the confusion.
>

OK, so you need to find out why it is empty.

What is the result of your

$userQuery->execute([
'userPW'=> $userPW

call? And btw - what is the 'userPW=> $userPW? You don't have any
parameters in your SELECT statement, so there's nothing to pass.

Also, ensure you are looking at the page source when looking at the
output of print_r(). Depending on what else you have in your HTML,
output may or may not show up in the normal browser window, but always
will in the source.

Christoph M. Becker

unread,
Jan 11, 2017, 9:37:48 AM1/11/17
to
On 11.01.2017 at 15:07, Jerry Stuckle wrote:

> On 1/11/2017 6:47 AM, Christoph M. Becker wrote:
>> On 11.01.2017 at 07:32, wart2ww wrote:
>>
>>> On Tuesday, January 10, 2017 at 8:28:10 PM UTC-8, Jerry Stuckle wrote:
>>>
>>>> So, what does print_r($pw) actually show? That is critical to the rest
>>>> of the code.
>>>
>>> Just ran the print_r and got nothing. In my attempts, at one point I did get the db table value but I am not now. Sorry for the confusion.
>>
>> Don't use print_r(), but rather var_dump().
>>
>
> Either one works, Christoph. They just show the information in a
> slightly different way.

print_r(false) produces no output, while var_dump(false) does.

--
Christoph M. Becker


Jerry Stuckle

unread,
Jan 11, 2017, 3:40:31 PM1/11/17
to
Which in itself tells you what the value is. I prefer print_r() with
new programmers because the output is more human-readable. var_dump()
often confuses more than it helps.

Thomas 'PointedEars' Lahn

unread,
Jan 11, 2017, 5:18:09 PM1/11/17
to
Christoph M. Becker wrote:

> On 11.01.2017 at 15:07, Jerry Stuckle wrote:
>> On 1/11/2017 6:47 AM, Christoph M. Becker wrote:
>>> On 11.01.2017 at 07:32, wart2ww wrote:
>>>> On Tuesday, January 10, 2017 at 8:28:10 PM UTC-8, Jerry Stuckle wrote:
>>>>> So, what does print_r($pw) actually show? That is critical to the
>>>>> rest of the code.
>>>> Just ran the print_r and got nothing. In my attempts, at one point I
>>>> did get the db table value but I am not now. Sorry for the confusion.
>>> Don't use print_r(), but rather var_dump().
>> Either one works, Christoph. They just show the information in a
>> slightly different way.
>
> print_r(false) produces no output, while var_dump(false) does.

That is also true for the string of zero length and the NULL value, because
that is their string representation (the result of converting them to the
string type). PHP 101.

With Xdebug so configured and loaded, var_dump() also has the advantage over
print_r() that it prints colored output, prepends '<pre>' and appends
'</pre>', and limits by default the output for nested arrays.

--
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.

wart2ww

unread,
Jan 12, 2017, 10:32:20 AM1/12/17
to
Well, I have been doing testing some of the posts suggestions and confirm that print_r() and var_dump show the hashed password in the database. I have also echoed out $userPW and $db_password in a line just before the verify_password function. The results display and are correct. This code works correctly on my wamp local host just fine. When I copy it to the websites server, it works up to the echo statement but then nothing happened so I thought 'rehash the userPW, copy it to the db and try again. Still not running the verify function. Any other ideas? Maybe a setting on the server? Any other suggestions on how to code this for it to work? Thanks

Christoph M. Becker

unread,
Jan 12, 2017, 11:23:11 AM1/12/17
to
On 12.01.2017 at 16:32, wart2ww wrote:

> Well, I have been doing testing some of the posts suggestions and
> confirm that print_r() and var_dump show the hashed password in the
> database. I have also echoed out $userPW and $db_password in a line
> just before the verify_password function. The results display and are
> correct. This code works correctly on my wamp local host just fine.
> When I copy it to the websites server, it works up to the echo
> statement but then nothing happened so I thought 'rehash the userPW,
> copy it to the db and try again. Still not running the verify
> function. Any other ideas?

Check the error logs on the server, and the return values of the
relevant function calls. For instance, what does

$userQuery->execute([
'userPW'=> $userPW
]);

return? And why do you pass an input parameter to a query that has no
placeholder?

--
Christoph M. Becker



wart2ww

unread,
Jan 12, 2017, 1:18:36 PM1/12/17
to
Thank you for the heads up on the error log. I did check it 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?

Christoph M. Becker

unread,
Jan 12, 2017, 1:36:25 PM1/12/17
to
On 12.01.2017 at 19:18, wart2ww wrote:

> On Thursday, January 12, 2017 at 8:23:11 AM UTC-8, Christoph M. Becker wrote:
>
>> Check the error logs on the server, and the return values of the
>> relevant function calls. For instance, what does
>>
>> $userQuery->execute([
>> 'userPW'=> $userPW
>> ]);
>>
>> return? And why do you pass an input parameter to a query that has no
>> placeholder?
>
> Thank you for the heads up on the error log. I did check it 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. :-)

--
Christoph M. Becker

wart2ww

unread,
Jan 12, 2017, 2:12:15 PM1/12/17
to
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?

wart2ww

unread,
Jan 12, 2017, 3:05:45 PM1/12/17
to
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.

Jerry Stuckle

unread,
Jan 12, 2017, 3:20:22 PM1/12/17
to
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.

wart2ww

unread,
Jan 12, 2017, 4:51:57 PM1/12/17
to
So I guess the problem is that there is a form on the same page containing the php code. I would use an include statement but I believe that would cause the same problem.

wart2ww

unread,
Jan 12, 2017, 4:53:20 PM1/12/17
to
I am still learning PDO and am trying to understand the processing so I appreciate your help and patience tremendously.

Jerry Stuckle

unread,
Jan 12, 2017, 5:00:29 PM1/12/17
to
On 1/12/2017 4:51 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.
>>
>
> So I guess the problem is that there is a form on the same page containing the php code. I would use an include statement but I believe that would cause the same problem.
>

No, having a form on the same page as the PHP code is not a problem.
You just have to ensure the header call is made *before* any output.

In fact, it is quite common to have PHP code to process the form in the
same page as the form itself. That way, if there is an error, you can
redisplay the form with the entered values an error message. If there
is no error, you can process the form and use the header call to go to
the next page.

include (or, better yet, require or require_once) just allows you to put
some common code in a separate file and include it in the existing file.
It is basically the same as doing a copy/paste of the included file
using your editor.

Jerry Stuckle

unread,
Jan 12, 2017, 5:01:38 PM1/12/17
to
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 :).

wart2ww

unread,
Jan 13, 2017, 10:16:28 AM1/13/17
to
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.

Thomas 'PointedEars' Lahn

unread,
Jan 13, 2017, 10:27:16 AM1/13/17
to
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>

Christoph M. Becker

unread,
Jan 13, 2017, 10:39:00 AM1/13/17
to
On 13.01.2017 at 16:27, Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
>
>> 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.

ACK.

> 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 “?>”.

A *single* newline (LF or CRLF) will _not_ cause PHP to produce output,
but is rather swallowed instead, see <https://3v4l.org/A8DUT>.
Interestingly, I haven't been able to find this info in the PHP manual
(even though I recall to have it seen there) nor in the PHP language
specification[2].

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

--
Christoph M. Becker

Jerry Stuckle

unread,
Jan 13, 2017, 10:39:23 AM1/13/17
to
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.

wart2ww

unread,
Jan 13, 2017, 12:06:31 PM1/13/17
to
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.

Jerry Stuckle

unread,
Jan 13, 2017, 12:58:27 PM1/13/17
to
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.

wart2ww

unread,
Jan 13, 2017, 1:30:53 PM1/13/17
to
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.

Jerry Stuckle

unread,
Jan 13, 2017, 1:57:29 PM1/13/17
to
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 :)

Christoph M. Becker

unread,
Jan 13, 2017, 2:02:51 PM1/13/17
to
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

Thomas 'PointedEars' Lahn

unread,
Jan 13, 2017, 3:36:02 PM1/13/17
to
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>

Jerry Stuckle

unread,
Jan 13, 2017, 4:24:08 PM1/13/17
to
Which I mentioned a couple of days ago. Do you ever post something
original? I didn't think so.

wart2ww

unread,
Jan 13, 2017, 4:29:46 PM1/13/17
to
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.

Jerry Stuckle

unread,
Jan 13, 2017, 4:57:02 PM1/13/17
to
>>>>> 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++)?

wart2ww

unread,
Jan 13, 2017, 5:24:09 PM1/13/17
to
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.

Ben Bacarisse

unread,
Jan 13, 2017, 9:37:42 PM1/13/17
to
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.

wart2ww

unread,
Jan 13, 2017, 10:20:49 PM1/13/17
to
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.

Jerry Stuckle

unread,
Jan 14, 2017, 12:57:36 PM1/14/17
to
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.

Jerry Stuckle

unread,
Jan 14, 2017, 1:02:49 PM1/14/17
to
> 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.

Thomas 'PointedEars' Lahn

unread,
Jan 14, 2017, 1:46:00 PM1/14/17
to
Ben Bacarisse wrote:

> Jerry Stuckle <jstu...@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 less seeing, his
postings containing only smattering, if that (except in quotations like
this) when actually I have much better things to do.

Thomas 'PointedEars' Lahn

unread,
Jan 14, 2017, 1:47:50 PM1/14/17
to
Ben Bacarisse wrote:

> Jerry Stuckle <jstu...@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.

Jerry Stuckle

unread,
Jan 14, 2017, 2:00:02 PM1/14/17
to
On 1/14/2017 1:47 PM, the well-know troll Thomas 'Pointed Head' Lahn wrote:
> Ben Bacarisse wrote:
>
>> Jerry Stuckle <jstu...@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.
0 new messages