2

I have a plugin that interfaces with an API and am storing retrieved schedule data in a transient.

Storing the transient for 24 hours:

set_transient($schedule_cache, $schedule_data, 60 * 60 * 24);

The problem (I think) is: Which 24 hours is it being stored for? I want TODAY to be displayed, but if the transient was set at 11PM last night when someone loaded the page, we're going to be displaying YESTERDAY until 11PM TONIGHT.

The inelegant approach I'm working with is to store a second transient with a unique TODAY identifier:

$this::$time_tracker = date('Fd', strtotime("today")); # 'March30' 
set_transient($schedule_timer, $this::$time_tracker, 60 * 60 * 48);

And then if the current time tracker doesn't match transient, delete all of the transients (there are others for pagination):

if($last_look != $this::$time_tracker)
    // Delete all the transients and save new ones

Minimal working example:

class transientIssues {

    public function __construct(){
        $this::$time_tracker = date('Fd', strtotime("today"));
    }

        $schedule_cache = 'sched_che';
        $schedule_timer = 'sched_tim';

        $last_look = get_transient($schedule_timer);

        if ( $last_look != $this::$time_tracker ){
            // delete_transient( $schedule_cache );
            // Replaced above with the following so we could deal with multiple date ranges being called.
            global $wpdb;
            $wpdb->query( "DELETE FROM `$wpdb->options` WHERE `option_name` LIKE ('%sched_ch%' OR '%sched_tim%')" );
        }

        if ( false === get_transient( $schedule_cache ) ) {

            $api = $this->instantiate_API();
            if ($api == 'NO_SOAP_SERVICE') {
                pr($api);
                }else{
                $api->gettData(); 
                }

            set_transient($schedule_timer, $this::$time_tracker, 60 * 60 * 24);
            set_transient($schedule_cache, $schedule_data, 60 * 60 * 24);

             // END caching*/
        }
}

Does this seem like a reasonable approach? I would welcome insights.

  • Just to address the TODAY issue, you could just set the $schedule_cache expiration to seconds left in the day: DAY_IN_SECONDS - current_time( 'timestamp' ) % DAY_IN_SECONDS rather than 24 hours... – bonger Mar 30 '16 at 17:30
  • Is this how that would work: Number of seconds since 1970 (in whatever timezone registered with the WP install) divided by number of seconds in a day gives the amount of days since 1970, with the modulus (remainder) being the number of seconds since the beginning of today. At 12:01AM this number would be 60. So we subtract 60 from the number of seconds in a day and the difference is sixty seconds less than a day: 86340. So at 11:59:59PM this number would be 1. – MikeiLL Mar 31 '16 at 6:25
  • Yes ..........! – bonger Mar 31 '16 at 8:48
2

There is no reliable way to achieve what you want with the Transients API - or even, if you have been considering it, with the WP Cron system. The problem is in a nutshell: Those API systems depend on user input. If you want to know more about it, do a research, as this has been discussed a couple of times.
To have a reliable solution, you can use the real - the WP one has pretty much nothing to do with it and in my mind it shouldn't even be called alike, but whatever - CRON system and the cronjobs you can set up with it. I'm not going into depth here, because you will find enough starting information about »How the real CRON can be used with WordPress« on the internet. As @MarkKaplun rightfully pointed out, WP CRON and real CRON can be used in conjunction to achieve your goal.

  • Thank you. I had surmised as much from previous research, but was hoping for a way to achieve what I want within WP. Will most likely accept this answer. – MikeiLL Mar 30 '16 at 16:37
  • No hurry, you can just wait a bit longer, maybe there is another answer/solution coming. I might just not be aware of a smart and elegant solution, that does meet your criteria - better at least. @MikeiLL – Nicolai Mar 30 '16 at 16:42
  • 2
    +1 but I think it is a little bit too white&black. yes, wordpress cron by itself is not reliable but you can trigger it reliably from the os cron. Once done you just need an event that will be triggered and will populate the cache – Mark Kaplun Mar 30 '16 at 16:51
  • @MarkKaplun You're right, of course. I wasn't even trying to paint it all black and white. Furthermore I kind of unintendedly assumed, that the research on the real CRON would have revealed that information. Anyway adding it to the answer now.. – Nicolai Mar 30 '16 at 16:59
  • @MarkKaplun Are you suggesting to create a function that will clear and repopulate transient, then trigger it with OS cron? Or to have the OS cron trigger WP_Cron? – MikeiLL Mar 30 '16 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.