Skip to main content

Helping CEPR Launch the Growth Research Platform

Abstract image of nodes connected by lines

Overview

The Centre for Economic Policy Research (CEPR) is one of the world's leading economics research networks, connecting nearly 2,000 affiliated researchers across 30 countries. Their work shapes economic policy at the highest levels — from central banks to international institutions. Behind the scenes, a central CRM system manages thousands of researcher profiles, publications, and events.

When CEPR set out to build the Growth Research Platform (GRP) — a new public-facing site pulling live data from that system — they ran into a series of interconnected technical challenges. They needed experienced Drupal and CiviCRM support to help them solve each one.

Challenge

CEPR's goal was to build a public platform where researchers, policymakers, and the public could discover publications, events, and researcher profiles. The complexity was in the architecture.

All the data lived in a central CiviCRM-powered system that CEPR's team depended on daily. The new GRP site needed to read from that system without overloading it, display publication attachments without exposing the broader file system, keep its search results current as data changed, and let staff manage content without inadvertently creating duplicate records.

Each challenge was solvable on its own. The difficulty was that they were all connected, and they all had to work together for a launch.

Solution

  • Designed a read-only database architecture so GRP could access CiviCRM data without adding expensive queries to the primary system. This included Redis caching configuration, domain-specific settings, and guidance on handling smart groups and scheduled jobs in a multi-site context.
  • Built a secure file download system for public access to publication attachments. Publications on GRP are CiviCRM contacts with file attachments stored on the central Hub. We built a custom module to allow selective public access to specific files and a matching field formatter on GRP — so readers could download what they needed without the broader file directory being exposed.
  • Diagnosed and resolved a duplicate contact problem where GRP admin users logging in were triggering blank contact records in the central CiviCRM. We tested core-level solutions, identified the risks, and proposed a multi-site configuration approach that separated user-to-contact sync behavior by domain.
  • Built a real-time search indexing system so that when contacts, publications, or events were updated in CiviCRM, GRP's search index updated automatically. This involved a custom REST endpoint on the GRP sites and a queue-based notification system — changes batch and process through cron rather than slowing down the save operation in real time.
  • Resolved a compatibility issue between CiviCRM Entity and Search API that was preventing CEPR's custom contact-type entity architecture from being indexed correctly. We fixed the bundle handling problem, contributed a patch upstream to the CiviCRM Entity module, and got the indexes working.
  • Developed a unified taxonomy system bridging Drupal vocabulary and CiviCRM option groups. Staff can now tag both Drupal content and CiviCRM researcher profiles using the same terms, and a single landing page aggregates both — making it possible to browse all publications and researchers associated with a given research theme. This required custom tokens and a multi-valued Search API field mapping module built specifically for this architecture.
  • Conducted a performance audit after launch and provided specific recommendations: enable CiviCRM's asset cache, configure Redis for CiviCRM caching, fix missing extension paths, enable CSS and JS aggregation, and replace the automated cron module with a scheduled Drush command to avoid unpredictable page load spikes.

Results

By building a read-only database strategy, a real-time re-indexing pipeline, and a unified taxonomy system, CEPR was able to launch the Growth Research Platform — making researcher profiles, publications, and events publicly discoverable without disrupting the central system their team depends on every day.

The primary database runs without carrying the overhead of public read traffic. Publication files are accessible to the public without exposing the broader file system. Search results reflect changes made in CiviCRM without requiring manual re-indexing. Content from two different systems, Drupal and CiviCRM, can be browsed together under shared taxonomy terms.

The work also contributed back to the open-source community. Patches developed during this engagement were submitted upstream to the CiviCRM Entity module, available to any organization running a similar stack.

Takeaways

Multi-site CiviCRM and Drupal architectures are achievable, but they require careful attention at every layer. Caching, domain configuration, user sync behavior, scheduled jobs, and file permissions all need to work together. Missing any one piece creates problems that are hard to trace.

Having consistent technical support from someone who understands the full system — not just one piece of it — makes that kind of work faster and more reliable.

If you are planning improvements, we can help.