Closed blairwigleyactu closed 2 weeks ago
Ok weird: adding --expires=0
to the command made it work. Very odd. 🤷♀️
Using --expires=0
will create a login link that will not expire. Glad you got it to work though! I'm not sure why it wouldn't work for you but happy to try to help debug it.
Do you have anything in your script that manipulates transients by chance? You might try inspecting what you have in there after creating one to see what the expiration looks like (without the added flag that is):
wp transient list --search="wp_cli_login*"
I had this problem, and it was because of a fancy clipboard manager app I use... when I copied the link out of the terminal for testing, this app was visiting the URL to scrape some data and therefore invalidating it.
And --expires=0
doesn't do anything in this case, for obvious reasons.
So watch out for anything that might be visiting or pre-fetching the link!
Thanks for sharing your experience @careybaird !
watch out for anything that might be visiting or pre-fetching the link!
This is a known issue, see https://github.com/aaemnnosttv/wp-cli-login-command/issues/1 😉
Closing as an old issue. Feel free to reopen if the cause is found 👍
So I've got a bunch of commands that are run via ssh/paramiko on some WP Engine sites.
If I run:
cd ~/sites/mysite/; wp login create myuser@user.com --url-only --redirect-url=/wp-admin/admin.php?page=theme-base-theme-settings
directly from ssh it'll generate a usable url, but for some reasons when I run the command via my paramiko script it'll generate a url that displaysThe attempted magic login has expired or already been used.
- the commands are exactly the same. There's a bunch of vanilla and custom wp cli commands that run fine via paramiko so it's not a universal issue.Really weird, I assume it's some quirk with how paramiko works, but just wondering if you have any idea what could be happening?