Add ability to disable a single site

[codyjames]

Description

It would be great if we could disable a single site in the CP. There are many reasons you may want to do this but the main one is that when you are first translating a site, you probably don't want that in-progress site to be visible on the front-end.

Having this be core functionality would allow plugin authors to check if a site is enabled. For example, SEOmatic may want check if a site is enabled before adding metadata about that site or adding it to the sitemap.

Additional info

• Craft version: 3.0.11

[khalwat]

This would be great to see imo

[brandonkelly]

If a site is disabled, I think it would also become hidden throughout the Control Panel, which probably isn’t what you’d want?

If you don’t want people to access a site on the front end, then just disable its “This site has its own base URL” setting. Then the only way you could access its content on the front-end is if the CRAFT_SITE constant is explicitly telling Craft to load content from that site.

[codyjames]

@brandonkelly Why would it need to be hidden throughout the Control Panel?

Removing the base URL for a site would make it really hard to work on, test, etc.

[brandonkelly]

I guess on second thought it could be shown only in the Control Panel if disabled, with a red status indicator.

[brandonkelly]

Having this be core functionality would allow plugin authors to check if a site is enabled. For example, SEOmatic may want check if a site is enabled before adding metadata about that site or adding it to the sitemap.

@khalwat Couldn’t you just look at the hasUrls property on the site?

[khalwat]

I do that already, yes @brandonkelly

[brandonkelly]

So what exactly would the ability to disable a site do, that disabling URLs doesn’t already do?

[codyjames]

@brandonkelly The goal is able to have sites that can be worked on before they are ready to go live. So if you are working on a new Spanish version of your site, you need to be able to look at the pages, share them (internally), etc.

[timbertens]

I have a specific use case that relates to this discussion. We are building websites for the franchise network of a large insurance company in Belgium. The specific thing about this solution is that all sites will share the same design and codebase and would be deployed multiple times for the individual sites and their own license while keeping the codebase in 1 repository.

The additions to version 3.1 are a true godsend, it allows us to be very efficient !

The only thing we are struggling with at this moment is the site configurations, as this is Belgium (everything is difficult here) we need to deal with

1. Sites that are in Dutch only
2. Sites that are in French only
3. Sites that are in Dutch and French, with dutch as default
4. Sites that are in French and Dutch, with french as default
5. Sites that are in Dutch, French and English, with dutch as default
6. etcetera …

The idea is that we define a project.yaml with 3 sites / language and then define in config files what sites (languages) are enabled or disabled and what the default would be (just like we do for the hostnames, mailaddresses and so forth), since we want to stick to one codebase (and thus one project.yaml file).

[brandonkelly]

@timbertens This wouldn’t solve that completely, since your builds will have different primary sites. And I think the idea here is that Craft will still generally be storing content across all sites per section rules, etc., in anticipation of the sites becoming enabled down the road. It would be annoying to have to wait around for Craft to store content in sites it’s never going to need.

[timbertens]

@brandonkelly just an update on this from my side: in this solution we have to live with the fact that it causes a small delay for storing content in languages that will never be needed. It is faster it that doesn't happen of course, but the performance is still okay (and more important, the codebase and settings are kept the same for all installations)

While looking for a solution, we've came up with this addition in the web/index.php file

if (getenv('OVERRIDED_DEFAULT_SITE')!='') {
    define('CRAFT_SITE', getenv('OVERRIDED_DEFAULT_SITE'));
}

As you can see the OVERRIDED_DEFAULT_SITE is set in the .env site for the particular installation.
This solves use case 2 (in my comment from above) and would solve any situation where there is a language to be set as default that is not configured as primary site in Craft. This won't work for sites that require to be multilingual with a default that is not the primary site though, but only for single language sites ...

I believe a small addition could solve the other use cases too (4 and 5 from the above comment). If there would be a PHP CONSTANT named eg 'PRIMARY_CRAFT_SITE' that sets the primary Craft site in case Craft cannot determine what site to show (so that logic remains)

[michtio]

@brandonkelly I don't know how the project management of Craft CMS is going or being handled, but are these "3.2" features still in active development and will they be added?

[brandonkelly]

@michtio Clearly they didn’t make the cut for 3.2 :) Still want to get to things on the 3.2 and 3.3 milestones, but we will need to reevaluate when exactly they make it in.

[michtio]

@brandonkelly thanks for the reply, hopefully sooner than later! :D Maybe add the things that didn't make it in for Craft 3.5? ;p

[ryanmwc]

Any chance this is coming sooner than later? A company I started working for will be adding several countries throughout the year, each country having at least a native language plus English as sites. It would be really nice to have one setting to keep that site off while the content editors can go in and do their thing...

[brandonkelly]

Just added this for Craft 3.5. All non-primary sites will have the option to be disabled on the front end.

This only affects front-end requests – disabled sites will continue to show up everywhere in the control panel. Live Preview requests will still work though.

[ryanmwc]

The timing of this couldn't be more amazing. Thank you so much!!!

[jsunsawyer]

@brandonkelly Would it be possible to adjust the site status Enabled on the front-end via an environmental variable or something else?

Similar to what @timbertens mentioned above, we have a project that will use the same codebase for two separate sites, each having English/French languages as sites in Craft. Each site needs to have its French language disabled until translation is complete, but these won't occur at the same time.

This status saves to the project config – affecting both sites, so it makes it difficult to manage the proper settings for each.

[brandonkelly]

@jsunsawyer We need to come up with a good UI for setting non-textual values with environment variables. In the meantime, you could do this from a module:

use craft\helpers\App;
use craft\models\Site;
use yii\base\Event;

Event::on(Site::class, Site::EVENT_INIT, function(Event $event) {
    /* @var Site $site */
    $site = $event->sender;

    switch ($site->handle) {
        case 'siteA':
            $site->enabled = (bool)App::env('SITE_A_ENABLED');
            break;
        case 'siteB':
            $site->enabled = (bool)App::env('SITE_B_ENABLED');
            break;
    }
});

[jsunsawyer]

@brandonkelly Thanks! I'll give this a shot.

[jsunsawyer]

@brandonkelly I couldn't get this to work. Any chance you could test this out on your end and verify that what you posted should be working for me?

[kobeaerts]

@jsunsawyer @brandonkelly I only got it working when I place the code snippet in the index.php in the public folder where Craft get's initiated!

[jsunsawyer]

@kobeaerts Thanks so much!

I got it working as well by placing it there.

Small note for anyone else, the Event must be placed before // Load and run Craft for this to work.

[brandonkelly]

If anyone here has any thoughts on #7996 I’d appreciate the input!

[jan-dh]

Custom 503/offline template would be very useful.

That said, we could theoretically start including disabled sites when comparing the requested URL to sites’ base URLs, and if there’s an exact match but the site turns out to be disabled, respond with a 404 or 503 status.

Really like this approach. Think I would prefer the 503 option or maybe let the user choose the status when disabling the specific site for maximum flexibility.

[brandonkelly]

The concern I have with 503 is that it would provide some insight into the fact that there is an actual site there – where currently there’s none. If we go with the latter option (404s for all non-exact-matches) then we are continuing to ignore disabled sites, so the client has no way of knowing via the 404 response whether they’ve hit a disabled site, or just not one of the configured sites.

[jan-dh]

Both options can be valid for a given situation. Giving the developer the option to choose from the 404 or 503 and handle the template accordingly seems like the most flexible option.

[mmikkel]

I don't have a strong opinion as to which HTTP response code would be the better option, but I think it would be a good idea to be clearer about which behaviour the "Enabled on the front-end?" setting is supposed to mimic or resemble – is it supposed to be a per-site isSystemLive, or is it supposed to work more like disabling an element?

[brandonkelly]

Just added support for setting sites’ enabled status based on an environment variable, for the next Craft 4 Beta release 🎉

[bzin]

Nice @brandonkelly!!

Another question on this, is it also possible to set an option to not render the Site in the Control Panel? Currently this feature you created allows us to disable the site via an env, but if we do not want to show this Site entirely on a server (even if user is admin). My use case is that apart of sharing the codebase, there can be different Craft instances where certain features / sites should not be enabled and visible (and I do not wish to remove these from project config on different instances).

See it as a white label app with all its logic that uses Craft CMS.

[brandonkelly]

@bzin You can keep non-admins from seeing them by not assigning the sites’ permissions, but there’s no way to hide them for admins. Wouldn’t make any sense from Craft’s perspective – at that point there would be no way in the UI to get the site back.

[brandonkelly]

Craft 4.0.0-RC1 is out with the ability to set site statuses with environment variables.