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 web feeds 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.


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.


  1. And while we all think that there is nothing happening here, Robert comes out with this brilliant news!

  2. This is excellent! I can’t wait to get the new version ;)

  3. Great news, great feature. Thanks!

  4. That’s just great!

  5. Great to see news from Textpattern in my Twitter feed : )

  6. 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.

  7. 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.

  8. 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.)

  9. 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! :)

  10. Wonderful! Thanks to all involved.

  11. 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.

  12. Great new feature and tags! These changes per se will make it worth updating to 4.0.7. Thanks, Robert!

  13. 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.

  14. @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.

  15. 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.

  16. That makes sense Robert. Thanks for clearing that up for me.

Commenting has expired for this article.