Configuration issue - odd

[buildingblocks]

We have a site which has been using the hosts ssl connection as their https server.

Ex: https://subdomain.hosts-site-name.com

Apparently the setup had been working but now all of the secured pages; login, checkout, my account pages etc. load a 500 error page.

What is really odd is, I set ENABLE_SSL to false in both configure files. That did not stop the store pages from using the https server url. Next I replaced the HTTPS_SERVER url with the actual zen cart http website url in both configure files. Still no change on the front end.

The host is saying misconfiguration somewhere and "upload configuration for the shopping cart"

The configuration changes I have made do not affect the front end. Any ideas what could account for this?

Wondering, if I was in the correct ftp account I made some text changes to the define_main_page.php file. The text change does not show on the home page BUT I can see the text change I made in the admin define page editor, so I know I'm in the correct ftp account. The server IP hadn't been changed.

[mc12345678]

We have a site which has been using the hosts ssl connection as their https server.

Ex: https://subdomain.hosts-site-name.com

Apparently the setup had been working but now all of the secured pages; login, checkout, my account pages etc. load a 500 error page.

What is really odd is, I set ENABLE_SSL to false in both configure files. That did not stop the store pages from using the https server url. Next I replaced the HTTPS_SERVER url with the actual zen cart http website url in both configure files. Still no change on the front end.

The host is saying misconfiguration somewhere and "upload configuration for the shopping cart"

The configuration changes I have made do not affect the front end. Any ideas what could account for this?

Wondering, if I was in the correct ftp account I made some text changes to the define_main_page.php file. The text change does not show on the home page BUT I can see the text change I made in the admin define page editor, so I know I'm in the correct ftp account. The server IP hadn't been changed.

Couple of things. One is did you clear the cache of the browser after changing the includes/configure.php file's secure setting to 'false' or try a different browser?

Secondly, after changing it to false, HTTPS_SERVER is no longer a factor in a new session.

Perhaps the site address could be shared so that an independent evaluation could be made?

As for the SSL certificate, has it expired/not been renewed? Did it change from a wildcard certificate to something else?

Forgot to also ask: what PHP version? Isn't it about time to upgrade to the latest ZC version? At least one that has been released in the last year or worse two?

[buildingblocks]

Hi

PHP Version: 5.3.13 (Zend: 2.3.0). Yes, I am going to recommend upgrade but this issue was so odd I wanted to get to the bottom of it before doing anything else in case it turned out to be a server configuration problem.

I did clear cache. I tried viewing in a different browser, I tried using a browsing proxy. BUT

The hosting account is a mess. There are backups all over the place. The backups are in the form of copies of the public_html folder.

I have been in

/public_html/shop/


I just discovered this is where the shop resides.

/public_html/public_html/newsite/shop/


I discovered this when I moved the /public_html/public_html folder and the site could no longer be found. I moved it back and the site loaded. Not sure what's going to happen if I move /shop/ from

/public_html/public_html/newsite/shop/

to where it belongs so all the garbage can be cleaned up. Going to talk to the site owner on my findings. I updated the configure files in

/public_html/public_html/newsite/shop/

and the error pages have stopped.

Thanks for responding.

[bislewl]

Hi

PHP Version: 5.3.13 (Zend: 2.3.0). Yes, I am going to recommend upgrade but this issue was so odd I wanted to get to the bottom of it before doing anything else in case it turned out to be a server configuration problem.

I did clear cache. I tried viewing in a different browser, I tried using a browsing proxy. BUT

The hosting account is a mess. There are backups all over the place. The backups are in the form of copies of the public_html folder.

I have been in

/public_html/shop/


I just discovered this is where the shop resides.

/public_html/public_html/newsite/shop/


I discovered this when I moved the /public_html/public_html folder and the site could no longer be found. I moved it back and the site loaded. Not sure what's going to happen if I move /shop/ from

/public_html/public_html/newsite/shop/

to where it belongs so all the garbage can be cleaned up. Going to talk to the site owner on my findings. I updated the configure files in

/public_html/public_html/newsite/shop/

and the error pages have stopped.

Thanks for responding.

Which version of Zencart are you running? Zend and ZenCart are 2 separate items.

[buildingblocks]

Which version of Zencart are you running? Zend and ZenCart are 2 separate items.

1.3.9h. The cart is now able to process payments again but the folder path isn't correct yet.

originally it was and should be

/public_html/shop/


They had site trouble and were using backups to try to fix things and somehow ended up with

/public_html/public_html/newsite/shop/


The issue now is to get that straightened out in the next day or so.

[RodG]

1.3.9h. The cart is now able to process payments again but the folder path isn't correct yet.

If the site is working then the folder path in the configuration files is correct for *that* installation.

originally it was and should be
/public_html/shop/

They had site trouble and were using backups to try to fix things and somehow ended up with
/public_html/public_html/newsite/shop/

Not particularly hard to do if a close eye isn't kept on the source/destination folders when using FTP.

The issue now is to get that straightened out in the next day or so.

Shouldn't be difficult.
Step#1. Make a backup of the entire site (everything in the 'first' public_html folder and below)
Step#2. Delete *everything* in the /public_html/shop/ folder.
Step#3. Copy (or move) everything in the /public_html/public_html/newsite/shop/ folder to the (now empty) /public_html/shop/ folder.
Step#4. Edit the two configure.php files by removing all references to /public_html/newsite/shop/ and replacing them with /shop/
Step#5. Check that the store is functioning correctly.
Step#5b If the site version is V1.5.1 or older install and run the fix Cache Key mod
http://www.zen-cart.com/downloads.php?do=file&id=8
Step#6. Delete the 'public_html' folder that resides in the 1st 'public_html' folder (IOW, get rid of the 'nesting').
Step#7. Check that all is still OK with the site.
Step#8. Celebrate your success with an ice cold beer (or whatever turns you on). :)
Step#9. Make another backup of the public_html folder and all it contains (as this will help avoid any future confusion should you ever need to perform a restore).


Cheers
RodG

[buildingblocks]

If the site is working then the folder path in the configuration files is correct for *that* installation.



Not particularly hard to do if a close eye isn't kept on the source/destination folders when using FTP.



Shouldn't be difficult.
Step#1. Make a backup of the entire site (everything in the 'first' public_html folder and below)
Step#2. Delete *everything* in the /public_html/shop/ folder.
Step#3. Copy (or move) everything in the /public_html/public_html/newsite/shop/ folder to the (now empty) /public_html/shop/ folder.
Step#4. Edit the two configure.php files by removing all references to /public_html/newsite/shop/ and replacing them with /shop/
Step#5. Check that the store is functioning correctly.
Step#5b If the site version is V1.5.1 or older install and run the fix Cache Key mod
http://www.zen-cart.com/downloads.php?do=file&id=8
Step#6. Delete the 'public_html' folder that resides in the 1st 'public_html' folder (IOW, get rid of the 'nesting').
Step#7. Check that all is still OK with the site.
Step#8. Celebrate your success with an ice cold beer (or whatever turns you on). :)
Step#9. Make another backup of the public_html folder and all it contains (as this will help avoid any future confusion should you ever need to perform a restore).


Cheers
RodG

Everything went well and pretty much as you described except the configure files still had the original path. Someone had changed things in domain central and pointed the domain name to

/public_html/public_html/newsite/shop/

All set now. A glass of wine sounds good to me :)

[RodG]

Everything went well and pretty much as you described except the configure files still had the original path. Someone had changed things in domain central and pointed the domain name to

/public_html/public_html/newsite/shop/

It did actually cross my mind that someone may have done this, but I refrained from mentioning it because
1) I didn't think anyone would ever set the document root to 'public_html/public_html' (which I'm guessing is what you mean by 'pointing the domain name to')

and
2) I figured that mentioning this as a possibility would make things a lot more complicated than it needed to be.

All set now. A glass of wine sounds good to me :)

You deserve several glasses for figuring this out without asking for further help. It isn't a common 'end user' type scenario.

Thanks for the update and the additional info though. It's always good to know that a thread can be 'closed' with a full resolution.

Cheers
RodG

[buildingblocks]

1) I didn't think anyone would ever set the document root to 'public_html/public_html' (which I'm guessing is what you mean by 'pointing the domain name to')

That's exactly what I meant. Thanks for the term correction :) It was interesting getting it untangled and was a first to see an account so scrambled up.