Opened 14 months ago
Last modified 7 months ago
#20220 new enhancement
add test to see if sunrise === on in ms-settings
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Multisite | Version: | 3.0 |
| Severity: | normal | Keywords: | has-patch commit 3.5-early |
| Cc: | sboisvert |
Description
We needed to disable sunrise for certain requests.
We thought about declaring sunrise before including wp-load, but setting it to 'off'. Then having a conditial in the wp-config that only defines it to on if it is not defined and then in ms-settings to a additional check to see if sunrise is defined and equal to on. (the patch I am adding does not have the wp-config if !defined() as wp-config doesn't get updated, but if someone feels it is helpful I can add it)
Others could of changed the default defined value of sunrise and this could break bc. I am therefore not sure if the limited use case warrants it. But I thought I would suggest it.
Attachments (2)
Change History (10)
That's quite possible.
It's to disable domain mapping and url rewriting for auto resized image downloads so that all thumbnails go thru the main site.
comment:3
johnbillion — 12 months ago
- Keywords needs-patch added; has-patch removed
- Severity changed from trivial to normal
- Version set to 3.0
The attached patch would break a site of mine which uses define('SUNRISE',true). We should patch it in the same manner as #20636.
johnbillion — 12 months ago
comment:4
johnbillion — 12 months ago
- Keywords has-patch added; needs-patch removed
Patch updated so any non-empty value for SUNRISE is accepted.
comment:5
SergeyBiryukov — 12 months ago
- Keywords commit 3.5-early added
- Milestone changed from Awaiting Review to Future Release
The 'SUNRISE' constant is one of those constants that, as long as it is defined in any way, triggers is_multisite() to return true. I don't find this to be a deal-breaker as to whether we assert truthiness before deciding whether to load sunrise.php, but it's nice to be consistent and at least understand what is going on.
The good thing is, SUNRISE never got the ridiculous "off" and "on" treatment given to VHOST. Setting it to "off" did not appear to have an effect in MU. So this change should be backwards compatible in a sane way, and seems sensible enough.
But I must ask, if you're going to disable sunrise for certain requests, why not just not define it?
I think what you are saying is that I should of done something like
if ( !defined('SUNRISE') && !defined('DONT_DEFINE_SUNRISE') )
define( 'SUNRISE', 'on' );
in my wp-config. I really don't have a good answer for why I didn't do that....
You can add a simple check to the beginning of sunrise.php and if some condition is met return.
Even though there is a sunrise.php included in domain mapping sunrise.php is intended to be manually maintained. There are lots of different things that you can do in sunrise.php. If you have two plugins that both use sunrise.php you have manually create your own sunrise.php that correctly incorporates the code from both plugins.

That sounds extremely convoluted. Are you sure the stuff you're trying to disable belongs in sunrise.php in the first place?