We have finally started migrated PoP to Composer components, hence it will soon be possible to install it with a simple `composer require` command. We are expecting this task to be finished around end of 2019. The migration involves the following actions:

• Convert all code to PSR-4
• Abstract all WordPress behind an interface, implemented on its own component
• Instantiation of objects through Symfony’s Dependency Injection component
• Setting configuration options through Symfony’s Dotenv component

All components already migrated can be found under PoP’s account in GitHub: github.com/getpop. To date, we have migrated the following components:

• root: Declaration of dependencies shared by all PoP components
• engine-wp: Implementation of PoP Engine for WordPress
• engine-wp-bootloader: PoP Engine Bootloader for WordPress
• engine-symfony: Implementation of contracts for PoP Engine through Symfony components
• hooks: Contracts to implement hooks (filters and actions) for PoP
• hooks-wp: WordPress implementation of the contracts to implement hooks (filters and actions) for PoP
• translation: Translation API for PoP components
• translation-wp: Implementation of the Translation API for WordPress
• cache: Contracts for implementing caching for PoP components
• cache-symfony: Implementation of the contracts for caching through Symfony Cache
• filestore: Base classes to save files to disk, read them and reference them through an URL
• spa: Single-Page Application for PoP

In addition, we have created a Bootstrap project for WordPress, enabling to quickly install WordPress together with PoP. This project will contain the most basic PoP components, which will be continuously added as their migration is completed.

The most important component in PoP is engine, since it contains the fundamental logic for rendering components in PoP. This component is currently being migrated. Once its migration is complete, PoP’s fundamentals will be in place, so that any application will be able to use it. From then on, the other components to migrate will be features.

The migration is taking a very long time due to the following reasons:

• PoP’s code was based on WordPress, which is very old. Hence, we’re conveniently converting PoP to a modern codebase, based around components installed through Composer, and full compatibility with the PHP Standard Recommendations, particularly PSRs 1, 2 and 4
• During the previous 5 years, we developed tons of functionalities which must be migrated to the modern codebase

How many components must still be migrated for the migration to be completed? A lot:

If anyone is unwilling to wait for so long until the migration is complete, and want to contribute with the migration, give Leo a shout!

When fetching data for a component, PoP allows to point to an external domain. Until now, the external site had to have the same components installed as the origin site, to guarantee that the response would be what was expected by the origin site. Undoubtedly, this was less than ideal.

This is solved now, and very elegantly: whenever a component fetches data from an external site, it automatically generates the URL to query, including all the fields that need be retrieved. Similar to GraphQL, this request will fetch only the required data, and because it is automatically generated by the application, there are no possibilities of manual errors from creating the query, and if any field is updated or a new one introduced or removed, the query is automatically upgraded too. The automatically generated query looks like this (assuming, in this case, that nextapi.getpop.org is the external site).

Through this feature, PoP sites will be able to share data effortlessly. The developer will not even need to code a query to fetch data, but simply arranging all modules inside each other will do. PoP takes care of the rest.

As usual, enjoy!

In our previous blog post we described that we were migrating PoP code into components. While doing so, we are abstracting the whole code away from WordPress, so that it can be powered by other frameworks, such as Laravel. The task involves finding all the references to WordPress code inside the PoP codebase, and move that code behind the implementation of an interface. Because the interface can be implemented for any CMS, we will then be able to install PoP using any framework.

This task is time consuming, so we are working on it, however we hope it will be finished within a couple of weeks, after which we will finally start making components available.

Stay tuned!

PoP has historically been called a “framework”. The reason for this is that, having started as a project for WordPress, its architecture expected to manage the whole website. Then, if you wanted to run PoP, it had to be a PoP website. It was an all or nothing situation.

However, this situation will soon be drastically improved: We are currently migrating PoP from a monorepo into a set of components, each of them hosted under its own repo, and all of them managed and tied together through Composer. The components can be installed independently of each other and, quite importantly, they will be CMS-agnostic. Having an architecture based on components, PoP is not expecting to take over the site any longer: components be added into any website to improve its capabilities, providing specific features (such as the component-based API)

Our aim is to release the components providing an implementation for WordPress and, in the future, provide an implementation for October CMS (given the availability of time and man power for the task). We expect to start releasing the first components around May 2019.

PoP is now compliant with PHP Standards Recommendations PSR-1: Basic Coding Standard and PSR-2: Coding Style Guide. This involved a huge refactoring of the whole codebase, renaming all functions from their snake case form (such as get_modules) into their camel case equivalent (getModules). As usual, enjoy!

Together with the release of the PoP API, we announce a major feature: the PoP API has been completely decoupled from the overall application, so it can be used as a standalone API to power any application, using a PoP theme or any standard WordPress theme.

For instance, we have deployed a site under https://nextapi.getpop.org, which uses the default WordPress 5.0 theme “Twenty Nineteen”:

If, however, we add parameter ouput=json to the URL, we get the data through the PoP API:

This makes it possible to use PoP purely as an API to fetch or post data, alongside any other theme out there.

Enjoy!