18 Aug 2026

feedDrupal.org aggregator

Specbee: How to use AI for Drupal SEO: Internal Linking explained

AI-powered internal linking in Drupal uses vector search and LLMs to surface relevant links as you write. Read this blog to learn how it works and which modules to use.

18 Aug 2026 10:39am GMT

17 Aug 2026

feedDrupal.org aggregator

Joachim's blog: Making Entity Pager module API-first

Making Entity Pager module API-first

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!

joachim

17 Aug 2026 4:45pm GMT

The Vardot Team: Is Your Drupal Platform AI-Ready? Here's How to Know

AI is changing how people find your content. Score your Drupal platform's AI readiness across five areas in five minutes.

17 Aug 2026 1:07pm GMT

feedSymfony Blog

Announcing Symfony Language Tools, the Official Symfony LSP Server

A Symfony application is full of strings that mean something: route names, service ids, template paths, translation keys, environment variables. But to most editors, they mean nothing. Write redirectToRoute('order_confirmaton') and nothing complains about…

17 Aug 2026 12:05pm GMT

16 Aug 2026

feedSymfony Blog

A Week of Symfony #1024 (August 10–16, 2026)

This week, development activity for the upcoming Symfony 8.2 release was very intense: PropertyInfo made accessors and mutators configurable with attributes, HttpFoundation added targeted Cache-Control support conforming to RFC 9213, Console attributes can…

16 Aug 2026 7:01am GMT

13 Aug 2026

feedSymfony Blog

Announcing the Symfony AI Core Team

When we announced the Symfony AI initiative in July 2025, the goal was to bring powerful, well-integrated AI capabilities to PHP applications and to build them in the open with the community. A little over a year later, Symfony AI has grown far beyond those…

13 Aug 2026 7:04am GMT

01 Apr 2004

feedPlanet PHP

ezSystems are classy folks

cover
Last week I helped the folks at ezSystems debug some APC problems they were having. The problems ended up being a 64bit architecture problem (they have uber-fast Opterons) and the bug is now fixed in 2.0.3.

Today I received Python & XML from them (off my Amazon wishlist). Thanks guys!

On a side note, my wishlist seems borked. The list I get when I search on my email address or name is not the same one I can edit when I log into the site.

01 Apr 2004 6:53pm GMT

PHP april fools...

1st of April 2004 get's to it's end and I guess it's time, to summarize the recent April fools a bit. Not that I think anyone in the world believes in them, but some were quite funny:

1. Changes to case sensitivity in PHP.
Alan Knowles announced that PHP will change to the studlyCase API and therefor will get everything broken by changing established functions.

2. IBM takes over Zend.
Myself hacked a little article about IBM taking over Zend to make PHP a compete of Java.

3. The first PHP virus has been seen.
Wasn't there one last year, too?

4. PHP has been overtaken by Micro$oft.
Mhhh... a little bit unreliable, if they had been taken over by IBM this morning... Maybe one should first look, what others wrote...

5. And finally, PHP4 and 5 showed their real faces...
Take a look at a phpinfo() output!

I guess I missed some, so feel free to comment on this entry, if you found another!

01 Apr 2004 5:49pm GMT

PHP Virus Attacking Web Hosts

Symantec have a report of the virus here. I've yet to see any of the PHP news sites picking up on it but, using a virtual host account, managed to deliberately expose some PHP scripts to it. From examining the infected scripts, what's disturbing is once infected, every tim...

01 Apr 2004 12:19pm GMT