A similar issue exists here: http://drupal.org/node/954872, but I wanted to create one under the 7.x version as well.

I currently have a node importer created with the following settings:

Update existing nodes: 'Replace existing nodes'
Expire nodes: 'after 1 hour'

I have my mapping settings such that each time I replace the existing nodes, I set the 'Published date' field on my nodes to the current time stamp. I have gone in and verified, when I look at one of the nodes, that the 'Authored by' field under the 'Authoring information' section for that node, has indeed been replaced properly.

However, time passes and the nodes never expire/never get deleted.

So I have two questions:
1) Is that the field that the node expiration setting is based on? The 'Published date' in the mapping for Node processor form?
2) What is actually triggering the expiration of nodes? I don't have much experience with the Job Scheduler module, but can see it's required for this module? Is running cron helping with triggering any actions or is it a totally separate set of events

Any clarification would be much appreciated, and if I can provide any additional info, I'd be happy to.

Thanks,
Boriana

Comments

ditcheva’s picture

ditcheva commented

... and actually, I can see that the job scheduler is running when I look at the recent logs. However, it always comes back with "Finished processing scheduled jobs (0 sec s, 0 total, 0 failed)."

ditcheva’s picture

ditcheva commented
Status: Active » Closed (works as designed)

It looks like the system does seem to be working... it just may not be working as I initially expected, which is mostly just because there's a lack of documentation on how the node expiration works, and so I wasn't understanding it properly.

It looks like hook_cron() -- which schedules the expiration job -- only reschedules it based on a 60 minute time period. So if you have a bunch of nodes that are about to expire in, let's say 5 minutes, but your job scheduler just ran, it's not going to run again until 60 minutes from now, doesn't matter that your nodes are expiring now, and doesn't matter how many times you run cron.

So that means your nodes may, in the worst case scenario, get expired roughly an hour after they're due.

I got all my tests done by simply modifying (on localhost under controlled circumstances!) the db entry for the job_schedule. If you look at that table, there are columns for period (set to 3600= 60 minutes) and the next time it is due to run (last+period). If you just set the column 'next' to the current timestamp (or some time in the past), you can get the job scheduler running more frequently than once an hour to at least get your testing, etc done.

Anyway -- just wanted to explain why I wasn't getting the behavior I was expecting and how this all works. Hopefully this small contribution to the documentation will help others.

I'm going to change this ticket to resolved, since I believe everything is working as expected!

OldAccount’s picture

OldAccount commented

I've tried your suggestions and still can't get the expiration to work, documentation is sparse to non-existent. I have my nodes set to expire after 1 hour, verified my Published Date mapping is working/correct, yet nothing happens, Job Scheduler says "Finished processing scheduled jobs (0 sec s, 0 total, 0 failed)." even though I see a feeds_importer_expire entry in the job_schedule table of the database. Any tips you can think of, something I'm missing?

jvdurme’s picture

jvdurme commented

It's indeed not working. All nodes stay alive. Suggestions? Using alpha5 for D7.

funkeyrandy’s picture

funkeyrandy commented

is this working yet?

ajayg’s picture

ajayg commented

No it is not. Any suggestion which function (and in which file) the deletion triggers ? So we can start debugging. It seems (from my experience) the deletion works for some cases but not all and over a period of time the nodes gets accumulated and never getting deleted.

brad.bulger’s picture

brad.bulger commented
Version: 7.x-2.0-alpha4 » 7.x-2.0-alpha8
Status: Closed (works as designed) » Active

Same for me. Somehow, the expiration job gets removed from the job_schedule table, and once that happens, it never gets re-inserted, and no expirations will be done from then on. Certainly, long-past-due nodes are never deleted.

byronveale’s picture

byronveale commented

There was a duplicate issue created that I closed (#1791954), here are the notes from there:

I've configured my feed importer to expire nodes after 3 months, and I've double-checked that the published date is being properly set on the nodes, but nodes that are much older than 3 months (4 years!) never expire. When I create an entirely new source node with the feed importer and the initial import runs, it imports all of the available content, included everything older than 3 months. If I then run cron, the nodes are still not deleted. Completely stumped.

-jackalope

byronveale’s picture

byronveale commented

Perhaps this is related to the issue (#930652) of expiry batching being broken? If anyone is still having trouble with this, please go try the patch available at that issue.

You may need to become acquainted with patches before trying to apply the patch.

bluegeek9’s picture

bluegeek9 commented
Issue summary: View changes
Status: Active » Closed (outdated)

Drupal 7 reached end of life and the D7 version of Feeds is no longer being developed. To keep the issue queue focused on supported versions, we’re closing older D7 issues.

If you still have questions about using Feeds on Drupal 7, feel free to ask. While we won’t fix D7 bugs anymore, we’re happy to offer guidance to help you move forward. You can do so by opening (or reopening) a D7 issue, or by reaching out in the #feeds channel on Drupal Slack.

If this issue is still relevant for Drupal 10+, please open a follow-up issue or merge request with proposed changes. Contributions are always welcome!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.