I have two quick questions, but I’m going to split them into separate
messages, since they are considerably different.
Is there any way to create articles and have them automatically
published in the future? I thought that setting a future date would
work, but the article appeared immediately.
-Rich-
On Mar 2, 2006, at 10:36 PM, Rich W. wrote:
I have two quick questions, but I’m going to split them into separate
messages, since they are considerably different.Is there any way to create articles and have them automatically
published in the future? I thought that setting a future date would
work, but the article appeared immediately.
It’s filed in Trac, but this is not something that is implemented yet.
I actually had a decent idea about this the other day but forgot to
post it to the list. The main problem with this request is
automatically publishing the article when the date passes. The idea I
had was to store the next auto-publish day in a global table and on
each request do a quick comparison against the table and, if the
current date is later than the saved one, sweep the fragment cache
(or, ideally, just the parts necessary to show the article) and re-
set the date to the next time. There’s 2 issues I can think of with
this, but they’re not bad. The first is checking this would probably
incur an extra SQL query per request, but that might be solved by
putting it in the settings table (since it is a kind of pseudo-
setting) which gets loaded anyway. The second issue is two fcgi
processes processing requests at the same time and both detecting the
date has passed, but I don’t think this is a problem either because
all that happens to publish the article is the cache is swept, and
there’s no problem with sweeping it twice - it just means one more
uncached request.
Scott L., if you’re reading this, do you have any thoughts on this
suggestion?
It seems to me, anything with a publication date in the future should
not be displayed. Which means it could be fixed with a very minor
change to the way the model grabs articles from the database.
Of course, the article could probably still be pulled up using the
search or archives. Maybe just change the model so the published flag
always returns false until the publication date/time has passed.
Again, I haven’t cracked open the code yet.
-Rich-
On Mar 2, 2006, at 11:16 PM, Rich W. wrote:
It seems to me, anything with a publication date in the future should
not be displayed. Which means it could be fixed with a very minor
change to the way the model grabs articles from the database.Of course, the article could probably still be pulled up using the
search or archives. Maybe just change the model so the published flag
always returns false until the publication date/time has passed.
Again, I haven’t cracked open the code yet.
It’s fairly simple to make articles that are in the future be treated
as unpublished. The problem is caching - you need some way to
invalidate the cache as soon as the date passes, so the article will
appear. Otherwise the article will never appear until the cache is
invalidated some other way (e.g. by posting another article,
commenting, manually clearing it, etc).
On Friday 03 March 2006 17:36, Rich W. wrote:
I have two quick questions, but I’m going to split them into separate
messages, since they are considerably different.Is there any way to create articles and have them automatically
published in the future? I thought that setting a future date would
work, but the article appeared immediately.
I have another question on my mind related to drafting: why can’t I
preview a
page which isn’t published?
I know I used to be able to, some time in the past, go directly to the
URL of
an unpublished page to make sure it looks right. But that was changed
for
some reason, perhaps as a side-effect of simplifying the Article model?
TX
Invalidating the cache would not need to happen exactly when the date
passes. This is kind of an “if a tree falls in the woods…” question.
If
the site updates when a user accesses the site after the date (could be
a
second later, could be an hour later), triggering the cache
invalidation,
it’s as good as if it were done with a cron or other scheduling process.
Of course, your other option is to run an external trigger, like a rake
run
from a cron job. This brings up platform issues, but hopefully we could
iron that out on the list.
I imagine that was deliberately changed so nobody could see an
article before it was published.
On Saturday 04 March 2006 04:18, Kevin B. wrote:
I imagine that was deliberately changed so nobody could see an
article before it was published.
Hmm… IMO, it’s a regression. I’m logged in as an admin, I should have
some
way to preview the page I just spent half an hour writing.
Right now, I need to set it to published, quickly jump across and look
at it,
and then set it back to draft.
I guess it wouldn’t matter so much if the live preview pane showed the
article
in the correct theme. 
TX
On Mar 3, 2006, at 2:02 PM, Trejkaz wrote:
in the correct theme.
I actually tried to fix the preview in that regards, but it’s a tough
nugget to crack. You need an iframe there so it can be completely
self-contained, but the trick is getting the content in to it
reliably, which is where I had trouble. If somebody else wants to
take a crack at it, go ahead.
Actually, invalidating the cache is mostly already done–the
currentcaching code lets you publish pages with an expiration date; once
thatdate passes, the cache entry will disappear on its own. So, all
wereally need is a way to calculate a global default expiration
datebased on the next unpublished article.
I’ll take a look at it in a week or so, once a few other bugs have been
closed.
Scott
On 3/3/06, Ernie O. [email protected] wrote:>> Invalidating
the cache would not need to happen exactly when the date> passes. This
is kind of an “if a tree falls in the woods…” question. If> the site
updates when a user accesses the site after the date (could be a> second
later, could be an hour later), triggering the cache invalidation,> it’s
as good as if it were done with a cron or other scheduling process.>> Of
course, your other option is to run an external trigger, like a rake
run> from a cron job. This brings up platform issues, but hopefully we
could> iron that out on the list.>>>>> On 3/3/06, Kevin B.
[email protected] wrote:> >> On Mar 2, 2006, at 11:16 PM, Rich W.
wrote:>> > It seems to me, anything with a publication date in the
future should> > not be displayed. Which means it could be fixed with a
very minor> > change to the way the model grabs articles from the
database.> >> > Of course, the article could probably still be pulled up
usin!
g the> > search or archives. Maybe just change the model so the
published flag> > always returns false until the publication date/time
has passed.> > Again, I haven’t cracked open the code yet.>> It’s fairly
simple to make articles that are in the future be treated> as
unpublished. The problem is caching - you need some way to> invalidate
the cache as soon as the date passes, so the article will> appear.
Otherwise the article will never appear until the cache is> invalidated
some other way (e.g. by posting another article,> commenting, manually
clearing it, etc).>> → Kevin B.> [email protected]>
http://kevin.sb.org> http://www.tildesoft.com>>>>>
_______________________________________________> Typo-list mailing list>
[email protected]>
http://rubyforge.org/mailman/listinfo/typo-list>>>>>>> → Ernie>
http://www.shokk.com/blog/>
_______________________________________________> Typo-list mailing list>
[email protected]> http://rubyforge.org/mailman/listinfo/typo!
-list>>
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs