Problem/Motivation

Hi, I was tempted to try out this module, but when I go ro /admin/structure/htmx-block and click on the "Add block" button, it stays grayed out and there is a 500 error in the network tab. Recent log messages doesn't show anything and the response of the network request is empty.

Steps to reproduce

  1. Pass a large amount of data to drupalSettings
  2. Requests fail when the data exceeds the maximum size allowed by server.

Possible resolutions

  1. Return to inserting, finding, and parsing the data from a JSON script tag
  2. Explore more efficient data storage in the header

Resolution

Returned to using HTMX's out-of-band swap as drupalSettings has no size limitation given that it's normal use is to be inserted as a JSON object into the DOM. Improved the the JS implementation rather than simply rolling back.

CommentFileSizeAuthor
#6 htmx_working_headers.png140.65 KBbbu23
#6 htmx_broken_headers.png1.29 MBbbu23
#5 block-add-dialog.png439.16 KBfathershawn
#3 htmx-block-add.mp44.12 MBfathershawn

Issue fork htmx-3463876

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

bbu23 created an issue. See original summary.

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Assigned: Unassigned » fathershawn

Thanks for the report. I'll verify and get a fix out or post back swiftly as it worked the last time I used it!

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Status: Active » Closed (cannot reproduce)
StatusFileSize
new htmx-block-add.mp44.12 MB

I did a fresh site build of a plain 10.2.7 site and changed my ddev setup to php 8.2 (8.2.20). With HTMX as the only contrib module, I could not reproduce the error. I've attached a video. I don't know what to suggest since your logs are empty. If this is in a built up site, could there be a conflict with another module?

bbu23’s picture

bbu23
Location 🇪🇺🇪🇺🇪🇺
commented

Hi,

Thanks for looking into this. Yes, in your video it looks nice. In this case, sure it could be some conflict with other module(s). I would suggest setting the status to "Postponed (maintainer needs more info)" instead of closing directly because others might have this issue, and for me atm it's unusable.
I will try to find out more information from debugging to share since on your end it's fine, I do have other contrib modules installed. Here's a video of what happens for now: https://www.awesomescreenshot.com/video/29945599?key=a0cd9d8c603272365a1...

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Status: Closed (cannot reproduce) » Postponed (maintainer needs more info)
StatusFileSize
new block-add-dialog.png439.16 KB

Thanks for continuing to examine this on your end for clues. Switching the status of this issue to "needs info" is the right idea too. Because HTMX is designed to work with standard HTML responses, you can copy the failing request from your network tab and load it directly as your admin user. In a working setup, the dialog tag will be present and populated. I've added a screenshot. In your case, perhaps you can get better insight into the 500 error working with the request directly.

bbu23’s picture

bbu23
Location 🇪🇺🇪🇺🇪🇺
commented
StatusFileSize
new htmx_broken_headers.png1.29 MB
new htmx_working_headers.png140.65 KB

I have more information.
So, in my project (that was originally a 9.5.* updated to 10.2.7) with all sorts of contrib modules installed vs. a project that I have for testing stuff using 10.2.7, and just a few contrib modules: the first one fails, the other one works well.

For the broken one I discovered the following errors at a higher level:

Premature end of script headers: index.php, referer: https://car.ddev.site/admin/structure/htmx-block
AH01070: Error parsing script headers, referer: https://car.ddev.site/admin/structure/htmx-block
AH01075: Error dispatching request to : , referer: https://car.ddev.site/admin/structure/htmx-block

After analysing the response in web/core/lib/Drupal/Core/EventSubscriber/FinishResponseSubscriber.php, I noticed that the broken site has a hx-trigger-after-swap header in the response that the other one does not.

Removing that header results in the dialog appearing. Now, idk why this difference, but sharing this information for now. I just hope it's not something stupid from a custom module, but I'll try to investigate further :D
Here are the screenshots of the two site responses, dump of headers:

Broken response:
Broken headers

Working response:
Working headers

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Title: "Add block" not functional » Ajax page state header can become too large
Status: Postponed (maintainer needs more info) » Active
Related issues: +#3459112: Refactor asset and behaviors management away from swap-oob

That's super helpful. Removing the header makes it work because the header size is huge. It looks like there is markup stored in drupalSettings. We may have to revert or adjust a design choice.

HTMX allows us to trigger an event via header and include data for that event. So rather than appending JSON into a script tag with new ajax page state at the bottom of the DOM and then spending time to find, load and parse it as core ajax does, we included the data in this way.

It looks like Magento has had a similar problem with cache tags:

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
bbu23’s picture

bbu23
Location 🇪🇺🇪🇺🇪🇺
commented

Oh, I see.
Well, I'm glad that this helps, and now you have the necessary info. If you need anything else, lemme know.

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Issue summary: View changes

FatherShawn opened merge request !17

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented

  • FatherShawn committed 53d5f4fb on 1.2.x 
    Issue #3463876 by FatherShawn, bbu23: Ajax page state header can become...
fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Status: Active » Needs review

@bbu23 I've tagged version 1.2.2-alpha1 with a refactor to address this issue. Would you be willing to see if it fixes your failure?

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Issue summary: View changes
fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Issue summary: View changes
bbu23’s picture

bbu23
Location 🇪🇺🇪🇺🇪🇺
commented

@FatherShawn sure, thanks. I'll try it out and let ya know. 😊

bbu23’s picture

bbu23
Location 🇪🇺🇪🇺🇪🇺
commented

The error is gone, I got the popup and added a successfully added block.
How do I load it now? Using the method here: https://project.pages.drupalcode.org/htmx/blocks/loading/ ?

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Status: Needs review » Fixed

That's great! Thanks for testing. Yes - you use the standard core block, HTMX Loader, which is placed and configured normally. When configuring it you can choose what triggers along with some other htmx attributes. The default swap behavior is that HTMX block replaces the HTMX Loader, but you can configure that too.

The HTMX block feature definitely has utility: using load as the event one could conditionally lazy load a block as one one use case. However, it principally demonstrates how a developer could use HTMX to create dynamic elements.

bbu23’s picture

bbu23
Location 🇪🇺🇪🇺🇪🇺
commented

Thanks also for fixing it!
Gotcha, I'll explore it then.👍

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented
Status: Fixed » Closed (fixed)