Easy change.

CommentFileSizeAuthor
#1 easier_to_use_settings.patch1.67 KBchx
easier_to_use_settings.php.txt4.11 KBchx

Comments

chx’s picture

chx commented
StatusFileSize
new easier_to_use_settings.patch1.67 KB

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

ksenzee’s picture

ksenzee
she/her
commented

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

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Needs work » Needs review

Testing bot snafu.

chx’s picture

chx commented

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

andypost
he/him
Primary language Russian
commented

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

JamesAn commented

+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

dries commented

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

chx commented

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

chx commented

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

andypost
he/him
Primary language Russian
commented
Issue tags: +DX (Developer Experience)

@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

ksenzee
she/her
commented

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.

Issue tags: +DX (Developer Experience)

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.