[wp-trac] [WordPress Trac] #14670: sunrise.php in single site installations

[WordPress Trac]

#14670: sunrise.php in single site installations
--------------------------------------------+-----------------------------
 Reporter:  nacin                           |       Owner:
     Type:  enhancement                     |      Status:  reopened
 Priority:  normal                          |   Milestone:  Future Release
Component:  General                         |     Version:
 Severity:  normal                          |  Resolution:
 Keywords:  dev-feedback reporter-feedback  |
--------------------------------------------+-----------------------------

Comment (by mikeschinkel):

 Replying to [comment:8 scribu]:
 > I don't think checking SINGLESITE inside is_multisite() is the best
 approach.
 Replying to [comment:9 scribu]:
 > Actually, a SINGLESITE constant shouldn't be necessary at all.
 > It's either MULTISITE or it's not. There's nothing in-between.

 '''Good suggestions'''.  My patch was just a proposed starting point for
 discussion, no pride of authorship there.

 I've revised the patch to use `!defined('MULTSITE')` or `MULTISITE==false`
 instead of adding a SINGLESITE constant.  This 2nd patch adds a function
 called `wp_load_sunrise()` to consolidate the loading logic.

 This 2nd patch also adds a `wp_die()` for when the file `/wp-
 content/sunrise.php` does not exist which was not previously checked in
 the case of `MULTISITE==true`.

 Replying to [comment:10 westi]:
 > {{{SINGLESITE}}} as a constant isn't needed you can just {{{!
 MULTISITE}}}.

 Addressed in the 2nd patch.

 > If we really want to add support for a sunrise mu-plugin for single site
 installs then we should just do a {{{file_exists}}} check inside the
 single site branch in {{{wp-settings.php}}} around line 90.

 That's essentially what the 2nd patch does.

 > However, I don't understand what can't be done here with a mu-plugin
 that is named such that it always appears first.

 See the things listed above that come before the first mu-plugin.

 > The agency has to be in full control of these sites to be able to ensure
 the plugin is always enabled and can therefore make sure that nothing else
 is loaded before it.

 Now expand the use-case to where the agency wants to release the software
 as a freely distributed GPL licenses open-source solution which, for
 arguments sake, targets a specific vertical market. Now they are becoming
 less in control.  ''(This is actually the longer term vision for described
 use-case.)''

 > A `mu-plugin` called `000-sunrise.php` should do exactly what you want.

 But that plugin does not get loaded before `0000-sunrise.php.` :) Not
 being facetious, but merely pointing out that it's the same problem with
 setting a hook's priority to `100`; as soon as you do someone else adds a
 hook with priority `101`.  Much better to tell them to modify
 `sunrise.php` to set the order than than require them to rename files.

 Further, file names like `000-sunrise.php` look hackish and people
 shipping a product don't like their files to look hackish just as I assume
 you wouldn't want to add files named like that to WordPress core.

 Lastly even `000-sunrise.php` won't be called before `wp_not_installed()`
 or `wp_plugin_directory_constants()`, and a `000-sunrise.php` hook won't
 allow hooking the `'all'` hook for the `'mu-plugins_loaded'` hook.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14670#comment:11>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software