So, you’d like to stick a “Best Before” label on those articles?
As almost nothing is made to last forever, articles may carry an expiry date/time in the upcoming Textpattern 4.0.7 release.
Various hacks and plugins have catered for this requirement in the past, with each of those having their own issues: They’d either hide articles in webfeeds up to the expiry date or on the contrary publish expired articles through feeds even past the expiry date, or mangle the article’s data itself.
With Textpattern 4.0.7, an additional timestamp designates an article’s expected shelf life:
Related tags
A few new template tags will complement this feature:
<txp:expires />mimicks the behaviour and attribute set of<txp:posted /><txp:if_expires>...<txp:else />...</txp:if_expires>: Checks for the mere presence of an expiry date.<txp:if_expired>...<txp:else />...</txp:if_expired>: Checks if the current article is past its expiry date.
Preferences
One additional preference setting dubbed “Publish expired articles” changes the way how Textpattern handles expired articles.
If set to “Yes”, articles will stay visible to the public even after their expiry time has elapsed. At first glance, this might look a bit nonsensical, but this is where <txp:if_expired> has its chance to chime in and render a slice of conditional markup for past gigs, training courses, announcements, whatever – without ripping out precious pages from the search engines’ indexes.
Setting “Publish expired articles” to “No” results in a snippy ‘410 Gone’ response when an expired article is requested. As for all of Textpattern’s 4xx responses, you can craft a page template named ‘error_410’ to customize the looks of that response page.
Posted 11 November 2008, 09:57 by Robert Wetzlmayr ·
Digg This
And while we all think that there is nothing happening here, Robert comes out with this brilliant news!
— Michael · Nov 11, 10:04 AM · #
This is excellent! I can’t wait to get the new version ;)
— Dragon Z. · Nov 11, 11:02 AM · #
Great news, great feature. Thanks!
— Jiri Melcak · Nov 11, 12:37 PM · #
That’s just great!
— Michiel · Nov 11, 02:52 PM · #
Great to see news from Textpattern in my Twitter feed : )
— eileen · Nov 11, 03:15 PM · #
This is absolutely fantastic news. I’m using textpatten to drive our company intranet and article expiry is a hot topic at the moment. The plugins tried so far have all had their weaknesses.
— Doug · Nov 11, 06:32 PM · #
I’m curious to see how this is going to be implemented. Adding another fieldset means that when “More” is expanded, the publish button would be significantly lower than the article and excerpt fields. I can think of several other questions. What are the default settings for new articles? What if the user doesn’t want to use expiration dates at all?
The <txp:if_expired /> conditional tag is great, but I’m not so keen on ‘removing’ expired information. I believe that all of the web should always be accessible, even if something is way-out-of-date. Do we really want to have expired articles result in a 410 error? That can be an abrupt dead end.
— Dave DeSandro · Nov 11, 08:23 PM · #
Dave, you might want to read the post once again. There’s a section on preferences which addresses your concerns about the 410 response, and there’s a screenshot a little above that paragraph.
Hiding the additional fieldset is a matter of a three-line plugin if one is inclined to do so.
The default expiry date is empty, resulting in an everlasting article. If the user doesn’t want to use expiration dates at all, she is best advised to simply ignore these.
— Robert · Nov 11, 08:29 PM · #
It’d be really helpful for us (and cool!) if there was an admin setting controlling the default expiry value to be x days after timestamp/publish date. (Once filled in the expiry date would not change.)
— PascalAndCamelCaser · Nov 11, 10:00 PM · #
Robert – thanks for clearing that up. I was concerned with the default values for new articles. Everything else should be fine then.
And, up until this point everyone else was applauding your efforts so I guess I had to rain on the parade. Sorry! :)
— Dave DeSandro · Nov 11, 11:40 PM · #
PascalAndCamelCaser, I’m sure plugin authors will find many ways to fulfill requests like yours. This won’t fit into the Textpattern CMS core as demands will differ too much.
— Robert · Nov 12, 04:17 AM · #
Wonderful! Thanks to all involved.
— Sven · Nov 12, 10:27 AM · #
Nice news.
It would be good if there was a possibility of looping trought Timestamp and Expire date on daily/weekly basis…
For instance: from 14h to 16h every Friday, like a radio show. That would make a possibility to use Articles as reccuring events, and some other event managing features.
— hamato · Nov 12, 02:45 PM · #
Great new feature and tags! These changes per se will make it worth updating to 4.0.7. Thanks, Robert!
— Uli · Nov 14, 04:43 PM · #
Robert, instead of having an publish expired articles preference wouldn’t it be better to control that in the article tag? Something like “Show Expired = yes”
I guess I don’t understand why it needs to be a preference.
— Jeff Adams · Nov 15, 07:26 PM · #
@Jeff: Not to speak for Robert, but I would say since the publishing date is managed at that location anyway, putting the expiration date right there in context makes reasonable sense. I can imagine there will be client users of this feature too (not just site developers) who might decide to use it as an afterthought (as opposed to being a planned development), thus an admin-side pref makes sense there too.
— Destry · Nov 16, 12:43 AM · #
Excellent news. I’ve cobbled together “expired” functionality before using a custom field but it’s much more satisfactory to have it built into the core with standard TXP tags. Well done and thanks.
— Adi · Nov 16, 05:17 AM · #
Jeff, please keep in mind that this preference controls the public display of articles in both the website and the feeds.
We have no opportunity to express preferences for the feeds’ contents besides setting preferences, so having a tag attribute would just lead to a potentially confusing mix of articles’ visibility through these two channels.
If this general preference setting should become a considerable concern for real-world Textpattern applications in the future, adding a respective setting at the section level would be an alternative. But this would have to be part of a more general rethinking for the concept of “sections”, as many of the currently site-wide preferences would as well fit into a per-section context.
— Robert · Nov 16, 09:55 AM · #
That makes sense Robert. Thanks for clearing that up for me.
— Jeff Adams · Nov 19, 08:14 AM · #