Hmm while this would be nice, I think the available logic should actually be enough, just with different logic. I will report back after another attempt.
megakeegman → created an issue.
I have tested the code, and it is working okay. I'm not yet ready to add facets or images yet, as I have work to do on the drutopia microblog side and decisions to make. But it is functional and useful as it is now, too.
Upon learning that I should not need to store the service instance in order to keep it available, I made one more attempt at that pattern. Unfortunately it did not work. My previous comment is probably the path forward here.
Alright was simply using the wrong use statement for ContainerInterface. Will let you know once I have tested this again
Alright I did update, haven't tested yet. Currently trying to figure out why my IDE is upset about the create function not being compatible with ContainerFactoryPluginInterface
Thanks for the feedback, I will try that out
Issue title was updated to reflect architectural change, where the plugin definition was moved from Social Post Controller (which was renamed and moved to MPOSSE), and moved into its dependency https://www.drupal.org/project/drutopia_microblog → . The issue fork will need to be updated to reflect the namespacing of the extended base plugin, just a small change.
This plugin definition was removed from Social Post Controller when it was renamed and move to MPOSSE - https://www.drupal.org/project/mposse →
The plugin definition now lives in Drutopia Microblog
Such a queuing functionality should probably be a separate feature request. Also noteworthy that https://www.drupal.org/project/social_post_controller → does actually manage such a queue for posting to social media, but does so via code, and not with any integration with ECA. I think it does make sense to have queuing here, but it should probably be noted that Social Post Controller should probably not be used on a site that is managing queues via an ECA, assuming that such plugins are created.
I started an issue fork, starting by attempting a refactor of the ECA plugin into multiple with different concerns. The idea was that there could be an action that prepares the mastodon post manager for posting, and then a separate one that was actually responsible for posting. Unfortunately, I have not yet been able to find a way to make the same instance of a service available across plugins in the same model. I wanted to do this so that someone could prepare the post manager once, and then post as many times as they wanted.
I don't necessarily want to continue on this at the moment, and may just continue separating out the functionality from doPost, and putting too much into the execute of the Toot action class. If ever we want ECA to be able to post multiple posts, then we should probably instead focus on queuing up posts and then having a single action that processes the queue and can post several posts at a time, or something along those lines, especially if I get confirmation that preparing a service in one plugin instance, there is no way to keep it available for another plugin instance.
megakeegman → created an issue.
megakeegman → created an issue.
Project page documentation has been updated. This documentation is under review. If you would like to help out, please try following those instructions and share feedback in https://www.drupal.org/project/social_post_facebook/issues/3422380 💬 How to configure applications on Facebook Active
I am going to close this issue, as I believe this module to be in a usable state, and I am generally available and interested in making improvements.
The documentation is now on the project page. I recommend anyone looking to review follow the instructions there. I will keep this open for now until I get some feedback.
The project page documentation has also been updated accordingly.
Tested this setup from a fresh installation of the module. Everything is working just fine.
With this issue fork:
The field can be added and configured by going to settings page for a content type, opening the Social Post Controller settings, and toggling "Enable Inline Microblog".
Once merged, the above description can replace a big chunk of the instructions on the project page.
This is a little old but maybe still useful: https://drupal.stackexchange.com/questions/222260/add-content-type-field...
One of the answers in this thread recommends adding a field storage config to the config/install directory. This is something I had considered before, but I thought I had tested something like that previously. I was pretty sure that if you did not have any field instances for a field storage config entity, then the storage would get deleted from config? Maybe it is different if you create the field storage without ever creating a field instance for it. Even still, this could be a little problematic if my memory of this is correct.
In the issue fork, I have simply added a new form mode and form and configured a new form display for microblog. Since adding the microblog reference field to a content type occurs manually right now, configuring the field widget to use the spc inline microblog form mode should be documented before this is closed. Otherwise, before merging and closing this issue, I want to think over the form mode name.
Thank you! If you are able to reproduce the issue using the CKEditor method described in the issue description, that would be really helpful. I am really curious whether the problem described there and the problem I describe with the masquerade module are in fact caused by the same thing. I suspect that they are, but I have not tried the CKEditor embed myself.
Updating the title to reflect behavior. Based on the updated code, my assumption is that this is only a problem when the additional form (and its form actions) occur before the form actions of the main form. I believe the query selector just grabs the first set of "edit-actions" and then sets the sticky save button to point to the first one it finds. This is why I think using id as the selector will be better than using the data-drupal-selector. This js fails to perform its intended purpose when there are multiple elements with a data-drupal-selector with the value "edit-actions"
FWIW, the needs here should be met by ECA integration, which will provide more controller over which user is posting: https://www.drupal.org/project/social_post_twitter/issues/3452996 💬 How to use with ECA module Active
The ECA plugin in this referenced issue allows for configuring which user posts, and ECA integrates with tokens, so you could say current user, or hard-code a value, like 1. And of course there are more possibilities too.
On a separate note, I did add functionality to Social Post Facebook and Social Post Mastodon regarding authorizing posting for a sitewide account. This included a new form route in the module's settings. This is a bit of a tangent, but I like this pattern because it allows you to use these social post modules in a way where you can not allow any users to add an account to their user, and be certain that there is only one account without having to make an individual role or anything. But it also preserves the originally intended use of one account per user.
Sorry that was empty (having a lot of technical difficulties today). Once again, a patch for 8.x-3.x
I was wrong, adding a patch for 8.x-3.x
I accidentally made the MR against 5.0.x, but I don't think it should matter. The same issue is present across versions 3, 4, and 5, and I think the patch should apply to all 3.
There was. I needed to compile!
I'm wondering if we can just change
const formActions = form.querySelector('[data-drupal-selector="edit-actions"]');
to
const formActions = form.querySelector('[id="edit-actions"]');
because I think using data-drupal-selector it is just finding the first instance (which may be the wrong one, but it would never be wrong if we selected by id instead (unless the edit actions in the wrong form got assigned that value I guess).
I tried making this change and testing, but I can't seem to get drupal to load the updated version of my js file no matter what I do. I turned off js aggregation. cleared all caches via the UI and via drush.
Is there something simple I am missing here?
I am actually having the same issue, but rather with the masquerade module (version 2), which provides a form block for masquerading. The "for" attribute on the save button in the gin sticky actions bar is pointing to "edit-submit--2" (which is the masquerade form, at least on entity edit pages) rather than "edit-submit" (which is my drupal entity form). So when I click save, same thing, the focus shifts to the masquerade form rather than saving my entity.
Also, I am on Drupal 11.2.2
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.