About: Kevin Vaughn

Unfortunately, re-saving the URE plugin form breaks all “access_s2member_levelX” checks, even when no changes are made to the form.

Note: the “Custom capabilities” part is missing from the URE settings form. Screenshots are posted here:
http://wordpress.org/support/topic/critical-saving-settings-breaks-all-s2member-access-checks?replies=2#post-4163048

http://www.topsitemakers.com

Buck, Thanks for your input regarding your experience with Courseware. Very good to know.

Anyone else, maybe someone from s2Member?

I’m not asking for an endorsement of the product, I just want to know if there are any compatibility issues in general.

Raam, thanks for the quick response!

My site is live and very active. Before disabling functionality, do you think you can take a quick look at the list of active plugins on the site and let me know if any are more likely to be the culprit?

Current theme: TwentyTen

Plugins:
BackupBuddy
Bad Behavior
bbPress
bbPress Post Toolbar
bbP Signature
Executable PHP widget
File Gallery
GD bbPress Attachments
Global Hide/Remove Admin Bar Plugin
Login Logout
Members List
Mime Type Link Images
More Mime Type Filters
PHP Execution
PHP Text Widget
Recently Registered
Revision Control
s2Member® Framework
Search bbPress 2.0
Send From
TinyMCE Advanced
User Messages
User Role Editor
Widget Context
Widgets on Pages
WordPress Media Tags
WP-PageNavi
WP Show IDs

Thanks!

Thanks Christian, I appreciate this…

Hi Raam,

Thank you for your response.

We found what caused this issue in the meantime.

One page ID on Restriction Options -> Page Access Restrictions did not exist anymore. The page was deleted from admin.
This caused unpredictable content access permissions, so users were not able to see the forum topics.
As soon as we removed that page ID, everything went back to normal.

The ID was in the “Pages that require highest level #4” field.

This is a bug/glitch in s2Member. You can solve it by implementing the delete_post or before_delete_post action and removing the page/post IDs automatically from the list of restricted pages.
Also there might be something wrong in the plugin logic which checks particular IDs – you can add an additional check to see if the page/post exists for sure and only then to continue.

As this possibly results in broken access permissions, the most appropriate is to address this issue in the next batch of updates. You have many paid customers who use your plugin for protecting private discussions and communities and they might not be even aware of this issue.

Let me know if you need any other details.

Regards,

Aram

• This reply was modified 4 years, 4 months ago by  Kevin Vaughn.
• This reply was modified 4 years, 4 months ago by  Kevin Vaughn.