This was pulled from Facebook Developer News
The publish_actions permission will be deprecated. This permission granted apps access to publish posts to Facebook as the logged in user. Apps created from today onwards will not have access to this permission. Apps created before today that have been previously approved to request publish_actions can continue to do so until August 1, 2018. No further apps will be approved to use publish_actions via app review. Developers currently utilizing publish_actions are encouraged to switch to Facebook's Share dialogs for web, iOS and Android.
I didn't see anything regarding this in the forums so I thought I would post it here.
Is SE working to fix this?
If it isn't working for you now, https://community.socialengine.com/forums/topic/4/submitting-issue-bug-reports , please follow the guide for posting bugs in the section for bug reports. We can then look into the issue. I will note though that I did post an internal enhancement to update facebook stuff for next major release.
Does this mean apps can't ask you to authorize access to them so they can publish stuff for you when you post activity to Social Engine? also Twitter is discontinuing their API entirely in August as well.
Log in still works but after Aug 1 the publish_action will stop working, I was creating a new app and it will not even give me the option to publish to Facebook.
That will be a real heavy blow to services like Janrain which relies on this to stay alive.
They do have other options its just gonna require them to re-write the code to use the new share functions
What was wrong with the old code? Let me guess. GDPR stepped in and now everyone's all up in arms panicking?
So does this mean that the Share Products by SES and SEAO can no longer post to FB after 2018.08.01? (hopefully these experts will weigh in here)
Elshara Silverheart said:
What was wrong with the old code? Let me guess. GDPR stepped in and now everyone's all up in arms panicking?
It didn't specify why, so its a guessing game...... but at min it is still available as an option.
gs said:
So does this mean that the Share Products by SES and SEAO can no longer post to FB after 2018.08.01? (hopefully these experts will weigh in here)
Per the post above that is the case, like i said I couldn't even set it up as an option was only given the login option in the developer app.
considering Twitter is shutting down API access for good in August 2018, I'd say that yes. That's what's going to happen to Facebook as well.
Great. Another forced round of upgrades. I guess I'll have to include several grand every year for upgrading, and plan hundreds of hours to do so (overall process took almost a year to complete due to Plugins and Customizations). The 4.09.* upgrades killed me last year, which is why I haven't moved to 4.10.* yet.
I use Buffer for my sites and have the app for free in the certified mp. It's been my favorite posting tool for years and my authors have come to love it as well. At least it does offer various social media to post to but it doesn't auto post from feeds. It's just mainly for content posting/sharing from your site to social media. Not sure if that will work for what you need but it's good to have options.
the only time I ever heard of Buffer, is through IFTTT.
FB seems to be vague on what they allow and what they don't. One thing appears clear as crystal however, preauthorized posting permissions are history.
Elshara Silverheart said:
FB seems to be vague on what they allow and what they don't. One thing appears clear as crystal however, preauthorized posting permissions are history.
Agreed
Good to know...
FB: I can post on fb from the site...
Probably the app got "grandfathered" in. Aug 01 will know for sure.
Twitter : stopped working couple days back.
Great tips guys, Thanks
Donna +1 on Buffer
Gonna check it out.
The only way I could see this improving is if you were able to have a Facebook session ID specifically used for one service and the ID token refreshed itself every so often to ensure the connection to the authorized server remained active. But it isn't as if Facebook is worried about hijacking, they're worried about something more redundant then that because they don't realize users have to give consent anyways to use an app to begin with.
All the more reason to buy and invest in Social Engine.
@Donna
Regarding integrations like this, would SE consider creating a method that would require an update to a 'separate' file(s) rather than requiring a full-blown upgrade all the time? This process is getting prohibitively expensive (planning, time, money) and I'm just in Dev mode (I can't imagine the hassle to those in live/production). What I'm geting at is a 'call' to a program that handles FB (or Twitter, or whatever) integration so that if things change it's a small, fairly quick fix across the board, rather than 'part of the next major release'. If this is the way that all scripts work, goodness - not good. If I had to offer to clients (non-SE) a full-blown upgrade to their entire accounting/MRP/HR/Payroll/etc. system every time an 'external' site/software changed something, they'd fire me.
I'm not sure what you mean. We already post changelogs when we have upgrades. That's how clients implement changes without upgrading when database updates aren't required.
But these manual changes are to Core, correct? I thought it was recommended and best practice to not modify Core. Maybe I don't know what's included in changelogs, i.e. do they include 'if you're on this version use this file' type of stuff?
What I'm referring to is something that is often done in other non-script platforms. A call is made to a file or subroutine (or whatever) that contains (for example, FB 'stuff') everything required, including different code when needed to support different versions of both to/from apps. This often helps with backward compatibility because 'old' code isn't always replaced with 'current' code but rather logic is included to allow a file(s) to support multiple versions of apps.
We recommend not making core changes that are from external places. If the script developers say, it's ok to do this to fix that, then you can do that. Changelogs are an example. You can, and many do, take those changes and implement them yourself if you know what you are doing and are careful with backing up each file before tampering with it. We recommend the upgrade process because it's easier for those without knowledge of coding. We require the upgrade process if database changes need to be done.
As for using hooks as you describe, that can be done for some things but for others it can't.