Rerolled the patch above to fix error with the following line "$this->addError(WATCHDOG_ERROR, $result->response->Message, $result->http_status_code);" being caused by "WATCHDOG_ERROR" doesn’t look like it was doing anything so I’ve removed it and the error message will now be the response message
Has anyone else looked into this? We're also facing this issue on the groups permission where it's extremely slow to load
I had the same issue as in #49 where we'd left devel_generate enabled on stage and disabling it fixed the issue of the dead screen upon submitting the form.
Commenting to update and confirm that the issue was indeed minified js files which didn't have the `minified: true` option set on them. After adding this to the files the issue was resolved.
I was able to figure out the issue here. The final fix was ensuring that the alpine.js and breakpoint-helpers.js files being added to wingsuit/dist/vendors, who's library definitions we had in our theme were also marked as minified. This completely resolved the slow loading issues with js aggregation turn on.
Lincoln-Batsirayi → created an issue.
Thanks @itamair! I can confirmed that this has fixed the issue! :-)
Re-uploading my patch so it includes all code, made an error on the last one
@madhaze's patch didn't quite work for me because on our project we use tailwind which can have classes such as "lg:block" and because of this the line target.querySelector(updatedSelector) was failing because it didn't recognise these classes ".lg:block" as actual classes/selectors, as a result of this i added a line to replace the colons with "\\:" as that fixes the issue. I understand this might be an edge case but it might help other's who have a similar set up.
Lincoln-Batsirayi → created an issue.
Hey @catch here are the files, I've also included a couple of network related screenshots of the file incase they have some information.
Hey @catch yes I've tried core aggregation without advagg and I'm still getting the issue. I tried the following steps you provided and here were the results:
- It's just javascript aggregates which are taking a long time to load, it's always one of the js file too
- It's always 2 js & css aggregates which are created in the folders per page load
- Looking at the contents of the file, there actually isn't much in there, from what i can tell it's some minified jquery, drupal once and drupal core js, obviously the durpal core one is the largest by far. When i cropped it out into a new file it came to about 479kb (I don't know if this typical or not). An additional note, when i compare the aggregate file from the D9 version of the page and the D10 version it's only a 20kb difference in sizes between the two files
- Yes xdebug is disabled on the environment
If you need me to share any screenshots from the network tab or the files themselves please let me know as I'm not a 100% sure what it is I'm looking for...
Hey guys, just commenting here because this sounds exactly like an issue we've been experiencing since upgrading to Drupal 10 except that it's only happening on front end pages for both logged in and anon users.
Initially when the bug was showing up, pages would take around 8 seconds on the initial load (not locally but on acquia hosted envs), and then load quickly after that. I found that this was coming from the aggregated js file. (note we were using the advagg module at this point). But then i noticed if i turned off js aggregation then pages would always load fast.
Since i and other members of our team weren't able to narrow down the issue we decided to deploy to prod without js aggregation turned on. This was okay at the start but now we've noticed that periodically when some pages load none of the js on the page works until the page is refreshed again. But reenabling js aggregation solves this BUT obviously this reintroduces the slow loading +8 seconds issue.
After some tinkering today I've noticed that both issues go away if i disable the advagg module AND the core js aggregation setting, I've not tested this on prod yet but I'm hoping that the results will be the same there.
Obviously this isn't ideal at all since js aggregation is supposed to improve performance but any tips on a better path/approach would be much appreciated!
Hey guys, i think this might be the same issue which I'm experiencing I'll tell you some of the issues I've noticed. So after upgrading one of our sites to Drupal 10 we noticed that pages were taking more than 8 seconds to load (using the network tab in dev tools) and after digging deeper into the issue i found that this was being caused by the js aggregated file. But interestingly if we turned off js aggregation then the pages would load quickly which doesn't make sense because aggregation is supposed to have the opposite effect.
Recently we saw that now there's an extra bug, if js aggregation is turned off sometimes when the page loads none of the javascript works at all until the page is refreshed, and the only way to stop this bug is to turn off js aggregation but obviously that then introduces the slow loading issue again. Does this sound at all similar to anyone else's experience?
The hook on #3 by @matthiasm11 has worked for me, a good placeholder until a more firm decision has been made on this issue.
I've tested this and confirmed it's also working for me.
Closing this because it is a duplicate of 📌 Automated Drupal 10 compatibility fixes Fixed
Lincoln-Batsirayi → created an issue.
Hi @huzooka spamspan has had a few releases since your comment above and it's D10 ready, does this mean that this patch is ready and the tests issue has been resolved? Unfortunately I've not done any work with tests so I'm not sure where I'd look and how to test them, is this something you're able to take a look at or point me to the right direction off?
As an aside, i used the upgrade status module to scan this module after applying the patch and it didn't find any issues, but I don't know if that scans the tests as well or not.