Explaining the coding principles guiding the development of PoP’s base code

There are several coding principles guiding the development of all code in PoP:

1. Reuse and leverage

All code we produce must be reusable, as much as possible, all through out the application. In addition, we use existing 3rd party (open source) libraries to provide the functionalities we need, and integrate them to the framework. Since the PoP framework has been done, all from the beginning, by just one person, reusing code from both internal and external sources been of extreme importance.


WordPress code reuse

WordPress currently powers 28% of all websites in the world, and their community of developers is huge. It seems that, for every new technology out there, there will be a plug-in implementing it in no time. By using WordPress in the back-end as a service, PoP leverages the power of the WordPress community, integrating their plugins into the framework.


Isomorphic rendering

Isomorphism means that developers can implement the code only once and use it everywhere. Those single pieces of code are Handlebars javascript templates, from which PoP is able to create the HTML for:

  • front-end rendering, powering the Single-Page Application architecture
  • server-side rendering (SSR), producing HTML on the server for the initial website load
  • email digests and newsletters


Atomicity/Reusability of modules

A PoP module is either an atomic/reusable functionality, a composition of other modules, or a combination of the two. This way, modules can build upon each other, create complex layouts and structures from very tiny and simple components, as if playing with LEGO.

This scheme allows for implementing Separation of Concerns, in which a module tackles a specific problem and nothing else, and the collaboration among developers, in which several developers can be working alongside each other on the same module, without conflict.



PoP’s decentralized architecture enables to create applications which get their data from different smaller websites, emulating microservices. This way, content that needs to be repeated in several websites can be extracted into an external entity and feed its data to everyone who needs it.

For instance, if you have 3 websites with ads, and all 3 need to show the same ad, instead of creating the same post with that ad image in all 3 websites, it is possible to create a 4th website, placed under ads.mydomain.com, create the ad just there, just once, and inject its data (in this case, the ad) into all 3 other websites.


2. Decouple

All code in PoP is decoupled as much as possible. We try to not depend on any specific software solution or vendor, and the implementation of the base code decouples the business logic, the presentation, accessing the database, and the configuration into different layers, which do not overlap into each other.

In addition, modules are composed in a top-down manner, and configured through dependency-injection, so that a developer overseeing the construction of the application at the top can change the behaviour of the different components, which are being built, at the same time, by other developers.


No dependency on WordPress (in theory)

Even though PoP currently is based on WordPress, this dependency was built loosely in the architecture, so that a different software system could replace WordPress if needed. Because PoP is built using PHP, other CMS solutions also based on PHP, such as Joomla or Drupal, could be plugged in without much trouble (this is in theory; in practice, there is still plenty of work to do to achieve an absolute decoupling, but the overall architecture has already been designed in this fashion and for this purpose).


Decoupling of business/presentation/database/configuration layers

All following elements are decoupled one from each other, and as such can be developed, concurrently, by different developers with different skills:

  • View design (through Handlebars javascript templates) and configuration (through PHP objects)
  • Javascript functions
  • Styles
  • Access to the database


Dependency injection

All modules can declare what properties can be configured, and allow their parent modules to modify this configuration in a top-down manner, in which upper modules take precedence over lower modules. This way, a developer overseeing the construction of the application can modify the behaviour of the application accordingly, and needs not bother the team building the components. This scheme effectively adds a layer of decoupling even among the development team.


3. Cache

PoP makes heavy use of caching, wherever possible. It implements several layers of caching:


Server cache (through WP Super Cache)

This is the standard cache: whenever a URL is requested, it caches the produced HTML in the server, so that the next request to the same URL needs not generate the response again.


Configuration cache

Because the configuration is decoupled from everything else, such as the object data, then it can be cached. Differently from the server cache, the configuration cache does not rely on the URL, but on the type of page that is requested, which can be applied more often.

For instance, if two event pages are requested, even though they have different object data (i.e. their title, content, date, etc), their configuration (i.e. the classnames, color, fonts, etc) will still be the same. Then, requesting the first event will generate the page as usual, but requesting the second one will only need to get the data from the database and nothing else, since the configuration can be reused after it was generated and cached for the first event. This way, the second request will be processed faster.


Content CDN + Asset CDN

A CDN is a network of servers which is located near the user, so requesting resources from it is generally faster than requesting them from the server. All static assets from the application (such as images, .js and .css files, PDFs, etc) can be normally cached in CDN, and PoP is no exception. However there is nothing extraordinary here.

There is magic, though, concerning the Content CDN: dynamic content, such as a post data, can also be cached in a CDN on its way back to the server. PoP indeed makes the best from both worlds: dynamic content generated in a CMS, such as WordPress, which behaves as if coming from a static site generator.


Service Workers

Finally, PoP implements the offline first strategy for caching all accessed content in a browser cache, so that it can be retrieved faster, and even when the user is offline. Through the use of the Cache then network strategy, PoP will serve content in no time, directly from the browser cache, but still notify the user if/when there is more up-to-date content.

Welcome to the PoP framework!
Break the information monopoly

the PoP framework is open source software which aims to decentralize the content flow and break the information monopoly from large internet corporations. Read more.

Sign up to our newsletter: