# ABeCe Booking user guide

Install the ZIP through Plugins → Add Plugin → Upload Plugin, then activate ABeCe Booking. WordPress 6.2 or newer, 64-bit PHP 8.1 or newer, and MySQL 8.0+ or MariaDB 10.6.1+ with InnoDB are required. Back up your website before updating. Optional Freemius sharing can be skipped in Lite.

In ABeCe Booking, create your sports and resources, enter opening hours and configure prices. Operators can create internal reservations without a customer account. Lite has no resource quota and its public calendar displays occupancy. Put `[abece_booking]` on a published page and choose that page in Settings → Integrations.

Premium is distributed separately. Its customer booking form requires a signed-in WordPress customer. In Resources, choose the resources that accept online reservations. Starter permits four online resources; Club and Pro have no online resource quota. Internal resource management is unlimited in all editions. A downgrade preserves reservations, prices and resource selections. If the selection exceeds Starter's limit, choose four resources explicitly to resume customer booking; internal booking remains available.

Configure your site time zone, cancellation policies, prices and payment methods before taking bookings. Club includes membership management. Pro additionally includes credits and financial reports. Record only actual payments. Creating a QR payment instruction does not transfer money.

Set a published privacy-policy page in WordPress Settings → Privacy. Review the booking privacy settings and collect only necessary data. WordPress Tools → Export Personal Data and Erase Personal Data provide the native request workflow. Verify the requester's identity. Financial evidence, outstanding debts and active operations can require retention and operator review. Automatic retention cleanup is off by default; inspect its preview and configure a justified policy before enabling it.

For a legacy full 0.23/0.24 installation, back up first and follow the guarded Premium handover: install the separately distributed Premium package and activate Pro through its official account page before retiring the old engine. Do not replace a legacy full installation with Lite if you need its paid functions.

Updates from versions up to 1.1.0 migrate WordPress setting names to `abece_booking_`. Existing new settings take precedence, including disabled values. The online resource selection is preserved. In 1.1.2, schema 13 renames all 24 operational tables from the historical `asb_` suffix to `abece_booking_`, retaining the actual WordPress prefix and every operating row. Existing installations require the maintenance procedure below; table renaming never runs during an ordinary HTTP or cron request. Legacy setting copies are retained for inspection. Temporary pre-upgrade import/export jobs must be restarted; expired jobs are not revived. A pending WordPress privacy request retains its owner and confirmation state.

Deactivation and ordinary plugin removal retain business data. The separately confirmed destructive data-removal tool permanently removes data; use it only with an appropriate backup and authorization.

The plugin includes editable frontend sources and pinned build inputs under `source/`. Instructions are in `source/README.txt`. PHP dependencies retain their source and license notices. See `LICENSE`, `COPYRIGHT.txt` and `THIRD-PARTY-NOTICES.txt`. Contact the venue operator about bookings and personal-data requests; plugin support: https://www.abece.cz/.

## Database maintenance upgrade to 1.1.2

New installations create schema 13 directly and do not need an MU plugin or a CLI migration. On an unsupported database, activation is refused with the actual server version and hosting requirements. No application tables are created.

For an existing schema 12 installation, schedule maintenance and retain a complete backup of both the previous plugin files and SQL database. Stop external cron jobs, queue workers and other CLI jobs that access this site. Install and activate the matching 1.1.2 edition; reactivation with retained tables is permitted into diagnostic mode. The new plugin remains in a safe diagnostic mode until migration completes; reservation, privacy and other business write handlers are not registered in that mode.

An administrator with filesystem access and the necessary database privileges then runs:

```
wp abece-booking database status
wp abece-booking database migrate --backup-dir=/private/booking-backup --verification-db=abece_booking_verify_yoursite
```

Create the backup directory beforehand, owned by the operator with mode 0700, outside the web root and Git. Create a separate empty verification database with the indicated prefix; it must never run a WordPress copy. The migration account needs SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER and LOCK TABLES for the site and verification databases, plus PROCESS visibility to drain connections safely. If the hosting account lacks these rights, ask the hosting administrator to perform maintenance. The workflow refuses unsupported engines, shared database prefixes, unexpected views/triggers, and unreviewed external or automatically named foreign keys. The actual WordPress prefix must contain only letters, digits or underscores and be at most 29 characters; longer names are refused without truncation.

The command requests confirmation, installs a temporary persistent maintenance gate, drains existing database workers, writes a private complete SQL backup and verifies it by a real import. It then renames all 24 tables atomically, verifies their definitions and row fingerprints, migrates historical WordPress identifiers and only then records schema 13 and reopens the site. The temporary MU maintenance file is created by this command and removed after success; it is not a permanent dependency or a condition of a clean installation. MySQL 8.0.13+ retains SQL WRITE locks through RENAME. MariaDB and older MySQL 8 releases require an unlock/rename/relock handoff while ingress remains blocked and external workers remain stopped. Arbitrary external direct SQL must not run during this window.

Allow a maintenance window appropriate to the database size and host. An isolated MySQL 8 test with 10,000 reservations, 20,001 history entries, 5,000 members/memberships and 20,000 credit transactions took about 17 seconds including full backup import verification; this is a measurement, not a hosting performance guarantee.

If the command fails or is interrupted, leave its maintenance files in place. Do not activate an older plugin against renamed tables, create missing empty replacement tables, delete the journal or infer success from a version label. Correct the reported prerequisite and rerun the command with the original private backup directory. A verified journal allows resumption after a completed atomic RENAME. If backup verification failed before a journal was written, provide a new empty verification database.

## Recovery and optional pilot protection

Downgrade is not an automatic feature. During closed maintenance, restore the complete verified SQL backup and the exact corresponding previous plugin files as a matched pair. Verify every table and operating row before starting WordPress, then check the previous engine and its business API before reopening the site. Keep the maintenance gate until these checks pass. A restore of an older backup after new business writes would discard those writes: reconcile them first, and never restore blindly. Private backup files and their manifests must remain outside the web root and repository.

A direct update from 1.1.1 or older code can replace its files even on an unsupported database: that older code has no pre-update database guard. The 1.1.2 fallback then stops business operations and displays diagnostics without migrating data. Preserving the previous files before such an update requires a pre-update check. Existing pilot operators may optionally install `tools/pilot-database-preflight.php` from the source archive in `wp-content/mu-plugins/` before updating; it blocks this plugin's update on an unsupported database and does not migrate data or initialize a licence. It is not required for ordinary installation, and can be removed after the pilot upgrade.

Once 1.1.2 is installed, its update guard checks future package requirements before core's deactivation callback. It uses the WordPress downloader and filesystem APIs to inspect the real package without executing target PHP or changing package bytes. It also rejects a standard ZIP downgrade to a pre-schema 13 package. Manual filesystem replacement outside the WordPress updater bypasses that protection and must follow the matched database/files recovery procedure.


## Security release 1.1.3 and historical installations

Sites already using schema13 (including public Lite1.1.2) retain schema13 and all24 tables when installing1.1.3. New installations create schema13 directly. The SDK security update does not change prices, purchased features, customer records or online-resource limits.

The old full0.23.0 archive uses the same WordPress.org basename as today's Lite. It must not accept an ordinary Lite replacement. Historical Freemius beta installations must not accept an unplanned update requiring the schema transition either. Before any release, their operator must verify the installed basename and actual update channels, apply and verify the separate `tools/legacy-update-guard.php` on every controlled historical site, or prove an equally effective external update block. The guard is an optional operator tool for those identified sites; new customers do not install it. It hides both known product update offers and refuses supported updater entry points before deactivation/file replacement while the schema13 layout is incomplete. It does not protect arbitrary FTP/file replacement.

For a historical site, schedule maintenance and stop external workers, verify complete database and matching file backups, use the existing confirmed CLI migration described above, verify all24 table fingerprints and the licence identity, then reopen the site. The guard remains closed until the complete InnoDB schema13 layout exists. Manual file replacement must happen only under that planned maintenance; do not disable the guard simply to click Update. Keep a complete matching files/database restore available. Do not send SQL backups, keys or signed update URLs to public support.