Andy Marquis Outlines Custom Field’s Role Alongside Paragraphs in Drupal

Drupal site architects weighing Paragraphs against Custom Field now have a clearer framework from Andy Marquis, maintainer of the Custom Field module. In a conversation with Kazima Abbas for The Drop Times, Andy said the strongest gains tend to appear in render performance, cache efficiency, editorial form speed, database size, and migration effort. The module stores structured data as field values rather than separate entities, a design intended to reduce entity loading and field table overhead on sites with repeatable or nested content.

The discussion matters because Paragraphs remain common for reusable page components, but deep nesting can expand queries, revisions, entity loads, and cache complexity. Andy recommends a hybrid decision model: reserve Paragraphs for components that need per-item revisions, moderation, workflows, or reusable modelling, and use Custom Field for lightweight structured data that does not need those entity-level behaviours. That distinction gives Drupal teams a way to simplify content models without removing Paragraphs where its governance features are required.

Custom Field’s core difference is storage. Instead of creating separate entities for each repeatable item, it stores related subfields as regular field values in a single field table. That model can reduce the work Drupal performs when rendering structured content, especially on sites with high-volume repeatable components or deeply nested content structures.

Editorial performance is another production concern. Andy said editors benefit from fewer queries, cleaner forms, and the ability to group related subfields through flexible layouts configured in Drupal’s Field UI. For teams maintaining complex content types, this can reduce the need for additional contrib modules or custom code simply to achieve common widget and formatter behaviour.

Database growth is a related issue. Traditional Paragraphs implementations can create large volumes of entity, revision, and field tables over time, especially when small repeatable structures are nested inside larger page components. Andy said Custom Field keeps those structures compact by consolidating related values into one table, which can reduce long-term configuration and storage overhead.

Migration effort can also change substantially when repeatable structures are simplified. Andy cited one site owner who reported cutting a large content migration from roughly two days to about 15 minutes after switching from Paragraphs to Custom Field. He also pointed to integration with Feeds as a practical route for importing structured data into custom fields.

Andy’s recommended architecture is not a full replacement rule. Paragraphs remain appropriate when a component needs separate revision history, moderation states, editorial workflows, or reusable modelling. A common pattern, he said, is to keep Paragraphs for true dynamic components while consolidating the many small fields inside those components into a single Custom Field.

That consolidation introduces its own planning questions. Schema flexibility is the main long-term concern because Drupal core locks field storage changes once content exists, protecting data but limiting later structural edits. Andy said the related Field Updater Service helps address this by offering mappings, Drush commands, and update hook examples for deployments.

The current Drupal.org page for Field Updater Service lists a 1.0.0-beta2 release and notes that there are currently no supported stable releases, so production teams should review release status before depending on it for migration tooling. Andy’s broader point is that schema evolution should be treated as part of the content model plan, not as an afterthought. Teams adopting Custom Field should evaluate schema changes, querying needs, multilingual requirements, content governance, and maintainability before consolidating fields.

You May Like

Article

Drupal Security Team Issues Eight Advisories for Core and Contributed Modules

Article

Drupal Security Team Issues Eight Advisories for Core and Contributed Modules

Migration planning should move in phases rather than through a single rewrite. Andy recommends starting with high-impact and low-complexity areas such as simple repeating sections, cards, accordions, or metadata blocks. He also advises teams to use the migration window to remove outdated modules, simplify overbuilt content models, and address technical debt connected to editorial dependencies.

Sites with revisions, nested structures, search indexes, and API consumers need additional checks. Existing Search API indexes, JSON:API consumers, GraphQL Compose schemas, and editorial workflows should be reviewed before replacing Paragraphs-based structures. Andy said Search API and JSON:API work well with Custom Field, while GraphQL Compose integration provides clean schemas for subfields.

Community feedback reflects the scale of the problem on some sites. Josh Fabean said he is migrating a client away from Paragraphs to Custom Field after the site accumulated more than one million paragraph entities, and the database had grown because of revisions and Paragraphs data. The feedback supports Andy’s view that the module is most relevant where deeply nested or repetitive entity structures create operational overhead.

Drupal.org currently describes Custom Field as dynamic custom field types with extensive widget and formatter plugin support, storing data in a single table. As of 24 June 2026, the project page says 5,904 sites report using the module, and release 4.0.8 was published on 23 May 2026 with support for Drupal 10.3 and Drupal 11. The project’s stable releases are covered by Drupal’s security advisory policy.

The module’s integration map has expanded beyond its original storage and form-building use case. Drupal.org lists integrations including AI, Entity Browser, Feeds, Field Updater Service, GraphQL Compose, Linkit, Search API, and Token Browser. Included submodules include custom_field_ai, custom_field_entity_browser, custom_field_graphql, custom_field_jsonapi, custom_field_linkit, custom_field_media, custom_field_sdc, custom_field_search_api, and custom_field_viewfield.

Several areas still stand out for Drupal teams using modern architectures. Andy identified JSON:API, GraphQL Compose, and Search API as important for decoupled and headless projects because structured subfield data is easier for downstream consumers to work with. He also pointed to AI Automator, Single Directory Components, and advanced formatters as areas where structured data can reduce custom code while improving editorial control.

Community contribution remains important for the module’s next stage. Andy said the project most needs testing around integrations and edge cases, documentation support, and real-world usage stories from developers. He is also working on a major documentation overhaul with MkDocs, planned for the next release.

For Drupal architects, the practical takeaway is not that one module should replace every content modelling pattern. Custom Field is strongest where structured values can remain field data, while Paragraphs is strongest where each item needs entity-level editorial control. Teams planning migrations should test the model on low-risk structures first, review indexing and API consumers, and then expand where the content governance model supports the change.

More information about the module, its releases, integrations, and installation command composer require 'drupal/custom_field:^4.0' is available on the Custom Field project page on Drupal.org.