How we tackle gutenberg


Some remarks about the talk:

  • What I didn’t mention about meta blocks: I’m not sure if there will be an actual block type called „meta block“ or if we’ll do that with dynamic blocks that will for example just show a Editor-UI block with settings that are saved gutenberg-style or classic-post-meta style but aren’t representing themselves with HTML in the frontend.
  • A very important setting that doesn’t seem to exist yet, are „templates“ or „required“ blocks to make it possible for a certain type to always have certain blocks already available. This would be great (no, required!) for (meta) settings blocks. Also, if a post type has no content, gutenberg should only allow registered settings blocks, but no content blocks, if they’re not shown anyway. We’ll see how (or if) register_post_type will be changed for that.
  • At the moment I’m working at a prototype and I realize that something like a „meta block“ doesn’t seem to exist (yet). But with lots of effort and hacks I was able to do a „meta block“ prototype that provides a text field within a block and that is being saved to post meta. I just hope there will be some APIs making that job easier – Maybe there are APIs/functions and I just didn’t find them yet. As I said: We’ll see what the future holds.
  • At the core talk after lunch I asked, how, for example, a user can set the font size (because that was a question and the answer was „yes, the user can set the font size“. I did ask that because in the current prototype of gutenberg, a lot of inline styles are used in the frontend, some of them are not even responsive. Font size in my opinion shouldn’t be settable like „11px“ by a user, but rather with different sizes like „large, medium, normal, small“ and then be added to the paragraph as classes – This makes it possible for theme developers to define what sizes are possible within the theme and different screens. Setting a font size by px, pt, em or rem is, in my opinion a thing of the past and nothing an average user should be able to define. Same with font colors. I didn’t dive deep into those parts of gutenberg as I’m pretty confident that we won’t make a step back there (inline styles would be a *huge* step back in my opinion).

Overall architecture of gutenberg

I didn’t talk too much about the actual underlying architecture of gutenberg – on purpose. I was and still am not sure if the architecture of mixing structured and renderable data in one database field, while using a syntax that is beta-ish, is a good idea. I know that this won’t be changed anymore at this point – We’ll have to live with that and hope that Core handles it well. Nevertheless, the goal of my talk was to take away some „fears“ of developers, freelancers and agencys that a) metaboxes may not be backwards compatible (they will be!) or b) things like metaboxes for settings are a thing of the past (They’re not, blocks like that will still be possible *and* the right post sidebar still exists for narrow type meta boxes).

After all, we still have to wait a little to see the picture. I’m looking forward to the first WordPress 5.0 alpha or beta, where gutenberg is fully integrated and we’ll see the full scope of possiblitites in regards of compatibility and APIs.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert