| 开发者 | akukitadvt |
|---|---|
| 更新时间 | 2026年7月3日 17:49 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
[akukita_chat] on any page or post.Yes. After activating the plugin, the free MyMemory provider is already selected. You only need to create a room and paste the shortcode. The default 5,000 words/day quota is enough for small to medium communities.
In Akukita Chat → Settings, enter any email address in the MyMemory field. That's it — your quota goes from 5,000 to 50,000 words/day at no cost.
No, by design. Only administrators can create and manage rooms from the dashboard. This keeps the chat moderated and prevents spam rooms. The Premium add-on adds private and invite-only rooms if you need that flexibility.
No. By default the chat is open to guests: a visitor enters a display name and their language and can start chatting right away — no account, no email. You can change this under Akukita Chat → Settings → Who can chat, where you can instead require visitors to be logged in, or require them to create a WordPress account. Spam protection (rate limiting, message length limits and a honeypot) is always on for guest chat.
Messages are stored in your own WordPress database. You decide how many days of history to keep in Settings, and older messages are auto-purged daily. Nothing is ever sent to third parties except the text being translated to your chosen provider.
The original (untranslated) message is shown. Users still see the conversation, just without translation during the outage. The chat itself keeps working at full speed.
Yes, but you must exclude the page containing [akukita_chat] from full-page cache. The chat output and its security tokens depend on the visitor, so serving a cached copy to guests can make sending messages fail. Add the chat page to your caching plugin's "never cache" list, or configure it to vary cache by login status.
Yes. Each site in the network has its own rooms, messages and settings.
PHP 7.4 or higher. PHP 8.0 or higher is recommended for better performance.
Yes, fully tested and compatible with WordPress 7.0.
/wp-json/akch/v1/whoami REST endpoint that returns the visitor's fresh identity and nonces on every page load. The client-side JavaScript now calls it on boot and uses its values instead of the inline data — this defeats the whole class of bugs where a page-cache plugin (WP-Optimize, LiteSpeed, WP Rocket, W3 Total Cache, Cache Enabler, Cloudflare) served HTML built for a previous visitor. Symptoms fixed: phantom guest gate for logged-in users, Cookie check failed (403) on every REST call, and stale user identities across sessions./wp-json/akch/v1/guest-name REST endpoint as the primary path for saving a guest's display name. Some hosting stacks (Wordfence, iThemes Security, restrictive WAFs) block non-logged-in POSTs to admin-ajax.php and return an HTML error page. The new REST route is treated as more legitimate by most WAFs.admin-ajax.php. Both paths share exactly the same validation code server-side.DONOTCACHEPAGE and nocache_headers() signals.<script> tags carry data-no-optimize, data-no-minify, data-no-defer and data-cfasync="false" so no JS bundler combines chat.js into a shared bundle that would then be cached across visitors.account access mode now shows a clean, single-CTA modal when user registration is disabled on the site (previously the modal showed an inactive "Log in" tab-button that appeared to do nothing).Guest chat is not enabled on this site) instead of a generic Error.akch_login_url filter lets you point the button anywhere.<body> with a maximum z-index.akch_message_created, akch_room_created, akch_can_post_message) for extensions and integrations.