As we migrated more of our components to Display Builder, our developers at UI Suite encountered an interesting challenge. Some of our old custom modules relied heavily on `hook_preprocess_block()` and `hook_preprocess_field()` to inject data or attach libraries. We quickly discovered that these hooks were no longer being triggered for content rendered by Display Builder.

Technical Deep-Dive: Adapting to a Preprocess-Light World

As the FAQ documentation explains, this is by design. For performance reasons, Display Builder's rendering pipeline often bypasses the theme layers that would normally trigger these hooks, such as block.html.twig and field.html.twig. This intentional choice results in a faster, more efficient rendering process, but it required us to rethink our approach to data alteration.

The solution was to move this logic to more appropriate, component-oriented locations. In many cases, we refactored the logic directly into the SDC components that were replacing the old fields and blocks. For more complex scenarios, where we needed to fetch external data, we created custom UI Patterns "Source" plugins. While this required some initial refactoring, the end result is a cleaner, more encapsulated architecture where logic lives with the component it affects, rather than in a global hook.