Forum Replies Created

Viewing 15 posts - 1,456 through 1,470 (of 2,529 total)
  • Author
    Posts
  • in reply to: Posts Edit Access #4096
    Vladimir
    Keymaster

    It could be a caching issue. WordPress may show older data 1-2 times after you add edit restrictions to a user or role, especially when you test it (before and after changing available posts list) at the same browser. Can you repeat this in a different browsers: login at one browser as admin, and as a test user at another browser.

    Edit access restrictions works for multiple roles assigned to the same user this way:
    URE takes an access model (Allow or Block) from the 1st role and add to it access conditions from other roles with the same access model only. For example: User has 3 roles. 1st role: Allow, 2nd role: Block, 3rd role: Allow. Access conditions will be applied from the 1st and 3rd roles only.

    in reply to: Editor Role adding access to Menu and Widgets #4094
    Vladimir
    Keymaster

    Hi,

    Send exact download link for the Redirection plugin.

    in reply to: flamingo access for role author #4091
    Vladimir
    Keymaster

    Hi Frederico,

    Flamingo requires ‘edit_users’ capability for all its features by default.

    It’ possible to change this through replacing current flamingo custom user capabilities mapping via filter ‘flamingo_map_meta_cap’. Look at flamingo/includes/capabilities.php for more details.

    Vladimir
    Keymaster

    Hi,

    Thank you for the additional details provided by email. It helped to found a reason.
    URE restricts editing of all post types, by default, including ‘attachment’ type. So if you allowed to user to edit pages with ID 2, 3, only this ID will be available for editing. But media library items attached to these pages are not edit to the list of allowed for editing IDs automatically. I will add this feature with the next update – in September, 2017.

    Currently you can exclude ‘attachment’ post type from ‘editing restrictions’ as a workaround: https://www.role-editor.com/documentation/hooks/ure_restrict_edit_post_type/

    in reply to: Shortcodes not working after update #4087
    Vladimir
    Keymaster

    Thanks for sharing your opinion. You are not alone. I will add a custom filter to the next version in order it will be possible to change this default logic and process the shortcode for administrator the same way as for any other user.

    in reply to: Shortcodes not working after update #4085
    Vladimir
    Keymaster

    Hi Brad,

    Did you test shortcode under regular users or as admin?
    Take into account that shortcode does not work for user with ‘administrator’ role. There is no restrictions for administrator. I do not process [user_role_editor] shortcode for administrator for this reason.

    in reply to: Prohibit hides all posts, disregards IDs #4080
    Vladimir
    Keymaster

    I already tried adding the tax. term only, which hid all the categories and tags in WP post edit screen.

    It seems I need to enhance URE’s logic at this point. I will research what it’s possible to do. Thank you.

    in reply to: Prohibit hides all posts, disregards IDs #4079
    Vladimir
    Keymaster

    Excellent, that you can resolve the issue.

    Child pages are included/excluded by default. You can change this using this filter:

    ure_auto_access_child_pages

    in reply to: Prohibit hides all posts, disregards IDs #4073
    Vladimir
    Keymaster

    I found a reason. Your assumption about string length limit was near to true. But this limit was set by your hosting WP Engine (WPE). It has an automatically executed code at ‘mu-plugins’ folder which restricts SQL query text length to 16384 characters.
    wp-content/mu-plugins/wp-engine-common/plugin.php, line #2518:

    
    if ( $query_length > self::QUERY_LENGTH_MAX ) {
      return '';
    }
    

    SQL query you get for full list of categories grows up to 16543 characters long. WPE just prevents its execution writing to the system log:
    “KILLED QUERY (16543 characters long generated: SELECT …”
    It’s a pity, that they do this silently, without raising exception. So you and me should waste a time searching what’s going wrong.

    What workaround is possible:
    1) define WPE_GOVERNOR PHP constant with FALSE value, add this line to wp-config.php file:

    
    define('WPE_GOVERNOR', false);
    

    It should force WPE to ignore SQL query length.
    Be aware, that it could not work if this PHP constant is defined already by WPE themselves. So just try it.

    2) You have 3027 posts, plus some pages and events. When you restrict role by defining categories in which you prohibit to edit posts, there are 3228 post ID in the list, which are prohibited. If define categories in which you allow to edit posts, then this list will be much shorter: 68 items only.
    I include comma separated list of post ID into the SELECT SQL query. That’s why this command could become longer then a limit set by WPE.

    in reply to: Prohibit hides all posts, disregards IDs #4072
    Vladimir
    Keymaster

    Strange. There is no a limit on the number of characters in ID lists.

    I will make another test with your data copy. Just in case I deactivated some conflicting plugin.

    in reply to: Problem with Content aware sidebars? #4064
    Vladimir
    Keymaster

    Hi,

    It’s the 1st request about “Content Aware Sidebars” (CAS) plugin. Give me more details (screenshots are appreciated) about what URE Pro settings are not worked with CAS plugin together. How do you use CAS? Did you using CAS place some widget inside a post with content view restriction and that widget was shown for all in spite of that restriction?. Show screenshots of post content from editor page and front-end and view restriction set for it.

    How it’s related to menu?

    in reply to: Prohibit hides all posts, disregards IDs #4061
    Vladimir
    Keymaster

    Hi,

    I can not repeat an issue on a provided data copy. All 3 users with ecd_curator role see posts (All – 68, Publshed – 66).

    I suppose that it could be some caching problem. Try to add 103 taxonomy back to the prohibited list and make another test.

    in reply to: Prohibit hides all posts, disregards IDs #4058
    Vladimir
    Keymaster

    Hi,

    Is it possible to to get a copy of your site files (without wp-content/uploads) and database to analyse this issue at my local development environment? If Yes, send download link (DropBox or similar) to suport [at-sign] role-editor.com

    in reply to: Rename a role does not cascade to subsites #4047
    Vladimir
    Keymaster

    Hi Shweta,

    ‘Apply to all sites’ checkbox takes effect for the ‘Update’ button only. This scheme will work:
    1) Rename role;
    2) Turn ON ‘Apply to all sites’ checkbox;
    3) Click update.

    Role with this ID will be renamed/created if it does not exist at all subsites of a network. Capabilities of this role will be synchronized.

    Thanks for showing me a problem. It’s useful to take a fresh look at a long time existing functionality.

    I think now that it will be better to move ‘Appy to All sites’ checkbox from a main form to the update confirmation dialog opened after click on ‘Update’ button, to not confuse users. And may be add ‘Appy to All sites’ checkbox to the dialogs opened for other buttons.

    Vladimir
    Keymaster

    Hi Andreas,

    If you have active ‘Nav Menu Roles’ plugin and wish to use front-end menu access add-on from User Role Editor Pro instead, deactivate ‘Nav Menu Roles’.
    If your theme contains some related code, make a context search at theme files for code which inherit from Walker_Nav_Menu_Edit class and look how you can disable it and do not break a theme functionality.

Viewing 15 posts - 1,456 through 1,470 (of 2,529 total)