Where I’m NOW at with WordPress: Gutenberg as a developer

Posted on by Ross Wintle

“As a developer, I think I’m coming around to the idea of the new WordPress Gutenberg editor. Here’s my updated thoughts and reflections.”

My previous post about Gutenberg as a business owner and developer got quite a lot of feedback from other people who felt a similar way, and generated some discussion. This is an update on that after exploring and thinking and conversing a bit about the topic.

What prompted the update?

This update stems from some thoughts that came about from doing Zac Gordon’s excellent video course on Gutenberg for developers.  I reached a point on this course where I realised that if you create a custom Gutenberg block in the way that was being demonstrated in the course, it would save the block’s content to HTML, using a template that you define, in the post content. And if you decided to change the template that the block used to save its content then you would have to re-save every post that uses that block to update them all.

https://twitter.com/magicroundabout/status/957381194395594753

Note: some of you will be thinking “yes, but that’s not the only way to save data in Gutenberg”. And you’re right. And I’m coming to that!

I actually got some good responses to the Tweet above. Matthew Haines-Young, in particular, made some comments that got me thinking:

I actually stopped replying to the conversation at that point because I wanted to think. I wanted to consolidate my thoughts.

So where are you at now?

I think what happened was this: while watching Zac’s videos (which I’m only part way through) I got stuck in the mindset of only having registerBlockType‘s edit and save attributes to work with. These allow you to specify, in JavaScript, what the editing interface for your block looks like, and what information gets saved to the post content when the block is saved.

So I was stuck with only these options. But also, I was stuck with the impression that this should be a WYSIWYG as possible: the editing experience should look much like the front end.

I realised that editing and displaying don’t need to look the same

My first change of mind was to realise that currently, in WordPress, my editing interface for most of my structured data – custom meta boxes – looks and works very differently to the output that’s generated (if any) from those meta boxes. So they can actually be very different things.

In other words, the equivalent of registerBlockType‘s edit setting is all my meta box code. And the equivalent of registerBlockType‘s save setting is…well…it depends on where you’re saving your block data to.

But if you’re saving the block’s content to post-meta (which is possible in Gutenberg) then I guess the save method doesn’t apply, I’m generating PHP in my template files, and I’m not really any worse off than I was when I was using custom meta boxes. The code for editing and output is very different and is in different places.

I realised that thoughtful code organisation can help solve the JS+PHP issue

Having accepted that it’s OK to save my data to post-meta and generate my output elsewhere, the next issue is the clumsy fact that I have code about the same block type in both JS and PHP.

Why is this an issue? Well, mostly for reasons of understandability and maintainability of my code.

So the question then is how can I structure the code for my blocks so that it all makes sense and is easily maintainable by future developers.

Let’s be clear: having code about the same thing in both PHP and JS is never going to be great. But it’s going to happen more and more in modern web development that I have to describe my data in two very different places, so I kinda have to get used to this and figure out ways to work with it.

Matthew’s idea of putting both PHP and JS for a block in the same directory is good and I’m sure there will be other architectural solutions to this.

I then have questions like:

  • How do I pull all the JS into the build process?
  • Do I even want to pull all the JS into a build process, or should I avoid code that needs to be compiled/transpiled?
  • Do I want one big JS/CSS file that loads on every page regardless of which blocks are used?
  • If I want separate JS/CSS for blocks, how do I configure the build process to make multiple outputs?

And so on.

So I’m not quite there with the detail. But nothing that can’t be worked out, I think.

I still have a problem with post meta data being in blocks. It doesn’t always seem like the right thing. But that’s for future thought.

Can you sum up the technical bits?

I’ll try.

  1. My issues with Gutenberg from a development standpoint have been around how I can manage structured data that I would typically store in post meta.
  2. I trust that the Gutenberg developers will find an appropriate way to keep existing meta boxes working. PLEASE!!!
  3. For better or worse – probably both depending on…stuff – Gutenberg gives us a new way to build interfaces for that post meta.
  4. Yes, Gutenberg can save the data in a block to post meta!
  5. The editing interface for post meta, and the display of post meta do not have to look or work the same – they aren’t with the current meta boxes!
  6. There are ways that you can structure your code so that having PHP and JS code about the same data objects is understandable and maintainable and probably no worse than current solutions for building meta boxes.

Well, of course! Gosh, it took you a long time to figure that out?

Again, this may be what some of you are thinking.  Let’s get a couple of things clear:

I’m struggling with this a bit. It’s a big change learning Gutenberg, bits of React, assessing it from both a user and developer perspective, talking to others, raising issues, making voices heard.  It will change how I’m going to work and I’m trying to learn, process, think, and plan while looking after two small children, doing my day job, and having a life. So I’m sorry if I’m a bit behind.

BUT…I hope that this process has shown that I’m trying to be as open minded as I can, and that, though I’m struggling, I want to be positive about Gutenberg.

Lessons

I think there are some lessons from this process too though.

The people building Gutenberg are doing an AMAZING job. I can’t over-state that fact. But there’s this perfectly natural phenomenon whereby if you’re deeply involved in something and have been working on it for a long time, you’ve been on a journey of learning and understanding and changing your mindset that’s taken months.

I’m trying to take that same mindset-changing journey in a shorter space of time and with lots of other things going on around me (GDPR anyone? A two-year-old’s birthday? My day job? ARGH I’M PRESENTING AT WORDPRESS BRISTOL PEOPLE NEXT WEEK!!!).  I’m playing catchup with limited mental capacity for it.

And I sometimes feel like responses to questions or statements I’ve made about Gutenberg have been of the form “but it works if you use this method/trick/workaround, so what’s the problem?”, when actually, what’s needed isn’t a one-off workaround, but for me to have my mind changed about something more fundamental.

This is NOT blaming any person for any specific comment or interaction. And us developers shouldn’t expect the Gutenberg developers to have time to be coaching us individually on changing our mindset (though they are having a really good job at trying).

But it is an observation about communication that is limited by where different people are in their thinking, the time that people have, the written medium we have in GitHub issues and Tweets to convey complex ideas.  And it’s as much my fault for leaping into discussions at the wrong times and places and without thinking things through before venting. For which I’m sorry.

Basically, I’m an old dude who thinks hard about everything and is set in my old WordPressy ways – heck, I’d still be writing SPARK Ada if I could. It’s hard to teach me new things. You have to be slow and deliberate and careful. You can’t always just tell me stuff; sometimes I have to find it out for myself.

And I suspect others are in the same boat.

So what’s next?

I’m choosing to persevere and I’m grateful to those who have helped.

I see the opportunity, but I sense and understand a lot of developer unhappiness, and I still have some of my own too, and that has some good foundation in some cases.

I’m starting to think this will be OK from a developer point of view. It will be hard, there is work to do, but it will be OK.

If you, like me, are a WordPress developer getting to grips with all this, I urge you to persevere; to ask questions; to read the handbook; to track down the resources people are making available; to be in the learning process for the long game, not the quick win; and to remember as you do so that the answers may not be simple workarounds, they may be more difficult shifts of thinking.

If you’re way ahead with thinking about Gutenberg then please remember to be gentle with old dinosaurs like me who lack a bit of neuroplasticity and are trying their best to catch up. We may need more than a quick fix!

I still have reservations about Gutenberg as a user, and I still think the upgrade process will be a shock to many who use WordPress. But as a developer, I think I’m coming around.

And I hope you will too.