[drupal-devel] [task] Usability tweaks: INSTALL.txt, .htaccess, settings.php.

Tue Apr 12 15:47:01 UTC 2005

In the handbook (http://drupal.org/node/275), it says symbolic links 
instead of symlinks, which seems to make more sense.

Anisa.

killes wrote:

> Issue status update for http://drupal.org/node/18641
>
> Project:      Drupal
> Version:      cvs
> Component:    base system
> Category:     tasks
> Priority:     normal
> Assigned to:  Morbus Iff
> Reported by:  Morbus Iff
> Updated by:   killes at www.drop.org
> Status:       patch
> Attachment:   http://drupal.org/files/issues/05_cleandocs3_0_0.patch 
> (2.27 KB)
>
> patch with symlinks not hard links.
>
>
> killes at www.drop.org
>
>
>
> Previous comments:
> ------------------------------------------------------------------------
>
> March 9, 2005 - 20:54 : 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
>
>
> ------------------------------------------------------------------------
>
> March 9, 2005 - 20:54 : Morbus Iff
>
> Attachment: http://drupal.org/files/issues/patch01_.htaccess (3.36 KB)
>
>
>
>
> ------------------------------------------------------------------------
>
> March 9, 2005 - 20:55 : Morbus Iff
>
> Attachment: http://drupal.org/files/issues/patch01_INSTALL.txt.patch 
> (10.26 KB)
>
>
>
>
> ------------------------------------------------------------------------
>
> March 9, 2005 - 20:55 : Morbus Iff
>
> Attachment: http://drupal.org/files/issues/patch01_settings.php.patch 
> (6.21 KB)
>
>
>
>
> ------------------------------------------------------------------------
>
> March 9, 2005 - 21:12 : 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.
>
>
> ------------------------------------------------------------------------
>
> March 9, 2005 - 22:02 : 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.
>
>
> ------------------------------------------------------------------------
>
> March 12, 2005 - 11:51 : Dries
>
> Good stuff!  Committed to HEAD.  Thanks Morbus.
>
>
> ------------------------------------------------------------------------
>
> March 12, 2005 - 16:29 : Morbus Iff
>
> Dries - did you mean to remove the ".conf" extension from the .htaccess
> Deny?
>
>
> ------------------------------------------------------------------------
>
> March 12, 2005 - 16:30 : Morbus Iff
>
> Oh wait. Nevermind. We don't have any of those extensions anymore. My
> bad.
>
>
> ------------------------------------------------------------------------
>
> March 13, 2005 - 17:58 : 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 
>
>
>
> ------------------------------------------------------------------------
>
> March 14, 2005 - 21:07 : 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.
>
>
> ------------------------------------------------------------------------
>
> March 14, 2005 - 21:08 : Morbus Iff
>
> Comment #10 is mine.
>
>
> ------------------------------------------------------------------------
>
> March 14, 2005 - 21:24 : TDobes
>
> Looks good to me.  +1
>
>
> ------------------------------------------------------------------------
>
> March 14, 2005 - 21:42 : 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...
>
>
> ------------------------------------------------------------------------
>
> March 14, 2005 - 21:45 : 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.
>
>
> ------------------------------------------------------------------------
>
> March 14, 2005 - 21:54 : 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
>
>
> ------------------------------------------------------------------------
>
> March 14, 2005 - 22:00 : 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. &ndash; and given
> Drupal's PHP requirements, it is not needed anymore.
>
>
> ------------------------------------------------------------------------
>
> March 14, 2005 - 22:01 : Morbus Iff
>
> Attachment: http://drupal.org/files/issues/03_cleandocs2_0.patch (3.69 
> KB)
>
> Confirmed. Updated version of patch #10 attached.
>
>
> ------------------------------------------------------------------------
>
> March 14, 2005 - 22:04 : Morbus Iff
>
> Attachment: http://drupal.org/files/issues/03_cleandocs2_1.patch (3.9 KB)
>
> This patch removes track_vars entirely.
>
>
> ------------------------------------------------------------------------
>
> March 15, 2005 - 19:40 : 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
>
>
> ------------------------------------------------------------------------
>
> March 15, 2005 - 22:08 : Dries
>
> Committed to HEAD.
>
>
> ------------------------------------------------------------------------
>
> March 17, 2005 - 15:17 : 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
>
>
> ------------------------------------------------------------------------
>
> March 20, 2005 - 20:00 : 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?
>
>
> ------------------------------------------------------------------------
>
> March 20, 2005 - 20:40 : 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
>
>
> ------------------------------------------------------------------------
>
> March 22, 2005 - 20:19 : 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".
>
>
> ------------------------------------------------------------------------
>
> March 22, 2005 - 20:20 : Morbus Iff
>
> Oh, and killes revision is +1.
>
>
> ------------------------------------------------------------------------
>
> March 23, 2005 - 11:28 : killes at www.drop.org
>
> The patch should really be applied the problem is going to be popular:
> http://drupal.org/node/19305
>
>
> ------------------------------------------------------------------------
>
> March 23, 2005 - 22:15 : Dries
>
> Jim Riggs is looking into this as well.  Let's wait a bit longer for his
> feedback.
>
>
> ------------------------------------------------------------------------
>
> April 8, 2005 - 20:40 : 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.
>
>
> ------------------------------------------------------------------------
>
> April 8, 2005 - 21:01 : 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&trade;.  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.
>
>
> ------------------------------------------------------------------------
>
> April 8, 2005 - 21:05 : 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
>
>