Hi guys, I've noticed that the past 2 commits to settings.php were both made inadvertently, due to someone including a settings.php $db_url change in their patch by mistake. As you can see, both of these commits had to be reverted: http://drupal.org/cvs?file=/sites/default/settings.php Can I request that all of the patch authors among us (including myself) _please_ check your patch files, and that you ensure that there are no custom settings.php $db_url (or other) changes that have slipped into your patch. I think that the primary responsibility for this should lie with patch authors. However, it would be good if the core committers could be on the lookout for accidental settings.php changes in patches as well. If anyone has any tips for excluding settings.php from a patch, that would be greatly appreciated. Personally, I just run "cvs diff -u > foo.patch" from the root Drupal install dir, and then manually edit the file to remove the settings.php cruft. I'm sure there's a better way to do it. ;-) The biggest problem that I have with accidental settings.php changes, is that running "cvs up -dP" after such a change results in CVS complaining about a conflict/merge in settings.php, even though the change was reverted. So let's try and keep _intentional_ settings.php changes to a minimum (which we seem to be doing quite well at), and keep _accidental_ settings.php changes to zero. Thanks, Jaza.
I'm the guilty party involved, and apologize for slipping that error into a largeish patch at the last minute. Only while testing the installer have I started working with actual command-line use of patch and diff, and have forgotten to move my default settings file a couple of times. I, too, (usually!) just cvs diff and manually remove the cruft. Thanks for the reminder. It is, indeed, very important. :) --Jeff -----Original Message----- From: Jeremy Epstein [mailto:jazepstein@gmail.com] Sent: Wednesday, August 02, 2006 10:05 PM To: Drupal devel Subject: [development] Patching settings.php Hi guys, I've noticed that the past 2 commits to settings.php were both made inadvertently, due to someone including a settings.php $db_url change in their patch by mistake. As you can see, both of these commits had to be reverted: http://drupal.org/cvs?file=/sites/default/settings.php Can I request that all of the patch authors among us (including myself) _please_ check your patch files, and that you ensure that there are no custom settings.php $db_url (or other) changes that have slipped into your patch. I think that the primary responsibility for this should lie with patch authors. However, it would be good if the core committers could be on the lookout for accidental settings.php changes in patches as well. If anyone has any tips for excluding settings.php from a patch, that would be greatly appreciated. Personally, I just run "cvs diff -u > foo.patch" from the root Drupal install dir, and then manually edit the file to remove the settings.php cruft. I'm sure there's a better way to do it. ;-) The biggest problem that I have with accidental settings.php changes, is that running "cvs up -dP" after such a change results in CVS complaining about a conflict/merge in settings.php, even though the change was reverted. So let's try and keep _intentional_ settings.php changes to a minimum (which we seem to be doing quite well at), and keep _accidental_ settings.php changes to zero. Thanks, Jaza.
Can I request that all of the patch authors among us (including myself) _please_ check your patch files, and that you ensure that there are no custom settings.php $db_url (or other) changes that have slipped into your patch. I think that the primary responsibility for
Generally speaking, if you suspect yourself of making a patch for core, you shouldn't use sites/default - use sites/disobey.com or what have you. Then you never have to worry about it (unless, of course, you make a patch that adds a file). -- Morbus Iff ( i subscribe to the theory of intellectual osmosis ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
If anyone has any tips for excluding settings.php from a patch, that would be greatly appreciated.
i made the same mistake once ... now i always copy sites/default to sites/127.0.0.1 and edit settings.php there. substitute 127.0.0.1 for your domain name if you are not developing locally. this insures that i never get conflicts, and never include my settings in a patch.
Jeremy Epstein wrote:
Hi guys, http://drupal.org/cvs?file=/sites/default/settings.php
The root cause of this is the installer, which writes directly to settings.php. I propose we move settings.php to settings-dist.php (or similar) and the installer can copy that and update rather than write to a file that is in CVS. At the same time, I think we should do the same with .htaccess if we can, because often .htaccess needs to be modified locally, and it's annoying having to weed that out of patches too. Of course, that's a little more complex due to needing write permissions and all.
Jeremy Epstein wrote:
Hi guys, http://drupal.org/cvs?file=/sites/default/settings.php
The root cause of this is the installer, which writes directly to settings.php.
I propose we move settings.php to settings-dist.php (or similar) and the installer can copy that and update rather than write to a file that is
in CVS.
Earl, after spending some time thinking things over this is a really important step. I just spent some time thinking through this, and looking at the install code again. I believe we would have to: 1) Store the 'clean' copy in settings-dist.php 2) Check for the presence of settings.php, and *always assume* that file is configured if it's present 3) If there's no settings.php, assume we're about to install 4) Once we've installed, COPY the settings-dist.php file to settings.php (rather than renaming it or deleting it) Does that make sense? --Jeff
Earl Miles wrote:
Jeremy Epstein wrote:
Hi guys, http://drupal.org/cvs?file=/sites/default/settings.php
The root cause of this is the installer, which writes directly to settings.php.
The problem is that the installer writes to the file in default/settings.php. The installer should create an appropriate subdiretory /mydomain and then copy the settings.php file there and write to the copy. To quote Steven "if we are going to have an installer we might as well do it right". :p Cheers, Gerhard
Gerhard Killesreiter schrieb:
Earl Miles wrote:
Jeremy Epstein wrote:
Hi guys, http://drupal.org/cvs?file=/sites/default/settings.php
The root cause of this is the installer, which writes directly to settings.php.
The problem is that the installer writes to the file in default/settings.php. The installer should create an appropriate subdiretory /mydomain and then copy the settings.php file there and write to the copy.
To quote Steven "if we are going to have an installer we might as well do it right". :p
Cheers, Gerhard
Yes, I did also wonder about that. Actually, we *should* do it right, which means letting the installer create a new directory in sites/ and copying settings.php there.
I like the -dist idea by Earl, and what Jeff is proposing. The other day, I did an install on my head checkout, and got SQL errors, because I already had a subdomain.example.com directory and settings.php in it. So, I erroneously assumed that the installer does not touch settings.php, and wrote an article about it, which several people (including Jeff) corrected. Only when I copied the default/settings.php to the subdomain.example.com was I able to see the installer work properly. Yes, we should make the installer create the multi-site directories. This means settings.php and themes at a minimum. Now that we have sites/all in there, a per site modules directory is not needed in most cases.
Gerhard Killesreiter wrote:
The problem is that the installer writes to the file in default/settings.php. The installer should create an appropriate subdiretory /mydomain and then copy the settings.php file there and write to the copy.
So we'll need another option in the installer to specify the hostname of the site being installed, yeah? -Rowan
Well, it's easy enough to auto-detect the current hostname. The question is whether it should be stored in sites/default, sites/www.example.com, sites/example.com... And so on and so on. I, for one, absolutely despise urls that don't have 'www' at the beginning -- the http://example.com style. It jst bugs me. I'd loathe having drupal default my sites to that style, but explaining the subtleties of how to specify your domain name makes things tricky. I *lean* towards the idea of installing in sites/default, and allowing users to create their own sites directories with an unmodified default-settings.php file. Sifting through the tricky bits of intelligently picking the right directory (or helping the user to) is... A complicated beast, I think. But then, I could be wrong -- it might not be as complicated as I fear. --Jeff -----Original Message----- From: Rowan Kerr [mailto:rowan@stasis.org] Sent: Thursday, August 03, 2006 7:03 PM To: development@drupal.org Subject: Re: [development] Patching settings.php Gerhard Killesreiter wrote:
The problem is that the installer writes to the file in default/settings.php. The installer should create an appropriate subdiretory /mydomain and then copy the settings.php file there and write to the copy.
So we'll need another option in the installer to specify the hostname of the site being installed, yeah? -Rowan
On 8/3/06, Jeff Eaton <jeff@viapositiva.net> wrote:
Well, it's easy enough to auto-detect the current hostname. The question is whether it should be stored in sites/default, sites/www.example.com, sites/example.com... And so on and so on.
Drupal (at least 4.7) handles the incoming host as the base_url.
From this code in bootstrap.inc:
$base_root = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') ? 'https' : 'http'; $base_url = $base_root .= '://'. $_SERVER['HTTP_HOST']; Althought this allows you to skip the base_url part, it has its own issues though, things that rely on $base_url will get more than one of them. For example, the referrers report under admin/logs will be screwed up, and will show www as being external referrals, or the other way around. The www vs plain can be solved by a symbolic link from one to the other.
I, for one, absolutely despise urls that don't have 'www' at the beginning -- the http://example.com style. It jst bugs me. I'd loathe having drupal default my sites to that style, but explaining the subtleties of how to specify your domain name makes things tricky.
I feel the opposite. The www prefix is redundant ... But that is a religious argument ...
I *lean* towards the idea of installing in sites/default, and allowing users to create their own sites directories with an unmodified default-settings.php file. Sifting through the tricky bits of intelligently picking the right directory (or helping the user to) is... A complicated beast, I think.
But then, I could be wrong -- it might not be as complicated as I fear.
--Jeff
-----Original Message----- From: Rowan Kerr [mailto:rowan@stasis.org] Sent: Thursday, August 03, 2006 7:03 PM To: development@drupal.org Subject: Re: [development] Patching settings.php
Gerhard Killesreiter wrote:
The problem is that the installer writes to the file in default/settings.php. The installer should create an appropriate subdiretory /mydomain and then copy the settings.php file there and write to the copy.
So we'll need another option in the installer to specify the hostname of
the site being installed, yeah?
-Rowan
Jeff Eaton wrote:
Well, it's easy enough to auto-detect the current hostname. The question is whether it should be stored in sites/default, sites/www.example.com, sites/example.com... And so on and so on.
I, for one, absolutely despise urls that don't have 'www' at the beginning -- the http://example.com style. It jst bugs me. I'd loathe having drupal default my sites to that style, but explaining the subtleties of how to specify your domain name makes things tricky.
We would use the url that the admin uses. That's apparently the one that he expects others to use too. I've been working on the CS installer, and it did it this way. Kieran, did anybody complain about this? Cheers, Gerhard
Gerhard Killesreiter wrote:
We would use the url that the admin uses. That's apparently the one that he expects others to use too. I've been working on the CS installer, and it did it this way. Kieran, did anybody complain about this?
You're right; I'm not sure what I was thinking. Moshe wrote:
this strikes me as getting too smart for our own good. using the host name, or worse, and host name + path, makes the install less portable. it also complicates docs and training because everyone's settings.php will be in a different place by default.
One of the problems is that right now, it's painfully difficult to install a multisite. Because we overwrite settings.php, BUT we require a pristine copy for the installer to work correctly, AND we no longer include sql files for manual installation, it's no longer possible to simply copy sites/default and go. You have to copy it, delete settings.php, download a new copy from drupal.org, copy IT over, THEN run the installer on your new domain. --Jeff
Jeff Eaton wrote:
One of the problems is that right now, it's painfully difficult to install a multisite. Because we overwrite settings.php, BUT we require a pristine copy for the installer to work correctly, AND we no longer include sql files for manual installation, it's no longer possible to simply copy sites/default and go. You have to copy it, delete settings.php, download a new copy from drupal.org, copy IT over, THEN run the installer on your new domain.
I've been making the new directory and setting up the settings.php in a new directory. Then, I go to install.php and it does the install (without asking anything) and says its done. Completely undocumented, but it works somehow. I don't trust the installer with any permissions on sites/... since it wrote .../default/settings.php when I first tried it and that managed to make it into a commit. -- Neil Drumm http://delocalizedham.com/
@Gerhard I like the idea of using the host the admin used. This is the safest and probably 'correctest' bet ... @Moshe Installing to default is good, until you decide to go to multi site, like I did from 4.6 to 4.7. NOW you have unportabe data, since all the images and files are now in sites/example.com/files and not in sites/default/files. I had to manually edit many nodes to change the paths for images and files. The reverse is seemless though: if a sites outgrows the current multisite install, and I decide to go from sites/example.com/files to a single site, everything is where it is and it is more portable that way. @Neil I also found out the same: if you copy the default settings.php to example.com/settings.php and point your browser to the url http://example.com, then install.php will be called and it works the same way as if on default/settings.php Very convenient ... @Jeff Substitute example.com with www.example.com above :-)
I *lean* towards the idea of installing in sites/default
so do i. this strikes me as getting too smart for our own good. using the host name, or worse, and host name + path, makes the install less portable. it also complicates docs and training because everyone's settings.php will be in a different place by default. -moshe
participants (10)
-
Earl Miles -
Frando (Franz Heinzmann) -
Gerhard Killesreiter -
Jeff Eaton -
Jeremy Epstein -
Khalid B -
Morbus Iff -
Moshe Weitzman -
Neil Drumm -
Rowan Kerr