Skip to main content

Several tourism sites

Pour :Administrateur
View of the « multi site » page

The same Unisoft organization can administer several tourism sites in parallel. This is useful in several cases:

  • You cover several cities (e.g.: a main Beth Habad in Paris with a branch in Strasbourg and one in Lyon).
  • You manage several neighborhoods of the same large city, each with its specifics (Marais, Saint-Mandé, Sarcelles…).
  • You run several branches or subsidiaries legally tied to your organization.
  • You want to distinguish two audiences (for example: a site for Israeli tourists, a dedicated site for foreign students).

Each tourism site keeps its own visual identity, its own kosher places, its own hotels, its own FAQ and its own seasons. Nothing is shared between two sites — you work on one without risking affecting the other.

The site selector, present everywhere​

All pages of the Tourism module — Configuration, Kosher places, Accommodations, Shabbat, Tourists — start with a site selector in the top right, right next to the breadcrumb.

The selector lists all the tourism sites attached to your organization, with their status (Active or Inactive). Click the name of the site you want to manage to switch to it.

The site choice is remembered​

When you select a site, your choice is stored locally in your browser. Consequences:

  • When you switch from one page of the module to another (Configuration → Kosher places → Accommodations…), the same site stays selected. You don't have to reselect it on each click.
  • When you close then reopen the back office (the next day, for example), the selector automatically returns to the last site you consulted.
  • Your colleagues who connect from their own workstation have their own memorized choice — each one finds their own last context.

If you change browser or clear the cache, the selector resets by default to the first available site.

True separation between sites​

When you switch from site A to site B, the entire page reloads with the data from site B:

  • For Configuration, that's the colors, FAQ, hero slides, eruv, Beth Habad contacts… of site B.
  • For Kosher places, that's the list of restaurants and categories of site B. The categories themselves (Restaurant, Butcher, Mikveh…) are not shared: each site defines its own.
  • For Accommodations, that's the hotels of site B and the Booking.com / Airbnb configuration of site B.
  • For Shabbat and Tourists, that's the registrations and arrival announcements concerning site B.

No change made on site A propagates to site B, and vice versa. This is by design: each site is treated as a distinct entity with its own editorial life.

Typical use case: one branch per city​

Imagine an organization that runs three branches:

BranchSelector showsColorsFAQ oriented
Beth Habad of Paris Marais« Marais » — ActiveNavy blueInternational tourism
Beth Habad of Strasbourg« Strasbourg » — ActivePine greenWeekend visitors
Beth Habad of Lyon students« Lyon Campus » — ActiveBurgundyStudies and internships

The organization admin connects once, updates the Strasbourg FAQ before the summer season, switches to Lyon to add a newly opened kosher restaurant, then to Paris to publish a new hero slide. All from the same back office, without possible confusion.

Public URL: one site per address​

Each tourism site is published at its own public address. The View live button, present in the top right of the configuration and place-management pages, opens directly the right page on the matching site — you don't need to remember the URL.

If your branch has its own domain name, the tourism site uses it automatically. Otherwise, it's published under a sub-path of your organization's main URL.

Best practices​

  1. 1

    Confirm the selected site before editing

    Get into the habit of glancing in the top right before each change. A site mistake is easy to make: you think you're editing the Paris FAQ when you're actually editing the Lyon one.

  2. 2

    Give clear names to your sites

    If the selector shows « Site 1 » and « Site 2 », ask support to rename them as « Marais » and « Saint-Mandé ». The selector shows the short name of each site — be explicit.

  3. 3

    Document editorial differences

    If two sites cover a different target (tourists vs students, for example), note in an internal document what you publish on each. This avoids two colleagues making the same update on the wrong site.

  4. 4

    Check the Active / Inactive status

    An Inactive site remains visible in the selector (followed by a red « — Inactive » label) but no longer serves public pages. If you close a branch temporarily, ask support to set it to Inactive rather than deleting it: your data stays safe.

See also​