Document all database settings in default.settings.php

One thing we could do is change the host field into a host/socket field (after all it's already a file for SQLite). I consider this a feature request.

Yeah, something like that might be the simplest possible solution (although I am under the impression that socket is a replacement for both host and port, not just host?).

There is also a more general issue that aims to allow any database driver to add or modify options on this form in any way they want to:
#346494: DB drivers need to be able to change the configure database form during install

The socket being referred to here is for the path to the socket file opened by mysql (e.g. /tmp/mysql.sock). I needed this param available so i could install d7 on zend server ce. Here's the patch...

After doing a little more research, and as stated above, socket is a replacement for host/port on mysql. There's an issue with specifying 'localhost' for the address of the database. Some LAMP stacks will use the socket instead. If the user runs into issues with this, such as on Zend Server, specify the address as '127.0.0.1'.

I see that some code in the database.inc file is already set up for socket connection, has this issue been fixed?

after going through the latest nightly the patch above DOES work, im not sure why the test system says it fails.

I did an install of the D7 beta posted yesterday on my Mac (Snow Leopard, running the Acquia Drupal stack), with MySQL running on 33066. The install failed every time I used "localhost", regardless of whether or not settings.php had been configured, as has been described above.

When, following instructions from response #7, I used "127.0.0.1", installation succeeded. This is, in my naive view, a bug rather than a feature request. "localhost" is valid and should be supported.

Just tried to install D7 RC1 however on my Mac (OS X 10.6 + Zend Server CE) localhost and '127.0.0.1' both fail the install, i have attempted to create a symlink from the default to my specific socket but this also fails.

I was just about to go over and see if this patch that work durring the bata's would still work, however i see that the entire way that install forms are generated are completely different.

Could we have a new patch please? I attempted one myself but can't seem to figure out where the new form elements are coming from. It should be easy all it seams is missing is the actual form element, the code is already set up to use it.

Drupal 7 is now at RC1. Form changes will not be accepted so this would have to wait until D8.

Alternatively Install Profiles have the ability to add to the installation process so you could create a Zend Server installation profile.

Also I run Zend Server and I just do the following:

cd /tmp
sudo ln -s /usr/local/zend/mysql/tmp/mysql.sock

I think this needs corresponding validation to ensure that the socket exists. Also how does windoze do sockets? will this work there?

Zend Server running upon AS/400 (iSeries/i5os, etc.) need to install with socket. If someone has patch for version 7.x, then I will test.

(Note: Magento allows install with socket. Zend Server AS/400 socket /var/tmp/mysql.sock)

@kent_zacharias the easiest way will be to create a symlink during install
ln -s /var/tmp/mysql.sock /tmp
then after install you can set the proper socket in settings.php.

Zend Server Version 5.0.4, As/400 V5R4M0, PHP Version 5.3.3, MySQL library version 5.0.45 MySQL server version 5.1.50.

I see no reference to "sockets" in settings.php

- Added proper unix socket support for PostgreSQL.
- Added support to specify a unix socket during the install on non-Windows operating systems.

Opps, forgot to add in core/includes/database/mysql/database.inc.

Related: #1409108: Improve "Failed to connect to database" Error message—we should probably improve the error message in a manner similar to the way described there if we add this option to install, since this change makes it more likely that a mismatch between the system and Drupal values might occur.

27: drupal-unix-socket-ui-793200-27-d8.patch queued for re-testing.

Reroll.

I think it could be a separate issue, but I do not like the hardcoded default port numbers such as MySQL 3306 and PostgreSQL 5432, because it is easily can be changed on compile time (compile from source), and it can be overwritten in by the php.ini.

There is a settings for the default socket in the php.ini
pdo_mysql.default_socket
http://www.php.net/manual/en/ref.pdo-mysql.php#pdo-mysql.configuration

There is no default "hostname" and "port" settings in the PDO section, but they are exists in the "mysqli" and "mysql" sections.
http://www.php.net/manual/en/mysqli.configuration.php

So the question is that can we replace the hardcoded default "hostname" and "port" numbers with an ini_get()?

In some cases the host:port based connection is disabled.

Can this be clarified in the issue summary, please? Where and how and when?

Pretty much every resource on the web explains that (1) There is no measurable performance difference between TCP to localhost vs. sockets, (2) Many other OS-level services are using TCP, (3) TCP is more flexible, and lastly, (4) In the exact situation where a performance improvement of a socket connection would become measurable (large-scale, high-traffic), a typical/modern web stack setup does not have a local database server in the first place, but operates with (at least) one slave/fallback.

(I assume this feature request must be performance related, because I have not seen a shared hosting provider in the past decade that wouldn't support TCP [only, even].)

@sun #33 If we do not provide UI for the unix_socket connection then why the core support it under the hood?
I think we have two options:

• Add UI for it. (this issue)
• Remove the support at all

The current situation is inconsistent.

EDIT: However I agree with your 4 points

There's no need for black/white thinking — Drupal core has plenty of settings and configuration options that cannot be configured through the user interface.

#2160705: settings.php setting names are inconsistent (and undocumented) lists a couple of them.

The user interface should cover the 80% use-cases. Drupal can happily support additional/advanced (non-UI) features under the hood (if there is community consensus that a feature is valuable to have/support.)

One more reason is usability/UX — not every supported feature has to be exposed and clutter the user interface. → Simplicity. Let's also bear in mind that the installer plays a key role in the first-time experience of Drupal for pretty much every new user.

I wasn't aware that we have support for sockets in our Database drivers already, but that is good news. :)

If you have one of the (very few?) use-cases in which you want/need to use sockets, then you can use this feature by preparing a settings.php, which contains corresponding $databases connection info before hitting the installer.

That method applies to all possible settings overrides — for example, if you want to install with custom public/private/temporary files directories, then you equally need to prepare settings.php with those values, before hitting install.php.

Just to be clear: I'm not saying that sockets should not be supported in the installer UI. All I'm really saying is, before cluttering the installer with further options, we should ensure that there are actually (sensible) use-cases for those options.

FWIW, I like the code changes to split up and clean up the database driver form options (to not include options that do not make sense for a driver, such as SQLite). Regardless of whether socket support is going to be added to the UI, I think we should do those changes. Perhaps it would be a good idea to split those into an own issue?

OK. The code clean up could be a separate issue. (Remove the unnecessary elements from SQLite).

And what about the idea in comment #31 ? (Hard coded default host name and port number)

What's the next step?

What's the next step?

Reroll #793200-30: Document all database settings in default.settings.php so as to test cleanly (updating tests as necessary), and to use the vars from #793200-31: Document all database settings in default.settings.php instead of the hardcoded port numbers. Create fresh before/after screenshots and put them in the issue summary. Push state to "needs review". Then someone (or multiples "someones") will review the UI changes and the code underlying them, and decide whether they make sense. If they do, the issue will be pushed into RTBC. Once that is done, a maintainer will do a final review and either push the patch in, or fail it back to Needs Work with feedback on what needs to be changed.

Of course, at any point, this can also go into WONTFIX, but that's a separate path that I won't document here.

What I read is that using sockets is likely not even a 20% use case, so there's no strong case to add options for it in the UI.

However, this already plays in the advanced fieldset which is collapsed by default so adding this wouldn't be disruptive to the flow for the 80% that doesn't have to get into this fieldset to complete installation.

If we add this UI then it's best to use js states and bring the configuration settings for each option inline:

And, for the unix socket path field, don't add the "Path to Unix socket" description, make the label itself more explicit instead: "Unix socket path".

Disappointed that this never hit Drupal 8. I just spent hours trying to make this work, tracing PHP code, and had to hack core to finally get it working. I had to hardcode "unix_socket" array value in core/lib/Drupal/Core/Database/Driver/mysql/Connection.php, for what it's worth.

I obviously don't want to leave the hardcode in there but I'm not sure how to even specify it elsewhere? In the pdo options when setting up my database in settings.php?

I had also created this stack exchange post:

https://drupal.stackexchange.com/questions/277053/how-to-configure-mysql...

Anyways, I have a current Drupal 6 site (where sockets just worked after you ini_set in settings.php) that I'm looking to upgrade to either Drupal 8 or something else, and just running into this right away is putting me off. How much else am I going to have to hack? Hopefully nothing, but even if 20% of users use sockets, then you're probably turning away 99% of those users from ever using Drupal 8.

hansamurai: in settings.php

$databases['default']['default'] = array (
  'database' => 'mydatabase',
...
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
  'unix_socket' => '/var/lib/mysql/mysql.sock',
);

In core/lib/Drupal/Core/Database/Driver/mysql/Connection.php this value is checked and if present, unix socket will be used spite of TCP/IP:
(Lines 383-)

// The DSN should use either a socket or a host/port.
    if (isset($connection_options['unix_socket'])) {
      $dsn = 'mysql:unix_socket=' . $connection_options['unix_socket'];
    }
    else {
      // Default to TCP connection on port 3306.
      $dsn = 'mysql:host=' . $connection_options['host'] . ';port=' . (empty($connection_options['port']) ? 3306 : $connection_options['port']);
    }

This was a bugsmash triage target a few days ago. lendude, borisson_ and myself agree that this should be addresses in documentation, not code. Comment #35 explains our viewpoint.

Changing to the DX special tag defined on Issue tags -- special tags.