Timed release of pages
Permalink 4 users found helpful
From my experience of using concrete5 for over 2 years, I've noticed that many clients need to be able to create news pages and release them at spesific date/time. I do know that this is possible to achieve with advanced permissions, but I don't find that too convenient. What I mean is that for probably 90% of sites I've done the basic permissions are enough permission-wise, but that leaves out the ability of releasing pages by date/time.
The problem I see here is that advanced permissions are quite a bit harder for less tech-savvy users. Many recent sites that I've done use Composer a lot, which makes releasing news pages very easy. However, the Composer doesn't seem to be able to set permissions on the fly and timed release is out of question. Also, the workflow for advanced permissions is somewhat uncanny, like "create the page first and THEN set it's permissions", which means that the priceless product announcement page could have been public for a moment too early, which is a tangible risk on high traffic sites.
I've noticed that many people mistakenly think the Public Date is for timed release. I do agree that currently it is done the right way and it shouldn't be used for timed releases, as it now allows sites to have listings like "upcoming events", which have their dates in the future.
I'd like to ask opinions from the community that should there be a Release Date attribute for pages? I mean, should it be there by default without creating any custom attributes that are checked in custom templates etc? On many blogging platforms (like Wordpress) the feature is there and is really easy to use.
There are packages like ProNews that have implemented the feature in some way, but I'd like to ask that should it be in Core by default? What do you think?
The problem I see here is that advanced permissions are quite a bit harder for less tech-savvy users. Many recent sites that I've done use Composer a lot, which makes releasing news pages very easy. However, the Composer doesn't seem to be able to set permissions on the fly and timed release is out of question. Also, the workflow for advanced permissions is somewhat uncanny, like "create the page first and THEN set it's permissions", which means that the priceless product announcement page could have been public for a moment too early, which is a tangible risk on high traffic sites.
I've noticed that many people mistakenly think the Public Date is for timed release. I do agree that currently it is done the right way and it shouldn't be used for timed releases, as it now allows sites to have listings like "upcoming events", which have their dates in the future.
I'd like to ask opinions from the community that should there be a Release Date attribute for pages? I mean, should it be there by default without creating any custom attributes that are checked in custom templates etc? On many blogging platforms (like Wordpress) the feature is there and is really easy to use.
There are packages like ProNews that have implemented the feature in some way, but I'd like to ask that should it be in Core by default? What do you think?
bump...am I the only one requesting this feature? :)
I think we should take some time to clean up the UI and details on advanced permissions so they're not as overwhelming. I think we might want to relabel the date created as well. I don't think we want to have overlapping functionality between the modes tho.
Ale,
I would like to see this as a built-in functionality, too. I've been playing around with the built-in (sample content) Blog function... and even I thought that the "Public Date" attribute for a Blog Entry would be when it was published... and was surprised to find out that it DOESN'T do that. So I would think that any non-techie user would be equally confused.
- John
I would like to see this as a built-in functionality, too. I've been playing around with the built-in (sample content) Blog function... and even I thought that the "Public Date" attribute for a Blog Entry would be when it was published... and was surprised to find out that it DOESN'T do that. So I would think that any non-techie user would be equally confused.
- John
yeah me too
i dont think advanced permmision can do this.
i have playing advanced permmision for a while, is someone has play with this, 'currently view' with date?
i think a lot of people still use basic permission.
i dont think advanced permmision can do this.
i have playing advanced permmision for a while, is someone has play with this, 'currently view' with date?
i think a lot of people still use basic permission.
Check times releases inside off advanced permissions. Works great, but is on our todo list to touch up soon
Best wishes
Pecked out on an iPhone
Best wishes
Pecked out on an iPhone
okay franz, thank you
Just wanted to mention I would also find this useful.
Especially if this could be used from within Composer.
Glad to know its on the cards though :)
Regards
Sean
Especially if this could be used from within Composer.
Glad to know its on the cards though :)
Regards
Sean
I agree, I would find this very useful too. And I agree that it would be useful from within the composer :)
And maybe it should be even possible to add the functionality for "timed delete" or "timed hide" for when a page is representing a event, after that event it should not be displayed any more? And all that from the composer - this would be great :)
Thanks to the C5 Team!
And maybe it should be even possible to add the functionality for "timed delete" or "timed hide" for when a page is representing a event, after that event it should not be displayed any more? And all that from the composer - this would be great :)
Thanks to the C5 Team!
play with advanced permissions, you can already do this...
(well sans the timed deletion)
(well sans the timed deletion)
With 5.6 is this something that has been built upon in the standard permissions or is it still an advanced permission level?
advanced.
you can now turn them on thru the dashboard tho.
you can now turn them on thru the dashboard tho.
Pardon my ignorance, but I can't find timed page release feature in 5.6... I'm pretty new to Concrete5, built only one simple site for starters, and been playing around with 5.5.2.1 first, but there I guess it was possible... But in 5.6, I just don't see such option anywhere (or am I blind? :). Schedule Guest Access only applies for blocks, but what about whole page?
***UPDATE***
Aargh, found it... As before, you have to switch page permissions to "Manually," and in View permission specify the access time for Guest. But then it means that in order to set the timed release a user has to 1) have rights to set permissions 2) switch the page permissions from inherited to manual. I totally agree with spinolaconsulting that this is very inconvenient and restrictive:
http://www.concrete5.org/community/forums/usage/setting-pages-to-pu...
To quote spinolaconsulting,
"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."
Too bad there is no progress in 5.6 to address this issue.
***UPDATE***
Aargh, found it... As before, you have to switch page permissions to "Manually," and in View permission specify the access time for Guest. But then it means that in order to set the timed release a user has to 1) have rights to set permissions 2) switch the page permissions from inherited to manual. I totally agree with spinolaconsulting that this is very inconvenient and restrictive:
http://www.concrete5.org/community/forums/usage/setting-pages-to-pu...
To quote spinolaconsulting,
"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."
Too bad there is no progress in 5.6 to address this issue.
Well I can imagine adding a short cut to set the permission on approve edit, but ya know for everything we add like that there's diminishing returns for new guys. Sure if that's what I want to do its "easier" if theres extra interface to let me do it. For the vast majority of folks who don't want to do that at all, its another set of form elements or buttons they need to NOT click on to keep from breaking something.. I do see the potential up side on this, but we'd have to be thoughtful.
We would do it by impacting permissions however- as that's what it is. Who can see the page and when.
We would do it by impacting permissions however- as that's what it is. Who can see the page and when.
I think the thing with the timed release pages is that they are often limited to a small section of a site, a blog or news area. (This is in my experience with the clients we work with)
Enabling advanced permissions often seems a little heavy(hammer to crack a nut, analogy) when all you want to to is provide a way for certain content to be available at a specific time. Advanced permissions adds a lot of extra bits that are (in my case) rarely needed. To be able to do this in composer would be great.
I did once attempt to do something with this and setting attributes depending the post date attribute however this had implications. Pages where not switched back unless someone visits the page, it was not automated correctly. I would be interested to know how the core team work this around the advanced permissions stage? Maybe this is something we could work into a block/package that could circumvent the advanced permissions.
Regards
Sean
edit *spelling corrections
Enabling advanced permissions often seems a little heavy(hammer to crack a nut, analogy) when all you want to to is provide a way for certain content to be available at a specific time. Advanced permissions adds a lot of extra bits that are (in my case) rarely needed. To be able to do this in composer would be great.
I did once attempt to do something with this and setting attributes depending the post date attribute however this had implications. Pages where not switched back unless someone visits the page, it was not automated correctly. I would be interested to know how the core team work this around the advanced permissions stage? Maybe this is something we could work into a block/package that could circumvent the advanced permissions.
Regards
Sean
edit *spelling corrections
Frz, I'm not sure I understood your idea precisely, but I guess adding a shortcut won't solve a problem. Currently, in order to be able playing around with timed access you have to break the inheritance of page permissions (set it to "Manually"), and this is a very bad thing. Not speaking that many people don't need advanced permissions at their sites at all, and this is not possible with simple permissions at all.
In my (and other people, as it seems) opinion a "timed/delayed release" feature should have nothing to do with setting permissions at all. I'm afraid it can be in contradiction with C5's idea of timed release as a special case of guest view access though...
In my (and other people, as it seems) opinion a "timed/delayed release" feature should have nothing to do with setting permissions at all. I'm afraid it can be in contradiction with C5's idea of timed release as a special case of guest view access though...
Well, when you change a page from inheriting to manual override, it
copies all the permissions down just as they were, so it's not like
we're asking you to recreate some complicated setup. It seems if
you're depending on inheritance, and you're able to break that because
timed releases exist outside of permissions, your faith in inheritance
should be in question.
I get that "advanced" sounds scary and you might not need all the
power that advanced permissions gives you. That being said, they're
really not that different than the basic permissions. If you don't
start configuring them all strangely, they wont get in your way.
I'm afraid I really don't agree with the idea that controlling who can
see a page and when isn't a permission. Permissions by their very
definition control who can do what, when.
I can certainly see the argument for making it easier to get to timed
releases at the page level, I mean we fell for that argument at the
block level - so that seems like an obvious extension.
I can see the argument for making timed releases work at a basic
permission level. You could still control which group can see it and
when, but not get the opportunity to learn about the rest of the
things you might be able to pull off with advanced permissions.
Where I am on it today is that the potential upside of having a client
start to wonder what else they might be able to pull off with
permissions out weighs the rather measured pain of having to turn on
advanced permissions and show them how it works. Did you know you can
serve different content to different groups? How about making a
private area and turning that small marketing site into an extranet
project?
Much of what has worked for us with concrete5 is clients starting with
an immediate problem and then slowly taking on more and more over time
with their website. My concern is that if we're always rethinking
features to be geared towards one specific immediate use case, and not
taking the opportunity to show people how the tool is solving
problems, there will be no learning, experimentation and creativity.
Ie you're delivering a finished airplane model instead of a lego set.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
copies all the permissions down just as they were, so it's not like
we're asking you to recreate some complicated setup. It seems if
you're depending on inheritance, and you're able to break that because
timed releases exist outside of permissions, your faith in inheritance
should be in question.
I get that "advanced" sounds scary and you might not need all the
power that advanced permissions gives you. That being said, they're
really not that different than the basic permissions. If you don't
start configuring them all strangely, they wont get in your way.
I'm afraid I really don't agree with the idea that controlling who can
see a page and when isn't a permission. Permissions by their very
definition control who can do what, when.
I can certainly see the argument for making it easier to get to timed
releases at the page level, I mean we fell for that argument at the
block level - so that seems like an obvious extension.
I can see the argument for making timed releases work at a basic
permission level. You could still control which group can see it and
when, but not get the opportunity to learn about the rest of the
things you might be able to pull off with advanced permissions.
Where I am on it today is that the potential upside of having a client
start to wonder what else they might be able to pull off with
permissions out weighs the rather measured pain of having to turn on
advanced permissions and show them how it works. Did you know you can
serve different content to different groups? How about making a
private area and turning that small marketing site into an extranet
project?
Much of what has worked for us with concrete5 is clients starting with
an immediate problem and then slowly taking on more and more over time
with their website. My concern is that if we're always rethinking
features to be geared towards one specific immediate use case, and not
taking the opportunity to show people how the tool is solving
problems, there will be no learning, experimentation and creativity.
Ie you're delivering a finished airplane model instead of a lego set.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Franz,
certainly I understand that permissions are copied down when I break the link by setting them to "Manually". But what if later I decide to change root page permissions? They won't be copied down again. That's the problem. Imagine if there are dozens or hundreds of news articles below a root, which all are supposed to inherit permissions of the latter...
Well, hmmm (thinking as I type), maybe in this case the solution is not relying on permission inheritance, but rather using Page Type-referenced permissions?
Another problem. I don't want to give my Content Managers (members of a user group, who are limited in their abilities - they are supposed to manage content, but should not mess around with more sophisticated system aspects) the ability to change page permissions. On the other hand, they should be able to routinely set timed/delayed release. A separate permission like "Schedule Guest Access" would be perfect, but... it works only for Blocks, not for the whole pages.
Lastly, I'm personally not afraid of advanced permissions and feel at home with and very much appreciate the new, complex system of 5.6. At the same time I understand people who don't want to or are not able to dive in this system - but still would like to be able using timed release.
certainly I understand that permissions are copied down when I break the link by setting them to "Manually". But what if later I decide to change root page permissions? They won't be copied down again. That's the problem. Imagine if there are dozens or hundreds of news articles below a root, which all are supposed to inherit permissions of the latter...
Well, hmmm (thinking as I type), maybe in this case the solution is not relying on permission inheritance, but rather using Page Type-referenced permissions?
Another problem. I don't want to give my Content Managers (members of a user group, who are limited in their abilities - they are supposed to manage content, but should not mess around with more sophisticated system aspects) the ability to change page permissions. On the other hand, they should be able to routinely set timed/delayed release. A separate permission like "Schedule Guest Access" would be perfect, but... it works only for Blocks, not for the whole pages.
Lastly, I'm personally not afraid of advanced permissions and feel at home with and very much appreciate the new, complex system of 5.6. At the same time I understand people who don't want to or are not able to dive in this system - but still would like to be able using timed release.
Snobo,
I completely agree with you. We've been implementing CMS applications for years, and the notion that we have expose users to complicated permissions, whilst fundamentally also exposing site-altering behaviour and authoring just to set a publish date/time is crazy.
Whether from a programming perspective it makes sense to have an automated publish start/end date/time in Permissions doesn't mean a fraction of that couldn't be exposed via the user UI to allow, what most end users of the CMS consider, a simple task.
Out clients pay tens of thousands of dollars to design agencies to come up with designs, they pay us to allow their authors to be able to create content and entrust us to make the CMS behave that their authors can't break the design, and so 90% of the time we lock down all the themeing, permissions, layouts, etc for pages and blocks straight off the bat. We want content authors to focus of content, context and publication - not adding 3 column layouts, changing presentation, changing caching rules, etc. Advanced Permissions goes hand-in-hand with this.
From the number of threads talking about this glaring user-centric omission, to the confusing existing Public Date/Time that DOES exist in the Page Properties (which editors then think does achieve part of their timed-publication needs), I think this needs addressing.
For mid-tier clients it's one of the biggest failings of C5 with multi-author deployments (alongside the standard open source propensity to do content editing in a WYSIWYG editor), and is something we have to constantly apologise for to out clients.
I second snobo in everything he has said, and whilst I understand that from a data / model perspective that the exposure of a page with regard role / user / time is a form of permission, the user's view of that and interaction does NOT need to be tied to all of the other advanced permissions that are far more sensitive and potentially damaging to a client's site than simple exposure of, say, a news article or short-time product offer.
I completely agree with you. We've been implementing CMS applications for years, and the notion that we have expose users to complicated permissions, whilst fundamentally also exposing site-altering behaviour and authoring just to set a publish date/time is crazy.
Whether from a programming perspective it makes sense to have an automated publish start/end date/time in Permissions doesn't mean a fraction of that couldn't be exposed via the user UI to allow, what most end users of the CMS consider, a simple task.
Out clients pay tens of thousands of dollars to design agencies to come up with designs, they pay us to allow their authors to be able to create content and entrust us to make the CMS behave that their authors can't break the design, and so 90% of the time we lock down all the themeing, permissions, layouts, etc for pages and blocks straight off the bat. We want content authors to focus of content, context and publication - not adding 3 column layouts, changing presentation, changing caching rules, etc. Advanced Permissions goes hand-in-hand with this.
From the number of threads talking about this glaring user-centric omission, to the confusing existing Public Date/Time that DOES exist in the Page Properties (which editors then think does achieve part of their timed-publication needs), I think this needs addressing.
For mid-tier clients it's one of the biggest failings of C5 with multi-author deployments (alongside the standard open source propensity to do content editing in a WYSIWYG editor), and is something we have to constantly apologise for to out clients.
I second snobo in everything he has said, and whilst I understand that from a data / model perspective that the exposure of a page with regard role / user / time is a form of permission, the user's view of that and interaction does NOT need to be tied to all of the other advanced permissions that are far more sensitive and potentially damaging to a client's site than simple exposure of, say, a news article or short-time product offer.
It's our intention to build timed releases into basic permissions in 5.7.
After waiting for one year and four months I was most pleased to mark Your answer as _the_ best answer ;)
Joking aside, thank you very much. Really, I'm most delighted to see the feature coming to basic permissions. Looking forward to 5.7.
Joking aside, thank you very much. Really, I'm most delighted to see the feature coming to basic permissions. Looking forward to 5.7.
Did this ever become a reality?
Not from what I can see, such a shame, and I am no geek but it must not be that tricky. Seems like I may have to stay up to midnight to hide a client's page, having just assumed this was possible. I can't be messing with the permissions on the live site at this critical point. Would be a lovely addition.
This is on the version 8 todo list.
"Add Timed Release of Pages #3339"
https://github.com/concrete5/concrete5/issues/3339...
"Add Timed Release of Pages #3339"
https://github.com/concrete5/concrete5/issues/3339...
I've never found that enabling advanced permissions causes any problems, it really just unlocks more functionality.
Timed access can then be controlled against 'Guest' permissions quite easily, see attached.
Timed access can then be controlled against 'Guest' permissions quite easily, see attached.
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 marketplacehttps://www.concrete5.org/marketplace/addons/page-timer/...
Our upcoming C5DK News package (not yet in PRB) has this feature build in (even for none administrators). We have build a news system that involves both writer and editor permission levels - Writers can postpone an article in date and time - The editor can control all writers articles, time of release and we have given the editor the tools to list every news article in different categories.
We even made a setting that will not allow the writer to delete a article fx. 15 minutes after release time.
Either writer or editor needs to be an administrator of the site.
Our package is currently on beta testing on 2 news sits in Denmark...
We even made a setting that will not allow the writer to delete a article fx. 15 minutes after release time.
Either writer or editor needs to be an administrator of the site.
Our package is currently on beta testing on 2 news sits in Denmark...
For 5.7.x users wanting this...
https://github.com/olsgreen/concrete-timed-release...
The package allows you to set the 'Public Date / Time' / 'Date Added' page attribute to a future date / time to control page visibility to guest users. It sets a 'Duration' object against the Guest groups 'view_page' permission which will hide the page from guest users until the given date / time, the same way as advanced permissions works, just a hell of a lot easier for end users.
https://github.com/olsgreen/concrete-timed-release...
The package allows you to set the 'Public Date / Time' / 'Date Added' page attribute to a future date / time to control page visibility to guest users. It sets a 'Duration' object against the Guest groups 'view_page' permission which will hide the page from guest users until the given date / time, the same way as advanced permissions works, just a hell of a lot easier for end users.
Nice. Thank you.
Hi, is there a version for version 8? Or any other new way to schedule a page to be published in the future?
Thanks,
Luca
Thanks,
Luca
