Menus: Add links to tags

[ghost]

From @Konzertheld on March 23, 2013 2:21

A typical application for a menu is to view posts by categories (aka tags). It would be helpful for less experienced users to have another button to add links to tag pages.

Copied from original issue: habari/habari#504

[ghost]

From @chrisjdavis on March 23, 2013 3:51

Not trying to be difficult, but I don't understand what it is your are asking for. Please explain further!

[ghost]

From @ringmaster on March 23, 2013 4:2

The menu admin allows users to create menu items that are one of:

1. A link to a post
2. A link to a URL
3. Some static text

To make things easier for users, there should be an additional option that allows them to produce a link to a built-in Habari page like the page that displays a listing of posts based on a tag.

[ghost]

From @Konzertheld on March 23, 2013 15:3

Exactly. You could do that by adding a link to a URL (http://yourblog.tld/tag/foo), but unexperienced users might not know that. Also, that would mean more work in case of domain changes etc.

[ghost]

From @chrismeller on March 23, 2013 15:29

I hate storing links to internal items, which then have to be updated later
on. Perhaps we could remove the blog's URL from the beginning, if that's
what the link points to, and only store a relative URL?

On Sat, Mar 23, 2013 at 11:03 AM, Konzertheld [email protected]:

Exactly. You could do that by adding a link to a URL (
http://yourblog.tld/tag/foo), but unexperienced users might not know
that. Also, that would mean more work in case of domain changes etc.

—
Reply to this email directly or view it on GitHubhttps://github.com/habari/habari/issues/504#issuecomment-15338454
.

[ghost]

From @ringmaster on March 23, 2013 16:46

The intent shouldn't be to store the explicit internal URL though, since
we can already do that.

Consider the links to posts in the menu. If you change the slug of the
post, the menus continue to work. Why? Because the menu plugin stores
the menu item for a link to a post as a specific type of menu item, and
includes the post id. When the menu is generated, the correct, current
URLs to the posts are used.

What should happen when storing a URL internal to the system is the
rewrite rule and the array of data that causes it to render correctly
should be stored in a specific kind of menu item term. In this way,
even if the rewrite rule or domain for that URL changes, the generated
URL will be correct.

It's possible to do this with a plugin that supplies a new menu type to
the menu plugin, but it seems useful enough to add this to the core menu
plugin itself. Still, I don't know what the interface for this type of
menu looks like. While it might simply provide a place to enter a tag,
it would be better if you could supply the necessary criteria to any
existing rewrite rule, thus creating a link to anything in the system.

[ghost]

From @chrismeller on March 23, 2013 17:0

If we're going to wrap up linking to a tag page, I think the UI should be
sufficiently complex that it lets you pick from a list of your vocabularies
and then lets you pick (either from a drop-down or an auto-complete,
depending on the type of vocabulary) which term to link to. This is very
complex, but I don't think anything less complex would provide any more
particular value to the user than is already possible by linking directly
to the tag URL.

On Sat, Mar 23, 2013 at 12:46 PM, Owen Winkler [email protected]:

The intent shouldn't be to store the explicit internal URL though, since
we can already do that.

Consider the links to posts in the menu. If you change the slug of the
post, the menus continue to work. Why? Because the menu plugin stores
the menu item for a link to a post as a specific type of menu item, and
includes the post id. When the menu is generated, the correct, current
URLs to the posts are used.

What should happen when storing a URL internal to the system is the
rewrite rule and the array of data that causes it to render correctly
should be stored in a specific kind of menu item term. In this way,
even if the rewrite rule or domain for that URL changes, the generated
URL will be correct.

It's possible to do this with a plugin that supplies a new menu type to
the menu plugin, but it seems useful enough to add this to the core menu
plugin itself. Still, I don't know what the interface for this type of
menu looks like. While it might simply provide a place to enter a tag,
it would be better if you could supply the necessary criteria to any
existing rewrite rule, thus creating a link to anything in the system.

—
Reply to this email directly or view it on GitHubhttps://github.com/habari/habari/issues/504#issuecomment-15340199
.

[ghost]

From @chrisjdavis on March 23, 2013 17:42

I am very much in favor if this approach. Being able to link to any URL available is a very, very desirable feature.

Sent from my iPhone

On Mar 23, 2013, at 11:46 AM, Owen Winkler [email protected] wrote:

The intent shouldn't be to store the explicit internal URL though, since
we can already do that.

Consider the links to posts in the menu. If you change the slug of the
post, the menus continue to work. Why? Because the menu plugin stores
the menu item for a link to a post as a specific type of menu item, and
includes the post id. When the menu is generated, the correct, current
URLs to the posts are used.

What should happen when storing a URL internal to the system is the
rewrite rule and the array of data that causes it to render correctly
should be stored in a specific kind of menu item term. In this way,
even if the rewrite rule or domain for that URL changes, the generated
URL will be correct.

It's possible to do this with a plugin that supplies a new menu type to
the menu plugin, but it seems useful enough to add this to the core menu
plugin itself. Still, I don't know what the interface for this type of
menu looks like. While it might simply provide a place to enter a tag,
it would be better if you could supply the necessary criteria to any
existing rewrite rule, thus creating a link to anything in the system.
—
Reply to this email directly or view it on GitHub.