RossGrant

Okay, I think FINALLY I have worked this out!

IGNORE EVERYTHING above more or less, here is what is happening.

‘Read’ is a core WordPress Capability, which by default is set to ‘on’ for many (if not all) WP roles.

Installing BBPress (current version 2.2.4) doesn’t alter that role on initial activation or subsequent deactivations WHEN S2 is NOT activated.

HOWEVER upon deactivation, through upgrade or manually WITH S2 Member ACTIVE, for some reason the ‘Read’ cap is deleted from subscriber, admin and S2 roles 1 – 4.

This won’t cause an issue UNTIL YOU DEACTIVATE S2, when you’ll start having issues with admin menus due to you no longer having the ‘Read’ cap.

The issue that I was having with no access to the ‘Topic Tags’ menu isn’t related I don’t think.

I think this was actually to do with BBPress NOT assigning the keymaster role to admin when upgrading from previous versions of BBPress.

It does this by default now in new versions, but i think for those that have upgraded from previous versions in the past that it wasn’t doing this.

From what I can tell, the best thing to do is to install the ‘Capability Manager Enhanced’ plugin, detailed by Jason in the link above.

Deactivate all plugins except the capability plugin.

Reset all WP roles.

Then activate all plugins again to run the new capabilities needed.

If you are upgrading BBPress after that you must turn off S2 temporarily, upgrade BBPress, then turn S2 on again.

I’m going to keep poking about, but that’s what i’m getting so far.

What do you think Jason, is this an S2 issue then?

*** To assign the Keymaster role to all admins, you will need to create an extra admin account, install the ‘Switch User Plugin’, switch to the new admin, access your original admin edit screen when logged in as the new admin, and assign the keymaster role to your initial admin account.

Update 3.

This doesn’t seem to be an issue on a new S2 install on a new BBPress install.

Some existing caps must be left from earlier BBPress versions that are screwing things up here unfortunately!

Any idea how we could tackle this Jason?

Any way to reset user roles at all and sync them again with S2 member?

I’m guessing there are going to be many folk in the same boat who have used bPress for a while.

Hi again Jason!

I have cleared out the standard tracking codes under API>Tracking and have gone with the cURL tracking pixel URL under API Notifications for both ‘Payments’ and ‘Post/Page’ Access.

I’ve tested for post/page and it works great.

I can’t really test for recurring just yet as I have no test subscriptions up and running.

Will this new method work in retrospect too?

So the subscriptions that HAVEN’T been generating recurring commissions now start generating them when the payments hit?

Is there anything else I need to set anywhere or is that simple cURL it?

Thanks!

Echo, just to let you know, adding download_key=”true” into the shortcode does make my media available to people who aren’t logged in.

Give it another try.

One thing that I have noticed though, is when playing mp3’s on iPad, even setting the player height to 24 as was done in Philly’s shortcode plugin, so that only the control bar shows, the height of the player is about 150px high.

Only happens on iPad or iPhone, the 24px setting is adhered to in all desktop browsers from what I can see.

Cheers Echo!

With Philly’s codes enabling non logged in members access, I’m sure S2 should be able to this this somehow too.

Bizarrely the videos I now have working DON’T play on my ipad even though the media files are EXACTLY the same ones that did play in JW Player 5.

Is there part of the shortcode I need to implement for iPhone/ ipad?

These exact files played fine in JW 5 with Philly’s plugin?

It was me being stupid.

This was a brand new install and I just hadn’t set any ‘Basic Download Restrictions’ in the backend that’s all.

I too do not get a custom image though, even though one is set above.

Is that now a premium feature of JW Player Jason, or should it be working with the basic free version?

:)

Hey Todd, the shortcodes are explained under the Download Options—> Shortcode Attributes And API Functions (Explained) tab.

Nice one Jason, that’s awesome!

Haven’t got a clue how to set it up, but I’ll look into it now.

Did it take you guys long to switch over?

Would be great if it improves deliverability!

Thanks for the heads-up.

Fixed this guys!

It looks like JW Player has issue with responsive themes.

When I turned off the responsive scripts in the theme it sprung back into life.

Anyone else had issues with JW Player and responsive themes?

Here’s a link to one of the pages on the staging site that should be showing the player.

You’ll see the white space only after the ‘Watch a preview’ title:

http://bit.ly/Yzj5dw

Would LOVE some help with this if anyone has any ideas what can cause this.

It’s definitely a change in the theme that I’m using after updating it, but I have no idea what kind of thing to look for.

If I change to the default theme, it all works great, and it still works in the older version of the theme I’m running.

Thanks :)

Hey Jason!

Just to be clear, the link between S2 Member and BB Press only changed when I upgraded BB Press.

S2 was already installed and up to date, so it ws only BB Press that was altered in the update process.

Reading the following from the S2 options for other integrations:

If bbPress® was already installed when you activated s2Member, your s2Member Roles/Capabilities are already configured to work in harmony with bbPress®. If you didn’t, you can simply click the “Update Roles/Capabilities” button here. That’s all it takes. Once your Roles/Capbilities are updated, s2Member and bbPress® are fully integrated with each other.

So the scenario of upgrading BBPress when S2 IS already active might not run that routine to link the roles?

I’m guessing that on each S2 upgrade that routine is automated, but when BB Press is updated and reactivated we may have to push that button to run the routine?

It’s happened on 2 installs now.

All works just fine, but has resulted in the same scenario each time.

Let me know what you think.

It looks like it was Akismet.

I deactivated it and it allowed the user to post.

Upon reactivation they can now post too, so perhaps the roles had played a bit with Akismet, or Akismet’s servers were just going a bit crazy!

It’s all just odd though! Hopefully we’ll get some BBPress2.2 docs soon to work with!

Let me know if you can reproduce anything!

Thanks again :)