“Expect the unexpected,” they said.
“It’ll be fun,” they said.
We’ve all been there: family emergency, scheduled time off, a phone call that starts with “I hate to ask, but…” There are dozens of reasons why you might have to leave an item before it’s ready to share with the world. Plans change, directions shift, and there aren’t always enough hours in the day. You’re staring at the item you’ve just created or modified. It’s saved as a draft and you trust workflow, but…what if?
What if someone approves your unfinished item while it’s sitting in draft?
What if it goes out before you’re ready to share it?
Publish Restrictions are the answer to that question (and an excellent way to avert an anxiety spiral). They’re a deadbolt, a safety check, determining when an item can be published, controlling from on high when an item is considered publishable.
Publish Restrictions are great for organizations who depend on content being published at specific times; news organizations, blogs, or those times when you need strong control over publishable content. If, for example, an earnings release has to be released at a very specific time or everyone goes to jail, having the proper protocols in place to make absolutely 100% sure that earnings release gets published is essential. Publish Restrictions provide an insurance policy for news organizations, blogs and retail businesses who may not want an item to go live accidentally, and they work nicely for companies that want content to be visible only for a certain period of time, like a special offer or holiday message.
The feature can be very useful, but there are a lot of misconceptions and misunderstandings about how Publish Restrictions work; they require a few manual steps in order to accomplish precisely what you want them to. Say, for example, a restriction is set saying “I want this specific item to be live between Thursday and Friday of this week.” Away you go, job done, confident that the item will go up on Thursday and automatically come down on Friday.
But if that’s all you do, nothing will happen. It’s similar to what happens when you delete an item in Sitecore; that item is removed from the master database, but it still exists everywhere else until the removal is published. Setting Publish Restrictions alone is not enough; ergo only setting the Publish Restrictions defeats the purpose of the function (the point was NOT to wake up at 1 a.m. on Thursday and publish the post). In order to avert catastrophe and be effective, Publish Restrictions require an extra step – you need to set the restriction, then publish and either add or remove that content from the live site.
This extra step is why Hedgehog created the Scheduled Publish Module.
The Scheduled Publish Module not only provides a friendly UI comparable to what content-editors are used to, it also has the ability to un-publish, to notify a person or a group of people of publishes that have occurred, and Edit Publish Schedules shows a complete list of all pending publishes. If you find that Publish Restrictions aren’t flexible enough or that they don’t meet your enterprise level requirements, the Scheduled Publish Module is an option.
A final note: when utilizing Publish Restrictions, remember to check Publishing Settings. If the publishable box is unchecked, no version of the item will ever go live. EVER. It’s also a magic eraser, because if any version of the item is live, it will be removed.