indieweb-post-kinds icon indicating copy to clipboard operation
indieweb-post-kinds copied to clipboard

Gutenberg support

Open chrisbergr opened this issue 6 years ago • 9 comments

Hi David,

the theme I'm workin on currently will be a WordPress 5.0 theme, so I'm working local on nightly builds of WordPress beta. Because of selfdogfooding I'm supporting many of your indieweb related plugins by default. In case of post kinds I've noticed, that there (in Gutenberg) aren't any of the special form fields visible, to be able adding the url I'm responding to.

The other strange thing I noticed, after posting a bookmark (as mentioned above, without bookmark url), the post got the css class "kind-note". Does this happen because of the missing relation?

I'm wondering about your plans for Gutenberg. Will you release something for wp beta or do you start active development after the public release of WordPress 5.0?

BTW: If you need / want some help according to UI elements or the UX of this plugin, I'd love to get involved.

Best, Chris

chrisbergr avatar Jul 10 '18 21:07 chrisbergr

@chrisbergr Thank you for the request. Gutenberg is something of a worry for me, as I haven't quite figured out in my mind how it would work with the plugin. Post Kinds consists of a few elements

  • A URL parser that takes an input URL and tries to extract it into structured data
  • Enhancements to the Post Editor to add additional structured data to the post object
  • A Taxonomy that takes that structured data and classifies it and dictates behavior
  • A rendering piece that takes the structured data stored in post meta and displays it using templates that can be overridden in the theme by including them in a subdirectory called kind_views

If you are using Gutenberg, I've made no modifications to ensure the behavior works. The taxonomy being set, which is what I assumed you did in Gutenberg, wouldn't trigger any of the other behavior.

I have been following Gutenberg a bit, but I haven't figured out how the block based philosophy would work with different Post Kinds. Because I'm not sure how that would work in the long run, I'm hedging my bets by working on Micropub integration so that, in the event Gutenberg causes major issues to integrate, people can use Micropub client apps to post to their sites while I figure it out.

dshanske avatar Jul 11 '18 03:07 dshanske

Micropub integration is a great win. Beside that I bet the Classic Editor Plugin https://wordpress.org/plugins/classic-editor/ will grow it's installations count very high after the release of 5.0.

The Gutenberg block based editor is a great tool for writing articles. For all other post kinds it's a bit too much I think. 99% of all rsvp's, replies, bookmarks etc.. I'll not need multiple paragraph blocks, images, columns and so on. But it will be the new default way of writing in WordPress..

I can see if I find some time in the next couple days to povide you some sketches how the post kinds elements can be implemented into Gutenberg to get a great experience.

chrisbergr avatar Jul 11 '18 14:07 chrisbergr

That would be very helpful, thanks

dshanske avatar Jul 11 '18 16:07 dshanske

I have some thoughts on this front as well. I intend to start digging in in a couple of weeks.

miklb avatar Jul 11 '18 16:07 miklb

Just a little update:

Instead of just sketching my ideas I thought it would be better (according to your interest in this topic) to contribute some code.

With very little changes (https://github.com/chrisbergr/indieweb-post-kinds/tree/gutenberg) I got the meta boxes appear at the right sidebar of the editor. There are some problems now:

  • It would be better to create a static block above the title block for the kind settings instead of the small meta box in the sidebar. Unfortunately I have to less knowledge about the functions of this plugin and only very basic knowledge about the Gutenberg Blocks so far.
  • The argument 'meta_box_cb' for custom taxonomies will be ignored in Gutenberg, so instead of the list of post kinds there is the same input/search field as used by tags. There may be a solution (https://webdevstudios.com/2013/07/08/replace-wordpress-default-taxonomy-metabox-with-a-radio-select-metabox/) but this will be a very huge change of the code.
  • I can type in e.g. 'reply' and add the URL - this works as expected. But because of the missing kinds radio form, the corresponding javascript function 'changeSettings' doesn't work anymore, so I can not RSVPing (e.g.)

Maybe I can digg deeper into both, the post kinds plugin and the gutenberg editor. But hopefuly some gen 1 indieweb citizen got inspired by my observations and can solve this by a fraction of the time I would need to spend.

At the end, I'm just a designer :)

chrisbergr avatar Sep 09 '18 01:09 chrisbergr

Just chiming in a little, I can definitely see how this is going to be a big hurdle to overcome given how the current metaboxes are created and utilized. Was kind of hoping it was going to be a little more straightforward somehow. Alas.

Also good to see @hrisbergr linking my employer here with that WebDevStudios link. :D

tw2113 avatar Jul 10 '19 05:07 tw2113

I have some ideas for building the backend pieces for this in future. No plans for the front end parts.

dshanske avatar Jul 10 '19 05:07 dshanske

So I've been thinking about this a fair bit recently and want to help make post kinds / mf2 in gutenberg a reality. Full disclosure - My selfish reasoning for this is I am working on a custom theme which I want to make indieweb friendly, but do not want to force anyone to use the classic editor.

I think one part has a fairly clear correct way to do things: Most properties should have their own block. Excluding content as WordPress default blocks should handle this. And excluding "meta" properties (eg categories, visibility, syndication) which should be meta data rather than blocks. I made a kind of proof of concept standalone plugin which shows this is viable. There is quite a lot of complexity inside of that though - how to best handle core WordPress blocks, UI of content editing, conversion between gutenberg & current post kinds & standard gutenberg content etc.

What is not so clear to me is how that would interface with the wider existing post kinds functionality, or how the split of gutenberg vs classic be handled. Forcing everyone to gutenberg is going to annoy a lot of people and maybe a pain to do the migration, but I expect gutenberg support will need a fairly extensive rewrite / addition to the codebase and I don't know if it makes a lot of sense to maintain both sets of code.

I in no way have any of this figured out but I'm willing to help out if I can, and am going to have a go at either building a separate plugin that works with the micropub plugin or a fork of post kinds to start adding blocks. I like the idea of using the existing plugin because there is so much great existing work here, but it may be too limiting or difficult.

grantcodes avatar May 03 '21 13:05 grantcodes

Ok, so I found post meta blocks are now a thing. You can also create re-usable block patterns. They could handle the nested classes for mf2.

I think the combination of the two would solve 80% of the issue.

Caveat of theme compatibility would still be an issue. Target minimal compatibility for Twenty-Twenty One or the WP release that came out with and don't look back.

miklb avatar Nov 19 '21 02:11 miklb