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.
It generalizes publishing using 3 important modules:
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).
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!
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:
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.
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.
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.
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:
As we progress through the discussion of the evolution of Publish2, consider this hypothetical use-case for publishing content to a website:
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.