Added Mink and Ajax testing links.
I created a new branch in the issue fork to try fixing the cron ordering as suggested by @megachriz but I can't get it to work, so I've pushed what I have so far because I need to go work on other stuff but maybe someone else can take it from here to get it working.
ambient.impact → made their first commit to this issue’s fork.
It would be awesome to have a well defined way to define variants of image styles in core so contrib no longer needs to hack around this problem as is often the case. I think @heddn has the right idea, in that a single image style could generate multiple formats (or variants? Naming is hard) as opposed to the current limitation of a single image.
ambient.impact → created an issue.
@mrweiner I know it's contrib and I would love it to go into core, but I don't feel like that's a downside - a lot of really awesome and super useful things are implemented in contrib, prove their worth there, and are adopted into core. The biggest benefit in using Typed Entity (in my opinion) is that you now have a clean separation of your data (entities, their fields) and the logic that allows you to interact with it (the wrapped entity plug-ins), which leads to more testable code and hopefully away from spaghetti code.
@berdir That's also a good point that entities are serialized/deserialized a lot which adds even more potential headaches.
ambient.impact → created an issue.
I used to think DI on entities was a good idea and even implemented a way to do it via overriding the storage class, but I've honestly completely come around to the Typed Entity module approach of using a (very clever) way of wrapping entities; see #26 ( #2142515-26: Provide a method of DI for entities → ). I over-engineered a solution to use DI on node entities, and it turned into a maintenance nightmare on multiple occasions, until I'd had enough and moved all that code to entity wrappers.
Here's the big problem with adding DI to entities: entities are already complex, and this just loads more complexity into them, making them more tedious to test, mock up, etc.
I know the thought of having to add an additional step every time you act on an entity to wrap it may seem annoying - and it certainly held me back for a while - but the benefits end up far outweighing that by allowing you to mock up and test parts of the logic without baking it directly into entity classes. If you want to see a concrete example (and one I'm very proud of), here's an absolutely massive merge request from last year where I did such a refactor to replace overloaded entity class logic with entity wrappers.
@kopeboy: Yup, the PWA module → provides a service worker sub-module. There are still a bunch of issues and things that can be improved, but it should work for basic offline stuff.
Updating the issue title and summary to reflect to the current state of the implementation. I've had a chance to work on the issue fork, and it seems it mostly works now if we detach behaviours on the turbo:before-cache event but there are still some remaining issues:
turbo:before-cacheis not currently able to be delayed until a page has transitioned out, so if a behaviour detaching causes visible changes to the page, these will be briely seen before a transition out has begun; there are potential solutions to this:- TBD; coffee shop closing back later lolol
- The core Navigation is even more broken due to lacking detach callbacks for most of its JavaScript; this is fixable by adding detach callbacks, but will take some time and untangling of its spaghetti JavaScript; see 🌱 Turbo: Tracking issue of core and contrib behaviours that need fixes to correctly detach and then attach Active
Awesome. Thanks!
ambient.impact → created an issue.
ambient.impact → created an issue.
Added failure states list item.
I just wanted to jump in and say that comment #31 ( #3404409-31: [Plan] Gradually replace Drupal's AJAX system with HTMX → ) is a phenomenal summary and argument for why Drupal should fully embrace the HTMX approach and not compromise on that philosophy. 👏
I die a little on the inside every time someone throws their hands up and wants to reimplement Drupal's front- and/or back-end using a purely front-end JavaScript framework, demoting Drupal to just a fancy JSON endpoint. We don't need to throw out the Cache API, Twig templates, all the security and reliability of rendering on the server, to fix the admitted UX problems associated with vanilla server rendered navigation.
If it's page transitions and partial page updates you're after, use HTMX, Hotwire Turbo, or Unpoly. (See the RefreshLess module → .) If it's that the server feels too slow, proper use of the Cache API can help a lot, but you can also implement a Service Worker to intercept and respond instantly while it sends requests to the server in the background. This is a solved engineering problem that works completely with server-rendered HTML.
Marking CSS specificity item partially complete.
🐛 Fix mismatch of $base_url with Symfony request object Needs work may be related to this, or at least an adjacent issue.
Yikes. Reminds of when
the Hux module →
started out and discovered there were a few modules that were type hinting to the ModuleHandler class instead of ModuleHandlerInterface like they should have. I'm thinking we should expand the scope of this issue to fix any other instances in the module where we're type hinting to classes rather than interfaces. What do you all say?
Finally had a chance to try this out and it seems to work well. Awesome work! Is it just ConfigSingleExportForm so far, or are there other forms or interactions that have been switched over?
Updated summary to reflect that we now have core patching in CI.
Marking 🐛 Turbo: Drupal messages are lost if Turbo does a full reload Active item as completed.
Updated the status of a bunch of items and rewrote a few things to reflect current state of various fixes.
I've created a new branch (3414538-what-if-attachments-processor) in the issue fork to try and implement a decorated attachments processor, but I can't yet get it to work. The main motivation here is to no longer rely on ajaxPageState because outputting it on every page results in certain generated URLs that have a query string (e.g. pager, admin/config compact toggle link, etc.) also including the Ajax page state in their URL, which in turn causes some weird behaviour with those links where Turbo doesn't kick in during history back/forward navigation, in addition to looking messy and ugly.
There's something I'm not understanding and not doing correctly with the library diffing, and without a clear indicator of what libraries are being added and when, it's hard to pin down. I think this would need some kind of debugging output when libraries are added to hopefully spot what's going wrong, but I'm tired and need to do other stuff right now.
Marking as fixed as a result of patching Turbo.
Added item for 🌱 Turbo: Tracking issue of core and contrib behaviours that need fixes to correctly detach and then attach Active .
ambient.impact → created an issue.
🤔🤔🤔 🐛 Logic error in Drupal's lazy load for asset aggregation Active will definitely be helpful for this. Will have to experiment with 10.4 when I get a chance.
I have mixed feelings about the stale file threshold: I can see it being useful for some smaller sites and it would be nice to have cache clears not wipe out aggregates, but on the other hand, I feel like it's treating a symptom and not the root cause; the root cause usually being that it's the tool someone reaches for when they don't know how to use update hooks, the Cache API (tag invalidation, etc.), or the appropriate service to clear/rebuild a specific thing they need. That's specifically why I created the Rebuilder module → , which can rebuild just aggregated assets among several other things.
ambient.impact → created an issue.
I'm very interested in seeing how this works out because making aggregation work - especially for JavaScript - was a nightmare for RefreshLess 2.x: 🐛 Turbo: JS aggregation causes the RefreshLess JavaScript to evaluate more and more times on navigation Active
This particular improvement might be less relevant to that project since it was more the additive part that had to be implemented, but anything core can do to make the library system even more predictable would be awesome.
Also, this makes me wonder if we get core to provide a list of all possible aggregates given the known dependency trees, could we then use that as part of a post-deploy process to proactively/preemptively build all those aggregates? That would be awesome from a performance point of view.
ambient.impact → created an issue.
After some significant work and testing, I think I've basically fixed FOUC under most circumstances.
Initial port works quite well. Setting to postponed for refining using ideas from NProgress.
Thanks! Also, I just discovered that a more thorough visible/hidden check was added to core at some point so I've updated the merge request to use that.
I recreated the change on 11.x, but since I can't edit MR !10210 (and I'm tired), I created a new one. Can someone close MR !10210 for me?
ambient.impact → created an issue.
ambient.impact → created an issue.
ambient.impact → created an issue.
My original implementation of dark mode toggling was primarily CSS using @media (prefers-color-scheme: dark) {}, which not only would have avoided having to store anything by default, but also removed the additional problems with having to check storage with JavaScript, i.e. no chance of brief flashes of light mode unless you used an inline script which is a problem with CSP, etc. See
#3161904-27: Auto Darkmode option →
for my concerns at the time.
That's what I get for having the tab open with the form state saved. 🤦
Right you are. Thanks!
Also fixed some typos in my summary.
An alternative if you don't want to install Ultimate Cron just to disable Warmer cron is the Hux module → 's ability to replace a hook implementation like we did on Omnipedia.
I can confirm that I'm also seeing this problem where a class that only uses ReplaceOriginalHook didn't get discovered no matter how many container rebuilds or full cache clears I tried, and I thought I was losing my mind until it dawned on me to search the issue queue. I can also confirm that adding a #[Hook('...')] to the class does seem to cause it to be discovered.
There's a module for that: https://www.drupal.org/project/image_style_warmer →
Added screenshots.
ambient.impact → created an issue.
Added videos.
Added screenshots.
ambient.impact → created an issue.
Ah, I see I'm not the only one that was utterly confused by the cryptic "LoadJS" error. It turns out the library did this to keep the size down, which I personally feel was a bad move because it's so confusing and non-helpful. I opened a pull request to change it, but since they still want to keep the size down, they're only willing to throw the bundle ID as the error message rather than a fully descriptive thing that says why it was thrown. Glad to see this is being handled on the Drupal side.
Not to dunk on the author of that even more, but I'm in agreement with @fathershawn, and would also highlight:
An attractive future direction might be to re-implement Htmx in React:
- The server sends a JSON blob that React converts into virtual DOM
components.
...which baffles me because it sounds like this person doesn't understand the core philosophy behind htmx and similar approaches. Sending a JSON blob for React to convert into a virtual DOM has nothing to do with htmx, and it's in fact entirely antithetical to htmx as I understand it.
Even after applying the patch from the merge request and clearing caches, I'm still getting the fatal error. Is there a step I'm forgetting to get this to work?
Added Turbo to HTMX guide link.
It's worth taking a quick look at Turbo, if only to get a sense of what we would have to recreate with HTMX. I did a bit of poking around the HTMX docs just now and realized they have a guide for migrating from Hotwire Turbo, so that'll be handy.
@fathershawn Most of that I'm aware of. I think the biggest challenge in implementing the current functionality in HTMX is that we'll have to re-implement a lot of stuff that Hotwire Turbo does out of the box, but building on your module will help get there a bit faster when I (or someone reading this?) have the time and energy for it.
My impression is that HTMX seems to more of a low level toolkit that you build with - would you say that's accurate?
ambient.impact → created an issue.
If someone is willing to implement it in a robust and reliable way, I'd be happy to review and merge it. I can see the value of it, but my time and energy are limited right now so it's not a priority for me.
ambient.impact → created an issue.
I took a quick look but Pinto seems to require more set up than I would like. I feel that it's missing what I love about Hux: I can just install Hux, drop one or more classes into src/Hooks with concise PHP attributes, and it automagically works. I don't know enough about the inner workings of Drupal's theme system, so maybe that's just not currently possible, but I feel like Hux has the winning formula from a DX perspective.
Doing a bit of research on this and came across the Preprocess module → , which seems pretty straightforward to use until core or someone else comes up with a better solution. It's not quite as elegant as Hux, but it's not terrible either.
Moved 📌 Turbo: Drastically simplify installation for end users Active to postponed as immediate goal is achieved.
We still need a proper build process as detailed in the issue summary but the commits above are good enough for now and accomplish the immediate goal.
Moved 🌱 Turbo: Tracking issue of core and contrib behaviours that need fixes to correctly detach and then attach Active to ongoing from blocking.
Marked the core/misc/announce.js item as complete.
Added 📌 Turbo: Drastically simplify installation for end users Active to blocking issues.
ambient.impact → created an issue.
Removed 📌 Turbo: Configuration and form for toggling Turbo features Active as it's not really relevant to a minimum viable implementation right now, though might be done down the road.
ambient.impact → created an issue.
Added 🐛 Turbo: Drupal messages are lost if Turbo does a full reload Active .
Removed 🐛 Turbo: Remove behaviours from Drupal.behaviors when Turbo removes their Active from issue summary.
Added postponed issues and ongoing issues lists, and moved linked issues where appropriate.
Removed some lingering old stuff that's no longer relevant.
Significant restructure of issue summary; moved the old stuff to a section at the end as archived notes.
Going to close this as won't fix because there's no realistic way we could do this without breaking various things.
Moved 📌 Turbo: Automated tests Active to non-blocking.
Added item for Drupal\refreshless_turbo\Value\RefreshlessRequest.
Added list item for page cache request policy.
Removed session item (not actually true) and added page cache request policy item.