Easy change.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chx’s picture

Erm wait. Poor patch got confused with the per connection prefix patch :)

ksenzee’s picture

I agree that settings.php has gotten really hard to use. This would make it easier to use, but significantly harder for new people to understand. So -1 from me. We ought to do something to solve the problem though. Maybe a Drush getter/setter for some of these variables?

Status: Needs review » Needs work

The last submitted patch failed testing.

webchick’s picture

Status: Needs work » Needs review

Testing bot snafu.

chx’s picture

So who will use this and why? Everyone to allow update access, update.php tells you what to do and now the variable is on the top so ... that's about $update_free_access . The rest is only important to Drupal sitebuilders and they will be quite glad that they do not need to hunt for DB creds any more.

andypost’s picture

Very big +1 for the patch, sometimes I need to make updates on sites (support) but often admin password has changed.

So everytime I put $update_free_access = FALSE; at the top of the file because I dont wanna scroll at console.

Glad to RTBC!

JamesAn’s picture

+1 from me too. I think moving the vars to the top is for the better.

I think the added blurb is good enough explanation, even for new people:

+// Explanation for these variables can be found below by searching on their
+// names.

Time to RTBC this thing?

Dries’s picture

Personally, I don't think this is better so I'm tempted to mark this "won't fix".

It seems like something that is perfectly reasonable to do on your development copy of settings.php, but not in the default settings.php file that ships with core.

chx’s picture

Dries, once again the typical usages for settings.php is

  1. Flipping the access variable -- this patches makes this easier as it's much easier to find.
  2. To quote andypost, "sometimes I need to make updates on sites (support) but often admin password has changed." -- do you remember the mysql credentials for all the sites you need to work with? I do not and need to read them from settings.php which is now a lot easier. I can do it with my own sites yeah but if we make this change then I can see immediately on other peoples sites, too :)
chx’s picture

And also, if you find awkward to have the database info before the comments, we can move the database part to the end of settings which makes it equally easy.

andypost’s picture

@chx Agree exactly - it's very useful if access variable and DB setting stays at top of file so no need to search them inside comments.

@Dries Why you dont want this out of box? It save a lot of time for many devs to not copy-paste this settings from middle of file to its top!

Lets compare how many people read contents of setting.php and how many change it...

ksenzee’s picture

DX has to include new Drupal developers too. They're very likely to hunt around for "the config file", find it, and try to figure out what it's doing. That introduction to Drupal should not be a WTF.

If all you want is to see your database connection details, try "drush sql conf". That's a lot faster than opening settings.php, even if what you want is at the top of the file. A setter might be useful, as might a command to toggle $update_free_access. But I do think this kind of highly tuned DX stuff belongs in Drush, not in settings.php where a bunch of brand new devs are going to start the long uphill climb.

Status: Needs review » Needs work
Issue tags: -DX (Developer Experience)

The last submitted patch failed testing.