path routing problem with the hosting

I can not get out of this situation, I tried but nothing seems to zencart does everything to give a 302 and then 404 as an error if the product does not even exist in the online demo is always a rederict 302 to 404. This is not normal and is probably the cause of my problems that I can not get rid of products exist where I can not make a rederict 301. But where there is a url rewriting of the 404 works well does not make the first 302 is directly as a 404 error.
I hope someone will give me the solution. Thanks Gio

Here's an example of a demo of zencart where product ID does not exist from a 302 and then a 404 something completely useless to give a 302 before.

https://www.zen-cart-pro.net/templat...ducts_id=34522

Attachment 16321

Recently I helped someone to do a sort of redirect. The first attempt also was to modify the main_template_vars file because it made sense as that was where the data was "determined" to be correct, but a similar issue occurred (headers already sent). This has to do with the sequence of information loaded and that such a redirect (at least a specific one like you are trying to do) ought to be handled in the header related file(s). While the responsive template may have some factor in the issue, my suggestion would be to do your test/check in the header_php.php file before the notifier at the end and redirect from there.

Now I am not aware of what all else is going on regarding the 302/404 issue, which seems to be a unique problem to the software/server side. There has been discussion about possible differences between your live site and your local one, but no identification of specifically those differences. I suggest that you find a comparison tool and identify any differences between the two sites including but not limited to the contents of each file as well as files that exist on one server and not the other. In some cases, and often, names of files are changed to make them "old" but the change does not prevent the file from loading because of the file's extension and the location in which it remains. Feel free to post the filenames and discrepancies to obtain further assistance.

Hello MC thank you for answering, I can understand everything but admit chese if a product does not exist instead of getting a 404 I get before a rederict 302. This has affected me for years since I removed the rewrite url. Now I've lost so many location on google ranking that I wonder why no one talks about it and nobody knows what to do to remove this rederict 302 before getting a 404.

Quote:

---

Originally Posted by diamond1

Hello MC thank you for answering, I can understand everything but admit chese if a product does not exist instead of getting a 404 I get before a rederict 302. This has affected me for years since I removed the rewrite url. Now I've lost so many location on google ranking that I wonder why no one talks about it and nobody knows what to do to remove this rederict 302 before getting a 404.

---

This is information that was not previously provided (among a number of other things that would lead to a solution). First of all, ZC (at least currently) only uses a 302 redirect within the paypalwpp.php file.... So, any 302 redirect other than an issue with paypal processing is brought on by something else on your system. One way to try to identify what code exists on your server that may offer the 302 redirect is from your admin, goto tools->Developers toolkit, then in the bottom left fill in 302, select catalog on the dropdown, then search... Haven't spoken about what version of ZC you are currently using, or perhaps so and I haven't gone through all of the posts specifically for that tidbit, but that search should identify includes/modules/payment/paypalwpp.php as having a 302 redirect and perhaps whatever else is causing yours. The next thing is that you said you "removed the rewrite url", you haven't identified which one was installed, and more than likely remnants of that url rewriter still exist on your system and that is a large part of what you are experiencing.

The why others haven't? Well, they haven't come across the issue, haven't looked, or when they have attempted to do what is stated above about removal of the software they were successful at fully removing it. It is again one reason why the upgrade process (BTW 1.5.5.a is out now) suggests basically to do a clean install of the software, integrate the needed plugins and other minor software modifications so that old/unused plugins don't interact.

Hello MC, has nothing to do with the 1.5.5a version, if you see all of the online demo version have the probleme, that if a product id does not exist does not provide a 404 but first a 302 and then a 404 as an error. as far as my version is a new 1,5,4 never did a rewrite url. I ask you to check the link above to me and you'll see that makes a 302 before and after going to page 404

diamond1,
Did you search using the developers tool kit for "302"??
If so, what were the results?

Hello Kobra, No rederict 302 apart on paypalwpp.php file. But this does not justify why it does, if you see any zencart demo we have the same result ie if the product does not exist does a 302 and then a 404 even if we do not find other header ("HTTP / 1.1 302 Object Moved"); apart on paypal

So had done a little research yesterday, but thing is I was having difficulty finding one piece of the puzzle. Have you confirmed that the 302 followed by 404 occurs even as the first visit to the site? I ask because of some of the standard operations that occur.

Generally speaking I found only two places that really addressed the "missing product" condition. The first that a guest is expected to come across is the sanitizer. But the conditions of the sanitizer appear to not play a factor on first visit, though I didn't look to see if the sanitizer is double run by ZC. So, if run once per "page" load, then on first visit it sets a session variable that would be used later to do a different action.

The second place found as related to the specific url provided was the header_php.php for product_info (includes/modules/pages/product_info/header_php.php) where the "first" line checks if the product exists and if not modifies the header to provide a 404.

So then, one asks, so whee's the 302? Well, a header sent with a location like is used to redirect will without other direction issue a 302 based on the php.net documentation on the header function. But, in the above process of establishing a "first" visit or as seen/detected by a SE which is not supposed to get an established session, there does not appear to be an action that would so automatically issue the 302 (no redirect action that would do/cause that). The only thing that appears could cause a 302 to be issued with a 404 in a non-session based visit is settings on the server that issue a 302 when a 404 is issued which based on the limited read of the php manual on the header function are either server based or controllable by the php.ini.

In summary, a "white-hat" SE or a recognized one will not start a session and therefore will not see the 302 of a redirect because of a non-existent product, but instead see the 404 as provided by the settings of the host server making the 302 followed by 404 a non-issue for such "visitors" but instead something seen by those with a session like a browsing customer.

Mc, I did not understand it is the fault of the server settings of the php.ini file? so those using zen cart have this problem of 302 before 404? How to avoid this?

Quote:

---

Originally Posted by diamond1

Mc, I did not understand it is the fault of the server settings of the php.ini file? so those using zen cart have this problem of 302 before 404? How to avoid this?

---

So I think you missed the bigger picture, but to be sure. What is it about the 302/404 that you as a visitor that is not indexing or ranking your site but see this response are trying to correct or prevent?

As to the "settings" at the moment all I have is what I found while reviewing the php manual on the header function regarding the special case of say an http/ request.