Sustainable Growth

How to Make the Most of Organic's Extensible Architecture

One of the largest advantages of Organic is the flexibility and extensibility of the architecture for Content, Ads, Affiliate, and more.

blog-art-p-2

Organic is unique in offering both value-driving components out of the box, as well as a framework for any publication to build domain-specific products on top of the lightning-fast infrastructure. In short: Organic handles baseline operations for online publishing so publishers’ internal technical teams can focus on business-specific products and integrations with clear ROI.

Why extensible architecture matters

In addition to a growth-minded feature set, data hosting options, and a headless React frontend, Organic offers an infinitely extensible architecture for businesses with dedicated tech resourcing. 

This allows publishers to relinquish concern about maintaining baseline operations and instead cleanly and clearly focus on the content and other products unique to their business.

For larger publishers that means less noise and more targeted development on projects like technical consolidation for new acquisitions, domain-specific partnerships and tools, and unique widgets that improve audience behavior metrics for their particular readership.

How Organic collaborates with publisher teams

Organic's designed content management system workflows have been established to grant autonomy to external engineers and contributors while preserving the stability due to Organic's rock-solid foundation. Find below an overview of the architecture, each team’s ownership of development tasks, and the workflow for reporting bugs, requesting features, and proposing code changes to the Organic content repository.

Please also feel free to reach out Organic Support via email (support@organic.ly) or the Help Desk to learn more.

Architecture Overview

Publisher-side engineers are given access to site-specific repositories in order to make frontend and business-specific backend changes. With this architecture, site-specific changes can be released in accordance with each publisher’s specific timelines and approval processes. 

Each domain that fully integrates with Organic (including the headless backend and DevOps management) has two relevant repositories: the backend plugin and the headless frontend. In addition, enterprise clients may have access to an additional backend plugin repository that impacts more than one domain across their business (commonly referred to as an “organization” repository). 

On occasion, a publisher’s technical team member has an idea to improve the core Organic codebase. We welcome such suggestions to the organic-content repository and ask they be submitted to Organic for review and approval. It is recommended that contributors propose these changes to Organic before beginning development work to obtain preliminary concept approval. 

Approved changes will be released by Organic according to their internal procedures, with or without prior notice to the original contributor. Release timing exceptions may be made for publisher contributions that have external dependencies if communicated to Organic in advance.

Organic's team provides ongoing support to client-side teams at regular intervals, including cross-team project management, success planning, business reviews, best practices presentations, user education and training, and other regular check-ins.

Code Accountability

Publishers have the autonomy to pursue their own changes, feature additions, and bug fixes. In addition, publishers with Premium Support also have dedicated engineering support hours, which can be used to ask Organic to troubleshoot integrations, add new fields or blocks, or make elements of the offering configurable for client-side replacement. 

External engineers and Organic engineers have ownership of different aspects of site maintenance as follows:

Non-Organic engineers tend to work on:
  • Site-specific frontend changes or redesigns
  • Site-specific block creation
  • Site-specific bugs
  • Site-specific scripts
  • Ads integration with non-Organic ad providers
  • Google Tag Manager changes (excluding consent management changes when CMP relationship is managed by Organic)
  • Third-party integrations, including Google Analytics
  • Updating the latest Organic Content versions on their own timelines, at the domain level
Organic engineers are responsible for:
  • Platform-wide new blocks, features, and improvements
  • Platform-wide bug resolution
  • Integrations with other Organic products, including Organic Ads and Organic Affiliate
  • CMP changes when Organic handles consent management
  • Updates and versioning for key required plugins like Yoast
  • Accepting or rejecting all proposed changes to organic-content repo made by external engineers
  • For DevOps clients: CDN-level changes

Creating and managing pull requests

To maintain an efficient and streamlined pull request (PR) workflow for Organic Content core, we have established a set of guidelines for creating and managing PRs. For the latest version of these guidelines, please visit our documentation site.