Joachim Jensen

Hi,

The automator should handle membership extensions out of the box, i.e. if it’s triggered for a user that is already a member (whether active or expired), their membership will be extended/renewed by the set level duration.

Would it be possible to share some more details about how you test purchases in WooCommerce? Then I will see if I can reproduce the problem.

Hi,

Would something like this work for you?

rua_get_level($level_id)->get_title()

If you are looking for the actual name/slug, and not the title, that is not currently possible via the RUA API, but I can see how that could be useful.

Since Access Levels are stored as custom post types, you could do this for now:

get_post($level_id)->post_name

Apologies for the delayed response here. I was able to reproduce the problem you are experiencing, and I will include a fix for it in the next version.

In the meantime, adding this to your theme’s functions.php should stop redirecting users to the admin area if they don’t have access to it:

add_filter( 'login_redirect', function($redirect_to, $requested_redirect_to, $user ) {
    $intercept = empty($redirect_to) || mb_strpos($redirect_to, 'wp-admin') !== false;
    if(!$intercept) {
        return $redirect_to;
    }
    
    if(!function_exists('rua_get_user')) {
        return $redirect_to;
    }

    $rua_user = rua_get_user($user);
    if ($rua_user->has_global_access()) {
        return $redirect_to;
    }

    $user_levels = $rua_user->get_level_ids();
    if (empty($user_levels)) {
        return $redirect_to;
    }

    $metadata = RUA_App::instance()->level_manager->metadata()->get('admin_access');
    foreach ($user_levels as $level_id) {
        if ($metadata->get_data($level_id, true)) {
            return $redirect_to;
        }
    }

    return home_url();
}, 10, 3);

Thank you for reporting this.

Are you using any other plugins to manage memberships, restrict access, or redirect logins?

Specifically, can you provide some more details about how you are doing this:

we’ve hidden the WordPress dashboard from members.

E.g. are you using the “Deny Access to Admin Area” option for one or more of your Access Levels?

Hi,

Thank you for reporting this. My first guess would have been that there is a mismatch between content IDs on stage and production sites, which could “unlink” the selected Display Conditions, despite the sidebar still being active and containing widgets. But since you say the sidebar shows up in Quick Select for a given page, that may not be the issue.

Would it be possible to reach out via https://dev.institute/contact/? You can just pick the “Pre-sale Questions” topic.

I am glad to hear you got the first issue resolved!

As soon as a redirection was set, impossible to unset it with no redirection. Recreating them from zero gave this option unset, with problem gone.

What is the expected behavior for users without access to a certain page, e.g. do you want them to be redirected back to the front page, or should they see a certain message on the same page?

And when I go on this page, I can see in the admin bar that the access is indeed only for this 3rd level (2nd and 3rd levels are extesion of the 1st level).

When one level extends another, it will inherit all the Access Conditions and Capabilities from that level, so this is expected behavior, though I will see if I can make that more clear in the admin bar.

Can you try to unset the Extend Level option and see if that makes your access conditions work as expected?

You can read more about hierarchal levels here: https://dev.institute/docs/restrict-user-access/getting-started/extend-level/

Thank you for reporting this. Are you still experiencing this problem? If so, are you using a Trigger or Trait automation?

You can read more about triggers and traits here: https://dev.institute/docs/restrict-user-access/getting-started/add-level-members/

Thank you for reporting this.

Would it be possible to provide screenshots of the Access Conditions and Options tabs for your levels? You can use imgur.com

Thank you for reporting this.

Are you still experiencing this problem? If so, are you using a plugin to create/manage roles and capabilities?

The “Content Aware” menu item should only be visible for users with the edit_theme_optionscapability.

The “Sidebars – Quick Select” metabox will be visible for anyone that can edit posts/pages, ie. it is intentional that they should be able to select an already created sidebar/widget area to be displayed for their content. Only users with edit_theme_optionscapability can create new sidebars from here.

If you want to hide the metabox for users without a certain capability, you can add a filter like this:

add_filter('cas/module/quick_select', function($enable, $post_type) {
    return current_user_can('edit_theme_options');
}, 10, 2);

Are you using a plugin to clean database tables, a raw SQL query, or something else?

Created sidebars are stored in the posts table with post_type=sidebar and post_type=condition_group. Widgets are stored in the options table under option_name=sidebars_widgets (default for all WordPress sidebar widgets)

Hi,

Specifically for the TwentySeventeen theme, you can install this plugin alongside Content Aware Sidebars: https://www.ads-software.com/plugins/page-sidebar-for-twentyseventeen/

Then, follow this guide: https://dev.institute/blog/twenty-seventeen-page-sidebars/

That should remove empty space and make the layout full-width when sidebars are empty.

I hope this helps!

Hi,

The sidebars and widget areas you create with Content Aware Sidebars will automatically inherit the design of the sidebars/areas they replace.

In the Design tab, you can change the HTML markup and CSS classes that should be used by the new sidebars instead. While it’s not necessary to be a developer to use this feature, you are right that it does require some knowledge of HTML and CSS.

I hope this helps!

Hi,

I am happy to hear you find the plugin useful. Unfortunately, Restrict User Access does currently not support restricting deep links to files, only attachment urls.

You should be able to use the Languages condition in combination with any other condition. This way you can e.g. keep the home page open in one language and restricted in another.

You can read more about the Language condition here: https://dev.institute/docs/restrict-user-access/conditions/languages/

There is currently no functionality like that in Restrict User Access, but you could try to take a look at this plugin: https://www.ads-software.com/plugins/press-permit-core/