arvoreen

Ok — thanks — so I think I may just disable the plugin on the backup/dev sites to make sure nothing bad happens with the production connection. It would be great if more commands became available to the ‘wp cli’

I’m sorry — part of the point of all this is to do it via command line tools only. Is there any way to do this in an automated fashion WITHOUT my having to login and go to the dashboard?

I’m sorry, that doesn’t make a lot of sense — or at least really negatively impacts any type of automation

What I am trying to do is setup an automated backup mechanism — the net result is 2 LIVE backup copies of my production site. One for ‘dev’ purposes that I only load on demand. The other is automatically loaded from the backup created the day before. To me it sounds like the only way I can accomplish what I’m looking to do is to disconnect jetpack on the restored sites and not have any access to it’s functionality when doing development or examing older backups. Is this accurate?

Sorry, missed the notification about your reply

Yes, my site is connected to the internet (it has access out) but the site itself is private to my own network (not visible to the world).

The site itself is loaded up as a copy of the production site, with URLS updated as needed (all via command line scripts)

I tried the staging flag, but was still getting warnings. Can you outline any specific steps I need to do? The process used is

restore a copy of all files
restore/load db backup
rewrite all of the URLS in the DB

If there are additional steps/changes needed please let me know

No, I expect and want to see that message. Instead, I’m getting the one about safe mode being activated.

So I just did a fresh install of TML myself, and ran into this same problem. I ended up futzing with the plugin by adding various logging statements to try to understand what was happening…and traced it down in my case to the following:

In the function ‘shortcode()’ in the main Theme_My_Login class, I need to move the following code outside of the main ‘if’ statement

if (! empty ($this->request_action ))
   $atts['default_action'] = $this->request_action;

For what ever reason, this function would be invoked twice. The first time, when $did_main_instance was not set, it would pick up the correct default action for the page. The second time, it would NOT find any default action, and create a new instance, which always displayed the login form.

I have not tracked down why the shortcode is called twice, but likely it is due to my theme (wild ass guess at this point, theme is Divi). But this small change solved the problem for me.