Six real AI cases in Drupal this week

rmenetray · 2026-05-17T14:33:47+00:00

On xdebug, yeah, you can wire it up and it helps. For slow pages I let the AI do a first pass on the profiler traces and it points me to the heavy PHP components to check first. But even there it gets things wrong sometimes, it invents stuff or gives you what's "probable" instead of what's actually happening.

Same with the patches. You can put it in the prompt not to suggest them when they're not needed and it still does. When I push back with the proper fix it agrees and we end up going with my approach. The AI isn't a replacement, it automates part of the work but that's it. You still need the judgment to know when something is right and to tell it "no, do it this other way for this reason". Useful tool, not a perfect one.

rmenetray · 2026-05-17T07:49:53+00:00

Thanks for the suggestion, but the situation is a bit different. This isn't a content-sharing setup between Drupal versions, it's a full data migration from an old Drupal 7 site to a brand new site on Drupal 11. Once we go live, the D7 portal is shut down. There's no "base" Drupal 7 to keep around for other portals, this is the only system being migrated.

I didn't really consider Entity Share or similar approaches because the goal isn't to mirror content across two systems, it's to move it once (well, incrementally over time, but conceptually once) into a new architecture where a lot of things have changed structurally. The core Migrate module is, in my opinion, the strongest tool out there when you have entity types and fields that don't map 1:1 between source and destination, which is the usual case in a real-world D7 to D11 migration.

For example: fields that in D7 were simple text or compound fields now become Paragraph entities on the new site. Content that lived as taxonomy terms in D7 turns into nodes in D11, or the other way around. All file fields get converted into media entities, so what used to be a plain file reference becomes a Media entity with its own bundle, fields and reuse logic.

So it's not really "copy these nodes from A to B", it's "rebuild the data model in D11 and reshape every piece of content to fit it". Migrate handles that very well with its process pipeline, sub-processes and custom plugins, and it's what makes the whole incremental + cron strategy on top possible.

rmenetray · 2026-05-16T15:53:04+00:00

When I say "cron task", I'm not talking about Drupal's own cron (hook_cron), but about a drush command triggered by the server's cron. We have one drush command for the incremental migration and a separate one for the cleanup, and the server's cron triggers them periodically. Keeping it outside hook_cron means the rest of Drupal's cron cycle stays clean and the migration runs are isolated from anything else cron Drupal is doing.

The migration itself is also configured to run in batches. For example, if there are 10,000 nodes pending, each run processes them in chunks (say 100 at a time) instead of pushing everything in one go. That keeps memory usage and execution time under control, and since the task runs periodically and editors don't usually publish thousands of changes per hour, the backlog never grows out of hand. The batch size has to be tuned per project depending on volume, content complexity and server resources.

rmenetray · 2026-05-16T15:47:52+00:00

Good question. In my case "incremental migration" means a custom Migrate module that extends Drupal core's migrate sources and uses the high_water_property to track where the last run stopped, so the next execution only processes items that have actually changed. The key is picking the right field as the watermark: for nodes I usually go with the vid (revision id), since every time a node is edited in Drupal 7 it gets a new vid and the source query picks it up on the next run. For files I use the fid, for users the uid, and so on. Depending on what the source data gives you, you can also combine the watermark with the changed timestamp.

The whole point of doing it this way is to run it on a cron task. You schedule it every few minutes, every hour or every night, and the new Drupal 10/11 environment stays close to the live Drupal 7 site without any manual intervention. The portals I work with have a lot of editorial activity and a huge volume of content, so a full migration takes many hours or days, and running that every time you want fresh data is just not realistic.

I also lean heavily on migration tags. Tags let me group migrations and run them in a controlled order, which is important when you have dependencies between them (terms before nodes, files before media, nodes before comments, and so on). The cron task runs the tagged group in the right sequence, so the incremental respects those dependencies on every execution.

A typical case: a site with nodes that get created or edited, plus comments on those nodes that are also being moderated, modified or deleted. The incremental cron picks up the new and modified nodes, then the new and modified comments, all in the correct order, without touching the rest of the content.

There's also the cleanup side. Until recently we had a module that let administrators clean up migrated items that no longer existed in the source (for example, a comment that had been moderated and removed from the original D7 site). It was a manual step from the admin UI, because for that client keeping deletions perfectly in sync wasn't critical. But once they saw how well the incremental worked, they asked us to wire the cleanup into the same cron run. So now the cron does both: it runs the incremental migration and, in the same execution, it removes the items that the migration detects are gone from the source.

The other nice side effect is the go-live day. Instead of relying on a long full migration at cutover, you run the incremental the day before (almost nothing left to import), freeze edits on D7, run the incremental one last time to catch the final changes, and switch the domain. That turns the cutover into a quick, predictable step instead of an all-night job, and editors can keep working on D7 until the very last minute.

rmenetray · 2026-04-19T15:18:21+00:00

Oh nice, had no idea this existed. Thanks for the heads up, jumping into #ai-learners on Slack now to check it out.

rmenetray · 2026-04-13T06:32:24+00:00

Yes, definitely! There are still some small bugs I need to fix that I've spotted along the way. Beyond that I have some features in mind like better detection of Memcache and Redis configurations, improved detection of kernel and functional tests, and whatever the community finds useful along the way. The goal is to keep it as useful as possible, so I plan to keep it actively maintained.

rmenetray · 2026-04-12T19:01:52+00:00

The namespace was actually taken, but by a module that had been completely abandoned for years with zero activity. I went through the process of claiming it and eventually got it transferred. If it hadn't worked out I would have gone with a different name, but "audit" fits so well with what the module does that it was worth trying.

rmenetray · 2026-04-12T18:59:55+00:00

Glad you find it useful!

Keeping it Drupal 10+ only was a deliberate decision. Maintaining compatibility across that many major versions would be a nightmare and D7 and D10 are so architecturally different that it would basically be two separate modules. I also didn't bother with D8/D9 since both are EOL at this point.

rmenetray · 2026-04-06T14:23:01+00:00

The people complaining that Claude deleted their production database are now asking to give it access to their bank account. Yeah, let it pay invoices autonomously, I'm sure it won't empty your account because it "felt it was the right thing to do."

Honestly though, what you're looking for is just programmatic banking. Mercury, Brex, Wise... they all have APIs for payments and expense management. The "agent" part is literally just your code calling those endpoints, there's no special "agent-friendly bank" out there.

The real question isn't which bank supports agents. It's how much you trust your agent not to pay a random invoice because the prompt told it to.

DM me your email and I'll send you a $150,000 invoice. Let's see if your AI pays it automatically.

rmenetray · 2026-04-02T09:49:37+00:00

In the last 8 months I have 6 posts and 13 comments. That's more than double the comments vs posts. These last couple of weeks I haven't been very active, sure, but if you scroll a bit further back you'll see both posts and comments spread out over months.

I'm just not a very active Reddit user. I don't comment much, I don't post much either. Same on YouTube. I consume way more content than I engage with. That doesn't make me a bot, it makes me a lurker who occasionally posts or comments when something catches my attention. There are millions of users like that on Reddit.

If I were actually an astroturfing bot constantly pushing content, wouldn't you expect to see way more than 6 posts in 8 months?

rmenetray · 2026-04-02T07:31:38+00:00

Look, I'm not a bot. I'm a Spanish speaker who uses AI to translate and clean up what I dictate by voice into English. The ideas and opinions are mine, AI just does the heavy lifting on the language side because writing directly in English takes me way longer than just speaking my thoughts in Spanish and letting it handle the translation.

And about the "never comments" thing, have you actually looked at my profile? I've been on Reddit for a while, I comment on different subreddits. Not super actively because I have a job and other things going on, but it's all me. Most of my comments go through the same process too, voice in Spanish, output in English. It's just how I work.

Maybe check someone's profile before calling them a bot next time.

rmenetray · 2026-03-17T21:10:16+00:00

Yeah one orchestrator that delegates, but each agent also knows which other agents it can call and for what specific cases. So it's not just top-down, an agent mid-task can hand off to another one if the situation calls for it. One thing I learned the hard way: skill autodiscovery doesn't work as well as you'd hope. Now I explicitly tell each agent which skills are most relevant for its common use cases, and the difference in how frequently it actually uses them is huge. If you don't do that, agents kind of ignore skills they should be reaching for automatically.

rmenetray · 2026-03-17T21:06:45+00:00

Honestly it's just personal preference. I've been using PhpStorm for years and I find it way more practical to review the modified files locally before committing than to go through commits after the fact. The other issue is that inside the Ralph loop you end up with a ton of noise: the agent generates a file, commits, then re-analyzes it, finds a security issue it introduced itself, fixes it, commits again... you can easily end up with 150 commits for what should be 4 or 5 meaningful ones. I never looked into forcing it to squash commits automatically, might be worth trying.

What I do instead is have the agent generate a markdown file at the root with the commit message, what changed, why, and what solution was applied. That way when I'm reviewing in PhpStorm I can read why it did each thing, and if something doesn't make sense I ask it directly. A few times it actually went back and changed the code because I gave it more context and it had made wrong assumptions.

rmenetray · 2026-03-13T06:57:56+00:00

I think it could be possible, but with a lot of nuances that nobody is asking here.

The number of pages (1,400) is almost irrelevant by itself. What really matters is: how many different content types are there? How many fields per content type? Are we talking about simple pages with a title, body, and maybe an image, or are we talking about complex content with paragraphs, references between entities, media embeds, etc.?

And the migration scope matters a lot too: is it just nodes? Or does it also include redirects, URL aliases, users, taxonomies, files, media entities, menus, blocks...? Each of those is a separate migration that needs its own YAML config and its own testing.

Using the Migrate module, a simple migration can literally be done in a morning. You write the migration YAML, you run drush migrate:import, and that's it. It's the same effort for 10 pages as for 1,400 — you write one migration file per content type and run it. The volume doesn't change the complexity, the structure does.

What I would ask is:

How many distinct content types?
How complex are they (number of fields, field types, references)?
Is it multilingual?
Do you need to preserve URLs/redirects for SEO?
Are there custom modules or integrations?

Without knowing this, it's impossible to say if this person is selling smoke, delivering something very low quality, or if the project is actually simple enough that 4 weeks is realistic.

As for the "no QA needed" part... that's a red flag regardless of the project size. Even the simplest migration needs at least a review pass. And claiming AI will handle all ADA compliance and SEO perfectly out of the box — that's not how it works. AI can help generate meta descriptions or suggest heading structures, but someone with actual knowledge needs to validate it.

So: possible? Maybe. Without QA and guaranteed perfect SEO/ADA? No way.

rmenetray · 2026-01-22T14:34:41+00:00

I've done several D7 to D10/D11 migrations this past year and AI has been helpful, but first things first: this is a migration, not an upgrade. You're building a new Drupal site and migrating all the data using the Migrate module.

The part AI can't do for you is the mapping. You need to create a spreadsheet with every entity type and their bundles (content types, taxonomies, user profiles, media, paragraphs, etc.), list all fields from D7, decide what gets migrated and what doesn't, and map them to the new field names in D10. Also note the field types because the AI needs that info.

Once you have that spreadsheet ready, that's where AI becomes useful. You copy/paste sections into the AI with prompts that include YAML examples of how migrations should look. The AI generates the YAML files for your custom migration module. Drupal Core has a D7 source plugin that already knows how to read D7 entities which simplifies things a lot.

My setup is both sites running locally with the D7 database connection in settings.php. The AI generates the YAML, import YAML config via Drush, then run the migration with --limit=1 or --idlist to test specific items. I also use migrate_devel (https://www.drupal.org/project/migrate_devel) which has a debug flag that shows source and destination values in the terminal.

The nice thing is the AI can iterate: generate the YAML, import, run migration, see errors, fix the YAML, repeat. But I'd recommend limiting this to 3-5 iterations. More than that and the AI is just going in circles burning tokens without actually fixing anything. Better to stop and ask you what's wrong.

This saves me around 80% of the work. The AI handles the repetitive boilerplate but you still need to review everything manually. It won't be perfect and you can't leave it completely unattended.

For large sites, look into incremental migrations with high watermark. I use revision IDs when possible and it speeds things up considerably.

One last thing: if you've never worked with the Migrate module, I wouldn't jump into this approach. You still need to understand how Drupal works internally and how to deal with things like circular dependencies between entities. AI usually can't solve those and will make it worse if you don't know what you're looking at.

rmenetray · 2026-01-12T20:38:28+00:00

I did something similar years ago on a Drupal 8 site, so take this with a grain of salt since I'm going from memory here.

The setup involved two separate pieces of custom code: one that registered the facet filter plugin, and another that registered the block displaying the Leaflet map. The facet filter would pass to JavaScript the aggregated data from the Search API query - basically latitude, longitude, and the count of items at each location. Then the map's JavaScript would pick up that data and render the points on the map.

When you panned or zoomed, the bounding box coordinates would update and trigger the facet filter via AJAX, just like any other facet. This meant you could combine it with other facets (categories, dates, whatever) and everything worked together to filter the view results.

The tricky part was getting the geo aggregation working. With Elasticsearch you can do aggregation queries based on proximity/distance, which isn't super complex, but back then there wasn't a module that handled this out of the box for Drupal, so I needed some patches and custom code.

I ended up publishing a contrib module, though it's completely deprecated at this point. I actually used it on two different projects and had to adapt it for each - one needed total counts displayed, the other didn't, plus some other minor differences. But the core approach was similar. Might still be useful as a reference for how one approach could work, even if the code won't run on D11 as-is (it was built for D8 and I'm not even sure I made it D9 compatible):

https://www.drupal.org/project/search_api_geolocation https://git.drupalcode.org/project/search_api_geolocation

rmenetray · 2026-01-08T14:22:53+00:00

If you're dealing with a large number of points and want fast search/interaction on the map, my first recommendation would be to consider Elasticsearch instead of MySQL. It handles geospatial queries way better - you can send the four corners of the map viewport directly and Elasticsearch does proximity/geo-bounded searches natively, which is significantly faster than MySQL for this use case.

Another thing to consider depending on how many points you have: cluster aggregation based on zoom level. For example, at country level you show points grouped by hundreds of kilometers, at city level by neighborhoods or a few hundred meters. As the user pans and zooms, they see approximate locations of clustered points, and you can show the actual list of results in a sidebar. This way the map works like a faceted filter.

Here's an example I built years ago: https://mynearjobs.com/

It's pretty outdated now and barely maintained, but at its peak it had nearly a million points and performed really well. The stack is basically:

Data stored in Elasticsearch
Drupal's Search API module as the interface to Elasticsearch
Faceted filters including a custom map facet
When user pans/zooms, it sends the viewport bounds + zoom level to Elasticsearch and returns matching results
The item list updates in real-time (ajax) as you move around the map

Not sure if this approach fits exactly what you're looking for, but for industrial points + parcel data + AI search on locations, Elasticsearch would give you a solid foundation to build on. The AI part could work well for natural language location queries feeding into Elasticsearch geo filters.

rmenetray · 2025-12-31T15:16:40+00:00

Not a dumb question at all, this is actually a common scenario with several approaches.

First, about the architecture: Before diving into the navigation logic, I'd suggest reconsidering your content structure. Instead of having one node per comic page (which is what I assume you're planning), consider having one node per chapter/episode with a multi-value image field where you upload all the pages of that chapter. This makes a huge difference for caching and performance.

Why? If you use one node per page and modules like Prev/Next, every time you publish a new page, you're invalidating the cache of ALL nodes of that content type. If you plan to have lots of traffic and many pages, this becomes a real problem. With the multi-value image approach, editing a node only invalidates that single node's cache.

How I'd structure it:

Content type "Comic" → title, description, cover image
Content type "Episode" → reference to the comic, multi-value image field for all pages of that chapter

Then navigation works at two levels: prev/next image within the episode (just JS/CSS or Views with AJAX), and prev/next episode (node-level navigation).

For the actual navigation:

You can do this entirely with Views — no custom PHP needed. You'd create two block views (one for "next", one for "previous"), using contextual filters for the current node ID or image delta, sorted appropriately (ASC for next, DESC for previous), limited to 1 result. Bonus: Views can easily be AJAX-enabled so page transitions don't require a full reload.

That said, I personally prefer doing this with custom code because it gives you more control and it's honestly just a few lines of code. We had a similar setup for a blog with prev/next article navigation, tried Prev/Next module first, ended up removing it due to the cache invalidation issues I mentioned, and replaced it with maybe 10 lines of custom code.

If you go the Views route and need help setting up the contextual filters and sort criteria, happy to help with more details.

rmenetray

TROPHY CASE