Syndicating WordPress content using content deployment
Written by on April 7, 2019
Recently we have been working on an exciting project for TOMD (The Outsourced Marketing Department). We originally built a content deployment and content syndication system for them back in 2017 and we have recently been commissioned to improve this and add new features.
In this post, with accompanying video and presentation slides, I am going to focus on content syndication in WordPress, what it is, how it is done and why you might want to deploy content from one WordPress site to another.
What is content syndication?
Put simply the act of syndicating content is when a piece of content is written and then deployed, or distributed to multiple places. This is often done in the publishing industry where a journalist may write a story and that story is then published in newspapers, maybe local and/or national.
In the web and WordPress world, content syndication means deploying a post (post, page or even custom post type for example) to multiple different WordPress websites.
Why would I want to syndicate or deploy content from one website to another?
The project we worked on with TOMD was to deliver content to websites for IFAs (Individual Financial Advisors|). When working in the financial service industry all content that is written, especially about financial services products and services, would go through a compliance checking process to make sure that the wording accurate about the products and meets legal requirements etc.
Our client (TOMD) is one of the leading providers of marketing services to the financial services industry, especially to independent financial advisers (IFAs). One of their core products is to provide compliance checked content to IFAs websites.
This content is delivered via a content deployment method. This means that a particular piece of content can be delivered to multiple IFAs websites. Once the content arrives at the destination website, the website owner has control of whether that content is visible on their site or not, but they cannot edit the content. This is because it would break the compliance process but also it would break the connection between the site from which the content was delivered. More about this later though.
What other industries or sectors would content deployment or syndication work well in?
As well as the financial services sectors that are a number of sectors and industries where it makes sense. One such example is a franchise business. Here it could be that the services pages on each of the franchisee websites are deployed from a central store, as the content of the services is the same, regardless of where the franchisee is, in terms of location.
Another example could be businesses where there are regional offices or divisions which has separate websites. If they have content on them that is the same for all divisions or offices, this could be content deployed. A good example here could be a regional estate agent with several offices. Each of these could have their own website to serve better the local community, however, the services that offer, the privacy policies etc. could all be the same and therefore delivered to each site by content deployment.
Also, as previously mentioned above the digital publishing industry is another good example. Articles are written once and deployed to multiple news websites, serving different areas and audiences.
How do we do content deployment in WordPress?
There are many ways to achieve content deployment using many different technologies. Below I will outline the overview of how we have achieved it.
Utilise WordPress multisite
Anytime when you have multiple WordPress sites that are going to share similar content but more importantly functionality including plugins, themes and even users, WordPress multisite is an excellent choice.
I won’t go into great detail here but a WordPress multisite network, allows us to serve multiple websites from a single install of WordPress. This means that all the sites within the network can share the same WordPress installation and the same plugins and themes.
This has great advantages. For example, when we need to make a change to a piece of functionality for all the sites, or even to update a plugin or WordPress core itself, we only need to do this once, in one codebase and all of the sites in the network automatically are upgrading and running on the new changes.
The content deployment process
The process of deploying a piece of content from one site to another in a WordPress network works like this.
We have a primary site, this is where WordPress is installed and this site is used to hold all of the content which can be deployed to other sites. In our instance, this site does not have a front-end to view the content. We are purely using this to write the content using the WordPress editor features and then storing that content in WordPress.
We call this the content master site and like another WordPress site, it can have custom post types, plugins and other functionality that a normal WordPress contains.
Underneath this site are all of the (in our case) IFAs websites. Since this is a WordPress multisite all these sites can run the same plugins and functionality as the site where the content is written (content master). They can even have their own domain name, so to the IFA and the outside world, they have nothing to do with the WordPress network to which they belong.
Content is then pushed down from the content master site to the other sites in the network. This process can have different commands of either add/update or delete. This allows content writers to not only deploy content to IFAs websites but also update that content and even delete it.
The important thing here to remember is that the flow of information is always from the content master site down to another site in the network. An individual site in the network cannot send content back the other way.
Syndication via by 2 plugins
In order to make this system, we have developed 2 plugins. One is always active on the content master site and the other is always active on the destination sites where content is delivered to. This is activated on the IFAs websites or sites receiving the content.
Lets first look at the plugin active on the sites receiving content – the deployed content plugin.
Deployed content plugin
Our deployed content plugin essentially creates the ability for a site to receive content from the content master. In more technical terms it creates an endpoint on the sites which accepts data from the content master and then turns this into a post on the site.
We have built a settings screen for the plugin which allows the site to change a few things, the make it all work better for them.
The settings screen contains the following options:
- Prevent deployment checkbox – checking this prevents a site from receiving any deployed content. This is usually not only for the website owner if they no longer want to receive content on their site, but also for developer debugging.
- Content post status – for each type of content that can be delivered to a site, the site owner can choose what status (publish or draft) that content will have when it is delivered. Draft means the content will not be live on the front en of their site yet, giving them time to take a look at the content before publishing it
- Notification email – a site owner can choose to receive an email notification each time a piece of content is delivered to their site by entering an email address of their choice.
- Notification email content – site owners can also customise the content of their notification emails.
Content deployment plugin
The second plugin, called content deployment is a plugin added to the content master site where all of the content is written and then ready to deploy to other sites.
There are two elements to this plugin – adding a site to deploy to and then the action of deploying content.
Sites are added by giving them a label and entering the details of the site, including the URL. We have built specific functionality for TOMD, where each site can have a specific plan which means they can only receive certain types of content.
For the technical reading this, sites are just stored as a WordPress custom post type and we use custom taxonomies to allow sites to be grouped. This also then allows us to easily deploy content to all sites in specific groups.
Deploying content is done one the post edit screen, searching for the sites or site you wish to deploy to, either using keywords search or dropdown for searching for sites in a network. The sites can then be selected before choosing a deploy action. This is either add/update or delete.
Finally uses hot the Action deploy to sites which pushes the posts data using the WordPress REST API to the endpoint of the destination site. This endpoint then processes that data and creates a new post, updates an existing post or deletes the post, depending on the command sent.
What happens when a content deployed post is received?
When a post is received on the destination site. The deployed content plugin gets to work and does the following:
- Authenticates the user – this makes sure that person deploying the content has the correct permissions and capabilities.
- Check whether the post being deployed already exists. This is done using the post ID of the post in the content master site. If the post already exists we are updating rather than adding.
- Insert or update the post
- Loop through each of the taxonomies and terms assigned to the post. First check whether they exist on the destination site, creating them if they don’t exist and then assigning them to the newly created post.
- Insert any post metadata for the post being deployed
- Store information about the source of the post – the source URL where it was deployed from and the ID of that post in the content master site.
- Store a deployment entry to record this deployment. This records who deployed the post, at what time, from which site and to which destination site along with the command.
Slides
Here you can view the slides from my talk, delivered at WordCamp London 2019 on April 6th. View at the same as the video of my talk above is a good idea.
Managing deployed content
On the sites which have received deployed content, it is displayed alongside any of the content they already have on their site, for example in the post listing screen.
The big difference here, as mentioned above is that the content cannot be edited in WordPress, only viewed on the users’ website. The site owner can also toggle the post status of the content from draft to publish and visa-versa.
Content is protected on the destination site using the “map_meta_cap” functionality. Since we mark deployed content using a taxonomy term, we can easily distinguish content as deployed and then as WordPress loads that content change the current users’ capabilities to prevent them from editing that content.
Handling media for deployed content in WordPress
Deploying content from one site to another does just that – it only deploys the content of the post and not the assets. This means that the content on the deployed site always references the media, such as images from the content master site.
For this reason, the content master site could potentially have a lot of traffic to server that media. To assist with this we used a media offload plugin from Delicious Brains, which allows you to store your media on something more efficient such as an AWS S3 bucket behind a CDN (content delivery network). This makes all the requests to those images much faster.
Since videos are usually embedded from the popular video sharing sites such as Youtube and Vimeo, these work just fine when deployed, as the content is stored on the video site, not locally.
But what about duplicate content
As we know, Google does not like duplicate content on websites and often if you have pages on your site that are the same or the same as other websites Google can penalise you for this.
The get around this you can add a canonical URL to the content. This tells Google where the original source is of the content and to use that as the real source. However, in this example, the canonical source is the content master site which does not have a front-end website.
Therefore, to get around it in this case, we would simply no index the deployed pages. However, this does depend on the sort of sites you are creating that have deployed content as to whether this is the best strategy.
In summary
Content syndication in WordPress, although not quite an out-of-the-box solution, requiring some development expertise and experience can be an excellent solution of delivering content to multiple websites.
Where solutions such as this make sense it can save a lot of time and money for business requiring such solutions.
Get in touch for your syndicating content needs with WordPress