WordPress.org

1. simonbugler
   Member
   Posted 6 months ago #
   

   Recently created pages - that have never had expiry dates set - are being set to Draft after updating to the latest version.

   I thought I would put the short code [expirydate] on a page that was being affected to find out what was going on and when I hit Update I got the following errors...

   Warning: date() expects parameter 2 to be long, string given in /home/r36784/public_html/wp-content/plugins/electric-studio-auto-expire-post/electric-studio-auto-post-expire.php on line 415

   Warning: date() expects parameter 2 to be long, string given in /home/r36784/public_html/wp-content/plugins/electric-studio-auto-expire-post/electric-studio-auto-post-expire.php on line 415

   Warning: Cannot modify header information - headers already sent by (output started at /home/r36784/public_html/wp-content/plugins/electric-studio-auto-expire-post/electric-studio-auto-post-expire.php:415) in /home/r36784/public_html/wp-includes/pluggable.php on line 881

   Any help appreciated...

   http://wordpress.org/extend/plugins/electric-studio-auto-expire-post/

2. Gabor Javorszky
   Member
   Plugin Contributor
   Posted 6 months ago #
   

   Hm, thank you. Looking into it.

3. Gabor Javorszky
   Member
   Plugin Contributor
   Posted 6 months ago #
   

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

   Let me know if that solves the problem.

4. simonbugler
   Member
   Posted 6 months ago #
   

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

5. Gabor Javorszky
   Member
   Plugin Contributor
   Posted 6 months ago #
   

   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'

6. simonbugler
   Member
   Posted 6 months ago #
   

   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.

7. Gabor Javorszky
   Member
   Plugin Contributor
   Posted 6 months ago #
   

   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?

8. Jan Dembowski
   Volunteer Mod. & Brute Squad
   Posted 6 months ago #
   

   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. ;)

9. Gabor Javorszky
   Member
   Plugin Contributor
   Posted 6 months ago #
   

   Thanks Jan. :)

10. simonbugler
    Member
    Posted 6 months ago #
    

    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.

11. Gabor Javorszky
    Member
    Plugin Contributor
    Posted 6 months ago #
    

    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?

12. simonbugler
    Member
    Posted 6 months ago #
    

    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...

13. Gabor Javorszky
    Member
    Plugin Contributor
    Posted 6 months ago #
    

    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")

14. simonbugler
    Member
    Posted 6 months ago #
    

    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.

15. Gabor Javorszky
    Member
    Plugin Contributor
    Posted 6 months ago #
    

    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.

16. simonbugler
    Member
    Posted 6 months ago #
    

    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.

17. Gabor Javorszky
    Member
    Plugin Contributor
    Posted 6 months ago #
    

    Oh, cool! That helps. I'll look into it, and get back to you. For the time being, downgrade to 1.4 or 1.5.5.

18. Marklcm
    Member
    Posted 6 months ago #
    

    I'm having a similar problem. I use the plugin to expire slides to draft on one of 4 slideshows which are on different pages. The slides on the 3 slideshows with no expiry date set are being changed to draft (twice now).

    Downgraded to 1.5.5.

19. Marklcm
    Member
    Posted 6 months ago #
    

    I don't have Duplicate Post mentioned above, and nothing else different other than upgrade to 1.6.2

20. Marklcm
    Member
    Posted 6 months ago #
    

    So after downgrade, I checked if slideshows were working, all fine. I checked the settings for this plugin and unchecked posts and pages as I don't need this function, only slides. Was on website a little while later and several random pages had changed to draft. Reset to published and will keep an eye on things, but it definitely has a problem

21. Gabor Javorszky
    Member
    Plugin Contributor
    Posted 6 months ago #
    

    Hm, right, I can see how that's a problem. For now, I'll just make a copy of 1.5.5 as 1.6.3, and have everyone backgrade to 1.5.5.

    Thanks for the report.

22. sberringer
    Member
    Posted 6 months ago #
    

    Hi there, I'm having the same issues as mentioned above. I had done the upgrade a couple of weeks ago and then all of my pages and several slides were suddenly set to draft, and in the content of the pages, anything with an iframe was deleted.

    I upgraded to 1.6.3 on a smaller site towards the end of last week to test; content did not expire as marked after that upgrade. Today, all the pages and slides were again set to draft and the iframes were deleted.

    I've deactivated the plugin on all my sites for now. This is a great plugin that I rely on quite a bit and I'm hoping for a fix so that I can use it again!

    Thanks much for your help.

23. peaksmedia
    Member
    Posted 5 months ago #
    

    Having the same issue. Have deactivated the plugin for now. Shame cause I use it on so many sites. Great plugin.

24. peaksmedia
    Member
    Posted 5 months ago #
    

    Having the same issue. Have deactivated the plugin for now. Shame cause I use it on so many sites. Great plugin.

25. Gabor Javorszky
    Member
    Plugin Contributor
    Posted 5 months ago #
    

    Looking into it. Sorry about the mess. :/

26. Gabor Javorszky
    Member
    Plugin Contributor
    Posted 5 months ago #
    

    Guys, I've double and triple tested. It works as expected for me. Whatever needs to be set to whatever I tell it to, gets set, and whatever should not be set, does not get set.

    I literally have no idea, but possible causes:
    - The time on your server is not up to date. This might be a stupid thing, but please check whether the time is correct. When you're publishing a post or a page, it will tell you that Publishedon: Nov 22, 2012 @ 12:06 pm or something similar. It should be the exact same time as your computer's clock is showing at the time you're publishing the post.
    - You're using an outdated version of WordPress. Can you guys just tell me what version of WordPress are you using?

    Also, just to reiterate: the point of the plugin is to move posts / pages / custom post types FROM published TO draft/private/whatever. It will NOT schedule publishing of posts.

    Also#2, if you do NOT have an expiry date set on a specific post, BUT you DO have an expiry interval set on the settings page ( Settings -> Post Expiry ), then your posts will still expire.

    Logic when deciding to expire a post or not:
    1) Is the post type enabled for expiry? (has a tick next to it in the Settings page)
    2) Does the specific post have an expiry set on it?
    2.1) Has that time passed yet? (if yes) -> Expire
    3) If the post does not have an expiry set on it, does the post type have a default validity set? ( Settings -> Post Expiry -> Default exp. time )
    3.1) Is the current time later than the original publish datetime + validity of the post? (if yes) -> Expire
    4) Carry on, nothing to see here...

    I really can't see any problem with the code, sorry guys.

    I've made an edit on line 658 which brings it to version 1.6.5. For those of you who want to reverse-engineer how it works.

27. Gabor Javorszky
    Member
    Plugin Contributor
    Posted 5 months ago #
    

    IMPORTANT!

    Managed to reproduce this. Currently looking into it. Stay tuned.

28. simonbugler
    Member
    Posted 5 months ago #
    

    Can't wait :)

29. Gabor Javorszky
    Member
    Plugin Contributor
    Posted 5 months ago #
    

    Okay, 1.6.6 should be up in a few minutes. For those of you who's interested, here's what was causing the problem:

    If the post has no expiry set on itself, it goes to check whether there's a default expiry time set, and if so, is the sum of that + original publish date is in the past when compared to the current time.

    However, due to PHP's fantastic way of handling different types, what happened is that if there was NO time set on the options, in the database the entry was still there, but it was empty. Now according to PHP, empty = 0, and therefore publish date + 0 = publish date, which by default is in the past => expire the post.

    Revised code now checks whether that value is empty, so this should not happen in the future.

    Again, hopefully, and ultimately you guys are my testers. :) Sorry about the oversight on this.

30. peaksmedia
    Member
    Posted 5 months ago #
    

    Thanks for looking into/fixing the issue. Greatly appreciated.

Reply

You must log in to post.