Recently, I’ve noticed certain trends in our industry which I believe will greatly impact the evolution of Drupal. It’s undeniable: the CMS landscape is changing as the future of the web gears toward content APIs and other ways of interacting with a content storage system. As this shift deepens, all-in-one, full-stack Drupal packages will become less important than Drupal’s ability to integrate and operate with other content stores and applications that aggregate that content for display.
There are already numerous examples of this. Social integrations (with Disqus, for instance) allow social media conversation to happen directly on the page, but not in the CMS. Other integrations, like advertisements or the injection of third-party content, demonstrate how necessary it has become for a CMS to manage external content from multiple sources. Stock tickers and quotes are a perfect example, as they inject stock quotes from external sources into their CMS instead of aggregating that content internally. Those quotes are not generated or stored within Drupal - but Drupal allows site maintainers to easily manage the location and format of that data.
Drupal has proven itself to serve as an excellent structured content store, and Drupal 8 will take that a step further by enabling better access and integration into the content store. As Drupal evolves to becomes more of a robust content repository, its ability to seamlessly integrate disparate content and data will likely out-weigh its prominence as a front-end rendering engine for HTML. The front-end itself is likely to move toward being a separate application altogether, likely based in a JS framework (e.g. Angular or React) or serving the ever-growing mobile landscape. Drupal is also moving in this direction by building front-end abstractions (like Twig) that are lighter, faster, and more suitable than developing a traditional Drupal theme. This provides an opportunity to create more efficient and speedy development cycles by integrating new tools for design in Drupal that reach the web more broadly. New tools like Pattern Lab and Mustache Templates can begin to extend Drupal’s front-end capabilities in new ways, further pushing Drupal’s value as a content store rather than an engine for creating websites.
Enterprise media sites have taken the lead on embracing Drupal as a unified content repository. Thomson Reuters’ 2012 Olympic site, for example, expertly utilized Drupal as a content ingestion engine. By integrating with the company’s extensive content feed service, Media Connect, Reuters accumulated photos, videos, and text articles to populate and publish through a Drupal platform. In the coming years we will become the standard approach for more media and publishing properties, and I suspect that the “enterprise” will follow suit.
These developments have an inevitable outcome which is captured by the idea of COPE (“Create Once, Publish Everywhere”), a concept illustrated beautifully by NPR’s API. COPE isn’t a new concept, but the Drupal community has only recently begun to fully utilize it in terms of ingesting content from multiple sources, as well as publishing and distributing content through multiple channels. In the coming years, COPE will manifest in a number of ways, but for the purposes of this blog post I am focusing on content APIs as the most relevant implementation of COPE for the Drupal community (for now).
Content APIs in Drupal will bring about the clean separation between content creation, storage, and management, as distinct from the display of content. This separation allows managing content with a common mechanism, yet rendering it in through a variety of experiences. It will become commonplace to build user experiences using the myriad of flexible and dynamic front-end frameworks on top of a Drupal API, capturing the potent capabilities of Drupal as a content aggregation system. Not only will building multi-channel responsive applications with amazing design be much easier, but content creators will gain greater control over access to their content. Private companies, for instance, can sell access to valuable content, while government agencies can provide public access.
Drupal 8 is an important turning point, bringing Drupal closer to the decoupled, API-favorable content engine it will evolve into - a positive development. What changes do you see in the CMS landscape, and how will Drupal play a role? Comment below!