In theory, yes, but probably not through WP_CLI because the client app needs to set and send cookie data for simulated logins to be successful. I am not familiar with WP-CLI, maybe there is a way to handle cookie data. There shouldn’t be any reason to simulate a login, whatever code might execute during login can still be executed. Posts can be attributed to any user regardless who is logged in or if anyone is logged in at all.
Since you don’t want us to ask why you want simulated logins, we cannot suggest reasonable workarounds.
Is there anyway to execute the code that is ran during login without like breaking down the entire theme and plugins? The simulated logins are to prevent any missed functions calls as suggested by someone else in my dev team.
Still thanks for your reply though.
You can go through the core login process source and identify all the filter and action hooks that fire during the process. Then have your code apply the filters and do all the actions. In each case you’ll need to pass the same information that the core code passes. I don’t know how feasible this would be. It will serve to execute any code that plugins or themes have hooked into the process, but of course the actual core login code is not executed.
At least the core code is well defined and predictable, so one way or another you can cover what’s accomplished by core code without actually logging in. It’s the unknown theme and plugin code that’s a mystery. Firing off all the filters and actions causes this code to execute even if you do not know what that code might be.
Ideally, you know what code you need to execute during a login. Then you can just call the related functions directly without blindly going through all the filter and action hooks. This could save you from needing to gather information to pass to callbacks that is never used.
