Reference documentation for Jahuty's PHP SDK.
This library requires PHP 7.3+.
It should be installed via Composer. To do so, add the following line to the
require section of your
composer.json file (where
x is the latest major version), and run
Instantiate the client with your API key and use the
snippets->render() method to render your snippet:
Then, output the render’s content by casting it to a
string or using its
In an HTML view:
You can pass parameters into your snippet using the options hash and the
The parameters above would be equivalent to assigning the variable below in your snippet:
Caching controls how frequently this library requests content from Jahuty’s API.
- In development, where content is frequently changing and low traffic, you can use the default in-memory store to view content changes instantaneously.
- In production, where content is more stable and high traffic, you can configure persistent caching to reduce network requests and improve your application’s response time.
Caching in memory (default)
By default, Jahuty uses an in-memory cache to avoid requesting the same render more than once during the same request lifecycle. For example:
The in-memory cache only persists for the duration of the original request, however. At the end of the request’s lifecycle, the cache will be discarded. To store renders across requests, you need a persistent cache.
A persistent cache allows renders to be cached across multiple requests. This reduces the number of synchronous network requests to Jahuty’s API and improves your application’s average response time.
To configure Jahuty to use a persistent cache, pass a PSR-16
CacheInterface implementation to the client via the
cache configuration option:
The persistent cache implementation you choose and configure is up to you. There are many libraries available, and most frameworks provide their own. Any PSR-16 compatible implementation will work.
Expiring cached renders
There are three methods for configuring a render’s Time to Live (TTL), the amount of time between when a render is stored and when it’s considered stale. From lowest-to-highest precedence, they are:
- configuring your caching implementation,
- configuring this library’s default TTL, and
- configuring a render’s TTL.
Configuring your caching implementation
You can usually configure your caching implementation with a default TTL. If no other TTL is configured, this library will defer to the caching implementation’s default TTL.
Configuring this library’s default TTL
You can configure a default TTL for all of this library’s renders by passing an integer number of seconds or a
DateInterval instance via the client’s
ttl configuration option:
If this library’s default TTL is set, it will take precedence over the default TTL of the caching implementation.
Configuring a render’s TTL
You can configure one render’s TTL by passing an integer number of seconds or a
DateInterval instance via its
ttl configuration option:
You can disable caching, even the default in-memory caching, by passing a
ttl of zero (
0) or a negative integer (e.g.,
-1) via any of the methods described above. For example:
If Jahuty’s API returns any status code other than
Jahuty\Exception\Error exception will be thrown:
If you’d like to see the SDK in action, see jahuty/jahuty-php-example.
Contributions or bug reports are welcome via GitHub!
Find a typo? Something is wrong in this documentation? Fork and edit it!