Very much used to mysqli being proposed as first choice for the database type (as most Joomla users use that db type), I did not care about the field.
In fact the default field value is now MySQL (PDO).
It totally broke the installation here.
To get back mysqli as first choice, I had to modify the xml to set mysqli as first choice.
<field
name="db_type"
type="databaseconnection"
id="db_type"
class="custom-select form-control"
label="INSTL_DATABASE_TYPE_DESC"
supported="mysql,mysqli,pgsql,postgresql"
required="true"
default="mysqli" /// Changed here
filter="string"
/>
No idea if this is the real solution to that issue as I am not sure about the supposed use of MySQL (PDO) although I read http://php.net/manual/en/ref.pdo-mysql.php
Labels |
Added:
?
|
Build | staging | ⇒ | 4.0-dev |
Category | ⇒ | com_installer |
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-02-25 11:59:33 |
Closed_By | ⇒ | franz-wohlkoenig |
Closed_By | franz-wohlkoenig | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/19779
i think this should be reopened as the default db proposed is also broken
Status | Closed | ⇒ | New |
Closed_Date | 2018-02-25 11:59:33 | ⇒ | |
Closed_By | joomla-cms-bot | ⇒ |
@infograf768 Please do not randomly link unrelated issues, none of the items you linked has ANYTHING to do with what you are describing in this item.
default db proposed is also broken
No, it's not. The PDO driver works just fine and I have it in use on production sites. What is broken is you have something triggering a session in the scope of the install application trying to use the database handler which is impossible.
for me, again a cultural issue?, this shows as broken. i have no idea what is
The problem is not that it is trying to read the database. The problem is the session handler is trying to connect to the database. In the install application. When you do not have a configuration saved. And can't reliably connect to your database. That is unrelated to the order of options.
The installation application should always use the filesystem session handler.
As for this issue "PHP Fatal error: session_start(): Failed to initialize storage module: user (path: /Applications/MAMP/tmp/php)" this implies that the MAMP temp directory doesn't have suitable read/write permissions. efc468a might fix that by making the configuration try to use the PHP runtime configuration instead of completely ignoring it, no promises on that one though.
As for what PDO is, it's basically another database connector built in C as an extension of PHP itself. Similar to how there are different extensions for legacy MySQL, MySQLi, and PostgreSQL. PDO tries to act as an abstraction layer (similar to what our database API does) and allows connections to different database engines. In 4.0 we explicitly support both MySQL and PostgreSQL connections either through the native PHP extensions (ext/mysqli
or ext/pgsql
) or the PDO abstraction layer. The only thing that really changes at our level is what internal PHP code is executed.
Title |
|
I modified the title of this issue to fit.
Status | New | ⇒ | Discussion |
Change the type at https://github.com/joomla/joomla-cms/blob/4.0-dev/installation/src/Model/DatabaseModel.php#L343 to "mysql" instead of "pdomysql".
Change the type at https://github.com/joomla/joomla-cms/blob/4.0-dev/installation/src/Model/DatabaseModel.php#L343 to "mysql" instead of "pdomysql".
This works, but should it no be also modified elsewhere in core?
https://github.com/joomla/joomla-cms/blob/4.0-dev/installation/src/Model/SetupModel.php#L464
(That one looks a bit redundant with the same method in DatabaseModel)
Also
https://github.com/joomla/joomla-cms/blob/4.0-dev/installation/src/Form/Field/Installation/SampleField.php#L44
https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Installer/Installer.php#L954
https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Installer/Installer.php#L1121
What about the code in libraries/src/Service/Provider/Database.php?
And also in test pdomysql.php?
You know, at one point I made all the required changes for that move, so I really don't know why all these problems are back.
I'll leave these modifications to the powers that be.
For example, it may be that the code in libraries/src/Service/Provider/Database.php is there for B/C.
Over my abilities.
Read the inline commentary in the database provider, it is a B/C layer
Can the problem be the move to namespaces in the installation app? Did I screw something up?
my tests show that using mysql instead of pdomysql works fine. The xml does not use pdomysql.
The xml should not use pdoxml as that would be invalid
Did I screw something up?
When the install app was converted to its current state some of the changes I made related to moving to the Framework's database package were lost (all the code references to "pdomysql" should have been replaced as seen in #16402 but looking at the current code they're back). So like I said, we just need to do another scan on the code base and find these remaining references and fix them.
Labels |
Added:
J4 Issue
|
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-03-26 05:24:55 |
Closed_By | ⇒ | franz-wohlkoenig |
Closed_By | franz-wohlkoenig | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/19779
Error log shows this