Opened 15 years ago
Closed 12 years ago
#14670 closed enhancement (worksforme)
sunrise.php in single site installations
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | General | Keywords: | dev-feedback reporter-feedback close |
Focuses: | Cc: |
Description
Let's make sunrise.php work regardless of is_multisite().
Attachments (2)
Change History (16)
#2
@
14 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
This came up after talking with MarkJaquith at WC Savannah about a few interesting use cases.
#3
@
14 years ago
- Cc mikeschinkel@… added
- Keywords has-patch dev-feedback added
- Resolution wontfix deleted
- Status changed from closed to reopened
- Type changed from defect (bug) to enhancement
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.
@
14 years ago
Implements a SINGLESITE constant referenced by is_multisite() with an optional loading of sunrise.php if it exists.
#4
follow-up:
↓ 5
@
14 years ago
If one must-use plugin depends on another, just use the 'muplugins_loaded' hook to make sure it's loaded.
#5
in reply to:
↑ 4
@
14 years ago
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?
#6
follow-up:
↓ 7
@
14 years ago
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.
#7
in reply to:
↑ 6
@
14 years ago
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
.
#8
@
14 years ago
- Milestone set to Future Release
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.
#9
follow-up:
↓ 10
@
14 years ago
Actually, a SINGLESITE constant shouldn't be necessary at all.
It's either MULTISITE or it's not. There's nothing in-between.
#10
in reply to:
↑ 9
;
follow-up:
↓ 11
@
14 years ago
- Keywords reporter-feedback added; has-patch removed
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.
#11
in reply to:
↑ 10
@
14 years ago
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 inwp-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
called000-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.
@
14 years ago
Enabled loading of /wp-content/sunrise.php when !defined('MULTISITE') and when MULTISITE==false.
#12
@
13 years ago
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:
#13
@
13 years ago
- Keywords close added
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.
Why?