When registering content in WordPress, it is expected that the same content will be replicated in a Drupal application.&nbsp;

To achieve this goal, we could build a solution using some queue service (such as AWS SQS, for example). The idea would be that when inserting, changing, or even deleting a WordPress post, a message would be sent to this queue service, informing the ID of the post in question and the type of operation performed (insertion, change, or deletion). This could be done in WordPress using the various hooks it provides. WordPress hooks are a way for us to perform certain actions at a specific point in the execution of WordPress. That way, we could use a hook that runs after inserting, changing, or deleting a post, so at that moment, we would be able to compose the message (containing the ID and operation) and send it to the queue service. We could use the transition_post_status hook for this case, as it is triggered whenever the operations mentioned above occur.&nbsp;

In most queuing services, we can send a payload to a distributed application. In the case of SQS, we could even use a Lambda Function. Thus, whenever a message was received (containing the ID and operation), we would trigger this function that would act as a kind of ETL (Extract, Transform and Load), as it would be responsible for making a request to the WordPress API based on the Post ID to retrieve the information. Then we would have a transformation step, after all, it would be necessary to translate a WordPress post into a format that is acceptable to Drupal. After this step, we would persist this post in Drupal through an API provided by it (core modules such as JSON:API and Rest can be used for this purpose). In this way, it would be possible to synchronize WordPress content with Drupal.&nbsp;

Obviously, using the WordPress hook we could parse the content of the post and then send it directly to the Drupal API, however, unlike the solution proposed previously (using queue service), such a solution would not so fault-tolerant, after all the content could not be inserted in Drupal if it was unavailable when the WordPress hook is activated (and makes the request to the API). Using the queue solution, we can guarantee that the message will be processed through a retry policy, that is, it will only be removed from the queue as soon as the application responsible for the transformation and insertion in the other CMS (Drupal) returns a response from success (typically HTTP Status 200). In addition, the solution using the queue service allows CMS (Drupal and WordPress) to work in an agnostic way in relation to the content sent and the content received, after all, this will be the responsibility of the application that will extract and transform the content. Thus, neither does WordPress needs to know the format used by Drupal (if the transformation was done by Wordpress), nor does Drupal need to know the WordPress format (if Drupal received the content in the “WordPress format” and was responsible for the transformation before the insertion).&nbsp;

So that we could make the association between WordPress content in Drupal, we could create a field in the Drupal content type to store the “WordPress ID”. That way, in an update or delete scenario, we would be able to locate Drupal content that relates to a particular WordPress content. So, if the content was changed or even removed, we would be able to locate it in Drupal to perform the necessary actions (update or delete).&nbsp;

Imagine that when you insert a new post in WordPress with the title “My New Post” it has ID 123, as shown below:&nbsp;

Thus, a message would be sent to the queue service with that ID and the Insert operation type. In this way, an application would extract the content of the post in WordPress and transform it into Drupal format, including the ID of the WordPress post, so that it could then be inserted into Drupal. After insertion in Drupal, it would look like this:&nbsp;

Notice that we have an EXTERNAL_ID field so that we can relate the content inserted in Drupal with that present in WordPress. Thus, if this post was changed in WordPress, a new message would be sent to the queue service with its ID and the operation (in this case, Change), so the application responsible for extracting and transforming the content could trigger some endpoint of the Drupal API that performs an Upsert operation (inserts if it doesn't exist and updates if it already exists) based on this EXTERNAL_ID (ID of the content in Wordpress). In the case of a deletion operation, it would be enough for the removal to be performed in Drupal through the API if there is any content with EXTERNAL_ID corresponding to the content ID in WordPress.&nbsp;

As mentioned before, we could have some simpler solutions (direct integration between WordPress and Drupal, for example), however, we opted for a solution with greater fault tolerance and better separation of responsibilities, through the use of the queue service.&nbsp;

This separation becomes clearer when we analyze the responsibility of each of our 3 components in isolation. First, we have WordPress responsible for sending a message to the queue service whenever we interact with content (insert, change or delete), then we have the application in the ETL layer responsible for extracting, transforming, and inserting the content, and finally, Drupal, responsible for providing an API so that the transformed content can be inserted.&nbsp;

By using this architecture, in eventual implementations (and adjustments), we will only need to deal with the ETL layer, eliminating the need for any coding in both WordPress and Drupal, reducing the chances of failures (after all, we will only need to deal with one of the components instead of three) and conclusively evidencing our separation of responsibilities in the adopted solution.&nbsp;

{"time":1655977886088,"blocks":[{"type":"paragraph","data":{"text":""}}],"version":"2.19.2-rc.2"}

How can I share content between a WordPress site and a Drupal site?