🇺🇸United States @MegaKeegMan

Account created on 8 July 2019, about 6 years ago
#

Merge Requests

More

Recent comments

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

Alright was simply using the wrong use statement for ContainerInterface. Will let you know once I have tested this again

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

The project page documentation has also been updated accordingly.

🇺🇸United States MegaKeegMan

Tested this setup from a fresh installation of the module. Everything is working just fine.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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"

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

Sorry that was empty (having a lot of technical difficulties today). Once again, a patch for 8.x-3.x

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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?

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

Applied the issue fork and it still looks good!

🇺🇸United States MegaKeegMan

Just rebasing to resolve merge conflict in #9

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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?

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

I have tested that authorization continues to work on both forms

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

I was just using tokens incorrectly

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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.

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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

🇺🇸United States MegaKeegMan

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.

Production build 0.71.5 2024