🇺🇸United States @fathershawn

That alter hook was never present on a stable release. The grant workflows are specified in the Oauth2 standard, which is why I removed the hook as I was converting this system to a plugin. If you aren't comfortable putting what and why you need to alter a grant type, please DM me in Drupal Slack. Otherwise can you describe what it is that needs to be different and if that difference is supported by the Oauth2 standard but not by this module?

I'll have a look at the history of that class and get back to you.

Thanks for considering my feedback.

Thanks - I did read that issue. The contextual crop approach is super useful - really like this idea!

I understand that swapping a modified class is more work but there are good reasons to do it:
- Users don't have to understand how to alter their composer.json if they aren't using patches already.
- I am using patches so I'm not sure why it didn't patch, but explicitly decorating a service or altering a route is more reliable.
- If a user uninstalls your module, the modifications are removed. With the patch approach when I uninstall the the module via Drupal the patch remains. Even if I composer remove, the patch remains unless I'm already patching that module or core myself for another issue.

Thanks for confirming - merging so I can tag

Thanks for the prompt! I was working on 📌 Add a sub-module that can be used if DS is present. Active locally without creating an issue here in the queue, which will require v13 but a release hasn't come out yet. Give a quick look at the MR - tested a generator command locally and all seems well.

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

This will be a new feature for v1.1

The upstream changed was merged on Dec. 10, 2024. Waiting on a new release of Drush.

fathershawn → created an issue.

I didn't check if that patch had applied, but I did search my entire codebase for the existence of those methods and I did manually inspect the parent class. So I think we can be confident that it did not apply.

Further, patching core in a contrib module is not generally a good plan. A better approach would be to include the altered ImageStyleDownloadController here in your module and then also alter the image.style_public and image.style_private routes here in your module to use your substitute controller.

fathershawn → created an issue.

Thank you as always Alberto :)

Thank you - what ever is required by the policy. I've been maintaining this module since July 2017. If @guillaumev still wants ownership that's fine and I'm sure he will restore my permissions then.

Yes, I created the D8 version of this project and have maintained it by myself since July 2017. I created it for a client that I no longer have but maintain it for the community. The owner last posted a few weeks ago so we will hear from him I'm sure.

I'll create the release as soon as I have the correct privileges again.

A log is a good idea. In this case I'm sure I've edited the project node in the last 7 years. I know that I've created release nodes, and I'm the only user to commit to this project in that time. It was definitely thoughtless to lock myself out, and I can wait for the timer to expire or perhaps we will hear from the owner on my request to transfer.

I don't have personal urgency but a user has asked for the D11 release now that Commerce has a D11 release.

Contacted @guillaumev via his contact form.

fathershawn → created an issue.

fathershawn → created an issue.

Absolutely - thanks for the prompt! I hadn't checked in a few weeks.

Thank you very much, both of you :)

Thanks @nikunjkotecha for the endorsement! The message I sent was to Avinash because of the policy @avpaderno stated in his comments.

If the process is inflexible we can wait @avpaderno but I'd like to point out that I did attempt to follow the policy by contacting Avinash and by posting an issue that sat silently for more than the two weeks expected and that we are not truly proposing to "create a different project" as what exists is a placeholder: https://git.drupalcode.org/project/dynamic_yield.

I appreciate your care in maintaining drupal.org and in protecting drupal sites against supply chain poisoning!

Hi - That's precisely the approach - to customize the provider as you need in your implementation!

For storage you can you use similar methods to the token storage and use which ever method you chose for that to store this code.

I plan to switch to the new GitLab pages soon - thank you for this question as it will be a good case to document.

Thank you @avpaderno. I sent a similar message on Jan. 17 when I created this issue and attempted to follow the guidelines. Thank you for correcting our process. We will monitor for a response.

greggles → credited fathershawn → .

The `dynamic_yield` project consists of a one line README file created 4 years ago.

My employer is sponsoring the creation on a module to integrate the Dynamic Yield personalization service with Drupal which we intend to contribute.

I used the drupal.org contact form to contact the project owner over 2 weeks ago and have had no reply. It appears that this project is abandoned and I am requesting ownership so that we can use it for our contribution.

I am happy to accept ownership of oauth2_client

fathershawn → created an issue.

It was so encouraging to have all the discussion on this idea this week. The most helpful thing anyone can do to move forward is to review the approach in 📌 [POC] Implementing some components of the Ajax system using HTMX Active and suggest improvements or give a +1. It does not seem prudent to build out an implementation until we have consensus.

Hi @1cg! What a joy to see you arrive in this issue! I'm the most active maintainer for the contributed module → and proof of concept 📌 [POC] Implementing some components of the Ajax system using HTMX Active that we are working on. I'll definitely be in touch today :)

I can think of one thing right off, and that is for the HTMX project to add a security policy. If this proposal continues to gain traction, we would be adding a dependency and our core maintainers will be using our existing dependency evaluation process → . Drupal recently worked with the Revolt event library 🌱 Adopt the Revolt event loop for async task orchestration Active on a similar policy. If it's helpful I'm happy to open a similar issue in your queue.

Your enthusiasm and engagement are a welcome gift @dqd! Our POC 📌 [POC] Implementing some components of the Ajax system using HTMX Active needs review. Your feedback there would really super.

fathershawn → created an issue.

Tested manually as this is dev facing

fathershawn → created an issue.

Definitely - although that might be best added directly in core

Yes you can do that now. I would probably reverse the funtionality of your named view modes but that's for the chef to choose! I would configure one view mode for display in the rendered entity settings for the paragraph field. I would build a Twig template for that view mode that just had the article tag with HTMX properties to get the HTML for the paragraph from our endpoint in the fully configured view mode, triggered on load and swapping itself with outerHTML strategy (replace).

fathershawn → created an issue.

Closing per #7

There is a minor code quality issue in the test results

FILE: ...-3344319/modules/entity_share_websub_hub/entity_share_websub_hub.views.inc
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
 40 | ERROR | [x] Short array syntax must be used to define arrays
    |       |     (Drupal.Arrays.DisallowLongArraySyntax.Found)
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------

fathershawn → created an issue.

Issue #3494451 by fathershawn: Backport HTMX v2.0.4 to 1.3.x - Merged

fathershawn → created an issue.

Implemented architecture

• Accessors for each of the composed attribute and header objects
• A method for both attribute and header that takes appropriate objects or render array snippets and returns that data merged with the data managed in the corresponding property.
• A method for merging another HtmxInterface object that returns an HtmxInterface object.
• Use HtmxOperationInterface objects that implements each of the current ajax behaviors by configuring the appropriate attributes and/or headers.
• Compose these HtmxOperationInterface objects into the HtmxInterface object and process them at render so that they can be altered.

The example implementation in ConfigSingleExportForm is updated with this approach

Passing tests:

• core/modules/config/tests/src/Functional/ConfigSingleImportExportTest.php
• core/tests/Drupal/Tests/Core/Render/Hypermedia/HtmxOperationsTest.php
• core/tests/Drupal/KernelTests/Core/Template/HtmxAttributeTest.php
• core/tests/Drupal/KernelTests/Core/Http/HtmxHeaderTest.php

Oh! I missed that conditional warning message :( I am tagging 1.2.0-beta2 with the message removed. Please confirm this works for you?

Please upgrade to 1.2.x →

The SDC module is no longer required in 1.2@beta:
https://git.drupalcode.org/project/commerce_donation_flow/-/blob/1.2.x/commerce_donation_flow.info.yml?ref_type=heads

@capellic To reduce the markup payload, I think what you are asking for two things:

1. To find a way to supress the admin toolbar when rendering a \Drupal\Core\Render\Plugin\DisplayVariant\SimplePageVariant
2. To be able to render part of a twig template, what HTMX calls a fragment.

It doesn't look hard to remove the toolbar from a render array.

The linked HTMX reference points out that Twig can render named blocks within a template. This would be an alternate render pipeline. I can look at the default "render the whole template" pipeline and see how difficult such a task might be.

As to your paragraph question and the general question of rendering dynamic elements that replace themselves, yes one needs an alternate source for the replacement. That's one reason for how I implemented HTMX blocks as I did. Plus inserting into or taking over the block building process seemed like a challenge. With your paragraphs, I would suggest adding an HTMX view mode that has your lazy loading attributes on an otherwise empty div, and call for the render of the paragaph in default as your HTMX request.

Our second part of the POC is to replicate a more complex command. I first thought of an Htmx object composed of the attributes and headers as a organization tool, but I realize it has more power than that. More complex behaviors will use both toolsets. In particular, we can achieve any behavior not available natively in HTMX using one of the trigger headers to invoke our own javascript.

Proposed architecture

1. Create an HtmxInterface to make it easy for contrib to create additional behaviors
   • Accessors for each of the composed attribute and header objects
   • A method for both attribute and header that takes appropriate objects or render array snippets and returns that data merged with the data managed in the corresponding property.
2. Create a method on the Htmx class that implements each of the current ajax behaviors by creating a method that configures the appropriate attributes and/or headers.

Need to revert the merge, wrong target branch

Added support for HTMX Response Headers which allowed me to implement a missing feature in ConfigSingleExportForm. The route and the form are built to take parameters for configuration type and name. However the implementation via core ajax does not update the url.

This htmx implementation now does so that the result can be captured via a link.

fathershawn → created an issue.

fathershawn → created an issue.