Can't seem to get it to work

Can you try the latest version and let me know if that solves your problem?

Dear Aaron,
I have the same problem than ‘kallekillen’ and I’ve just downloaded the 2.1.1 version.
I would like to add an expire date to a page but I got the following:

2013-06-19 21:57:44 568 -> SCHEDULED at Wed, 19 Jun 2013 21:00:00 +0000 (1371675600) with options Array ( [expireType] => draft [id] => 568 )
2013-06-19 21:57:44 568 -> UNSCHEDULED

Any help would be highly appreciated

Can you verify that cron is working correctly on your host? Someone else had a similiar problem that a reinstall of WordPress fixed.

I am having the same issue. It appears that when the cron runs that It runs a single event and then stops without expiring the post. I have multiple posts that should have already expired, but haven’t. But, it seems to only trigger the oldest post and then quits with out actually expiring it.

2013-06-20 16:41:40 4897 -> SCHEDULED at Sat, 06 Jul 2013 13:30:00 +0000 (1373117400) with options Array ( [expireType] => delete [id] => 4897 )
2013-06-20 16:41:40 4897 -> UNSCHEDULED

I cannot reproduce this issue at all, which is making it extremely hard for me to debug.

What web host are you using?

iPower – https://www.ipower.com
We have every capability on our server(s) that is needed and more. I doubt it has anything to do with the server. If we need to make an php.ini change, we can do that.

I should point out that we are using the ‘Better WP Security’ plugin. It does make changes to permissions and the htaccess file, but it has not been a problem yet with any other plugins I’ve used.

I see future expirations in the log, but when they run they do not expire, and the record is pulled from the cron list.

@ecco Did you install WordPress direct from a download or was it installed using cpanel or some other automated method?

Are there any other plugins you have activated on the site?

SimpleScripts in iPower’s vDeck. but it installs great. I used to put them in manually because their previous system did a horrible job, but SimpleScripts works great and is no different than manual as far as I can tell.

I will do some testing on this in the next couple of days.

If you are willing, can you setup a manually installed WordPress on your host to see if it makes any difference?

Unfortunately This site is live and holds a lot of content for a local news station. I could set up another version, but it wouldn’t make a difference because moving everything between them would not be in the client’s budget.

I’m mainly just interested in confirming that the scripted installation is not the cause. If you were able to reproduce the issue with a vanilla WordPress installation with just the Post Expirator plugin that would be helpful to know. Transferring over content and settings would not be needed.

I installed it manually and installed only this plugin on the same server. It works. I am also going to install a stock version from the SimpleScripts app and install this plugin to see if there is a difference. I believe it is probably not the installer but a conflict with another plugin. But, I will do the second install to be sure.

If there is truly a problem with the plugin, any details/info you can provide would be appreciated. Thanks for your effort in further debugging this issue!

I was having the same issue. I disabled the WP Total Cache plugin and Post Expirator works again.

I did not see the UNSCHEDULED note in my debug logs however. I just got:

4390 -> SCHEDULED at Tue, 25 Jun 2013 18:59:00 +0000 (1372186740) with options Array ( [expireType] => category [id] => 4390 [category] => Array ( [0] => 3 ) [categoryTaxonomy] => category )

for a failed Expiration. No other info in the debug log.

However, I notice that after I disabled the Total Cache plugin and did a successful Expiration test I got:

2013-06-25 14:20:02	4534 -> CATEGORIES COMPLETE Array ( [3] => Past Events )
2013-06-25 14:20:02	4534 -> CATEGORIES REPLACED Array ( [3] => Past Events )
2013-06-25 14:20:02	4534 -> PROCESSED category Array ( [expireType] => category [id] => 4534 [category] => Array ( [0] => 3 ) [categoryTaxonomy] => category )
2013-06-25 14:19:09	4534 -> SCHEDULED at Tue, 25 Jun 2013 19:20:00 +0000 (1372188000) with options Array ( [expireType] => category [id] => 4534 [category] => Array ( [0] => 3 ) [categoryTaxonomy] => category )

So for some reason with the Total Cache plugin activated only the SCHEDULED log/process went through, but once Total Cache was deactivated the SCHEDULED, PROCESSED, CATEGORIES REPLACED, and CATEGORIES COMPLETE log/processes went through.

Not sure if this is the same issue but hope this helps.

@ceebeez The plugin relies on the wp-cron process. If you are caching aggressively or even disabling wp-cron, that would explain why it is not working.

This issue though appears to be different from the one that @ecco is seeing.