Setting Pages to Publish at a Future Time
Permalink 2 users found helpful
I have yet to figure out what the setting for "Public Date/Time" does. Can anyone explain this?
My initial thought was that it was a way to set pages to "go live" at a date and time in the future, which would be completely intuitive and quite handy for things like press releases and new product announcements. Unfortunately, it does not have any effect on when the page will be live.
Instead, to make a page live at some time in the future, I have to set the page permissions to "Manual" then set the "Timed Release Settings" for each permissions group, which seems very clunky and counter-intuitive to me. After all, I don't want to determine WHO can see the page, just WHEN. This implementation might be intuitive to a developer, but it makes no sense to me and I'm guessing to others like me who are not developers.
Additionally, requiring content authors to manually set permissions to achieve something as basic as future publishing is a frightening proposition to me as a site administrator. My authors should be able to write a press release or new product announcement tonight and set it to "go live" tomorrow or next week. They shouldn't have to muck around in page permissions to achieve this. Also, setting the page to "Manual" permissions breaks the permissions model by removing the page's permissions inheritance from its parent. That could result in an awful mess if you do this sort of thing a lot.
I'd like to see some better way to make a page go live in the future that does not require me to manually edit page permissions. As it currently stands, "Public Date/Time" is a confusing setting since it doesn't appear to do anything, and the mechanism for making a page go live in the future is unintuitive and disruptive.
Unless I'm missing something...
My initial thought was that it was a way to set pages to "go live" at a date and time in the future, which would be completely intuitive and quite handy for things like press releases and new product announcements. Unfortunately, it does not have any effect on when the page will be live.
Instead, to make a page live at some time in the future, I have to set the page permissions to "Manual" then set the "Timed Release Settings" for each permissions group, which seems very clunky and counter-intuitive to me. After all, I don't want to determine WHO can see the page, just WHEN. This implementation might be intuitive to a developer, but it makes no sense to me and I'm guessing to others like me who are not developers.
Additionally, requiring content authors to manually set permissions to achieve something as basic as future publishing is a frightening proposition to me as a site administrator. My authors should be able to write a press release or new product announcement tonight and set it to "go live" tomorrow or next week. They shouldn't have to muck around in page permissions to achieve this. Also, setting the page to "Manual" permissions breaks the permissions model by removing the page's permissions inheritance from its parent. That could result in an awful mess if you do this sort of thing a lot.
I'd like to see some better way to make a page go live in the future that does not require me to manually edit page permissions. As it currently stands, "Public Date/Time" is a confusing setting since it doesn't appear to do anything, and the mechanism for making a page go live in the future is unintuitive and disruptive.
Unless I'm missing something...
I totally subscribe to everything you say. Could not have described the problem better. Too bad that 5.6, while thoroughly revamping (and improving) the permission mechanism, still hasn't addressed this.
The Public Date/Time is just the date and time the page _seems_ to be published. It allows you to create page today and make it look like it was published last year (or next :) ). I agree that the name is somewhat misleading and makes you think the page is invisible until that date. I recall that on some Totally Random web stream the core team mentioned something about changing the naming on that attribute.
While the new permissions UI made many things much simplier, I still agree that using advanced permissions for timed release is a bit overkill. Especially the fact you mentioned about breaking permissions inheritance when setting them manual, just to achieve a simple timed release. In my opinion there should be a "release date" attribute that could be used for timed release and IF there's any need for some more complicated settings on release (like different group options etc), they could be achieved with adv. permissions.
I think this topic has been talked many times before. I wonder if there is some special technical difficulty on making such attribute work seamlessly with all the other stuff in core? It would be nice to hear some insight from core team about this.
While the new permissions UI made many things much simplier, I still agree that using advanced permissions for timed release is a bit overkill. Especially the fact you mentioned about breaking permissions inheritance when setting them manual, just to achieve a simple timed release. In my opinion there should be a "release date" attribute that could be used for timed release and IF there's any need for some more complicated settings on release (like different group options etc), they could be achieved with adv. permissions.
I think this topic has been talked many times before. I wonder if there is some special technical difficulty on making such attribute work seamlessly with all the other stuff in core? It would be nice to hear some insight from core team about this.
I've been fighting with this lack of easy timed release from the beginning I started using concrete5. Now I got it packed to easier use without advanced permissions. It can be found in marketplace
https://www.concrete5.org/marketplace/addons/page-timer/...
https://www.concrete5.org/marketplace/addons/page-timer/...
