Will not install: blank white page

• When I start the v1.5.3 installer (http://mydomain.com/ZEN153/zc_install/index.php, the next screen is blank, white, view source is empty.
• IF I use the v1.5.1 installer, things progress through a typical install but I did not expect to end up with a functional v1.5.3 installation.

http://mydomain.com/ZEN153/ does display the "Hello. Thank you for loading Zen-cart" screen. System setup required.

I spent the better part of yesterday uploading the fileset several times and verifying folder/path permissions. Surely someone will be able to point out my shortcomings.

Steps:
Download v1.5.3 zip and verify hash
Unzip v1.5.3
ftp complete set of files to the mydomain.com/ZEN153/
rename /ZEN153/includes/dist-configure.php & verify permission 777
rename/ZEN153/admin/includes/dist-configure.php & verify permission 777
change permissions of folders to 777
create new, empty database zen153
enter http://mydomain.com/ZEN153/zc_install/index.php
blank screen

Delete contents of /ZEN153 folder and start over:
Repeat above from my notes
Same result

Delete contents of /ZEN153 folder.
Upload v1.5.3 zipped file to server.
Unzip v1.5.3 on server to folder /ZEN153
Repeat install steps. Same result.

For the heck of it:
Make no changes to files/folders except rename zc_install folder to 1zc_install
FTP v1.5.1 zc_install folder to server folder /ZEN153
Start installer:
http://mydomain.com/ZEN153/zc_install/index.php
Installation begins & progresses through all steps but doesn't yield a fully functional v1.5.3 install but I didn't expect that either.

There is a functional v1.5.1 installation in the domain root.
Apache 2.2.27
php: 5.3.28
MySQL: 5.5.37

Anything in the /logs folder?

/ZEN153/logs folder empty except for .htaccess, index.html and index.php

cpanel server error log empty

Ensure logs is writable and retry.

RixStix:

change permissions of folders to 777

Recheck /ZEN153/logs folder and verify permission still 777
Check root/logs and verify permission 755 (just in case the installer wants to write there)

Look at php-info and see whether it says mysqli support is enabled (not just mysql)
Who's the hosting company?
Do you have access to the apache errorlogs? Any PHP errors causing white pages should be shown there (assuming it's running PHP in SAPI mode, not CGI)

DrByte:

Look at php-info and see whether it says mysqli support is enabled (not just mysql)
Both appear to be enabled - screenprint below

DrByte:

Who's the hosting company?
TVCnet.com

DrByte:

Do you have access to the apache errorlogs? Any PHP errors causing white pages should be shown there (assuming it's running PHP in SAPI mode, not CGI) That's over my head :blink:

cPanel error logfile
I cannot tell whether these were generated by my install attempt or from my root v1.51 install
[Wed Jul 09 10:02:09 2014] [error] [client myIPaddress] File does not exist: /home/mysandbox/public_html/404.shtml
[Wed Jul 09 10:02:09 2014] [error] [client myIPaddress] File does not exist: /home/mysandbox/public_html/favicon.ico
[Wed Jul 09 10:02:09 2014] [error] [client myIPaddress] File does not exist: /home/mysandbox/public_html/404.shtml
[Wed Jul 09 10:02:09 2014] [error] [client myIPaddress] File does not exist: /home/mysandbox/public_html/favicon.ico

[Attachment no longer available]

Though I'd rather not.

If it makes any difference or if it will help,
I can wipe the v1.5.1 sandbox in the server root and attempt a v1.5.3 install there.

I went to a live site. Same host. Different server. Significantly different php-info settings between the 2 servers.
created /ZEN153 folder
performed same steps as before, creating empty db, unzip v1.5.3, run zc_install

Installation completed as designed.

I am confused that the db tables after the install are showing MyISAM, latin-1 collation because I thought that I read InnoDB and UTF-8 was the v1.5.3 default.

Also gunshy about performing a v1.5.3 update once the edits are finalized in the sandbox. Is v1.5.3 that finicky with server settings. Maybe I just drew the short straw.

RixStix:

Is v1.5.3 that finicky with server settings. Maybe I just drew the short straw.
Shouldn't be. Nothing much changed as far as server requirements. Just built for compatibility with more and newer PHP versions.

RixStix:

I am confused that the db tables after the install are showing MyISAM, latin-1 collation because I thought that I read InnoDB and UTF-8 was the v1.5.3 default.
Zen Cart operates as utf-8 out of the box. But, it doesn't explicitly force an override of the database's defaults when creating new tables. So, it appears your server's database currently has latin1 set as that specific database's defined default collation. You can edit that database's default so that future tables are will be utf8 when created.
But Zen Cart will still attempt to store its data as utf8 data, stuffed into whatever format you've created your tables as. So, if you're starting fresh, you should probably change the db default, and then wipe out those temporary latin1 tables, and do a new install.

InnoDB vs MyISAM is a different issue. Zen Cart v1.5.x still uses MyISAM for all its tables, although there are plans to make some of those InnoDB in a future release. Unfortunately, historically speaking, few webservers have any tuning done for the InnoDB engine, so realize few performance gains by making the switch. Fortunately modern trends are beginning to prevail and InnoDB is becoming more commonplace, so the time will soon be good for making the switch.

RixStix:

I went to a live site. Same host. Different server. Significantly different php-info settings between the 2 servers.
...

Installation completed as designed.
It would be good to find out which specific settings are causing the problem for you.

Thank you for the explanation.

I'll wipe the db on what has just become Sandbox#2 and chalk up yesterday's 1.5.3 attempted install on Sandbox#1 as a lost cause since I didn't learn anything from that drill other than watching a 30 minute ftp several times and hope for different results each time.

Forgive my ignorance but it appears that the db server is set for UTF-8 but creates new db as latin-1. At least that is my interpretation of the settings.
[Attachment no longer available]

DrByte:

It would be good to find out which specific settings are causing the problem for you.

There are so many differences when comparing the two files that I wouldn't have a clue. Both are shared servers.

RixStix:

Forgive my ignorance but it appears that the db server is set for UTF-8 but creates new db as latin-1. At least that is my interpretation of the settings.
[Attachment no longer available]

1. "server connection" refers to the connection established to the database from whatever client is telling you about the connection type. Zen Cart will connect TO and communicate WITH the database using utf8, much like your phpmyadmin is doing in that screenshot.

2. "server charset" refers to the character set that the server knows and uses. It may even use that when creating new "databases".

But neither of those is referring to how your store's database itself is configured:
3. In phpMyAdmin, click on your specific database, then go to the Operations tab and look at the Collation section, to see/change the collation for that specific database you've selected.
WARNING: But only change this if your database is empty and you're prepared to delete all the tables in it. Else you'll need to manually go and change all the data in all the tables to be the right charset, and if you do that without knowing what you're doing, you'll lose any data related to utf8-vs-latin1 conflicts (basically any non-english chars will be mangled). There's a utility in the Plugins area here to help convert existing databases if needed.

Thank you for taking the time to teach me a bit. This is getting confusing and tells me that I am probably better to leave well enough alone.

phpMyAdmin:: structure tab:: all tables show latin1_swedish_ci Collation
pmyMyAdmin:: operations tab:: UTF8_general_ci Collation

Yes, DB converter. How well we know about hidden characters in the attribute price prefix field ( +,-, blank)

If you want/need the php-info files from the two servers, you're welcome to them for comparison. They won't do much for me.

Sure, PM me with a link to the php info outputs. Thanks

I also had this issue: Blank page when clicking install.

I was able to fix it by removing the apc and xcache checking code from the zc_install\index.php file.

However, on a different server 1.5.3 installed without any problems.

BTW, no errors where show in apache's error_log, or under zencart's log folder (with 777 permissions).

chadderuski:

I also had this issue: Blank page when clicking install.

I was able to fix it by removing the apc and xcache checking code from the zc_install\index.php file.
ARGH. xcache is such an unfriendly beast! And painfully hard to test reliably ... probably because there's no reliable predictability in how people implement it.
And we only trigger the cache suppression if the functions exist. But, it's such a mixed bag.

DrByte:

ARGH. xcache is such an unfriendly beast! And painfully hard to test reliably ... probably because there's no reliable predictability in how people implement it.
And we only trigger the cache suppression if the functions exist. But, it's such a mixed bag.

Here's a nice wrench for you! While working on this sever it turns out xcache WAS loaded, but not active... ?!?! I don't remember doing that.

What I do remember is banging my head against the wall over the years with apc/xcache and which way to run Apache (cgi/fcgi/dso/etc) and which were compatible and which weren't ... and not even my host's engineers seemed to know what worked properly with what!

So I had them remove it while they rebuilt apache with the latest 5.4 stable release.

Isn't PHP 5.5 supposed to have a built in (APC) opcode cache? I wonder how that will work.

Any known issues with LightSpeed? Not that zencart needs it (like Mabloatgento).

DrByte:

Sure, PM me with a link to the php info outputs. Thanks

I spent 1/2 day on this too :( - no error messages or error logs.

Commenting out the xcache line fixed the problem immediately.