sunrise.php in single site installations

[nacin]

Let's make sunrise.php work regardless of is_multisite().

[scribu]

Why?

[nacin]

This came up after talking with MarkJaquith at WC Savannah about a few interesting use cases.

[mikeschinkel]

I'd like to reopen this because I'm finding that I need for client use and I can't really tell why it was closed; @nacin's comment on closing seems to imply there was interest in this.

The use-case: An agency wants to implement specialized functionality they would including in all implementations of sites they implement that are based on WordPress. Some of this functionality needs to be loaded earlier than the theme, and then don't want the modules to appear in the plugin repository because they don't want the admin users disabling them. This is consistent with WordPress' ​Decisions, not Options principle.

Further adding then as Must-Use plugins is problematic because the company name may appear alphabetically after one of the other must use plugins that depend on it.

Yes there are some hackish workarounds but it would be very nice if it were just elegant.

[mikeschinkel]

Implements a SINGLESITE constant referenced by is_multisite() with an optional loading of sunrise.php if it exists.

[scribu]

If one must-use plugin depends on another, just use the 'muplugins_loaded' hook to make sure it's loaded.

[mikeschinkel]

Replying to scribu:

If one must-use plugin depends on another, just use the 'muplugins_loaded' hook to make sure it's loaded.

Yes there are hacks. But why would you oppose enabling sunrise.php to work for single site?

[scribu]

You call using actions hacks?

I oppose it because I don't see the use for it. Maybe nacin can describe those interesting use cases he mentioned.

[mikeschinkel]

Replying to scribu:

You call using actions hacks?

Please don't put words in my mouth. Read on...

Replying to scribu:

If one must-use plugin depends on another, just use the 'muplugins_loaded' hook to make sure it's loaded.

You can't enable the 'all' filter to process the 'muplugins_loaded' hook from within the 'muplugins_loaded' hook, nor modify any of the global variables $wp_filter, $wp_actions, $merged_filters, $wp_current_filter prior to the 'muplugins_loaded' hook in that manner.

The 'muplugins_loaded' hook comes after wp_not_installed() and wp_plugin_directory_constants() are called so you cannot modify global variables that would affect their behavior. And the 'muplugins_loaded' hook also comes after each of the must-use plugins are loaded in alphabetic order by file name. So if you need to be able to be sure to run something before one of the must-use plugins is loaded you cannot.

Those reasons above I why I called it a hack.

I oppose it because I don't see the use for it.

Maybe I'm missing something. Is there a reason it makes sense that sunrise.php should be able to be loaded for multisite but not for single site? I don't mean a use-case that multisite has that single site does not, but a reason why single site should be disallowed the use of an equivalent sunrise.php?

Also, how harmful an addition would this be in your eyes? It's not like it adds anything visible into the admin console and doesn't do anything except for very selected circumstances. Unless I made a logic error, my patch stays completely out of the way unless a sunrise.php is in the /wp-content/ directory, and my patch demurs to the existing code to load sunrise.php if MULTISITE has been defined in /wp-config.php.

[scribu]

Of course I put words in your mouth if you don't paint the whole picture. :)

Yes, all those things you mention in your last comment are valid use cases.

Moving on to singlesite.diff​:

I don't think checking SINGLESITE inside is_multisite() is the best approach.

[scribu]

Actually, a SINGLESITE constant shouldn't be necessary at all.

It's either MULTISITE or it's not. There's nothing in-between.

[westi]

SINGLESITE as a constant isn't needed you can just ! MULTISITE.

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.

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

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.

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

[mikeschinkel]

Replying to scribu:

I don't think checking SINGLESITE inside is_multisite() is the best approach.

Replying to 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 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.

[mikeschinkel]

Enabled loading of /wp-content/sunrise.php when !defined('MULTISITE') and when MULTISITE==false.

[dtbaker]

I was trying to get sunrise.php working on a singlesite install, so that I could modify WP_CONTENT_URL so that the same wordpress blog would work on different URL's. This is so I can visit the wordpress blog on the normal URL along (example.com) with the shared hosting SSL url (ssl.hostingexample.com/~example/)

I couldn't get sunrise.php working so I had to modify index.php to get it working:

​http://dtbaker.com.au/random-bits/how-to-make-a-single-wordpress-install-work-on-multiple-urls-.html

[nacin]

Just use wp-config.php rather than modifying index.php.

I know I created the ticket originally, but I don't see the purpose of sunrise.php for multisite. I chatted about it with MarkJaquith (in 2009 sometime) but quickly realized there were better alternatives, either going into wp-config.php or waiting later until a mu-plugin.