Start with three addresses on your own site; they tell you which part to look at.
https://your-site/opensolr-chat/widget.jsmust open as JavaScript. A 404 means the request never reaches the chat: the folder, the.htaccessor the nginxlocation.https://your-site/opensolr-chat/configmust show a short JSON with your title. A server error means PHP reached the chat but the chat could not start: almost always the data folder.https://your-site/opensolr-chat/adminmust open the admin.
The chat writes its own errors to the PHP error log of your site, each line starting with Opensolr Chat Bot:. That line usually names the problem.
Check the three addresses above first. If all three work, the page itself is missing the script tag, loads it from another host (example.com on a page of www.example.com counts), or a Content-Security-Policy of your site blocks it: the browser’s console says which. See Add the chat to your pages.
On Apache: mod_rewrite is off, or .htaccess is not read in that folder (AllowOverride). Check that the file is named .htaccess, with the dot, next to index.php. On nginx: the location blocks on Installing are missing or another location takes the path first.
PHP cannot write the data folder. It must exist, be the folder named in data_dir, and be writable by the user PHP runs as, the folder itself as well as the files in it:
sudo chown -R www-data:www-data /opt/opensolr-chat
The most common cause is a password command run as root, which leaves a database owned by root. If PHP-FPM runs with systemd’s ProtectSystem, a folder under /etc or /usr is read-only to it whatever its permissions: move the data folder to /opt/opensolr-chat and change data_dir.
The password command did not find Composer’s autoloader. Run it from your project folder, the one that holds vendor/, as on Installing.
Set one with the command on The admin, with the same data folder as the front controller, then reload the page.
Most often the command and the front controller use different data folders, so the password went into another database: run the command again with the exact data_dir of index.php. Spaces around a pasted password are ignored, so they are not the cause.
Five wrong passwords from your address within 15 minutes. Wait, or set a new password with the command; the wait applies either way.
What each message means is on Account and index. The connection failed is about your server’s outbound HTTPS, not about the key.
It must be a PNG, JPEG, GIF or WebP image of at most 1 MB and 4,096 pixels on each side. If PHP itself refuses the upload, its upload_max_filesize and post_max_size must be at least 1 MB.
The email, the API key or the index is missing. Test the connection on the Account tab, choose the index and click Save settings.
The host name that reaches PHP is not the one in the visitor’s browser, almost always because a reverse proxy in front of the site replaces it. Make the proxy pass the visitor’s host on: proxy_set_header Host $host; in nginx, ProxyPreserveHost On in Apache.
Something between PHP and the browser buffers or compresses the answer. See Streaming through your server.
Your site is behind a proxy, a load balancer or a CDN and all visitors arrive with its address, so they share one limit. Set trusted_proxies in the front controller, as on Installing.
The visitor, or someone on the same IP address, has an answer still being written. One answer at a time is always the rule; it frees itself when that answer ends, or a few minutes later if the answer was cut off.
The answer failed on the way. Asking again usually works. If it keeps happening, the Opensolr Chat Bot: line in your PHP error log has the reason. Check also that the AI requests of your plan are not used up for the month: see API Quota.
The captcha was solved for another site, The captcha could not be checked and a captcha box that does not load are on Captcha.