Expired Articles: Finetuning

jsoo · 2009-07-09 10:58:13

saccade wrote:

I hope I did understand the behaviour of jsoo’s plugin right.

Yes ("solely" and "none" were wet’s additions, as you pointed out).

I like wet’s use of "any" to mean completely ignore Expires datestamp and publish_expired_articles pref. "solely" I find non-intuitive.

Is the attribute to be called selectexpired as proposed? I think there is an important difference between this and expires or expired. I would prefer expires (or perhaps selectexpires); expired implies an article with an expired datestamp. selectexpires/d also connotes the datestamp itself whereas we are now encompassing the state of the publish_expired_articles preference as well.

An alternative set:

"ignore": same as wet’s "any"
"past": same as wet’s
"future": my version; like wet’s but only with expires datestamp set to a future value
"any": same as wet’s solely (alternates: "has" or "isset")
"none": same as wet’s
"future, none" same as wet’s "future" (alternate: "not-past")
empty: same as wet’s

saccade · 2009-07-09 11:22:24

I think it would make most sense call the attribute “expiry”, for then all items of wet’s set would fit in a comprehensible way:

expiry=“any” (will ignore differences)
expiry=“past” (only past = expired articles)
expiry=“future” (only not yet expired articles, includes never expiring ones)
expiry=“solely” (only articles with an “expires” date)
expiry=“none” (only articles that don’t have an “expires” date)
expiry=”“ (use preference)

saccade · 2009-07-09 11:38:27

btw, just to be complete: only one case is left out now – but might be useful for someone:
(Edit No, not left out in the discussion, this is what leads jsoo to his different set.)

It’s the equivalent to “past”: only articles with an expiry-date, but not yet expired.
(this would be a combination of solely and future)

Maybe it could be solved by

expiry=“solely, future” (only articles with an expiry-date, but not yet expired)

To me it makes sense to solve it like this – and not let past/future be both of a kind of “solely”.
Past is “expired” (expires inevitably filled) and future is “not expired” – true even if “expires” isn’t filled at all.

Last edited by saccade (2009-07-09 11:51:48)

ruud · 2009-07-09 17:33:25

Am I missing something?
The attribute values “past”, “future” and “any” are already available in the “time” attribute for txp:article. I don’t see a good reason for duplicating them in another attribute. To achieve the desired result, can’t the user combine that attribute with an attribute like “expired” that has values like: “only”, “no” and “any” or probably better an attribute (can’t think of a good name) that has values like “any, current, expired”?

So if you’d want to show only future expired articles, you could do: <txp:article time="future" expired="only"/> or <txp:article time="future" good-attribute-name="expired" />

Bloke · 2009-07-09 17:56:04

ruud wrote:

Am I missing something?

I had the same head-scratch moment trying to find what I’d missed.

So if you’d want to show only future expired articles, you could…

Sounds god to me. Or as a curveball idea, allow an optional component to the time attribute:

time="future expired"
time="future current"
time="past expired" (?!)
time="future all"

But time="any all" or time="any any" gets a bit silly and will likely generate far more support questions than the flexibility it adds :-O Hmmmmm.

Last edited by Bloke (2009-07-09 17:56:36)

saccade · 2009-07-09 18:00:37

Hi Ruud, nice to see you here :)

Good reason?
I think there is one.

In my eyes “time” and “expired” are twins:

While “time” exactly regards “Posted”-values
“expiry” (or whatever) regards “Expires”-values.

And so I think it’s not a bad idea to reflect that connection in terms.

But as I first too had different values I can think of a different approach too.

Your proposal is nearly what I had in my second attempt: “ignore”, “include” and “only” expireds.

But how to take in tests on “expires” without being expired yet?

saccade · 2009-07-09 18:04:32

ruud and Bloke

I personally don’t think it is good to mix it with time.
I like the clearly separated concept of dealing with posted and expired in Textpattern.
It is most easily to understand.
And there will be no complicated concatenation of values.

Take in or sort out expired articles is a special thing.
Especially on article-tag-basis because normally I think you will solve it globally by the preference setting.
the article tag is clearly meant as a more sophisticated technique when you deal with different needs.

Edit: Thinking again of your examples, ruud, I think that is headscratching as well: Time=future and expired="only". expired is by definition “past” and won’t fit well to “future”. Also time="future" good-attribute-name="expired" – the same contradiction. Maybe the value should then be “expires”, that would be appropriate.
But I think we should keep concepts separate.

Last edited by saccade (2009-07-09 18:14:14)

ruud · 2009-07-09 20:29:48

I’d split it in two attributes then, one that indicates selects whether an article expires (has expiration date set) and another to indicate if you want future expired articles or past expired articles. (Combining them into a single attribute makes my head hurt when trying to pick the right attribute value)

expires = [1|0|] (empty value meaning "don't care", which is the default) 
expire_time = [past|future|any] (default: any)

any: expires=""
past: expires="1" expire_time="past" (implies time="past")
future: expires="1" expire_time="future" (can be combined with any value for the time attribute)
solely: expires="1" 
none: expires="0"

But since expire_time implies the article has an expiration date, setting expires=“1” explicitly shouldn’t really be needed there.

if publish_expired_articles is set to no, then how would you display an individual article page for an expired article? IIRC, an appropriate HTTP response code is sent and that’s it. No tags are parsed, so you never reach the attributes mentioned in this topic.

PS. Michael, my previous example was a bit insane, yes. I should’ve picked a different combination.

saccade · 2009-07-09 20:51:39

Ruud,
splitting seems too complicated to me, and now my head is hurting :)
Really – now it looks much too complicated for me.

My main intention was based on publish_expired_articles=yes and getting limits done correctly and have some way to collect expireds in one place without too much overhead.
That was my main challenge and I think it’s the main benefit.

But the other way round (publish…=no and including expireds) makes sense when you want to show a list of articles that have been there once (and even not linked – only for information). So I think mostly in lists.

I must admit, that I didn’t think about displaying an individual article when the preference is set to “no”.
That even doesn’t make sense to me. No is no at least in this way for me.
But you’re right. It has to be taken into account that someone could want to show a single article (or provide links to single expireds).
But is it true? Doesn’t it parse at all if I select it as done in my patch code?
Or do you refer to jsoo’s solution? Maybe that is different.
I didn’t have the time to test it now.

wet · 2009-07-10 05:13:43

ruud wrote:

if publish_expired_articles is set to no, then how would you display an individual article page for an expired article?

An individual article page would not be rendered. I consider an separate article_custom or related_articles area on a live article’s own page as the most common use case. E.g. A concert schedule shows a single entry for an upcoming gig, and lists all past events of that series in a sidebar.

Textpattern CMS

Textpattern CMS support forum

#13 2009-07-09 10:58:13

Re: Expired Articles: Finetuning

#14 2009-07-09 11:22:24

Re: Expired Articles: Finetuning

#15 2009-07-09 11:38:27

Re: Expired Articles: Finetuning

#16 2009-07-09 17:33:25

Re: Expired Articles: Finetuning

#17 2009-07-09 17:56:04

Re: Expired Articles: Finetuning

#18 2009-07-09 18:00:37

Re: Expired Articles: Finetuning

#19 2009-07-09 18:04:32

Re: Expired Articles: Finetuning

#20 2009-07-09 20:29:48

Re: Expired Articles: Finetuning

#21 2009-07-09 20:51:39

Re: Expired Articles: Finetuning

#22 2009-07-10 05:13:43

Re: Expired Articles: Finetuning

Board footer