[Vladimir]

Quick fix for version 4.21.1. Open wp-content/user-role-editor-pro/includes/pro/classes/posts-edit-access.php, find save_user_restrictions() function, line #313 and replace this code:

if (isset($_POST['ure_posts_restriction_type'])) {
    $posts_restriction_type = $_POST['ure_posts_restriction_type'];
    if ($posts_restriction_type!=1 && $posts_restriction_type!=2) {  // sanitize user input
        $posts_restriction_type = 1;
    }
    update_user_meta($user_id, $this->umk_posts_restriction_type, $posts_restriction_type);
}

with this version:

if (isset($_POST['ure_posts_restriction_type'])) {
    $posts_restriction_type = $_POST['ure_posts_restriction_type'];
    if ($posts_restriction_type!=1 && $posts_restriction_type!=2) {  // sanitize user input
        $posts_restriction_type = 1;
    }
    update_user_meta($user_id, $this->umk_posts_restriction_type, $posts_restriction_type);
} else {    // 'profile_update' action was fired not from the 'user profile' page, so there is no data to update
    return;
}

[Vladimir]

I repeated a problem at my test environment emulating fake data from AD.
Code after which user loses his URE created meta data is ad-integration.php, line #2784:

if ($display_name != '') {
	wp_update_user(array('ID' => $user_id, 'display_name' => $display_name));
			}

But it is correct. It just shows the bug in my own code, where I delete metadata if there is empty value of a correspondent POST array element, like this:

if (!empty($_POST['ure_posts_list'])) {
...
} else {
  delete_user_meta($user_id, $this->umk_posts_list);
}

This code is definitely fired when user profile is updated not from the web-page but via WordPress API call. So I confirm the bug in User Role Editor Pro and will develop a fix for it.

Thanks a lot for your help in discovering this issue. Update will be available in a week.

[Vladimir]

All ‘Directory Admin’ menu items are protected by ‘administrator’ role.
‘Directory’ custom post type uses the same user capabilities as a standard WordPress post does: ‘edit_posts’, etc. So you may use built-in WordPress roles (editor is enough to publish pending directories from other contributors) as the base for your own custom role to work with ‘Directory’ one.

[Vladimir]

Data input by this add-on at the user profile are stored as the user meta data at the ‘wp_usermeta’ DB table with ‘wp_ure_’ prefix.

Is there any reason it should be cleared when the users role is updated/changed?

I don’t see such reason in general. It could be possible just in case ADI plugin fully clears user meta data during its data update process. I will look into this plugin code and let you know if I find something. I could not test it myself as I don’t have AD server available for testing.

I work currently on the ‘posts edit restrictions’ for roles. It will be available soon.

[Vladimir]

Hi Pierre,

Thanks for letting me know that you found a workaround. I had write a promised code sample if you did not.

Thanks for the suggestion about categories drop-down list at the back-end posts list. I will fix this.

[Vladimir]

All posts are available for view at the front-end by default.

There is a way to restrict posts available at the front-end for view by the logged-in user:

Content view access restriction for selected roles

It does not include ‘by author ID’ feature though. I see that such option will be useful. I will add it to the some of the future versions.

Currently, it’s possible to use some tag or category as a workaround – setup such ‘Posts View’ restriction for role, assigned to this author.

If it’s not acceptable for your client I may provide a piece of code for functions.php in order users of some role will see at the front-end just the posts for which they are authors.

[Vladimir]

Hi Pierre,

Thanks for the good feedback.

If I put author ID’s in there, will this ensure that they can only edit posts by that author ID and not all other posts?

Absolutely correct. Access to the all others posts will be blocked in this case by User Role Editor.

[Vladimir]

Hi Wayne,

I suppose that some other plugin may add its own restriction. You may try to deactivate all plugins and test, if user with ‘list_users’ may open users list.

If you still will need my help on-site, send login credentials to [email protected]

[Vladimir]

Show me the screenshot of such role. Does it have access to the ‘manage_options’ capability.

I tested with standard ‘editor’ role and user does not see ‘Settings’ menu, while ‘Sharing’ under it is protected by ‘published_posts’ only.

[Vladimir]

I don’t see other quick solution. I doubt that similar problem is wide enough to take this specific configuration into account for starting URE’s global code refactoring.
Moreover, it could be resolved by changing WordPress settings.

Removing extra redirection for every page request for the live site is a quite better choice for its health/speed/SEO. It may cost to spend some time to resolve a possible problem with data preparing for the dev/stage copies in order to get such enhancement.

[Vladimir]

After you mapped subsite to the different domain, you need to replace its “Site URL” with that domain in order to exclude extra redirections made by WordPress. Go to the ‘Network admin->Sites’, select the site and click ‘Edit’ under its row to get needed form.

I did that for https://yourgigguide.com/ site and URE started working as expected for that site. Please test.

[Vladimir]

I’ve setup test instance of WordPress multisite with domain mapping locally. But it did not repeat this issue. URE works as expected from any domain (primary or mapped) in URL.

Send superadmin login credentials to [email protected]
I will look on the site settings, make some tests on-line.

I suppose that moving the part of parameters responsible for the presentation, from the POST to GET (adding to URL) may resolve the issue. It depends if redirect takes place after POST data was really processed by plugin code. And it will not help if redirection occurs before POST data processing by URE plugin.

It’s not a quick fix and will require some time to refactor the code any way.

[Vladimir]

Thanks for the information. It’s the bug, which fill be fixed with 4.21.1.
I plan to publish 4.21.1 today.

[Vladimir]

Hi,

I did not make full tests of the latest URE version against older WordPress versions.
But quick look shows that version 4.21 works in general with WP 3.9.9. In order to remove required WP version warning, open the file user-role-editor-pro.php, go to the line #48 and replace 4.0 there to 3.9.9, in order to get this:

$ure_required_wp_version = '3.9.9';

I raised required WP version to 4.0 starting from URE version 4.19. If you need it, I may send it to your email.

[Vladimir]

Thanks for the additional information.
1st, I will try to setup multisite with domain mapping locally 1st and try to catch a reason.

Then I will contact you with results and may be ask you about the on-line access if needed.

[Author]

Posts