Closed (fixed)
Project:
Admin Toolbar
Version:
8.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
14 Jun 2019 at 13:46 UTC
Updated:
26 Nov 2020 at 07:16 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
romainj commentedComment #3
oknateAnother option rather than losing those bundle items is to use Entity Toolbar. It moves those out of the admin menu into their own toolbars and loads them with ajax.
Comment #5
adriancid@romainj we will port this to the 8.x-1.x branch or the 8.x-2.x branch will go out soon?
Comment #6
oknateNote: the search feature only uses the links within the admin toolbar. So the bundles excluded by this patch will no longer appear in the search feature.
Comment #7
adriancid@oknate, in this case, we will need to use something like the code used by the module coffee? Or you have another idea in mind?
Comment #8
oknateThere are a few options. Coffee is slower because it makes an API call on every search, so I don't want to duplicate Coffee's approach. I would imagine we could have a single endpoint of extra links that would include the excluded links, and when someone first searches, it would load the additional links. Or perhaps if no result is found, it would then make the api call to load the additional links. It wouldn't be as fast, but it's a trade off. The initial page load will be faster when we don't load hundreds of bundles. I think reducing the number of bundles in the drop downs are the right way to go. I think we should create a ticket to figure out how to include links excluded in 8.x-2.x in the search.
I created the Entity Toolbar module to offload those bundle links to other toolbars, and it loads them with ajax. I think we could use a similar approach, but not display them. We could also delay the loading until either
1) someone toggles to the search toolbar
or
2) they start to type in the search textfield.
I created an issue for it.
#3062346: Restore in search feature bundles and menus removed for performance reasons
Comment #9
romainj commented@adriancid we could release the 2.x version if we do not have any major bug which is the case IMO.
Comment #10
oknateEven if there are bugs, there's no better way to find them then let a lot of people try it out. How about 8.x-2.0-beta1? Rather than straight to 8.x-2.0? That way, we can let people know that it's new and potentially buggy.
Comment #11
adriancidI think this is a good idea @oknate.
@romainj no problem, I will close this issue as we don't need to port.
If we need to discuss the next release is better to open a new issue as a Plan and then prepare the release roadmap.
Comment #12
romainj commentedok for a 8.x-2.0-beta1 version
Comment #13
adriancidIn this case, I think that now is a good moment to release the beta1. If you agree @romainj I can do it in the next hour.
Comment #14
romainj commented@adriancid let's go!
Comment #16
liquidcms commentedyes, i am sure the page load time is much longer than the time it takes to click and go to All Types (facetious), and then select the submenu item for the type i was interested in.
disappointing this got lost.
a better approach might have been to allow admins to set the depth they wanted.. so we could leave this full if we wanted.. since some of us have fast servers with fast connections and this an admin only feature anyway as users don't see this menu.
:(
tried Entity Toolbar.. and then disabled it.
Comment #17
siavash commentedThis 'Feature' makes for a terrible UX. It should at LEAST tell you it's cutting off the results with a "seem more" option that takes you the parent link or have a way to expand it. Also, MAX_BUNDLE_NUMBER should be configurable maybe?
Comment #18
romainj commented@Siavash The max number of bundle to display is now a configuration. @see https://www.drupal.org/project/admin_toolbar/issues/3094835.