Glovario – Reusable Site Content

Use [glvr key="company_phone"], place {{glvr:company_phone}} in supported frontend text content, insert the searchable Site Variable block, or call glovario_get_value( 'company_phone' ) from theme code.

Built-ins are read-only values retrieved directly from WordPress, including glovario_builtin_site_name, glovario_builtin_site_description, glovario_builtin_site_url, glovario_builtin_admin_email, glovario_builtin_current_year, and glovario_builtin_current_date. They work through shortcode, token, block, Usage Inspector, and PHP API, and stay current without a saved duplicate.

Yes: [glvr key="company_phone" fallback="Contact us"].

Yes. Text and Multiline values can contain [glvr key="another_key"], including across multiple levels. Nested references inherit the same request and language context, so scheduled and language-specific values apply at every level. Cycles and excessive reference trees stop safely, using the nested shortcode fallback when supplied.

Yes. Enable title integration under Glovario → Site Variables, then insert a variable from the editor's Site Variable in title panel or type [glvr key="company_name"] directly in the title. The shortcode remains visible while editing and resolves on the frontend. Themes and page builders that use WordPress's normal title filters inherit the result; integrations that read the raw database title may need an adapter.

When a published title like "Call us at [glvr key=…]" gives the page its address, the address uses the value at that moment. If you change the value later, the variable's screen lists the addresses made from the earlier value and asks whether to update them. Old addresses keep working: they redirect to the new ones.

Weglot translates the whole page. When a variable has its own value for the visitor's language, Glovario marks it so Weglot leaves it unchanged (in shortcodes, tokens, and the Site Variable block). Titles, menus, and HTML attributes cannot carry that mark: there, correct the text in your Weglot translation list or add a Weglot glossary rule that keeps it unchanged.

No. Shortcodes, tokens, and blocks store only the variable key and resolve the latest value on every render.

Yes. Choose Find matching content after creating a variable, from its row action, or under Glovario → Content Conversion. Glovario scans only when requested, previews exact matches in standard WordPress post content, lets you select content items, and replaces supported text-node occurrences with {{glvr:key}} after confirmation. It preserves WordPress revisions and leaves attributes, URLs, scripts, styles, code/preformatted regions, shortcodes, unsupported blocks, metadata, widgets/options, and third-party builder storage untouched.

Glovario shows a real detected usage example and lets you leave the reference, replace detected references with the variable's current value, or remove them. Replacement previews highlight the exact change. If no usage is detected, deletion proceeds immediately. Detection is not exhaustive for PHP, themes, plugins, or third-party storage.

No. Variables are reusable site content and can be visible on the front end. They are not a secrets vault.

JSON. An export contains your variables, their categories, scheduled and language values, and image references; importing it into another site recreates missing categories and finds the same images in that site's Media Library. Every file is fully validated before anything is written, and a preview shows what would change.

Glovario is built for bilingual sites: it handles a default language and one second language, and no more. On a site with more languages, variables cannot have a value for the others; visitors in those languages see each variable's default value, and a red notice in the admin names your multilingual plugin and lists the languages concerned. The plugin is still useful there for content that does not change with the language, such as addresses, phone numbers, and email addresses.

Yes. The Paragraph, Heading, and Button widgets have the Make variable and Insert variable buttons in their text toolbar, both in the panel and in the floating toolbar when you edit the text directly on the page. The editor canvas shows each variable's current value, and the widget keeps the shortcode, so later changes to the variable appear everywhere.

Yes, for two languages (the default and one more). In Standalone mode, enable the compact site-wide flag switcher under Locale Settings, insert the Glovario Language Switcher block, or use [glvr_locale_switcher]. The site-wide option is off by default and, when enabled, appears with safe spacing in the top-right header area on every public page. A visitor's allowlisted choice switches the frontend WordPress request locale, installed translation files, locale-aware formatting, document language, and locale-conditioned Site Variables together. The switcher does not create or translate separate posts, menus, slugs, media, or URLs. Those require authored translations or a full multilingual plugin. When Polylang, TranslatePress, or a configured Weglot installation is active, Glovario automatically defers to it and hides the standalone selector. An unconfigured Weglot installation does not disable Glovario's selector. With other multilingual plugins, choose the WordPress request locale mode under Locale Settings so Glovario follows the language WordPress uses for each page.

Yes, with supported cache plugins. LiteSpeed Cache, WP Super Cache, and W3 Total Cache keep one cached copy per language, so visitors who chose the second language also get cached pages, and saving a variable refreshes every copy. On OpenLiteSpeed servers, restart the web server once after switching to Standalone mode so it applies the new cache rule (Locale Settings reminds you). W3 Total Cache's Disk: Enhanced mode cannot keep a second copy, so Glovario makes visitors who chose the second language skip it (they get correct, uncached pages). Cloudflare, Varnish, and similar caches do not cache visitors with cookies in their standard setup; if yours caches every page (for example a Cloudflare "Cache Everything" rule), add a rule that skips the cache when the glovario_locale cookie is present. On Cloudflare: Caching, Cache Rules, a rule for (http.cookie contains "glovario_locale=") with Bypass cache. Locale Settings warns when it recognises Cloudflare, Fastly, or Varnish in front of your site. On Varnish, in vcl_recv: if (req.http.Cookie ~ "glovario_locale=") { return (pass); }. On nginx FastCGI cache: fastcgi_cache_bypass $cookie_glovario_locale; fastcgi_no_cache $cookie_glovario_locale;. Locale Settings reports every detected provider, raw and normalized locale mappings, the provider Glovario follows, WordPress and Glovario locale values, provider destinations, and missing language packs. It warns when multiple multilingual providers are active or when the multilingual plugin's current language is not one of the two configured languages.