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

Is there a way to run the Drupal AI demo website (North moor University) locally?

The Hidden Cost of Volunteering: Reflections on Contributing to Drupal Core

I have worked with Drupal for many years and have contributed to several projects, including Drupal Console and Drush. Recently, I decided to spend some of my free time contributing small improvements to Drupal core.

My intention was deliberately modest. I was not proposing a new subsystem, a major architectural change, or an ambitious refactoring. I selected narrowly scoped issues: the kind of tasks commonly described as “low-hanging fruit”.

The experience has made me reflect on what “small” really means in a mature open-source project.

The patch may be small, but the contribution is not

A one-line documentation correction may require only a few minutes of actual implementation. However, the complete contribution can involve considerably more work:

• Understanding the history and precise scope of the issue.
• Finding the correct files and current development branch.
• Creating and publishing a working branch.
• Preparing a merge request using the expected format.
• Updating both the Drupal.org issue and the GitLab merge request.
• Understanding issue statuses, assignments and contribution credits.
• Monitoring pipelines and distinguishing relevant failures from unrelated ones.
• Responding to feedback and updating the implementation.
• Watching the branch become progressively older while waiting for review.
• Rebasing and repeating automated checks if enough time passes.

None of these requirements is unreasonable in isolation. Drupal core needs strong quality controls, and reviewers need submissions that are clear, tested and maintainable. The difficulty lies in their cumulative effect.

For a volunteer, a technically trivial contribution can acquire a surprisingly large administrative and cognitive cost.

Review availability is the real bottleneck

Drupal’s documentation encourages new contributors to start with small issues. This is sensible advice, but it leaves out an important consideration: the size of a patch does not necessarily correlate with the time needed to complete its lifecycle.

One of my recent contributions, issue #3628393, changes a single PHPDoc comment. The corresponding merge request was ready to merge and had no conflicts, but remained without human review.

This creates an uncomfortable form of uncertainty. The code may be correct and the merge request may be green, but the contributor does not know whether it will be reviewed tomorrow, next month or at all.

Meanwhile, the target branch continues to move. Eventually, an otherwise valid contribution may require a rebase and another pipeline. If that pipeline encounters unrelated or intermittent failures, the contributor must investigate them before knowing whether any further action is genuinely required.

A green pipeline does not become red merely because time passes. Nevertheless, the longer an unreviewed contribution remains open, the greater the probability that maintaining it will require additional work.

Drupal already recognises this problem through the Needs Review Queue Initiative. The existence of that initiative is itself evidence that producing patches is not always the main constraint. Review capacity and committer attention are scarce resources.

Automated testing does not always provide a clear answer

Continuous integration is essential, particularly in a project as large and widely deployed as Drupal. However, its value to contributors depends on whether failures can be interpreted reliably.

A very small documentation-only change may encounter a pipeline containing numerous failures from large test suites. Some may be recurring failures unrelated to the merge request. From the contributor’s perspective, the result is still red, and determining whether the submission is responsible can require more time than producing the change itself.

It would be helpful if the interface distinguished more clearly between:

• Failures introduced by the current merge request.
• Failures already present on the target branch.
• Known intermittent failures.
• Infrastructure failures.
• A genuinely outdated or conflicting branch.

Experienced core contributors may understand these distinctions immediately. Occasional contributors often do not, and uncertainty creates additional work for both contributors and maintainers.

Drupal.org and GitLab form a fragmented workflow

Contributing to Drupal core requires navigating two connected but distinct systems.

Drupal.org contains the issue, its status, assignment, credits and main discussion. GitLab contains the branch, commits, merge request, diff and pipeline. Changes made in one system do not always make it obvious what must be updated in the other.

Even small questions can interrupt the work:

• Should I assign the issue to myself while working on it?
• Should I leave it assigned after moving it to “Needs review”?
• Does editing a file in GitLab’s web editor save it automatically?
• Should separate file edits become separate commits?
• Does the merge request description also need updating?
• Is being several commits behind the target branch a problem?
• Should I rebase now or wait until somebody requests it?
• Should I post a reminder, or would that be considered noise?

Each question has an answer, but finding it requires knowledge that is not directly related to fixing Drupal.

Feedback is valuable, but timing matters

In another recent contribution, issue #3629274, a reviewer identified that a dedicated key/value collection should be used instead of the general state collection.

This was useful technical feedback. I updated the implementation, adjusted the tests and obtained a successful pipeline.

However, this illustrates why early review is important. A short architectural observation made near the beginning can prevent unnecessary implementation and testing. When feedback arrives late, even a small correction can require reopening the development environment, reconstructing the context, modifying several files and restarting the validation cycle.

The burden is not only measured in minutes. Context switching has a real cost, particularly for volunteers contributing outside their normal working hours.

AI transparency introduces another area of uncertainty

English is not my native language, and Drupal core issues can contain long and technically subtle discussions. I sometimes use AI as a supporting tool to verify that I have understood a problem correctly and to help express my reasoning clearly in English.

I do not use it as a substitute for technical judgement. I review the changes, follow the discussion, respond to reviewers and accept responsibility for everything I submit.

Drupal’s AI policy reasonably requires contributors to understand, verify and take responsibility for AI-assisted work. It also requires disclosure when AI generates a significant amount of submitted code or text.

However, transparent disclosure can itself lead to uncertainty if it is immediately treated as a possible policy violation without identifying the specific concern. A contributor attempting to comply with the policy may feel that disclosure has created suspicion rather than trust.

This is particularly relevant to contributors whose first language is not English. There is an important distinction between:

• Automatically generating unreviewed technical contributions.
• Using a tool to avoid linguistic misunderstandings.
• Asking a tool to challenge or corroborate one’s interpretation.
• Using grammar or translation assistance.
• Generating substantial code without understanding it.

Clearer guidance on these distinctions would encourage responsible transparency without discouraging contributors who use language assistance.

Possible improvements

I do not think the solution is to weaken Drupal’s review standards. Those standards are one of the reasons Drupal core is trusted. The objective should be to reduce avoidable uncertainty and make the existing process more proportionate.

Some possible improvements would be:

1. Provide an explicit fast-review queue for documentation changes and other very small, low-risk patches.
2. Offer early triage that confirms whether the proposed approach is acceptable before substantial work begins.
3. Make the relationship between Drupal.org issue states and GitLab merge-request states easier to understand.
4. Explain directly in the interface when contributors should assign or unassign themselves.
5. Distinguish unrelated, intermittent and infrastructure test failures more clearly from failures introduced by a merge request.
6. Provide automatic assistance for keeping otherwise valid merge requests current.
7. Clarify how the AI policy applies to translation, grammar correction and linguistic assistance for non-native English speakers.
8. Treat transparent AI disclosure as the beginning of a factual assessment, not as evidence that a contribution is inherently unreliable.
9. Make it easier to request an appropriate reviewer without needing personal connections within the project.

None of these ideas eliminates the need for human reviewers. They might, however, reduce the amount of reviewer attention spent explaining procedural details and investigating avoidable uncertainty.

Is volunteering still the logical choice?

Open source depends on people deciding that contributing their time is worthwhile. That decision is influenced not only by ideals, technical interest or recognition, but also by whether contributors can see a reasonable path from effort to completion.

A contribution does not need to be merged immediately. Maintainers are volunteers too, and nobody is entitled to another person’s time. Nevertheless, a process can unintentionally discourage participation when a five-minute correction creates weeks of uncertainty and an indefinite maintenance obligation.

The real comparison is not between contributing and doing nothing. It is between contributing and every other meaningful or enjoyable use of limited free time.

After preparing a branch, updating two platforms, monitoring pipelines, interpreting policies, waiting for review and wondering whether the branch will need another rebase, a perfectly rational question eventually arises:

Would Drupal benefit more from a simpler contribution process—or would I be making a more logical use of my evening by lying on the sofa and watching another episode of a series?

At the moment, the sofa presents a remarkably efficient workflow.

AI disclosure: I used ChatGPT to help organise and draft this article in English. The experiences, arguments and opinions are my own.

At DrupalCon Rotterdam, the DA announced the Drupal Advocacy program to incentivize folks to be louder about Drupal in an effort to "win back" folks who moved away from / dismissed Drupal in the past, showing off all the cool modernization we've done. And that's a great and worthy goal!

However, there are WAY more humans on this earth who have _never_ heard of / tried Drupal. And they're not necessarily in our networks to hear what we have to say, they will not understand words like "Drush" or "render array." ;) But, they also don't necessarily have a preconceived notion of Drupal at all, and therein lies an opportunity.

So, here's a challenge to the Drupal community: during the month of October (the spoooookiest month), go to a local meetup / hackathon / community event where Drupal *isn't* (AI, JavaScript, WordPress...) and report back what you heard and learned about the developers there, what they're building, and where they're struggling.

We can then use this information to brainstorm the best way to "show and tell" Drupal for these developers, in _their_ words, around _their_ use cases and pain points. Then we do DevRel at global scale. 😎

Will this work to drum up new interest in Drupal? Who knows. But hey, worst-case, it's an opportunity to meet fellow nerds and talk tech over free pizza. :)

What do you think?

Background - I have been maintaining a Drupal site for years, but I am a casual that doesn't really know much. I started on Drupal 8 and survived a migration over to Drupal 10 and switched themes at that point to "Drupal8 W3CSS Sub-theme". I get by but ultimately I don't really know what I am doing.

Today I saw an update to the theme I am using and I foolishly installed it with composer. I now get the error:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "Drupal\drupal8_w3css_theme\Hook\Drupal8W3cssThemeHooks". in Drupal\Component\DependencyInjection\Container->get()

Been googling and using AI recommendations for a fix but so far no luck sorting it out. I decided to then install the Solo theme which is the latest generation of W3CSS. I installed it fresh and switched over, and that resulted in the following error instead:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "Drupal\solo\Hook\SoloThemePreprocessHooks". in Drupal\Component\DependencyInjection\Container->get(

I have cleared the cache with drush each time and verified that these files do exist where you would expect them to be. I have also used composer to check for outdated components and none are red, although a number are yellow.

If I switch to a completely different theme then my site loads, although it is very malformed, so I am hoping to get one of the above themes working rather than having to do implement a completely new theme.

Any advice for me?