The main focus for this month's Melbourne Drupal Meetup was Kobus Van Wyk demonstrating his Entity Fields Report module, which addresses common challenges developers face when analysing field usage during site migrations. The session also covered proper Drupal module development practices..
Entity Fields Report module – a summary
Drupal site migrations often hit a frustrating roadblock when developers need to understand what fields exist in the current system. Kobus from Salsa faced this exact challenge when a client asked to migrate their Drupal site to . Without a clear way to analyse field usage, developers typically resort to complex SQL queries or struggle with inadequate existing tools. His Entity Fields Report module solves this problem by providing comprehensive field analysis, filtering capabilities and export functionality that makes migration planning straightforward and reliable.
Why existing Drupal field migration tools fall short
When Kobus needed to migrate a client's Drupal site to , the first challenge was understanding what fields existed in the current system. Drupal's backend does not provide a built-in report for field analysis, which forces developers to resort to complex SQL queries or hunt through existing modules that don't quite meet their needs.
Kobus investigated three existing solutions on drupal.org. The Better Fields module offered decent functionality but felt clunky and lacked essential export capabilities, while the Entity module, which provides insights about entity type structure, didn't meet his specific requirements for migration workflows. The Content Model & Site module provided more comprehensive information about site architecture, but still didn't deliver the specific field usage analysis that migration projects require.
While SQL queries might seem like an alternative, they quickly become problematic with status checks for unpublished content, deleted records, and complex table joins that often produce duplicate data or miss edge cases entirely.
How to analyse Drupal fields without complex SQL queries
To solve this field analysis challenge, Kobus built the Entity Fields Report module. The module addresses the problem through a straightforward admin interface that requires no SQL knowledge. Once enabled, the module appears under the Reports section and automatically scans your entire Drupal installation to build a comprehensive field inventory.
What makes this module particularly useful is its smart filtering system. Instead of preset options that might not match your site, every dropdown menu shows what's actually on your site. If your site has 50 fields, the interface shows all 50 with precise details about where they're used. You can group results by field ID, entity type, entity bundle, widget type, or widget modules to understand field patterns across your site.
During his live demonstration, Kobus showed how the module reveals field usage counts for each entity type. A field might appear on blocks, media, nodes, paragraphs, and users, with specific counts showing how many times it's actually used. Fields with zero usage immediately stand out as potential cleanup candidates. The export functionality lets you download specific field data as CSV files, making it easy to share findings with clients or manipulate data in spreadsheet applications for deeper analysis.
Using field analysis to improve site performance and migrations
The Entity Fields Report module is especially useful during migration projects where understanding field usage becomes critical. Kobus explained how developers can run the report before starting a migration to document exactly what fields exist and how they're used. This creates a baseline for field mapping between the old and new systems.
Fields showing zero usage raise important questions during migration. Are these fields genuinely unused and safe to remove? Or did something go wrong during the content migration process? Kobus demonstrated how clicking on any field count takes you directly to the specific entities using that field, letting you verify whether the data migrated correctly, rather than discovering missing content weeks later.
After migration completion, running the report again provides validation that the content moved correctly. If you expected 10 items to migrate and the report shows 10 items in the new field structure, you know the migration worked as planned. This before-and-after comparison gives migration teams confidence that nothing got lost in the process.
This approach also helps with long-term site maintenance by making it easy to identify and clean up truly unused fields that accumulate over time, potentially improving overall site performance.
Best practices for developing a new Drupal module
Kobus shared the development process behind his module, emphasizing the importance of following proper Drupal contribution workflows. The first step should always be checking drupal.org to see if a suitable module already exists. If you find something close, consider contributing improvements to the existing project rather than creating something entirely new.
When building a new module, following Drupal code standards is essential. The module must include comprehensive tests, as submissions without tests will fail the Drupal security advisory review. Kobus stressed the importance of running pre-checks using code , PHP standards, and PHP unit testing before submitting anything.
The Drupal.org pipeline runs three stages automatically: building your code, checking validation, and running unit tests. All of these must pass before you can submit for security advisory review.
Kobus plans to publish his Entity Fields Report module on drupal.org within the next few weeks, once he completes the testing requirements. This methodical approach ensures the module meets Drupal's quality standards and will be maintainable for the community long-term.