A year ago, I attended a one day drupal training camp and met a few absolutely wonderful people.

So encouraging and just consistently hyping me up any time I got stuck. I tried to download the cms on my chrome book with Linux emulated and forgot to give it enough disk space and they didn't let that keep me behind.

They instead introduced drupal forge to me and made sure I left with some knowledge which I can't thank enough.

However, icl I kinda got lost and could not learn any more cause the difficulty increased tenfold so I never picked it up again but, I'd really like to learn it purely to make my, one day, mentors proud💚

I am running two docker services that use the same Drupal instance.
The first one, let's call it "http", serves the site, and the second one, let's call it "amqp" runs a drush command that listens to AMQP messages (via rabbitmq) to alter content.

The amqp service process tasks that outlive a normal request; a task can take up to several minutes.

I am experiencing cache issues between both services: when a configuration is updated on the "http" service, the "amqp" service still uses a cached version, and when an entity is updated on "amqp" service, the "http" service still shows the old cached version.

I managed to fix the first issue by calling "ConfigFactory::reset" before retrieving the config object when a new message is processed, but this seems like a dirty fix, and I don't see how I can apply such a fix for the issue regarding entities.

Has anyone experienced such an issue ?
Any ideas of how to deal with this ?

P.S: I have APCu and memcache enabled, but the issue appeared before memcache was installed.

Any help will be highly appreciated.

I've been thinking about how much money gets wasted on development and staging environments that sit idle most of the time.

For example, DigitalOcean still charges you for a Droplet even when it's powered off. The only way to stop compute charges is to destroy it entirely.

But then you have to deal with snapshots, restoring env vars, networking, etc. whenever you need it again.

I'm curious how other developers deal with this. Do you just leave everything running and accept the cost? Destroy and recreate environments manually?

The usual way to put a map on a Drupal site is Google Maps. It is easy to start: get an API key, paste it in, and a monthly free allowance covers your first maps. After that, Google bills per map load. The map of a venue is the same for every reader, yet every view is a new request, counted and billed, and every reader's browser talks to Google while they look. The map doesn't change; the meter keeps running.

There is an open alternative to Google's data. OpenStreetMap is built by volunteers and published under an open licence. I wanted maps drawn from it that a site downloads once and keeps, so I built Maper.

What it does

• Your server downloads each map tile once, keeps it in private files, and draws the map itself. Browsers receive the finished drawing, never a tile, so no third party sees your readers.
• No API key and no per-view billing. Tiles come from OpenFreeMap, a free, donation-funded service, or from a Protomaps file you host yourself, in which case nothing is downloaded at all.
• It is polite to the tile provider: downloading stays off until you set a contact address. After that, every download respects daily and per-job limits, one request at a time, and backs off when the provider asks.
• Restyling is free. Tiles hold shapes and names, not colours, so switching or editing a map style redraws every map from the tiles you already have. Three styles ship today, and five more come in the next release.
• It works the Drupal way: a Maper map block for nodes (a venue, or the dates of a tour), and a Maper map format for Views, where every result row becomes a pointer with its own card.
• Headless if you want it: the server hands any front end the map as JSON, with a reference script in plain JavaScript.

Is it real?

It runs in production on Oído en Vivo, a live-music listings site in Colombia: 836 tiles, 69 MB, serving the maps of 550 places and every search. See it at https://oidoenvivo.com/buscar

Where it stands

This is 1.0.0-alpha1. It needs Drupal 11.2+, PHP 8.3 and a private file path. Alphas have no upgrade path, so reinstall between them. Beta comes next, and from then on every change carries an update.

• Project: https://www.drupal.org/project/maper
• composer require drupal/maper:1.0.0-alpha1

I'm the author. I'd welcome bug reports, rough edges and questions in the issue queue, or right here.

Map data © OpenStreetMap contributors (ODbL).

Hi everyone,

I’ve been working with Drupal (custom modules, theming, migrations, performance tuning) for several years and love contributing to open‑source CMS projects.

I’m curious:

• What kind of Drupal projects are you currently working on?
• Which challenges (security, upgrades, integrations) do you face most often?

I’d be glad to share insights, swap experiences, and even collaborate if anyone is exploring new builds or upgrades.

#Drupal #DrupalJobs #WebDevelopment #FreelanceDeveloper #CMS #Drupal10 #RemoteWork #ForHire #FullStackDeveloper #OpenSource

There will be an upcoming critical security release of Drupal core this coming Wednesday, October 14. For more information please see https://www.drupal.org/psa-2026-10-12 - the security team cannot release any further details at this time