Dynamic change to category assignment when article expires

Destry · 2011-08-07 06:52:13

I have a situation where the client keeps some of their past events online. These events go into a past-events category to be viewed in a separate listing. The decision about which events stay live or not is (obviously) a human one (for now), but it requires remembering when the article expires, because when that happens it disappears from view and is out-of-sight; out-of-mind, for the most part. They don’t spend much time in the admin-side.

The workflow currently is:

Event article is posted to event section and given an expired date for removal.
Article expires (Editor must remember to evaluate event and make decision about it online)
If kept online, editor must manually assign article to past-events category and remove expires date to reveal it again.

What we would like to do is this workflow:

Event article is posted with expires date (as before).
Article expires and is automatically assigned to the past-events category. (Now hidden and at new location without human intervention.)
The expires date also triggers an automatic email to Editor to inform them a decision needs made on the moved, hidden article. (I.e., whether to remove the expires date and make article visible again.

Another thing I’ve never thought about before until working on this problem is why an expired article still shows in the Write panel as “Live”. It would seem to me that should automatically change to a status of Hidden or Pending when it’s not actually visible on the front-side anymore. As it is it’s kind of confusing to the client.

You might see how part of this relates to another discussion I’m having about article status options, particularly the notifications feature when the status of an article changes. In this case, if an article expires and changes from live-to-hidden, or even live-to-pending would be ideal here, then an email notification is sent. The same functionality in both topics.

It doesn’t look like jmc_event_manager will be any help here, but the notifications part I’m describing above and in the other thread would be handy independently of events scenarios too.

Any thoughts about how to do auto category changes or auto notifications when articles expire?

jakob · 2011-08-07 07:22:39

I agree that a generic email notification and associated action on particular events would be most useful. There is upm_pending_notify which serves just one such situation but as far as I know there is no general-purpose plugin for notifications. Mary’s upm_pending_notify plugin is triggered by a specific action (e.g. saving an article), but an article expiring is not an “event” in the sense of something you can hook your plugin action onto, which makes it more difficult to realise. A plugin could perhaps check on login or when the article list pane is called up, but that only updates when someone uses the back-end. Probably something like a cron-job is required that periodically compares article expiry dates against the current time.

Regarding your other point, with all due respect I think you’re generalizing from the viewpoint of your particular use-case. There are plenty of cases where people want to save past events, archived or not, for posterity, for information, to show visitors what future unannounced events might be like and so on. For example, I’ve done sites where current and future events are listed on the /events page and past events on the /events/archive page.

I totally understand the motivation behind your statement for the use-case you describe – and the above ‘envisaged plugin’ would potentially cater for that need – but I don’t see a need to make that default behaviour. One of the great things about Textpattern is its flexibility – why prescribe one particular way of working? The same point applies to the other thread on the use of status hidden. I already find that txp:article and txp:article_custom’s restriction to only “live” and “sticky” status is overly restricting.

Destry · 2011-08-07 07:42:35

Sorry, Jakob, you’ve lost me…

jakob wrote:

Regarding your other point, with all due respect I think you’re generalizing from the viewpoint of your particular use-case.

What other point, exactly?

There are plenty of cases where people want to save past events, archived or not, for posterity, for information, to show visitors what future unannounced events might be like and so on.

I know. This project is exactly one of those examples. They want to keep some past events that show potential members the kinds and quality of events they have. How is that different from what I’m asking about? Because it’s some events and not all?

I totally understand the motivation behind your statement for the use-case you describe – and the above ‘envisaged plugin’ would potentially cater for that need – but I don’t see a need to make that default behaviour.

Where did I say anywhere above about making something default behavior? I’d gladly accept a plugin to handle notifications and auto-category changes if one exists that I don’t know about. That’s really what this boils down to.

Ed. And I’m never above contributing to a plugin ransom either, since I can’t develop them on my own.

If you’re talking about the other thread, well, that’s a different discussion. :)

Last edited by Destry (2011-08-07 07:48:15)

jakob · 2011-08-07 08:53:59

I apologise: I guess I wasn’t quite “with it” so early on a Sunday morning.

I meant that “an expired article … should automatically change to a status of Hidden or Pending” shouldn’t necessarily be made default behaviour. Re-reading what you wrote, you didn’t say that explicitly. Sorry.

I too would contribute to a plugin that sends notifications / changes statii to different types of users on particular article events such as saving, status changing and article expiry.

Destry · 2011-08-07 14:09:35

No worries, Jakob. Your frequency is usually clear so I was wondering what I missed.

jakob wrote:

I meant that “an expired article … should automatically change to a status of Hidden or Pending” shouldn’t necessarily be made default behaviour.

Ah, I see. Yeah, maybe I was sending mixed messages inadvertently. In actuality, I was just pointing out what seemed odd to me, more than I was saying the core should be changed. By you know me a while now…I tend to speak up right? So I can understand the leap. :)

But, let’s really consider the logic of an expired article status being live vs. something like hidden or pending. I say logic because when content is taken offline, which is what the process expires-then-hide would suggest, then one doesn’t typically think of it as still being “live” (online). That does seem odd to me. More importantly, it probably is (though untested by me) odd to clients who adopt a habit of using the Articles panel (and status readings there) as a way of quickly determining if an article is online or not (I do that all the time). They see “live” and get confused when it’s actually not live on the front-end.

So, while I wasn’t suggesting a core change in this case, when I stop and think about little things like this, I can’t help but wonder why they are the way the are. Simply changing that little status behavior so it’s more logical doesn’t seem like the purpose of a plugin to me. More like good default behavior to start with.

Can anybody explain why it does stay live? There must be a tech reason, eh?

THE BLUE DRAGON · 2011-08-07 17:23:51

Does smd_countdown can help you with the email notifications?

Something like:

<txp:smd_countdown to="expires">
	<txp:php>
		$to = "someone@example.com";
		$subject = "Test mail";
		$message = "Hello! This is a simple email message.";
		$from = "someonelse@example.com";
		$headers = "From:" . $from;
		mail($to,$subject,$message,$headers);
	</txp:php>
</txp:smd_countdown>

jakob · 2011-08-07 17:52:37

@Destry
You’re right, the article list tab could signal the expired status more visibly. Future articles are shown gray, and when the comment period has expired that is noted too (switch to “show details”).

@Gil, nice find that. I’ve never used it before so I can’t say for sure. My guess is that it can help when a particular article is displayed or an article list, but won’t work “on its own” (i.e. the trigger is the form that displays the article details whether in an article_list or individual_article view).

I guess in combination with a cron job on your server that would work. You get the cron job to periodically (e.g. daily) load a pre-prepared page that runs through all your events and does what you want it to if the article expires. In the example you show you send a mail. If the status is supposed to change automatically, you could use smd_query to do that. I’ve not thought it through, but I guess that might work with built-in txp:if_expired tag. Maybe that is a realistic solution…

els · 2011-08-07 18:50:00

Destry wrote:

…when content is taken offline, which is what the process expires-then-hide would suggest, then one doesn’t typically think of it as still being “live” (online). That does seem odd to me.
(…)
Can anybody explain why it does stay live? There must be a tech reason, eh?

Well, there is a Publish expired articles preference. I suppose that whether staying live or becoming hidden is the more logical behaviour from your point of view depends on how you’ve set this preference.

Textpattern CMS

Textpattern CMS support forum

#1 2011-08-07 06:52:13

Dynamic change to category assignment when article expires

#2 2011-08-07 07:22:39

Re: Dynamic change to category assignment when article expires

#3 2011-08-07 07:42:35

Re: Dynamic change to category assignment when article expires

#4 2011-08-07 08:53:59

Re: Dynamic change to category assignment when article expires

#5 2011-08-07 14:09:35

Re: Dynamic change to category assignment when article expires

#6 2011-08-07 17:23:51

Re: Dynamic change to category assignment when article expires

#7 2011-08-07 17:52:37

Re: Dynamic change to category assignment when article expires

#8 2011-08-07 18:50:00

Re: Dynamic change to category assignment when article expires

Board footer