Problems with upgrade to version 2.00

  • Resolved Abigailm

    (@abigailm)


    9 years, 4 months ago

    I experienced major problems with upgrade to Groups v.2.0.0 (I don’t know if it is a bug or a feature –but it is change in expected function that messes up my site)

    With all previous versions, if the pages within a menu item were restricted to a particular group (for example, lets assume that there is a group called “Red Group”) – then the menu item wouldn’t display until the group member had logged in.

    So let’s say there is a section of the site called “Red Group Only”, and all pages are nested under that title. No web site user who wasn’t in Red Group would see that menu item. Non-registered visitors or visitors in other group (example, Blue Group) would never see the Red Group menu item or any pages within their navigation hierarchy.

    I designed the site with a tabbed menu, entirely relying on that behavior.

    With the upgrade to 2.0.0 that behavior changed — now all menu items are displayed to everyone, but when a non-group member clicks a link, it produces a page not found error.

    That is unacceptable to me so I have rolled back to Version 1.13.1.

    Is this expected behavior with the new framework? Or is there something new I need to do with settings to get the behavior I want? (Menu Links to protected pages hidden from view except to authorized viewers).

    I have multiple design, performance, & security concerns about the new behavior, so I need to know whether this change is intentional.

    I noticed the changelog indicated “Changed the access restriction model to group-based access restrictions.” As far as I know, all of my restrictions have been group-based all along– the only instance of capability-based access is for site administrators.

    I’d note that I am running PHP 7.0. (I posted in another thread about a minor issue with PHP 7.1, but I have reverted to PHP 7.0 for other reasons)

Viewing 9 replies - 1 through 9 (of 9 total)
  • Thread Starter Abigailm

    (@abigailm)

    9 years, 4 months ago

    OK .. as a follow up… I now see what the problem is. With the previous versions, if a page had access restrictions set to a particular group, page visibility was also restricted.

    With the upgrade, access & visibility are now two different settings. So it seems that it will be possible to replicate the behavior I want on the site — with items only visible to those with authorized access…. but it appears that it would require a separate edit to every single page or post that is restricted. (And perhaps media files as well?)

    For new users this may be an improvement to site function, but for legacy users it represents a tremendous amount of work…. certainly a task I do not want to undertake now.

    Is there any way to get the current read access restrictions on all pages and posts to automatically carry over to the new Group-based visibility restrictions? I’m guessing I have several hundred pages & posts on the site that would need to be updated to work properly with the new system.

    (Again, I’ve reverted to the prior version for now. I think I am in love with the WP Rollback plugin.)

    Plugin Author Kento

    (@proaktion)

    9 years, 4 months ago

    Thanks @abigailm for your detailed feedback on this possible issue, I’ll try to replicate this on a test site to see if there’s a fix needed.

    Plugin Author Kento

    (@proaktion)

    9 years, 4 months ago

    I’ve identified the issue that is causing the menu items to appear and a fix is on its way for today.

    @abigailm Again many thanks for reporting this. Regarding your question:

    Is there any way to get the current read access restrictions on all pages and posts to automatically carry over to the new Group-based visibility restrictions?

    For this new release, I had considered adding a somewhat automated process but discarded it. Basically because I think it would have made things more difficult than they are – here’s why: the previous model uses capabilities to restrict access and the new one uses groups, so even though many deployments may use a direct mapping between capabilities used to restrict access and groups, this is not necessarily so in all of them. In fact, the default capability used to restrict access might be shared by many groups, and so could others created by site owners. Now if we were to automate the process of ‘migrating’ from the old to the new model, a direct 1-1 mapping couldn’t be assumed and thus manual intervention would be needed. This would have required an interface where you map the capabilities to groups and then run a process of updating the restrictions based on groups etc. … not pretty IMHO and we actually already have an interface that we can use and it’s simple, the Posts, the Pages etc. on the WordPress Dashboard.

    So how can you use this to migrate to the new model? With legacy access control enabled, for posts for example:

    Of course, make a full backup of your site and its database first!

    We’ll assume you want to use group-based restrictions for all posts protected until now with a “premium” capability. You would create the “Premium” group if it doesn’t already exist now. If you have many posts, you might want to increase the number displayed per page for what comes next.

    1. Go to Posts and use the access restrictions filter to select one access restriction. Let’s assume that you have one called “premium” there, select it and hit the Filter button.
    2. Now you have your list of posts that are restricted by that capability.
    3. Use the checkbox on top of the list to select all and then in the Bulk Actions dropdown select Edit and click Apply.
    4. In the Groups section of the bulk actions select to add a restriction and choose the “Premium” group, click the Update button.

    Now all the posts in the list should carry the group-based access restriction and the previous capability-based restriction.

    Depending on the number of posts displayed per page, you might need to repeat this for the remaining pages.

    Do the same thing for all access restriction capabilities, creating new groups where necessary.

    So I hope this helps, please let me know if I can help further.

    Plugin Author Kento

    (@proaktion)

    9 years, 4 months ago

    The issue affecting the menu items reported here has been fixed in 2.0.1 – please update to this release if you’d like to give it a try.

    I’ll mark this as resolved, please let me know if you have further issues related to this.

    Thread Starter Abigailm

    (@abigailm)

    9 years, 4 months ago

    Kento, Thank you for your very prompt reply and explanation. I have installed version 2.0.1 as suggested and it the problem with display of access-restricted menu links has been resolved.

    However, I have run into another problem. I followed the instructions you provided for bulk editing and it worked fine for pages.

    However, for posts, the new Groups access option is not showing up on the bulk edit screen — only the older legacy access restriction screen. This is true for custom post types as well as regular posts. The individual post editing screen does display the new Groups-access form widget, but this goes back to the problem of being very intensive.

    It is no longer a critical issue to edit these, but I would like the option of coding all pages so I can dispense with the legacy function at some future time.

    Plugin Author Kento

    (@proaktion)

    9 years, 4 months ago

    Hi,

    I’ve checked with posts and several other post types but I can see the Groups bulk actions to add and remove restrictions, but it’s located above the Tags field when you bulk edit. It looks different for pages but it’s there, along with the old capability access restriction field when you have legacy mode enabled.

    Would you mind having another look?

    Thread Starter Abigailm

    (@abigailm)

    9 years, 4 months ago

    Thank you- you are right, I was looking in the wrong place because of the different location of the field on the “pages” bulk edit page.

    I think I have managed to update all files to the new protocol now.

    I do feel that the direct use of groups to manage page access is an improvement overall and much more intuitive. So thank you for your great work & prompt response to questions and support requests posted here!

    Plugin Author Kento

    (@proaktion)

    9 years, 3 months ago

    That’s great, I’m glad this worked out well. Thank you very much for your detailed feedback and understanding, if there’s anything else I can help you with please let me know. Also any suggestions for improvements are very welcome!

    Thread Starter Abigailm

    (@abigailm)

    9 years, 3 months ago

    Thank you –one suggestion I have would be a way for the administrator to preview and navigate pages as it would appear to different groups.

    I have a plugin called “User Switching” – https://ww.wp.xz.cn/plugins/user-switching/ – that in the past allowed me to do just that. I could just select a user in a particular group and switch to take on that user’s role.

    However, with the upgrade to v. 2.00/2.01 that no longer works. When I switch, the site slows down and pages won’t load. I don’t get any particular error message showing in logs, but I suspect that there is a problem with cookies and perhaps some sort of infinite loop being created within the Groups plugin.

    I didn’t report this before as it is clearly a conflict with another plugin rather than a problem with the Groups. But it would be a nice feature for Groups (though probably not all that easy to code… so this is only a suggestion, not an expectation).

Viewing 9 replies - 1 through 9 (of 9 total)

The topic ‘Problems with upgrade to version 2.00’ is closed to new replies.