Joachim Jensen

That is currently not possible no.

It is an interesting idea though, would you mind telling a bit more about your use case?

Are you by any chance using an administrator user to test the shortcodes?

Administrators will always have access to all content by default. This can be changed with a wp filter, but is done to prevent lockout and cases where other users potentially could hide content from admins.

You can use a plugin like https://www.ads-software.com/plugins/user-switching/ to easily test how the site looks for different users.

Let me know if that isn’t the issue

I will try to reproduce this with the PHP API, and yes you can reach out on the wp.org slack as well.

Thank you for reporting this and for the details.

Edit:

After being able to reproduce this problem at first, I realized that the level name I used in the shortcode was wrong.

Can you double check that you are using the level name exactly as it’s displayed in the Access Levels overview? And e.g. not the title, no whitespace, no uppercase letters etc.

• This reply was modified 10 months, 2 weeks ago by Joachim Jensen.

Thank you for reporting this.

Are you referring to the PHP API, or adding levels via an automator?

If using the PHP API, would it be possible to show a snippet/example of your code?

Thank you for reporting this.

I can confirm that the BP profile sections aren’t being displayed properly in the admin for BP 12.0+, and that using BP Classic plugin resolves it.

This will be fixed in the next version of RUA.

In version 2.5, user level data storage was moved to a custom comment type (wp_comments, type=rua_member) and all existing data was migrated.

To get the status of a membership level, you should look at the “wp_comments.comment_approved” column.

I am interested to know more about your desktop app, are you using PHP for it? In that case, you can use the RUA PHP API: https://dev.institute/docs/restrict-user-access/developer-api/

Thank you for the responses. I have a working fix for both WPML and Polylang and it will be released soon.

Thank you for reporting this.

Just to be clear: everything now works as expected in the latest version of RUA, or did you have to rollback to a previous version?

Are you using any other plugins to manage access control, custom roles, etc?

Thank you for reporting this.

To restrict access to the front/home page, you should use the Special Pages condition. You can read more here: https://dev.institute/docs/restrict-user-access/conditions/static-pages/

For the 2nd issue, would it be possible to provide a list of plugins installed on your site?

Thank you for reporting this.

Do you use Polylang, WPML or another multilingual plugin? If not, can you list the plugins you use?

In version 2.5, user level data storage was moved to a custom comment type (wp_comments, type=rua_member) and all existing data was migrated. In a future version, the old data will be deleted.

Thank you for all the details, this is very helpful.

I have found a conflict with WPML and Polylang in the latest version, can everyone in this thread confirm that you are using either of these plugins, or another multilingual plugin?

Thank you for all the details, this is very helpful.

I have found a conflict with WPML and Polylang in the latest version, can everyone in this thread confirm that you are using either of these plugins, or another multilingual plugin?

@maplearmor

Thank you for the details.

Did memberships expire unexpectedly during the upgrade, and after rolling back they remain expired? What does the Expiration column say (e.g. future or past date)?

for example Language filtering for AJAX operations is unchecked in languages section and Access Levels (restriction) is checked not translateble in settings section

Can you elaborate on what you mean by this, e.g. with a screenshot of what you are seeing?