Set up Ollama

Set up Ollama

Ollama runs a model on your own hardware. No API key, no per-question cost, and nothing about your visitors' questions leaves your network. The trade-off is that you supply the machine, and a small local model tells weaker jokes than a large hosted one.

Before you start

Install Ollama on the server that runs WordPress, or on a machine that server can reach, and pull a chat model:

ollama pull gemma3

Confirm it is answering:

curl http://localhost:11434/api/chat \
  -d '{"model":"gemma3","messages":[{"role":"user","content":"hi"}],"stream":false}'

If that returns JSON, WordPress will be able to use it. If it does not, fix that before touching the plugin settings — nothing on the settings screen will tell you the endpoint is unreachable.

Configure the plugin

Settings › AI Fun Questions, choose the Ollama card, then:

Field	Default	Set it to
Ollama URL	http://localhost:11434/api/chat	Leave as-is if Ollama runs on the same server
Ollama Model	gemma3	Whatever you pulled

Save, then load a page with [ai_fun_question] on it. There is no test button.

Why localhost is allowed here, and only here

WordPress ships a helper, wp_http_validate_url(), that rejects loopback and private addresses to prevent a site from being tricked into calling internal services. The OpenAI-compatible provider uses it.

Ollama cannot, because a self-hosted Ollama is a loopback or private address. That helper would reject the default configuration.

So Ollama uses a host allowlist instead. Out of the box, exactly three hosts are accepted:

• localhost
• 127.0.0.1
• ::1

Any other host is refused, and the widget shows a configuration error.

Pointing at Ollama on another machine

If Ollama runs on a different box — a GPU server on your LAN, say — you have to opt in explicitly. Two filters do it, and the difference matters.

Add specific hosts to the allowlist. This is the safer one: you name exactly what is permitted.

add_filter( 'ai_fq_allowed_ollama_hosts', function ( $hosts ) {
    $hosts[] = '10.0.0.42';
    return $hosts;
} );

Or allow any host. This is a blanket permission and it is false by default for a reason:

add_filter( 'ai_fq_allow_remote_ollama', function ( $allowed, $host ) {
    return true;
}, 10, 2 );

Returning true unconditionally turns your site into something that will issue server-side HTTP requests to whatever URL an administrator puts in that field. On a site where you are the only administrator that is a non-issue. On a site with several, or where the options table might be modified by other means, prefer the allowlist.

The filter receives the host as its second argument, so you can be selective:

add_filter( 'ai_fq_allow_remote_ollama', function ( $allowed, $host ) {
    return str_ends_with( $host, '.internal.example.com' );
}, 10, 2 );

Notes

• Requests time out after 30 seconds and follow at most 2 redirects.
• The call is synchronous, inside the request that serves the widget, so a slow model makes the widget slow. Small models are noticeably snappier.
• Ollama's response shape differs from the OpenAI one, which the plugin handles — you do not need to configure anything for that.

If it does not work

Symptom	Likely cause
"The Ollama configuration is invalid."	URL is empty, malformed, or a host that is not on the allowlist
"The AI service is temporarily unavailable."	Ollama is not running, is unreachable from PHP, or timed out
"The AI provider returned an invalid response."	The model replied with something that was not the expected JSON — try a different model

A common trap: Ollama running fine in your terminal but unreachable from PHP, because PHP-FPM runs as a different user or in a container with its own network. Test from the web server's perspective, not your shell.