[drupal-devel] [task] Usability tweaks: INSTALL.txt, .htaccess,
settings.php.
Morbus Iff
drupal-devel at drupal.org
Fri Jul 29 21:36:42 UTC 2005
Issue status update for
http://drupal.org/node/18641
Post a follow up:
http://drupal.org/project/comments/add/18641
Project: Drupal
Version: cvs
Component: base system
Category: tasks
Priority: normal
Assigned to: Morbus Iff
Reported by: Morbus Iff
Updated by: Morbus Iff
Status: patch
I still stand behind the (identical) patches in #30 and #31.
I don't see how a non-symlink solution will work with mod_rewrite.
Regarding Dries' comments:
* I don't like "subsite" - it presumes too much (that it is some
"subset" of a greater whole)
* The information is a "good thing" because otherwise, people will
wonder why it doesn't work.
* Multiple files and vhosting is ALREADY an advanced topic; there is
no other place for it, IMO.
Morbus Iff
Previous comments:
------------------------------------------------------------------------
Wed, 09 Mar 2005 19:54:23 +0000 : Morbus Iff
The following patches clear up a number of minor inconsistencies during
a Drupal installation. Largely, this is related to internal
documentation and "where things go", but should help organize, clearup,
and ease the installation. These aren't features, so they're eligible
for a 4.6 commit.
* The INSTALL.txt no longer contains the SERVER CONFIGURATION block.
These settings are now hardcoded into sites/default/settings.php, and
are merely scary technical junk here.
* The INSTALL.txt has been updated with the latest system requirements.
A whole sentence was struck regarding differing versions of PHP for the
OSs.
* The INSTALL.txt contains URLs to MySQL and PostgreSQL. If we're
including the URL for PHP in the same sentence, then there's no reason
why we wouldn't include them for the database engines. What are the
minimal requirements for the RDBMS? Those should be included here too.
* The INSTALL.txt's OPTIONAL COMPONENTS has renamed to OPTIONAL
REQUIREMENTS. The only difference between the meaning is the amount of
user confusion.
* The INSTALL.txt has a new CONTENTS OF THIS FILE, in hopes that people
will more immediately notice that there are upgrade instructions at the
bottom.
* The INSTALL.txt had some potentially confusing lines adjusted,
including further clarifications, standarding to "userid" (instead of
using both userid and username interchangebly) and so on.
* I've moved most of .htaccess php_value's to the ini_set system for
/sites/. There are a few reasons for this, chiefly that it is
centralizing all the PHP setting modifications to one place. But, this
also clears up a few initial configuration issues: first, the user
doesn't have to worry about whether they have Apache 1 or 2, and
whether they need to change an IfModule line. Also, the running
assumption is that these php_value's are /going to work by default
anyways/, when the INSTALL.txt suggests otherwise (under OPTIONAL
REQUIREMENTS, it talks about "the ability to use local .htaccess
files", which suggests that "local .htaccess files" INCLUDING
"mod_rewrite" are entirely optional.) Some variables, however, had to
remain in .htaccess because they can't be overridden at runtime, but
the amount was so small that duplicating them for both Apache 1 and
Apache 2 possibilities is no longer a prohibitive concern.
* There are two variables in .htaccess that I'm concerned about:
track_vars, and allow_call_time_pass_reference. track_vars appears to
be no longer necessary (as of 4.0.3, track_vars is /always/ on [1], and
my setting it here had no impact on the results of a phpinfo), and
allow_call_time_pass_reference seems, at least here, to ONLY WORK if
the .htaccess value is set to "1", and not "On" - meaning that Drupal
installations are currently working correctly with its default value
(off). According to the PHP docs, this feature is now deprecated.
However, since both of these variables require further investigation,
track_vars has been moved to settings.php, and
allow_call_time_pass_reference has been "fixed" to a 1 (not 'On').
* Along with the changes above for sites/default/settings.php, I've
also removed the spacing indent in the documentation, as well as many a
few grammatical/punctuation changes here and there. I don't think the
leading spacing is "right" according to the style guidelines, but maybe
there's a special need for it. Correct me if I'm wrong.
These patches were made during the exploration and customization of
Drupal by NHPR.org. In loving support of open source software, NHPR.org
will continue to contribute patches they feel the community will benefit
from.
[1] http://us3.php.net/session
------------------------------------------------------------------------
Wed, 09 Mar 2005 19:54:46 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/patch01_.htaccess (3.36 KB)
------------------------------------------------------------------------
Wed, 09 Mar 2005 19:55:07 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/patch01_INSTALL.txt.patch (10.26 KB)
------------------------------------------------------------------------
Wed, 09 Mar 2005 19:55:24 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/patch01_settings.php.patch (6.21 KB)
------------------------------------------------------------------------
Wed, 09 Mar 2005 20:12:26 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/patch01_INSTALL.txt_0.patch (10.27 KB)
Slight revision of the previous INSTALL.txt patch. One of the added
Contents was listed wrong.
------------------------------------------------------------------------
Wed, 09 Mar 2005 21:02:24 +0000 : Chris Johnson
Well done. Cleaning up this kind of stuff is not as exciting as cutting
code, but it really helps the over-all quality. My hat is off to you.
------------------------------------------------------------------------
Sat, 12 Mar 2005 10:51:52 +0000 : Dries
Good stuff! Committed to HEAD. Thanks Morbus.
------------------------------------------------------------------------
Sat, 12 Mar 2005 15:29:25 +0000 : Morbus Iff
Dries - did you mean to remove the ".conf" extension from the .htaccess
Deny?
------------------------------------------------------------------------
Sat, 12 Mar 2005 15:30:06 +0000 : Morbus Iff
Oh wait. Nevermind. We don't have any of those extensions anymore. My
bad.
------------------------------------------------------------------------
Sun, 13 Mar 2005 16:58:05 +0000 : TDobes
As for allow_call_time_pass_reference, I would tend to agree that we
don't need it at all. See this drupal-devel topic from a while ago
[2]. Since then, I've been running with it in the "OFF" state and have
experienced no problems with core or a variety of contrib modules and
themes. See also: the php.net description of why it's deprecated [3].
One comment about the INSTALL.txt changes: I think you meant PHP
4.3*.*3 as the minimum version... not 4.33. :-)
With 4.3.3 as the minimum requirement, I'd also say it's safe to get
rid of track_vars... I see no difference with it removed.
Also: Why do we have short_open_tag in there? I'm pretty sure we use
the long form of the php open tag throughout Drupal and almost all
contrib modules. (those that do not should be fixed, IMO)
[2] http://lists.drupal.org/archives/drupal-devel/2004-07/msg00474.html
[3]
http://us3.php.net/manual/en/ini.core.php#ini.allow-call-time-pass-reference
------------------------------------------------------------------------
Mon, 14 Mar 2005 20:07:24 +0000 : Anonymous
Attachment: http://drupal.org/files/issues/03_cleandocs2.patch (3.33 KB)
Per TDobes comments:
* INSTALL.txt corrected to use 4.3.3, not 4.33.
* .htaccess: removed allow_call_time_pass_reference. two confirmations
that a) the setting was wrong in the first place, b) there were no
adverse affects for the incorrect setting, c) the PHP docs say it is
deprecated.
* .htaccess: removed short_open_tag. Running grep -r "<? " * across the
entire directory tree of both core and contributions only brought up
contributions and no core. I agree that the fuller form is better. The
following contributions will need to be updated:
modules/edit_template/edit_template.module
sandbox/garym/themes/marvin_2k/templates/page.tpl.php
sandbox/killes/compare.php
sandbox/paolino/import/click.php
themes/spreadfirefox/block.tpl.php
For error's sake, I also did a manual verification for "<?" (no space)
across core and came up against nothing in addition to the above
contribs.
And my own further analities:
* .htaccess: cleaned up some whitespace valleys (i hate 'em, hate 'em!)
and fixed a few stray colons.
* settings.php: minor whitespace error.
------------------------------------------------------------------------
Mon, 14 Mar 2005 20:08:45 +0000 : Morbus Iff
Comment #10 is mine.
------------------------------------------------------------------------
Mon, 14 Mar 2005 20:24:52 +0000 : TDobes
Looks good to me. +1
------------------------------------------------------------------------
Mon, 14 Mar 2005 20:42:02 +0000 : Goba
Do not depend on PHP.ini defaults please. It would be essential to get
back the session.auto_start 0 setting into .htaccess, or otherwise
those, who have this turned on in their PHP will get ugly errors, since
the database session handler will not be able to initialize and work at
all...
------------------------------------------------------------------------
Mon, 14 Mar 2005 20:45:26 +0000 : Morbus Iff
Per the already-committed patch, session.auto_start 0 has been moved to
sites/default/settings.php. Per the PHP documentation,
session.auto_start is a runtime variable: http://us4.php.net/session.
------------------------------------------------------------------------
Mon, 14 Mar 2005 20:54:10 +0000 : Goba
Morbus, read this in the manual: session.auto_start specifies whether
the session module starts a session automatically on request startup
Request startup, you see? It might be possible to modify the setting
later, but if session auto start is enabled on the server, it will
start the session with the handler set in php.ini (the "files" handler
by default) and you will not be able to use a different handle later
on. Have you tried it? We just provided support [4] to a clueless user
at drupal.hu, who had this auto start turned on and then the ini_set()
was unable to change the save handler. Although the linked comment is
hungarian, all the PHP codes and PHP errors are English, and are easy
to understand.
[4] http://drupal.hu/node/304#comment-793
------------------------------------------------------------------------
Mon, 14 Mar 2005 21:00:15 +0000 : Goba
BTW track_vars would also be pointless to set from PHP, since it is also
affecting request startup processing, but quoting from the manual: Note
that as of PHP 4.0.3, track_vars is always turned on. – and given
Drupal's PHP requirements, it is not needed anymore.
------------------------------------------------------------------------
Mon, 14 Mar 2005 21:01:47 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/03_cleandocs2_0.patch (3.69 KB)
Confirmed. Updated version of patch #10 attached.
------------------------------------------------------------------------
Mon, 14 Mar 2005 21:04:55 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/03_cleandocs2_1.patch (3.9 KB)
This patch removes track_vars entirely.
------------------------------------------------------------------------
Tue, 15 Mar 2005 18:40:37 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/03_cleandocs2_2.patch (5.33 KB)
Updating this to critical, as the previous patch broke the build (see
Goba's comments).
Per TDobes' comments:
* INSTALL.txt corrected to use 4.3.3, not 4.33.
* .htaccess: removed allow_call_time_pass_reference. two confirmations
that a) the setting was wrong in the first place, b) there were no
adverse affects for the incorrect setting, c) the PHP docs say it is
deprecated.
* .htaccess: removed short_open_tag. Running grep -r "<? " * across the
entire directory tree of both core and contributions only brought up
contributions and no core. I agree that the fuller form is better. The
following contributions will need to be updated:
modules/edit_template/edit_template.module,
sandbox/garym/themes/marvin_2k/templates/page.tpl.php,
sandbox/killes/compare.php, sandbox/paolino/import/click.php,
themes/spreadfirefox/block.tpl.php. For error's sake, I also did a
manual verification for "<?" (no space) across core and came up against
nothing in addition to the above contribs.
Per Goba's comments:
* .htaccess: Moved session.auto_start back.
* sites/default/settings.php: Removed track_vars.
Per mailing list comments [5]:
* INSTALL.txt: Added text about the files/ directory, creating it, and
permissions.
* INSTALL.txt: Added an example of why Drupal requires cron (the
search.module) in an attempt to justify why a crontab is a good, nay,
required step.
And my own further analities:
* .htaccess: cleaned up some whitespace valleys (i hate 'em, hate 'em!)
and fixed a few stray colons.
* settings.php: minor whitespace error.
[5] http://lists.drupal.org/archives/drupal-devel/2005-03/msg00630.html
------------------------------------------------------------------------
Tue, 15 Mar 2005 21:08:06 +0000 : Dries
Committed to HEAD.
------------------------------------------------------------------------
Thu, 17 Mar 2005 14:17:48 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/05_cleandocs3.patch (2.26 KB)
Adding a block per this thread [6] regarding subdirectory vhosting.
[6] http://lists.drupal.org/archives/drupal-devel/2005-03/msg00691.html
------------------------------------------------------------------------
Sun, 20 Mar 2005 19:00:26 +0000 : Dries
The problem mentioned in that report looks like a bug report to me. The
sim-link stuff shouldn't be necessary, or am I wrong?
------------------------------------------------------------------------
Sun, 20 Mar 2005 19:40:19 +0000 : killes at www.drop.org
Attachment: http://drupal.org/files/issues/05_cleandocs3_0.patch (2.25 KB)
Updated the patch to use hard links instead. suggestion from:
http://drupal.org/node/278#comment-30623
------------------------------------------------------------------------
Tue, 22 Mar 2005 19:19:35 +0000 : Morbus Iff
Dries - the symlink stuff is necessary when you consider a site without
clean URLs enabled. In a normal old site without rewrite,
http://www.example.com/subdir isn't going to be controlled by Drupal at
all - Apache is going to happily look for and then serve something from
that directory. The symlink is there to say "Apache, this location
exists, but we want to send you back to the Drupal installation so that
it can handle the request based on the URL".
------------------------------------------------------------------------
Tue, 22 Mar 2005 19:20:33 +0000 : Morbus Iff
Oh, and killes revision is +1.
------------------------------------------------------------------------
Wed, 23 Mar 2005 10:28:25 +0000 : killes at www.drop.org
The patch should really be applied the problem is going to be popular:
http://drupal.org/node/19305
------------------------------------------------------------------------
Wed, 23 Mar 2005 21:15:19 +0000 : Dries
Jim Riggs is looking into this as well. Let's wait a bit longer for his
feedback.
------------------------------------------------------------------------
Fri, 08 Apr 2005 19:40:33 +0000 : Morbus Iff
Any word on this one? If there's no code fix in time for next week, then
the docs should be amended with this.
------------------------------------------------------------------------
Fri, 08 Apr 2005 20:01:25 +0000 : jhriggs
Currently, as has been noted, this does not work without creating a
link. Personally, though, I strongly recommend against using hard
links. I spend all day in various Unices, and I never have need to
make a hard link. Hard links are Bad™. So if we update the
docs, I recommend that is gives instructions for symlinks. Note that
the latest patch is mix-and-match. It has one hard and one symlink
example.
I /do/ have some code that would allow one to have subdirectory-based
sites without doing a symlink, but I am not sure how comfortable I am
with it. I would like to discuss it with Dries.
------------------------------------------------------------------------
Fri, 08 Apr 2005 20:05:01 +0000 : Morbus Iff
This patch [7] contains the softlink instructions, before the hardlink
modification. It's still commitable. I'm having problems contemplating
how your (proposed, unseen) patch would work on a non-mod_rewrite site
though.
[7] http://drupal.org/files/issues/05_cleandocs3.patch
------------------------------------------------------------------------
Fri, 08 Apr 2005 20:10:26 +0000 : killes at www.drop.org
Attachment: http://drupal.org/files/issues/05_cleandocs3_0_0.patch (2.27 KB)
patch with symlinks not hard links.
------------------------------------------------------------------------
Mon, 11 Apr 2005 20:19:18 +0000 : Dries
Can't we use 'subsite' instead of 'site3'. The name 'site3' seems
pretty random and is not very descriptive IMO.
(Does everybody think this kind of information is a good thing?
Sometimes I fear that this is going to scare or confuse the heck out of
people who don't need all this 'mambo jambo'. Maybe stuff like this
belongs in an 'advanced setups' section.)
More information about the drupal-devel
mailing list