Connected Community and Learning

Why we built it

Our community experience and learning experience lived in two different open-source Drupal products: Open Social and Opigno. Each was strong at its own job, but users experienced them as two separate systems. They could discover a conversation or organization in the community, yet courses, enrollment, and progress lived elsewhere.

Members needed to find courses where they already participated, enter the learning system without another sign-in, and see relevant learning status back in the community. We also wanted what the community already knew about a member to help decide which courses they could reach. All of that had to feel like one product without merging databases or tightly coupling two independently deployed systems.

My role

I designed the integration between the two systems and built the core synchronization, local course catalog, Search API integration, OAuth and REST communication, and secure course-launch flow. I also worked through the trust boundaries, failure behavior, and how community-side membership rules could influence learning access, and I reviewed the work that touched the integration on both deployments.

The project was still in its final stages of development when my work on it ended, so this case study focuses on the architecture and integration work I completed rather than presenting it as a finished production rollout.

What it was designed to unlock

The integration was designed to let members discover learning alongside people, groups, and organizations already in the community. Because synchronized course records existed locally in Drupal, courses could participate in Views, search, dashboards, and planned community-side access rules such as membership-based course eligibility.

The learning platform remained responsible for the actual training experience and learner progress, while the community handled discovery, access, and the surrounding member experience. Open Social and Opigno stayed independently deployable and responsible for their own data.

What we added to the platform

OAuth 2 credentials authenticated communication between the systems, with secrets managed through Drupal’s Key integration. A versioned REST API contract defined requests, responses, synchronization checkpoints, and errors. Course records were synchronized into local entities and indexed with Search API, so discovery remained fast, searchable, and available even when the learning system was not responding.

Launch authorization used a short-lived, one-time token instead of putting identity or durable credentials in a URL. Learner progress followed a separate synchronization path and appeared through personalized lazy builders, allowing the surrounding course page to remain cacheable. Course discovery stayed local to the community, while only narrowly authorized launch and learner-state requests crossed the boundary into the learning system.

How synchronization and launch worked

A scheduled coordinator acquired a lock, read the last saved checkpoint, and requested the next bounded batch through the authenticated REST API. It validated the response, updated local course entities, queued Search API indexing, and saved the next checkpoint only after the batch succeeded. Interrupted work resumed without skipping records.

For launch, Open Social checked the learner’s access and requested a short-lived token. The browser carried that token to Opigno, where it was consumed exactly once and checked against the intended learner and course before the destination opened. Expired, reused, or mismatched tokens failed without revealing hidden course information.

Drupal under the hood

OAuth 2, REST, and Key

Separated machine authentication from human sessions and kept secrets out of exported configuration.

Entity and Search APIs

Created a Drupal-native local catalog with normal field, display, access, Views, and indexing support.

Queue, Lock, and Flood APIs

Controlled background work, prevented overlapping synchronization, and rate-limited sensitive requests.

HTTP client, cache metadata, lazy builders, and Twig

Handled remote failure safely while keeping public pages reusable and learner status personalized.

Why I chose this approach

I chose to synchronize course information into the community instead of making every course display depend on a live request to the learning platform.

Keeping course records locally meant Drupal could use its normal tools for search, Views, dashboards, and relationships to community data. It also created a clean place for community-side rules, such as membership, to influence learning access.

The learning platform still remained responsible for the actual course experience and learner progress. That separation let each system continue doing the job it was built for while giving us a practical way to make them feel like one product.

It required more synchronization work than simply embedding a remote catalog, but it reduced runtime dependency between the two systems and gave the community much more control over how learning appeared and behaved.