CMS Troubleshooting

This standard gives the diagnostic order for content management problems. It is used by Content Editors and the Web Administrator when a change does not appear or a public page behaves unexpectedly, and by Front Desk staff reporting such problems. Most console problems are one of three things: the wrong store was edited, the store the site reads is empty, or the public site has not yet refreshed. Operators shall work this standard in that order before requesting engineering help.

Roles and duties

• Content Editor: performs the checks below and corrects content in the correct store.
• Web Administrator: checks the audit log and record state, and escalates what this standard does not resolve.
• Front Desk: reports the page, the expected content, and the time the change was saved; does not re-edit content to force a result.

First check: the wrong-store traps

Three duplicate stores account for most "I updated it but nothing changed" reports. Check these first.

1. Gallery. The public gallery reads the public photo store. A second gallery store exists but has no public reader; photos placed there never appear. If photos are missing, confirm which store received them and move the work to the public photo store, under Website.
2. Policies. Public policy pages render from the policy store. Page records have no public rendering for policies. If a policy edit did not appear, the edit was made in the wrong place; repeat it under Legal and Waivers.
3. Reusable block locale. Reusable blocks are read only under the en-US locale. A block created under any other locale value is invisible. Check the locale before anything else, under Website.

Second check: empty stores

1. Banners. If no banner displays, confirm a banner record exists at all. Once one exists, check in order: the active switch; the schedule window (a future start means scheduled, a past end means expired: both are the system working as set); placement matching the page being viewed; and a valid banner type, under Website.
2. Navigation. Navigation entries take effect through the public navigation reader once records exist, filtered by menu and active switch, in sort order. Every entry requires a web address or a linked page, and shall never link to a page that is not live.

Third check: the refresh delay

The public site displays stored default content on first load and refreshes as changes publish. After saving, allow a few minutes before treating an absent change as a failure. If the change still has not appeared, verify in order: the record actually saved (check the store, not recollection of clicking save); the correct store was edited (first check, above); and whether the refresh mechanism failed. Console actions return explicit errors: "page not found," "image is required," "either address or page is required." Read the error instead of retrying without changes.

Content-specific failures

Page not publishing. Check the publication state (a page that is not live is invisible by definition); then any scheduled publication time (a future time means waiting, not failure: clear it to publish now); then the page address (two pages sharing one address means the site may serve the other); then the revision history, which shows whether the save landed. For policy pages, see the wrong-store traps.

Pricing rule not applying. Check the surcharge record: inactive switch (an inactive rule does not apply); a restriction to a service the booking does not include; the automatic-application switch off, meaning the surcharge waits for staff to add it manually: the state of both current weekend surcharges; and whether the amount is a flat fee or a percentage. Batch pricing edits are audit-logged; check the log to see whether the batch ran and what it changed. Duplicate active weekend surcharges shall be consolidated under Services and Pricing.

Service invisible. For the booking catalog, check in order: the online-booking switch, the active switch, and the location record for the customer's location. For public services content, check the visible switch and the display order. The two stores do not update each other; see Services and Pricing.

Booking flow broken. Isolate the failing step. Service selection: the catalog checks above. Date and time: blocked times on the calendar, or a service duration that does not fit the open gap: a 60-minute service cannot book into a 45-minute opening. Deposit payment: a gateway problem, worked under Payments and Gateway. Confirmation: confirm whether the appointment record exists before treating the flow as failed; a booking saved without a confirmation message is a messaging fault, not a booking fault.

Gateway errors. Work in the order customer, configuration, processor, under Payments and Gateway. Record every gateway error with what happened, when, and for which booking; a kept log turns a recurring mystery into a visible pattern.

The audit trail

Every console action: page edits, banners, gallery, navigation, reusable blocks, search metadata, waivers, gateway settings, promotions, and pricing and service changes: is recorded in the audit log with the action, the record, the operator, the network address, and the resulting state. When something changed and no one reports changing it, when a batch edit appears not to have run, and when a price moved overnight, the audit log is the first diagnostic, not the last resort.

Controls

Troubleshooting shall not be performed by deleting and recreating records to force a result; deletion destroys the history the audit trail and revision records exist to preserve. Corrections are made in the correct store, and the incorrect record is deactivated or corrected, with a change note stating the reason.

Records

This standard produces corrected records with change notes, audit log entries for each corrective action, and gateway error logs kept by Front Desk. A fault that recurs three times shall be written up as a short incident note: symptom, cause found, correction made: and kept with the console records.

Escalation

A fault this standard does not resolve within one business day, or any fault affecting checkout or booking, goes to support@aapawz.com with the incident note. A fault that has published incorrect legal or pricing content to customers goes also to legal@aapawz.com the same day.

Review cadence

The Web Administrator reviews recurring-fault notes monthly and amends this standard where a new failure pattern has been established.