That’s a really nice idea… but horribly complicated, given the number of different possibilities with expiration types, categories, post stati and so on.
It would be easy to implement if the expiration dates were “static” – i.e. stored directly in the database as metadata or something – but the plugin deliberately works out expiration on the fly, so that changes don’t cause a big re-query and re-storage of data (and so there’s none of the micro-management involved in such systems). My intention was to allow admins to change their criteria at will, and have everything run behind the scenes.
I know there are other expiration plugins that have this facility and store individual dates for each post’s expiration as metadata, so there are alternatives if you really need that data displayed… the downside is that most of them (if not all) need micro-management for the expiry dates. That’s the reason I wrote TIEexpire to do things on the fly – it was too much work to do things per post!
As I say, though, a very nice idea. I’m currently working on a new version of TIEtools (which includes TIEexpire) which I hope will be more of a “construction kit” approach to expiration, so I’ll add this to my list of thing to consider and see if I can find a neat way to do it without too much querying and stuff…!!
Thanks for your feedback!