# AI-generated Rector rules for Drupal

May 7, 2026

By Oleksiy Kalinichenko

Drupal Core API changes create a steady maintenance burden for teams responsible for custom code and long-lived platforms. In a recent newsletter, **Dries Buytaert** outlined how **Drupal Digests** now analyzes Drupal Core commits, related issues, discussions, and code changes to generate **AI-generated Rector rules** automatically.

The result is already substantial: **more than 175 Rector rules** have been generated. That does not eliminate upgrade work, and the output will not be perfect, but it can reduce repetitive modernization tasks and make Drupal upgrades more scalable.

Summarize this page with AI

[](https://chat.openai.com/?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260507-ai-generated-rector-rules-for-drupal "Summarize this page with ChatGPT")[](https://claude.ai/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260507-ai-generated-rector-rules-for-drupal "Summarize this page with Claude")[](https://www.google.com/search?udm=50&q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260507-ai-generated-rector-rules-for-drupal "Summarize this page with Gemini")[](https://x.com/i/grok?text=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260507-ai-generated-rector-rules-for-drupal "Summarize this page with Grok")[](https://www.perplexity.ai/search/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260507-ai-generated-rector-rules-for-drupal "Summarize this page with Perplexity")

![Blog: AI-generated Rector rules for Drupal](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20260507-ai-generated-rector-rules-for-drupal--cover)

Drupal's upgrade story has improved significantly over the years, but the maintenance burden of Core API change is still real.

Every deprecation introduced in Drupal Core eventually becomes work for someone else: module maintainers, platform teams, agencies, and in-house engineering groups responsible for custom code. A single deprecation may be easy to fix by hand. Hundreds of them, spread across multiple modules and repositories, are not.

That is the context for **Dries Buytaert's** recent note on **AI-generated Rector rules for Drupal**. The core idea is straightforward: if Drupal Core changes can be understood systematically, then at least part of the upgrade work can also be generated systematically.

### Why hand-written Drupal Rector rules do not scale

The Drupal ecosystem already has **Drupal Rector**, and it remains one of the most practical tools available for modernizing Drupal codebases.

Rector works well when there is a reliable rule that can transform an old API usage into a newer one. The challenge is not whether Rector is useful. The challenge is the amount of human effort required to keep writing, reviewing, and maintaining rules as Drupal Core continues to evolve.

Hand-written rules do not always scale well because:

*   Drupal Core introduces a steady stream of API changes over time.
*   Each change may require someone to interpret intent from code, issues, and discussion.
*   Writing a safe automated transformation still takes engineering time.
*   Edge cases often need iteration and follow-up fixes.
*   The backlog of possible upgrade rules can grow faster than volunteers or maintainers can process it manually.

In other words, the bottleneck is often not the transformation engine. It is the production of enough high-quality rules to keep up with change.

### What Drupal Digests is doing differently

According to Dries Buytaert's newsletter, **Drupal Digests** now analyzes several inputs together:

*   Drupal Core commits
*   related issues
*   discussions
*   code changes

From that material, the system generates Rector rules automatically.

That matters because deprecations are rarely fully described in one place. The code shows what changed. The issue explains intent and migration guidance. The discussion may reveal constraints, edge cases, or implementation nuance. Looking across these signals gives a much better foundation for generating a meaningful rule than reading only a diff.

This is also why the announcement is notable beyond a single tooling improvement. It points to a broader shift in upgrade automation: not just running transformations automatically, but **deriving the transformations themselves** from project history and technical context.

### Over 175 Rector rules have already been generated

One of the strongest details in the source material is the current output volume: **over 175 Rector rules** have already been generated.

That number is large enough to be strategically interesting.

It suggests the approach is not a one-off experiment around a handful of easy deprecations. It is becoming a repeatable method for translating Drupal Core change into upgrade automation.

At the same time, it is important to stay realistic. AI-generated rules will not all be equally robust. Some rules will have bugs. Some will miss edge cases. Some may need human review or refinement before they should be trusted across large codebases.

That does not reduce the value of the work. It clarifies where the value is.

For experienced Drupal teams, the upside is not "perfect automation." The upside is a reduction in repetitive migration work, a faster path to first-pass refactoring, and a better ability to focus human effort where human judgment is actually needed.

### How to try it

The source notes include the exact command sequence to try the generated rules.

```bash
git clone https://github.com/dbuytaert/drupal-digests.git
composer require --dev rector/rector
vendor/bin/rector process web/modules/custom \
  --config drupal-digests/rector/all.php --dry-run
```

This is a sensible way to evaluate the output.

Use `--dry-run` first. Review the proposed changes. Compare them against your codebase conventions and module assumptions. Then decide whether a subset of rules is ready for broader use in CI or migration workflows.

For teams managing enterprise Drupal estates, the practical evaluation path is usually:

1.  Run on a narrow set of custom modules.
2.  Inspect diffs for false positives or partial transformations.
3.  Test affected paths, especially entity handling and custom integrations.
4.  Promote the approach gradually rather than applying every rule everywhere at once.

### Example: modernizing `$entity->original`

One of the most concrete examples from the source material is the modernization of the deprecated `$entity->original` property.

In **Drupal 11.2**, `$entity->original` was deprecated in favor of:

*   `$entity->getOriginal()`
*   `$entity->setOriginal()`

The property is **removed in Drupal 12**.

This is exactly the kind of change that fits Rector well. The old and new forms are explicit, the migration intent is clear, and many codebases may contain the same pattern.

#### Before

```php
$entity->original->field->value;
$entity->original = $unchanged;
```

#### After

```php
$entity->getOriginal()->field->value;
$entity->setOriginal($unchanged);
```

This example is useful because it shows both kinds of replacement that upgrade tooling needs to understand:

*   **property read to method call**
*   **property assignment to setter call**

That distinction matters. A simplistic search-and-replace would not be sufficient. The transformation has to recognize intent and convert usage into the appropriate accessor pattern.

### Why this matters for Drupal 12 migration planning

For teams already thinking about **Drupal 12 migration**, this approach can improve planning in a few ways.

First, it can reduce the amount of manual inventory work needed to understand what deprecations are fixable through automation.

Second, it can shift upgrade effort earlier. Instead of waiting until migration pressure is high, teams can run automated refactors incrementally as deprecations appear.

Third, it creates a more scalable model for large organizations with many custom modules. When the same deprecation pattern appears across dozens of repositories, a generated Rector rule can save substantial repeated effort, even if it still needs review.

This is particularly relevant in enterprise environments where platform owners need predictable upgrade motion. Manual refactoring does not disappear, but automated first-pass modernization can make roadmaps less reactive and less dependent on last-minute cleanup. That is closely aligned with a disciplined [Drupal version upgrade](/services/drupal-version-upgrade) approach rather than treating major-version work as a one-time scramble.

### The tradeoff: speed versus certainty

The most useful way to think about AI-generated Rector rules is not as a replacement for maintainers, but as a force multiplier.

There is an obvious tradeoff:

*   **Speed improves** because rules can be generated from project change history at much higher volume.
*   **Certainty varies** because generated rules may contain bugs or fail to capture edge cases.

Senior teams will recognize this pattern immediately. Many forms of automation are valuable before they are perfect, provided they are reviewed within a disciplined engineering workflow.

That means the right posture is neither blind trust nor dismissal.

A practical posture looks like this:

*   treat generated rules as accelerators
*   validate them against real code
*   use tests and code review to catch unsafe changes
*   feed findings back into the rule set over time

If adopted that way, AI-generated rules can make upgrade automation materially more effective without lowering engineering standards.

### A meaningful step for the Drupal ecosystem

The significance of this work is larger than a single repository of generated rules.

It suggests a future where Drupal can respond to its own evolution faster. As Core APIs change, the ecosystem may be able to convert more of that change into reusable upgrade intelligence, rather than relying exclusively on manual translation by a limited set of maintainers.

That could help reduce friction for module maintainers, improve modernization velocity for custom applications, and make long-term platform stewardship more sustainable.

It is also worth noting the ecosystem context around this work, including **Drupal Rector**, **Drupal Digests**, **Rector**, and contributors such as **Bjorn Brala** referenced in the source notes. None of these tools or people eliminate the need for engineering judgment. What they do is increase the leverage available to teams doing the work.

In practice, that kind of leverage becomes most valuable when it is paired with broader [Drupal platform modernization](/services/drupal-platform-modernization) work and proven delivery patterns from large estates such as [Veolia](/projects/veolia-environmental-services-sustainability), where predictable rollout, governance, and upgrade sequencing matter as much as the code changes themselves.

### Final thought

AI-generated Rector rules will not eliminate all Drupal upgrade work.

Some rules will have bugs. Some will miss edge cases. Some API changes will remain too context-dependent for safe automation.

But that is not the standard they need to meet in order to matter.

If tools like Drupal Digests can reliably reduce repetitive upgrade tasks, help teams modernize custom code earlier, and turn more Drupal Core change into usable automation, they can lower a meaningful portion of migration cost while helping Drupal evolve faster.

That makes this a practical and important development for Drupal developers, module maintainers, technical leads, and platform engineers.

_This article is based on source material from Dries Buytaert's newsletter, "AI-generated Rector rules for Drupal."_

### References

*   Drupal Rector: https://www.drupal.org/project/rector
*   Drupal Digests: https://github.com/dbuytaert/drupal-digests
*   Introducing Drupal Digests: https://dri.es/introducing-drupal-digests
*   Rector: https://getrector.com/
*   Generated rules repository: https://github.com/dbuytaert/drupal-digests/tree/main/rector/rules
*   Bjorn Brala: https://www.drupal.org/u/bjorn-brala

Tags: AI-generated Rector rules, Drupal Rector, Drupal Digests, Drupal Core upgrade automation, Rector rules, Drupal 12 migration, Drupal automation, Drupal

## Learn more about Drupal upgrade planning and platform maintenance

These articles extend the upgrade and modernization themes behind AI-generated Rector rules by looking at Drupal version migration planning, deprecation-driven upgrade patterns, and the operational realities of maintaining enterprise Drupal platforms over time. Together, they add strategic and implementation context for teams trying to make upgrades more repeatable, lower risk, and easier to govern across complex codebases.

[

![Drupal 11 Migration Planning for Enterprise Teams](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260304-drupal-11-migration-planning-for-enterprise-teams--cover?_a=BAVMn6ID0)

### Drupal 11 Migration Planning for Enterprise Teams

Mar 4, 2026

](/blog/20260304-drupal-11-migration-planning-for-enterprise-teams)

[

![Drupal 8 vs Drupal 9](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog--20201107--drupal-8-vs-drupal-9?_a=BAVMn6ID0)

### Drupal 8 vs Drupal 9

Nov 17, 2020

](/blog/20201015-drupal-8-vs-drupal-9)

[

![Drupal Configuration Drift in Multi-Team Platforms: Why Release Confidence Erodes Over Time](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20240918-drupal-configuration-drift-in-multi-team-platforms--cover?_a=BAVMn6ID0)

### Drupal Configuration Drift in Multi-Team Platforms: Why Release Confidence Erodes Over Time

Sep 18, 2024

](/blog/20240918-drupal-configuration-drift-in-multi-team-platforms)

## Explore Drupal upgrade and modernization services

If AI-generated Rector rules are reducing repetitive Drupal refactoring work, the next practical step is turning that momentum into a safer upgrade and modernization program. These services help teams assess custom code, remove deprecated patterns, refactor for current Drupal versions, and improve delivery practices so upgrades become more repeatable. They are especially relevant for long-lived Drupal platforms that need both implementation support and a clearer path for ongoing version changes.

[

### Drupal Upgrade

Drupal Major Version Upgrades: Drupal 8/9/10 to 11/12

Learn More

](/services/drupal-upgrade)[

### Drupal Version Upgrade

Drupal major version upgrade services with dependency and code remediation

Learn More

](/services/drupal-version-upgrade)[

### Drupal Platform Modernization

Enterprise Drupal upgrade strategy for upgradeable delivery

Learn More

](/services/drupal-platform-modernization)

## See Drupal modernization in practice

These case studies show how Drupal platforms were modernized through version upgrades, legacy cleanup, and safer long-term architecture decisions. They help contextualize the blog’s focus on reducing repetitive upgrade effort by showing the kind of real-world maintenance, migration, and refactoring work that accumulates across complex Drupal estates. Together, they illustrate why scalable automation and upgrade tooling matter when teams are responsible for long-lived Drupal codebases.

\[01\]

### [Copernicus Marine ServiceCopernicus Marine Service Drupal DXP case study — Marine data portal modernization](/projects/copernicus-marine-service-environmental-science-marine-data "Copernicus Marine Service")

[![Project: Copernicus Marine Service](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-copernicus--challenge--01)](/projects/copernicus-marine-service-environmental-science-marine-data "Copernicus Marine Service")

[Learn More](/projects/copernicus-marine-service-environmental-science-marine-data "Learn More: Copernicus Marine Service")

Industry: Environmental Science / Marine Data

Business Need:

The existing marine data portal relied on three unaligned WordPress installations and embedded PHP code, creating inefficiencies and risks in content management and usability.

Challenges & Solution:

*   Migrated three legacy WordPress sites and a Drupal 7 site to a unified Drupal-based platform. - Replaced risky PHP fragments with configurable Drupal components. - Improved information architecture and user experience for data exploration. - Implemented integrations: Solr search, SSO (SAML), and enhanced analytics tracking.

Outcome:

The new Drupal DXP streamlined content operations and improved accessibility, offering scientists and businesses a more efficient gateway to marine data services.

“Oleksiy (PathToProject) is demanding and responsive. Comfortable with an Agile approach and strong technical skills, I appreciate the way he challenges stories and features to clarify specifications before and during sprints. ”

Olivier RitlewskiIngénieur Logiciel chez EPAM Systems

\[02\]

### [VeoliaEnterprise Drupal Multisite Modernization (Acquia Site Factory, 200+ Sites)](/projects/veolia-environmental-services-sustainability "Veolia")

[![Project: Veolia](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-veolia--challenge--01)](/projects/veolia-environmental-services-sustainability "Veolia")

[Learn More](/projects/veolia-environmental-services-sustainability "Learn More: Veolia")

Industry: Environmental Services / Sustainability

Business Need:

With Drupal 7 reaching end-of-life, Veolia needed a Drupal 7 to Drupal 10 enterprise migration for its Acquia Site Factory multisite platform—preserving region-specific content and multilingual capabilities across more than 200 sites.

Challenges & Solution:

*   Supported Acquia Site Factory multisite architecture at enterprise scale (200+ sites). - Ported the installation profile from Drupal 7 to Drupal 10 while ensuring platform stability. - Delivered advanced configuration management strategy for safe incremental rollout across released sites. - Improved page loading speed by refactoring data fetching and caching strategies.

Outcome:

The platform was modernized into a stable, scalable multisite foundation with improved performance, maintainability, and long-term upgrade readiness.

“As Dev Team Lead on my project for 10 months, Oleksiy (PathToProject) demonstrated excellent technical skills and the ability to handle complex Drupal projects. His full-stack expertise is highly valuable. ”

Laurent PoinsignonDomain Delivery Manager Web at TotalEnergies

\[03\]

### [United Nations Convention to Combat Desertification (UNCCD)United Nations website migration to a unified Drupal DXP](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[![Project: United Nations Convention to Combat Desertification (UNCCD)](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-unccd--challenge--01)](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[Learn More](/projects/unccd-united-nations-convention-to-combat-desertification "Learn More: United Nations Convention to Combat Desertification (UNCCD)")

Industry: International Organization / Environmental Policy

Business Need:

UNCCD operated four separate websites (two WordPress, two Drupal), leading to inconsistencies in design, content management, and user experience. A unified, scalable solution was needed to support a large-scale CMS migration project and improve efficiency and usability.

Challenges & Solution:

*   Migrating all sites into a single, structured Drupal-based platform (government website Drupal DXP approach). - Implementing Storybook for a design system and consistency, reducing content development costs by 30–40%. - Managing input from 27 stakeholders while maintaining backend stability. - Integrating behavioral tracking, A/B testing, and optimizing performance for strong Google Lighthouse scores. - Converting Adobe InDesign assets into a fully functional web experience.

Outcome:

The modernization effort resulted in a cohesive, user-friendly, and scalable website, improving content management efficiency and long-term digital sustainability.

“It was my pleasure working with Oleksiy (PathToProject) on a new Drupal website. He is a true full-stack developer—the ideal mix of DevOps expertise, deep front-end knowledge, and the structured thinking of a senior back-end developer. He is well-organized and never lets anything slip. Oleksiy understands what needs to be done before being asked and can manage a project independently with minimal involvement from clients, product managers, or business analysts. One of the best consultants I’ve worked with so far. ”

Andrei MelisTechnical Lead at Eau de Web

\[04\]

### [Bayer Radiología LATAMSecure Healthcare Drupal Collaboration Platform](/projects/bayer-radiologia-latam "Bayer Radiología LATAM")

[![Project: Bayer Radiología LATAM](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-bayer--challenge--01)](/projects/bayer-radiologia-latam "Bayer Radiología LATAM")

[Learn More](/projects/bayer-radiologia-latam "Learn More: Bayer Radiología LATAM")

Industry: Healthcare / Medical Imaging

Business Need:

An advanced healthcare digital platform for LATAM was required to facilitate collaboration among radiology HCPs, distribute company knowledge, refine treatment methods, and streamline workflows. The solution needed secure medical website role-based access restrictions based on user role (HCP / non-HCP) and geographic region.

Challenges & Solution:

*   Multi-level filtering for precise content discovery. - Role-based access control to support different professional needs. - Personalized HCP offices for tailored user experiences. - A structured approach to managing diverse stakeholder expectations.

Outcome:

The platform enhanced collaboration, streamlined workflows, and empowered radiology professionals with advanced tools to gain insights and optimize patient care.

“Oleksiy (PathToProject) and I worked together on a Digital Transformation project for Bayer LATAM Radiología. Oly was the Drupal developer, and I was the business lead. His professionalism, technical expertise, and ability to deliver functional improvements were some of the key attributes he brought to the project. I also want to highlight his collaboration and flexibility—throughout the entire journey, Oleksiy exceeded my expectations. It’s great when you can partner with vendors you trust, and who go the extra mile. ”

Axel Gleizerman CopelloBuilding in the MedTech Space | Antler

“Oleksiy (PathToProject) is a great professional with solid experience in Drupal. He is reliable, hard-working, and responsive. He dealt with high organizational complexity seamlessly. He was also very positive and made teamwork easy. It was a pleasure working with him. ”

Oriol BesAI & Innovation (Discovery, Strategy, Deployment, Scouting) for Business Leaders

\[05\]

### [DeprexisDrupal Performance Stabilization & Secure eCommerce Payment Workflows](/projects/deprexis-digital-mental-health-platform "Deprexis")

[![Project: Deprexis](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-deprexis--challenge--01)](/projects/deprexis-digital-mental-health-platform "Deprexis")

[Learn More](/projects/deprexis-digital-mental-health-platform "Learn More: Deprexis")

Industry: Digital Health / Mental Health

Business Need:

The Deprexis mental health digital platform on Drupal required stabilization, faster performance, and a secure ecommerce payment workflow to support online services. The solution needed to meet strict reliability and security expectations common for digital healthcare products.

Challenges & Solution:

*   Critical performance bottlenecks were identified and resolved with caching and rendering optimizations. - A secure eCommerce/payment module was implemented with ABank integration for online checkout. - Automated regression coverage was introduced to protect sensitive order workflows and reduce release risk. - Quality gates were improved through test-driven delivery and repeatable validation in CI.

Outcome:

The platform was stabilized, performance was improved, and secure checkout workflows were delivered with strong automated coverage to reduce operational and compliance risks.

\[06\]

### [London School of Hygiene & Tropical Medicine (LSHTM)Higher Education Drupal Research Data Platform](/projects/lshtm-london-school-of-hygiene-tropical-medicine "London School of Hygiene & Tropical Medicine (LSHTM)")

[![Project: London School of Hygiene & Tropical Medicine (LSHTM)](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-lshtm--challenge--01)](/projects/lshtm-london-school-of-hygiene-tropical-medicine "London School of Hygiene & Tropical Medicine (LSHTM)")

[Learn More](/projects/lshtm-london-school-of-hygiene-tropical-medicine "Learn More: London School of Hygiene & Tropical Medicine (LSHTM)")

Industry: Healthcare & Research

Business Need:

LSHTM required improvements to its existing higher education Drupal platform to better manage and distribute complex research data, including support for third-party integrations, Drupal performance optimization, and more reliable synchronization.

Challenges & Solution:

*   Implemented CSV-based data import and export functionality. - Enabled dataset downloads for external consumers. - Improved performance of data-heavy pages and research content delivery. - Stabilized integrations and sync flows across multiple data sources.

Outcome:

The solution improved data accessibility, streamlined research workflows, and enhanced system performance, enabling LSHTM to manage complex datasets more efficiently.

“Oleksiy (PathToProject) has been a valuable developer resource over the past six months for us at LSHTM. This included coming on board to revive and complete a stalled Drupal upgrade project, as well as carrying out work to improve our site accessibility and functionality. I have found Oleksiy to be very knowledgeable and skilful and would happily work with him again in the future. ”

Ali KazemiWeb & Digital Manager at London School of Hygiene & Tropical Medicine

![Oleksiy (Oly) Kalinichenko](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_200,h_200,g_center,f_avif,q_auto:good/v1/contant--oly)

### Oleksiy (Oly) Kalinichenko

#### CTO at PathToProject

[](https://www.linkedin.com/in/oleksiy-kalinichenko/ "LinkedIn: Oleksiy (Oly) Kalinichenko")

### Do you want to start a project?

Send