Interferes with other plugins which use login and key GET parameters

Sorry for the slightly more technical question, I wasn’t able to find a github repo.

I’m finding that this plugin is causing conflicts with any other plugins that depend on a login and key GET parameter: it automatically redirects any requests on a page that includes both of those parameters to the password reset page, regardless of whether the given page has anything to do with UR or not.

Here’s my understanding of the issue:

The problem seems to be coming from the ur_get_page_id() function, which will always return the CURRENT page’s ID rather than the ID of the page which corresponds to the string passed to in:

user-registration/includes/functions-ur-page.php

function ur_get_page_id( $page ) {

  $page = apply_filters( 'user_registration_get_' . $page . '_page_id', get_option( 'user_registration_' . $page . '_page_id' ) );

  $page = get_the_ID();

  return $page ? absint( $page ) : - 1;
}

By commenting out the line $page = get_the_ID(); everything functions as I would expect, and all plugin conflicts are seemingly resolved.

The effect of this is that is_ur_account_page() function always returns true since is_page( ur_get_page_id( 'myaccount' ) ) will always return true. (Essentially: is_page(get_the_ID())).

user-registration/includes/functions-ur-core.php

function is_ur_account_page() {
  return is_page( ur_get_page_id( 'myaccount' ) ) || ur_post_content_has_shortcode( 'user_registration_my_account' ) || apply_filters( 'user_registration_is_account_page', false );
}

This probably has affects throughout the entire plugin, since any time it checks whether the site is currently on a given UR page, the answer is always “YES!”. In the redirect_reset_password_link method, we can see why any page that has the key and login parameters is redirected.

/user-registration/includes/class-ur-form-handler.php

public static function redirect_reset_password_link() {
  if ( is_ur_account_page() && ! empty( $_GET['key'] ) && ! empty( $_GET['login'] ) ) {
    // redirect
  }
}

Is there any hope that this could be patched soon?

There might be some intentional reason that ur_get_page_id() always returns the current page id, and there might be some effects that I’m not seeing to changing this. In that case, maybe we can figure out a way that the plugin doesn’t simply rely on those 2 GET parameters?

Please let me know if there’s anything I can do to help, and also when the plugin will be patched!

Thanks so much!

Chris Borchert