jdavidstark

Hmmm … that’s a good point. I suppose I’d say the post time at step 4 should be the default time of 10:00. If I wanted to retain the non-default time at 11:00, I should just drag the post to a different day on the calendar without a stop to the drafts drawer in the middle. (I could even make this a day very far in the future if I just wanted to not reset the time that much but needed a place to put the post where it wouldn’t publish.)

That said, I follow the rule of always posting at the same time of day. So for me, if I get some other time thrown in the mix, that’s almost certainly a mistake. At any rate, it’s so rare as to be fine just to modify (again if need be) once the post is on the calendar or via the post details.

So I’d be okay with adding a “custom times die when a post comes out of the drafts drawer” code snippet.

Thanks so much for your thoughts about this issue as well.

Got it. Thanks for looking into it.

I did happen to think that it looks like a scheduled post will already appear on the calendar by definition. A draft post might appear there or in “unscheduled drafts.” But when a draft post appears on the calendar, it no longer appears in “unscheduled drafts.”

I don’t code more than hacking out a minor change here or there. But this made me start wondering whether a workflow like what I’ve described above couldn’t be supported pretty easily by a user adding a custom code snippet like what I’ve done with update_option above.

The snippet would do something like

1. When post status changes from "unscheduled draft" to "scheduled draft" (i.e., on the calendar) then
2. Overwrite the saved post time with the calendar default post time

I may be very wrong, but from using the plugin, it looks like there’s already a way of detecting 1. And there’s already a way of writing the a new default time to be the time for a post on the calendar. So there would just need to be something to link the two together to achieve 2.

That said, I don’t know what that code snippet would look like. But if it’s an optional snippet users can install that just blanket stamps the default time on anything moving from “unscheduled” to “scheduled,” that would support this workflow without a code change to the plugin itself and without disrupting a workflow that relies on the draft time being retained.

I don’t know if these thoughts might be helpful at all. But I thought I’d post them in case they may.

Thanks again for your work on this very helpful tool.

Yes, getting the default time to override whatever draft time is the behavior I would have expected.

I can see the logic in the current setup certainly. But if I mean to set a time for the post via its own post details (not the editorial calendar), then I probably also am going to pick a date for it at that time. By contrast, if I haven’t yet assigned a date, I probably don’t care too much about the time that happens to be assigned via the post details (which could then be overridden with the editorial calendar’s default time).

To me, that seems a preferable way to have the feature work. But what you’re describing as the current rationale for why it works as it does does certainly make sense as well.

Thanks so much for all your efforts on developing this very useful tool!

Same here. Thanks so much for being on it already! ??

Yes, that does look like it’s fixed the issue on at least one page. I’ll keep an eye out for anything else that crops up. But otherwise, looks like we’re good to go.

Thanks so much for your help with that!

Ok. Great. Thanks so much for your help, again, and for that additional recommendation!

Ah, I see. Ok. Thank you. That’s fabulous and does seem to be working perfectly.

One more question, if I may: Doing this sort of thing is quite new for me. Will this change get wiped out and need to be reapplied if I update the installed theme? Or, will this persist through theme upgrades?

Thanks so much. I’ve added the following to the bottom of functions.php:

function override_time_diff() {
      return '-10'; //10 seconds
}
add_filter( 'wplmi_date_time_diff_post', 'override_time_diff' ); //for posts
add_filter( 'wplmi_date_time_diff_page', 'override_time_diff' ); //for pages

But, the “last updated” information still doesn’t show on this post and several others as it does on this one.

Might you have any other suggestions?

Thank you. It looks like if I roll back to v.6.1.6, all is well again (on WP v.4.8.1).

For me, v.6.2.1 gives the similar following error:

Fatal error: Can't use function return value in write context in /home/jdavidst/public_html/wp-content/plugins/zotpress/zotpress.php on line 355

I’ve removed and reinstalled the plugin, and I get the same result. Any suggestions for remedies would be most welcome.

Thank you so much.

Worked like a charm. Thanks so much!

Thanks. The font icon actually looks like an excellent substitute (https://fontawesome.io/icon/font/).

Same here. Cleared the cache, and we were back off to the races. Thanks, again, so much!

Come to think of it, I think it did work properly on 4.6.0. If I recall correctly, the current Zotpress version (6.1.5) rolled out after WordPress 4.6.0 but before 4.6.1. This version of Zotpress fixed the author-based sort issue I was having (does that sound right?), and I remember verifying that the very-long-bibliography pages on my site were displaying all of each collection, sorting correctly, etc. after that Zotpress update, which should then still have been on WordPress 4.6.0, I believe.

The same is true for me. I can get up to 100 items on a page with the “zotpress” shortcode, but not more than that. I can’t say for sure since I’ve been working through other issues, but it does seem that the timing for this issue would have coincided with either the latest WordPress or latest Zotpress update.

Interestingly, pages that I have based on the “zotpressLib” shortcode still pull all the relevant entries (and paginates accordingly). But, unless I’m missing it:

1) “zotpressLib” won’t allow narrowing to only one collection within a library.
2) “zotpress” won’t automatically start paginating after the “limit” of items per page is reached (e.g., item 101 starting page 2 if the limit is set to 100).

The tool really is fabulous. Thanks so much for all your efforts on a fix!