[PP-1] Local Storage for Coffee

Works like a charm.

Hi Guys,

Just wondering, when I applied this patch, I could not see the url anymore, it just the title showing. any idea why?

Thank you for the patch, legend!

Fixing localStorage error with Safari: QUOTA_EXCEEDED_ERR: DOM Exception 22

With a new patch it Needs review

6 years after the last comment I needed this feature, as I wanted to offload this request to a multisite on with not a huge amount of resources.

Overall I feel it's quite good, I added an install hook, a configuration option and small theme tweaks so that you can see if the data is cached as well as an option to refresh it. See MR !8 - https://git.drupalcode.org/project/coffee/-/merge_requests/8

We've had the patch from MR8 running for some time and is seeming good, currently applying to Drupal 10.2.7 with Coffee 8.x-1.4.
Help to performance so that the system is not unnecessarily scouring the site for all admin link options every time.
Thank you @hanoii

Awesome work in here! Thanks @joelpittet and @hanoii. Bump this to Major regarding the important improvement stated in #17 "Help to performance so that the system is not unnecessarily scouring the site for all admin link options every time."

Maybe needs a re-roll or new branch to sync MR with #3428399: Automated Drupal 11 compatibility fixes for coffee for possible upcoming Coffee Drupal 11 release.

Just (re-)discovered this in #3491405: Add performance testing.

Given that Coffee is activated by a link or keyboard shortcut, could the AJAX request not be deferred to then? If it's in local storage it should be instant, but it would help in the non-cached case and potentially also help with browser memory usage given the data structure wouldn't be loaded on most requests then.

On the approach here, I think it would make sense to key the local storage key by Drupal core version and/or $settings['deployment_identifier'] or possibly something added to Drupal settings that is based on a hash of the menus being fetched - could be written to state on menu link rebuild or similar. That would allow for a longer TTL then, or possibly even hard-coding the TTL if it's reliable enough. Core's toolbar module has similar logic to do a similar-ish thing.

Postponing this on #2233323: Implement caching mechanism and #3494208: Get coffee data only when the search box is opened - those can be done without complex complex cache invalidation logic (or cache staleness bugs), and should make this less necessary. If it's still necessary after those, then dynamic_page_cache support would allow for a short TTL here without much impact on server load.

#3494208: Get coffee data only when the search box is opened got in.

I am experiencing big performance issues when editing a node. The get-data coffee's call is blocking the loading of ckeditor for 2-3 seconds, what can I do ?

PS : I have tried updating to the 2.0 branch but it is the same

@yonailo can you confirm you're already on version 2.0.1 of coffee?

yes I have tested with 2.0.1, with drupal 10.4.5. I have maybe exaggerated the situation, there is no "big performance" issue but it is very noticeable because the ckeditor field takes a few seconds to show up... I wouldn't like to disable coffee it is really useful, but if there is no other solution... :(

#3494208: Get coffee data only when the search box is opened should have changed things so that the request isn't made until the search box is opened. If that's running all the time, something else is broken. Do you have e.g. gin_toolbar enabled?

I will try to find out, non I don't have gin_toolbar my backoffice theme is claro.
Thank you for your return anyway. I understand that the issue that you mention should only make the get-data() request when opening the search toolbar, but it is not like this in my case, weird !

I don't see any more the get-data call so i guess I have another issue, thank you.