Posted by gmclelland on November 5, 2010 at 1:54pm
Does any one know of a module that can expire specific pieces of content inside a node using a filter?
See this for inspiration:
http://churchit.com/expiring-content-use-this-wordpress-plugin
http://alexking.org/blog/2010/11/02/expiring-content-shortcode
I was thinking it would also be cool if the module could create a new revision of the node when the content expires.
Comments
There are modules for that
I'm assuming your talking about publishing/unpublishing
http://drupal.org/project/scheduler
http://drupal.org/project/nodeprune
http://drupal.org/project/rules - will allow you to do just about anything
http://drupal.org/project/workflow_extensions - good read and an example of rules in action
Thank you for the feedback,
Thank you for the feedback, but those solutions expire the entire node. I'm looking for a way to expire just specific content in the node body based on an input filter.
For example:
Say you have a page that represents an annual event. On that page you specify that the event takes place on say Nov. 13, 2010. I would like to remove just that sentence after Nov. 13, 2010 has passed.
So I was hoping there was a module that provides an input filter that I can wrap that sentence in something like [expires on="11-13-2010"]This event takes place on Nov.13, 2010[/expires].
When the sentence expires, I was wanting the module to create a node revision reflecting the change in the node body.
Hope that makes it a little clearer.
@gmclelland, I see where
@gmclelland, I see where you're going with this, and agree that what you're asking for is beyond node-level or even field-level control. The one part that is going to be fun is figuring out the most efficient way to control filtered content caching. Possibly creating a new revision via code will do the trick, but I'm no D6 cache guru (even less of one for D7).
I do believe that content with input filters applied is processed once, then cached until a new revision is created or the old node content is saved over. You can disable caching via your filter, but then any content using that filter is rebuilt on every page render, which defeats the purpose of having caches. Using a cron hook and an expiration lookup table like the Scheduler mentioned above uses, you should be able to create a new revision thus forcing a re-render and re-application of the filters (no reason to actually change the node's raw stored content as you might have reason to go back and review it).
Down side? The granularity of your expiration is limited to the cron run intervals for your site, unless you code a special "page" request in your filter module that handles the expirations.
I for one think this is a good suggestion as I have a client that has to remove and/or update content on a weekly basis sometimes, and at the moment we're solving the problem with entire nodes via the Scheduler (resource intensive) or direct content edits (time intensive).
...via the Scheduler
Care to elaborate (the "resource intensive" part)?
@Eric - no slam on the
@Eric - no slam on the Scheduler, as it works great for taking large numbers of nodes on/offline at a time - but it's not really tailored towards field-level content modifications unless I've missed something in the docs or settings...?
What I was getting at was the fact that to get that level of functionality from the Scheduler, you'd have to set up special rules, triggers, etc, and still have to write some custom module code to actually modify the field content. You've got to admit - that's a lot of overhead to change the content in one value on one node at a pre-determined time in the future. Kinda like using a hammer to drill a hole - it can be done, but it's a lot of work and adds more complexity.
Besides, with a filter as suggested, you could also have content inside the field turned on as well as off at predetermined times:
[expires on="11-13-2010"]Welcome to our registration page! Click here to sign up for the event! Registration closes on 11/12/2010.[/expires][enabled on="11-13-2010"]Sorry! Registration closed for this event on 11/12/2010. Click here to view our other events.[/enabled]Keeps all the relevant information in one node, and if you have a large number of such nodes it literally would cut the number of nodes in half (unless you go the revision route of course). Coupled with the Scheduler, the node could then be unpublished after a set period of time (i.e. actual event date has passed, say 11-14-2010 in the example above).
Agree. Configuring fields
Agree. Configuring fields would be a major headache.
How would you flag errors in the markup/date format?
Good question...
I'm not sure how errors are handled in filters as it doesn't appear that hook_filter offers any kind of error-handling to flag improper markup. I've never implemented one myself, and am a bit surprised that it doesn't have a mechanism to do that.
One could try to make the filter as robust as possible, say parsing the dates using the PHP strtotime() function which is about as forgiving as it gets...
Since the markup could be
Since the markup could be anywhere in the text you would need to put the error-flag inside the textbox, which might not be possible. Otherwise you would need something like SQL syntax error style:
In-place would be a good
In-place would be a good option - probably the preferred one as it would be readily apparent after saving. You could also use drupal_set_message() calls to report it at the top of the page, as well as watchdog messages, etc to log it.
I guess I expected hook_filter to have implemented something like a validate operation that could generate an error on preview/save like you do with CCK fields. It doesn't appear that the previews invoke the filter chain(s) selected for a node, so I imagine that would be non-trivial to add in...
OK, started coding it...
... and I have a question to run by folks. Should I have the enable and expire filters be separately available (although in one module) or one filter? I guess I'm trying to figure out if there's a use-case where only expire or enable would want to be active on an input format... Off the top of my head I can't think of one, but figure I'd toss the option out there.
This would be handy if users
This would be handy if users might be only allowed to do one, but not the other. We split the option for the node type in scheduler for that reason.
Thanks!
Thanks for the confirmation, Eric. I was already leaning towards more flexible, but didn't want to sacrifice ease-of-use or confuse users. If that kind of feature is something already in play on your module, then I think I'm going that route as well...
Crontent Filter now available for beta
I just committed and tagged a 6.x-1.0-beta1 release for this new project:
http://drupal.org/project/crontent
Might take a few for d.o to package it up, but it's in GIT now... Enjoy!
Great job @arpieb. I must
Great job @arpieb. I must have missed some notifications when drupal went down. I just noticed your module in the new modules rss feed. Look forward to testing it out.