Customize or create? Core thoughts on core blocks

As developers, we’re often asked to implement features that would be slight variations on features that already exist in WordPress core. Since building things is our forte, it can be reflexive to start from scratch, but that isn’t always the best route, and it can cost you precious time and resources. In fact, there’s a name for this phenomenon: Not Invented Here Syndrome, which tempts developers to create bespoke approaches to problems that have already been solved. Striking a balance between optimizing existing solutions and creating innovative features is the name of the game.

When it comes to developing in WordPress, there’s an advantage: WordPress allows developers to customize core blocks, which could be anything from a minor change of the front-end design to a complete overhaul. Customizing core blocks can save hours— even days —of development time, especially if the desired feature is just a slight variation from core. At the outset, however, it can be hard to tell just how different your new feature will be.

Weighing your options

As a developer, building blocks from scratch can become a default pathway. But the truth is, there are benefits to customization too — and in the interest of efficiency, developers should weigh the benefits of each approach.

Recently, a client asked our team to implement a gallery feature with a lightbox and a carousel for their image displays. When initially scoping the project we knew we had two main choices: create a custom gallery block, which would duplicate all the effort of integrating with the media library, or limit the customizations to the rendering of the block and add a toggle to swap between the two views. In our case, we chose the latter.

It doesn’t always go according to plan

Originally, we chose the core block customization path for the lightbox gallery because it allowed us to complete the development in a fraction of the time compared to creating a custom block. We were able to demo a functionally complete version of this feature to the client within a week.

What we had yet to anticipate, however, was a follow-up request asking if we could change the way the block appeared in the editor. Specifically, they wanted it to appear the same way as it did on the front end, which meant we would need to incorporate the same structural changes in the editor as we did on the render function.

While implementing this additional request, it quickly became apparent that we were creating a brand new editorial view for the core block, which meant reimplementing many of the features from scratch. At this point, we needed to reassess our decision to customize the core gallery block.

Customize or create? Choosing your solution

In many software development projects, there comes a time when developers need to decide if they should start fresh or continue on the current path when new challenges surface. In this particular lightbox gallery case, we faced a choice: start over with a new block, or customize an existing core block. 

We find the following questions help create a map to navigate these situations:

1. What experience is your user looking for?

As with any product or feature build, figuring out whether to customize a core block or create a block from scratch comes down to the desired user experience.

In our case, the client wanted a low-effort experience for their editing team. Specifically, they wanted to be able to use the existing gallery feature and toggle a lightbox view on or off on the front end as needed. They also didn’t want to have to recreate galleries to swap between the gallery views, which was a concern given WordPress gallery images are only stored at the block level as InnerBlocks. Given these requirements, it made sense for us to lean on the existing core block and restrict our changes to modifying the front-end design.

2. Is there a core block that gets you 90% of the way there?

When deciding on a path to take for your feature, start by asking yourself what the primary goal is. There are a number of core blocks that go unused; do any of them get you most of the way to your desired feature?

In our case, the answer was clearly yes. Our client was requesting a lightbox gallery that performed exactly like the core gallery, but on the front end, it would present as a lightbox carousel. The existing gallery got us 90% of the way there. We were able to lean on the functionality of the existing gallery block, which restricted our customizations to front-end markup and style changes. Is there a block that can do the same for you? 

3. Would customizations to a core block be functional or visual? Is it primarily in the back-end or the front-end?

If you’re lucky, the changes you need to make to the core block might be limited to styling. In that case, your customization may be as small as adding a class to the block and updating a stylesheet. In our situation, we had to filter the rendering of the gallery block to generate our own markup. However, even that was much simpler than creating a custom block from scratch.

We had to add a SlotFill to the block to allow switching, which meant filtering the block in the editor, but we expected the gallery experience to functionally remain the same in the editor as it had always been.

Ultimately that wasn’t the case, given the decision to modify the editor’s view, but that leads me to my last point.

Core block customizations can (practically) become custom blocks

The lightbox gallery effectively acts as a custom block that uses a block variant and a custom edit component. A block variant, or block variation, is an alias for a defined block that allows us to pre-configure attributes. In our case, we were able to create a block variant with the alias of lightbox gallery that pre-configured the lightbox attribute to active.

In lightbox mode, it uses existing attributes from the core gallery block — but it doesn’t use all of them. When not in lightbox mode, it looks and acts exactly as it would without any modifications. When using the lightbox gallery block variant an additional, hidden, attribute is configured that, when set, disables the ability to toggle the lightbox mode off.

This approach allowed us to maintain the customization for the user experience, and effectively offer two blocks to toggle between, which protects our customizations in the event the core block changes. We also incorporated a block variant that forces the lightbox effect on and disables the ability to toggle it off. This way, we have the best of both worlds. Editors can convert existing galleries to lightbox galleries without having to rebuild them, and anywhere a lightbox gallery is specifically required, editors can disable the ability to toggle off the lightbox view by using the lightbox gallery block variation.

If we were to remove our code today, all the existing lightbox galleries would automatically revert to core galleries, essentially leaving the core code unaffected, just as a custom block would. 

The core issue

The decision to customize core blocks or create custom blocks in WordPress depends on various factors such as time, resources, user experience goals, and the extent of required modifications. While building from scratch allows developers to have more control and showcase their skills, customizing core blocks can save time and effort when the desired result is a slight variation of an existing core feature.

However, it’s essential to consider potential risks, challenges, and future compatibility issues associated with customizing core blocks. By carefully evaluating the user experience objectives and utilizing block variants and custom components, developers can strike a balance between leveraging existing solutions and implementing innovative features, ultimately leading to efficient development processes and satisfying user experiences.

Want to learn more about how Alley approaches custom solutions? Check out our work.