REST API browser caching

Hi @deltafactory,

Thanks for getting in touch! We don’t directly control the max-age or re-validation headers for these requests, which means that is not something we are setting intentionally. Instead that would be managed by the browser caching solution you employ, across the entire site’s REST API.

Altering the payload can be done, but it would require a small extension of our frontend JavaScript REST API module, as it would need to be done before the request is dispatched. We don’t track the last modified dates of the map at the moment, but we could potential add some kind of counter for you.

We could add a counter of some sort to the payload using our Custom JavaScript setting, but I’m not sure what we would base it on without a last edit time/date. On that note, this is likely something we should be tracking for cases like this, I’m adding it to our development to-do list so that this can be improved in a future update as well.

The issue with the counter solution in this case is that, when the map makes those requests it doesn’t know how many shapes/markers to expect as that is data which is returned with these requests, so it would need to be something else.

As an alternative, we could do something like sending the current browser hour (time from local machine) as part of the payload, but that would mean the browser cache would only apply for an hour at most.

You’re correct that the plugin is not setting cache headers. I haven’t pinpointed the source, but it might be part of the server config. The caching is actually desirable in this case as long as it’s implicitly invalidated when the data is modified.

The counter I envision would be a meta value stored with the map and incremented when any aspect of the map was modified. A timestamp from the last-modified date would be a simpler alternative as long as it’s updated when related records are changed. I’m assuming you handle cache invalidation for the WP REST integration so the increment counter/modified date could be set at that point in the code as well.

To implement this myself all I would really need is a way to get a custom parameter into the data sent to the REST API. Some sort of hook into WPGMZA.Map.prototype.getRESTParameters would be all it took. Is that something that already exists or could be implemented in the future?

Hey @deltafactory,

Yes, I see, and I completely agree that’s something we could and should support in the plugin. I’ve logged this on our internal roadmap and we’ll start tracking the last edit date, or something similar, in the future, so that it can be included in these requests.

I’m linking this thread so that we can build something more robust for environments where that is a factor.

We do support extending any of the classes on the frontend as long as you are not running our developer mode, if you would like to implement something in the meantime. Here’s an example:

jQuery(($) => {
    
    WPGMZA.Map.prototype.__getRESTParameters = WPGMZA.Map.prototype.getRESTParameters;
    WPGMZA.Map.prototype.getRESTParameters = function(options){
		let options = this.__getRESTParameters(options);

        options.customvalue = true;

        return options;
	}
});

This is untested, and isn’t exactly a hook, but it is our official method for extension/overrides. These kinds of extensions can be added directly to our settings within the Custom JavaScript block (to ensure the load order is correct), and should run as expected.

You may also find some of our PHP hooks helpful for updating a meta value: https://docs.wpgmaps.com/hooks

Thanks for the guidance! Your snippet works with the let removed (it’s already declared in the args.)

I’ve added a value to the snippet for now which can be incremented manually for now and be properly implemented soon. Thanks for your help.

Hey @deltafactory – Fantastic, I’m glad to hear that helped you get around the issue on your side.

We’ll work on more robust solutions for this in the coming versions! ??