[typo] Q1: automatically publishing files.
rwmlist at gmail.com
Fri Mar 3 02:16:24 EST 2006
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.
On Mar 2, 2006, at 8:55 PM, Kevin Ballard wrote:
> On Mar 2, 2006, at 10:36 PM, Rich Warren 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 Laird, if you're reading this, do you have any thoughts on
> this suggestion?
> Kevin Ballard
> kevin at sb.org
> Typo-list mailing list
> Typo-list at rubyforge.org
More information about the Typo-list