So. As an example, I have two separate sites. I want to feed data from site A to site B.

The way I have been doing it is to generate a JSON file on site A, and then fetch it on site B, and then display content via that data.

Site B checks if the JSON file from site A is updated every hour.

That's the basic setup I have.

So I feel this approach might be something practiced sometime in the stone-age.

What's the more current way of doing this? Maybe an approach that doesn't require a cron checking for new data ever hour etc.

Maybe the rest APi is the approach.

Don't laugh btw haha I have not needed to touch this for a while but I feel it's time to go with the latest technology.

Can you update_option() via rest API? Maybe that's the most appropriate way. Site A updates a row in options on site B...

you can use a REST API endpoint with authentication to avoid having to trigger generating the file on site A

endpoints respond in JSON already by default

Can you update an option via rest API? (Not that it's the only way to do this, but still curious)

Also, if there are any good resources I can consume on creating content with rest API, throw them at me. I am a baby in this area.

you can create custom endpoints

and then call update_option

but if you already have code on site B just change it to point to the endpoint on A

and have the endpoint serve what your JSON file was serving

No I am rebuilding both sites so looking at improving the workflow. Everything will be coded from scratch essentially.

Thanks. I will look into this further and learn more about how the heck it works.

I presume the custom end point will need to be registered via code that exists on site B and it is not possible to register an end point cross sites.

@ChristineCooper I think what you want to consider is "push" or "pull" (see en.wikipedia.org/wiki/Pull_technology) - not sure of there exist better word in English for it. Right now you're pulling every hour, this means if data changed there'll be a lag of max 1h and if no change is done, the request is still made.

However, in a "push" setup, your site A would send a request to B whenever something changed. This is also usually how webhooks work. You can create a custom REST endpoint in B that is guarded (as Tom already suggested), and use that to update.

This might also allow that you only send changed data and not everything, but that depends on what kind of data we're actually talking about.

@TomJNowell / anyone: Recently I started reading up on core methods for caching. But now I'm unsure if I fully understand the difference between transient and object cache in WP. My understanding right now: object cache by default will only store for a single request, while transients store over multiple requests. I'd need an additional cache like Redis, for object cache to persist between requests. Is that correct? And if so, are there any more fundamental differences between the two?

@ChristineCooper indeed, you can only register things for the site you're currently on, it's like post types

@kero not quite true

When WP grabs a post or a term etc, it stores in in WP Cache

that way if you request a post 5 times it only retrieves it once, and it also retrieves associated meta etc in bulk to avoid lots of little requests

like a cooking show when they say here's something I prepared earlier

at the end of the request though, these are just variables so they die with the request

Yeah, So WP Cache is a big map. But that gets flushed once the request is done, as the PHP process is killed, no?

that's right, .. sometimes

transients are generic key/values that are stored in the options table

it's essentially an option that has an expiry date

BUT

if you install an object cache

those things get stored in that, rather than as variables

now they can persist across requests

if you play your cards right and design your site well, it may make zero database requests on most pages

because the posts are already in memory and it just needs to ask Redis or memcached for it

that's why object caches provide such a massive speed up

and transients get stored there too

So if I have an object cache, the difference between WP Cache and Transient gets negible? As I can give TTL for both and need to expect both to be deleted at any time as well

not quite

object caches handle expiration for you and are generally better at it

they also have other constraints

so for example, you can be sure that a 5 day transient will last exactly 5 days

you also have buckets

how they work varies on the implementation, but that post it stored but wasn't loaded for 10 days gets garbage collected to make way for more used data

again depending on how the object cache works internally

and things you store in WP_Cache are ephemeral, they can be discarded on a whim

it's a persistant cache, not a persistent store

if you decide to ignore transients and just use wp_cache_set directly, then all those transients die when you run wp cache flush

and any code becomes non-portable and fails on systems with no object cache

@TomJNowell I thought the same was true for transient

or if the object cache is unavailable

transients persist

emphasis on persist

wp cache does not, it's temporary, ephemeral

Okay, thank you so much!

and object cache lets things stick around longer to speed things up greatly

but at least you can store things in transients

you can't rely on that for wp_cache_set

I feel that, doing a Woo project now and for a couple of things we need a bit more complex calculations in the frontend - but they can be cached for at least a day. So will go for transients for them (and make sure to setup Redis / memcached so DB doesn't get shredded)

you should put an object cache on every site you can

purely for the improved WP Admin performance

Yes, started with that a year ago or so

just keep in mind to have a shared object cache if you have multiple machines

Thanks to docker-compose can make it only available for the PHP container - after a misconfigured Elastic last year getting hacked I was a bit afraid to add another service though =D