Paul Kaiser

Well, what I meant by time stamp is Unix time, which is just an integer. This is how we’re storing your expiration time, in UTC. Then to display it for you we take into consideration your WordPress time zone and date / time formats to make it local and pretty.
https://en.m.wikipedia.org/wiki/Unix_time

In older versions of content scheduler, your expiration time was stored as a string, in format YYYY-MM-DD HH:MM:SS. What’s more, it was stored with your WordPress time zone already accounted for. This ended up creating a number of problems, as the expiration date became a moving target of sorts in some situations.

Anyway, your question is much appreciated and will see a fix in the next day or so.

That makes sense, and I know how to fix it. It will probably be Monday the 5th before a fix is posted.

When you update the post, the CS date/time field parses the unix timestamp into a human-readable format according to your chosen date format–in your case, custom.

When you save your update, CS takes the date/time field and tries to parse it into a unix timestamp again for storage. The PHP DateTime class is not able to recognize / parse your custom format, so it chokes and stores 1st Jan, 2000.

I will:
1. Add error checking to notify the user if DateTime is unable to parse a format, instead of just silently failing.
2. Add hidden field to the CS form to hang on to the CS date time in a known, parseable format at all times.
3. Incidentally, you’ve made me realize CS saves the date time information every time you update the post–even if you didn’t change the CS date time. I’ll be fixing that, as well (just a performance issue for larger sites, but still…)

Thanks for reporting this–I’ll work on it for Monday.

Take care,
Paul

Argh, OOPS! These last few fixes I just threw testing to the wind; bad move.

The problem you saw in 2.0.4 is because I did not check to see if you had datepicker disabled before adding some JS in the head that attempted to use datepicker class to munge a datetime string. The JS error would occur, interfering with JS responsible for the published date, media uploader, and others.

I just pushed CS version 2.0.5, which fixes this.
Thanks for your patience…

Thanks for the bug report, and for including version numbers.
I’ve added more error checking to the DateUtilities class to head this off before erroring out.

That said, I’m not sure why setTimezone failed on you. Basically it couldn’t construct a DateTime object with the given unix timestamp.

I’m wondering if you updated Content Scheduler, but did not Deactivate / Reactivate it? In these latest updates, I made changes to how the expiration date and time are stored, and when you Activate the plugin it checks for / migrates any existing timestamps you might have stored.

Anyway, please check out version 2.0.4, just uploaded, and let me know if problems persist or if you have any other requests.

Happy Holidays.

Thanks for chiming in. I’ve re-added the “show / hide datepicker” option in version 2.0.4, just uploaded. Check it out and let me know of any other issues / requests.
Happy Holidays.

Hmm, good point.
We could have:
1. Option to disable date picker
Or
2. “Default” button in date picker
Or
3. Second click in date field makes date picker go away. (Essentially each click in the field toggles date picker visibility)

Which would you prefer?

Sorry, I got in too much of a hurry.
array_replace is another 5.3+ function.
I’ve now replaced it and tested again.
Please try Content Scheduler 2.0.3 when you can.

Please update to Content Scheduler 2.0.2, which I just updated to fix this problem. I was inadvertently developing using PHP 5.3, which includes the “add()” method in DateTime class.

Let me know if this doesn’t work out for you.

Thanks, but I need the version of PHP.
PHPMyAdmin is just your web-based MySQL tool.
If you can, on your webserver, create a new php file:
myphpinfo.php
In the file, put:

<?php
phpinfo();
?>

Then, visit that new file in your browser, like maybe:
https://yoursite.com/myphpinfo.php

That should tell you a lot, including the PHP version on your server.

Greetings,
Do you know what version of PHP is on your server?
The DateTime class is only available in PHP versions 5.2 and newer.
Please let me know so I can try helping out.

I’m going to mark this as resolved — let me know if Activation does not solve the version number issue. I will work to make plugin Activation functions happen on update in the future, so folks don’t need to deactivate / reactivate.

Hi tpinkus,
If you still need Content Scheduler’s features, please give it a try now. I’ve updated it (finally) and have addressed some Multisite-specific issues.

NOTE that I have also disabled Network Activation for the plugin for now.
Rather, you would need to activate the plugin on each individual site that needs to use Content Scheduler.

Please let me know if this is an issue, and I can consider working on network activation changes.

Thanks,
Paul

Howdy — I’m not able to duplicate that situation. I assume you mean at the very bottom of the page. I have that there so folks can let me know for sure what version is active when they have problems.

If you had Content Scheduler installed before, and this was an “update” from the dashboard, I recommend you Deactivate and then Activate the plugin again.
During Activation, your version number would normally get updated after some database migration and other changes happen.

Please update Content Scheduler to 2.0.0 — just released — and try again. Let me know if problems persist.
Thanks,
Paul

Please update Content Scheduler to 2.0.0 — just released — and try again. Let me know if problems persist.
Thanks,
Paul