redesign to coordinate with other mf2 plugins and themes

[dshanske]

Right now, rendering is called directly by the creation process. It should be called by filter. This was originally an option, but was removed in a previous commit.

This code should be less tightly intertwined with the Micropub server code.

[snarfed]

i'm repurposing this issue for the big new redesign we want to do for coordinating with other plugins and themes that render mf2 data. (@dshanske, please holler if you think i shouldn't!)

we're going to implement @kraftbj's design sketch in https://github.com/indieweb/wordpress-uf2/issues/30#issuecomment-312375228 . here's an initial draft of the requirements for this plugin and a possible design.

• first, unit tests. look at all of the existing unit tests for creating and updating posts with different mf2 properties. right now, they check post_content. change that to render the post and look for the same content in the rendered HTML.
• add new post meta properties that indicate a post was created with the micropub plugin, and which version. we'll use this later.
• generate_post_content, generate_event, and friends currently convert mf2 data to HTML that's stored in post_content. extract out each individual mf2 property or logical group of properties, e.g. the ones inside an h-event, and move them to their own render_XXX method that prints them out.
• add a new render_mf2 method that takes a property (mf2) string and a content (HTML) string with . attach it to a hook or filter that runs when rendering the post. (probably after the post content.) its code should be something like:
  1. if the post was created by micropub before this, it will have the mf2 already rendered and baked into post_content, so we want to short circuit. determine this by looking up the post meta mf2_type property, and also the new post meta properties mentioned earlier that store whether this plugin created it, and which version. if mf2_type exists but the new ones, don't, return content unchanged.
  2. if content is non-null, another plugin already rendered this mf2 property, so just return it unchanged.
  3. otherwise, call has_mf2_support and pass the mf2 property. if that returns true, return content unchanged.
  4. otherwise, call the appropriate render_XXX method for the mf2 property.

[snarfed]

I'm not actively working on this right now, so it's available if anyone else wants to. otherwise I'll get to it eventually!

[snarfed]

i still don't use micropub much myself, so I'm gradually realizing that I'm the wrong person to own this plugin or drive its development.

so, i don't expect to work on this change myself, but it's still probably still the single most important thing we need to do right now, for IndieWeb WordPress authoring overall.

just FYI @dshanske @pfefferle @miklb et al!

(I'm also happy to transfer it to the @indieweb org at some point! that won't let us do anything we can't already do now though, with it here, so probably not high priority yet. coordinating people and time is more important.)

[dshanske]

I wonder if there is a solution that doesn't involve duplication of effort. I would gladly take on the plugin but I have a lot I am maintaining

[pfefferle]

I can review code and help brainstorming, but I am also not really using the plugin (actively)...

[dshanske]

I am only partially using it, but more than either of you. We need more involvement in everything, to be honest. Recruitment time?

[dshanske]

I am still wondering if we can save development resources by spinning out the mf2 rendering in Post Kinds and Micropub into one single rendering project. One less thing to develop in parallel.

[pfefferle]

There are central rendering projects called themes... I do not see any advantages in adding a third plugin to the stack that does nothing but rendering... It makes the whole plugin stack even more complex...

[dshanske]

Agreed, but we know that the majority of themes don't support the rendering we need. So what I built was a template engine that can be put into a theme, but has defaults in the plugin. With Gutenberg coming, that may have to switch to block based editing, so I would wait till we see how that goes.

[dshanske]

Maybe that should be our decision. Table solving this problem till we have a proposal that factors in Gutenberg.

[dshanske]

It may even help

[snarfed]

Could https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/ help with this?