Prepare the site and install SmartSite Assistant

Before Upload Plugin

Know the package, the environment, and the way back.

A safe installation begins before WordPress extracts a ZIP. Obtain the release from the controlled dashboard, read its changelog, verify the site can run it, take a recoverable backup, and use staging or Local for the first pass.

Get the official plugin package

The private SmartSite download dashboard is available at smartsite.markomalec.com/download. It provides:

the latest installable SmartSite Assistant plugin ZIP;
the current changelog; and
changelog history for earlier releases.

The dashboard requires a password. Obtain access by contacting marko@saleswizard.nl or Marko through Google Chat. The Saleswizard Bitwarden vault also contains the saved dashboard password for authorized team members.

Download the ZIP itself—not the documentation project, a development folder, or an extracted working tree. Keep the filename and changelog together in your release record so an administrator can later explain what was installed.

Check the site before you upload

The practical environment check
Requirement	Why it matters	How to verify safely
WordPress administrator access	Installation, activation, settings, and wizard actions require appropriate dashboard capability.	Confirm you can open Plugins → Add New Plugin on the intended site.
PHP 8.2 or newer	The bundled OpenAI client dependency requires PHP 8.2, which is stricter than older README claims.	Use Site Health or hosting controls; test the exact production PHP branch on staging.
A supported current WordPress release	The plugin header does not currently declare a minimum WordPress version.	Use the organization’s supported release and verify on staging rather than assuming compatibility from a header.
Outbound HTTPS	OpenAI, the private update service, Meta when used, and configured public webhooks need server-side network access.	Ask the host or run controlled connection tests after activation; never disable TLS verification.
Writable uploads area	Compiled public widget assets and knowledge-file uploads use WordPress uploads.	Confirm ordinary Media uploads work and filesystem permissions follow WordPress guidance.
OpenAI API account and billing	Chat, translation, metadata, knowledge, and file operations require a regular project API key and may incur cost.	Prepare a scoped key in the intended OpenAI project; do not place it in the ZIP.
Backup and rollback access	Activation upgrades plugin data and copies assets; updates can affect stored configuration and runtime behavior.	Take database and `wp-content` backups and confirm the person performing rollback can restore them.

Test mail delivery if you plan to use the Contact Request preset. Confirm public HTTPS and receiver authentication if you plan to use webhooks. Those are capability requirements, not reasons to delay a basic knowledge-only installation.

Install with a way back

Read the current changelog. Identify configuration, data, runtime, or compatibility changes that deserve a staging test.
Download the latest ZIP. Use the access-controlled dashboard and store it in the approved release location.
Back up the site. Capture the database and wp-content; know how to restore, not merely how to create an archive.
Test outside production. Use Local or staging with the same PHP branch and representative configuration.
Open Plugins → Add New Plugin → Upload Plugin. Select the SmartSite Assistant ZIP and choose Install Now.
Activate. WordPress loads the plugin, creates or upgrades its analytics/log table, and copies compiled widget assets into uploads.
Open AI Website Chat. Confirm the main interface or Setup Wizard loads without a PHP error.
Complete a restricted conversation. Activation alone does not prove API, knowledge, frontend assets, streaming, or logs work.
Record the result. Keep release, date, tester, environment, test questions, and any rollback decision.

If WordPress reports that the destination already exists, stop and confirm whether this is a first install, an update, or a manual replacement. Do not delete the production plugin directory casually. Use the normal controlled update route and preserve configuration/data backups.

Installation changes more than one folder

What activation touches
Area	What happens	What removal or rollback must consider
Plugin directory	PHP, JavaScript, styles, vendor dependencies, and bundled build tooling are installed under `wp-content/plugins`.	Replacing code does not automatically remove database options or uploaded knowledge.
Database	The SmartSite log/analytics table is created or upgraded; plugin settings and profiles live in WordPress options.	A code rollback may leave newer data structures; use a tested backup for high-risk changes.
Uploads	Compiled widget assets are copied and knowledge documents may later be stored locally.	Deactivation is not the same as deleting uploads or remote OpenAI files.
External services	Later setup can create OpenAI vector stores/files, send mail, call webhooks, or configure Meta.	Restoring WordPress alone may not undo external actions or remote data.

The Astro documentation directory is a separate application. Never upload smartsite-assistant-docs through WordPress. The installable package must contain the plugin rooted correctly so WordPress recognizes ai-website-chat.php as the plugin bootstrap.

Verify the installation in layers

First confirm the administrative layer: SmartSite is Active, AI Website Chat appears, tabs render, and no PHP fatal error appears. Next confirm the service layer: save a regular OpenAI key and verify the Assistant model list can load. Then confirm the runtime layer with one active Assistant and a private frontend conversation. Finally confirm operations: Chat History receives the test and errors are understandable.

Do not make the widget public during this check. A fresh plugin may have incomplete instructions, no approved knowledge, sample presets, and default visibility/security choices that have not been reviewed.

Updating an existing site

Treat an update as a release, not a file copy. Read every changelog entry between the installed version and latest dashboard version. Back up, reproduce the site in Local/staging when practical, install the update, and rerun a small regression set: one general response, one knowledge question, one Tool path if enabled, visibility for an allowed and denied visitor, and Analytics recording.

If Advanced Agents is used, run Flow Checks and a safe simulator test after the update. If it is off, test the Basic Assistant-plus-Tools runtime directly. Do not enable a runtime merely to test an unrelated update.

Keep a small installation record

For every environment, record the site name, installed release, package source, download date, person performing the change, backup location, PHP/WordPress versions, and regression result. Do not include API keys or the download-dashboard password. This record helps distinguish “the latest release exists” from “this site is running and has tested that release.”

When the dashboard shows several changelog entries ahead of the installed site, review the whole interval. A later entry may assume a migration introduced earlier. If a release affects stored options, database tables, frontend assets, OpenAI behavior, Knowledge sync, Tools, or workflow runtime, include that path in the update test rather than checking only whether the Plugins screen says Active.

Production timing matters

Choose a maintenance window proportional to the site’s chat usage and enabled actions. Have an administrator logged in, the previous approved package or backup available, and an owner ready to test the frontend. Avoid beginning immediately before a high-traffic campaign, outside support hours, or when nobody can check mail/webhook receivers.

If the update changes public assets, clear only the relevant caches after confirming the new files exist. Broad cache deletion is not a substitute for knowing which version WordPress loaded. Test a private browser so an old authenticated session or cached conversation does not mask the result.

If activation fails

Capture the exact error without secrets. A PHP version or dependency failure should be corrected at the hosting layer before repeated activation. A filesystem failure needs permissions/ownership investigation. A blank screen belongs in WordPress/PHP error logs, not in a series of random plugin-setting changes. Restore the known-good state if production is affected and investigate in a clone.

Confirm the plugin—not private licenses around it

Screenshot capture pending /images/screenshots/start/requirements-installation.webp

Requirements and Installation

Capture: Show the Plugins list immediately after activation with SmartSite Assistant visible and active. Hide unrelated premium license data.
Show: Plugin name, version, Active state, AI Website Chat menu
Viewport: Desktop, 1440 × 900
Annotate: Use numbered callouts only for controls referenced in the procedure.
Redact: OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text