Pantheon Community

Maintenance page during Clone Database to the Live Environment

We are using a terminus script to make a copy of the live environment to a multidev environment then running some other logic to update the database and then pushing the multidev environment’s database back to live.

However, this is problematic because there is a short window of time when we see the WordPress install page that is displayed when WordPress senses it does not have a configured database. What we need is for a way to have Pantheon switch to a maintenance page while the clone is in process.

Or is it somehow possible to manage this ourselves without having to commit code twice on each database update?

1 Like

@mikeschinkel That’s really not the way the platform is intended to be used – it violates the basic “code moves up, content moves down” principle that underlies the “Pantheon workflow” outlined here:

I don’t work with WordPress, more exclusively with Drupal, and in Drupal-landia, the approach to what you’re describing is to make database updates via code that fires upon deployment to the LIVE environment. In Drupal, this is accomplished via what are called “update hooks,” not sure if there is an equivalent in WordPress.

1 Like

@gravelpot — I hear you. But the updates take longer than can be handled via a 90 second HTTP request timeout. So we need to do via a Terminus/WP CLI script.

Now we wrote our script to operate directly on the live environment, but we ran into a chicken-vs-egg problem. If we make changes to the schema of the data we are importing then we can’t import without first updating our code. But if we update our code before we import the changed schema then the production site will be broken until the WP-CLI command completes, which could be several minutes or longer.

So while yes I agree that in theory that is how the platform should work, there are facts on the ground that make it impractical for 100% of use-cases. And so we need a maintenance screen while the database is being updated, but we can’t use hooks prior to that point.

1 Like

Hey, @mikeschinkel! Welcome to the community forum. :slight_smile:

+1 to @gravelpot’s point about the general workflow. We generally recommend against cloning into the Live environment because of the kind of thing you’re seeing (and it’s just risky to overwrite the canonical DB).

That said, I had a few ideas:

You could try to add a couple lines to the script using WP-CLI to activate and then deactivate maintenance mode, e.g.:

terminus wp -- maintenance-mode activate
[copy your db to live]
terminus wp -- maintenance-mode deactivate

I’m not sure if WP will be able to run maintenance mode during the time when there isn’t a database at all, though.

Second idea: I don’t know what the logic you’re running on the Multidev is doing, but I wonder if WP-CFM would help. If you could get the DB configuration into code, you could deploy that up without the no-db screen popping up.

1 Like

@sparklingrobots — Thanks for your reply.

As for the general workflow see my reply to @gravelpot regarding why it does not work in all use-cases.

No, WP-CFM would not help, but I appreciate the mention per chance it did. We are basically adding updates to our product database in the background.[*]

Thanks for the mention of maintenance mode. I was not aware of it, but that might be exactly the solution we need. I will try it and post the results here once I’d confirmed if it will work or not.

[*] — Some have suggested we should be using APIs for this, but we moved away from using APIs to get the product data to eliminate inconsistency across the dataset.

1 Like

What @sparklingrobots says is :100:, WordPress maintenance mode is the way to go here. When WordPress bootstraps, it first looks for a .maintenance file in the site root. If it sees this, WordPress will print either a default MM message, or the contents of wp-content/maintenance.php (so you can customize the display). [Relevant code] As long as that .maintenance file is there, WordPress won’t get to the database screen for normal page loads. Admin screens will work fine if you’re logged in and the db is working. MM also shouldn’t impact WP-CLI commands, so you should be able to perform any/all operations as needed and users will get either cached content (if it’s in the edge layer) or the MM message. In theory you could create a static copy of the site and use logic in maintenance.php to serve that too :grin:


TIL how maintenance mode actually works in WordPress! Thanks @doug_pantheon!

1 Like

@doug_pantheon — Thanks for the response.

Question about the .maintenance file on Pantheon. Can we add/delete the file when in Git mode? Or do we have do switch to SFTP mode? I assume the latter?

So I assume I would need to use:

terminus connection:set sftp

then use an SFTP client to upload the file. run the updates, use the SFTP client to delete the file, and then run this?

terminus connection:set git

@doug_pantheon @sparklingrobots — BTW, looking at core WP code it weirdly seems that you get a 10 minute window on the .maintenance file and if past that time window, WordPress just keeps loading. Even though it still runs the code in your .maintenance file.

So, all updates much take less than 10 minutes! :astonished:

sorry for the super late reply here,
you should be able to set maintenance mode with wpcli on any env:

wp maintenance-mode activate

That should work even if the site is in read-only/git mode, and should work on dev/test/live (disclaimer, I didn’t test it :slight_smile: )


@mikeschinkel If @doug_pantheon’s answer (or any of the others) worked for you, would you mind selecting that answer? It helps future visitors know where to start. <3

Happy Friday!

Sure thing. Too bad Discuss doesn’t let you specific two messages as the solution, but such is life.

Thanks – and agreed, the option to pick two would be better.