Parallels Centos server failures: admin page & image fails; IE&Firefox mis-displays

[cyberbaffled]

After a great deal of work using a hosted server I got an ecommerce site to display identically on IE, Firefox, and Chrome. Everything functioned correctly until a purchase was made. Then the software crashed for lack of PHP memory. To gain this memory I had to place the site on a Parallels Centos virtual shared server. Now the application works correctly through the entire purchase, payment, and Thank You - Appreciate page. However, the administration utility fails upon my submitting user/password. The error_log states that a file cannot be found. What file I've so far been unable to determine. Below please find a copy of those errors as they are stated in the log. I posted for discussion everything within parentheses on a PHP forum. Another problem is that the server can't find the main-page background image. Finally, the application only displays correctly with the Chrome browser. With IE and Firefox there are multiple issues. The ZC version is 1.50 and the server php is version 5.3. The ZC files uploaded to the shared virtual server are identical to those which work correctly on the hosted server. So also the database. Below, my "Statement #1" presumption of recursion is a best guess using the debugging code I've succeeded with so far. Nothing in the Cache file sheds light on the unlocatable file. Any insight into these issues would be greatly appreciated.

"Here are three versions of the same error message (PHP 5.x and Red Hat Linux OS):
(1) [Fri Jan 30 12:06:57 2015] [error] [client 73.181.84.157] File does not exist: /var/www/vhosts/MyDomain.com/MyDomain.com/zyBer-admin/login
(2) [Fri Jan 30 12:07:28 2015] [error] [client 73.181.84.157] File does not exist: /var/www/vhosts/MyDomain.com/MyDomain.com/var
(3) [Fri Jan 30 12:38:32 2015] [error] [client 73.181.84.157] File does not exist: /var/www/vhosts/MyDomain.com/MyDomain.com/zencart

Statement #1 is most perplexing. The file login (I get the same message if I use login.php for the call address) calls itself. In older programming languages it would be called a recursion. Yet the server can't find the self-same file whose code it is executing. I've tried using a complete URL for the file call -i.e., http:/MyDomain/folder-containing-login.php/login.php, and that doesn't solve the problem.

Statement #2: What's Linux address .../var got to do with this?

Statement #3: Nowhere in this ecommerce application is there a "zencart" file. The database is named zencart-database. Would it be not unprecedented that the error log generator would clip the characters zencart from the complete database name?"

[DrByte]

IMO all of this is server configuration stuff.

1. a) /admin/login.php does indeed POST back to /admin/login.php ... but not recursively. It requires the admin user to actually click the submit button in order to POST to login.php. The system then redirects to the index.php if login is successful. There's nothing in Zen Cart code that will recursively loop to login.php repeatedly.
b) Calling /admin/login without the .php suffix doesn't work in any v1.x version of Zen Cart. To enable that would require customizing the code to add routing and URL rewriting functionality specifically to handle that.

2. Nothing in Zen Cart code would call a URL of just /var ... there's no purpose to that

3. Nothing in Zen Cart code would call a URL of just /zencart ... there's no purpose to that


Notes: Both PHP 5.3 and Zen Cart v1.5.0 are end of life. Much newer versions are available.

[frank18]

I would first look at my 2 configure.php files. If that is all ok I would get in touch with the server people. Also, if you have a local dev server, copy the lot onto your local machine (including DB ofc) and see if that works. If it does then to 99% it is a server problem.

[cyberbaffled]

DrByte, thanks for your prompt reply. I'll next try frank18's ideas. I only have the Apache component of a dev server, but if I have to I'll install Linux. I figured that these were server issues, which is why I went through a week of PHP forum communications trying to isolate precisely what those issues were before posting on the Zen Cart forum.

IMO all of this is server configuration stuff.

[cyberbaffled]

Frank18, thanks for your prompt reply. I'll next try your suggestions. As I posted to Dr. Byte, if I have to complete development of a dev server then that's what must be done.

[frank18]

..... if I have to complete development of a dev server then that's what must be done.

That is always handy, you can test anything new (mods, templates etc) on your local machine without messing up your live site. For Linux install the LAMP stack and for Windows use XAMPP - all free.

Good luck!

[cyberbaffled]

Dr Byte, I'm splitting this off as a new post because after an interval of several days I'm not sure you'd find a reply to the original post.

In your reply to that post you wrote-

"The system then redirects to the index.php if login is successful."

The system crashes upon login, so the problem occurs before the index.php file is executed. I'm having to go through the arduous task of installing Firebug to trace the problem. However, in the meantime, if I knew which index.php file is involved I might be able to circumvent the problem sufficiently to get some new products on my ecommerce site. However, last count there were 56 index.php files. To which did you refer?

Thanks for your attention to this matter, ahead of time.

[RodG]

In your reply to that post you wrote-

"The system then redirects to the index.php if login is successful."

The system crashes upon login, so the problem occurs before the index.php file is executed.

That doesn't seem right.

The login page is
YOUR_STORE/index.php?main_page=login
If the login is successful you'll find yourself on
YOUR_STORE/index.php?main_page=index

In both cases it is the index.php file that gets loaded (albeit with a different parameter), so to state that it crashes before the index.php is loaded is a bad assumption.

if I knew which index.php file is involved I might be able to circumvent the problem sufficiently to get some new products on my ecommerce site. However, last count there were 56 index.php files. To which did you refer?

I think you should check this again. There should only be 9 files called 'index.php', and that includes two in the zc_install folder, two in the /language/ folders, one in the /cache/ folder, one in the /logs/ folder, and one in the /backups/ folder.

So that only leaves one in the 'main' folder and one in the /admin/ folder.

Even if you include the index.html files (most of which are 'dummy' files anyway) there should only be ~39 of them (ZenCart V1.5.x), so I've no idea how/where/why you are finding 56 of them??

Cheers
RodG

[DrByte]

Dr Byte, I'm splitting this off as a new post because after an interval of several days I'm not sure you'd find a reply to the original post.

I'm merging this back with your original discussion because splitting it off lost a whole lot of context, as you can tell by the other reply posted.

In your reply to that post you wrote-

The system then redirects to the index.php if login is successful."

The system crashes upon login, so the problem occurs before the index.php file is executed. I'm having to go through the arduous task of installing Firebug to trace the problem. However, in the meantime, if I knew which index.php file is involved I might be able to circumvent the problem sufficiently to get some new products on my ecommerce site. However, last count there were 56 index.php files. To which did you refer?

Since we were talking about admin login, I was referring to the /admin/index.php file.

Seriously I think either you've made some alterations to the code so that it no longer performs the way original Zen Cart does, or you've got some odd server configurations going on that are causing odd redirects/rewrites or broken sessions.
To isolate the Zen Cart issue, I'd recommend installing a fresh uncustomized copy as a test tool, if that's possible for you.
To address the server config issue, I recommend getting your webmaster/sysadmin/devops person involved.

[cyberbaffled]

Dr Byte, this dilatory reply is due to the fact that before I read your most recent post I had done what you suggest in that post. I have installed a fresh zc v1.50 file on a different "web space" on my Centos 6 server, and it works perfectly. No problem accessing the admin utility. My conclusion entails the reason I'm installing this application on a virtual server to begin with. When zc was installed on a hosted server, it worked perfectly until a product order was attempted. Then it crashed due to insufficient PHP memory. That's what motivated the virtual server move. However, germaine to this series of posts, before I moved the application I attempted to locate the precise place in execution where the PHP memory was exceeded. To accomplish this I added a lot of kluge debug code. It was that file with those changes that I installed on the v-server. Your intuition about this is exactly correct. I seem to be the source of the disfunction. Again, thanks for sharing your time and expertise on this issue.