Posted by iantresman on December 20, 2007 at 8:30pm
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | install system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
My Unix host does not use localhost to access the database, and I inadvertently overlooked the Advanced settings where the database host can be entered.
Is it not possible to check whether localhost is valid, and if not, automatically open the Advanced setting options?
Comments
#1
how could we check that there is a mysql running on localhost? that's impossible.
#2
Interesting idea. Promoting to "Usability".
If no server is running under localhost and you don't change the parameters in the collapsed "Advanced options" fieldset, the installer returns the cryptic error message: "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'". Maybe we could handle error messages intelligently and form_set_error the relevant fields depending on the error (ie. Host in case of a connection error, User and Password for an authentication error, etc.).
#3
Identified at UB Usability Testing: http://www.drupalusability.org/node/12
We get a form set error on the database name if field is empty, but no other field identifiable errors.
#4
This issue does not correspond to the issue found at UBUserTesting2009, that one was related to wrong password/username (although this one is related - its in the error) - I don't think it is part.
#5
The two issues are closely related -- as the error for both connection and login are handled as one.
Here's a patch to make things a bit more user friendly :)
[this is a small bugfix patch, just to get things reasonable ;). If it goes through I'll work on making the error handling intelligent and more helpful]
before screenshot
after screenshot
please review?
thanks,
Jared
#6
jabapyth, could you roll a 'regular' patch?
#7
When creating patches, please use the options -up.
#8
Ah, that's how it's done. sorry, couldn't seem to find the right arguments.
#9
The code comments need some work; better explanation and conform to our coding style.
<b>%error.</b>should be:<strong>%error</strong>.-- also note the position of the point.Otherwise looks good to me.
#10
Updated to address Dries code comment style and HTML issues.
#11
The last submitted patch failed testing.
#12
testbot failure.
#13
This looks good to me, but I haven't tested it. If someone can try testing this, it should be RTBC.
#14
thanks for doing that, michaelfavia
#15
It works fine.
I tried it with Mysql and SQLite.
#16
Committed to CVS HEAD. Thanks.
#17
Automatically closed -- issue fixed for 2 weeks with no activity.