New installation 2.1.2 failed

After I input MYSQL host, database name, user name, password, admin email and click “next step” button, it goes to a blank page.


  1. File and directory permissions no problem.
  2. MYSQL host, database name, user name, password no mistake.



    I tried several times and under different domain, all the same problem.



    Anyone can help?

What does your PHP error_log say?

php error_log is empty.

Make sure you have error_reporting(E_ALL) on. Usually a blank page indicates a php error.

I can install Cs-cart 2.0.15, but can’t install 2.1.2 !

The error message is “Cannot unset string offsets in /public_html/core/fn.cms.php on line 704”. Please help me!

Sorry Madaha, I just don’t know. That is a strange place for failure during installation… Are you sure the archive you have is correct?

Are you sure the archive you have is correct? - Yes! I empty the error_log file, try to install, fail, go back to check the error log, found the error message “Cannot unset string offsets in /public_html/core/fn.cms.php on line 704”.



By the way, I can install CSCart 2.0.15, but not for 2.1.2.

My point is that if you keep using a bad archive to install from, you will continue to get bad results no matter how many times you clear your error log. Go get a fresh copy from cs-cart and try it with a different archive.

I tried both zip and tgz archive, none of them work. I installed 2.0.15 them upgrade to 2.1.2. But there is a new problem: when I click a category to modify, it goes to a blank page after I upgrade to 2.1.2.

hi

To solve the problem, try to rename the files in the “core/db” directory:

  1. Rename the “mysqli.php” file into “mysqli1.php”.
  2. Rename the “mysql.php” file into “mysqli.php”.



    Also please try the following solution:
  1. Open the “config.local.php” file located in the root CS-Cart directory.
  2. Find the following line of the code there:



    $config[‘db_type’] = ‘mysqli’;





    and replace it with this one:



    $config[‘db_type’] = ‘mysql’;




  3. Save the file.

is public_html with 777 ? in my case problem was sorted with mysql in stead of mysqli

I’m having the EXACT same problem

blank screen during install after the same step as described above


[quote name=‘martin1979’]hi

To solve the problem, try to rename the files in the “core/db” directory:

  1. Rename the “mysqli.php” file into “mysqli1.php”.
  2. Rename the “mysql.php” file into “mysqli.php”.



    Also please try the following solution:
  1. Open the “config.local.php” file located in the root CS-Cart directory.
  2. Find the following line of the code there:



    $config[‘db_type’] = ‘mysqli’;





    and replace it with this one:



    $config[‘db_type’] = ‘mysql’;




  3. Save the file.[/QUOTE]



    have you tried this solution???



    i think you may have made a typo above or left out another crucial step, as this solution doesn’t work.



    All this seems to do is hide the MySQLi db function wrappers from cs-cart and load the MySQLi db function wrappers if you are using a MySQL db.



    Changing the $config[‘db_type’] in config.local.php seems to make sense if you aren’t using mysqli



    but that doesn’t work either and also rsults in a blank screen

just before I found this thread I started another regarding this exact same problem :



anyways that thread mentioned that the only thing that seemed odd was that all of the uploaded cscart files had owner.group values of 2012.2009



chowned everything to root.root



tried install again



still got the blank screen same place.

What OS are you using? I’ve never heard of those kinds of values (2012.2009) for permissions.



Try installing again but before you do, edit the config.local.php:


// Default permissions for newly created files and directories
define('DEFAULT_FILE_PERMISSIONS', [COLOR="Red"]0644[/COLOR]);
define('DEFAULT_DIR_PERMISSIONS', [COLOR="Red"]0755[/COLOR]);

FIXED IT



so Martin1979 was on the right track…


  1. Rename the “mysqli.php” file into “mysqli1.php”.
  2. Rename the “mysql.php” file into “mysqli.php”.



    But then leave it at that ( at least in my case )



    for some strange reason, the installation kept trying to force mysqli wrappers which were failing.



    so simply renaming the mysql.php file to mysqli.php works.

    renaming the db_type in config.local.php had no affect because as soon as I would click NEXT during the install, it would of course, rewrite the config.local.php file and change the db_type back to “mysqli”





    with response to Tool



    no idea how the ownership got set to 2012.2009, no other files I have uploaded have done this so I don’t think it’s the server doing it. I untarred via SSH so maybe it kept the permissions that were on the files while they were still zipped ?!?!

Sounds like you run your strore as root (very bad idea) and that when you unarchived yor cart, it used the owner/group that was in the archive (since you did it as root). Those user/group ids were not known on your system so the integer values were shown instead of the names.



I’d fix your php config to honor mysqli. You’ll get much better performance since the connections will be reused rather than establishing new ones.

What’s your URL? If you run your store as root, I could use to commandeer a new server for my exclusive use… VERY BIG SECURITY ISSUE.

[quote name=‘tbirnseth’]Sounds like you run your strore as root (very bad idea)[/QUOTE]



nope. i don’t run as root, but i also don’t post my real username in forums, so i just said i chowned everything to root.



sudo root :smiley:


[quote name=‘tbirnseth’]I’d fix your php config to honor mysqli.[/QUOTE]

haven’t looked into it much. phpinfo says it’s enabled and the settings in php.ini look ok, yum says it’s installed… kinda stumped.



but far more distracted by :



Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/config.local.php:108) in /var/www/html/core/fn.init.php on line 401



fresh install



I haven’t touched one bit of code except config.local.php and there’s no whitespace in that. I’m thinking it might be output bufering nonsense maybe.

yup…

looked in php.ini

output_buffering = Off



turned it on



no more problems