justin_k

I haven’t received any reports of issues from any other users, and I just manually verified it myself & it’s still working. Please see the FAQs for common user errors (i.e. you have other conflicting plugins/themes, browser extensions, etc) – or fully describe what behavior you’re actually seeing (“the token doesn’t work” could mean many things, but is not an actual error message shown by the plugin).

2nd comment deleted

• This reply was modified 5 years, 5 months ago by justin_k. Reason: Oops, duplicate info
• This reply was modified 5 years, 5 months ago by justin_k.

The required BP profile fields only affect BP’s registration form. Because there isn’t a 1:1 mapping of BP fields (which could be pretty much anything) to what can be pulled from FB (which is very limited, subject to FB’s review, and constantly changing as FB revises/locks down their API), trying to generically prevent autoregistration unless every BP field were filled by FB would be infeasible and constantly breaking. The addon does provide the ability to do XProfile Mapping with some initial options, and has well-documented examples of how its hooks & filters can be used to implement any other you need. The login-time hooks and filters can similarly be used to enforce whatever registration requirements you desire, based on how you choose to map your XProfile fields to FB, and which fields you’re able to get FB to approve for you.

So yes, there is full support – and what you seek can be done – but a one-size-fits-all fully automated approach of for something like this simply wouldn’t work.

• This reply was modified 5 years, 5 months ago by justin_k.

Not built-in at the moment – please see FAQ #9-d.

Cheers,

I rewrote the auth process & it should be back to 60-day tokens. Please let me know if you have this issue again.

Thanks for pointing this out – ugh, it looks like Facebook has taken it upon themselves to quietly break their API for about the 10,000th time.

I’ll try to start looking into ways to re-implement this to hopefully restore the previous behavior, & will update here with the result…

Oops – I just found one more issue I’d overlooked. Please try to re-authorize once more, it should now prompt you for the manage_pages permission, which should then allow it to work.

Please try de-authorizing & re-authorizing in the plugin’s admin panel; the issue should now be fixed (let me know if not).

Please try de-authorizing & re-authorizing in the plugin’s admin panel; the issue should now be fixed (let me know if not).

Not related to the update – Facebook has started requiring a new permission for getting data from pages. I’ve applied for the new permission & am awaiting their review. Fingers crossed that they approve it, as it is required to be able to continue offering this feature.

As stated above: I’ve submitted a review request, hopefully it should be back up and running in a week. It depends entirely on Facebook approving the newly-required permission.

Looks like Facebook made another breaking change to their API, & now requires additional review before page-fetching will work. I’ve submitted a review request, hopefully it should be back up and running in a week. Thanks for the report.

Version 2.8 should be up shortly. It uses a different method to authorize that should fix the issue. Let me know how it goes!

Thanks – I managed to reproduce it. Looks like it’s a server-side setting, which prevents browsers from loading content in an i-frame on another domain – which is how the login process works.

I guess I’ll have to come up with a different authorization method.

I’m unable to reproduce this in FF v64.0 or Chrome v74.0.3729.169. Can you please provide some specific browser names & version numbers where you observe this message? Also the info from the Support Info tab of the plugin. I’m assuming you see the message in the developer tools console in those browsers?