Might be something to do with the database framework package? @mbabker

https://stackoverflow.com/questions/8321096/call-to-undefined-method-mysqli-stmtget-result

Long and short is some of the stuff we're doing requires PHP to use the mysqlnd engine under the hood. We're going to have to make some checks to work around that it seems.

Can't confirm.

System information

4.0.0-dev / nightly Build
macOS Sierra, 10.12.5
Firefox 54 (64-bit)

MAMP 4.1.1

• PHP 7.0.15
• MySQLi 5.6.35

You probably have the mysqlnd engine enabled on your platform. When you go to /administrator/index.php?option=com_admin&view=sysinfo, on the PHP Information tab, search for mysqlnd. If it's enabled it'll have its own heading in the output, not quite sure what you'd see in a phpinfo() output if it's disabled.

Got:

Oh ya, that's what #16789 is all about.

Put a file on your webserver with these contents and you basically get the same output:

<?php phpinfo();

Just delete it when you're done!

@mbabker don't wanna waste your Time, this is beyond my Skills.

My apologies to everyone who looked into this issue. I took a really good look at things, today (first time that I've had enough time available) and discovered an error when I created the db access rights.

Now that I've fixed the error, the problem has gone away, so I shall close this issue.

I'm re-opening as you could still reproduce it according to our skype tonight

It's true. I did get further but I still get the same error message.

Just to circle back around on this, George and I were talking about this a little bit over the weekend too.

One of the things we looked at was how Doctine handles this. First, keep in mind that it's primarily a PDO based API so their MySQLi support is kind of tacked onto that and still has a lot of "PDO-ism's" littered into their code. As far as handling things goes in our database API, we're about functionally similar all the way up to what we do after the query is actually executed. Specifically, it's this line that the behaviors start differing at (the line that's producing the undefined method error).

Doctrine uses a behavior of manually binding the result data instead of processing a result cursor, this is also a generally accepted workaround to requiring mysqlnd. The relevant code is at https://github.com/doctrine/dbal/blob/899c62bb579027c146b73f6b580c871eb669d310/lib/Doctrine/DBAL/Driver/Mysqli/MysqliStatement.php#L175-L217 but generally it is fetching the selected column names out of the mysqli_stmt object to create an array of columns to bind to, then builds a references array with the pertinent data, then calls mysqli_stmt::bind_result with the references. This handles getting the data in a usable form for the most part.

So back to the point about processing a result cursor. Without the cursor, you have to manually build a result set. In Doctrine, that's fetching the results from mysqli_stmt and building a result array, and then they use some PHP logic to build the appropriate return sets for the requested fetch type (relevant functions are at https://github.com/doctrine/dbal/blob/899c62bb579027c146b73f6b580c871eb669d310/lib/Doctrine/DBAL/Driver/Mysqli/MysqliStatement.php#L244-L311). Our internal fetch* methods would have to be refactored to emulate this logic and no longer use a result cursor and the mysqli API to fetch the data.

@tarotray Can you please try using the MySQL (PDO) and see if you can install please. I think that may work for you whilst we try and figure out the best way to solve this problem

So sorry, but a lot of that explanation goes over my head.

If it's any help, as it just simply doesn't create the database, on installation, I just reconstructed the database, on my host server, by running the SQL in /installation/sql/mysql/joomla.sql and I got this result:

Error displaying the error page: Failed to start the session: already started by PHP.: Call to undefined method mysqli_stmt::get_result()
Fatal error: Uncaught Error: Call to undefined method mysqli_stmt::get_result() in /home4/tarotray/public_html/j4-dev/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php:716 Stack trace: #0 /home4/tarotray/public_html/j4-dev/libraries/vendor/joomla/database/src/DatabaseDriver.php(1156): Joomla\Database\Mysqli\MysqliDriver->execute() #1 /home4/tarotray/public_html/j4-dev/libraries/vendor/joomla/session/src/Handler/DatabaseHandler.php(276): Joomla\Database\DatabaseDriver->loadResult() #2 [internal function]: Joomla\Session\Handler\DatabaseHandler->write('n8c8ddk6lc98ag8...', 'joomla|s:160:"T...') #3 /home4/tarotray/public_html/j4-dev/libraries/vendor/joomla/session/src/Storage/NativeStorage.php(108): session_write_close() #4 /home4/tarotray/public_html/j4-dev/libraries/src/CMS/Session/Storage/JoomlaStorage.php(127): Joomla\Session\Storage\NativeStorage->close() #5 [internal function]: Joomla\CMS\Session\Storage\JoomlaStorage->close() #6 {main} thrown in /home4/tarotray/public_html/j4-dev/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php on line 716

My next test will be to delete the db, again, put all the latest build, into the directory and try to install again. I suspect I shall get the same result as before.

I'll let you know.

BTW: @wilsonge I seem to remember that I did, already, try using MySql (PDO) instead of MySQLi, some days ago without success.

So sorry, but a lot of that explanation goes over my head.

It's just notes for us to come back to, nothing that has to be acted on by you.

FYI: The problem has been fixed, if I use the mySQL PDO setting. Thanks, team.

Closing in favor of #18660 which has more detail at this point on the underlying issue and the work needed to resolve it. Now to just find some time to finish it...

Disable mysqli extension and enable nd_mysqli extension, works like a charm