[wp-trac] Re: [WordPress Trac] #2866: WP can't be used from a single source installation

[WordPress Trac]

#2866: WP can't be used from a single source installation
-------------------------+--------------------------------------------------
 Reporter:  RuddO        |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:           
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:               |  
-------------------------+--------------------------------------------------
Old description:

> In summary, WordPress can't be used in a single source installation.
>
> To achieve this, I'm using a technique which involves having WP in a
> master directory, plus a "phantom" directory for each different blog -
> where wp-config.php resides, and the other WP files are symlinks to the
> master directory's contents.  I thus, for each blog, set the Apache
> DocumentRoot to the blog's phantom directory (which contains that blog's
> wp-config.php) rather than to the master directory.
>
> This would work okay, except for the fact that, on wp-blog-header.php,
> `if ( !file_exists( dirname(__FILE__) . '/wp-config.php') ) {` does not
> work, because __FILE__ points to the *real* wp-blog-header.php instead of
> to the wp-blog-header.php on the phantom directory.  Of course, this
> results in wp-config.php "not existing".
>
> Since, for all general executions of the blog engine, dirname(__FILE__)
> in wp_blog_header.php should equal the results of getcwd(), I'm changing
> this.  Attached is the patch that performs this fix on WordPress 2.0.3
> (plus nonces fixes).

New description:

 In summary, WordPress can't be used in a single source installation.

 To achieve this, I'm using a technique which involves having WP in a
 master directory, plus a "phantom" directory for each different blog -
 where wp-config.php resides, and the other WP files are symlinks to the
 master directory's contents.  I thus, for each blog, set the Apache
 DocumentRoot to the blog's phantom directory (which contains that blog's
 wp-config.php) rather than to the master directory.

 This would work okay, except for the fact that, on wp-blog-header.php, `if
 ( !file_exists( dirname(__FILE__) . '/wp-config.php') ) {` does not work,
 because __FILE__ points to the *real* wp-blog-header.php instead of to the
 wp-blog-header.php on the phantom directory.  Of course, this results in
 wp-config.php "not existing".

 Since, for all general executions of the blog engine, dirname(__FILE__) in
 wp_blog_header.php should equal the results of getcwd(), I'm changing
 this.  Attached is the patch that performs this fix on WordPress 2.0.3
 (plus nonces fixes).

 {{{All plugins that use this method are broken. BRO-KEN. By design. In
 other words, it's a really dumb idea.

 Why? Because str_replace(dirnameFILE with siteurl) can't be assumed to
 yield the right URL.

 - odd WP installation paths or Apache mappings can make the replacement
 useless - }}}

 No, any string should be replaced by any string fine. Now, please, before
 you go on telling us where this is so wrong, a use case outside of your
 single hack of trying to make WordPress-MU out of a normal install. I'd
 like to be accomodating to your attempts, but suggesting that every plugin
 is broken in a place where we have never heard anyone complain that they
 are broken in a real environment despite hundreds of thousands of testers
 for the past few years is a bit of insanity.

Comment (by masquerade):

 {{{Matt, what you just said about "other countless plugins" using the same
 technique... dude, that theory doesn't hold water. The theory that
 countless other plugins are broken (and in my personal supercharged
 3rdparty plugin mishmash, so far I haven't found any that uses this
 technique) does NOT matter ZILCH in the face of the fact that Widgets also
 needs fixing. I respect your opinion, but the "other boys do the same
 brokenness as well" argument just doesn't fly with me :-)}}}

 It should float very well, but I hate how you assume that because some
 plugin does what the WP core does with no issue on a regular blog, it is
 therefore "broken". I'm not sure where you found your definition of
 broken, but they've been working pretty darn good for us for the past few
 months.

 Your solution is twice as hackish than anything in the core right now, and
 is fundamentally broken a few ways. First plugin that does chdir() breaks
 everything. chrdir() is disabled on many servers for security reasons.

  1. First plugin or auto-prepended script to do chdir breaks everything.
  1. getcwd()'s value changes to be unusable with its context, for example
 during shutdown, where its value becomes "/"
  1. I still fail to

-- 
Ticket URL: <http://trac.wordpress.org/ticket/2866>
WordPress Trac <http://wordpress.org/>
WordPress blogging software