I can't load drupal.org for the last few minutes. Some pages have been unavailable longer than that. Most of the down detectors say it is still up, but not for me. I am in St. Louis.

Anyone else seeing this? Thanks.

If you can't patch yet.

This game was made just to teach people about the Drupal AI ecosystem, but it is hopefully fun to play for anyone.

The game can be played online or downloaded here: https://macpackwala.workflows-of-ai.com/

Some more information here: https://workflows-of-ai.com/blog/i-vibe-coded-a-point-and-click-game-to-learn-about-the-drupal-ai-ecosystem

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💚

My take is that contributing to and growing an open-source project is easier with AI than without it. Still, while working on the Webform module's security issues, I was terrified that a single AI-generated misstep would draw vitriol.

Let's talk about our Drupal gardens and engage in an open dialogue among those who are AI-pilled, AI-curious, and AI-cautious.

This is mainly targetted at the broader AI community, but it also has a section what we mean to implement in AI Image Crop module

A demo on the work that I've been doing on exposed slots in Drupal Canvas.

This is still a proof of concept, we are not there yet.

I hope this demo gets people as excited as I am about this feature.

I think this one is very important to drive Canvas adaption.

Let me know what you think!

MR: https://git.drupalcode.org/project/canvas/-/merge_requests/1359

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.

Especially sketchy is that it goes back to 8.x so any unsupported sites floating around out there could be in trouble

Remark: I work at CKEditor as a Developer Advocate 🥑

Drupal 12 is in beta since DrupalCon Rotterdam, and today both official CKEditor contrib modules got their matching 2.0.0-beta1 releases:

• CKEditor 5 Plugin Pack 2.0.0-beta1
• CKEditor 5 Premium Features 2.0.0-beta1

What to know before you try them:

• 2.x requires Drupal 12 and is not compatible with Drupal 10 or 11. The 1.x line stays for Drupal 10.3+ and 11.
• Both modules have to be upgraded together with core, in one Composer operation:

``` composer require \ 'drupal/core-recommended:<sup>12.0@beta'</sup> \ 'drupal/core-composer-scaffold:<sup>12.0@beta'</sup> \ 'drupal/core-project-message:<sup>12.0@beta'</sup> \ 'drupal/ckeditor5_plugin_pack:<sup>2.0@beta'</sup> \ --no-update

composer update --with-all-dependencies ```

• Already on Drupal 12 without the modules? Then just composer require 'drupal/ckeditor5_premium_features:^2.0@beta' 'drupal/ckeditor5_plugin_pack:^2.0@beta'.
• Both betas switch to the CKEditor 5 UMD installation method that Drupal 12 uses. Premium Features also adds a collapsible AI container, AI Chat context configuration, configurable heading levels in the document outline, clipboard mode for collaboration, and Arabic-Indic numbering for footnotes.

I tried to kick this off a bit during DrupalCon Rotterdam, the slides give the high-level idea of the 1.x vs 2.x split: CKEditor in Drupal: News in Content Editing

Are the release notes clear? If anything in the upgrade path is confusing or breaks on your Drupal 12 test site, say it here and I will pass it on to the module maintainers.

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).

I support our Drupal page in the company, and the part in the red circle bothers everyone for some reason. Is there any way to get rid of it?

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

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 

"Running with scissors: Using AI to explore, build, maintain, contribute, and secure Drupal" is the title of my DrupalCon Orlando session proposal. I've been using and writing about AI as a Drupal developer for the past year, and I look forward to sharing my experience with fellow Drupalers at the conference. There is so much discussion about AI and Drupal, and I'd like your help with my DrupalCon session proposal.

What questions or concerns should I explore? What would you like to take away from a presentation on AI for Drupal developers?

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.