Microformats 2 Rendering

[dshanske]

@snarfed, @pfefferle and I were discussing the problem of various plugin interoperability in pfefferle/SemPress#51

It occurred to me, if we are going to set this up, this repo is probably the better place to keep the discussion and possibly any functionality or such we want to support it.

Right now, Micropub takes over rendering if add_theme_support( 'microformats2' ) is not set. This plugin loads microformats2 compatibility functions(add h-entry, etc) if the same flag is set.

So, the add theme support flag should, in future, be used solely to discuss a theme's support for marking up standard WordPress elements, as opposed to properties stored solely in meta. We can be more granular in future if needed.

Rendering microformats2 properties from Post Meta probably requires a global variable(the same way that add_theme_support, register_post_type, etc are in reality global variables).

The issue that was being discussed was priority on any given feature. WordPress registration does this with the last one to register, as registration is done by hook. Same can apply here.

While I still think we can combine our rendering efforts, for now, I want to try to build this as a class here in Microformats 2, which could then be included in the other plugins. Thoughts?

[pfefferle]

thanks for summing this up!

[snarfed]

hey, great! happy to talk wherever. and expanding to also include wordpress element markup sounds fine too.

i do still think we need to support priority, though. the micropub plugin, for example, needs to be able to render all mf2 properties that it handles, but it also should defer to any other feature-specific plugin that handles an individual mf2 property, since those plugins will generally be better.

i think we also need this coordination to work regardless of which specific plugins are installed. SemPress users, for example, often won't have this uf2 plugin, but should still be able to use micropub and other feature-specific plugins together happily.

given all that, the global variable approach seems to have two flaws:

• no priority support.
• no obvious single place to actually create the global variable(s). we could make all plugins create it (them) if necessary, but that seems error prone at best.

i'm not excited about the feature approach described in pfefferle/SemPress#51 (comment) either. it requires all plugins that use it to check and use the filter return value correctly. still, it may be the least bad option we have so far...?

[dshanske]

@snarfed That's why I suggested this repo as the 'canonical' place for any microformats2 in wordpress discussion. The lack of single place to discuss things.

This is really where plugin dependencies would help a great deal, but saying that doesn't help with this. But why can't SemPress users, Micropub users, and Post Kinds users be encouraged to install this plugin, especially if it doesn't activate the extra features if the theme says it already supports them?

I'm worried about not only creating confusion for us, but for new people(who already find it confusing). I don't think there is an easy answer, but what we have now isn't working exactly.

[pfefferle]

My idea:

I agree with @snarfed, every plugin should handle it's properties, the best it can.

The main other authority for the rendering is the theme, so I would start defining the add_theme_support( 'microformats2-rendering', array( 'mf2_photo', 'mf2_name' ) ); discussed here: pfefferle/SemPress#51 (comment)

If a plugin like indie-post-kinds want to overwrite micropub functionality, it should be done individually be remove actions or filters or with changes done by filters and actions.

[dshanske]

I might not want to. @snarfed's rendering could be nicer than mine.

Why 'mf2_photo' as opposed to 'photo' ?

[pfefferle]

If the theme is the only authority it is even better.

The syntax of the theme support was only a first shot, I would highly recommend to discuss and change the feature flags!

[dshanske]

The theme being the top authority makes sense...as long as the theme knows how to do something. If it doesn't, it needs to fall back on something.

[pfefferle]

sure, and that can be handled with more granular theme support flags.

[dshanske]

So, 'microformats2' as a theme_supports flag will have arguments for WordPress properties..For example, author, content, etc.

'microformats2_rendering' would have arguments for properties that don't directly map to WordPress properties? Or do we want to combine them into one single microformats2 flag with the differences set in properties?

We still, either way, end up with collision.

[pfefferle]

exactly. i would use microformats2 (because of its adoption) for both

[dshanske]

Then prefixing the mf2 properties with mf2_ makes sense, I suppose.

[pfefferle]

ah, now I know why I proposed a new rendering flag... Let me think about that... perhaps we should create a section on the wiki, where we collect the different ideas and where we can define the flags. I hope @snarfed is ok with this too.

[dshanske]

Why not have all possible plugins register support, and have the user specify their priority for applying them if both have support for that property? For example, both Post Kinds and Micropub register they support rendering checkins. The user specifies in configuration that they'd prefer rendering in the event of both?

[miklb]

-1 to putting the onus on the user to specify priority. They aren't going to want that responsibility, they just want an integrated experience. Just sounds like opening up a bad UX with a ton of options and configurations.

[dshanske]

I'm suggesting 1 option...who has priority. Not on a per property basis.