Documentation

We are glad to have you here! In our documentation you’ll find everything you need to work with Posts Bridge.

Posts Bridge is a powerful tool to synchronize your WordPress site content with third party systems over HTTP requests. The approach of this plugin is to escape from closed solutions and to bring to the user a set of tools to make him autonomous to set up his own integrations. At the same time, “With great power comes great responsibility” and basic knowledge of how HTTP and REST APIs works is required.

You can complement this documentation with the tutorials of the blog. If you miss something or think a new tutorial may be interesting for the community, send us a message through the contact form.

Getting started

This guide is an introduction to the Posts Bridge plugin for WordPress. With various examples, this tutorial explains how to setup a bridge that synchronize WordPress posts with remote systems over the network.

Set up a backend

The first step to establish a bridge between your WordPress posts and your backend or service, is to register the backend / service connection. On the admin panel, go to Settings > Posts Bridge to open the plugin’s settings page and go to the HTTP tab. If it’s your first time here, you will find a screen like this:

A backend is nothing more than a URL, an array of headers and a unique name to identify it. Start by typing a name and a URL and then click the Add button. Once done, you can add more headers to your backend connection.

A good practice is to use your backend URL domain as the backend URL, without path, and use the path as part of your bridge endpoints!

In this example, we will work with {JSON} Placeholder, a free fake and reliable API for testing and prototyping. The idea is to get the mocked posts from its API synchronized with you WordPress posts.

Connect your posts

Once you have your backend connection configured, you can start using it on your bridges. Let’s bridge our posts to {JSON} Placeholder. Go to the REST API tab and create a new bridge. A bridge needs a post type, a foreign key, a backend, an HTTP method, an endpoint, and, optional, a single endpoint pattern. Depending on the add-on you use, the bridge will need more or less fields.

The foreign key field is the attribute name of the backend record that will be used as primary key, or ID.

The bridge endpoint field should point to the backend endpoint that returns the list of records to get synchronized. Following the convention, to load data for a single record, Posts Bridge will append the record ID as the last part of the endpoint as follows: /api/posts => /api/posts/123.

The single endpoint pattern allows you to indicate a rewrite rule to be used when the bridge fetches data for a single record of your backend or service. Use the {id} there where the record ID has to be replaced (e.g. /api/post/detail/{id}).

In this example, we’ve specified the following values:

  1. Post type: post
  2. Foreign key: id
  3. Backend: JSON Placeholder
  4. Endpoint: /posts
  5. Single endpoint pattern: /posts/{id}
  6. Method: GET

In addition, in the Post fields section, we’ve mapped the title and body attributes from the API response records to the Title and Content fields of our posts.

After that, we have our first bridge ready 🎉. Now, click on Synchronize and Posts Bridge will create as posts in WordPress as posts returns the Placeholder API.

Screenshot of the posts collection in the WordPress admin panel after the synchronization.

This is a basic setup. Now, you can schedule and automatic synchronization from the General tab of the plugin settings to get your posts automatically synchronized in the background.

Settings page

To get you to the settings page go to Settings > Posts Bridge on the admin page of your WordPress site. This page is where you can configure and create your form bridges.

General settings

  1. Schedule: Enable or disable automatic background synchronizations.
  2. Recurrence: Time interval to be used for automatic synchronizations.
  3. Add-ons: Activate and deactivate add-ons. Each add-on open a new tab, with new bridges. REST API add-on is enabled by default.
  4. Debug: Activate the logging mode to open the console and get logs of your bridges in real time.
  5. Import / Export: Import or export your Posts Bridge configurations as JSON files and move it between instances with easy!
  6. Credits: Credits about the plugin and Còdec.

HTTP settings

  1. Backends: Backends are reusable and add-on independent. Configure your backend connections on the HTTP tab and reuse them on your add-on tabs.
  2. Authentication: If your backend requires some kind of standard HTTP authentication, you can use this panel to register authentication credentials. There are 7 types of credentials: Basic, Token, Digest, URL, OAuth, Bearer and RPC.

Add-on tabs

Each time you activate a new add-on, a new tab will be visible in the settings page. Navigate to this tab and start bridging your posts to the add-on’s API. To get more detail about add-ons, go the the add-ons chapeter.

Backends

In Posts Bridge, a backend is a set of configurations that handles the connection information and credentials required to get your posts synchronized with remote records over HTTP requests. Go to Settings > Posts Bridge > HTTP to configure your backend connections.

In the backends panel, you can configure as many backend connections as you need. To create a new backend connection, you have to set the following fields:

  1. Name: A label to identify the backend. Backend names should be unique as it is the internal identifier Posts Bridge use to bind backends to bridges.
  2. Base URL: The base URL of your backend. The URL should start with http:// or https://. This base URL will be prepended to the bridge endpoint on runtime when a bridge is sending form submissions to your backend.
  3. Encoding schema: Select how the bridge payload will be encoded on the HTTP request body. You can use one of the standard schemas, or use a custom one.
  4. Authentication: Chose one of your registered authentication credentials, if required.
  5. Headers: An array of HTTP headers. By default, this table will has the Content Type header. In addition, you can add as many headers as you want.

Authentication

The Posts Bridge backend system implements the most common HTTP authentication standards. With authentication credentials you can register user credentials required to perform authenticated requests to your backends. Go to Settings > Posts Bridge > HTTP to configure your authentication credentials.

On the authentication panel you can configure as many credentials as you need. To create a new credential you have to chose between the 5 available authentication schemas:

  1. Basic: In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of client_id and client_secret joined by a single colon :.
  2. Token: In token HTTP authentication, a request contains a header field in the form of Authorization: token <credentials>, where <credentials> is the client_id and client_secret joined by a single colon : as plain text.
  3. URL: A variation of the basic schema where the client_id and client_secret are placed on the request URL as plain text values as follows https://<client_id>:<client_secret>@<backend_url>.
  4. Digest: It applies a hash function to the client_id, realm and client_secret before sending them over the network with usage of nonce values.
  5. OAuth: OAuth provides a method for clients to access a protected resource on behalf of a resource owner. In the general case, before a client can access a protected resource, it must first obtain an authorization grant from the resource owner and then exchange the authorization grant for an access token. The client_id, client_secret and scope fields are used to get this authorization grant performing an authentication request to the Authorization URL.
  6. Bearer: Bearer Tokens are security tokens that grants the “bearer” (i.e., the party presenting the token) access to protected resources. The access_tokenfield of the credential will be sent in the HTTP Authorization header as follows: Authorization: Bearer <token>.
  7. RPC: In RPC authentication, the client_id, client_secret and database parameters are shared with the backend as the payload of an RPC login call to obtain the user ID and session required to perform authorized requests.

Depending on the schema you chose, the credential form will require more or less fields.

Once you have your credentials registered, you can use them on your backend connection settings. If a backend has an authentication credential registered, Posts Bridge will apply the authentication schema to get authorized access to the backend resources.

The OAuth schema requires an authorization request to the authorization server to obtain access and refresh tokens. This requests has to be done on registration time and once done successfully, the tokens will be stored on the database. If an OAuht credential has been authorized by the server, the credential will be frozen until you revoke the stored tokens.

API keys are not part of an HTTP authentication standard schema. If your backend use this kind of authentication, simply register it as an HTTP header in the backend.

Bridges

Think of a bridge as a mapping that links your backend data with a post type collection from your WordPress web page. Each item on your backend database will be converted to a post, and each field on your backend records can be mapped to a post field, post meta or taxonomy terms.

Once you link a post type to an endpoint from your backend API, you get a Remote CPT. Remote CPTs are a special type of posts that can fetch data over HTTP requests on render time and stay synchronized with your backend state.

With bridges you can connect your WordPress posts to any kind of backend, it doesn’t matter if it is a CRM, an ERP, a booking system or an online spreadsheet, the only requirement is an HTTP API.

A bridge is tied to an API, so to create bridges you need to have at least one add-on enabled. Each Posts Bridge add-on comes with a new bridge class with the ability to communicate with the respective API. Posts Bridge have REST API bridges enabled by default.

Field mappers

Field mappers are relations between backend record fields and WordPress post fields. For each bridge, Posts Bridge allows you to map foreign fields to standard post fields, or to arbitrary custom fields.

A field mappers has two parts:

  1. Name: The standard WordPress post field, or custom field name.
  2. Foreign: The attribute name from the backend response to be mapped to the post field.

In the field mappers table, you can use the introspection API of Posts Bridge to get information about the fields schema of the bridge endpoint. Simply click on the button {…} to get a list of all its fields and its types.

Tax mappers

Works as field mappers, but each mapped value from the backend responses will be registered as a new taxonomy term in WordPress. For tax mappers, you can pass single values or arrays. During the mapping, Posts Bridge will transform the foreign value to an array if it isn’t. On synchronization, each item of the array of values will be registered as a taxonomy term.

Posts Bridge will only show tax mappers if the current post type supports, at least, one taxonomy.

If you have custom taxonomies, Posts Bridge will show them on the bridge mappers table.

Json fingers

A json finger is a hierarchical pointer to data structures like children[0].name.rendered.

Json fingers are used by Posts Bridge as field names to allow the user to traverse complex data structures from the backend responses while synchronizing posts.

The syntax is inspired on the JSON standard, hence the name. If JSON is unknown to you, start by reading about the JSON syntax and then, a good playground to learn the concept is the jsonpathfinder project, give it a whirl.

Json fingers are can be used as foreign names of field mappers, or as remote field names. If your json finger is simple (without path hierarchy), it works as a simple field name, but a the same time, you can break the name into hierarchy levels get the nested values of a backend response.

For example, if your backend returns a payload like this:

{
  "name": "Bob",
  "address": {
    "street": "Carrer de Balmes, 250",
	"city": "Barcelona"
  }
}

Then you can use address.street and address.city fingers to point to this nested attributes.

Use them as field mappers foreign names to retrive nested attributes, or as remote field names to render nested values from your backend responses in your post templates and content.

Take a look at our Deep dive into json fingers tutorial if you want to realize the full potential of the json finger syntax.

Remote fields

Posts Bridge includes the Remote fields custom block to be used inside the WordPress editor. You can use it both, when editing posts templates and when writing post content. This block allows you

This block allows you to use remote field placeholder marks in the content of your posts. On render time, Posts Bridge will request those field values to the backend and replace them dynamically.

A remote field placeholder mark looks like {{fieldName}}, with the name of the field between curly brackets. Place them there where you want your backend fields to be shown and Posts Bridge will do the rest.

Synchronization

Posts Bridge treats post collections as indexes that represents your backend data.

Posts Bridge offers two strategies for content synchronization:

Ahead of time

On each synchronization loop, if your bridge has field mappers, Posts Bridge will fetch data for each record and insert in the database its attribute values as post fields, post meta or taxonomy terms.

This strategy increase synchronization workloads as requires Posts Bridge to dispatch a request for each item in the synchronization loop. An other drawback of this strategy is that remote data updates only will be visible after the next scheduled synchronization loop.

In return, after each synchronization loop you will have your data inside the WordPress database, which allows page fastest page renders and the use all the WordPress features, such as taxonomy archives and filters or show post excerpts.

Lazy loading

In case your bridges does not use field mappers, Posts Bridge will only synchronize foreign IDs on each synchronization loop, and, for each foreign ID, insert an empty post in the database. During renders, you have to use the remote fields custom block to dynamically load record data and map attributes to the post content elements.

This strategy allows light synchronization loops as only the list of foreign IDs has to be fetched from the backend. On render time, record data will be fetched, which ensures that the rendered data is always updated.

The drawback of this strategy is that each page render will require some time to load remote data. This can lead to several performance issues if you plan to show your posts as archives.

Both synchronization strategies are not mutually exclusives. You can use both at the same time. For example, you can use field mappers to get your post title and excerpt to be shown in the posts archive, and remote fields to dynamically fetch record data to be shown in the single post template.

Custom post types

Posts Bridge allows you to bridge any registered post type from your WordPress site. If you’ve not registered it yet, you can register it with Posts Bridge. Go to the CPTs tab and create a new custom post type. The registration form will inherit the registration defaults, but you can modify its values at any time. The only required fields are Name, Label and Singular label.

Take a look to the official documentation to get a more in detail explanation about the post type registration arguments.

In this example, we’ve set event as the post type name, and Events and Event as labels. In addition, we’ve enabled archives for this type of post.

This panel allows you to register post types without writing code. In addition, it allows you to register post meta. Simply open the Custom fields panel and register as many fields as you want. Each field will be registered as custom fields of the post type on registration time.

Add-ons

Posts Bridge comes with free add-ons. Each add-on adds to the plugin new bridges to work with specific APIs.

By default, Posts Bridge has the REST API add-on enabled. This is the generic add-on, with an abstract bridge not tied to any API and with which you can set up bridges to work with any API that implements the REST standard.

Because the REST API add-on is intended to be abstract, it does not support introspection, so Posts Bridge wont be able to propose you fields and endpoints while configuring your bridges. Use this kind of bridges to work with your custom APIs.

In addition to the REST API add-on, there are other add-ons tailored to work with specific APIs. To enable or disable this add-ons, go to Settings > General > Add-ons and select which ones you want to enable.

Below you can access the documentation for each one of theme:

REST API
Airtable
Dolibarr
Google Calendar
Google Sheets
Grist
Holded
Nextcloud
Odoo
WordPress

API

Posts Bridge has an open API of filters and methods to allow developers to extend Posts Bridge features with PHP. In this chapter we will cover the most interesting of them from the point of view of the developers who wants to integrate their themes or plugins with Posts Bridge.

It isn’t an extensive documentation of the Posts Bridge API. If you want a more in depth knowledge, you can browse the plugin’s code on the github repository 🐱‍💻.

PBAPI

The PBAPI is a global available object that works as a proxy that allows developers to manage Posts Bridge settings and data. This is the list of available PBAPI methods:

static PBAPI::get_addon

Gets an add-on instance by slug. Add-ons are only available if they are active.

Arguments

  1. string Add-on slug.

Return

  1. POSTS_BRIDGE\Addon|null Add-on instance, if found, null otherwise.

Example

$addon = PBAPI::get_addon( 'dolibarr' );
if ( $addon && $addon->ping( 'Dolibarr' ) ) {
	$backend_endpoints = $addon->get_endpoints( 'Dolibarr', 'POST' );
}

static PBAPI::get_post_types

Gets the list of registered post types.

Return

  1. string[] List of post type names.

Example

$post_types = PBAPI::get_post_types();
foreach ( $post_types as $post_type ) {
	echo $post_type;
}

static PBAPI::get_custom_post_types

Gets the list of registered custom post types configurations.

Return

  1. array[] Custom post types registration data.

Example

$cpts = PBAPI::get_custom_post_types();
foreach ( $cpts as $name => $cpt_args ) {
	if ( ! $cpt_args['public'] ) {
        # do something
    }
}

static PBAPI::get_custom_post_type

Gets a custom post type registration data by name

Return

  1. array|null Registration data or null

Example

$event_data = PBAPI::get_custom_post_type( 'event' );
if ( $event_data ) {
	$event_data['public'] = true;
    PBAPI::register_custom_post_type( 'event', $event_data );
}

static PBAPI::register_custom_post_type

Registers a new custom post type in WordPress.

Arguments

  1. string Post type name.
  2. array Post type registration parameters.

Return

  1. boolean Registration result.

Example

$success = PBAPI::register_custom_post_type(
    'event',
    array(
        'label'          => 'Events',
        'singular_label' => 'Event',
        'public'         => true,
        'show_in_rest'   => true,
        'rest_base'      => 'events',
    ),
);

if ( ! $success ) {
	# handle registration error
}

static PBAPI::unregister_custom_post_type

Unregisters a custom post type from WordPress. Only applies to the custom post types registered with Posts Bridge.

Return

  1. boolean Unregistration result.

Example

$result = PBAPI::unregister_custom_post_type( 'event' );
if ( $result ) {
    # do something
}

static PBAPI::get_remote_cpts

Gets the list of bridged post type names.

Return

  1. string[] List of bridged post type names.

Example

$rcpts = PBAPI::get_remote_cpts();
foreac ( $rcpts as $rcpt ) {
    echo $rcpt;
}

static FBAPI::get_bridge

Searches for a bridge by post type name.

Arguments

  1. string Post type name.

Return

  1. POSTS_BRIDGE\Post_Bridge|null Bridge object or null.

Example

$bridge = PBAPI::get_bridge( 'event' );
if ( $bridge ) {
	$events = $bridge->fetch_all();

    if ( is_wp_error( $response ) ) {
        # handle error
    }
}

static FBAPI::get_bridges

Returns the list of available bridges.

Return

  1. POSTS_BRIDGE\Post_Bridge[] Array of bridge objects.

Example

$bridges = PBAPI::get_bridges();
foreach ( $bridges as $bridge ) {
	# do something
}

static FBAPI::get_addon_bridges

Returns the list of available bridges filtered by add-on slug.

Arguments

  1. string Add-on slug.

Return

  1. POSTS_BRIDGE\Post_Bridge[] Array of bridge objects.

Example

$bridges = PBAPI::get_addon_bridges( 'odoo' );
foreach ( $bridges as $bridge ) {
	if ( ! $bridge->is_valid ) {
        continue;
    }

    # do something
}

static FBAPI::save_bridge

Creates or updates the bridge data in the database.

Arguments

  1. array Bridge data.
  2. string Add-on slug.

Return

  1. boolean Update result.

Example

$bridge_data = array(
    'post_type'     => 'event',
    'backend'       => 'Google Calendar',
    'endpoint'      => '/calendars/v3/calendar/[email protected]/events',
    'method'        => 'GET',
    'field_mappers' => array(
        array(
            'name'    => 'summary',
            'foreign' => 'post_title',
        ),       
        array(
            'name'    => 'description',
            'foreign' => 'post_excerpt',
        ),
        array(
            'name'    => 'start_date',
            'foreign' => 'start.date',
        ),
        array(
            'name'    => 'end_date',
            'foreign' => 'end.date',
        ),
    ),
    'tax_mappers' => array(),
);

$result = PBAPI::save_bridge( $bridge_data, 'gcalendar' );
if ( ! $result ) {
    # handle error
}

static FBAPI::delete_bridge

Remove the bridge from the database.

Arguments

  1. string Bridge name.
  2. string Add-on slug.

Return

  1. boolean Update result.

Example

$result = PBAPI::delete_bridge( 'events', 'gcalendar' );
if ( $result ) {
    # do something
}

static PBAPI::get_backends

Returns the list of available backends.

Return

  1. POSTS_BRIDGE\Http\Backend[] Array of backend objects.

Example

$backends = PBAPI::get_backends();
foreach ( $backends as $backend ) {
	if ( str_starts_with( $backend->base_url, 'http://' ) {
        $data = $backend->data();
        $data['base_url'] = str_replace( 'http://', 'https://', $data['base_url'] );
        PBAPI::save_backend( $data );
    }
}

static PBAPI::get_backend

Searches for a backend by name.

Arguments

  1. string Backend name.

Return

  1. POSTS_BRIDGE\Http\Backend|null Backend object or null.

Example

$backend = PBAPI::get_backend( 'Dolibarr' );
if ( $backend ) {
	$response = $backend->get( '/api/index.php/status' );
    if ( is_wp_error( $response ) ) {
         # handle error
    }
}

static PBAPI::save_backend

Creates or updates the backend data in the database.

Arguments

  1. array Backend data.

Return

  1. boolean Update result.

Example

$result = PBAPI::save_backend( array(
    'name'       => 'Odoo',
    'base_url'   => 'https://erp.example.coop',
    'headers'    => array(
        'Content-Type' => 'application/json',
    ),
    'credential' => 'John Doe RPC',
) );

static PBAPI::delete_backend

Removes the backend from the database.

Arguments

  1. string Backend name.

Return

  1. boolean Update result.

Example

$result = PBAPI::delete_backend( 'Odoo' );
if ( $result ) {
     # do something
}

static PBAPI::get_credentials

Returns the list of available HTTP credentials.

Return

  1. POSTS_BRIDGE\Http\Credential[] Array of credential objects.

Example

$credentials = PBAPI::get_credentials();
foreach ( $credentials as $credential ) {
	if ( 'RPC' === $credential->schema ) {
        $rpc_credentials[] = $credential;
    }
}

static PBAPI::get_credential

Searches for a credential by name.

Arguments

  1. string Credential name.

Return

  1. POSTS_BRIDGE\Http\Credential|null Credential object or null.
$credential = PBAPI::get_credential( 'Google Console Client' );
if ( $credential ) {
	$authorization = $credential->authorization();
}

static PBAPI::save_credential

Creates or updates the credential data in the database.

Arguments

  1. array Credential data.

Return

  1. boolean Update result.

Example

$result = PBAPI::save_credential( array(
    'name'          => 'Airtable Token',
    'schema'        => 'Bearer',
    'access_token'  => 'abcd123456789',
) );

static PBAPI::delete_credential

Removes the credential from the database.

Arguments

  1. string Credential name.

Return

  1. boolean Update result.

Example

$result = PBAPI::delete_credential( 'Airtable Token' );
if ( $result ) {
    # do something
}

Filters

posts_bridge_remote_data

Filters the fetched remote data for a Remote CPT before it is used for synchronization.

Arguments

  1. array $remote_data Loaded remote data.
  2. POSTS_BRIDGE\Remote_CPT $rcpt Remote CPT object.

Return

  1. mixed|null Remote data. If null is returned, post synchronization will be skipped.

Example

add_filter(
    'posts_bridge_remote_data',
    function ( $data, $rcpt ) {
        if ( 'event' === $rcpt->post_type ) {
            $data['tags_input'] = array( 'remote' );
        }

        return $data;
    },
    10,
    2,
);

posts_bridge_remote_items

Filters the list of remote items, or records, loaded from the list endpoint of the bridge.

Arguments

  1. array $items Bridge remote items.
  2. POSTS_BRIDGE\Post_Bridge $bridge Bridge instance.

Return

  1. array Filtered items.

Example

add_filter(
    'posts_bridge_remote_items',
    function ( $items, $bridge ) {
        if ( 'contacts' === $bridge->name ) {
            return array_filter(
                $items,
                function ( $item_data ) {
                    return ! empty( $item_data['email'] );
                }
            );
        }

        return $items;
    },
    10,
    2,
);

posts_bridge_http_backend_headers

Filters backend HTTP request headers.

Arguments

  1. array $headers Associative array with HTTP headers.
  2. Http_Backend $backend Backend object.

Return

  1. array Filtered HTTP headers.

Example

add_filter(
    'posts_bridge_http_backend_headers',
    function ( $headers, $backend ) {
        $headers['Accept-Language'] = 'es_ES';
        return $headers;
    },
    10,
    2,
);

posts_bridge_http_backend_url

Filters backend request URLs.

Arguments

  1. string $url Synchronization request URL.
  2. POSTS_BRIDGE\Http\Backend $backend Backend object.

Return

  1. array Filtered HTTP headers.

Example

add_filter(
    'posts_bridge_http_backend_url',
    function ( $url, $backend ) {
        $url = str_replace( 'http://', 'https://', $url );
        return $url;
    },
    10,
    2,
);

posts_bridge_http_request

Filters the backend request params before it is sent. Posts Bridge use the WP_Http under the hood. Check out the WP_Http::request documentation for more details about the params.

Arguments

  1. array $params HTTP request params.

Return

  1. array Filtered HTTP request params.

Example

add_filter(
    'posts_bridge_http_request',
    function ( $request ) {
        $request['args']['ssl_verify'] = false;
        return $request;
    },
    10,
    1,
);

posts_bridge_skip_synchronization

Controls if Posts Bridge should skip the post synchronization.

Arguments

  1. boolean $skip False by default, use this filter to skip posts synchronizations.
  2. POSTS_BRIDGE\Remote_CPT $rcpt Remote CPT object.

Return

  1. boolean True value will skip the synchronization of the current Remote CPT.

Example

add_filter(
    'posts_bridge_skip_synchronization',
    function ( $skip, $rcpt, $data ) {
        if ( 'event' === $rcpt->post_type && ! $data['start_date'] ) {
            return true;
        }

        return $skip;
    },
    10,
    3,
);

posts_bridge_introspection_ping

Filters the result of a ping introspection request of the REST API add-on (for custom integrations).

Arguments

  1. boolean $result True if the backend is successfully reached, false otherwise.
  2. string $backend Backend name.

Return

  1. boolean Ping result.

Example

add_filter(
    'posts_bridge_introspection_ping',
    function ( $result, $backend ) {
        if ( 'Placeholder' === $backend ) {
            return true;
        }

        return $result;
    },
    10,
    2,
);

posts_bridge_introspection_endpoints

Filters the response of an endpoints introspection request of the REST API add-on (for custom integrations).

Arguments

  1. string[] $endpoints List of available endpoints.
  2. string $backend Backend name.

Return

  1. string[] List of available endpoints.

Example

add_filter(
    'posts_bridge_introspection_endpoints',
    function ( $endpoints, $backend ) {
        if ( 'Placeholder' === $backend ) {
            return array(
               '/posts',
               '/comments',
               '/albums',
               '/photos',
               '/todos',
            );
        }

        return $endpoints;
    },
    10,
    2,
);

posts_bridge_introspection_schema

Filters the response of endpoint schema introspection request of the REST API add-on (for custom integrations).

Arguments

  1. array $schema List of available endpoints.
  2. string $backend Backend name.
  3. string $endpoint Target endpoint.

Return

  1. array Endpoint fields json schema.

Example

add_filter(
    'posts_bridge_introspection_schema',
    function ( $schema, $backend, $endpoint ) {
        if ( 'Placeholder' !== $backend || '/posts' !== $endpoint ) {
            return $schema;
        }

        return array(
            array(
                'name' => 'id',
                'schema' => array( 'type' => 'integer' ),
            ),
            array(
                'name' => 'userId',
                'schema' => array( 'type' => 'integer' ),
            ),
            array(
                'name' => 'title',
                'schema' => array( 'type' => 'string' ),
            ),
            array(
                'name' => 'body',
                'schema' => array( 'type' => 'string' ),
            ),
        );
    },
    10,
    3,
);

Actions

posts_bridge_before_synchronization

Action to do just before a post synchronization.

Arguments

  1. POSTS_BRIDGE\Remote_CPT $rcpt Current Remote CPT object.
  2. array $post_data Post data to be inserted.

Example

add_action(
    'posts_bridge_before_synchronization',
    function ( $rcpt, $post_data ) {
        # do something
    },
    10,
    2,
);

posts_bridge_after_synchronization

Action to do just after a post synchronization.

Arguments

  1. POSTS_BRIDGE\Remote_CPT $rcpt Current Remote CPT instance.
  2. array $post_data Post data inserted.

Example

add_action(
    'posts_bridge_after_synchronization',
    function ( $rcpt, $post_data ) {
        # do something
    },
    10,
    2,
);