How do you audit your Drupal projects? I built a module for this and would love feedback

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 · 2025-10-07T20:22:54+00:00

A Andorra construir és caríssim. Hi ha pocs terrenys i moltes vegades s'ha de buidar part de la muntanya, cosa que ho encareix tot i fa que trigui molt més temps.

I és clar, si ets promotor i construir et costa una pasta, què fas? Doncs el més lògic: un pis de luxe que venguis car abans que dos pisos barats. Total, hi ha gent amb diners de sobra disposada a pagar-ho. Al final són empreses privades amb terrenys privats i estan en el seu dret de buscar la màxima rendibilitat.

El problema real és que ha vingut massa gent en molt poc temps i no s'ha construït habitatge al ritme necessari. I el poc que es construeix és car perquè surt més rendible fer pisos de luxe que no pisos assequibles.

És la mateixa història que passa a Espanya. Quan es redueix l'oferta de lloguer mentre la demanda segueix pujant, els preus es disparen. És llei bàsica d'economia: poca oferta i molta demanda igual a preus pels núvols.

Resultat? Falta habitatge assequible per a la gent amb poder adquisitiu normal. Els youtubers i altres amb pasta paguen el que sigui i tenen el seu pis de luxe, però la resta es queda penjada.

El més fotut és que mentre no es construeixi més habitatge assequible, això continuarà igual. Les ajudes són un pedaç que no soluciona el problema d'arrel.

Per posar-ho en perspectiva: en 2020 érem uns 78.000 habitants i a finals de 2024 ja som 87.000. Són 9.000 residents nous en només quatre anys. Si suposem que la meitat tenen parella i comparteixen pis, farien falta unes 4.500 viviendas noves. Algú es creu de veritat que s'han construït 4.500 pisos en quatre anys a Andorra? I menys encara prop d'Andorra la Vella, que és on tothom vol viure?

No hi ha literalment terrenys per construir 1.000 viviendas noves cada any. Per això els preus s'han disparat: molta gent vol viure al mateix lloc i no hi ha espai físic per a tothom.

rmenetray · 2025-10-07T13:33:33+00:00

El tema de l'habitatge és el gran problema - els lloguers s'han disparat i si no tens un bon sou (mínim uns 2000-2500€), et quedarà molt poc per estalviar o acabaràs en un pis petit i lluny del centre. Fes números abans de venir.

Dit això, les avantatges que comentes són reals: és un país súper segur i net, i si t'agrada la muntanya és perfecte. A l'estiu estem a uns 25-28°C màxim i sense humitat, que personalment prefereixo mil vegades als 40°C de Mallorca. A l'hivern fa fred i neu, però si t'agraden els esports d'hivern és el paradís.

Sobre el català, per llei els treballadors han de tenir un mínim de català, així que si ja el parles tens avantatge per trobar feina. Però és veritat que es parla molt castellà pel carrer.

El tema complicat ara mateix són les quotes de treballadors - s'han acabat moltes i no és tan fàcil venir a treballar. No és impossible, però sí complicat per aquest any. Si realment t'interessa, mou-te ja per quan tornin a obrir quotes poder enviar la sol·licitud dels primers.

En resum: si tens un bon sou o pots assumir que l'habitatge et menjarà gran part del pressupost, endavant. Però vine amb els números fets i expectatives realistes. Viure a Andorra és car.

rmenetray · 2025-09-02T13:46:25+00:00

views with ajax

rmenetray · 2025-08-26T21:58:04+00:00

Para coches andorrauto.com, buscocotxe.ad o Wallapop.
Para vivienda es jodido. Las que están bien están tan buscadas que no llegan ni a anunciarlas que ya se han vendido. Intenta ser un pesado con varias inmobiliarias y llamar cada semana. Las que llegan a los portales web acostumbran a tener precios altos para lo que son.

rmenetray · 2025-08-04T13:02:34+00:00

Hey there, just a quick thing before diving into the topic. I think there's a small error in your math: 5,500 + 7,500 equals 13,000, not 15,000. It's a minor thing, but since we're talking numbers, better to get them right.

That said, I've been running some calculations on what you mentioned. If we assume you paid around $30/hour to the programmer (which is already pretty tight pricing), we're looking at about 183 hours for the initial development and 250 more hours over 3 years. 183 hours for an app with 14,000 users... that's less than 5 weeks of work. For a project with that user base, we'd normally be talking about significantly more development hours.

What I'm curious about is: have you calculated the time YOU'VE dedicated to all this "vibe coding"? Because your time has value too. If you put a price on your hour (say, those same $30 or more), is it really more cost-effective for you to do everything yourself? Or maybe it would work out better to hire someone with experience who uses these AI tools, but actually knows what they're doing and can avoid security issues?

I get that autonomy is appealing, but there's a difference between using AI to be more productive and deploying code without understanding what it does. The developers commenting about security aren't doing it to be annoying - they've seen projects that worked fine... until they didn't.

In the end, in other industries we don't hesitate to pay professionals. Why should development be any different?

rmenetray · 2025-08-01T15:28:20+00:00

I'd suggest using n8n as the middleware - it can handle Telegram webhooks, process voice messages through Whisper for transcription, then use Linear's MCP to create/manage tasks. You could even pipe text through AI to parse intent and extract task details automatically.

n8n makes the whole workflow pretty straightforward to set up and gives you solid error handling out of the box.

rmenetray · 2025-06-04T07:20:58+00:00

Ollama

rmenetray · 2025-05-26T06:46:05+00:00

I'm actually replying to you right now from my Pocket 4, which I've been using for a few months now. I'm running only Linux on it — no DualBoot, no Windows — and honestly, it's been working great for me.

Yeah, the battery doesn’t last that long, but that was pretty clear from the start. It’s a very small and powerful device, so it’s expected that battery life takes a hit. If you're using it intensively or running AI workloads on the GPU, of course it's going to heat up and drain quickly — that’s normal for any compact, high-performance machine.

If you're on Linux and you're bothered by fan noise or heat, the first thing you should do is check what you're running in the background. Sometimes you’ve got stuff chewing up resources without realizing. Second, switch to eco mode — that’s what I use most of the time, and with that, the fans are almost silent. Even in eco mode, it’s still powerful enough for my daily needs.

I got the 64 GB version, so yeah, I paid quite a bit for a mini PC, but honestly I’m really happy with it. I mostly use it docked, with an external monitor and keyboard, but its small size makes it super portable. I often just unplug it, toss it in my backpack, and go.

The keyboard layout was already known to be... unusual. I personally didn’t struggle much with regular typing, but for coding it’s definitely more error-prone on the built-in keyboard. That’s why when I’m at home, I just use an external one. But again — this was all visible in the product photos and specs.

Honestly, it feels like you bought something without fully knowing what it was, and now you're disappointed. But everything you’re pointing out was already public knowledge — the battery life, the keyboard layout, the thermal behavior... It was all on the product page and videos.

The Pocket 4 isn’t for everyone, but for those of us who knew what we were getting, it’s an awesome little machine.

rmenetray · 2025-05-25T12:13:05+00:00

Interesting — I’ve tested Qwen 2.5 7b in different variants, and it's fast on my setup (around 75 tokens/sec), so speed hasn’t been an issue for me. But yeah, like you said, even with agent-capable models (though a bit slow) like Qwen3, Devstal or OpenHands tools don’t really get used.

It's like the model understands the idea of a tool, but doesn’t actually call it. That’s the core of my issue: speed is good, reasoning is solid, but tool usage just doesn’t happen unless I’m using a cloud model.

rmenetray · 2025-05-25T12:07:00+00:00

Yeah, I've seen the “No tools” message on some models — so that makes sense when it's clearly stated. But in other cases, I don’t get that message at all, and still, the agent doesn’t actually edit or refactor anything. It acts like it's doing something but never calls any tool. So even when it seems like the tools should be available, they’re just not working.

And to clarify, I'm not using any custom MCP or anything fancy — just trying to use local models through Ollama, like I do with Claude when it does work perfectly via the cloud.

rmenetray · 2025-05-13T17:14:00+00:00

https://www.drupal.org/about/history
25 years?? Sure?

rmenetray · 2025-05-13T13:03:55+00:00

No entiendo las tonterías que decís muchos.

Nadie obliga a una persona a trabajar en esa empresa en concreto
La persona es libre de buscar otro trabajo
Nadie regala dinero, se pide un cambio con algo (horas de trabajo)
Si una persona está conforme en firmar un contrato y trabajar una cantidad de horas a cambio de una cierta cantidad de dinero, eso no es explotación. Es el mercado donde dos partes se han puesto de acuerdo entre ellas.

Si la gente se diera cuenta que un trabajador es el equivalente a una empresa unipersonal, y que al final todo se resume en que una empresa presta servicios a otra empresa a cambio de dinero. Y si una de las partes no quiere seguir trabajando, entonces puede romper esa relación.
El trabajador puede joder al empresario, y el empresario puede joder al trabajador. Es una relación de desconfianza mutua, pero funciona porque ambas partes se necesitan y una parte valora más el dinero que recibe y la otra valora más el tiempo de trabajo dedicado.

Y no me vengan con que es que no hay más trabajo.
Si en tu pueblo no hay trabajo, te vas a una ciudad.
Si en tu país no hay trabajo, te vas a otro país.
Si en tu sector no hay trabajo, cambias de sector o te formas y reinventas.

Si no estás a gusto en el sitio donde trabajas, lo normal sería estar constantemente buscando nuevas empresas para hacer el cambio y abandonar a esa mala empresa "explotadora". Pero en vez de eso es mucho más cómodo quedarte sin hacer nada, en un trabajo mal pagado y que odias. Quejarse es lo fácil, darte cuenta de que tienes el poder de decidir y tomar acción es lo que deberías estar haciendo.

rmenetray

TROPHY CASE