VTX AI Chat / WordPress plugin / PHP + JavaScript

The answer starts
with what gets in.

The chat window is the small part. I built the WordPress layer that selects context, applies scope settings and makes the provider request.

Content lifecycle. Administrator controls.
A separate, server-side OpenAI client.

01 / Before the provider

WordPress is
the knowledge layer.

Native content and deliberately imported knowledge are different inputs. They have separate controls—and different trust boundaries.

Real VTX AI Chat WordPress knowledge index and JSON knowledge upload controls — Actual knowledge workspace · captured configuration, not adoption metrics

01 / Native content

Follow the content lifecycle.

Save, trash and delete hooks maintain an option-backed index. Selected post types, extracted text and title-weighted keyword matching supply relevant records.

02 / Imported knowledge

Make extra context explicit.

An administrator can upload a validated JSON knowledge file. Trusted PHP extensions can also contribute context through a separate registry.

03 / Provider boundary

Keep the transport separate.

The browser calls WordPress AJAX. PHP assembles the context and bounded history, then calls OpenAI. The API key is not sent to the widget.

02 / A request has more than one exit

Not every question
needs a model.

When general questions are disabled, the context and keyword scope check can return a local reply. A provider request is a branch—not the whole architecture.

Read the behavior · illustrative scenarios, not a live plugin

01 / QuestionA question about the site
02 / Retrieve contextKeyword-matched context
03 / Scope decisionWithin configured scope
04 / OutcomeOpenAI → reply

WordPress/KB context and bounded conversation history enter the server-side request. Retrieved source links accompany the result; they are not verified citations.

Real AI Chat settings crop showing content selection, widget, logs and request-limit controls — Actual settings crop · controls, not a security certification

Configuration belongs
in the operator’s hands.

Settings, index rebuilds and knowledge changes require an administrator capability and a nonce. Public chat uses its own AJAX nonce and a transient-based request limit.

A public nonce is not a user identity. A request limit is not a hard cost ceiling.

03 / Product boundaries, without the fine print

A useful boundary
must be a real one.

What Free excludes

The built-in index excludes WooCommerce product/order types, assigned shop and checkout pages, and recognized commerce blocks, shortcodes and builder content.

Imported knowledge and trusted extension callbacks are separate inputs. This is not a blanket guarantee that commerce information can never reach the provider.

What this is not

Keyword retrieval is not semantic search. A scope instruction is not proof against hallucinations or prompt injection. Only the OpenAI transport is implemented; the extension registry supplies context, not interchangeable model providers.

04 / Running it is part of building it

An interface for
the operator, too.

Knowledge controls, a test console, conversation logs and diagnostics make configuration inspectable. The screenshot records a past test environment—not a live health check.

Actual VTX AI Chat diagnostics screen for key, knowledge, log table and configured rate limiter — Historical interface capture · no new API call or live PASS result

Deliberately small frontend

Vanilla JavaScript, a WordPress AJAX request and DOM-rendered replies. No frontend provider key or model SDK. Message length and server-side conversation history are bounded.

Still on the product backlog

Stronger abuse and spend controls; log retention and privacy workflow; batched indexing; generic public provider errors; widget focus refinements. The current transcript log needs deliberate operational policy.