WordPress.org

Make WordPress Core

Opened 15 months ago

Closed 12 months ago

Last modified 11 months ago

#23347 closed enhancement (fixed)

Theme fallbacks for post format meta data

Reported by: helen Owned by:
Milestone: 3.6 Priority: normal
Severity: normal Version:
Component: Post Formats Keywords: has-patch commit
Focuses: Cc:

Description

If a theme doesn't declare support for a format, we should have output fallbacks available for hooking onto the_content using nice semantic HTML.

IRC reference: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-31&sort=asc#m544599

Attachments (14)

23347.diff (6.9 KB) - added by wonderboymusic 15 months ago.
23347.2.diff (7.5 KB) - added by wonderboymusic 15 months ago.
23347.3.diff (7.1 KB) - added by beaulebens 14 months ago.
23347.4.diff (6.9 KB) - added by beaulebens 14 months ago.
Removed the chat fallback entirely, until we can decide what to do with it. Also bailed earlier in the function for aside/status formats.
23347.5.diff (6.4 KB) - added by helen 14 months ago.
23347.6.diff (6.5 KB) - added by helen 14 months ago.
23347.newline.diff (812 bytes) - added by SergeyBiryukov 14 months ago.
23347.8.diff (1.2 KB) - added by nacin 14 months ago.
Implements structured-post-formats theme support.
23347.7.diff (892 bytes) - added by helen 14 months ago.
23347.9.diff (1.3 KB) - added by helen 14 months ago.
23347.10.diff (1.1 KB) - added by obenland 13 months ago.
23347.11.diff (913 bytes) - added by obenland 13 months ago.
23347.12.diff (513 bytes) - added by wonderboymusic 12 months ago.
23347.13.diff (523 bytes) - added by wonderboymusic 12 months ago.

Download all attachments as: .zip

Change History (76)

comment:1 sabreuse15 months ago

  • Cc sabreuse added

comment:2 beaulebens15 months ago

  • Cc beau@… added

comment:3 beaulebens15 months ago

Apologies, it's long :)

Goals/Constraints

  • Minimal markup/design/layout
  • Maximum (correct) semantics
  • If we can't do something valid, at least don't do something explicitly invalid
  • Use all data elements from the UI (below)
  • Present them in the "most expected/obvious" way
  • Take into account "normal" CSS applied to HTML tags
  • Must be backwards (pre-HTML5) compatible, and forwards (HTML5+) compatible
  • Informed by Best Practices and Common Usage, erring towards Best Practices

Post Formats Data Fields/UI -- note I made up meta key names to demonstrate consistency, those are not final

Standard (current post editor)

post_title
post_content

Status: http://cl.ly/image/170O1N0L062U/o

post_content

Quote: http://cl.ly/image/1V0h3O211K2T/o

post_content (Quote)
meta: _format_source
meta: _format_commentary (?)

Aside: http://cl.ly/image/3v3T3b3L2s1o/o

post_content

Link: http://cl.ly/image/2l213j3i2625/o

meta: _format_url
post_title
post_content (Description)

Chat: http://cl.ly/image/3Y2n0N153x3g/o

post_title
post_content (Transcript)

Image: http://cl.ly/image/2X0S2u2f053c/o

post_title
post_content (Caption)
meta: _format_url

Video: http://cl.ly/image/3J2v2v0j0o37/o

post_title
post_content (Description)
meta: _format_url

Audio: http://cl.ly/image/2a0c0y3z3v3i/o

post_title
post_content (Description)
meta: _format_url

Gallery: http://cl.ly/image/032J3l2w1t10/o

post_title
post_content (Description)

Post Formats Default HTML Output

Standard

Title

{$post_title}

Content

{$post_content}

Status + Aside (identical treatment)

Title

(empty string)

Content

{$post_content}

Discussion

We don't ask the user for a title, so we shouldn't display one, but we *should* generate one based on the first x characters/words of the post_content, for use in wp-admin. When rendering, don't rely on a comparison (in case content changes); check format which is instructive on how to handle the title.

Quote

Title

(empty string)

Content

<div class="format-quote-quotation">
	<blockquote cite="{$url}">{$post_content}</blockquote>
	<div class="format-quote-source">{$_format_source}</div>
</div> . "\n\n"
{$_format_commentary}

Discussion

Blockquotes are basically a semantic disaster :) There does not appear to be a currently-agreed-upon solution which is compatible with HTML<5 and which handles sourcing a quote that is anything other than just a URL. <cite> is used commonly, but it presents a number of problems, specifically around the changes from pre HTML5 into HTML5. In short, we can't use it reliably without creating invalid markup somewhere. Since we don't ask for a title, don't output one. Generate one for the admin (based on the quote/post_content). The above recommendation is based on common usage patterns, combined with accurate-as-possible semantic usage, plus a desire to have information visually accessible without special CSS allowances. The source/citation is outside the <blockquote> because the HTML5 spec explicitly states "Attribution for the quotation, if any, must be placed outside the blockquote element.". If we put the citation inside the <blockquote>, it'd increase "compatibility" with existing CSS (positioning, styling etc). In this case we would extract the first URL (if available) from post_content and use that in the cite="" attrib (could also be stored in _format_url?). Note that it's totally fine for $post_content to contain other block-level elements. Note the recommended method in the HTML5 spec is now to use a figure > blockquote + figcaption grouping for citation. See also http://alistapart.com/blog/post/more-thoughts-about-blockquotes-than-are-strictly-required and http://html5doctor.com/blockquote-q-cite/

Link

Title

{$post_title}

Content

{$post_content} . "\n\n"
<p class="format-link-url"><a href="{$_format_url}">{$post_title}</a></p>

Discussion

Content, linked title in a new paragraph after that. I opted to append rather than prepend the link to post_content, since most themes display post_title before the content, so in that case you'd end up with the post_title effectively duplicated. I think most themes that choose to handle this themselves will make the link on the post_title (main/biggest link) go to the external URL.

Chat

Title

{$post_title}

Content Alternative 1

<dl class="format-chat-transcript">
	<dt>timestamp/name</dt>
	<dd>message</dd>

	<dt>timestamp/name</dt>
	<dd>message</dd>

	...
</dl>

Content Alternative 2

<ol class="format-chat-transcript">
	<li><strong>timestamp/name</strong>: <span class="format-chat-message">message</span></li>
	<li><strong>timestamp/name</strong>: <span class="format-chat-message">message</span></li>
	<li><strong>timestamp/name</strong>: <span class="format-chat-message">message</span></li>
	...
</ol>

Content Alternative 3

<div class="format-chat-transcript">
	<div>
		<strong>timestamp/name</strong>: <span class="format-chat-message">message</span>
	</div>
	<div>
		<strong>timestamp/name</strong>: <span class="format-chat-message">message</span>
	</div>
	<div>
		<strong>timestamp/name</strong>: <span class="format-chat-message">message</span>
	</div>
	...
</div>

Discussion

Using the <dl> keeps the pairs of data related in a nice semantic way, although will probably be less-likely to have appropriate CSS applied, since <dl> will often have a <dt>, then the <dd> on a new line, indented. Using an <ol> gives us things on one line, but by default is also going to be numbered. The HTML5 spec uses both Alternative 1 and 2 as possibilities for marking up a "conversation" (http://www.w3.org/html/wg/drafts/html/master/common-idioms.html#conversations). Trying to get some default CSS in there seems to defeat the purpose a little. Alternative 3 is the only one I can see that will keep things together, force each line of conversation to a new line, and give us full CSS flexibility. In 2 and 3 we could drop the <span> if we don't think it's worth including. I put it there to provide more CSS formatting hooks. All of above assume that we can come up with a reasonabe parsing algorithm for chat transcripts. If we can't, then 2 and 3 can just split post_content based on linebreaks, and otherwise I suggest we use a trimmed version of the Quote format.

Image

Title

{$post_title}

Content

<div class="wp-caption format-image-img">
	<img src="{$_format_url}" alt="{$post_title}" height="" width="" border="0" />
	<div class="wp-caption-text">{$post_content}</div>
</div>

Discussion

Re-using roughly what we already do for images inserted with captions, and adding a standardized class in there for targeting (maybe redundant, since you'll have the post_class?). Wrapping post_content in a div since it's likely to be auto-p'd, so don't want to wrap it in a <p> (which is what current captions do). <figure> and <figcaption> are unfortunately out because they are HTML5 only. See also http://www.cs.tut.fi/~jkorpela/www/captions.html (and some of the links at the end)

Video

Title

{$post_title}

Content

[video src="{$_format_url}"] . "\n\n"
{$post_content}

Discussion

Assuming http://core.trac.wordpress.org/ticket/23282 happens. We're going to need a native player if we're giving a direct URL for the media item. If we get a URL for a media *page* from the user, then we should put it on a line of its own and let oEmbed handle it. post_content just goes directly below that.

Audio

Title

{$post_title}

Content

[audio src="{$_format_url}"] . "\n\n"
{$post_content}

Discussion

Assuming http://core.trac.wordpress.org/ticket/23282 happens. We're going to need a native player if we're giving a direct URL for the media item. If we get a URL for a media *page* from the user, then we should put it on a line of its own and let oEmbed handle it. post_content just goes directly below that.

Gallery

Title

{$post_title}

Content

[gallery] . "\n\n"
{$post_content}

Discussion

If we're just uploading a bunch of images against a post, then we can just drop in a [gallery] shortcode and let it do its thing. Below the gallery, we can insert the post_content (gives the media priority over the text).

Further Discussion

No titles

Might be the only navigation element to permalink pages in some themes

Native media players

Can we do them? Will they be good? If we can then they can handle audio/video

Standardized Postmeta

Need to figure out the standardized postmeta fields so that we can provide some test data. We can just use the Custom Fields UI to fill them for testing.

Test Content/Plugin

Should get some quick test content that covers each post format and export it into a WXR file so that theme developers can see what happens with their themes. Needs a quick and dirty plugin that applies the above default HTML based on post format.

comment:4 johnbillion15 months ago

  • Type changed from defect (bug) to enhancement

Are you working on this Beau? If not I'd like to volunteer to knock up the first version in plugin form along with a WXR.

comment:5 follow-up: johnbillion15 months ago

The markup for the image format isn't quite correct.

<div class="wp-caption format-image-img">
	<img src="{$_format_url}" alt="{$post_title}" height="" width="" border="0" />
	<div class="wp-caption-text">{$post_content}</div>
</div>

should be:

<div class="wp-caption format-image-img">
	<a href="{$_format_url}">
		<img src="{$featured_image_url}" alt="{$post_title}" height="" width="" border="0" />
	</a>
	<div class="wp-caption-text">{$post_content}</div>
</div>

with a bit of logic to only add the link if a URL has been entered.

comment:6 in reply to: ↑ 5 beaulebens15 months ago

Replying to johnbillion:

The markup for the image format isn't quite correct.
...

Thanks for the (accurate) correction johnbillion; definitely need that <a> in there.

I haven't started on a plugin or test data, so if you'd like to handle those bits, that'd be excellent. LMK if you'd like a hand with any of it.

comment:7 beaulebens15 months ago

I realized I missed a field in the Quote format, with all the mess around it :)

In the latest mocks, there are the following fields:

  • Quote (the actual quote)
  • Who said (source name)
  • Where did they say this? (source URL? I think?)
  • Comment (my commentary on the quote)

If we formalize the "Where did they say this" to be "URL to source" and only allow a URL (which is what I think we should do), then we can use that directly in the cite="" attribute on the <blockquote>.

<div class="format-quote-quotation">
	<blockquote cite="{$_format_url}">{$post_content}</blockquote>
	<div class="format-quote-source"><a href="{$_format_url}">{$_format_source}</a></div>
</div> . "\n\n"
{$_format_commentary}

(change is $url => $_format_url, to use the standardized meta field, and wrap the _format_source in a link to _format_url, since the cite attribute isn't actually exposed in most (any?) user agents)

If the "Who said" field is indeed the name of a person, then HTML5 dictates we cannot use the <cite> tag around it. If it was the name of a "text" (document, script, some body of work) then we could wrap it in a <cite>. Annoyingly, pre-HTML5 it would have been fine to wrap whatever was entered in this field with <cite>, which would have given nice clean markup.

comment:8 helen15 months ago

For quote source URL, let's assume it's a shared URL field with things like the link format, and I think image as well. Not sure what to think about the semantics of the markup. Dangit, cite.

For the image, do we imagine that the data could be an attachment ID as well as a URL? I was sort of thinking it could, but not sure. Audio and video are similarly flexible inputs - could be an oEmbed URL, a shortcode (hoping for a bundled player), or copy-pasted HTML embed markup. I don't think it really makes much of a different in practice for audio/video compat output, but thought I'd note it.

For the chat format, I'm not convinced/sold on doing anything to it markup-wise at all.

comment:9 mercime15 months ago

  • Cc mercijavier@… added

comment:10 follow-up: helen15 months ago

Linked on Make/Core about the quote format: http://synapticism.com/working-with-wordpress-post-formats-and-quotations/

For the record, I'm just a personal crankmonster about the chat format. If it's just splitting up lines and applying some markup that can be styled, then that's just fine. :) Would say that it might not be good to use default markup that could potentially look extremely different from paragraphs, though. Maybe in that way we need to think about how a theme could define what the marked-up output is.

comment:11 greenshady15 months ago

  • Cc justin@… added

comment:13 in reply to: ↑ 10 beaulebens15 months ago

Replying to helen:

Linked on Make/Core about the quote format: http://synapticism.com/working-with-wordpress-post-formats-and-quotations/

While I like this approach for HTML5 (minus the date, personally I think that's overkill); unfortunately it doesn't translate too well to <HTML5. We could maybe just take the general structure of it and instead of the <footer> and <article>, use <div>s still.

comment:14 wonderboymusic15 months ago

  • Keywords has-patch added

Attached is an initial run - can be tweaked obvs but lays the groundwork. Audio / Video still have hard dependency on #23282 which works, still needs tires kicked.

In my attached patch, I did not go crazy with wrapper divs a la Beau, they can be added at will, as can more filters. Everything works great in 2011 theme, minus the status which adds 65px margin-bottom to the entry content, and the audio / video shortcodes just get output on the page raw.

wonderboymusic15 months ago

comment:15 helen15 months ago

Quick testing notes:

  • Image compat = awesome!
  • Audio/video media field compat doesn't do oEmbed. Could also use detection to make sure whatever's provided is not already in the content.
  • Chat has some tricky things - what if the person uses paragraphs (two new lines) instead of line breaks (single new line) to separate lines of the chat? We lose the paragraphs here and get <span><br /></span> kind of stuff. The break tags shouldn't be inside the spans in any case. Also, even/odd classes are probably a good idea here.
  • Quote puts URL as the source, probably just a sprintf accident. Also could use de-dupe detection.

comment:16 rachelbaker15 months ago

  • Cc rachelbaker added

comment:17 wonderboymusic15 months ago

attached new patch, fixed(?) oEmbed by wrapping URL in [embed]

Introduces, get_post_format_meta() which will return an associative array of "key minus the _wp_format_ part" => $value

wonderboymusic15 months ago

beaulebens14 months ago

comment:18 beaulebens14 months ago

23347.3 makes a few modifications/additions to .2:

  • Tries to detect "duplicate" content; where the user has already entered the format-specific data within the_content, but has also filled out the specific fields. In this case we always trust the user to have entered what they want to appear in the_content
  • Adds a check after the main switch in post_formats_compat so that if no $format_content has been created, then we return $content without modifying it (adding tags/classes); basically only modifying things when we explicitly have something to offer
  • Uses stristr rather than preg_match for the image check, since if the URL is there at all, let's just assume the user knows what they're doing
  • Beefs up the gallery detection, which was previously only checking the first shortcode encountered. Now checks all shortcodes and bails if any of them are a gallery.

get_post_format_meta() has been moved to #19570, so I'm leaving it out of this diff.

beaulebens14 months ago

Removed the chat fallback entirely, until we can decide what to do with it. Also bailed earlier in the function for aside/status formats.

helen14 months ago

comment:19 helen14 months ago

23347.5.diff continues on from .4:

  • Made the compat wrapper class generic - thinking CSS should look like .chat .post-format-content rather than .chat-post-format-content. post_class() gives that to us, and a filter is included should a theme author really want to do something to it.
  • Compat wrapper is only wrapped around the compat output itself, not around the entirety of the content + compat output. There was some funkiness happening because of that, and it doesn't make much sense the other way around.
  • Removed audio/video shortcodes for now, because it's useless without #23282. If we get #23282 done, we can restore it.
  • As noted for .4, chat is removed because it just wasn't working well and we want to get this in soon. Iteration welcome :)

Thing I noticed, not sure if we need to address now or not: using the embed shortcode in the fallback for audio/video means that if the user enters something funky like "http://blah.com and some more stuff" it esc_url()s the whole thing and makes it a link in WP_Embed::maybe_make_link(). It happens if you do it in the content too, so maybe it's something to make better in maybe_make_link(), or it's fine because that would be a weird thing to do, anyway.

comment:20 aaroncampbell14 months ago

$compat['class'] needs esc_attr(), and $compat['tag'] should probably do something similar (maybe even a whitelist of tag names?)

Other than that, this looks ready for a first pass commit to me.

comment:21 aaroncampbell14 months ago

Actually, it looks like $compat['tag'] just needs to use tag_escape()

helen14 months ago

comment:22 helen14 months ago

In 23450:

Output fallbacks / theme compat for post format metadata.

  • Currently handles link, quote, image, gallery, audio, and video formats.
  • add_theme_support() for a given post format is now an indicator that the theme handles format-specific metadata.
  • If no support for a given format is defined, fallback output will be generated and hooked onto the_content if a post has metadata for that format.
  • Fallbacks attempt to be smart about not duplicating data already appearing in the post content itself. Gallery is particularly liberal, looking for any instance of the gallery shortcode in the content, not just an exact match to the gallery shortcode defined in the format-specific meta.
  • Compat output defaults to being wrapped in a div with a class of post-format-content.

Theme authors: please test and evaluate, keeping in mind that the goal is to support user expectations of not losing format-specific data they've entered in the admin when viewing the front-end of their site.

props wonderboymusic, beaulebens, helen. see #23347.

comment:23 greenshady14 months ago

Pulling this conversation from #19570 since it belongs in this ticket.

Replying to helen:

Replying to greenshady:

Support for post formats for several versions has meant something different. It simply meant that a theme supports post formats in some way. Now, this meaning is being changed to say that a theme handles specific metadata too.

I don't know if it's "too" so much as "instead". The UI for all formats shows now no matter theme support, rather than having the theme determine the UI (all of some radio buttons before). This is in line with our goal of providing something that users can rely on to be consistent. I don't know how we can move forward unless we make at least some kind of break from the previous paradigm. Hoping that theme compat can address as many situations as possible to build trust with users and yet not disrupt everything for theme authors. Again, relying on those who build themes regularly, especially public release ones, to really help us shape this piece.

The theme compat and UI stuff are great. That's not the big issue. We need a solution for existing themes that currently expect post format data to be stored in $post->post_content. That's where it's always been. So, we need solutions for:

  • Themes that don't support post formats.
  • Themes that support post formats and the new metadata.
  • Themes that support post formats and aren't using the new metadata.

The work thus far has focused on the first two items. We need to also focus on the third.

My proposal is that we make the theme support call look something like the following.

add_theme_support( 'post-formats', array( 'aside', 'gallery' ), array( 'compat' => false ) );

The compat argument:

  • If true (default), would add the theme compat layer. Basically, it adds everything where it's expected (the post content).
  • If false, would remove the theme compat layer. This would allow themes to explicitly say that they will use the new metadata and don't need WP to handle it.

This will be a good solution for two reasons:

  • Users will be able to use the new post format data with existing themes that support post formats.
  • New themes can simply allow WP to handle how the data is output if they choose this route.

comment:24 kwight14 months ago

  • Cc kwight@… added

comment:25 nacin14 months ago

The Different Situations

Three theme situations:

  1. Theme doesn't support post formats
  2. Theme supports old-style post formats
  3. Theme supports new-style "structured" post formats

A — Three fallback situations:

  1. Theme does not support a format, but the post has new-style "structured" post format data
    • Fallback: Turn new-style structured data into HTML and use the_content filter
  2. Theme supports a format (old-style), but the post has new-style "structured" post format data
    • Fallback: Turn new-style structured data into HTML and use the_content filter
  3. Theme supports a format (new-style), but the post has old-style unstructured post content
    • Fallback: Parse out post_content into individual pieces of post format data. (This needs to occur, because this theme wouldn't necessarily have a call to the_content() for all post formats, would it?)

B — Three situations where do not 'fall back':

  1. Theme does not support a post format, and the post has old-style unstructured post content
  2. The theme supports a format (old-style), and the post has old-style unstructured post content
  3. Theme supports a format (new-style), and the post has new-style post format data

To reorganize these content situations based on the individual theme situations: (someone can turn this into a flowchart if they'd like)

  1. Theme doesn't support a post format:
    • The post has new-style "structured" post format data. Fallback: Turn it into HTML, use the_content.
    • The post has old-style post content: Do nothing.
  2. Theme supports a post format, old-style:
    • The post has new-style post format data: Fallback: Turn it into HTML, use the_content.
    • The post has old-style post content: Do nothing.
  3. The theme supports a post format, new-style:
    • The post has new-style post-format data: Do nothing.
    • The post has old-style post content: Fallback: Parse post_content into pieces of post format data.

Old versus New Formats

It is clear here that a theme not supporting a format is pretty much the same as supporting old-style formats. This is even more apparently now that we will be allowing a user to use any formats they wish, even if the theme does not support it, so the old-style "support" becomes pretty close to meaningless.

Also, since each format is individually supported or not supported, you could have many of these situations occurring on the same site, without a teme switch:

  • A theme supports the quote format, with new-style structured data (B3)
  • The site also has chat posts written with metadata (A1 — must convert these into HTML)
  • The site has link formats without metadata (B1 — show these as-is)
  • It also has old-style quotes (A3 — must parse these into pieces)

Or:

  • A theme supports the quote format, old-style (B2)
  • The site has quote formats written with metadata (A2 — must convert these into HTML)
  • The site has chat posts written with metadata (A1 — must convert these into HTML)
  • The site has chat posts written without metadata (B1)

Theme Support

It is probably apparent by now that we need to know when a theme supports a new-style format in particular. Whether the theme supports an old-style format in only has to do with whether the theme has a particular design for that format, and isn't very helpful anymore.

To make this change, I suggest we come up with a new theme support argument. Specifically, structured-post-formats:

add_theme_support( 'structured-post-formats', array( 'quote' ) );

This would replace post-formats support. It is a trivial change, but would be necessary because themes would have to make bigger changes anyway — specifically, switch to new template tags to support the new-style metadata.

Under the hood, we could automatically register support for post-formats when structured-post-formats is registered. Then you can have checks like current_theme_supports( 'post-formats' ) && ! current_theme_supports( 'structured-post-formats' ) to see if a theme supports post formats generally, but not the newer structured ones. (Note that I would prevent in code the ability for a theme to say "Yes I support these formats" with some being old-style, others being new-style. As said above, there is no purpose for this — in terms of working with content, supporting old-style is the same as not having the format supported at all. So it is best to avoid such an API rift.)

Compatibility Across WordPress Versions

If a theme wishes to remain compatible with 3.5 while still supporting 3.6 methods, they'll need to do a few things. (I would recommend doing this for Twenty Ten and Twenty Eleven, and leaving Twenty Twelve for 3.6+ only, to set different examples and to keep 3.6 clean. Supporting forward for an older theme is important; supporting backward for a newer theme is not.)

  1. They'd need to call add_theme_support() for both post-formats and structured-post-formats. The former would get ignored in 3.6, the latter would get ignored in 3.5.
  1. They'd need to function_exists( 'get_post_format_meta' ) before using the new-style functions. In their else, they'd use the_content() as before.

Feeds

One final note, everything goes out the window when dealing with an RSS feed. Everything needs to be piped back into the_content(). is_feed() does not appear to be accounted for in [23450].

comment:26 SergeyBiryukov14 months ago

Noticed a couple of PHP_EOL references in [23450]:
http://core.trac.wordpress.org/browser/trunk/wp-includes/formatting.php?rev=23450#L1959

We don't use that constant anywhere else in core. Could it be just "\n" for better readability (23347.newline.diff)?

Last edited 14 months ago by SergeyBiryukov (previous) (diff)

comment:27 wonderboymusic14 months ago

Related #23570 - the functions introduced there can exist without any knowledge of fallbacks

comment:28 helen14 months ago

  • Component changed from Template to Post Formats

comment:29 lancewillett14 months ago

  • Cc lancewillett added

nacin14 months ago

Implements structured-post-formats theme support.

helen14 months ago

comment:30 helen14 months ago

In 23467:

Implement theme support for structured-post-formats, which will supercede theme support for post-formats. Usage is the same as declaring support for post-formats: add_theme_support( 'structured-post-formats', array( 'quote', 'video' ) ). Adding structured-post-formats support also adds post-formats support for the given format(s) underneath.

Declaring support for a given format indicates that the theme handles format-specific metadata; admin UI will not change based on theme-declared support of either variety as it did previously. If no structured-post-formats support is explicitly declared for a format, a post in that format will have fallback output utilizing that metadata applied. In this way, a theme can style core-provided output for a full post format experience without having to handle metadata in any way.

props nacin. see #23347.

comment:31 helen14 months ago

In 23468:

Post formats compat output:

  • Check for theme support of structured-post-formats rather than post-formats.
  • Use \n instead of PHP_EOL constant.
  • Add new lines after opening compat wrapper tag for some wpautop() treatment.

props SergeyBiryukov. see #23347.

comment:32 Otto4214 months ago

The new post_formats_compat function seems to be doing something stupid. It was automatically adding a [gallery] to the end of posts with the gallery post format for me, even though those posts already contained a gallery (after a !--more-- tag).

Note that the theme in question does declare support for the gallery format like so:

add_theme_support( 'post-formats', array( 'aside', 'audio', 'chat', 'gallery', 'image', 'link', 'quote', 'status', 'video' ) );

I think that post_formats_compat needs to be done away with, or altered, or somehow modified to not be changing existing content already being produced by sites and themes.

This code currently breaks existing sites in major ways, and should be considered a blocker.

comment:33 helen14 months ago

It's supposed to be smart about not duplicating things that are found in the existing content - I imagine there's something going wrong that needs fixing. I don't know what's "blocking" about it, as this is definitely work in progress. There's a whole other side we're still tackling (new theme, old data). See http://make.wordpress.org/core/2013/02/22/post-formats-ui-update-221/

comment:34 Otto4214 months ago

It's a blocker in that it breaks existing content on existing sites. Changing pre-existing site content, in any way, is a regression and thus a blocker.

Fallback output should be eliminated entirely. IMO. You can make it smarter all you like, but the moment somebody's actual site content changes from an upgrade, then the upgrade is instantly "broken", capable of "breaking people's sites", and roundly hailed as yet-another-failure of the WordPress development team.

I would suggest reverting this entirely and marking as wontfix, unless you can correct it such that it does not change displayed content on existing sites. If you want to handle new-sites with old-themes, that's fine, but you can't just flat out break pre-existing sites willy-nilly like this.

comment:35 Otto4214 months ago

Note, this can be as simple as having a flag somewhere to not add the post_formats_compat filter function to the content on upgraded sites, thus only allowing it to apply to new sites.

comment:36 wonderboymusic14 months ago

(Otto is mostly right,) it's because the full picture of how this is gonna work is not in core yet, and there has been no iteration really since the initial commit, and not against a defined set of test cases. Let's discuss the battery of related tickets in dev chat today and a plan for not breaking anything

comment:37 wonderboymusic14 months ago

Scenarios

  1. If the post doesn't have a post format or the theme supports structured-post-formats, nothing should happen to content
  2. If you don't support structured-post-formats and you don't have gallery, audio, or video metadata, we are currently adding the shortcode to the_content() - you said "it's audio!", didn't opt in to structured, and have no meta, you are getting a new shortcode when:
    • you have no audio-like URL, embed, or shortcode in your content,
    • but you DID attach audio to your post.

So the main question here: should we add shortcodes for attached media (post_parent is the current post) when nothing in the content or meta is present? Otto says no. I personally hate the idea that media can only have one post_parent as is, so I lean towards no when there is no meta and nothing explicitly looking like gallery|audio|video or a URL in the content.

comment:38 wonderboymusic14 months ago

Now, let's open our hymnals to the Codex: http://codex.wordpress.org/Post_Formats

video - A single video. The first <video /> tag or object/embed in the post content could be considered the video. Alternatively, if the post consists only of a URL, that will be the video URL. May also contain the video as an attachment to the post, if video support is enabled on the blog (like via a plugin).

"May also contain the video as an attachment to the post" - what do we do here? Have people been following these rules? Should they have been? Does it matter?

comment:39 Otto4214 months ago

For the case of brand new websites running themes without structured-post-formats but with normal-post-formats, I'm okay with post_formats_compat(), although it does need some minor improvements.

The specific problem I encountered was basically because it's only examining the input $content data, which doesn't get the complete content in the case of a !--more-- tag situation (and probably will have the same issue with !--nextpage--). For it to work properly, post_formats_compat() needs to examine the entire post. It can do this by looking at the $post->post_content directly instead and that would fix the immediate issue. Minor change to the preg_match_all on line 371 would probably do the job.

For the case of older websites, I'd rather it not do anything at all, or even have that filter be connected. Many people with existing sites won't be happy to upgrade and notice posts looking different, even if we think they may be "better". Set an option on upgrade to prevent that filter from attaching and it's fine. This isn't without precedent, look at the Links menu in 3.5.

No opinion on audio/video as yet, however it's not unfeasible that some people have used the video format and then been posting something like youtube links in the post and such. Making any assumptions here about what the old-post should contain is probably ill-advised.

comment:40 helen14 months ago

On an old site with old data, what this currently should do is a whole lot of nothing. Seems like it was the gallery shortcode default that made that a false statement, so removing the default shortcodes from compat (just gallery right now) is probably a good idea. We shouldn't make that kind of assumption about content. Fixing the matching to look against the entirety of the post content is also a good idea, anyway, assuming that's also broken.

comment:41 helen14 months ago

Okay, I think I see the issue - the compat fallback doesn't take more/excerpted content into account, both in terms of matching and display. It'll put the compat output after the more link by default, which is definitely bad. I think we'll need to output the compat stuff (noting that it should only show with old themes and new data right now) regardless of the presence of more/nextpage by default, but we need to place it better as a default.

helen14 months ago

comment:42 helen14 months ago

In 23499:

Remove default content from post format compat output. We shouldn't magically create content for display not specified by the user, especially given that the current compat is handling the case of new data, old theme. see #23347.

comment:43 SergeyBiryukov14 months ago

In 23655:

Pass the post ID to the_title filter in post_formats_compat(). see #23347.

comment:44 helen13 months ago

In 23753:

Remove separate meta fields for image and gallery post formats. These are proving to be more confusing and labor-intensive from both a user and dev perspective than entering into the regular content editor. We will rely on good content parsing instead. See #19570, #23347.

obenland13 months ago

comment:45 lancewillett13 months ago

.10 patch has better default quote markup.

comment:46 markjaquith13 months ago

In 23822:

Better default quote markup for post format fallbacks.

props obenland. see #23347

obenland13 months ago

comment:47 obenland13 months ago

I'm sorry, my previous patch introduced a bug :( Fixed in .11.

comment:48 aaroncampbell13 months ago

  • Keywords commit added

comment:49 obenland13 months ago

.11 was fixed in r23847

comment:50 aaroncampbell13 months ago

  • Keywords commit removed

Thanks. There's been a LOT of movement here and I fear I'm losing track a bit. What's still needed for this ticket?

comment:51 helen13 months ago

I think we need to fix what happens with appended content when there's a more tag present, and probably also paging (haven't actually tested the latter). Right now things that are positioned afterward will come after the more link on an archive.

Also, looking at it - seems like the filter on the defaults array gets ignored for some of the values for the link case?

comment:52 danielbachhuber13 months ago

FYI - r23655 was nooped in r23773 and causes error notices when using the_title filter

comment:53 SergeyBiryukov13 months ago

In 23924:

Pass the post ID to the_title filter in post_formats_compat(). props danielbachhuber. see #23347.

comment:54 follow-up: wonderboymusic13 months ago

  • Keywords close added; has-patch removed

Are there still issues here? seems like we *might* be able to use new tickets?

comment:55 in reply to: ↑ 54 helen13 months ago

Replying to wonderboymusic:

Are there still issues here? seems like we *might* be able to use new tickets?

See my last comment. Fine with opening new tickets, but the second part is a question. :)

wonderboymusic12 months ago

comment:56 follow-up: wonderboymusic12 months ago

  • Keywords has-patch commit added; close removed

23347.12.diff​ respects $compat vals - 2013 will need to filter if they want link to come before content

comment:57 in reply to: ↑ 56 lancewillett12 months ago

Replying to wonderboymusic:

23347.12.diff​ respects $compat vals - 2013 will need to filter if they want link to come before content

Should be fine, in Twenty Thirteen we use the link URL on the title of the post.

wonderboymusic12 months ago

comment:58 wonderboymusic12 months ago

.13.diff refreshed against latest master

comment:59 helen12 months ago

In 24075:

Respect $compat values for the link format fallback output. props wonderboymusic. see #23347.

comment:60 wonderboymusic12 months ago

  • Resolution set to fixed
  • Status changed from new to closed

New tix

comment:61 markjaquith11 months ago

In 24386:

Revert [23467]. Removes structured-post-format theme support.

see #23347, #24452. closes #24453.

comment:62 markjaquith11 months ago

In 24387:

Revert [23450]. Removes post format compat.

see #23347, #24452. closes #24454.

Note: See TracTickets for help on using tickets.