This is a guest post by Jan Krueder, who asked whether I could solve a content sharing problem.

Scenario

 

Use-Case

This use-case describes a network of entertainment websites that are being built to target individual interest groups such as parents, teachers, seniors, or specific events like Easter, Halloween, or Christmas. The network will be operated in a franchise-like mode. While the network sites are designed to be operated and administrated individually, they will be governed by a network wide shared set of user data, custom post types and taxonomies, as well as shared content that can be extended by network sites based on their individual needs. Site administrators and editors of the network sites are generally independent in their site management and editorial content, as long as they follow certain network standards. A key aspect of the model is the content syndication from the main network site (the network owner) to the individual network sites.

Implementation – Challenges and Solutions

The idea and model as described in the use-case was born from experience the author has made with one specific site (kindergaudi.de) that has been running successfully for over 15 years. Over time, thousands of posts and related content has been aggregated that was specifically geared towards a certain interest group (german speaking parents and educators) in the area of crafting, recipes, coloring, activities, etc. For years, the site had been operated with a proprietary content management system that became more and more a liability and made a relaunch inevitable in fall of 2019. In planning the relaunch of the site, however, the team realized that the majority of the content was fairly universal and not necessarily just limited to the specific interested group of kindergaudi.de, but could also be used for other interest groups or sites for specific events. Therefore, the above use-case was defined and elaborated and a plan was developed to extend the use of the existing content towards other sites and specific target groups. This plan did have it’s challenges, though…

1. Technical Challenges
   1. The existing content was stored in a proprietary form in a mysql database and used a proprietary CMS – how do we transfer the data into a new system?
   2. The existing content was organized in several independent sections d.t. various content specific information (recipes need different info fields than e.g. crafts or trips) – how do we still maintain the inherent logic and interrelations btw these content artefacts?
   3. how can we easily share content between sites and in particular from the central repository site to network sites?
   4. how can we make network site administrators independent, but still maintain network coherence?
2. Editorial Challenges
   1. the existing content was written with a specific interest group in mind, so it was written in a certain language using key words (kids, family, kindergarden, school, …) – how do we sanitize the content so it can be re-used easily, but still be adapted to target specific interest groups?
   2. How do we ensure content that is being re-used by specific sites is properly updated without having to manually update each and every post of each site that re-uses it?
   3. How do we share content when new sites are added to the network later without having to go through each and every post that is being shared again?

This article is about how broadcast and it’s new feature “parent-pull” solves several of these challenges, so we will focus on that. Just for completeness, I want to quickly mention what tools were used to solve the other challenges:

1. Technical Solutions:
   1. use of wordpress in multisite network setup (sub-domain install) as the basis was a quick decision, the data transfer was then successfully completed by use of the wpallimport plugin. A decision was also made to import and manage all content in a network central site (gaudinauten.net) which is not publicly accessible, but serves as the network content repository
   2. The pods framework plugin was found to be the ideal solution to establish and manage custom post types and taxonomies, The structure of the CPTs and taxos can be easily transferred to other sites as a basis for content sharing
   3. It was soon found, that the broadcast plugin with control pack addon was perfect to enable content sharing/syndication btw network sites and early implementations have proven to be very stable and reliable. There was just one problem: scalability – and we are discussing that below.
   4. for certain administrative tasks and configuration settings that are considered desirable to be applicable for all network sites, a proprietary plugin is being developed to add this functionality.
2. Editorial “Solutions”
   1. there’s just one way to adapt the content of the posts, they have to be edited. Therefore, all post content on the repository site is currently being re-written in an as much as possible neutral form, which makes it easier to be shared across interest sites. To allow network site editors to adapt the posts towards their specific interest groups, the custom post types have site-specific fields that can be used for additional intros and informations. The re-writing of content is a tedious but inevitable work and has to be done manually…
   2. the advantage of this approach, however, is that the core information of each post can be centrally maintained and updated. By using the broadcast plugin, it is easy to update information in a post and immediately post the update to any number of connected network sites.
   3. With all this implemented, one challenge remained: what if a new site enters the network family? The editors of the central site would have to go through all posts to re-broadcast them to the new site and with the workload that would induce, it almost seemed to be a killing point for the whole concept.

Introducing broadcast Parent Pull

With the technical implementation mostly defined, the team started to rebuild the content and the original website. In the current test mode, the network only consists of the new network repository site (gaudinauten.net), which is not publicly accessible and behind a simple landing page. Two network sites have been implemented and are currently being tested, one is the original  site (kindergaudi.de) and another one is a site dedicated for the Holiday season (weihnachtsgaudi.de) which only uses a reduced scope of the content and hence was considered suitable for testing the functionality.

The key to the overall network approach of shared content is the broadcast plugin. It is the pivotal element of the setup that enables sharing posts across the sites. It has proven very powerful and with the addition of the control pack addon the plugin provides an easy and straightforward way to broadcast content from the central network site to other sites.

There was just one problem: whenever a new site will be added to the network, every post that shall be used on the new site would have to be edited in the repository, marked for broadcast to the new site and re-published again. Those posts would get an updated “last modified date” on the repository and by default on each site that the post is broadcasted to. While the latter can be prevented by using the resp. feature from the control pack addon, it still updates the last modified date on the repository. Not nice, but probably acceptable. The bigger issue for this use-case, however, was that the only way to broadcast posts to the new site was by the editors of the repository site to walk through all posts that were supposed to be broadcasted and edit them manually. That was not considered a feasible approach, because for once, it would put a huge workload on the editors of the repository, and second it wouldn’t allow the network site admins the autonomy and flexibility that we wanted them to have.

That’s when we reached out to Plainview Plugins, the author and distributor of broadcast. After briefly discussing our use-case and needs statement, in less than 4 weeks we were presented with a test-version of the new parent-pull feature which now provides everything we need to finally implement the full use-case.

Install broadcast and the control pack addon

The first step ist to install the broadcast plugin and control pack addon through the network’s main site. Activate both plugins and also activate parent pull in broadcast’s add-on menu.

Make sure you have the same custom post types and taxonomies installed on each network site as you have them defined on the central repository site.

Activate Parent-Pull

On the network repository site, we create a new pull setup from the broadcast parent-pull configuration page. This is also the menu location from where all parent-pull activities are being started on the network sites, so administrators and/or editors on network sites need to have proper access rights for this menu item.

 

 

Create a new Pull Setup

The next step is to create a new pull setup that defines the possible and allowable combination of sites for the parent pull relationship. Any site that is added as a child side in this setup will be allowed to pull posts from the site marked as parent (the repository in our case).

Here it is also possible to limit the parent-pull permission to certain post types for the sites in this setup. this allows to create fairly complex setup of sites that are allowed to pull content from other sites. For example, if we decide to only allow a certain post type to be pullable by a specific site, we could eliminate this site from the overall pull setup and create  new one with this site as child and only the allowable post type in the pull setup.

Mark posts on Parent Site as pullable

With the pull setup defined, we now mark all posts on the parent site (the repository in our use-case) that can be pulled by network sites. One way to do so is by selecting the checkbox to “Allow parent pull” when editing the post. This can be done on the fly when posts are being updated anyways. However, it is not necessary to individually edit every post on the repository as the parent-pull add-on also provides a way to mark all selected posts in the admin post list as ready for parent-pull. This allows for an easy and quick way to prepare a large number of posts for the parent-pull feature. Once marked as “parent-pull ready”, posts can be pulled to other sites, provided this pull-combination is defined in a pull-setup defined above.

Conclusion

With the new parent-pull feature, Plainview Plugins has significantly increased the usability of the broadcast plugin for this use-case. It is now possible to build on-demand content syndication networks in which network sites can decide on their own what content they want to re-use from other network sites or, like discussed here, from a centralized repository site. Once a post has been pulled from a parent, it can be modified and managed just like any other broadcasted post. The only difference is the way in which the broadcast is initiated – it’s is not a push operation from one site to many, it is a pull operation that one site initiates from another site.