[Plugin: Post Expirator] Cron runs every 60 seconds!

in post-expirator.php
‘interval’ => 60,
convert to
‘interval’ => 3600,

Ummm … you can’t be serious about that? What happens on the next update?

The plugin by design is set to run every minute. Now, are you looking to run this on a multisite network or just single hosts? Because I could look into adding an option to select, but that wouldn’t address your concern if users can select this themselves.

Thanks for the thoughtful response Axel.

The issue is that I believe running every minute, just in case you need to do something, is over using resources. If you literally had an event every minute, no problem, but 99.99999% of the time you will simply be running a query and exiting.

What would address the issue nicely would be this: by default, for the plugin to run hourly. Then, as well, there’s an option somewhere that says, “Use precise timing” (or better wording, that’s my poor wording) and ran every minute. I’d suspect this would be more than acceptable for most people, who really don’t care when a post is expire down to the minute — eg for me, so long as it’s within an hour or so, no problem.

For those few who did care about the timing down to the minute, they could select the option and deal with the extra overhead.

BTW, to check whether a cron entry exists you might be able to use wp_next_scheduled() – that could be run every hour to see whether expirationdate_delete is still scheduled, and if not, to replace. You then wouldn’t need the manual Reset button except in dire circumstances. ??

This plugin originally was only available to run every hour. There was actually a huge demand for it to expire on the minute, which is one of the reasons why it was changed. I would likely keep “minute” as the default, and look at having an option to use hourly.

This will required a good amount of changes/testing, so it will be a bit before it’s ready. If you are willing, once I get it in a “beta” worthy state, I can shoot a link over for testing.

I always have resources usage in my mind, and do what i can to minimize unnecessary db calls, etc.

I’ll probably re-work the cron entry check, and keep it as an admin side only checked. Because if something is screwed up with the cron scheduled, its likely any additional events to check the schedule would also be hosed.

Sure, happy to help if I can, and thanks for being willing to look at it and discuss it.

Obviously the other option is to schedule the events for exactly when the expirations are needed, with an hourly event to just check everything is OK.

That way you get control down to the minute, without using any resources at all.

I take your point about keeping the cron check button in admin. It wouldn’t be unreasonable to just check that the hourly cron event is scheduled on all admin pages, then the hourly event can do more extensive checking and you don’t need to get people to click on a reset button. Although, you may like the button! ??

Thanks again, BTW, looks like you are king of the download stats, you have some serious download numbers happening!

I have implemented some tweaks in the dev version – take a look and let me know if it works and does the trick for you.

https://downloads.www.ads-software.com/plugin/post-expirator.zip

Sorry to be so very slow to respond to this.

I had a look at the code, but without diffs or some idea what you’d done it was hard to follow.

What needs to be done is to schedule the cron jobs at the time the next post needs to change. That way you get as near exact granularity as you can while not wasting CPU cycles (and getting blogs running your plugin into trouble with hosts like myself! :)). More seriously, many hosts these days measure excess CPU users and kick blogs off if they are violators.

If you like, you could schedule an hourly check for cron being set correctly, it’s only when stuff polls every minute that you’ll run into trouble.

We have been using Post expirator on one of our sites for over two years. We only had one issue after one of the upgrades, but this site always used a bit more resources than others with similar visitor count.
I was keen to put the blame on the code we wrote (theme and custom made plugins) but I was wrong. I have checked with our hosting company and they said load is caused by something in wp-cron.php. Other than usual WP stuff Post Expirator was the only plugin using scheduler. We have rescheduled it to run hourly and loads fell into normal.

So I second what brianoz wrote about scheduling cron jobs at the time the next post needs to change. No one wants to waste resources.

Just to let everyone know, I am adjusting the plugin to schedule an event for each post – because that is a much better way to go about this. When the plugin first came about I believe there was some limitations with that route.

Either way, I hope to have something ready for “testing” in the next week or so (pending all goes well). Any volunteers to test it out?

Good news. Post a notification here when it is ready for test.

Just doing some cleanup and I’ll have to spend a couple days testing the upgrade path before releasing it to you guys to try out. Here is a sneak peak to date of whats changed:

* New: Improved debug calls and logging
* New: Added the ability to expire to a “private” post
* New: Added the ability to expire by adding or removing categories. The old way of doing things is now known as replacing categories
* New: Revamped the expiration process – the plugin no longer runs on an minute, hourly, or other schedule. Each expiration event schedules a unique event to run, conserving system resources and making things more efficient
* New: The type of expiration event can be selected for each post, directly from the post editing screen
* New: Ability to set defaults for each post type (including custom posts)
* Fix: Removed kses filter calls when then schedule task runs that was causing code entered as unfiltered_html to be removed
* Fix: Updated some calls of date to now use date_i18n
* Fix: Most (if not all) php error/warnings should be addressed
* Fix: Updated wpdb calls in the debug class to use wpdb_prepare correctly

For those of you who were interested in testing – please grab the version from the SVN trunk. https://downloads.www.ads-software.com/plugin/post-expirator.zip

I want to roll this out within the next few days. I have tested every upgrade scenario and post scenario that I can think of – so additional testers are welcome.

The only outstanding issue that I am still working on is:

– when checking default post categories, the categories of the epxiration box are also checked.

The changes included are:

* New: Improved debug calls and logging
* New: Added the ability to expire to a “private” post
* New: Added the ability to expire by adding or removing categories. The old way of doing things is now known as replacing categories
* New: Revamped the expiration process – the plugin no longer runs on an minute, hourly, or other schedule. Each expiration event schedules a unique event to run, conserving system resources
and making things more efficient
* New: The type of expiration event can be selected for each post, directly from the post editing screen
* New: Ability to set defaults for each post type (including custom posts)
* New: Renamed expiration-date meta value to _expiration-date
* New: Revamped timezone handling to be more correct with WordPress standards and fix conflicts with other plugins
* Fix: Removed kses filter calls when then schedule task runs that was causing code entered as unfiltered_html to be removed
* Fix: Updated some calls of date to now use date_i18n
* Fix: Most (if not all) php error/warnings should be addressed
* Fix: Updated wpdb calls in the debug class to use wpdb_prepare correctly

* New: Revamped the expiration process – the plugin no longer runs on an minute, hourly, or other schedule. Each expiration event schedules a unique event to run, conserving system resources
and making things more efficient

– How this approach will work for currently expired posts?

it has no impact on currently expired posts (other than renaming the meta value) – since they are already expired, and nothing had to be changed.

Any posts that are scheduled to expire in the future will have an event schedule for them at upgrade time.