BevQ web widgets: location scope, saved URLs, caching, and deletion

What this does

BevQ menu widgets have location-owned configurations and stable public IDs. Updating configuration differs from duplicating or deleting a widget, and cached pages may retain older content.

Before you start

• Choose a group and location and prepare the intended menu sections.
• Treat creation and deletion as persistent actions, not preview controls.

Steps

1. Choose the widget in the selected location.
2. Select sections and configure the display.
3. Save the same widget to retain its public URL.
4. Reload the installed public page and account for caching when checking changes.

Install one or several menu widgets

The web-menu script registers the smartqtv-web-menu custom element. Its widget-id attribute selects a saved widget; menu-id and data-widget are fallback attribute names, in that order. Each element has its own React root and shadow root, so multiple elements can select different widgets on the same page. Legacy .smartqtv-webmenu[data-widget] and [data-smartqtv-webmenu][data-widget] placeholders are replaced during initial mounting, and newly inserted matching nodes are observed. Keep the saved widget ID, not the display name, in the installation markup. This is the script/custom-element path, not evidence of an iframe installer or domain allowlist.

Embedded menus refresh on mount or widget ID change

The embedded menu initially reads the same per-widget cache as the public page and then makes a request. Changing an observed widget-ID attribute rerenders the element; a changed effective ID reruns the load effect. Saving settings elsewhere does not change that ID and does not trigger periodic polling in this component. Reload the host page to remount and check changes, allowing for the documented cache layers. Removing the element unmounts its React root and aborts its current load. Adding the same widget twice creates two instances, not a merged configuration.

Embedded width follows the website container

The script embed observes its host element with ResizeObserver and also handles window resize. The width passed to the menu renderer is bounded from 320 to 1200 pixels and normally comes from the host's client width, not the Admin preview selector. A container narrower than 320 can therefore still receive a 320-pixel layout calculation. The element is block-level and 100% wide; test the actual website container rather than assuming an Admin mobile preview proves the installation fits. Its shadow root isolates these internal styles from ordinary host-page CSS selectors.

Embedded loading and fallback link

Without a usable cache, the script initially renders Loading menu. Missing widget data or incomplete group/location scope fails the load and displays Menu not loading? View here with a link to the widget's public URL. A cached payload can remain visible after a failed refresh instead of showing an error. The installer also creates a light-DOM fallback link when its target is empty, but the script must execute to create that fallback; it is not a guarantee for sites that block all script execution. The direct link is a troubleshooting alternative, not evidence that the underlying widget still exists.

New and Copy immediately create widgets

New Widget requires a selected group and location and immediately writes a location widget plus public lookup. It starts with no selected sections, grid layout, two columns, mobile stacking and alphabetical sorting; image and price display start off. Copy makes a separate saved widget with a new ID and public URL, named with (Copy). Neither action is an unsaved preview. The item write and public lookup write are separate, so a failure can require checking for partial creation before retrying.

Saving preserves the public widget URL

Saving an existing BevQ widget writes the same widget ID and refreshes its public lookup; its URL remains https://bevq.smartq.tv/widgets/ followed by that ID. Changing its name or slug does not replace the ID-based URL. Copying creates a different ID, so a copied widget requires its own installation target. The script URL is https://bevq.smartq.tv/web-menus.js. The public-page refresh behavior is separate from the script bootstrap behavior; this unit does not claim an already installed script hot-reloads every settings change.

Why a public widget still shows older content

The public widget page can first display a session-cached payload up to five minutes old, then makes a fresh menu request when the widget ID loads. If that request fails and a valid cached payload exists, it retains the cached display instead of surfacing the error. The inspected page does not periodically poll for configuration updates. The menu API separately has a 30-second memory cache and successful responses permit 60-second caching plus 300 seconds of stale-while-revalidate. Reload and allow for these layers before diagnosing a save failure.

Deleted widgets and cached copies

Delete removes the saved location widget and its public lookup in parallel. A fresh public menu lookup with no widget returns Widget not found with HTTP 404, itself cacheable for 30 seconds. Existing successful API caches and an already loaded/session-cached page can retain older content; deletion is not an immediate erasure of every embedded display. The inspected delete handler has no confirmation step. Do not use it to test whether a URL is still installed.

Widget location and section selection

The widget manager stores each configuration beneath the selected group and location and normalizes its selected section IDs. No selected sections means show none, not show every menu section. Widget list entries are sorted by name. Desktop/tablet/mobile preview controls use widths 1100, 820 and 390 pixels. The public lookup identifies the owning group/location; this is not a parent-widget inheritance-and-location-override contract. Verify the widget's location and section selections when its preview contains no items.

Permissions and scope

• This guide traces location storage and public delivery; complete editor-role enforcement and installation-domain controls remain under audit.

Mobile

• Manager preview widths are desktop 1100, tablet 820 and mobile 390 pixels. These preview choices are not proof of actual mobile-browser behavior.

What happens next

Verify the saved result in the correct scope and delivery path. A preview or status badge is not proof that every production Player has refreshed.

Warnings

• This source-reviewed guide describes the named paths only. Operational coverage and production visual verification are still in progress.

Related articles