# Installation, upgrade and recovery

Use WordPress 6.5+, PHP 8.2+ with Sodium, HTTPS, and outbound API access to the trusted Waitlistize origin. Install the ZIP from Plugins → Add New → Upload Plugin. No Composer, npm or remote code is needed at runtime. On Multisite connect every subsite separately; network activation does not share an account.

In WAITLISTIZE → Settings enter the target account slug, start pairing, sign in to that account in the separate approval tab and compare the site URL/security code. Only the account admin or global superadmin can approve. Approval does not verify domain ownership. New pairings request service/availability reads, public booking creation and booking reads. Existing grants never gain scopes automatically; explicitly disconnect/reconnect if the booking list requests permission.

Insert either Waitlistize block, bind it to the current numeric account and select a service. Services and embeds also generates account-bound shortcodes and unpublished page drafts. New-block defaults affect inserter variations and newly generated drafts only. Pasting existing blocks or reusing old shortcodes keeps their saved attributes. No global booking rules, capacity or redirect configuration is added.

The booking list is restricted to `manage_options` with a REST nonce. Filter by account-local date range, service ID (including an inactive service when known), native status and past records. Backend L5 fixes page size at 50 and includes native active waitlist rows. The row link comes from the backend; opening it requires normal Waitlistize login and permissions. No local booking writes or persistent list cache exists.

## Upgrade from 0.1.1 / W2 / W3

1. Back up the database, plugin files and trusted configuration. Keep WordPress salts and instance identity unchanged.
2. Confirm the backend has integrated L1/L3/L4/L5 and `default_resource_id` support. No Laravel changes are made by this package.
3. Replace plugin files using the ZIP. Do not delete/uninstall first. Existing connection options and block schemas are retained.
4. Check existing blocks, shortcodes, pending pairings, diagnostics and frontend. New admin-read permission requires a newly approved connection; refresh does not add scopes.
5. Test single/group and redirects with dedicated test data; do not use real customer records for new tests.

Deactivation clears scheduled checks and keeps encrypted credentials/defaults/pages. Reactivation resumes checks for an approved connection. Disconnect deletes local credentials and tries remote revocation; if confirmation fails, revoke from Waitlistize Settings → Integrations → WordPress. Delete removes local plugin options on each subsite without network traffic and keeps content. Reinstall then requires new approval; restore an older ZIP by replacing files without uninstalling if rollback is needed.

## Diagnostics and limitations

WordPress.org language packs provide the plugin's PHP labels, admin JavaScript messages and Gutenberg editor translations. Install available translations through Dashboard → Updates → Update Translations. The release ZIP does not bundle PO, MO, POT, JSON or PHP translation catalogs. Until an appropriate plugin language pack is available and installed, these plugin surfaces use English; missing strings also fall back to English. This also applies to PHP-rendered public embed notices and no-JavaScript messages. The surrounding WordPress interface uses its own core translations. The native booking widget keeps its existing Hungarian/English/German dictionary and service-language selection; service names and descriptions keep their existing API language behavior. Repository translation sources are retained for maintenance and import, rather than loaded from the source checkout.

Reload the admin screen after nonce expiry. API outages produce safe errors without exposing upstream bodies or tokens. Refresh service data repeats uncached reads; there is no configuration cache to purge. Diagnostics show service counts only after a complete bounded catalog read (maximum 2,000 services). Counts cover the public catalog; an unavailable result is never presented as zero.

The backend does not expose subscription plan details, capabilities or an inactive-service admin catalog. These requested overview/service-admin features remain unavailable; the plugin does not invent endpoints or substitute mobile credentials. The list uses a numeric service filter so an inactive service can still be selected by its known ID.

Use a WordPress.com site that permits plugin uploads and meets runtime/API requirements. Consult [current hosting conditions](https://wordpress.com/support/plugins/). WordPress.com has not been independently tested; do not claim every plan or host is supported.

Before cloning, set a distinct trusted `WAITLISTIZE_INSTANCE_KEY`; unchanged complete clones cannot be distinguished locally. API origins belong in trusted server configuration, never a REST parameter or admin host field. See `security.md` for local-only HTTP exceptions.

[Waitlistize terms](https://waitlistize.com/legal/en/terms.html) and [privacy policy](https://waitlistize.com/legal/en/privacy.html) describe the external service. Update the site's own privacy notice for guest fields, consents, visitor metadata and any hosting/plugin logs. The plugin contains no analytics or remote executable code.