Use menu system more heavily

[ewinslow]

There are several places I can think to do this that would make Elgg that much more extensible:

• Page header buttons
• Entity "metadata" list (elgg-list-metadata)
• Etc.

Unless I'm missing something, this would at the same time simplify things and make them more powerful.

[cash]

Should be easy to change the page links over to the new menu system. The entity metadata would not work with the menu system because the menu code does not support non-links (such as the entity access).

[ewinslow]

Is it worth trying to find a workaround for that case? That seems like a frustrating coincidence that is preventing the menu from behaving as it should. If there's a like button there, I am confident that people are going to want to be able to easily add a dislike button and it would be best if it worked the same way as every other menu. And in fact, in our implementation, that output/access is an action that allows you to change the access_id on the fly.

Here are all the menus I can think of:

• topbar (main)
• topbar (alternate)
• footer (main)
• footer (alternate)
• page (main context sensitive menu)
• page actions (buttons at the upper right of a page)
• page links (for things like rss, bookmark this, etc.)
• site (for jumping to different kinds of content).
• content filter (I've seen lots of screenshots of people extending this -- we should definitely make it easy by using the menu system).
• owner_block (used on group pages -- anywhere else?)
• user_hover
• entity metadata (visibility, like, reply, comment, etc.)
• entity river menu(comment, like this)
• longtext input menu? (toggle editor, embed, could want others?)
• breadcrumbs (but doesn't really count since it uses it's own functions)

Did I miss any?

[cash]

owner block is also used when viewing a user's content when that user is not you (if that makes sense).

If we wanted to extend the menu class, we could replace getLink() with getContent() and add a parameter to specify a non-link. Then getContent() would not wrap non-links in an <a> tag.

For the footer, there are 3 menus: footer menu, footer links, footer links alternate.

[ewinslow]

So I notice menus support "sections". Should we just take advantage of these, rather than providing 3 different menus for the footer?

[ewinslow]

I guess the question is really: at what point do we use a different section vs a different menu entirely?

[cash]

The two links sections (for both topbar and footer) make sense as sections in a menu. I wouldn't combine the footer menu with footer links. They are serving different purposes (in a similar way of page menu and page links).

[ewinslow]

Actually, for the topbar, I'd prefer if we kept them as separate menus, so we'd have topbar and topbar_links. This just gives more flexibility when theming

[cash]

Well, we would need better names than topbar and topbar_links as they are really just parts of the same menu. Maybe topbar and topbar_alt

[ewinslow]

Sounds good to me

[ewinslow]

(In [svn:8473]) Refs #2895: Made topbar into 2 menus. CSS will have to be fixed

[ewinslow]

(In [svn:8474]) Refs #2895: Converted page_links into a menu. Bookmarks now uses it

[ewinslow]

(In [svn:8475]) Refs #2895: Messages now uses new topbar menu

[ewinslow]

(In [svn:8476]) Refs #2895: Converted topbar to one menu (felt dirty using two). Fixed styles.

[ewinslow]

(In [svn:8480]) Refs #2895: Added support for an "alt" section in the footer menu. Put "powered by Elgg" badge in here

[ewinslow]

Forgive me for being difficult, but what's the point of a footer_links menu? Seems like it would get crowded?

[ewinslow]

(In [svn:8481]) Refs #2895: Removed footer/links view. Moved report-this link into alternate footer menu

[ewinslow]

(In [svn:8487]) Refs #2895: .elgg-list-metadata => .elgg-menu-metadata. Still not using menu system yet, though

[ewinslow]

(In [svn:8508]) Refs #2895: Renamed "page_links" to "extras" -- feels more semantic (facebook's menu has actions such as unfriend, share, block)

[ewinslow]

(In [svn:8527]) Refs #2895: Converted content filter to a menu, duplicated styles to mimic tabs... ick.

[ewinslow]

(In [svn:8530]) Refs #2895: Content header now emits a "title" menu

[ewinslow]

So far we have:

• topbar (default/alt sections)
• footer (default/alt sections)
• page
• title (was page actions) -- buttons at the upper right of a page
• extras (was page links) -- for things like rss, bookmark this, etc.
• site
• filter (some plugins hardcode overrides; only available on "content" pages)
• user_hover
• metadata
• breadcrumbs
• owner_block

Todo:

• entity river menu(comment, like this)
• longtext input menu? (toggle editor, embed, could want others?)

These were actually really easy to convert to menus, all thanks to cash for making such a great system!

[ewinslow]

(In [svn:8532]) Refs #2895: River items now emit a "river" menu. Not confident on the name, just trying to keep things short and sweet.

[ewinslow]

(In [svn:8533]) Refs #2538: Cleaned up custom tinymce code into elgg.tinymce.*.
Refs #2895: TinyMCE makes use of longtext menu

[ewinslow]

(In [svn:8534]) Fixes #2895: Embed uses longtext menu -- I believe that covers *all* the menus we had brought up!

[cash]

(In [svn:8566]) Refs #2895 reverting [svn:8532] as code is not working as intended. Can comment and like everything because menu items are being registered. Perhaps questionable benefit of using the menu system here.

[ewinslow]

People are going to want to add a dislike button and a share button and a vote button etc. The benefit is clear to me, I just botched the implementation because it needs to use the plugin hook rather than the registration functions.

[cash]

I needed a working implementation for some other code I'm working on.

Should we find a way to reuse the metadata menu? The original design came from elgg.com (sort of tabby interface with options vertical on the right).

[cash]

(In [svn:8607]) Fixes #2895 river menu reimplemented using plugin hook

[cash]

(In [svn:8622]) Refs #2895 entity menu uses new menu system