How are admin files managed when a site is manually re-installed on a shared serve?

I was ready to release a site to the public (and a financial contribution to the ZC organization) when I realized that some change I had made was causing PHP memory to exceed its allotment in a shared hosting environment. Therefore, I'm having to reinstall on shared server. I've tried making the reinstall by changing the configure files relative to a new database and changing the domain's physical path. That works when moving between domains in a single hosting account in a shared hosting environment. That doesn't work when reinstalling on a shared server. I'm required to use the www.domain_name/zc_install technique. The problem is that there's a preexisting admin directory that's connected to a vastly changed set of files elsewhere. That admin directory's name was changed on the original installation, as advised. However, after that initial installation I deleted the zc_install folder. So I immediately have two questions.

(1) Can I use the zc_install folder on an archival copy of the initial install (the archival zc_install folder was renamed, so my re-use of it presumes its renaming)? In other words can I copy that (archival) folder to the root folder (of the new install) so that the www.domain_name/zc_install has a folder to find?

(2) The manual install generates a new admin folder, which can only occur because the preexisting admin folder was renamed after the initial install. Before commencing the new install, what should I do with that preexisting admin folder to retain its connections to all other files?

cyberbaffled:

I was ready to release a site to the public (and a financial contribution to the ZC organization) when I realized that some change I had made was causing PHP memory to exceed its allotment in a shared hosting environment. Therefore, I'm having to reinstall on shared server. I've tried making the reinstall by changing the configure files relative to a new database and changing the domain's physical path. That works when moving between domains in a single hosting account in a shared hosting environment. That doesn't work when reinstalling on a shared server. I'm required to use the www.domain_name/zc_install technique. The problem is that there's a preexisting admin directory that's connected to a vastly changed set of files elsewhere. That admin directory's name was changed on the original installation, as advised. However, after that initial installation I deleted the zc_install folder. So I immediately have two questions.

(1) Can I use the zc_install folder on an archival copy of the initial install (the archival zc_install folder was renamed, so my re-use of it presumes its renaming)? In other words can I copy that (archival) folder to the root folder (of the new install) so that the www.domain_name/zc_install has a folder to find?

(2) The manual install generates a new admin folder, which can only occur because the preexisting admin folder was renamed after the initial install. Before commencing the new install, what should I do with that preexisting admin folder to retain its connections to all other files?

While the above identifies a relatively common problem (difficulty following published directions directions on how to move a site) there are several things missing. What version of zc is being addressed? How was the original cart installed, and other items in the posting guidelines. What instructions were attempted to be followed and what step was a problem encountered or not understood?

Assuming that this is/was a 1.5.x install, the content of the directory named admin is not essential except for the admin/includes/configure.php file assuming you still have a copy of your old admin (renamed) directory. If that old admin (renamed) is on this server, then the new directory named admin can be renamed to a not yet existing directory, the old admin renamed to admin, a copy of zc_install placed back onto the server and the configure.php file identified above stored in the new admin/includes directory to replace the configure.php file that is there. This also assumes that the version of the new code is the same as the old in all respects.

As to the claim that the installation/modification of configure.php files doesn't work under shared hosting seems false. If the program works by manual install it will work if the configure.php files are modified to suit the newly installed version. The installation process doesn't do anything different than the directions advise. Provision of applicable paths (maintaining any desired security of disclosure) would be additional information applicable to solve this problem.

Thank you for your thought provoking reply.

Using the FAQ titled: "I want to move my Zen Cart installation to another host or a different server" I went through the process as closely as I could understand, and got a home page with almost but not entirely nothing of my preexisting site page.

My preexisting site installed on shared hosting worked perfectly through the Paypal process and the zc post-payment page. Then, for reasons I could not trace, it began crashing at the login step immediately before entering the purchase process. The error appearing in the cache file was that the site had exceeded its PHP memory allotment. I added code to trace the error's source, thinking there was a loop, but the trace ended innocuously in the default-template arena of tpl_box_default_left, tpl_columnar_display, and tpl_whats_new. I had previously removed the "featured" and "new" left column displays because they aren't appropriate to the site in its current state. However, those changes appeared correctly on the home page. The site crashed at the login process, with PHP demanding 20mg of memory more than my hosting account allowed. So I decided that I couldn't pursue the crash's cause further without providing that extra 20mg of PHP memory. That's the decision that delivered me into the shared server environment and the post originating this discussion.

Anyway, I'll go through the list of posting protocols one by one, but it will take me awhile. Not tomorrow or the next day probably. I have other responsibilities demanding my attention.

cyberbaffled:

Thank you for your thought provoking reply.

Using the FAQ titled: "I want to move my Zen Cart installation to another host or a different server" I went through the process as closely as I could understand, and got a home page with almost but not entirely nothing of my preexisting site page.

My preexisting site installed on shared hosting worked perfectly through the Paypal process and the zc post-payment page. Then, for reasons I could not trace, it began crashing at the login step immediately before entering the purchase process. The error appearing in the cache file was that the site had exceeded it PHP memory allotment. I added code to trace the errors source, thinking there was a loop, but the trace ended innocuously in the default-template arena of tpl_box_default_left, tpl_columnar_display, and tpl_whats_new. I had previously removed the "featured" and "new" left column displays because they aren't appropriate to the site in its current state. However, those changes appeared correctly on the home page. The site crashed at the login process, with PHP demanding 20mg of memory more than my hosting account allowed. So I decided that I couldn't pursue the crash's cause further without providing that extra 20mg of PHP memory.

Anyway, I'll go through the list of posting protocols one by one, but it will take me awhile. Not tomorrow or the next day probably. I have other responsibilities absorbing my time.

So, based on that... Please advise on the ZC version and the PHp version... It is possible that you were/are chasing your tail on this. There are some base compatibilities of ZC and a knownissue with one combination.

mc12345678:

So, based on that... Please advise on the ZC version and the PHp version... It is possible that you were/are chasing your tail on this. There are some base compatibilities of ZC and a knownissue with one combination.

Thank you again for your prompt reply.

It's PHP 5.3.3 and ZC 1.5.0.

CORRECTION. Previously I stated: "I added code to trace the error's source, thinking there was a loop, but the trace ended innocuously in the default-template arena of tpl_box_default_left, tpl_columnar_display, and tpl_whats_new." That's incorrect. I added the trace to determine how to remove "[More]" from the left column, which is why the trace ended in the "arena" described. I never attempted to trace what was executing when the site crashed. I needed more of PHP's error investigating capabilities than my shared hosting account allowed. That, along with obtaining additional PHP memory, was the reason I decided to move the site to a shared server.

The simplest way to trace and remove the [more] link would be to use the Developers Toolkit in admin > Tools. Paste the offending text [more] in the lower left box, select all files and search. This will show the language file where the text is defined, and you can change its definition from '[more]' to '' (nothing).

If you want to go further and eliminate the link from being created in the first place, you can use the DTK again to find the file(s) where the constant defined as '[more]' is used, and remove the code that calls it when appropriate.

Whatever you do, save the modified file(s) in your template override directories rather than replacing the original version of the file.

gjh42g, it's good to hear from you again. I've done what you suggest, but the second part of your solution necessitates deconstruction of a complex address, which is what I was attempting when I got into the tpl "arena" I mention. There's no block of code that can be commented out such as is the case for "featured" products and the list of "new" products that occurs without having to use the [more] link.

I would like to suspend this discussion until I can determine whether or not my problems with the shared server are caused by an inability to link to the database. It's possible I've succeeded with a manual install but am now dealing with a database problem. Hopefully, the forum moderator can flag this discussion as solved. If in fact it has not been solved, I'll reinitiate it at a later time.