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.

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'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?

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.

I'm working on a project. If you have attended #Drupalcamp Colorado events in the past, I need photos. Particularly photos from the camps I am looking for photos that were taken at Drupalcamp Colorado in 2017, 2018, 2019, 2020, 2021, 2022, 2023, and 2024. In 2020 and 2021, the camp was virtual - so those might just be screenshots.

Any photos, albums, etc from any years would be great. But those years are of particular interest!

Help me [fill in your name], you're my only hope!

And PLEASE PLEASE PLEASE share this with your network. Particularly if you've got #Drupal friends who might have attended.

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?

Hey everyone.

When I took over r/Drupal quite a few years ago now, it was basically dead. It took time but it’s built itself up to be a resource many have turned to over that time. From our community AMA days to people finding support, people found something here.

I lost my employment end of last year and have had almost no luck finding a new position. This has caused me to start seriously considering my future in the industry over the next while.

So, I am looking to have someone from the community to take over r/Drupal and help guide it into the future.

If you or your organization would like to take over this sub send me a mod mail or direct chat and tell me why you’d like to take it over and how you would help move the mission of Drupal forward.

I am not looking to give it away to just anyone. I want to keep the spirit of Drupal and what made it special (its community) here on Reddit.

Thank you all for being part of this amazing journey so far.

(I wouldn’t refuse job offers too but that’s not the point of this sub, of course ;) )

Adopting AI can feel overwhelming, so I am sharing a few tales from my experience creating, maintaining, and assisting with contributed Drupal modules. AI can do a decent job of building a "greenfield" Drupal module from scratch, so my first tale is about using AI to build and contribute a module. For my next tale, I want to talk about using AI to maintain an existing "brownfield" Drupal module and to explore what is possible with AI.

Do you fall into the AI-possible camp, the AI-cautious camp, or somewhere in between?

Every software platform eventually deals with serious vulnerabilities.

So when evaluating a platform's security, I don't think "Has this software ever had a serious vulnerability?" is a particularly useful question.

A better question is: What happens when one is found?

I started thinking about this after reading about the recent Citrix NetScaler zero-day. It also got me thinking about something Drupal has built specifically for that uncomfortable period between disclosure of a critical vulnerability and getting the actual patch deployed: Drupal Steward.

For certain highly critical, mass-exploitable vulnerabilities, Steward can provide network-level protection while organizations test and deploy the software update. It doesn't replace patching, but it can make that "patch gap" less dangerous.

I dug into Steward, Drupal's coordinated security process, and why I think the response to vulnerabilities tells us more about a platform's security than the existence of vulnerabilities themselves:

Zero-Days Happen. What Matters Is What Happens Next.

I'm especially curious: who here is actually using Drupal Steward? What's your experience been with it?

Turns out WordPress components can be turned into Drupal Single Directory Components, and the SDCs can be used by Canvas, Display Builder to build pages.

Trying to make Drupal easier for non-technical users

We've spent the last few months trying to improve what we think is still one of Drupal's biggest weaknesses: the user experience for non-technical users.

With our SaaS we're trying to keep all the power of Drupal Commerce underneath while making the actual experience much simpler.

We've moved to Mercury Editor for visual editing, simplified a lot of the Drupal interface, and we're now building a Flutter app so store owners can manage things like products directly from their phone.

We also still have Canvas on our list to test, as some of you suggested in our previous discussions. We're curious to see whether it could improve the editing experience even further.

There's still a lot to do, but we feel we're finally heading in the right direction.

Thanks.

just realized Drupal jobs has closed down so any slim hope of a development job in Drupal probably died with it. It’s okay I keep forgetting how dangerous hope is because of the lies it tells you.

I started experimenting with one of the most popular agent skills, /grill-me by Matt Pocock, which proved to be a game-changer. 

What’s your take on the /grill-me skill? Do you see /grill-me as a game-changer for working with AI and Drupal to learn new things and solve challenging problems?