That message is correct. The permission publish_actions has been removed and should not be requested by JFBConnect at all if you're using a current release (which it seems like both of you are).
Can you please go to the Scope Review section in the Admin area and see if that properly shows you what feature in JFBConnect is requesting 'publish_actions'? That will help us narrow down what's wrong. It could be any of:
1) An outdated Social Profile plugin requesting it
2) A channel setup incorrectly
3) A custom permission request from another extension or manually entered in the Configuration -> Facebook area of JFBConnect
It's possible #2 above is the cause if you had a channel setup before upgrading to 8.0, then deleted the channel after the upgrade. I'm just thinking through this now as a possibility, but if that is the case, then a permission request for your user may still be present from the earlier JFBConnect version. We'd have to investigate further.
Let me know if any of the above helps narrow things down and we'll help you figure out how to resolve it.
The good news is that the message above will only show to your developers, not users, and everyone should still be able to login normally. This shouldn't cause any functional issues, but we definitely want to get to the bottom of it.
Yes, you can do that. There's a difference between a Facebook Application and a Facebook Page:
* Your website (Joomla) requires a Facebook Application to be setup. This is what let's JFBConnect fetch information from a user's profile, post to pages or do any other interactions with the Facebook platform.
* With an Application setup, you can setup as many 'Channels' as you want to connect users that have authenticated to your Application to Pages that those users administer. Each channel lets you post or read from that Facebook Page after the user has give your site/application permission to do so.
So, get started with setting up your Facebook Application and verify that authentication works on your front end. Then, create Channels for each Page you want to be able to post to.
I hope that helps explain, but if you need further details, just let us know!
I don't think that's well documented. It's something we need to fix. I'm glad to hear you got things going though. Should you need anything else, just let us know!
Finally, if you haven't already, please consider leaving a rating and review for JFBConnect, or our support, on the Joomla Extension Directory. It's certainly not required, but very appreciated:
https://extensions.joomla.org/extension … jfbconnect
From our understand and from what we're seeing now that the August 1st deadline has passed is that if you're site doesn't allow normal people to register or login with Facebook, you should simply leave your app in Development mode. In that state, you (the admin) will still be able to grant whatever permissions you want to yourself without any Facebook Review process. JFBConnect can use those permissions just fine.
If you need other users to register (that aren't admins of your app), then it gets more tricky, but even then, you can always flip to development mode (quickly) to grant your admin permissions and then flip back.
At least with the above, you can get around the App Review process (legitimately) while you figure out if you actually need to submit or while you're going through the submission process.
We do what can to confuse and confound
In the "Social" admin area of JFBConnect, there is a drop-down in the Article, Blog and Category sections where you can choose if the share buttons are shown at the top, bottom or both sections of your content.
I hope that helps, but if you need anything else, just let us know.
To get Facebook to allow even your admin to grant the permission, Facebook now seems to require the app to be in Development (not Live) mode. Once that is done, then admins of your app can authenticate and any permission you want can be granted.
Once you grant that permission to your admin, then you can switch the app back to Live mode. At that point:
* Your admin will still have granted the permission and JFBConnect will be able to use the Channel on their behalf as you want
* Normal users will be able to register and get the standard profile fields like email, name, etc
Facebook is changing a lot lately and we apologize for the trouble. We'll be updating the Channel configuration guide with the details above shortly.
I'm assuming that happens when you're logging in? If so, please read through our Facebook Application Setup Guide. That error usually means there's something wrong with your "Valid OAuth redirect URIs" in step 21.
Take a look at that step and make sure everything is as shown in the guide. If it already is, let us know when you get that message (if it's not during logging in) and we'll gladly help further.
I've read a bit about Line before. Crazy business model and yes, huge I haven't looked into it at all for integration with JFBConnect, so I can't speak to that directly.
JFBConnect was built to be pretty easily extensible with new social networks. This is mainly for us to make it easier on ourselves, but we know others have added their own network integration with lesser known or more regional social networks. For basic authentication, it's a matter of creating your own /components/com_jfbconnect/libraries/provider/xyz.php file. That sets up the OAuth2 URLs that need to be called. Then, there's a similar /libraries/profile/xyz.php file that describes how to pull in profile information.
That's not to say it's 'simple', but once those files are setup, JFBConnect automatically detects them and tries to start letting you use them.
Things like Channels (for posting/reading from streams) is another level of complexity because that's usually very specific to each social network. OAuth2 is a standard.. the APIs for each social network are.. not.
I hope that gives a quick overview. If there's something specific you're looking for, or if you know more details about Line on how you need to proceed, we can gladly provide some support and assistance along the way. Generally though, it starts with setting up the OAuth2 portion to let a user authenticate and then moves into permissions and other details.
Objects are hierarchical. So, if you have a category structure of:
* Registered Category
** Reg stuff
** Reg widgets
** Reg garbage
* Public Category
** Pub stuff
** Pub widgets
You could create an object for "Registered Category" and it would work all of the Reg* categories underneath. You should even be able to create an object for "Reg garbage" itself, in which case that object would only apply to that category (in case you don't want to post from just one sub-category)
So, you can get pretty fined tuned on things.. but that shouldn't be necessary for what you're trying, frankly. We like the idea of a Public | Public + Registered setting, so that's going in in an upcoming release either way. I just wanted to point out other flexibility you may be interested in.
We're hoping that the Dev mode setting is a viable option as well. We're hesitant to promote anything as a solution now as Facebook is re-arranging the deck chairs constantly right now. There are many customers like yourself that just want to push and pull content from their page. They don't have registered users to have to accomodate as well. In that case, the dev mode seems like the right solution.
Unfortunately, a large portion of sites need both Channel access and allow users to register. Those are the trickier situations right now, as Facebook doesn't seem to like 'selective' permissions only for the admin. That used to be fine.. in public mode, admins would still be requested the permission but normal users would see it. They've flipped that upside down now to only allow admins to get it in dev mode... but then require approval as if you want to get it from all users.
We think they'll correct that at some point, but don't know if they'll make it more onerous or more lenient.
I do hope you have what you need by using Dev mode and don't run into any further issues!
What you're looking for may be possible with CSS, but it'd be difficult to shift it all the way over there. What I'd recommend is:
* In the SCLogin module, disable the showing of social network login buttons
* Create a new custom HTML module
** Place it in the top right corner of your page wherever you want it
** In the Custom HTML area, add:
<img src="/media/sourcecoast/images/provider/facebook/icon_label.png" alt="Identificarse con Facebook" title="Identificarse con Facebook">
That's the same code the SCLogin module uses.
With that, you have a lot of flexibility to move the button around, change the image, and style it however you want.
I hope that helps,
We agree about knowledge sharing. We're awaiting approval of a few apps to see how it goes, find tune, and then publish our results. We'll make it very clear what works for us.. and we'll be very persistent as well
Thanks for the explanation. Your use case is spot on and one we've thought of before. Many sites use auto-posting as a 'hook' to get people in, so the current method hasn't caused any complaints. With how it is now, an autopost happens and that may make people register on your site. The content wouldn't fully be in the post.
One thing possibly not mentioned is that you can select which categories an autopost can happen from. If you segregate your content by category and certain categories are for Registered users only, that could work. The setting is a better catch-all, but calling that out in case you weren't aware of the category-level ability.
We'll be looking into adding this as an option in the next release. We completely understand if you want to keep some stuff private though
My question is that now that I am locked out of these permissions how can I show them being used in a updated screencast? I am not sure what I would even add to the screencast...
You have 2 options that I know of:
1) (Recommended) Put your app in Development mode while you create the screencast. In that mode, admins of the app will still get any permissions.
2) (Ugly) Create a copy of your site, create a new app, use that new 'clean' app to request permissions
The only reason we'd recommend #2 is if you have so much traffic and constant logins that 0-downtime for social logins is required on your live site.
I figured it would only show me it once and after I click okay it would take me back to my site logged in as Admin (as it is my developer account). It didn't, the dialogue just repeated itself after I hit okay (I did it 3 times).
This is likely a bug in JFBConnect. When you setup a channel, we check if you have the right permissions on login and redirect you to request them. Since you can't grant them, JFBConnect is probably causing a loop by not detecting -> re-requesting...
Again, going into dev mode (temporarily) should let you grant that permission and *I believe* allow you to still use that permission for your admins while in 'live' mode. That may be what is necessary now to let you work through the review process (if that's even possible) while still being able to use those permissions.
Let us know how that goes,
A lot probably depends on the reviewer you get.
I think that sums it up exactly. It's going to be hit or miss... the good news is that if it's critical, you can likely keep submitting and (eventually) get it approved as long as you're not too out of bounds on something.
So I am wonder is an app is never set to public, and is only used by the creator, with dev mode working, will that bypass the app review process.
Our understanding and belief is that yes, this is true. If you don't want normally users to login to your app, leaving it in Dev mode to do what you want is acceptable.
We definitely appreciate the feedback. We know there's a learning curve to JFBConnect. It's grown quite a bit over a decade of development and constant changes in each social network. It's a constant game of trying to simplify things as much as possible, but we don't have full control of it all (and things move fast, making it difficult to keep everything in check).
Anyways, glad you're happy and definitely let us know if there's any other suggestions or thoughts you have!
We're still in the waiting process ourselves. We had received approval for various permissions before they made everyone go through the process again though.
You're correct that, at a minimum, you should always be able to get the basic profile information (name, email, etc) even if your review request for other permissions is denied. JFBConnect works seamlessly with whatever permissions are available, so even if you have JFBConnect configured to import user_link or other profile data that requires permissions, if that permission isn't available for the user (it was never requested or the user denied it), JFBConnect will just skip trying to import that field.
We'll agree with you though that the process is a bit of a mess. Right now, it's taking weeks to get someone to review your application. The feedback is light if you're denied and you have to re-submit from scratch if so (waiting in line again). The deadline of August 1st has been very blurry as well where Facebook has used language like "You have 'x' days to submit your apps for App Review to retain access to Facebook Platform APIs before the August 1, 2018 deadline." which, in some places, they seem to indicate they won't cut off your ability until you've been denied (since reviews take a while) or if you'll lose access while waiting.
We are putting together information about our app review submission, but for some features of JFBConnect, the permissions don't fall directly in line with Facebook's requirements. Especially for "Channels"... JFBConnect follows the rules on what can be done with the permissions, but JFBConnect really is only meant to get those permissions from admins.. so review process hasn't (and really shouldn't) be required since it's not for all users. We'll see what they say though.
If you're interested in our submission videos for channels, feel free to check them out:
https://www.youtube.com/channel/UCKJ-56 … subscriber
Keep us posted on the review of your JFBConnect application!
Awesome. I'm unsure what's going on their either. Unfortunately, LinkedIn's authentication API isn't as robust (or stable) as many of the others. Obviously, it shouldn't take repeated login attempts to get things going.. but fortunately, once it works, you should have a valid token that works for months.
In the future, if it breaks again, we'll gladly help investigate further.
Thanks for pointing that out. From a quick check, you're right that we're not copying that value over. I haven't tested this yet, but it seems like adding the following code to the /media/sourcecoast/mod_sclogin.js file, around line 45, should do the trick:
var rememberField = jfbcJQuery(formId + ' :input[name=remember]').eq(0).clone(true);
I believe that will work if the Remember Me field is set to show, but will break OTP if the field is not set to show. We'll have to do some testing with it in general, but would love to hear your feedback if that gets things going for you.
I tried to go to your /actueel page, but it's just a white blank page. That usually indicates a PHP error is causing the page to not render. Did you edit some code that may have caused that? To check the error, you can set the Error Reporting option in the Joomla Global Configuration area to 'Development' and reload the page. That will show an error message along with details about the cause. Revert the Error Reporting setting once fixed though.
The errors you show in the console are from Linkedin's CDN (Content Delivery Network). It seems like something on that page was trying to load content from LinkedIn, but was denied. I see that on your homepage as well and it looks to be coming from a broken image in the "LinkedIn Company Profile" widget in your 'Who are we' block. The lower right of that widget isn't showing your image. I don't think that's related to the stream issue, but I honestly don't know how to fix that either. LinkedIn is generating that block automatically, we don't have control of the content within it.
I just tried to login with LinkedIn. My account is not admin-activated yet, but if you can do so, feel free to setup a Channel for my user and see if you get the same errors.
I believe what you're saying is correct, and I'm sorry for the trouble you've run into and debugging it took you to get there. Unfortunately, Facebook has been constantly changing their API access and approval process over the last 4 months since all the privacy issues have come to light. We've been working hard on updates on our end to ease the transition to the new Facebook order, but surely have missed some steps on the way.
In the past, the message you got was standard fare. It would display until you went through the App Review process. However, if you were an admin of the app, you could still grant that permission to yourself. In almost all uses cases of JFBConnect, that was enough. You didn't need the full app review for those permissions because it was just the admins using it anyways.
Now, it seems like you can only grant that while in Dev mode. BUT, once granted, that permission will work when the app is switched back to Live mode. Our new (current) recommendation is to:
* Get the permission while your app is in dev mode
* Switch back to live
* Submit the app for approval for manage_pages and publish_pages - If you get approval, you never have to worry about this
That last point is annoying though because elsewhere in Facebook's documentation they say you shouldn't go through App Review if just admins are using the permission.
On August 1st, Facebook has set a deadline for getting app review for some permissions to keep working. We'll be keeping a close eye on what functionality works, and doesn't, after then. Of course, we'll make any adjustments necessary to JFBConnect as well.
We're putting together more guides for the approval process, but you can see our submission videos for different channel features on our YouTube page. These were intentionally made 'off the cuff' because that's how most users will do it. We didn't want to show a professionally edited video, just what (we think) Facebook expects. Our reviews our still in flight:
https://www.youtube.com/channel/UCKJ-56 … subscriber
For more info on the App Review process, if you haven't read it, see:
https://www.sourcecoast.com/blog/facebo … -explained
In the top right of the Autotune Facebook App area there is a "Refresh" button. Click that and it will refetch the recommendations for your site.
I hope that helps,
I have installed SClogin and JFBconnect on our site and always been able to share the Linkedin posts on our news page, but now it's broke.
Tried it again by your doc.. but without succes.
You were able to post to LinkedIn previously using JFBConnect and it just stopped? I'm just trying to confirm what may be happening because we haven't had any other reports of LinkedIn not functioning and you can see it works in our social stream on the page below.
Based on the message though, the only thing I can recommend is to re-authenticate on the front-end of your site with LinkedIn. The message in the Channels area indicates that JFBConnect isn't seeing the proper permission.
In your configuration settings, please update the following:
* OAuth Redirection URLs - Remove the last 2 items that are just your domain without any query strings after. Those aren't correct.
I hope that helps,