trustedlogin / remove-dashboard-access Goto Github PK

I had come to believe that it was good practice to test if ABSPATH was defined in all the PHP files of a plugin, and I see you only test for it in the main top-level file.

I don't know if this is an issue or not, but raising this for at least consideration.

Is there a way to exclude a specific URL from being blocked by this plugin? Specifically, we use Wordfence and have its two-factor authentication options enabled. However, users are being redirected away from the Wordfence two-factor configuration page when they click the activate button within their profile page.
https://wordpress.org/support/topic/allow-specific-url/

Over the life of this plugin, several users have ended up getting locked out of the back-end of their own sites because they set a capability that their user didn't actually have.

In brainstorming how to implement some kind of fail-safe mechanism to prevent unintentional lock-out, I think the best option would be to simply do a cap check when the access setting is changed to warn the current user if they don't have the given capability. This could either be tied directly to the access setting change event or trigger it on settings save.

Maybe we should whip package from Yoast to encourage PHP upgrades. Haven't decided yet though.

This plugin is not compatible with bbPress and BuddyPress in it's current format.

Notice: bbp_setup_current_user was called incorrectly. The current user is being initialized without using $wp->init(). Please see Debugging in WordPress for more information. (This message was added in version 2.3.) in/wp-includes/functions.php on line 3547 Notice: bp_setup_current_user was called incorrectly. The current user is being initialized without using $wp->init(). Please see Debugging in WordPress for more information. (This message was added in version 1.7.) in /wp-includes/functions.php on line 3547

This is easy enough to fix. In remove-dashboard-access.php wrap everything after line 15 in a function and then add add_action( 'init', 'your_function'); and everything should work fine.

Hi there,

I was just checking in to see if we are any closer to having exception URLs be implemented into this plugin.

The plugin aggressively redirects ALL traffic from the backend, including instances from automated services such as those trying to make AJAX requests.

It looks like people have asked for a feature for a "whitelist" of URLs that you can add here, here, here, and here.

It looks like here it was mentioned that this could become a feature. Is there a status update on implementing this? It severely limits use cases where this plugin can be implemented without it.

Thanks

I am using a plugin that let's me modify the user profile from front-end. But with this plugin, the plugins doesn't work even when "Enable Profile" is true. I guess the check for profile page in the code below looks incorrect. I have suggested the change. Let me know what you think.

Current way :

function dashboard_redirect() {
		/** @global string $pagenow */
		global $pagenow;

		if ( 'profile.php' != $pagenow || ! $this->settings['enable_profile'] ) {
			wp_redirect( $this->settings['redirect_url'] );
			exit;
		}
	}

Suggested Way:

function dashboard_redirect() {
		if ( ! IS_PROFILE_PAGE || ! $this->settings['enable_profile'] ) {
			wp_redirect( $this->settings['redirect_url'] );
			exit;
		}
	}

No problem for users who have already configured their 2FA but for new users, after entering their login details, when they would be sent to the 2FA setup, they get the "too many redirects" error. Fixed by deactivating Remove Dashboard Access plugin. Any fix that keeps this plugin usable?

I'm using a modal login system. Could the redirect page give an option to stay / reload the same page the user is currently on?

Thx

Requests to be handled by Paid Memberships Pro are being redirected if Remove Dashboard Access is active at the same time.

It would be nice, if you could release the new version from the develop branch as it is much better.
The filters allow easy extending and there is no need to patch the core of the plugin everytime.

Thanks for your plugin!
Is it possible in option 'User Profile Access: Allow all users to edit their profiles in the dashboard' to limit by capability user's role too? For example, to view 'User Profile Access: Allow all users to edit their profiles in the dashboard' only editors/contributors and above could see it?

One of the biggest requests over the years has been to add true network support for multisite, that is to say, when RDA is network activated have one set of canonical settings that works across the network.

Hello,

I am not sure whether it is important issue, so Please check the message at http://prntscr.com/ikrggd

Alex

Please provide wp-cli support. It would be very useful for admins. Thanks.

It causes an extra query for each page load.

It's a migration method to move from versions 1.0.* to 1.1.*. That was added EIGHT YEARS AGO. We can remove this.

https://wordpress.org/support/topic/prevent-rarely-used-mysql-call/

The Paid Memberships Pro Membership Manager Add On (https://www.paidmembershipspro.com/add-ons/pmpro-membership-manager-role/) enables non-admins to access Paid Memberships Pro, which is great, however with the Remove Dashboard Access plugin active, access to Paid Memberships Pro is denied even though the menu is visible. These two plugins appear to be mutually exclusive; you can have one but not the other.

Is there a way to make these two plugins play nicely together?

OR

Could the Remove Dashboard Access plugin be refactored to select roles from a list rather than just having the three options (Administrators Only, Editors & Administrators, Authors, Editors, and Administrators)?

OR

Is there a way to enable certain plugins i.e. bypass the plugin? For example, Paid Memberships Pro in this case.

See https://wordpress.org/support/topic/error-the-information-youre-about-to-submit-is-not-secure/

Also, consider always redirecting to HTTPS…