GarrukR

Hey Andrew, thanks for the reply.

Looking into this more, it appears the “Reason For Cancelling” Add On is potentially interfering with the cancel.php script. I didn’t initially think of this as being a problem/when I posted my original question, but I’ve been digging into this more, and when I deactivate this plugin/add on, the updates I made to the text on the custom cancel.php page (in the paid-memberships-pro/pages folder) actually worked. If this plugin is activated, updating the cancel.php page does not do anything.

Do you know if there is another script I should update instead when using the Reason For Cancelling add on? I haven’t looked into the gettext option as I’m not that familiar with this process. Would this approach work? Thanks

Thanks for the response! I’ve actually gotten used to logging in through the wp-login.php page, and like I mentioned that is working totally fine. It’s not really a big deal right now, but was thinking for my site if we want to expand the 2FA options for non-admins and editors, it would be useful to possibly have some type of 2FA integration in the pmpro login page. I’ll keep an eye out for any updates in the future.

After some additional research, I was able to utilize the pmpro_after_change_membership_level hook base on this code and replace the delete user code in the inner-if statement with wp_logout();. I should’ve figured this out sooner, but I’m still not particularly knowledgeable of all the WP/Pmpro hooks. In case anyone finds this in the future, this works.

Alright, working through this a little more, this is what I needed. Thanks again for the help.

Thanks for the response. I maybe wasn’t fully clear about this (my bad), but I was hoping to set the cookie specifically at/after login and not at initialization. I’m not sure if that is not recommended? But based on some other discussion I’ve seen regarding this, setting the cookie at login (using the wp_login and wp_logout is not uncommon.

However, switching init in for wp_login now seems to be doing the trick! I might have to play around with it a little more, but because users will have to navigate to another page under the domain to use the other app that the cookie need to be set for anyway, I think this may work since the cookie isn’t need immediately after login. Kind of odd that the cookie was setting but the value wasn’t being retained at login but is at initialization. Anyway, thanks for the help!