Closed (outdated)
Project:
Drupal core
Version:
8.9.x-dev
Component:
base system
Priority:
Normal
Category:
Feature request
Assigned:
Issue tags:
Reporter:
Created:
19 Jan 2011 at 16:01 UTC
Updated:
14 Jul 2021 at 10:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
eclipsegc commentedquick patch
Comment #2
eclipsegc commentedAdded a comment as to why we're using cache_menu per sun's instructions.
Comment #3
sunExceeds 80 chars.
Powered by Dreditor.
Comment #4
eclipsegc commentedsorry for the code style issue
Comment #5
catchI'm usually all for adding caching usually, but I wouldn't expect implementations of this function to do more than return some very small arrays. Is there a contrib module doing something evil that makes this expensive?
Comment #6
eclipsegc commentednot necessarily but I was discussing adding the ability to create admin_paths through page_manager with merlin and he had mentioned that could start getting expensive without some caching. ksenzee and sun both didn't seem to have issues with adding caching there, so I just went ahead and did it so that I could add the functionality I wanted to page_manager w/o objection. It seems a pretty obvious thing to add caching to since as you add more modules it WILL get bigger, so I just went ahead and did it.
Hopefully that explains where I'm going and why.
Comment #7
David_Rothstein commentedI think this will cause some issues as described by @ksenzee's comment in http://drupal.org/node/669510#comment-3750808. (Though I think we already have other reasons why a menu rebuild might be needed when switching settings on the Appearance page.)
I'd also be interested in benchmarks; like @catch says this doesn't seem expensive? I'd expect path_is_admin(), which calls this, to be a bit more expensive (since it does all sorts of regular expression matching on the results), but still probably not that bad.
Comment #8
catchOK page manager would presumably need to go look up path definitions or similar to figure out if they're admin paths or not, I can see that getting expensive. This won't do any particular harm if you don't have such a module installed, and the cache is maintained by existing menu cache maintenance anyway, so no objections from me.
Comment #10
eclipsegc commentedOK, per David's issue in #7, the patch failed, I think this one should pass: There doesn't appear to be a more elegant way to clear just the cached item we're looking for, so we're clearing the entire menu cache.
Comment #11
eclipsegc commentedComment #12
David_Rothstein commentedYup, the patch in #10 looks like it fixes the bug I was worried about in #7. It is good that we already have a test that caught that :)
Comment #13
sunLet's prefix this bin with
path_, please. This is working off path.inc, so it should be in the path namespace.Flushing the entire menu cache seems like lots of overhead here - it should be sufficient to do
Powered by Dreditor.
Comment #14
eclipsegc commentedper sun's requests
Comment #15
sunThanks!
Comment #16
dries commentedAre we confident this is faster?
Comment #17
eclipsegc commentedDries,
The point here is a little less the immediate benefit of any speed (whether there is or not, I can't say) and more an effort to make sure we don't loose whatever speed currently have to other modules.
In the case of page_manager I actually need to parse through every page_manager page and find out if it's intending on being an administrative path. For the moment, page_manager's the only module I KNOW of that is needing this, and we could certainly put the caching into page_manager instead, but my fear was the fact that this gets called on every page load, so if any module complicates this hook in the slightest, we could lose a lot of performance.
Bottom line, I'm trying to prevent future problems, not solve current ones.
Thanks!
Eclipse
Comment #18
eclipsegc commentedIs this going to happen? or should individual modules be expected to provide their own caching mechanism for hook_admin_paths? Just needing a final word one way or another.
Thx
Comment #19
plachDuplicate issue: #896570: Add db caching to path_get_admin_paths().
Comment #20
moshe weitzman commentedSorry, we have way way too much caching in our app already. This patch is a good example of the problem. It proposes to add a cache in case a contrib/custom module does something slow. Thats not core's problem. Slow modules should implement own cache. Caches add a lot of DX headache and expiration/invalidation subtleties.
-1 from me.
Comment #21
dawehnerComment #22
dries commentedI'm with Moshe on this. I'm not sure this is needed in core. I don't understand why this is set to 'major' either. I'm going to postpone this issue until we have more reasons to believe this is required in core.
Comment #23
eclipsegc commentedAnd I've got an issue in place to add this sort of caching for page_manager specific admin pages. Sorry if this has side-tracked time, but there was some discrepancy in irc as to whether this was useful or not. Also, sorry I don't recall marking this "major".
Comment #24
damien tournoud commentedI'm -1 here as well. The menu system not do caching on behalf of the implemented modules, we should not do that either here.
Comment #25
jibranSo is it a won't fix after -1 form @moshe weitzman, @Dries and @Damien Tournoud
Comment #26
nod_Overlay is dead to D8 #2088121: Remove Overlay.
Comment #27
sunI wondered whether hook_admin_paths() isn't obsolete, but found out that path_is_admin() is still being used for the administrative theme switching and some other stuff.
However, in D8, the hook should be renamed to hook_admin_route() (route vs. path), and ideally, routes should be flagged directly in the route definitions already. In turn, the basic (non-altered) information would be "cached" (compiled), as originally proposed here.
Existing issue: #1316692: Convert hook_admin_paths() into declarative properties on routes
Comment #28
moshe weitzman commentedFYI - #2058845: Pre-load non-admin routes. Its does the opposite of caching admin paths.
Comment #37
longwavehook_admin_paths is long gone: https://www.drupal.org/node/2224207