[wp-trac] [WordPress Trac] #37974: Add multi-panel feature to pages through add_theme_support

[WordPress Trac]

#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:125 bradyvercher]:
 > I can update those to use the slug, but that leaves a few things that
 need to be worked out:
 >
 > 1. Is there an alternative to using the hash?

 Hash is ugly, but it's a pretty common solution on sites that have a
 single page with multiple sections.

 An alternative might be, if you visit `/about/`, instead of redirecting to
 `/#about`, it loads the front page template and some JS scrolls to the
 `about` section. It'd probably need a `rel=canonical` link to the actual
 front page in the header, though.

 > 2. Should we update the separator that's used for page hierarchy? For
 example, the page URI for a child would currently be `parent-page/child-
 page`. Do we replace the slash with a dash or underscore instead? The HTML
 4 spec doesn't appear to allow slashes in the `id` attribute, while HTML 5
 does.
 > 3. If the separator is updated, to what extent should we go to ensure
 the fragments are unique to prevent collisions?

 We can replace `/` with `.`. It's allowed by HTML4, but
 `sanitize_title_with_dashes()` removes it from slugs. That will keep it
 unique.

 > 4. How should themes ensure the anchor is present on the page? A new
 template tag?

 We'd probably need to figure out a way to insert our own elements with the
 correct ID, I'd like to think about doing it without a new template tag,
 so that old themes can more easily support it.

 Also, there's an interesting case when the slug is renamed: When `/about/`
 becomes `/about-us/`, WordPress will redirect from the old slug to the new
 slug. If the visit `/#about`, it won't know about `/#about-us`, unless we
 insert anchors for every slug the page has had.

 > > What are plans for indicating that X pages are the fragments that make
 up Y page on the pages list table?
 >
 > I'm all ears if anyone has any ideas on this front.

 I'll play around with some ideas today.

 > > Does this have to hinge on theme support?
 >
 > I think it would be a poor experience for users to try to use the
 feature in a theme that doesn't support it. At the very least, themes need
 to make sure the anchor for each section matches the fragment core
 generates. Themes may also need to register a container selector for
 selective refresh to work unless we can inject a temporary container in
 the Customizer preview using `loop_start` and `loop_end`.

 I think we can do it without requiring themes support. I'll do some
 experimenting. :-)

 Replying to [comment:124 folletto]:
 > It seems we are going in the direction of redirecting page URLs to
 anchors, but I can see only reasons to not do that (one being the point 2
 of your questions above for example).
 >
 > Can you explain the rationale behind that direction?

 Sorry, Davide. I meant to reply to your earlier comment on this, but I got
 lost in all the ticket updates. :-)

 My primary concern about this is duplicate content on the site, which
 search engines tend to frown upon. Much like we redirect when slugs are
 renamed, it seems like the correct behaviour is to redirect to a
 "canonical" source.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37974#comment:126>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform