[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