I would like to use Edit with Administration Menu, which is a replacement for Toolbar. Could we either:

  • A) Add direct support for Administration Menu and/or Admin
  • B) Provide an alternative ui that does not depend on Toolbar, such as tabs or a block containing the toggle
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

haggster’s picture

Same issue. Would have been awesome!

klonos’s picture

I understand that Toolbar comes with core, but that one along with Overlay are the two modules I always disable in every setup. Now, this wouldn't be an issue if it wasn't that I too use admin_menu and I can't have that simultaneously with Toolbar. This prevents me from testing the module in my live production environments.

webchick’s picture

Haven't looked into this at all, but the content staging project is using http://drupal.org/project/iib as a generic wrapper for page-level vs. entity-level bars. Might be worth a look.

kingfisher64’s picture

Agree with eusonic. Admin menu toolbar can be turned off and admin menu kept on though.

webchick’s picture

Title: Remove Toolbar dependency » De-couple Edit module from any particular toolbar implementation
Priority: Normal » Major

Re-titling this slightly, and I actually think this is fairly major for better interoperability with various distros.

Not specifically slotting it in for a sprint yet though. Would welcome any patches.

kingfisher64’s picture

For testing help this issue could do with being addressed sooner rather than later. With alpha 4 implementing navbar the whole edit mod no longer works for me.

Anonymous’s picture

Thanks for this item! Really important.

webchick’s picture

Title: De-couple Edit module from any particular toolbar implementation » [META] As a Drupal community member, I would like to see Edit module de-coupled from any particular toolbar implementation
Project: Edit » Spark
Assigned: Unassigned » Gábor Hojtsy
Category: feature » task
Issue tags: +Spark sprint 4

Re-purposing as a meta issue, and moving to the Spark queue. Gábor will be taking a look at this this sprint.

Gábor Hojtsy’s picture

Looked at IIB module. So looks like our history is the following:

- first integrated with toolbar + shortcut module, really just the shortcut module only to place our edit/view radio buttons
- then integrated with the navbar module only to place view/edit tab-links and rename the node edit tab

So currently we are trying to tie in existing local tabs with the view/edit combo, and want to display the view/edit combo even on pages that don't have edit tabs otherwise. We are currently overriding this for only the node edit tab, not for any other pages which might have an edit tab on their own. In #1747916: Edit mode should be activated when clicking the Edit toolbar tab (was: "(selected tab) indicator does not change on View/Edit"), Everett suggests we *do not* use regular tab-links for this or at least make them more accessible. There is also only navbar module that would have an integrated experience right now with tabs and the edit module toggles, other modules display tabs with the theme at other places.

DESIGN: So if we want to go integrate this with toolbar/shortcut modules or iib, we'd need to break free of this current notion of tabs integrated with the edit toggle, or at least make up an approach that would work for multiple cases. iib/toolbar/shortcut are all independent of the local tabs for the page. So looks like to solve this nicely we should be bouncing back to design thinking about this. There is one thing as to how we want to integrate this in spark, where we can bake an interaction with navbar/iib/toolbar/shortcut whatever, but then if we want people to reuse, they would either have a somewhat or entirely different experience, or we figure out a common solution across.

TECH: As for the technology, I looked at iib, and its very simply just getting items as render arrays though a hook. (http://drupalcode.org/project/iib.git/blob/refs/heads/7.x-1.x:/iib.api.php) It does not really do any magic beyond that at this point as far as I could see. For navbar/shortcut bar, they can be worked with by going in page alter and altering the page array. They have different structured presence in the page array obviously, which means we'd need separate integration code for them based on their code. Then we still need to figure out if we should stop with these tree things to integrate with or want to work with other things. It does not seem like there are generic ways, so we'll just need to have integration code with multiple things. This will make the setup a bit complicated because (a) we cannot rely on 1 module we require, so we cannot just put in a dependency; we'll need to check at enable-time if none of our dependencies are there, or make up our own solution (like l10n_update) for the "bar problem" and (b) if for some reason multiple bar modules are installed (is that a real concern?), then our UI will show up multiple times. Think if someone uses both toolbar module and iib.

The tech problems are not really hard to solve looks like (but will have more custom glue code). However, looks like we need to follow different design paths here for different solutions or go back and figure out a common way to proceed.

Any feedback on that?

Wim Leers’s picture

I also don't see how we can have both a clean and a generic implementation. For that, we'd need some sort of Toolbar API (let us please don't do that).

I'm inclined to say that this implies we should rethink the design. But OTOH, I think it's pretty obvious that genericness is a hard requirement, yet Drupal's module dependency system leaves much to be desired in that case.

An alternative route could be to have edit_toolbar, edit_navbar, edit_iib etc. modules, which require both the Edit module plus the specific toolbar implementation it relies on. Maybe that is the best solution, for now?

Long-term, I think every "toolbarish" module should implement a certain (D8 core) hook, that allows modules such as Edit to use it for this kind of purpose. That's the only feasible way I can think of to have both genericness and not the above insane number of glue modules.

Gábor Hojtsy’s picture

Did a first run at re-integrating with the shortcut module. Now we have no requirement for either the toolbar or shortcut or navbar modules. If you have neither enabled, we throw a big red error on your pages. This should be better in the meantime (and should prove the level of custom code we need just to integrate with these two toolbar solutions). Ideas welcome as to how better integrate with other solutions, such as admin_menu, where some serious UX thinking would be required too.

Current experience if there are no toolbar modules:

EditRequireToolbar.png

Experience with Navbar module:

WithNavbar.png

Experience with toolbar/shortcut modules (note this used to be some prototype-y radio buttons but now "real link buttons"):

WithShortcut.png

(Note that for the shortcut bar integration, the shortcuts themselves still jump around, they are on the left when no edit feature is on, and and the right, when the edit buttons kick in - as said above, each experience would need its own analysis and decisions for how it should work).

I think this is better for the shortcut bar integration than it was before (with the radio buttons) AND is now compatible with two toolbar modules instead of one. The code should be a vivid demonstration as to how custom that code needs to be.

Anybody up for integrating with other toolbars? There are minimal JS adjustments required, its mostly just PHP magic.

Committing this patch now.

Wim Leers’s picture

Status: Active » Reviewed & tested by the community

Looks great :)

Only one nitpick:

+++ b/includes/toolbar.incundefined
@@ -39,10 +81,68 @@ function edit_navbar_pre_render($navbar) {
+ * API to generate common toggle links for different toolbars.

s/API/Public method/

?

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Fixed that in fact as "Builds a render array for common toggle links for different toolbars.". Committed.

webchick’s picture

Awesome!!! Thanks a ton!

klonos’s picture

So, just to be clear here: we went with introducing an API (sort of) so that various toolbar modules can easily integrate the buttons required to use the edit.module. Right?

Also, since my initial concern is to be able to use Edit with admin_menu, has anyone filed an issue in that module's queue to provide this sort of integration with Edit?

Gábor Hojtsy’s picture

@klonos: right, as per http://drupal.org/files/re-integrate-with-shortcut.patch above, we introduced edit_toggle_links() as an API function to get the render array for the items we need to toggle the functionality. The CSS selectors in JS and CSS we have are using the markup resulting from this render array and are independent of the containing wrappers I believe. The JS changes did include specific selectors for toolbar and navbar, so depending on the wrapper for the admin_menu, we might need some more changes there for admin_menu. I don't know of any issues people opened to integrate with admin_menu, but we are open to any code suggestions :)

klonos’s picture

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

added A) and B)