404 errors

[sheldonlg]

I don't know which is the best newsgroup for this, so I put it into three.

I have several sites that are working perfectly. When I look at the
statistics for these sites there are huge numbers of 404 errors
tabulated (like 12,000). This is only for sites where I have added the
php coding for the server code. Other sites from this same web company
that do not have php do not have the 404 errors.

Again, there seems to be no error in the operation of the sites where
these errors are being counted. Does anyone have an idea as to what may
be happening here?

[Rik Wasmus]

sheldonlg wrote:

I don't know which is the best newsgroup for this, so I put it into three.

I have several sites that are working perfectly. When I look at the
statistics for these sites there are huge numbers of 404 errors
tabulated (like 12,000). This is only for sites where I have added the
php coding for the server code. Other sites from this same web company
that do not have php do not have the 404 errors.

Again, there seems to be no error in the operation of the sites where
these errors are being counted. Does anyone have an idea as to what may
be happening here?

Just check the URLS of those 404's. Most common is some mod_rewrite
rules going haywire, of just lousy url-creation. The worst case I ever
saw was defaulting to a 404 .php page when calling an html page, and
thus providing a different URL for the content, horrible.

Then again, 404's are about the least interesting errors if everything
works OK for the users. Who cares if spiders can't find robots.txt,
browsers no favicon.ico or no index.html?
--
Rik Wasmus
....spamrun finished

[sheldonlg]

sheldonlg wrote:

I don't know which is the best newsgroup for this, so I put it into three.

I have several sites that are working perfectly. When I look at the
statistics for these sites there are huge numbers of 404 errors
tabulated (like 12,000). This is only for sites where I have added the
php coding for the server code. Other sites from this same web company
that do not have php do not have the 404 errors.

Again, there seems to be no error in the operation of the sites where
these errors are being counted. Does anyone have an idea as to what may
be happening here?

I did a little experiment. Going from page to page on this one site
did not produce any additional 404 errors so long as I stayed with html
pages. When I clicked on a menu item that took me into the shopping
card (Zen Cart), the 404 count increased by 7. If I clicked on a Zen
Cart menu item (different category), then it also increased by 7. Since
Zen Cart is written in php, and this doesn't happen in straight html
pages, and I didn't code the Zen Cart application, I am led to believe:

1 - It has something to do with php
2 - I didn't make an coding error to produce these 404 errors.

[Els]

sheldonlg wrote:

I did a little experiment. Going from page to page on this one site
did not produce any additional 404 errors so long as I stayed with html
pages. When I clicked on a menu item that took me into the shopping
card (Zen Cart), the 404 count increased by 7. If I clicked on a Zen
Cart menu item (different category), then it also increased by 7. Since
Zen Cart is written in php, and this doesn't happen in straight html
pages, and I didn't code the Zen Cart application, I am led to believe:

1 - It has something to do with php
2 - I didn't make an coding error to produce these 404 errors.

I think your first next step is to check the error logs to see *which*
pages/files are being called that generate a 404. Then find where in
the code they are called, and figure out why they give a 404.

Could be as simple as a certain directory or set of files not having
the right permissions. Some scripts need to generate new files (cache
for example), which are then called from the same script later. If the
permission on the folder didn't allow the file to be created, it will
not be present when it's called again either, generating a 404.

Switching PHP error notification on might also give a clue straight
away if the above is the case.

Another common cause is images. Images you don't miss because you
never saw them, but which are still called by the script.

--
Els http://locusmeus.com/

[Jukka K. Korpela]

Scripsit sheldonlg:

I don't know which is the best newsgroup for this, so I put it into
three.

Wrong move. The correct move is to think and study until you know the
right group. You could start from reading the group descriptions, or at
least their names.

Followups trimmed to alt.html, in which this issue is least off-topic
(maybe even on-topic by some definition).

I have several sites that are working perfectly.

But you don't reveal the URL of any of them. Anyway, you have
effectively said just that you are a self-confident and do not see the
problems that your sites have. Nothing about reality, just your
attitude.

When I look at the
statistics for these sites there are huge numbers of 404 errors
tabulated (like 12,000).

So is this part of "working perfectly"?

And what _are_ these 404 errors? Any site that really works and is used
to some extent will get 404 errors to some extent, just because people
mistype URLs or set up broken links to your site.

But naturally you can greatly increase their number by "redesigning" the
site and changing all or most URLs. Many organizations do this every two
or three years, spending quite a lot of time, money, and effort in
breaking the site badly. Did you do that?

This is only for sites where I have added
the php coding for the server code.

You're not saying what you have actually done, and you don't even tell
the site URL. Do you _really_ expect to get useful help, or are you just
trolling?

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[sheldonlg]

Jukka K. Korpela wrote:

Scripsit sheldonlg:

>I don't know which is the best newsgroup for this, so I put it into
three.

Wrong move. The correct move is to think and study until you know the
right group. You could start from reading the group descriptions, or at
least their names.

I subscribe to these three sites and regularly read and post to these
sites. I don't know whether this best falls into the alt.html or the
comp.lang.php. I also included the javascript on the chance that this
is what is causing it (less likely)

>
Followups trimmed to alt.html, in which this issue is least off-topic
(maybe even on-topic by some definition).

Frankly, I think that the comp.lang.php is the best group for this.
Others in comp.lang.php have offered php reasons for this. This
illustrates my point of not limiting it to one newsgroup.

>

>I have several sites that are working perfectly.

But you don't reveal the URL of any of them. Anyway, you have
effectively said just that you are a self-confident and do not see the
problems that your sites have. Nothing about reality, just your attitude.

Whatever. The sites are perfoming according to spec from a user's
perspective. I am trying to find out why the admin area shows these 404
s -- that the user does NOT see! Confident? Yes. You want a URL?
Fine. Here is one: www.peglegsurf.com. I don't know how that will
help you, but there it is.

>

>When I look at the
statistics for these sites there are huge numbers of 404 errors
tabulated (like 12,000).

So is this part of "working perfectly"?

The user sees what he is supposed to see and doesn't see any 404 errors.

>
And what _are_ these 404 errors? Any site that really works and is used
to some extent will get 404 errors to some extent, just because people
mistype URLs or set up broken links to your site.

See my experiment that I posted as a self-reply. These are not coming
from mis-typing of URLs. Seven are added with each new php page -- and
from within Zen Cart as well.

>
But naturally you can greatly increase their number by "redesigning" the
site and changing all or most URLs. Many organizations do this every two
or three years, spending quite a lot of time, money, and effort in
breaking the site badly. Did you do that?

This was a new site. There was no redesign.

>

>This is only for sites where I have added
the php coding for the server code.

You're not saying what you have actually done, and you don't even tell
the site URL. Do you _really_ expect to get useful help, or are you just
trolling?

Yes, I would hope to bear upon the wide experience of this group to
possibly give or suggest and answer. I don't troll.

[sheldonlg]

Rik Wasmus wrote:

sheldonlg wrote:

>I don't know which is the best newsgroup for this, so I put it into
three.

I have several sites that are working perfectly. When I look at the
statistics for these sites there are huge numbers of 404 errors
tabulated (like 12,000). This is only for sites where I have added
the php coding for the server code. Other sites from this same web
company that do not have php do not have the 404 errors.

Again, there seems to be no error in the operation of the sites where
these errors are being counted. Does anyone have an idea as to what
may be happening here?

Just check the URLS of those 404's. Most common is some mod_rewrite
rules going haywire, of just lousy url-creation. The worst case I ever
saw was defaulting to a 404 .php page when calling an html page, and
thus providing a different URL for the content, horrible.

Then again, 404's are about the least interesting errors if everything
works OK for the users. Who cares if spiders can't find robots.txt,
browsers no favicon.ico or no index.html?

Thanks Rik. Once again you were a big help. The problem was the calling
of images that were not there. I really don't want those images. I
will have to muck around in Zen Cart code to not call those images.

[Stevo]

sheldonlg wrote:

>>I have several sites that are working perfectly.

Whatever. The sites are perfoming according to spec from a user's
perspective. I am trying to find out why the admin area shows these 404
s -- that the user does NOT see! Confident? Yes. You want a URL?
Fine. Here is one: www.peglegsurf.com. I don't know how that will
help you, but there it is.

That site isn't working perfectly if you ask me. Right from the start
it's using up half a megabyte for 2 jpg images that don't even appear to
be high quality. They should be about 70KB each and you won't even
notice a loss in quality. Then the page tries to load (and I really
cannot believe this) 3.75MB of .wav file for background sound effects.
Just to really grind the bandwidth down, it tries to load the file
twice. So far we're over 4MB of bandwidth and the page hasn't even
finished loading.

Then at the end, there's a 404 plain as day. How come you're not seeing
it ? If you're producing web pages then you must have a http traffic
sniffer like Fiddler or Charles. You can't release a site to a client
without checking it, surely?

The 404 I got was for favicon.ico which is very common and nothing to
worry about, but it will continue generate server log entries until you
put one up.

[Jerry Stuckle]

sheldonlg wrote:

Jukka K. Korpela wrote:

>Scripsit sheldonlg:

>>I don't know which is the best newsgroup for this, so I put it into
three.

Wrong move. The correct move is to think and study until you know the
right group. You could start from reading the group descriptions, or
at least their names.

I subscribe to these three sites and regularly read and post to these
sites. I don't know whether this best falls into the alt.html or the
comp.lang.php. I also included the javascript on the chance that this
is what is causing it (less likely)

>>
Followups trimmed to alt.html, in which this issue is least off-topic
(maybe even on-topic by some definition).

Frankly, I think that the comp.lang.php is the best group for this.
Others in comp.lang.php have offered php reasons for this. This
illustrates my point of not limiting it to one newsgroup.

>>

>>I have several sites that are working perfectly.

But you don't reveal the URL of any of them. Anyway, you have
effectively said just that you are a self-confident and do not see the
problems that your sites have. Nothing about reality, just your attitude.

Whatever. The sites are perfoming according to spec from a user's
perspective. I am trying to find out why the admin area shows these 404
s -- that the user does NOT see! Confident? Yes. You want a URL?
Fine. Here is one: www.peglegsurf.com. I don't know how that will
help you, but there it is.

>>

>>When I look at the
statistics for these sites there are huge numbers of 404 errors
tabulated (like 12,000).

So is this part of "working perfectly"?

The user sees what he is supposed to see and doesn't see any 404 errors.

>>
And what _are_ these 404 errors? Any site that really works and is
used to some extent will get 404 errors to some extent, just because
people mistype URLs or set up broken links to your site.

See my experiment that I posted as a self-reply. These are not coming
from mis-typing of URLs. Seven are added with each new php page -- and
from within Zen Cart as well.

>>
But naturally you can greatly increase their number by "redesigning"
the site and changing all or most URLs. Many organizations do this
every two or three years, spending quite a lot of time, money, and
effort in breaking the site badly. Did you do that?

This was a new site. There was no redesign.

>>

>>This is only for sites where I have added
the php coding for the server code.

You're not saying what you have actually done, and you don't even tell
the site URL. Do you _really_ expect to get useful help, or are you
just trolling?

Yes, I would hope to bear upon the wide experience of this group to
possibly give or suggest and answer. I don't troll.

No, Jukka is correct. You need to do more troubleshooting to find out
what's going on.

And PHP does not produce 404 errors. Missing resources (pages, or, in
your case, images) produce 404's. It may be because your PHP code is
screwed up - but you need to find the cause - THEN post to the
appropriate newsgroup.

Just because you're calling a PHP page doesn't mean the 404 is a PHP
problem.

Keep posting to inappropriate newsgroups without doing your basic
troubleshooting will soon get you a bad reputation - and people will
stop trying to help you.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Ed Jay]

Jerry Stuckle scribed:

>sheldonlg wrote:

>Jukka K. Korpela wrote:

>>Scripsit sheldonlg:

I don't know which is the best newsgroup for this, so I put it into
three.

Wrong move. The correct move is to think and study until you know the
right group. You could start from reading the group descriptions, or
at least their names.

I subscribe to these three sites and regularly read and post to these
sites. I don't know whether this best falls into the alt.html or the
comp.lang.php. I also included the javascript on the chance that this
is what is causing it (less likely)

>>>
Followups trimmed to alt.html, in which this issue is least off-topic
(maybe even on-topic by some definition).

Frankly, I think that the comp.lang.php is the best group for this.
Others in comp.lang.php have offered php reasons for this. This
illustrates my point of not limiting it to one newsgroup.

>>>
I have several sites that are working perfectly.

But you don't reveal the URL of any of them. Anyway, you have
effectively said just that you are a self-confident and do not see the
problems that your sites have. Nothing about reality, just your attitude.

Whatever. The sites are perfoming according to spec from a user's
perspective. I am trying to find out why the admin area shows these 404
s -- that the user does NOT see! Confident? Yes. You want a URL?
Fine. Here is one: www.peglegsurf.com. I don't know how that will
help you, but there it is.

>>>
When I look at the
statistics for these sites there are huge numbers of 404 errors
tabulated (like 12,000).

So is this part of "working perfectly"?

The user sees what he is supposed to see and doesn't see any 404 errors.

>>>
And what _are_ these 404 errors? Any site that really works and is
used to some extent will get 404 errors to some extent, just because
people mistype URLs or set up broken links to your site.

See my experiment that I posted as a self-reply. These are not coming
from mis-typing of URLs. Seven are added with each new php page -- and
from within Zen Cart as well.

>>>
But naturally you can greatly increase their number by "redesigning"
the site and changing all or most URLs. Many organizations do this
every two or three years, spending quite a lot of time, money, and
effort in breaking the site badly. Did you do that?

This was a new site. There was no redesign.

>>>
This is only for sites where I have added
the php coding for the server code.

You're not saying what you have actually done, and you don't even tell
the site URL. Do you _really_ expect to get useful help, or are you
just trolling?

Yes, I would hope to bear upon the wide experience of this group to
possibly give or suggest and answer. I don't troll.

No, Jukka is correct. You need to do more troubleshooting to find out
what's going on.

And PHP does not produce 404 errors. Missing resources (pages, or, in
your case, images) produce 404's. It may be because your PHP code is
screwed up - but you need to find the cause - THEN post to the
appropriate newsgroup.

Just because you're calling a PHP page doesn't mean the 404 is a PHP
problem.

Keep posting to inappropriate newsgroups without doing your basic
troubleshooting will soon get you a bad reputation - and people will
stop trying to help you.

When I look at a site's error log using cPanel, it informs me which file or
image or whatever was missing and caused the 404 error. Does the OP's error
log provide the same information? Has the OP scrolled the error log to see
the entire log entry? Perhaps he should.
--
Ed Jay (remove 'M' to respond by email)

[sheldonlg]

Stevo wrote:

sheldonlg wrote:

>>>I have several sites that are working perfectly.

Whatever. The sites are perfoming according to spec from a user's
perspective. I am trying to find out why the admin area shows these
404 s -- that the user does NOT see! Confident? Yes. You want a
URL? Fine. Here is one: www.peglegsurf.com. I don't know how that
will help you, but there it is.

That site isn't working perfectly if you ask me. Right from the start
it's using up half a megabyte for 2 jpg images that don't even appear to
be high quality. They should be about 70KB each and you won't even
notice a loss in quality. Then the page tries to load (and I really
cannot believe this) 3.75MB of .wav file for background sound effects.
Just to really grind the bandwidth down, it tries to load the file
twice. So far we're over 4MB of bandwidth and the page hasn't even
finished loading.

Then at the end, there's a 404 plain as day. How come you're not seeing
it ? If you're producing web pages then you must have a http traffic
sniffer like Fiddler or Charles. You can't release a site to a client
without checking it, surely?

The 404 I got was for favicon.ico which is very common and nothing to
worry about, but it will continue generate server log entries until you
put one up.

I don't do the front-end stuff. I only do the php side, and an occation
bit of javascript as needed, so all those MBs that you talk about, well
I'll pass that info on to the web company that does it. I don't know
why I am not getting a 404 while you are. As for "releasing it tot he
client", he IS the client and HE does all that front end. I just do the
back end for him.

[sheldonlg]

Ed Jay wrote:

Jerry Stuckle scribed:

>sheldonlg wrote:

>>Jukka K. Korpela wrote:
Scripsit sheldonlg:

I don't know which is the best newsgroup for this, so I put it into
three.
Wrong move. The correct move is to think and study until you know the
right group. You could start from reading the group descriptions, or
at least their names.
I subscribe to these three sites and regularly read and post to these
sites. I don't know whether this best falls into the alt.html or the
comp.lang.php. I also included the javascript on the chance that this
is what is causing it (less likely)

Followups trimmed to alt.html, in which this issue is least off-topic
(maybe even on-topic by some definition).
Frankly, I think that the comp.lang.php is the best group for this.
Others in comp.lang.php have offered php reasons for this. This
illustrates my point of not limiting it to one newsgroup.

I have several sites that are working perfectly.
But you don't reveal the URL of any of them. Anyway, you have
effectively said just that you are a self-confident and do not see the
problems that your sites have. Nothing about reality, just your attitude.
Whatever. The sites are perfoming according to spec from a user's
perspective. I am trying to find out why the admin area shows these 404
s -- that the user does NOT see! Confident? Yes. You want a URL?
Fine. Here is one: www.peglegsurf.com. I don't know how that will
help you, but there it is.

When I look at the
statistics for these sites there are huge numbers of 404 errors
tabulated (like 12,000).
So is this part of "working perfectly"?
The user sees what he is supposed to see and doesn't see any 404 errors.

And what _are_ these 404 errors? Any site that really works and is
used to some extent will get 404 errors to some extent, just because
people mistype URLs or set up broken links to your site.
See my experiment that I posted as a self-reply. These are not coming
from mis-typing of URLs. Seven are added with each new php page -- and
from within Zen Cart as well.

But naturally you can greatly increase their number by "redesigning"
the site and changing all or most URLs. Many organizations do this
every two or three years, spending quite a lot of time, money, and
effort in breaking the site badly. Did you do that?
This was a new site. There was no redesign.

This is only for sites where I have added
the php coding for the server code.
You're not saying what you have actually done, and you don't even tell
the site URL. Do you _really_ expect to get useful help, or are you
just trolling?

Yes, I would hope to bear upon the wide experience of this group to
possibly give or suggest and answer. I don't troll.

No, Jukka is correct. You need to do more troubleshooting to find out
what's going on.

And PHP does not produce 404 errors. Missing resources (pages, or, in
your case, images) produce 404's. It may be because your PHP code is
screwed up - but you need to find the cause - THEN post to the
appropriate newsgroup.

Just because you're calling a PHP page doesn't mean the 404 is a PHP
problem.

Keep posting to inappropriate newsgroups without doing your basic
troubleshooting will soon get you a bad reputation - and people will
stop trying to help you.

When I look at a site's error log using cPanel, it informs me which file or
image or whatever was missing and caused the 404 error. Does the OP's error
log provide the same information? Has the OP scrolled the error log to see
the entire log entry? Perhaps he should.

Well (OP here), I learn things all the time. This time I learned how to
track down where the 404s are coming from. Yes, I did it now and it is
coming from missing images coming out out the Zen Cart configuration.
Had I known how before, I wouldn't have had to post -- but that is why
this group is go great. I learn new things all the time.

[Gregor Kofler]

sheldonlg meinte:

I don't do the front-end stuff. I only do the php side, and an occation
bit of javascript as needed, so all those MBs that you talk about, well
I'll pass that info on to the web company that does it. I don't know
why I am not getting a 404 while you are. As for "releasing it tot he
client", he IS the client and HE does all that front end. I just do the
back end for him.

Is the markup is generated by your PHP scripts? Frankly, it's the pits -
44 warnings,generated by markup like this:

[...]
</HEAD>
<div id="apDiv1">
<div align="center" class="style3 "... </div>
</div>
</BODY>
</HTML></div>
</DIV>
</BODY>
</HTML>
Gregor

--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[sheldonlg]

Gregor Kofler wrote:

sheldonlg meinte:

>I don't do the front-end stuff. I only do the php side, and an
occation bit of javascript as needed, so all those MBs that you talk
about, well I'll pass that info on to the web company that does it. I
don't know why I am not getting a 404 while you are. As for
"releasing it tot he client", he IS the client and HE does all that
front end. I just do the back end for him.

Is the markup is generated by your PHP scripts?

No, it is not. The PHP is only for the backend stuff. In this
particular case it is basically just the Zen Cart which I configured for
him. I have tried to get him to improve his html......but he is the one
paying the freight, so I just stick to doing what I am paid for after
giving the suggestion two or three times. Any more than that and I
would endanger my getting the php work.