Shortened the additional information.

When I install 1.2.0rc2 Ihave three SYSTEM WARNINGs
with mysqli database type
SYSTEM WARNING: htmlentities() expects parameter 1 to be string, array given
SYSTEM WARNING: Invalid argument supplied for foreach()
SYSTEM WARNING: mysqli_real_escape_string() expects parameter 1 to be mysqli, boolean given

with mysql database type
only
SYSTEM WARNING: htmlentities() expects parameter 1 to be string, array given

After updating php 5.3.0 to php 5.3.1
No changes
I try php 5.2 tomorrow

With php 5.2
No changes
The same warnings

Installation Option Type of Database Mysqli

SYSTEM WARNING: htmlentities() expects parameter 1 to be string, array given
SYSTEM WARNING: Invalid argument supplied for foreach()
SYSTEM WARNING: mysqli_real_escape_string() expects parameter 1 to be mysqli, boolean given

Installation Option Type of Database Mysql

SYSTEM WARNING: Invalid argument supplied for foreach()
SYSTEM WARNING: htmlentities() expects parameter 1 to be string, array given

Instalation 1.2.0rc2 on php 5.2
install.tar.gz

I,ve tried to install ver. 1.1.8
with the same warnings

I think this is caused by enabeling the checkbox "Print SQL Queries instead of Writing to the Database"

I am no experienced PHP developer, maybe
echo htmlentities( $sql ) . ";\r\n\r\n";
should be
echo htmlentities( implode ( $sql ) ) . ";\r\n\r\n";

I have the same problem when I try to install the latest stable version 1.2.1 on my version 1.1.1

Hi,

The reason for this problem is that the install.php page tries to print out SQL code for schema-creation directives that are actually intended to trigger the excution of logic coded in PHP. One way or another, the attempt is bound to fail.

What the PHP code does is things like copying data between columns that have had their definitions changed. There is no solution to this except perhaps to express the actions in pure SQL, but that might not be possible in a portable way.

Below is a patch in diff -u format to the 1.2.1 stable version of the admin/install.php file that at least cleans up the output by printing an informative comment instead of letting the error printouts mess up the SQL syntax.

The patch also includes another useful change, by temporarily disabling the error-reporting subsystem, which otherwise wipes out the page content upon errors, so that the administrator cannot see how far the script managed to run before breaking.

--- admin/install.1.2.1.php 2010-05-05 12:08:40.556079300 +0200
+++ admin/install.php 2010-05-05 16:30:28.251297600 +0200
@@ -670,6 +670,9 @@
<?php
}

• temporarily disable the "friendly" error reporting, so that the progress can be monitored

• $current_error_reporting_setting = error_reporting();
• error_reporting(0);

  install the tables

  if( false == $g_failed ) {
          $g_db_connected = false;

  @@ -743,10 +746,14 @@
  }
  }
  if( $f_log_queries ) {

• if( $t_sql ) {
  foreach( $sqlarray as $sql ) {
  echo htmlentities( $sql ) . ";\r\n\r\n";
  }
  } else {
• echo "-- NOTE: The PHP function 'install_$sqlarray[0]' would have been run here.\r\n\r\n";
• }
• } else {
  echo 'Schema ' . $upgrade[$i][0] . ' ( ' . $t_target . ' )</td>';
  if( $t_sql ) {
  $ret = $dict->ExecuteSQLArray( $sqlarray );
  @@ -778,6 +785,8 @@
  } else {
  $t_install_state--;
  }

• restore error reporting

• error_reporting($current_error_reporting_setting);

  ?>

  </table>

Thanks Otto for the patch and everyone else for reporting and debugging this issue.

It should be fixed now, ready for the next release.

@ottog: I haven't applied your error disabling patch yet as I have to look into that matter further. I think I'll end up rewriting the installer entirely as it is a big mess at the moment.