For 30 years we write all our code by hand in BBEdit, the BOA Drupal hosting stack included, and until recently the smartest chatbot money could buy couldn't produce three bash scripts aware of each other, so our verdict was simple: a modern Stack Overflow, and not much else. Then 2026 arrived, and the documentation BOA was owed for 16 years finally got done - after one model fabricated most of it behind our backs, and a better one caught it red-handed and fixed it all, section by section, in four voices for four different audiences. Add a security review of the codebase, end-to-end test suites our old Jenkins could never run, and hosted Drupal and Backdrop sites defended against machine-made attacks, and you will see why we finally stopped joking about Artificial Stupidity.
It's funny how big ideas start.
I am doing some maintenance work on the Entity Pager module, which has been fixing bugs, improving the tests, and so on. And because Computed Field is also a module I maintain, and because I have at the back of my mind the idea of finding more use cases for it, I had the thought that I could add support for Computed Fields to Entity Pager.
Specifically, this would mean that Entity Pager would allow you to add computed fields to your entity type, which would be computed entity reference fields to the previous and next entities in the pager. As well as allowing you to output the previous and next links with more flexibility, and within the rendered entity rather than in a block, it would open up having these links in JSON:API (though there's a bug to fix still).
So, then, quite a good use case!
It does, however, require a bit of re-plumbing inside the EntityPager class. Currently, EntityPager, expects to be instantiated within the theming for an executed view. Our computed field needs a new API which it would call with the basic data (the view ID, display ID, and current entity), and that would take care of executing the view, extracting the data from the result, and returning it.
I suppose I could make a whole new pathway, but a lot of the code that would need is in EntityPager so it makes more sense to me to change that to allow both cases. This means adding a new way of constructing it from the factory service, and then executing the view if necessary.
So then we'd have an API for getting the previous and next entities. And that's where the big idea suggests itself: what if we used this API for everything?
Currently, the rendered entity pager is a specially-themed view. We define a custom Views style plugin, and that uses our theme template 'entity_pager' for its theming. We use the Views block system to show the pager. By the time our code is involved, the view has already been executed, and all of our code is taking place within the Views theming. This makes it tricky to do things like hiding the pager completely.
But... once we have an API, we could totally invert this. We could define a custom render element which outputs the pager. This would take the view ID and display ID as properties, and the current entity if you have it (and continue to detect it from the current route if you don't). Like this:
$build['pager] = [
'#type' => 'entity_pager',
'#view_id' => 'my_pager_view',
'#view_display_id' => 'my_display',
];
This render element would then be in charge of executing the view, and getting the data it needs from the view's result. You'd still store settings for the pager on the view's style plugin, but we'd no longer rely on the theming of that - the view would just be used as a data source. The render element would have similar theming to the Views style - it could pretty much use the same Twig template. The block we provide would change to being a completely custom block plugin, which would output the pager element.
To me, this seems like a cleaner structure. Our pager is a separate render element, and our code no longer runs inside Views rendering, which feels a little bit convoluted and fragile.
If you use Entity Pager, what do you think? Would this make your use of Entity Pager simpler, more complex, or not affect you at all? It would be a big change to the module, so I'd love to hear opinions on the issue for this, as I'm still undecided about it.
Do you need help with updating a contrib module, refactoring it, or expanding its capabilities? I'm available for hire - contact me!
Beta 4 release of Drupal AI Context Beta 4 of Drupal AI Context , also known as Context Control Center (CCC), is now available. CCC helps Drupal sites provide governed, reusable context for AI workflows and agents, from brand voice and editorial standards to organisational knowledge and governance rules. This gives AI systems access to more structured and relevant information while allowing teams to manage that information centrally. Following the beta 3 release , beta 4 has been shaped by extensive community testing and an expanded scope. The community testing revealed refinements for a more intuitive user experience, and several features earmarked for 1.1 have been brought forward into 1.0. The result is a more capable, usable and reliable context management system.