Please contribute in 📌 Automated Drupal 11 compatibility fixes for geshifilter Needs work for this.
Applied the bot's patch to the issue fork - not sure why it didn't do that - and expanded version constraints to allow core ^11.
ambient.impact → made their first commit to this issue’s fork.
ambient.impact → created an issue.
2.x should not have this issue since we don't replace the main content block any longer.
ambient.impact → created an issue.
ambient.impact → created an issue.
ambient.impact → created an issue.
Dear Drupal.org please refresh the cache for this kthx.
ambient.impact → created an issue.
Added Media Library items.
Added tabledrag.js item and marked tableselect.js more or less fixed.
This has finally been merged. Only lingering issue is to figure out if we can delay Turbo caching asynchronously like we can with rendering, but we can do that separately and it can be worked around in the meantime.
Added media grid table select item.
ambient.impact → created an issue.
ambient.impact → created an issue.
Set contextual and core Navigation as completed.
Completed dropbutton and table select.
Added dropbutton and table select.
Sat down and had another look at this. Turns out the initial load was still breaking the BigPipe JavaScript because doesn't handle being in the <head> and with the defer attribute well, most likely because it needs to be render blocking and kick in as early as possible.
With that figured out, I tried to exclude it from the <head> + defer, but that broke because it needs Drupal.ajax, which was still being output to the <head> with the defer attribute. At that point, I didn't want to mess with the dependency tree because the library handling is already kind of janky and gives me a headache.
So my next thought was to make a more fundamental change: since our <head> + defer is primarily for RefreshLess requests, why not just let JS be output to the footer without the defer attribute alterations on non-RefreshLess loads, i.e. the initial load. Shockingly, this completely fixed it and BigPipe's JS works as intended on the initial load, and doesn't interfere on subsequent RefreshLess loads. Because nothing in my life ever seems to be easy, my excitement was short lived, as it only works correctly with aggregation off: my clever solution seems to break assets and doesn't load most on an initial load if aggregation is enabled.
Also note that this causes JavascriptAlterTest to fail, but that can probably be fixed by mocking up the current request in setUp() with the RefreshLess header so that our request wrapper indicates this is a RefreshLess request and alterations are performed.
I've created a second branch in the issue fork for these changes in case they're not usable at all: 3519784-bigpipe-compatibility-assets. I'll get back to this at some point or someone else can finish this.
Irrelevant issue linked whoops.
ambient.impact → created an issue.
ambient.impact → created an issue.
I think I have it working by decorating BigPipeStrategy in the issue branch. Will let this sit for a bit so I can test it more thoroughly another day.
ambient.impact → changed the visibility of the branch 3519784-bigpipe-compatibility-routing to hidden.
Reworked and expanded proposed solutions.
Spent the week on this because I discovered that preloading links into Turbo's cache can be a big performance boost in a lot of cases, and that requires caching to actually work. After a lot of trial and error and quite a lot of swearing, I got it to more or less working, but I'll have to test it over the following days to see if it's robust enough to merge.
Awesome. Thanks!
I created three merge requests, one for each of the currently supported branches. Not sure if there was a better way to do that, but there ya go. Also used Drupal core's constant that they added as part of that change record so we don't even have to know what the limit is, so if they ever decide to change it, Hux just uses the new limit.
ambient.impact → changed the visibility of the branch 3472641-wrong-module-name-limit to hidden.
ambient.impact → made their first commit to this issue’s fork.
@iseeaflyingcrane I think you need to include the @. This works for me to send to the current user:
{{ @user.current_user_context:current_user.mail.value }}
See also #2849810: Data processors do not check type before performing type-specific operations → .
Yup, setting the language fixed it for me as well!
Created a new branch that just adds preprocess: false to the loadjs library. Direct link to commit patch for use with Composer.
ambient.impact → changed the visibility of the branch 10.1.x to hidden.
ambient.impact → changed the visibility of the branch 11.x to hidden.
@catch Would stripping 'use strict' be a good idea, though? I'd rather my JS doesn't become less strict when aggregation is enabled, i.e. in production. Am I misunderstanding your comment?
Not sure if this is out of scope for this issue, but what I'd love to see is an option to not just set the link content to the entity's label when it's inserted, but also have it update if I later change the title of the linked entity. A use case for this would be to have a a custom list of nodes in some other content as sort of an overview page, without having to create a view. In that case, it would be less maintenance to not have to remember to update the displayed links elsewhere that they're linked.
ambient.impact → created an issue.
Closing as outdated as 2.x may work better with this. If you're still seeing this issue with 2.x, feel free to re-open.
Closing as outdated because the 2.x releases should not have this problem.
Closing as outdated; please try the 2.x branch which is a complete rewrite and shouldn't have this issue.
Closing as outdated; 2.x branch does not have this problem.
Closing as outdated because 2.x supports this; see my comment: #2861128-3: Disable Refreshless for all child links of a designated element. → .
Closing as outdated. 2.x handles this correctly and as expected.
Closing as outdated. 2.x should handle pagers quite well.
Whoops.
Closing as outdated. See the extensive list of events in 2.x, some of which allow cancelling or delaying.
Closing as outdated. The 2.x branch now does this in the listed cases and others. See the refreshless:reload event documentation.
Closing as outdated because the 2.x releases navigate to error pages correctly.
Closing as outdated because this is included in the 2.x releases: data-turbo="false" can be added to links, buttons, or entire containers, and data-turbo="true" can be added to re-enable on specific links, buttons, and descendants; see Turbo attributes documentation. I'm also planning on adding more info about this to our documentation when time permits.
Also note that we have a refreshless:click event that can be cancelled on a case by case basis.
Closing as outdated. Please see the 2.x releases which now apply to the admin section and for all users - including authenticated users.
I'm going to close this as outdated but feel free to re-open if you're still having issues. A ton of work has gone into 2.x and we now have a fairly robust basic implementation in our alpha releases.
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.