Automatically Add Post/Page IDs to Restricted Access

#1

Just wanted to verify that this is the only real way to automatically add specific post/page IDs to access restrictions. My client will be adding properties (posts) regularly, which is already a little complicated for them because the posts have tons of custom fields that they need to fill out. I don’t want them to also have to go to s2member and add the post IDs to ‘specific post/page access restrictions’. Not a big deal to make the shortcode for these posts dynamic using PHP. I’ve done that before.

Anyway I see that every single s2member option, including the post/page access restrictions, are stored in a single record in the wp_options table with the option name ‘ws_plugin__s2member_options’. I figured I’d use the ‘save_post’ WordPress action with a category conditional (only include a specific category), and add the post ID to the gigantic options record [in the correct place] and update the record in the database at each post save (as long as they select the correct category). Any opinions on whether this the best/only way to accomplish this?

#2

It is definitely the best way. You have now seen the biggest design flaw in s2Member, but it doesn’t seem to cause problems in practice.

1 Like
#3

Awesome! Just wanted a second opinion… thanks Tim!

#4

I don’t get it. I had this issue with s2member before… it just loses all configuration settings. I did what was the only way possible to solve my issue. I completely configured s2member. Copied the record from the database with all the configuration settings (ws_plugin__s2member_options), and set it up so that the post IDs would get inserted into the configuration. It works. Then all of a sudden s2member loses EVERY SINGLE SETTING. There’s nothing worse than a plugin that keeps losing it’s configuration. What gives?

#5

Obviously, it doesn’t happen generally, so that suggests that there is something specific to your site (e.g. another plugin or some other code) or your host that causes this.

Equally obviously, I am not in a position to know. But my guess would be that the source of your problem is your host.

#6

Host doesn’t have control over s2member communicating with the database. In fact, it’s perfectly normal for the plugin to reset it’s configuration if it detects the options have been modified. That’s just strict security. I didn’t realize that before, but I believe that’s the issue. I noticed a checksum value change in the ‘gigantic string’ (ws_plugin__s2member_options). Anyway, I thought since that’s way way more specific than my original question, I re-posted it at Options_checksum. I’ll close this thread/remove/mark as resolved if I find out for sure that’s the issue.

#7

Actually, in the end, the host has control over everything. But maybe you have found the specific cause here.

#8

I have had another thought. Did you, perhaps, try to filter the options table? If so, I suspect that the problem was that you forgot to return the results before attaching them to the filter.

#9

Nah. The reason for the issue was figured out… I just can’t get a solution to the issue here: Options_checksum

#10

So what did you find that it was?

#11

Whenever you save plugin options, it creates a huge variable out of the option values called a checksum. And every time the plugin runs, it checks that value against the option values and if it’s different, it resets everything to default. If you follow the link in previous replies to the other thread in the forum, it’s more detailed.

#12

OK, I read that. Didn’t realize it caused all options to disappear.

Will continue there.