Open dshanske opened 6 years ago
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.
post_content
. change that to render the post and look for the same content in the rendered HTML.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.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:
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.content
is non-null, another plugin already rendered this mf2 property, so just return it unchanged.has_mf2_support
and pass the mf2 property. if that returns true, return content
unchanged.render_XXX
method for the mf2 property.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!
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.)
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
I can review code and help brainstorming, but I am also not really using the plugin (actively)...
I am only partially using it, but more than either of you. We need more involvement in everything, to be honest. Recruitment time?
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.
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...
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.
Maybe that should be our decision. Table solving this problem till we have a proposal that factors in Gutenberg.
It may even help
Could https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/ help with this?
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.