Need help to do an upgrade from 1.5.0 to 1.5.5

[mc12345678]

More than likely it is in your .htaccess at the root of the domain. It could also be in the sub-folder of that domain.

[CaroleAs]

More than likely it is in your .htaccess at the root of the domain. It could also be in the sub-folder of that domain.

There is one file on the root of the domain but both sites are on that, one with the /store/ and the other /storetest/.
I have one .htaccess at the root of the /store/ but not for /storetest/. Where should i compare??

[CaroleAs]

Just in case (trial and error here), i compared the .htaccess file from the root of the domain, to the .htaccess inside the /storetest/ installation.
I see these lines that are in the /storetest/ file only:

RewriteCond %{REMOTE_HOST} !^142\.167\.20\.37 <-- this looks like my IP but since i have a dynamic IP, right now, it is not the right one. So should i remove that? Changing it to my IP of today might block me again in the future.

Then, i see this line on the "original"
RewriteRule .* - [F]

but this in the /storetest/
RewriteRule (.*)$ http://www.creationcassel.com/store [R=301,L] <-- which looks like it might be a 301 redirect to the live store. Should i remove that and replace it with what is in the .htaccess of the root?

Would that grant me access to the store or will that cause other problems?

[mc12345678]

There is one file on the root of the domain but both sites are on that, one with the /store/ and the other /storetest/.
I have one .htaccess at the root of the /store/ but not for /storetest/. Where should i compare??

Just in case (trial and error here), i compared the .htaccess file from the root of the domain, to the .htaccess inside the /storetest/ installation.
I see these lines that are in the /storetest/ file only:

RewriteCond %{REMOTE_HOST} !^142\.167\.20\.37 <-- this looks like my IP but since i have a dynamic IP, right now, it is not the right one. So should i remove that? Changing it to my IP of today might block me again in the future.

Then, i see this line on the "original"
RewriteRule .* - [F]

but this in the /storetest/
RewriteRule (.*)$ http://www.creationcassel.com/store [R=301,L] <-- which looks like it might be a 301 redirect to the live store. Should i remove that and replace it with what is in the .htaccess of the root?

Would that grant me access to the store or will that cause other problems?

First there seems to be a discrepancy between the two posts. First says no htaccess in the storetest directory, second says there is, so which is it?

Second thing is that the one in the store directory does do a redirect for all visitors no matter what file/directory they are trying to reach.
At this point it depends on how you want to proceed and what you want to do/be able to do. You could rename the folder and change the associated configure.php files, create the store folder again and place that htaccess there so that it continues to redirect like it always has been and then setup/establish the renamed folder to do like you are doing with your test location to prevent indexing and to indicate that the location is not a "functional" site.

You could also make the admin folder accessible by not redirecting if the admin folder has been chosen/used to access the site. Could also add a "temporary" ip redirect as part of that or not that... temporary because of the non-dedicated ip address and would have to be changed whenever your ip address changed.

As to the htaccess in the root, it too could have something in it that prevents access as htaccess files are somewhat similar to interfere with access to the store directory or once there to have caused an unexpected/undesired action.

All depends on how you want to have things set up.

[CaroleAs]

First there seems to be a discrepancy between the two posts. First says no htaccess in the storetest directory, second says there is, so which is it?

You are right. I reversed the two; one file in the domain itself and one on the /storetest/ but none in the /store/

Second thing is that the one in the store directory does do a redirect for all visitors no matter what file/directory they are trying to reach.
At this point it depends on how you want to proceed and what you want to do/be able to do. You could rename the folder and change the associated configure.php files, create the store folder again and place that htaccess there so that it continues to redirect like it always has been and then setup/establish the renamed folder to do like you are doing with your test location to prevent indexing and to indicate that the location is not a "functional" site.

You could also make the admin folder accessible by not redirecting if the admin folder has been chosen/used to access the site. Could also add a "temporary" ip redirect as part of that or not that... temporary because of the non-dedicated ip address and would have to be changed whenever your ip address changed.

As to the htaccess in the root, it too could have something in it that prevents access as htaccess files are somewhat similar to interfere with access to the store directory or once there to have caused an unexpected/undesired action.

All depends on how you want to have things set up.

Since i am not expecting a ton of visitors from Google in the storetest, maybe i could set it to be "normal", but i'd just put it in maintenance mode so i could work on it as a normal site.

On the "root" file, it has these lines that are not in the /storetest/ one:

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index_error.php [F,L]
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

and

order allow,deny
deny from 80.82.78.57
allow from all

So what would be the process to get a "live" store that i can put in maintenance mode and work as if it were the live one?

[mc12345678]

The information in your root htaccess (provided at the end of the previous post) offers some security for your site in the first "batch", the second one denies access to the site for a specific ip address. I haven't looked up to what that address belongs, but it's there.

Removal of the htaccess (by renaming or removing from the server) from the storetest directory will restore access to the site. The password has more than likely expired for the admin account(s) for that store which would still allow attempt to access if you recall it, or otherwise require "reset" by way of: http://www.zen-cart.com/content.php?44

[CaroleAs]

The information in your root htaccess (provided at the end of the previous post) offers some security for your site in the first "batch", the second one denies access to the site for a specific ip address. I haven't looked up to what that address belongs, but it's there.

Removal of the htaccess (by renaming or removing from the server) from the storetest directory will restore access to the site. The password has more than likely expired for the admin account(s) for that store which would still allow attempt to access if you recall it, or otherwise require "reset" by way of: http://www.zen-cart.com/content.php?44

I just renamed the .htaccess file to _.htaccess and now, it does not even display the store (test):
http://creationcassel.com/storetest/

I didn't change anything else. Am i missing a file somewhere?
Before it was locked on me, it was readily accessible.

[mc12345678]

I just renamed the .htaccess file to _.htaccess and now, it does not even display the store (test):
http://creationcassel.com/storetest/

I didn't change anything else. Am i missing a file somewhere?
Before it was locked on me, it was readily accessible.

Don't know if you put it back or because of cache on my device, but when I attempted to go to the link I was redirected to your main store. If it wasn't put back, then two things. Power of the 301 redirect is at play and/or as always when get a blank or partial blank screen: http://www.zen-cart.com/content.php?124-blank-page

[CaroleAs]

Don't know if you put it back or because of cache on my device, but when I attempted to go to the link I was redirected to your main store. If it wasn't put back, then two things. Power of the 301 redirect is at play and/or as always when get a blank or partial blank screen: http://www.zen-cart.com/content.php?124-blank-page

It loads this for me:
Hello. Thank you for loading Zen Cart®.

You are seeing this page for one or more reasons:
...

I found part of the problem. The config files for this cloned store were never changed (obviously, it was locked), but the whole store was somehow, transfered when i changed host, so the DB info was incorrect, the path was incorrect, etc. I fixed that on both config files BUT, i have no clue what the DB_SERVER_PASSWORD is (obviously, it is not correct). So i am trying to figure out where it is or how i can change it.

[mc12345678]

It loads this for me:
Hello. Thank you for loading Zen Cart®.

You are seeing this page for one or more reasons:
...

I found part of the problem. The config files for this cloned store were never changed (obviously, it was locked), but the whole store was somehow, transfered when i changed host, so the DB info was incorrect, the path was incorrect, etc. I fixed that on both config files BUT, i have no clue what the DB_SERVER_PASSWORD is (obviously, it is not correct). So i am trying to figure out where it is or how i can change it.

Actually from "our" perspective (viewers of this forum thread) the information provided from that message does not suggest anything directly obvious other than that there is some error in the installation. The details that are provided towards the bottom of that message are what give the clues needed to the reader.

Of course you're familiar with your own sites history so you can fill in the blanks, but providing just the top of that message does not give a lot of detail to the inquiring minds. :)

As to database access, well if the database actually did survive the/a move, you could always establish/re-establish credentials for that particular database. Be careful though, because you may have assigned the same user to have access say as your live site, and if you go and modify the password to work on your test site it may prevent access to your live site (unknowingly), so check the facts and/or create a new user with credentials, etc... keep your live site chugging as much as you can.