MySQLi can be left out if you aren't using mysqlnd because the prepared statement support depends on it and it was causing issues for those without it (still gotta fix that one).

PDO, I'm clueless.

FWIW I have installed the site manually, editing the configuration.php by hand. Both mysql and pdomysql options seem to work. However, I have had all of 2' of using the site so maybe it's broken indeed. Maybe you need to recheck how the installer determines which drivers to render in the dropdown?

If you want to reproduce this issue you can use my Vagrant box. It's essentially the same setup, just based on Ubuntu Server 16.04.

I have noticed similar issue, in my tests the Installer detect only MySQLi but no PDO,
I have tested on default Ubuntu Server 16.04

/etc/php/7.0/cli/conf.d/20-mysqli.ini,
mysqli
mysqli.allow_local_infile => On => On
mysqli.allow_persistent => On => On
mysqli.default_host => no value => no value
mysqli.default_port => 3306 => 3306
mysqli.default_pw => no value => no value
mysqli.default_socket => no value => no value
mysqli.default_user => no value => no value
mysqli.max_links => Unlimited => Unlimited
mysqli.max_persistent => Unlimited => Unlimited
mysqli.reconnect => Off => Off
mysqli.rollback_on_cached_plink => Off => Off
API Extensions => mysqli,pdo_mysql

/etc/php/7.0/cli/conf.d/10-pdo.ini,
/etc/php/7.0/cli/conf.d/20-pdo_mysql.ini,
/etc/php/7.0/cli/conf.d/20-pdo_sqlite.ini,
API Extensions => mysqli,pdo_mysql
pdo_mysql
pdo_mysql.default_socket => /var/run/mysqld/mysqld.sock => /var/run/mysqld/mysqld.sock
pdo_sqlite

@Fedik See the comments in gh-18661. I think it's a problem with the PHP configuration on our servers.

For the PDO part I think it's server config.

For MySQLi, basically instead of this line I need to find a way to replace it with a non-mysqlnd specific solution (I think this method in Doctrine's DBAL is what I'm looking for but I need to make sure I can make it work without breaking our API internals).

I tried installing Joomla! 4 again today on MAMP. Since PHP there is compiled against mysqlnd I was able to select MySQLi. However, it still didn't detect PDO. I could use PDO after the installation was over just fine. So, maybe, PDO detection isn't server config after all? :)

I confirm the same thing happened to me on a simple LAMP Stack Vagrant box and on a hosting space managed by cPanel. I could only see PostgreSQL.

Not shure that this is the same problem. Just tried to install J!4 on a server with php 7.1 and mySQL not on localhost. Cannot select any database type at all ??

Not yet any solution?

@Artwebco maybe this help #18783 (comment)

Seems this issue is related only to MAMP, I tried with WAMP and everything
is OK

On Fri, Dec 8, 2017 at 4:38 PM, Franz Wohlkönig notifications@github.com
wrote:

@Artwebco https://github.com/artwebco maybe this help #18783 (comment)
#18783 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18660 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYdMMZgubYlUB7xrhypTIPKCerwUHgtoks5s-VgLgaJpZM4QjASd
.

--
Nikola Nikovski
Upwork Joomla and Wordpres developer

Actually is not everything OK.
I installed Joomla4, but after I logged in to /administrator and I see this error.
"An error has occurred.
0 This is not implemented, as it is not possible to implement Argon2i with acceptable performance in pure-PHP"

@Artwebco Installation is successfully on:

System information

4.0.0-dev
Multilanguage Site (4 Lang.) & Sample Data
macOS Sierra, 10.12.6
Firefox 57 (64-bit)

MAMP 4.2

• PHP 7.0.22
• MySQLi 5.6.35

@Artwebco Somehow you have a non-Bcrypt based password hash stored for that user account then (core supports Argon2i hashes but we definitely aren't generating them right now).

Right, now is OK.

On Fri, Dec 8, 2017 at 4:56 PM, Michael Babker notifications@github.com
wrote:

@Artwebco https://github.com/artwebco Somehow you have a non-Bcrypt
based password hash stored for that user account then (core supports
Argon2i hashes but we definitely aren't generating them right now).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18660 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYdMMabQfLPBApUmMfCwkt2k91ATiQ2hks5s-VxKgaJpZM4QjASd
.

--
Nikola Nikovski
Upwork Joomla and Wordpres developer

The Argon2i error comes up if the user had a salted MD5 password. I think it’s a bug on its own right: accounts which have not been logged in since Joomla 3.3.5 (if memory serves) are permanently logged out of the site with an ungraceful and inelegant server error. I was planning on reporting it this weekend. Would you like me to, @mbabker? I can provide sample DB data.

I think once we get 4.0 up to the latest sodium_compat release and improve the isSupported checks in the password handler things will work themselves out (see paragonie/sodium_compat#55 for more info on why). But yes, a separate issue would be helpful if for nothing else than to act as a nudge.

FYI I just committed 87957ce so the Argon2i issue should be resolved now. If not, please open a separate issue for that.

hit the problem myself today using MAMP showing no database available.
Note that J3 works perfectly on the same MAMP install

MAMP 3.3.1 on windows
php 7.1.5
mysql 5.6.34

Same problem on Macbook Pro Joomla3 works perfectly.

AMPPS 3.8
php 7.1.8
MySql 5.6.36

Please test after this patch here: #19646.

That might get the PDO option to show back up but the MySQLi stuff is still broken and will continue to be until someone with the time and knowledge can chase down something like I explained in #18660 (comment)

See also #19779

Some issue with PHP 7.2.1
Only MySQL(PDO) selection in Database field posssible, NO MySQLi displayed.
Installation not possible on Apache server 2.4.29 at Strato.

I changed the configuration.php-dist to configuration.php after deleting the original configuration.php file.
Although I could not select MySQL in the database selection field (Only MySQL(PDO) displayed) I manegd to get the installation running and it seems to work fine now.
For yr reference I enclose the working config.php file and current System Information.pdfsystem onfo. configuration.php.pdf

Cross linking this and #16799 since at this point they are one in the same (unless there's an outstanding issue with the PDO driver I'm missing).

Right now our DatabaseDriver::execute() method works by storing a result cursor reference to DatabaseDriver::$cursor that is used by default in various internal methods for loading records. For PDO, this is the PDOStatement object created by running PDO::prepare(), in MySQLi this is a mysqli_result instance, and in PostgreSQL this is a generic "resource" type.

For MySQLi, without mysqli_stmt::get_result() being available, it is not possible to get a usable mysqli_result instance. So in essence our entire API design falls apart unless you use PHP with ext/mysqli compiled with mysqlnd support; libmysql support is totally broken right now.

I've mentioned Doctrine's DBAL a few times in the various issues dealing with this, I'm doing it again. Their API design makes each SQL statement a separate \Doctrine\DBAL\Driver\Statement object. Since their DBAL is based on PDO, that interface's design is an abstraction based on a subset of the PDOStatement class, then they have created implementations for MySQLi and SQL Server (as I've said elsewhere, their API doesn't support native PostgreSQL, it's only supported through PDO). At this point I'd really love to just pull the Statement objects from Doctrine and use those, but that requires a dependency on doctrine/dbal in full to bring in 2 interfaces and 3 classes, so that option's probably off the table unless we're going to start rewriting our database API to make more use of Doctrine (which to be honest with our API design the only other thing I find interesting is the Connection objects, but that's minimal gain as well).

Why would I want the Statement objects? As I said a bit ago, our existing PDO architecture treats PDOStatement as the result cursor, it should be reasonably practical to adapt the non-PDO drivers to a similar approach.

As far as API design goes, to pull off migrating to a set of Statement objects, I foresee the need for these B/C breaks at a minimum:

• Public DatabaseDriver::execute() will only return boolean true (because false conditions result in Exceptions being thrown), it would no longer return the result cursor
• Protected DatabaseDriver::fetch*() will only work with the internal result cursor set by DatabaseDriver::execute(), it would no longer accept an injected cursor

Thoughts?

Same error with Joomla 4 alpha 2 on OSX and AMPPS , only PostgreSQL possible

installation/forms/setup.xml mysql was missing
<field name="db_type" type="databaseconnection" id="db_type" class="custom-select form-control" label="INSTL_DATABASE_TYPE_DESC" supported="mysqli,pdomysql,postgresql" required="true" default="mysql" filter="string" />

fix : supported="mysql,mysqli,pdomysql,postgresql"

fix : supported="mysql,mysqli,pdomysql,postgresql"

Fix: Use a nightly build. The XML is correct in the current development branch, the older alpha releases are now several months behind and should not be used.

thanks ! but I dont know where to find the lasts alpha , is there a place where to find all last versions ?

https://developer.joomla.org/nightly-builds.html

thanks !!!

Just tried the latest nightly. Now I see the choice mysql (PDO) - but when I press next I get a blank screen and nothing more happens...
PHP 7.1 on the server.

OK, at this point there is really no point in continuing to comment "it's broke". We all know it is, hence this issue being open. I pointed out in November 2017 why it's broke (actually a cross-referenced issue going back to June 2017 explained it the first time around). Nobody has stepped up to help with fixing it, I finally made some time last week to start on the solution I think is required for this issue, see joomla-framework/database@2.0-dev...statements for the code diff if anyone is interested enough to do a preliminary review. I will try to find time to continue on that at some point this month, but as long as I'm the only one who seems willing or able to work on a fix then it's going to be a very slow process to reach the end state of everything working as it needs to (and no, the fix is not to revert to the 3.x code; the 3.x code does not support a critical security tool in writing secure database queries, prepared statements, and the reason there are issues in the current 4.0 code is because the database drivers have been updated to support that but issues were introduced along the way, it's unfortunate but it happens in major refactoring sometimes).

There is also #19989 open needing testing/review which addresses some other minor code related issues (doesn't fix the database drivers but fixes some conditional behaviors around the active database driver).

In the branch I mentioned in my last comment 3 of the 4 drivers the CMS supports (PDO MySQL and PostgreSQL and MySQLi) should be in a testable state now (the PostgreSQL environment should be tested on 9.x, I have 10.0 installed locally and there are some new test failures in that version to be addressed next). The PostgreSQL driver for native ext/pgsql is having issues, see https://travis-ci.org/joomla-framework/database/builds/360958604 for failing Travis build. This is predominantly when using the DatabaseIterator objects, but there are two other failures outside that (one involving transactions and another the data type of a column in a prepared statement). Until I can sort those out I'm not merging that work back to this repo.

#20055 holds the changes ported to the CMS environment if anyone is willing to test.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18660

closed as having Pull Request #20055