dshanske / indieweb-post-kinds

adds support for responding to and interacting with other sites using the standards developed by the Indieweb Community
https://wordpress.org/plugins/indieweb-post-kinds/
Other
43 stars 28 forks source link

Gutenberg support #190

Open chrisbergr opened 6 years ago

chrisbergr commented 6 years ago

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

dshanske commented 5 years ago

@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

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.

chrisbergr commented 5 years ago

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.

dshanske commented 5 years ago

That would be very helpful, thanks

miklb commented 5 years ago

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

chrisbergr commented 5 years ago

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:

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 :)

tw2113 commented 5 years ago

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

dshanske commented 5 years ago

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

grantcodes commented 3 years ago

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.

miklb commented 2 years ago

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.