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 Mon, 17/08/2026 - 16:45 TagsLast week’s AI releases put a familiar question back into view: who controls the technology that digital systems depend on? On 10 August 2026, Meta released Muse Glimmer, a 30-billion-parameter model optimised for local agent workflows, with its weights under the Apache 2.0 licence. Mark Zuckerberg, Meta founder and CEO, argued in an essay published the same day that superintelligence should be broadly distributed rather than concentrated in a small number of hands. On 14 August, Alibaba Group’s Qwen team released Qwen3.8-27B, another downloadable model with weights under Apache 2.0.
There is a catch in calling all of this “open AI.” Downloadable weights under an open-source licence do not by themselves establish that an entire AI system is open source. Under the Open Source Initiative’s Open Source AI Definition, the preferred form for modification also requires sufficiently detailed information about the data used to train the system, the complete source code used to train and run it, and the model parameters. Even so, downloadable weights can expand practical deployment choices by allowing organisations to run and adapt models on infrastructure they control rather than relying solely on a vendor-hosted service.
Drupal is relevant here not because a content management system and an AI model are equivalent, but because the project has spent 25 years working within open-source principles. Drupal marked its 25th anniversary on 15 January 2026, and the Drupal Association’s Open Web Manifesto describes the open web through principles including freedom, decentralisation, participation, choice, privacy and security. The comparison should remain limited: a content management system, model weights, training data, source code and computing infrastructure are different layers with different licensing and governance problems. The shared principle is practical: leave organisations room to choose infrastructure, modify systems, and avoid unnecessary dependence on a single provider.
The larger question is whether those principles are becoming easier to recognise beyond software-development communities. AI is forcing organisations to consider what happens when a technology provider changes terms, raises prices, closes a service or simply stops fitting their needs. Drupal cannot answer AI’s licensing, computing, data-governance or portability questions, and open source does not guarantee independence. What Drupal can offer is a 25-year example of why choice, modification and exit matter when digital infrastructure becomes important enough to depend on.
As AI becomes another dependency inside websites and digital services, that old open-web argument has a new place to land. The question is no longer only what an AI model can do, but how much control remains with the people and organisations that build on it.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
This issue of Editor’s Pick was written and curated by Kazima Abbas.
If AI can generate an application from a description, is software still worth anything?
I have lived with a version of that question longer than most.
I released Drupal for free more than twenty-five years ago, and later co-founded Acquia, which has grown into a large enterprise software company built around Drupal.
Granted, Drupal is free in a different way than AI-generated applications are free, but I'm not sure that changes the basic question of how to build a successful business around either one.
Open Source made code abundant by giving people broad rights to use, modify, and redistribute it. AI is lowering the cost of producing code. One lets you copy the software; the other makes it cheaper to recreate software.
Free code changes what customers pay forBecause anyone could use Drupal for free, Acquia could never build a durable business around access to the code. From the start, we had to make money another way.
We built that business around helping enterprises build, run, and manage Drupal applications throughout their lifecycle. That includes hosting, but goes well beyond it: the tools and services needed to develop, deploy, secure, scale, monitor, and improve applications in production.
Proprietary SaaS typically bundles access to the application with the hosting and operations required to run it. With Open Source, organizations can run the software themselves or choose who hosts and operates it.
As AI makes applications cheaper to recreate, the traditional SaaS bundle of software and operations comes under pressure. Customers may become less willing to pay for access to application functionality without becoming any less willing to pay to run and manage applications in production. For Open Source businesses those economics are not new.
Dependability becomes the productSoftware can be free, or nearly free, without becoming cheap to depend on. The more people and organizations depend on a system, the more of its value comes from operating it securely, reliably, and at scale.
Once people depend on an application, the cost of its failure has little to do with how much it cost to build. An application that costs $1,000 to build can still cause a $10 million failure.
As AI makes enterprise applications easier to create, adapt, and integrate, they still have to be deployed, secured, scaled, monitored, and run reliably over time. As software cost comes down, dependability becomes a differentiator.
Linux is abundant; dependable cloud infrastructure is a service worth paying for. Drupal is abundant; dependable digital experience infrastructure is a service worth paying for.
Acquia has lived with those economics for nearly 20 years. Drupal made the code abundant, so we built our business around helping organizations build, run, and improve what they created with it. As AI makes code cheaper to generate, that business model may start to look a lot less unusual.
Either way, more software companies will have to answer the same question: if the code is abundant, what are customers really paying you for?
This is the second article in a series of articles looking at migrating from Jadu into a LocalGov Drupal (LGD) site for Central Bedfordshire. In the first article we looked at the Jadu API and setting things up so that we could make calls to the API and parse the XML data using the migration systems available.
In the last article I mentioned something about the Jadu API that caused me a lot of headaches. The API contains most of the information for a page, but critically, the Jadu API contains no information about the path of a page. There is basically no way to get the URL of a page in Jadu from the XML API.
I'm quire sure that this makes creating anything useful in the API a real pain since referring back to the site needs to be done with manually placed links, but it's clearly like this by design. I couldn't find any documentation on why it is like this, but it almost feels like vendor lock-in. Please correct me if I'm wrong here.
If you migrate a page from one system to another then it is highly important that you maintain the URL structure of the site. If you change the URL of a page then you need to add in a step that adds a redirect from the old system to the new so that all of your search engine results, the existing links from other sites, and any user bookmarks that have been created work correctly. This is critical to get right for a public facing council site like this.
Since I was migrating into a LGD site, it made sense to use the Drupal path auto system and LGD path management plugins to manage the paths on the Drupal site. We therefore needed to know the existing Jadu URLs so that we could create these redirects.
To get the URLs during the migration caused quite a bit of experimentation, but I did solve the issue with a solution that had a high success rate.
philipnorton42 Sun, 08/16/2026 - 19:06Webform is the most popular module for building forms in Drupal. You can use it for a simple contact form or for a long form with conditional logic, file uploads, and email alerts. Either way, you build the whole thing from the admin interface without writing code.
In the video above, you will learn how to build a form with Webform in Drupal CMS. You will create a Customer form, add conditional logic, send a confirmation email, split the form into pages, view submissions, and embed the form on a Drupal Canvas page.
What three decades has taught us about what lasts
Thirty years ago last month, between my sophomore and junior years of college, I started a company called Palantir Internet Services, later known as Palantir.net. I had been building personal websites for nearly two years at that point and was captivated by this revolutionary new medium that allowed anyone, anywhere, to publish something that anyone else in the world could read.
While the internet touches nearly every part of our lives today, in the summer of 1996 it was still seen by many as a novelty. There were only about 250,000 websites on the web, and while Amazon and eBay had already launched, Google, Facebook, and Wikipedia were still years away.
That fall, I met Tiffany Farriss, and together we built Palantir into a company that developed websites for clients of all shapes and sizes. As college students, we were featured in a news story on CNN and profiled in a front-page Chicago Sun-Times article. Our first paying clients were colleges and universities, and then for several years we partnered with Chicago design firms who were making the transition from print to the web.
During that time, we built and deployed several versions of our own in-house content management platform, eventually deprecating it in 2007 in favor of the newly released Drupal 5. Putting our energy into contributing to an open source project not only brought us new business opportunities but also introduced us to a community we are proud to still be part of today.
Along the way we grew into a full-service digital consultancy, bringing our strategy, design, build, and support services to public sector agencies, higher education institutions, nonprofits, and healthcare organizations whose needs are genuinely complex and whose work has a profound impact on others.
Only a handful of companies in our industry have been around as long as we have. Over the years, we've watched it go through several transformations: the dot-com bubble of the late 1990s, the rise of "Web 2.0" and social media in the mid-2000s, and the emergence of smartphones and the mobile web in the late 2000s.
Today, we are in the middle of one of the web's biggest transformations yet, as generative AI has fundamentally disrupted the traditional ways that online content is both created and consumed. The business models that built the web are no longer sufficient for an environment increasingly dominated by bot traffic and bot-created content. As more money has flowed into generative AI, we've seen less of it invested in other forms of online infrastructure, and that shift has affected us and many others in our industry.
At the same time, these tools have already demonstrated their usefulness for automating manual and labor-intensive work, from code review to content audits. We believe that when used thoughtfully, generative AI can improve the online experience and make vital information more accessible to more people.
And that's why, in an era of slop and enshittification, we feel it's more important than ever to recommit to our mission and vision. Palantir exists to help others discover, create, and share knowledge, and to strengthen humanity through the work that we do and the way that we do it.
We may not be able to predict the future, but 30 years of experience gives us a lot of perspective on where things have been and where they might go next. Technology keeps changing, but it's people who decide where to put their time and attention. That's the choice we've made so far, and it's the one we will continue to make.
I know this blog post's title implies losing my (programming) skills, and I will gladly address my feelings about how agentic coding has caused my problem-solving and coding to atrophy from lack of use. The main focus of this post is about losing, specifically deleting, my overly verbose and complicated skills and AGENTS.md files.
I was inspired to write this post after recently switching to the latest OpenAI GPT 5.6 models with Codex and OpenCode as my harnesses for Drupal development. In a previous post, I discussed that one approach to working with AI is to accept that every beginning and end of a session is like onboarding and offboarding a new team member. To help onboard an AI, we need to provide documentation, guidance, and workflows, typically implemented as AGENTS.md and agent skills.
AGENTS.md and agent skills are instructions added to your context to nudge the AI in the right direction. After switching to a more intelligent frontier model, I began to suspect I needed to rethink my assumptions about what the AI was capable of and how much initial context was required for the AI to succeed at a task. So I removed all my assumptions, deleted my AGENTS.md and skills directory, and started fresh.
Losing my agent skills
I had a hunch that some of my installed agent skills were costing me extra tokens and not adding enough value when I read a Reddit thread about "are you guys still using the superpowers skill?" Superpowers nudges coding agents to adopt a pragmatic workflow that includes brainstorming, specs, plans, tests, and review....Read More
At Ai4 in Las Vegas, the CIO of the NATO Support and Procurement Agency told a room of executives that if you can't reconstruct what your agents were doing, you have no reason to believe anything they produced. No traces, no trust. Set the red lines first, let the agents work inside them, and check afterward what they actually did.
95% isn’t 95%An agent that's right 95% of the time at every step is right about 36% of the time across a twenty-step process. Not 95%. Thirty-six. Krishna Gade, who runs Fiddler, put an even starker number on it: 90% a step, a hundred-step process lands a rounding error from zero.
That number usually gets deployed as an argument about model reliability. I read it as an argument about controls. If accuracy decays that badly by step twenty, the trouble started around step three and nobody was watching.
Amazon's session on brittle agents supplied the reason. Difficulty is a property of the procedure, not the agent. The same models, run against different standard operating procedures, scoredclose to 100% on some and 57% on others.Moving to a better model doesn't fix a problem that lives in the procedure either. The same team found that handing an agent too many tools collapses its accuracy rather than just slowing it down.
That matches what I see in practice. The worst agent failure I've dealt with didn't look like a failure at all. The agent ran, produced output, and kept going past what I'd asked for into adjacent work nobody wanted. Nothing broke. No error surfaced. I got a clean deliverable answering a question I never asked, and the cause was an agent file that didn't say clearly enough where the mission ended. Write the guardrails badly and you get confident work product outside the scope of the request.
Coronado's point lands harder than it first sounds. Traces are the precondition for every other control here, because a procedure you can't see is a procedure you can't fix. At Phase2, when we put an agent into a workflow, we can follow it end to end.
Another speaker, a VP of AI and data science, sharpened the point: validate the whole trajectory, not just the final response. Her escalation model tiered the response to severity, with minor signals logged for scheduled review, moderate signals assigned to an owner for investigation, and severe signals triggering a pause. Her framing of the kill switch is the part I'd steal. Shutting everything down is rarely the right move. The useful capability is isolation, cutting off one tool, one action, or one segment of users while the rest keeps running.
The NATO CIO's architecture included a role that most teams skip. Alongside the agents that search, extract, and synthesize, he ran skeptic agents and evaluators whose job was to argue with the work.
I run the same pattern, and it's the single practice I'd move to the top of anyone's list. When agent work matters, there's an adversarial reviewer checking status and progress at each turn. That reviewer is why the twenty-step math never gets a chance to play out. Errors get caught at step three.
Gade's sharper point was about how little of this anyone actually inspects. Teams sample their trace logs at 10%, sometimes 1%, and then describe themselves as monitored. A 1% review rate leaves 99% of the exposure unexamined. He also argued that the cost of evaluation should run somewhere around 10 to 20% of what you spend deploying an agent. That's a budget line, and he meant it as one.
I don't have a universal review rate to offer, and I'm suspicious of anyone who does. What I do is front-load. The first five or ten runs of a new agent get read in detail, and whatever I learn goes back into the prompting before the agent goes anywhere near production work. After that, depending on the scope and the depth of the project, it might be one turn in five or one turn in ten. I read the output myself again toward the end of a cycle, looking for drift. What I never do is hand an agent a large workflow and let it execute the whole thing unattended.
One piece of advice for anyone deploying their first agent:treat it like an entry-level employee. Be specific about the ask. Give it the ground rules. Show it concrete examples of what good looks like and what a wrong answer looks like. Almost everything people find surprising about agent behavior is explained by having skipped that step.
The comparison stops at correction. A person you coach on Monday shows up Tuesday having absorbed it. An agent doesn't. The fix has to be written down somewhere the agent reads (the prompt, agent file or skill definition) or the same failure arrives again on the next run wearing the same confident tone. You're not managing something that learns from you, you're maintaining the procedure it executes.
Phase2 Principal AI Technologist Chris Johnson’s panel on code quality got to the part that most governance conversations avoid: an agent's recommendation should be assigned to a specific owner, and you're accountable for what the code does regardless of how it got generated. One panelist described a customer who talked an agent into going beyond its scope and making offers it had no authority to make.
Here's where I land. An agent's performance is attributable to whoever owns and runs it. That means agent performance management already sits inside somebody's performance review, whether or not anyone has said so out loud. The agent doesn't get a rating. The person who deployed it does.
The stakes aren't theoretical. EY's Responsible AI Pulse survey found that 99% of the large enterprises it surveyed had already taken a financial hit from AI-related risk, with average losses conservatively put at $4.4 million. In the regulated industries where a lot of our work sits, bad output carries financial, reputational, and legal exposure at the same time. That's why I don't believe in running these things without human oversight, and why the review rate question deserves a real answer instead of a policy statement.
The practice I keep coming back to started with a specific annoyance. Across projects, I kept catching numbers that were subtly wrong, usually when data came in through an MCP connection or out of a large Google Analytics or Search Console export. So I built a skill that makes the agent construct a databank first. Every statistic used anywhere downstream has to verify against that file. Nothing gets asserted from the model's memory of what it read three steps ago. It's my own method rather than an agency standard, though it's spreading internally. It works for a reason that has nothing to do with the agent being smart. It works because the check now lives inside the procedure.
Coronado had a better line for this than I do. “Put your agents in the basement and keep the job upstairs.”
Build as many as you want down there. The performance review still has one name on it.
Today we are talking about Open Source sustainability, becoming your own content creation machine, and how drupal influenced some of that with guest Jeff Geerling. We'll also cover AI Metering as our module of the week.
For show notes visit: https://www.talkingDrupal.com/565
TopicsJeff Geerling - jeffgeerling.com geerlingguy
HostsNic Laflin - nLighteneddevelopment.com nicxvan Mike Anello - drupaleasy.com ultimike JD Flynn - dorficus
MOTW CorrespondentMike Anello - drupaleasy.com ultimike
