🇺🇸United States @fathershawn

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.

fathershawn → created an issue.

Level 5

Up to level 3. We need a test fro \Drupal\oauth2_client\Controller\OauthResponse

fathershawn → created an issue.

The failing test is was for the upgrade from 3.x to 4.0. Although there are still 150 or so installs on that version, it's not possible to upgrade from 3.x to the release that this code will land on as 3.x only runs in D9. Removed the test. Corrected other lint detected.

Thank you for such a well executed contribution!

I see that all tests passed in GitLab. Checking out the MR and running tests in DDEV via ddev-selenium-standalone-chrome:1.1.0 I get a couple of things:

HTML output was generated.
https://oauth2-client.ddev.site/sites/simpletest/browser_output/Drupal_Tests_oauth2_client_Functional_Oauth2ClientCollectionTest-93-40265769.html
https://oauth2-client.ddev.site/sites/simpletest/browser_output/Drupal_Tests_oauth2_client_Functional_Oauth2ClientCollectionTest-94-40265769.html
https://oauth2-client.ddev.site/sites/simpletest/browser_output/Drupal_Tests_oauth2_client_Functional_Oauth2ClientCollectionTest-95-40265769.html
https://oauth2-client.ddev.site/sites/simpletest/browser_output/Drupal_Tests_oauth2_client_Functional_Oauth2ClientUpdateTest-153-31269380.html


Time: 00:06.686, Memory: 6.00 MB

There was 1 failure:

1) Drupal\Tests\oauth2_client\Functional\Oauth2ClientUpdateTest::testOauth2UpdateHooks
The link Continue was not found on the page.
Failed asserting that an array has the key 0.

/var/www/html/docroot/core/tests/Drupal/Tests/UiHelperTrait.php:456
/var/www/html/docroot/core/tests/Drupal/Tests/UpdatePathTestTrait.php:50
/var/www/html/docroot/modules/oauth2_client/tests/src/Functional/Oauth2ClientUpdateTest.php:78

--

2 tests triggered 1 deprecation:

1) /var/www/html/vendor/symfony/error-handler/DebugClassLoader.php:341
Method "League\OAuth2\Client\OptionProvider\OptionProviderInterface::getAccessTokenOptions()" might add "array" as a native return type declaration in the future. Do the same in implementation "Drupal\oauth2_client\OAuth2\Client\OptionProvider\ClientCredentialsOptionProvider" now to avoid errors or add an explicit @return annotation to suppress this message.

Triggered by:

* Drupal\Tests\oauth2_client\Kernel\Oauth2ClientEntityKernelTest::testClientCredGetToken
  /var/www/html/docroot/modules/oauth2_client/tests/src/Kernel/Oauth2ClientEntityKernelTest.php:153

* Drupal\Tests\oauth2_client\Kernel\Oauth2ClientEntityKernelTest::testRefreshGetToken
  /var/www/html/docroot/modules/oauth2_client/tests/src/Kernel/Oauth2ClientEntityKernelTest.php:207

Investigating...

fathershawn → created an issue.

Added an explicit test to validate that the js is properly loaded by our processes.

I also don't see anything unexpected in Gin 3.0-rc14 . Please re-open with more information about how to recreate if I'm missing something.

Cannot reproduce with Claro in D11.0.6

fathershawn → created an issue.

fathershawn → created an issue.

fathershawn → created an issue.

The pushUrl method takes a Url object or a boolean value. This is in line with https://htmx.org/attributes/hx-push-url/. To accomplish what you would like, pass the url that you are calling in https://htmx.org/attributes/hx-get/ in the call to pushUrl

I'm still not sure what Twig was calling, but there is a syntax error in your code. The proper syntax for the method to generate a push url attribute is

.pushUrl(true) or .pushUrl(someUrlObject)

I'll do some testing. I would have expected a type exception with the given Twig expression. The function signature for that method is:

  public function pushUrl(bool|Url $value) {}

I'm not clear why Twig is interpreting your string as a Url object.

fathershawn → changed the visibility of the branch 3485198-tweak-twig-dot to hidden.

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

Thanks for the extra eyes @nicxvan! I missed a variable change moving some JS over from the HTMX module → . Updated the branch.

The markup format is discussed and decided in 🌱 [policy, no patch] Choose a markup strategy for HTMX POC Fixed

I have a working POC on the Single Config Export form: https://git.drupalcode.org/issue/drupal-3446642/-/compare/11.x...3446642...

Feedback invited!

I'm not sure your requested url can be satisfied, but we may be able to make it nicer by moving page state back to a header.

That is accurate. As we find areas in which a utility or service would help, I've been adding them here in Drupal. I don't know anything about Hotwire Turbo. All of the methods of HTMX enhance and expand on these 5 capabilities:

1. Behaviors are described within the element
2. Any element can issue an HTTP request
3. Any event can trigger an HTTP request
4. Use all the “verbs” of HTTP
5. Target any element in the document for replacement by any element in the response

These enable a rich hypermedia based paradigm.

Please re-open and/or switch to a feature request if more is needed.

fathershawn → created an issue.

The module seems more low level in its goal, in that it doesn't try to progressively enhance the entire Drupal front-end, but rather to enable Ajax-like functionality for designated blocks.

The purpose of the HTMX module is two-fold:

1. Provide a set of tools to make it easy to use HTMX within Drupal.
2. To be an arena of innovation for bringing HTMX to Drupal core.

The HTMX Blocks are intended to be a usable example of developing a solution in Drupal. Both the admin interface and the blocks use HTMX. The module provides the following tools:

1. The latest version of the HTMX library as a Drupal asset library
2. The HtmxAttribute object which builds the data attributes that make HTMX work.
3. JS/CSS asset loading: the same intent as Drupal Ajax - load any CSS or JavaScript in the response that is not already on the page.
4. Render an entity in a given view mode and return the markup
5. A route option to render a simpler html response
6. Views plugins for HTMX displays and pagers

I'm excited that you are inspired to build with HTMX and interested in what you learn, especially any learning that would apply to 📌 [POC] Implementing some components of the Ajax system using HTMX Active .

fathershawn → created an issue.

Absolutely! Happy to help.

It's not possible with the provided checkout panes.

The client that this module was developed to support did not have any commerce beyond donations. After this code was released as a contributed module, donations along side the purchase of actual goods was requested by several users and I built a second checkout flow plugin to support that. However, all the plugins in this module are built to support the dedicated donation OrderItem. OrderItems are always paired with an Order in Commerce which is paired with a Checkout flow. So to support two flows, the checkout panes and the Donation order controller would all need to be configurable as to which OrderItem was expected in each flow. That's not the current state of the code.

"You will need to create extensions of the donation and memorial panes that select for your additional OrderItem type, and use those panes in the checkout flow which you configure to use this second OrderItem."

The included checkout panes, regardless of which setup is used, look for donation OrderItems. Using both checkout routes is an advanced scenario that requires having a second OrderItem type created and then coding checkout panes to look for that type. This can be done by extending the existing pane plugins but the module does not currently offer out of the box for this scenario.

If you have your site configured for Option 2 (standard checkout) as you stated in 💬 Donation checkout flow not being displayed in config Active then the /donate route isn't going to work. That's the beginning of a dedicated checkout process that only does donations.