This website that you are browsing is pretty out of date: It is still using the first version of PoP, which has been improved with nifty new functionality, and it is promoting only features which are obsolete by now. A new version of PoP provides much better features, and we are still working on its release.

Unfortunately, the process to release the new version of PoP is a long and winding one, and we are still working on it: We have recently finally released PoP API for WordPress, and our next target will be to enable to create the whole website. However, we expect this release to be ready in only a few months from now, and only then we will be able to update the information in this website.

Until then, to learn about what features PoP provides, please check our GitHub repo instead, which is being constantly kept updated. Sorry for the inconvenience (we are working for you!)

Alright, that took some time in coming, but we can finally announce it: PoP can finally be installed through Composer! Sucess!!!!!

So for first time in its history, PoP can be easily installed, without resorting to hacks: simply execute a script, wait for a few minutes, and voilà. Currently, only the PoP API for WordPress is finished, and in a few months we will unlock further functionality: creating the whole site through PoP, and for other CMSs in addition to WordPress. Yay!

Installation instructions

Via Composer and WP-CLI (both are assumed to be installed globally):

1. Create the WordPress database and user
2. Configure WordPress through environment variables:

Copy the code below to an editor, replace all values (such as {YOUR_SITE_DB_NAME}) with your own values, and then either paste it on the terminal to execute, or save it in file “~/.bash_profile” and then execute source ~/.bash_profile.

export DB_NAME={YOUR_SITE_DB_NAME} #eg: database
export DB_USER={YOUR_SITE_DB_USER} #eg: admin
export DB_PASSWORD={YOUR_SITE_DB_PASSWORD} #eg: sADF!kl9diq@#Sjfk
export DB_HOST={YOUR_SITE_DB_HOST} #eg: 127.0.0.1
export SITE_URL_WITHOUT_HTTP={YOUR_SITE_URL_WITHOUT_HTTP} #eg: localhost
export SITE_URL_WITH_HTTP={YOUR_SITE_URL_WITH_HTTP} #eg: http://localhost
export SITE_NAME="{YOUR_SITE_NAME}" #eg: "My awesome website"
export ADMIN_USER={ADMIN_USER} #eg: admin
export ADMIN_PASSWORD={ADMIN_PASSWORD} #eg: JKo$@sfjASD00w
export ADMIN_EMAIL={ADMIN_EMAIL} #eg: pedro@example.com

To set the SALT keys there are two alternatives:

I. Set random values through environment variable SHUFFLE_SALT_KEYS:

export SHUFFLE_SALT_KEYS=true

II. Set the corresponding values directly:

# Obtain random values from https://api.wordpress.org/secret-key/1.1/salt
export AUTH_KEY={YOUR_AUTH_KEY}
export SECURE_AUTH_KEY={YOUR_SECURE_AUTH_KEY}
export LOGGED_IN_KEY={YOUR_LOGGED_IN_KEY}
export NONCE_KEY={YOUR_NONCE_KEY}
export AUTH_SALT={YOUR_AUTH_SALT}
export SECURE_AUTH_SALT={YOUR_SECURE_AUTH_SALT}
export LOGGED_IN_SALT={YOUR_LOGGED_IN_SALT}
export NONCE_SALT={YOUR_NONCE_SALT}

3. Bootstrap a new project from this repo:

composer create-project leoloso/pop-api-wp

4. Wait for a few minutes ☕️😁
5. ✅ The site is installed under:
   • 👉WordPress site: {YOUR_SITE_URL_WITH_HTTP}
   • 👉WordPress admin: {YOUR_SITE_URL_WITH_HTTP}/wp/wp-admin/
   • 👉PoP API: {YOUR_SITE_URL_WITH_HTTP}/posts/?action=api&datastructure=rest (REST for posts)

Enjoy!

We are very proud to announce that PoP can now return the response of its API using both the REST and GraphQL formats. This way, a PoP API can be used as a drop-in replacement for both REST and GraphQL, providing the benefits of both these APIs, at the same time! Check out these benefits:

• No over/under-fetching data (as in GraphQL)
• Shape of the response mirrors mirrors the query (as in GraphQL)
• Passing parameters to the query nodes, at any depth, for filtering/pagination/formatting/etc (as in GraphQL)
• Server-side caching (as in REST)
• Secure: Not chance of Denial of Service attacks (as in REST)
• Provide default data when no query is provided (as in REST)

In a nutshell: the PoP API is REST endpoints with GraphQL queries.

Demonstration

The API is accessed through the following endpoints (click on them to see an example):

REST-compatible:

Add parameters action=api&datastructure=rest to the endpoint URL:

• List of posts:
  /posts/?action=api&datastructure=rest
• Single post:
  /{SINGLE-POST-URL}/?action=api&datastructure=rest
• List of users:
  /users/?action=api&datastructure=rest
• Author:
  /{AUTHOR-URL}/?action=api&datastructure=rest
• List of tags:
  /tags/?action=api&datastructure=rest
• Tag:
  /{TAG-URL}/?action=api&datastructure=rest
• Page:
  /{PAGE-URL}/?action=api&datastructure=rest

GraphQL-compatible:

Add parameters action=api&datastructure=graphql to the endpoint URL, and parameter fields with the data fields to retrieve (using a custom dot notation). Examples:

• List of posts (+ author data):
  /posts/?action=api&datastructure=graphql&fields=id|title|date|url,author.id|name|url,author.posts.id|title|url
• Single post (+ tags and comments):
  /{SINGLE-POST-URL}/?action=api&datastructure=graphql&fields=id|title|cat-slugs,tags.id|slug|count|url,comments.id|content|date,comments.author.id|name|url
• List of users (+ up to 2 posts for each):
  /users/?action=api&datastructure=graphql&fields=id|name|url,posts(limit:2).id|title|url|date
• Author (+ all posts, with their tags and comments):
  /{AUTHOR-URL}/?action=api&datastructure=graphql&fields=id|name|url,posts.id|title,posts.tags.id|slug|count|url,posts.comments.id|content|date
• List of tags (+ all their posts ordered by title, their comments, and the comment authors):
  /tags/?action=api&datastructure=graphql&fields=id|slug|count|url,posts(orderby:title;order:asc).id|title|url|date
• Tag (+ all their posts, their comments and the comment authors):
  /tags/?action=api&datastructure=graphql&fields=id|slug|count|url,posts.id|title,posts.comments.content|date,posts.comments.author.id|name|url
• Page:
  /{PAGE-URL}/?action=api&datastructure=graphql&fields=id|title|url

PoP native:

Add parameters action=api to the endpoint URL, and parameter fields similar to the examples above for GraphQL.

How does it work?

Through a parameter datastructure in the URL we can select if the response must be REST-compatible or GraphQL-compatible. To fetch the data fields, for REST it supports default fields (as in typical REST behaviour), or explicitly querying for the fields, like in GraphQL. For this, the GraphQL query is converted to dot notation and passed in the URL through parameter fields. For instance, the following query:

query {
  id
  title
  url
  content
  comments {
    id
    content
    date
    author {
      id
      name
      url
      posts {
        id
        title
        url
      }
    }
  }
}

Is converted to dot notation like this:

id|title|url|content,comments.id|content|date,comments.author.id|name|url,comments.author.posts.id|title|url

Enjoy!

Leo took part in the latest version of JSConf Asia 2019, with a talk titled “Introduction to the Component-based API” in which he explains many of the concepts powering PoP, including how it features a component-model architecture for the back-end (PHP), and how PoP delivers an API which is a mix of REST and GraphQL, containing benefits from both of them, and which can be progressively enhanced to deliver the application itself.

The talk is now available online:

Enjoy!

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!