Site Exits from "Offline" Mode when Applying the Project Config

[josephkerkhof]

Description

While performing CMS upgrades using project config, it is often required to put the site into "offline" mode first (using the craft off command) before performing system upgrades. During upgrades, it is also common to apply changes to the CraftCMS Project Config.

In Project Config (project.yaml) there is this value:

system:                                                                                                                                                                                                                                                                                         
  live: true

Then, when running craft project-config/apply, it takes the site out of "offline" mode and turns it back on to "online" mode, possibly before the developers/operations people are ready.

Might it be possible for craft off to temporarily supercede the value in the Project Config and for the site to remain in "offline" mode until the craft on command is issued?

Steps to reproduce

1. Take any CraftCMS site setup using Project Config.
2. Run craft off.
3. Apply the Project Config: craft project-config/apply.
4. Observe the site is now back in "online" mode.

[brandonkelly]

Yeah this is a known issue – see #6729 (comment) – however we don’t have a good way of solving it yet. Will keep this open and update if we come up with something.

[MoritzLost]

@brandonkelly Mabye you could just exclude system.live from the project-config? I don't think the on/off state of the system really needs to be part of the persistent configuration, since it's almost always used temporarily for maintenance. Is there a single use-case where I want to store the system.live value as off in the project-config?

Not sure how much work this solution would be from a technical perspective, but from a user perspective this makes perfect sense.

[brandonkelly]

We aren’t just going to stop tracking something like the system live status in project config out of the blue.

[thupsi]

I can relate to both sides of the argument (tracking or not tracking the system live status in project config):

• If tracking is disabled it could maybe catch some people off-guard when the deployed app's state doesn't match the source of the deployment
• If tracking is enabled again some people are getting caught off-guard when the live site is enabled, just because it's enabled on local

Maybe make it (the tracking) optional so as to accommodate all kinds of workflows? Or, have an option to get the status from an env variable?

EDIT: Somewhat relevant discussion about setting lightswitch values in .env
EDIT 2: Hmm, maybe the "env" suggestion would not be helpful in the OP's case if it was the only option. So the ideal situation would be to have two independent options: "on/off/from-env" AND "tracked in project config?" Of course, it is entirely possible I'm overcomplicating things :)

[bencresty]

+1 for leaving this setting out of the project.yaml

Every time we deploy a website to staging or a new production env to test the cms or background tasks via a command controller the site gets unintentially, unwanted (and most of the time even un-knowingly!!) on-line for the world to see, while it was specifically set offline on that hosting for a reason.

[thupsi]

@bencresty As a temporary workaround, maybe you could have system.live set to off on your local dev server and enable the setting Access the site when the system is off for users on that server. I know.. it sounds weird.

[bencresty]

@thupsi thanks for thinking along. Yeah I know and I did that before but it's obviously not a solution to the problem as that would also go to the production server when deployed to prod. I've changed the flow now by leaving it online and added an IP block to all except allowed IP's on the staging server in the .htaccess though

[thupsi]

@bencresty Sure, there are so many different workflows. That's why I think it would be best to have the option to choose what is best for each specific case. Also, have you considered the Knock-Knock plugin? Of course, that's if you are not opposed to installing more plugins than strictly necessary.

[nickdunn]

Could this be solved by setting live = false as an environment variable? I currently set the site name this way, but it doesn't seem to work for the live setting.

system:
  edition: pro
  live: $SITE_LIVE
  name: $SITE_NAME

Edit: I'm using this in my general.php file now which works, so I can switch the site into maintenance mode with an env var before I do a deploy, and switch it back on when I'm happy the deploy has completed:

'isSystemLive' => (getenv('SITE_LIVE') === '1'),

[MoritzLost]

@nickdunn Interesting workaround! But how would you go about changing the environment variable only during deployments? Changing the environment the deployment scripts run in won't have any effect on PHP-FPM … or are you doing that manually? We're using Laravel Forge to deploy automatically whenever a PR is merged into the main branch, so any manual solution won't work, at least for us.

[nickdunn]

I'm using an Azure App Service and I manually change the env var within the Azure portal, which restarts my Docker container. Our deployments are automated in a similar way so we could build this into the deployment script to update the environment variable and cycle the app container before starting the deployment. However my client's own release process forbids continuous deployment through to production, so a manual step works for us.

Does Forge have an API your deployment routine can use to update environment variables and restart apps maybe? Or clear opcache?

[MoritzLost]

I'm using an Azure App Service and I manually change the env var within the Azure portal, which restarts my Docker container. Our deployments are automated in a similar way so we could build this into the deployment script to update the environment variable and cycle the app container before starting the deployment. However my client's own release process forbids continuous deployment through to production, so a manual step works for us.

Yeah, that's understandable … a manual step is not a problem if you deploy manually (to production) anyway. Though it's still something that's easily forgotten.

Does Forge have an API your deployment routine can use to update environment variables and restart apps maybe? Or clear opcache?

Forge is a bit closer to the metal (or rather, the VPS), more of a general server management tool. The environment editor just writes to the .env in the project root directly. The deployment script is just a list of commands that get executed directly on the server. So in theory, you can do anything you want (restarting PHP-FPM to clear the OP Cache is already the last step in our deployment scripts). I guess writing to the .env file directly would be an option – though it would still leave the system offline if any command in the deployment script fails (deployments aren't atomic).

Anyway, thanks for the insight, I'm sure it would be possible to include this workaround in our build script. Though I still think the issue should be addressed in the core (since the current behaviour is unexpected and potentially site-breaking).

[nickdunn]

Agreed. Maybe this thread should be restructured to a feature request, to remove "live" status from project config?