🇺🇸United States @MegaKeegMan

I can confirm that I have encountered the error and that the MR does fix it

Applied the issue fork and it still looks good!

Just rebasing to resolve merge conflict in #9

megakeegman → made their first commit to this issue’s fork.

Well it looks like my issue was actually the fault of some custom template overrides. The line mentioned above turned out not to be problematic, once my overrides were updated to be more in line with gin's expectations

I am also having an issue relating to these few lines of code. I did a little debugging and checked before:

$form['status']['#group'] = 'status';

I saw that the value was 'footer'

Now I am able to get the status checkbox to show up when I comment out the line that sets the '#group' property to 'status'. But if I leave the code as is, then the status checkbox is nowhere to be found. I am a little bit confused about the reasons behind setting the '#group' property (I see that it is not on every field), and I feel like resolving this issue sort of hinges on an understanding here. I assume that setting it to 'status' is related to the stickiness though?

MR is not ready, I just created it so it was easy to apply the diff. Currently, only the mapping configuration fields have been updated to be textfields that accept tokens, and have a handy link to open the token browser.

megakeegman → made their first commit to this issue’s fork.

Following along the above documentation did not work for me. I was not able to get my access service to load, so I put the access check directly in the form.

I think the main thing I am interested in your patch is usage of media and link in fb post. I have opened another issue for that.

But it would help to get a better sense of what errors you are hitting, as I have not experienced issues with the Agaric Facebook library. This doesn't really have much to do with D10 compatibility, as the module is already D10 compatible, and also D11 compatible. Additionally, different parts of the module have been updated pretty significantly in the past few weeks. So I wonder whether your issues will still occur.

Advanced access check documentation here: https://www.drupal.org/docs/8/api/routing-system/access-checking-on-rout... →

I went ahead and made an issue fork, but haven't tested it yet, bc like I said I haven't been able to log into twitter. But I think it is set up correctly. I personally like the ability to choose which user should post from a token, as it provides the flexibility to get the user id from a field or from current user, or wherever. Same rules as usual apply when using tokens. My typical values for the configuration fields would look something like:

[current-user:id]
[node:field_facebook_post:value]

Even though I may not be able to use this, I would love feedback on this as it relates to the work I am doing on facebook and mastodon social post modules.

Applied updates from the bot. Have not tried this on D11 yet, so will leave this open, but can confirm that upgrade status only reported that D11 compatibility only needed the version requirement added.

megakeegman → made their first commit to this issue’s fork.

megakeegman → created an issue.

I have tested that authorization continues to work on both forms

megakeegman → created an issue.

Additionally, I am adding a sitewide account functionality ( https://www.drupal.org/project/social_post_facebook/issues/3536481 ✨ Sitewide account Active ), while preserving the per-user functionality, so this is one other thing to consider as far as what kinds of RulesAction might be possible

In addition to adding the flexibility of enabling a sitewide account, I updated the ECA action to default to the sitewide id (0)

megakeegman → changed the visibility of the branch 3536480-integrate-with-eca to active.

megakeegman → changed the visibility of the branch 3536480-integrate-with-eca to hidden.

Also noteworthy, I have started the ECA implementation in a separate issue fork: https://www.drupal.org/project/social_post_facebook/issues/3536480 ✨ Integrate with ECA Active . It allows some flexibility as far as choosing which user's account should be doing the posting. I haven't done anything like that for this RulesAction plugin, mostly because I don't have experience with setting context for rules, but maybe while we are on this topic it would be good to consider what people want/need out of this.

I was just using tokens incorrectly

Nope running into errors. Having an issue where using token replacement for message and user id gets complicated because different fields and/or other token replacements are of different types. Need to make sure I understand how to work with different kinds of tokens.

The RulesAction implementation has many broken parts. Discussion and code for fixing the plugin implementation are occurring in https://www.drupal.org/project/social_post_facebook/issues/3338595 🐛 Rules Implementation Error Needs review

Would be helpful if someone could test the issue fork and provide feedback. If you need it, there is updated documentation pending in https://www.drupal.org/project/social_post_facebook/issues/3422380 💬 How to configure applications on Facebook Active

Feedback on that documentation would be helpful too.

I am not very familiar with rules, so will be relying on people here for feedback.

I have implemented an ECA plugin over in Social Post Mastodon: https://git.drupalcode.org/project/social_post_mastodon/-/blob/3.0.x/src...

I would try doing it here, but I haven't had any success with twitter in years now. I haven't even been able to log in because verification codes never get sent and twitter support never responds to support requests. So for anyone that has twitter working, I hope the example in mastodon helps with getting this set up over here. If I do end up getting into Twitter, then maybe I will come back to this.

I actually set it up so that if someone authorizes posting to more than one page, then the account details will not be added to Drupal.

I did implement such an action in Social Post Mastodon: https://git.drupalcode.org/project/social_post_mastodon/-/blob/3.0.x/src...

Ideas to improve this are welcome. And if there is a good way to build an action plugin in Social Post, rather than the implementing modules, I'm happy to discuss that and help out. But I hope this helps move this effort forward. I think ECA will really help these modules out. Thanks for the suggestion, and for the help with implementing this for Mastodon.

megakeegman → created an issue.

megakeegman → created an issue.

As for the documentation, it will be important that if someone accidentally authorizes posting to multiple pages, they will need to delete the connection to their account on the Drupal side, and re-add it. During authorization, they should click the link, "Edit previous settings", which will allow them to update their selection of pages that the app can post to.

This has actually turned into a somewhat larger refactor than I had initially anticipated, but it couldn't really be helped. Posting methods are being moved out of the network plugin and into the FacebookPostAuthManager. I have managed to get posting working in the issue fork. I think the only remaining step here is to make sure to sufficiently document for the end user that they should only authorize posting to a single page.

Adding related issues, which should be completed before this one.

megakeegman → created an issue.

megakeegman → created an issue.

Tested this locally and all seems good. Thanks for the report and MR.

megakeegman → made their first commit to this issue’s fork.

The module is functional, but in a difficult to use state. I am actively documenting and addressing existing issues now. I will update the Module page once I feel that the module is in an easily usable state. That should be soon.

I can make an attempt to clean this up. This module has been in a bit of a mess for a few years now. As a result of a lot of changes in facebook, I have mostly been posting externally by calling a post method that is in the .module file, which requires passing the page id and everything to it. The rules action plugin uses the original doPost, which I have not used in a very long time, but I can return to this issue once I have updated the module to actually utilize doPost like has been expected. In the meantime, let me know if there is still interest, or if an ECA integration would cover people's needs at this point in time. I intend to add an ECA action plugin anyway.

Going ahead and closing. Additional documentation is also being introduced in another issue: https://www.drupal.org/project/social_post_facebook/issues/3422380 💬 How to configure applications on Facebook Active

megakeegman → created an issue.

Yes, I have not used the RulesAction plugin, but intend to implement an ECA action plugin very soon. Should rules still be supported at this point?

I have added the above documentation to the readme as well. If anyone wants to take a look, and maybe try to follow along, that would be helpful. These instructions should enable you to auhorize posting to a page on behalf of your account. Having an account show up in the table on your user page is a good measure of success here.

I think the use-cases pattern that facebook has added does make some of this a little bit easier than it used to be, but it is still pretty convoluted

Sorry this has taken so long. This module has been in a halfway state for a little while now, and a big part of the reason is that working with facebook is so complicated. We had made it through this process once. I will put my notes here, and then make sure that they make it somewhere more prominent before closing this issue.

Requirements:

• Facebork account
• Business/other page with permissions to manage that page (create posts, etc)

To create an application on Facebook

The Application is what your web site will use to authenticate to Facebook and ask a user to grant privileges to post to your pages. You'll need the Application created and to add it's settings to your Drupal configuration so that it can prompt to request permissions. Essentially, the Application acts as an agent for your website to create posts.

Go to the developer center at https://developers.facebook.com/ and go to "My Apps"

Create an application:

Provide some name and an email for the application. The name of the application will appear on posts as the "Published by"

For permissions, select the use case "Manage everything on your Page".

There's no requirement to select a business portfolio for this application.

Click next until you are able to complete creating the application.

Ensure you are on the application dashboard. This should be where you land on upon creating the app. If not, select the application in the list of applications.

Select the "Customize the Manage everything on your Page use case", and ensure the following permissions are granted:

• pages_manage_posts
• pages_show_list
• public_profile
• email
• pages_read_engagement (seems needed on use case, but not on business configuration?)

Click Add next to any that are not enabled. No additional permissions should be needed, so remove others if you'd like.

Return to the application dashboard, and expand the Facebook Login for Business and go to the settings.

Add Valid OAuth Redirect URIs to reach back to your application. You'll want to add one for each domain you need to reach. For example, to reach a live example domain and also test with your DDEV instance, add:
https://example.ddev.site/user/social-post/facebook/auth/callback
https://example.com/user/social-post/facebook/auth/callback

Now add a login configuration. This is also under Facebook Login for Business called Configurations.

Call the configuration anything you like, for example "user_login".
Use the general login variation.
Select user access token.
Under permissions, add the pages_manage_posts, email, pages_read_engagement, and pages_show_list permissions. When finishing the creating the configuration, make note of/copy the configuration ID (you can still get this from the configuration list if you missed it).

This should be sufficient configuration to use your app. Now, acquire the ID/secret you'll need - along with the configuration ID - to add to Drupal.

On the left, under App Settings, go to the Basic Settings. Copy the following:

App ID
App Secret

Then under App Settings go to the Advanced Settings. Make note of the API Version. Remember this location - Facebook will periodically deprecate API versions, and this value may need to be changed in the future.

# Configure Drupal

Add your App ID, App Secret, and Configuration ID to your Drupal configuration at `/admin/config/social-api/social-post/facebook`. Also ensure the API version matches what was listed in the advanced settings of the application.

If you prefer to keep your settings in your `settings.php` (or e.g. `settings.local.php` as applies to your usage style/environment), the structure looks like this:

$config['social_post_facebook.settings'] = [
  'app_id' => '1234567890123456',
  'app_secret' => 'bMYAPPSECRETETC',
  'graph_version' => '23',
  'config_id' => '0987654321098765',
  'oauth_redirect_url' => 'https://example.ddev.site/user/social-post/facebook/auth/callback',
];

*Dev note: the oauth_redirect_url should default to Drupal's hostname/user/social-post/etc... if it does not already*

# Connect your facebork user to your Drupal instance

When logged in as the user you want to associate with your Facebook account, go to your users edit page, and click "Add account" under the Social Post Facebook section.

During this process, ensure you select the option "Opt in to current Pages only", and select ONLY the one page that you will want to allow the app to post as.

# Create a page

Creating a page is pretty straightforward. Logged in, on the main facebook page, click on see more in the left sidebar. Then click "pages". From there, click "Create new page" and just follow the prompts until your page is complete. Once done, navigate to your page, and you can find your page id by clicking "About" and then "Page transparency".

**To be removed:** This is also a convenient time to acquire the Page ID, which is also needed in settings for Drupal to know what page ID to post to. If you do not get it here, see the "Create a page" above for another way to find it.

The page ID then also goes in `settings.php` as:

$settings['facebook_page_id'] = '123456789012345'; (planning to change this soon)

Instead of adding the ability to specify pages, we can just document in the UI that the module only supports authorizing access to a single page. This will keep things simpler for now. Users will just have to make sure to only select a single page during the authorization process.

This issue does not seem entirely unique to this module:
https://github.com/bluesky-social/social-app/pull/8572
https://github.com/bluesky-social/social-app/issues/6133

I intend to experiment a bit this week to learn a little bit more about this issue.

also, @will_frank, your question may be more appropriate as a support request, or somewhere in the Drupal slack. Sounds pretty interesting though.

While there is certainly more to do here, I have successfully posted a message via this plugin implementation in the issue fork. The post here currently only contains a message. Before doing more, I need to review and consider building the post data from the SPC side.

megakeegman → created an issue.

Tested adding and deleting accounts for both the sitewide and user context. All seems to be working okay.

In a meeting, we determined that we will actually move forward with the first alternative:
allow admin to authorize posting from the admin settings (rather than user context)

For anyone following along, or for future me, my immediate use-case for this is that it is prerequisite for implementing the Social Platform plugin (social post controller module). Social Post Controller can not make use of the Toot action plugin, since rather than posting on save, social post controller instead queues the posts (so that posting can occur asynchronously). It may be worth considering whether that queue could be generated at some point also.

Anyway, the blocker is that a plugin for Social Post Controller does not currently have a way to determine which social account should be posted to. Implementing a site-wide user here is a quick, low barrier fix that could be generally useful.

megakeegman → created an issue.

Okay was able to resolve my issue. Jurgen informed me that clicking on tokens in the token browser is not supported. My issue was that I am sometimes able to click on tokens in the token browser to populate the field. When that happens, I do see visually that the field does in fact get populated. But when saving the form, Drupal does not know that there is a value there, and so it does not get saved. But the good news is that if I type manually (or copy and paste), it does actually work as expected.