Pages being set to Draft after update

Hm, thank you. Looking into it.

I’ve modified the code, 1.6.1 should be up (whenever WordPress finishes crunching it).

Let me know if that solves the problem.

How can I update without having to re-enter all the expiry dates?

You go to plugins, and click update. It will make all the modifications automatically. However, it will not touch the database, so if you have any expiry dates entered, they will carry over to the new version. All the pages that are drafts though, you will either have to manually publish again, or run an SQL query if you have access to the database.

The SQL query would publish all the content that are in draft, so if you want to keep certain posts as drafts, first set them to private and then run it, and then turn the private content back to drafts.

With ANY SQL queries, save a backup of the database (‘Export database’).

Here’s the SQL Query (assuming your table prefix is ‘wp_’

UPDATE wp_posts SET post_status = ‘publish’ WHERE post_status = ‘draft’

Problem still exists.

Pages are being set to draft – I can’t see any connection between the ones that this plugin are setting to draft at all.

Hm… interesting.. one of my comments have been removed. Try disabling the plugin, and verify that this is the one that’s indeed doing the bad stuff.

Just to verify, you do have the 1.6.1 up and running, right?

Hm… interesting.. one of my comments have been removed.

Spam filter, it happens. This morning the queue was up to ~430 and it’s easy to accidentally delete non-spam comments when handling such bulk.

I’ve restored your comment, please carry on. ??

Thanks Jan. ??

I have 1.6.1 installed.

I just deactivated and reactivated.

I have 206 Pages – about 7 to 12 of them were being set to draft by this plugin – I confirmed that by changing the frequency to 15 minutes – every 15 minutes it set them to draft – I have now given them all long expire dates as to stop the annoyance – but I’m keeping a close ey on what it does tomorrow… over night….

One thing I have just noticed is that in the drop down box ‘frequently should the site check for expired content’ I have an option to choose ‘BackWPup’ which is my backup plugin. Is this a conflict…?

I can’t figure out why it is only that selection of pages that are being effected.

What happens there is that WordPress has a number of builtin schedules out of the box: hourly, twicedaily and daily if I remember correctly. You would use these in the functions relating to cron jobs ( script execution automation ). I have added a few more ( 15 mins, 30 mins, 4 hours ). Your backup plugin must have added a new one also: essentially both plugins are using the built-in WP Cron functionality to automate execution of stuff. So to answer your question, this is an expected behaviour when dealing with the same area of WordPress.

For me it’s checking expiration times vs current times, for the backup plugin it’s backing up.

The 7 to 12 pages, those are actually pages? In the setup section of the auto-expiry plugin you only have pages enabled? Do you have an auto-expiration time set?

On the actual pages, do you have a date and a time set?

I have it set to expire Posts , Pages, and 4 of 6 custom post types.

None are set to Auto Expire – I have never used this feature.

I have discovered this morning that it has now set some of my Custom Post Types to Draft – again seems to be random choice.

The only way I can stop this is to set the exipre date to the future. Which isn’t practical…

What is it that you’re trying to achieve?

The point of the plugin is that you publish a post/page/whatever, set a date and a time in the future, and when that time comes, the post/page/whatever will be expired: thus not available to the public.

So if you’re running a promotion: “Download this widget for free for 4 days!”, this is perfect, because you don’t need to remember to go back 4 days later and change it to Private.

Why would you want to set the expiry date to the past? (besides the fact that you can’t, as the first date you can set it to is always “today”)

I was saying that I have to set an expiry date on every post/page and custom post type to guarantee your plugin doesn’t randomly set them to draft.

I’ve been using this plugin successfully for 8 months – the latest update has screwed it up.

Don’t worry though I’ll downgrade to the last working version.

Hm, I really can’t think of any ways to see this happen randomly. This is what happens in the guts of the plugin when deciding what to expire:

1. Get the current timestamp in local time.
2. Sanitize the options (put them in a usable array)
3. Loop over the types part of options. These are the ones that you have selected on the options page. If it’s only page, then only pages will be looped over.
4. For each post type, get all articles that are either publish, future or pending status (because we don’t want draft ones to be put to draft)
5. For each of the content found, check if there’s an expiry date set on the content itself, AND if it’s set, is it larger than 600000 (a week after jan 1st, 1970; basically that it’s not empty), AND check whether the current time is larger than the expiry time (meaning it should expire now). If all of those are true, set it to the post status you specified on the settings page. Default is Draft
6. If any of the above fail, check if there is no expiration set on the article, AND check if there’s a default expiration time set, AND if there is, check whether that default time + the original publish date of the article is smaller than the current time. If it is smaller, expire it.
7. If neither conditions return true, leave the piece of content alone.

This is run according to a schedule that you’ve set up in the settings. Also, the settings are not backwards compatible, so an earlier version will not be able to read the settings the newer version saved.

If you have any more info to help me debug it, I’ll be here. Sorry to hear about your trouble though.

The only thing that I can think of is that I use a Plugin that creates clones of posts/pages – if it is cloned maybe its screwing up your logic and thinks that it should be expired…

The plugin is Duplicate Post – I can’t afford any more downtime to test this for you though – just a theory.