Introducing Publish2

Publishing is about presenting the right content to the right audiences at the right time. Publish2, which has evolved over years of practice by The Plant in publishing content to the web, aims to provide the right solution for it.

To be clear, Publish2 is the successor to Publish, we believe it is a superior solution worth moving to in cases where Publish needed a lot of customization and definitely for any new projects that require publishing features.

What is Publish2?

Version: to allow an object to have more than one copies and chain them together

Publishing complexity varies from scenario to scenario. For example, it could be as simple as posting an article, or as complex as continuously publishing a changing resource. We don’t want to crack a nut with a sledgehammer, but we may need to address complex problems as our business grows. That’s why Publish2 is separated into 3 modules and the modules are designed to be composable. Each module simply does one thing, but in combination, they could solve more complex problems. By the way, modularity and composability are parts of QOR’s core philosophy.

Publish2 also provides a new section within QOR Admin for listing upcoming content resource publishing changes, i.e. what content is coming online and what content is going offline. In case you need to schedule a group of objects, the Schedule module has a scheduling event helper. In the QOR Admin Frontend Editor view, we have a Time Travel component for navigating through time, so you can make sense of how your site will look like in the future (or even how it looked in the past).

Use cases

We’ve been using Publish2 ourselves for some time, and would like to share some of our own use-cases with you to show how useful the new tool is. We’d also love to hear about how you use it, when you do!

A legal document system

We’re working on a client project that manages all their legal documents in the global context. The Publish2 solution has been implemented as follows:

Admins can take a legal doc online/offline using Visible

Admins can make a legal doc effective on a specific date using Schedule

Admins can make a minor/major update of a legal doc, which will automatically make a new version, using Version

The system utilizes all 3 modules of Publish2, with minor customization on the version numbers created and managed by Version to suit our client’s specific needs. The client is very happy that the docs are well versioned as prior to the Publish2 solution, variations (versions) of a document were separated in different files, potentially many different files - which could result in a mess.

Campaign pages

Consider an app that requires a marketing campaign which has several phases: the campaign page needs to show different content during each phase. Prior to Publish2

Suppose you’re launching a new product, you may divide the process into 3 stages: buzz-building, pre-release, released. In the buzz-building stage, you try to activate all channels you can reach to, saying that you have something major that’s coming soon. While you’re gaining attention, entering into the pre-release stage, you announce the product and allow pre-ordering. When your product is finally ready, the released stage, then you can guide your customers to your shop.

With Publish2, you can create a campaign that has 3 versions, each version will be activated during different time ranges (corresponding with the 3 stages outlined above). When visitors hit the same URL during different phases, they see the appropriate content for that phase. You can prepare all the content well in advance or you can assemble them just before the commencement of the next phase.

Our clients from the marketing department, they run dozens of campaigns every year. By taking advantages of Publish2 along with some templates, they avoid rebuilding campaigns, which saves them a lot of time and money.

Please try it!

The scenarios discussed above use the full features of Publish2. Do these examples inspire you to apply Publish2 to your own business? If it seems a bit heavy, remember that Publish2 is designed to be composable so you’re not required to use all 3 modules. You can use the Version to build your wikis; use Visible and Schedule to manage your EC sites or blog. Just use what you need and you’re not forced to use more.

At The Plant, we are gradually migrating more and more projects to utilize Publish2(instead of the old Publish). We encourage you to try it. If you found any bugs or problems, please feel free to submit an issue on Github.

Please find the documentation here. If you would like to get a sense of what the UI looks like, please try out the live demo. We have applied it to the Articles and Products. You might as well check out the publishing schedules and events.

Keep reading if you are interested in how the publishing mechanism evolved over the years from an engineering perspective.

The evolvement

We started the QOR project early when the company was funded. Content publishing plays an important role in QOR. I think it’d be interesting to look back into the process of evolvement. We’ve never considered something as done, technically. We always improve and polish our tools/products. But, generally, I divide it into 3 stages:

QOR2 Publish(note: QOR2 was not open-sourced)

QOR3 Publish

QOR3 Publish2

As we progress through the discussion of the evolution of Publish2, consider this hypothetical use-case for publishing content to a website:

Inadequacies in QOR2 Publish

QOR2 Publish requires two applications running in different environments (production and staging), each connecting to an independent DB. When publishing, data is copied from the staging DB to the production DB. This allows content to be created and edited on the staging site, then after verification that new content could be pushed to the production site in “one fell swoop”.

Problems:

It could take a long time to publish for some cases.

We didn’t develop a feature to take things offline.

It could be a burden to sync data created on production DB back to the staging DB.

An Administrator could only set up and schedule one future version of any content resource at a time, having to await that version being published before being able to set up and schedule the next version.

Our clients have been mostly happy with this solution, however as needs grow and websites become more advanced, problem scenarios were appearing more and more…that need lead to the development of QOR3 Publish.

Inadequacies in QOR3 Publish

In QOR3 Publish we eliminated the two DB/environment structure by instead using two tables (draft tables vs. production tables) for content that needs to be publishable. We were freed from the slow syncing process when publishing content to production. What’s even better was we don’t have to set up two apps on two environments, rather staging and production data is contained within the one app - which yielded obvious cost savings for our clients.

A problem point for our clients was that when they wanted to edit data that was already in production, they had to go through the staging-to-production process, which was a hassle from a UX perspective. There was also no means to unpublish content, an Administrator could only delete content at the time it needed to go offline. These needs lead to the development of QOR3 Publish2. And still, an Administrator could only set up and schedule one future version of a content resource at a time.

What about QOR3 Publish2?

Except for more features Publish2 provides, we now have only one table. No data copy anymore. Content to be displayed in production/staging is determined by the logic of the Visible and the Schedule module.

Administrators can now set up and schedule various future versions of a content resource, plus add new versions ad-hoc and unpublish if/when need be.

Cool new features:

Date Ranges (a version could be published at a start time until forever, where any newer version published after would take over, or could be published from a start time to a specific end time allowing unpublishing of the content resource).

Publish Events (special, named events can be defined as Date Ranges to align Administrators with, for example, marketing campaigns like a ‘New Years Sale’).

Time Travelling (an Administrator can view how the site did or will look at any time in the past or future. This also means more traceability with respect to content and content changes, there is a history of changes now).

Thank you!

Thank you for reading this article. I hope you like our Publish2. Please do try it when you have a chance. Make comments if have questions. Cheers!