[wp-trac] [WordPress Trac] #37974: Add multi-panel feature to pages through add_theme_support
WordPress Trac
noreply at wordpress.org
Thu Oct 13 01:07:07 UTC 2016
#37974: Add multi-panel feature to pages through add_theme_support
-----------------------------------------+------------------
Reporter: karmatosed | Owner:
Type: task (blessed) | Status: new
Priority: normal | Milestone: 4.7
Component: Themes | Version:
Severity: normal | Resolution:
Keywords: has-ux-feedback needs-patch | Focuses: ui
-----------------------------------------+------------------
Comment (by pento):
Replying to [comment:129 folletto]:
> As far as I know, rel=canonical alone is one of the ways to deal with
that as an alternative when the page can't redirect (think of parametrized
pages where query parameters can shuffle for the same results).
Redirects are also a valid way of dealing with this. :-)
> I'm not even sure that a page that pulls partial content from other
pages is considered duplication. I'm sure duplication acts when the same
page is replicated (see the examples [https://moz.com/learn/seo/duplicate-
content here]), I'm less sure when a piece of it is present across
multiple pages, otherwise... sidebars and footers wouldn't be duplicated
content as well no?
Tag/category pages are considered duplicate content, so I'm assuming that
this is the same, just in the other direction - the single page is a
duplicate of the aggregate page.
> Keeping the page, would allow theme authors to have simple setups where
a page can show title and excerpt in home, and then link to the same page.
Yup, I can see that being a potential use case. Though, then we have to
look at the menu UI - how do we distinguish linking to the section on the
front page, versus linking to the page?
> And maybe even users would be surprised the page used in the homepage
now disappeared entirely? How do we clarify that behaviour?
I'm okay with a little bit of user surprise, as long as the outcome makes
sense, and the behaviour is consistent after that.
> > But if a section of the front page is removed from the front page
(remaining as a standalone page), the link from the menu will
automatically direct to the standalone page, instead of the front page.
>
> This automation seems a bit of an edge case to me: a menu that leads
somewhere else is likely very distinct, both design and code wise, from an
in-page menu.
I agree that this example in an edge case, it wasn't a particularly good
example. :-)
How about this: when you're initially setting up the feature, and decide
to add `/about/` as a section to your front page - do you want the menu to
continue to send visitors to `/about/`, or to `/#about`?
If we figure out how to make this work on all themes, isn't it better to
always direct to `/#about`, even when changing themes, effectively making
`/#about` the new canonical URI?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/37974#comment:130>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list