Appearance

Regles de gestion & contraintes ​

Multi-tenant (skins) ​

  • Un seul socle de code sert 30+ clients. Chaque client = un skin selectionne au build via --skin=.
  • La configuration d'un client est centralisee dans doc/StarterKitv3_InfosTechniques.json (langues, URL, modules, widgets, shop on/off, secrets DB). Ce JSON est valide contre StarterKitv3_InfosTechniques_Schema.json au demarrage du build ; une entree invalide bloque le build.
  • Il n'y a pas de build "global" : tout cible UN skin. Build-All-Customers est l'exception (compile toutes les solutions clients).

Base vs shop ​

  • La couche shop (StarterKitv3_shop.sln) n'est compilee et installee que si le client a le module Shop active (IsShopEnabled() lit doc/StarterKitv3_InfosTechniques.json).
  • Un client vitrine n'embarque pas la pile uCommerce ; un client e-commerce si. C'est un flag de configuration, pas une branche de code.

Umbraco / patches ​

  • A chaque mise a jour d'Umbraco, reappliquer les 4 fichiers patches (source de verite Nanoxi.Cms.Resources/Umbraco/) : umbraco.css, umbraco.controllers.js, umbraco.resources.js, umbraco.services.js.
  • Lors d'une mise a jour de jQuery, aligner currentArticlePreview.html (ligne 4).

Langue ​

  • Contenu multilingue par item selon le client (FR / DE / EN). Locale par defaut fr-CH.
  • L'image Docker importe explicitement la region fr-CH (RegionSettings_frCH.reg).

Donnees & index ​

  • Tables custom prefixees nanoxi_* (petaPoco).
  • Pour les sites a index Examine custom (ex. IEDS / IchMedia), la base et les medias doivent matcher : ne pas remonter l'un sans l'autre, sinon l'index est incoherent (reconstruire l'index apres remontee).

Deploiement ​

  • Deploiement pull-based : un runner sur chaque serveur IIS applique l'artifact website/ via robocopy /E (copie/mise a jour seulement, sans /MIR/purge) : on ne supprime jamais les fichiers extra cote serveur (ils contiennent du runtime non present dans l'artifact : Umbraco\ucommerce\Apps / RavenDB25, Raven\, *.lic, local.config, Plugins...).
  • Dossiers preserves cote serveur (jamais ecrases, exclus du robocopy) : Config, App_Data, Media, Customer, umbraco\Logs, Web.config.
  • Convention IIS : app pool umb_<skin>_<env>, chemin physique E:\<skin>\website.
  • staging et production se deploient manuellement (jamais sur push direct). master/staging ne declenchent un pipeline que via "Run pipeline" (web).

Secrets ​

  • Les mots de passe DB (saPassword, customerPassword) et licences sont dans doc/StarterKitv3_InfosTechniques.json et prodconfig/<skin>/. Ce depot est interne ; ne pas diffuser.

Newsletter ​

  • Toute inscription newsletter se fait en double opt-in. Un formulaire public ne doit jamais creer un abonne directement chez le prestataire (Infomaniak, Brevo, MailChimp) : il enregistre une demande, le prestataire n'est appele qu'apres validation du lien de confirmation. Passer par la Nanoxi Newsletter API (https://newsletter-opt-in.spektrum.media, repo newsletter-opt-in), qui gere l'attente, le mail de confirmation et l'ecriture finale.
  • Un formulaire public ne choisit jamais sa cible. Liste, groupe, domaine et cles API se resolvent cote serveur (host de la requete + config). Tout parametre de ciblage lu dans la requete est une faille : l'appelant choisit sa liste.
  • Un endpoint d'inscription est un endpoint d'envoi de mail. Il exige donc au minimum : antiforgery, validation d'adresse, honeypot, limitation de debit par IP et par adresse, et un log IP/UA/email des demandes acceptees et refusees. Sans cela, le double opt-in aggrave le probleme au lieu de le resoudre (le site devient relais de mails vers des tiers).
  • Historique : ces regles viennent d'un flood constate en aout 2026 sur www.icogne.ch et www.l-info.ch (liste passee de ~300 a >1000 abonnes, plaintes de spam). L'endpoint accmpd etait public, sans antiforgery ni validation, en simple opt-in, avec la liste cible choisie par un champ cache du formulaire, et sans aucun log d'inscription.

Specificites client (exemples) ​

  • IEDS : restrictions de mix de catalogues, methodes de livraison custom, synchros planifiees ; un redemarrage de pool + website resout la plupart des erreurs de synchro.
  • CMVEO : les primes d'assurance changent par annee ; dupliquer PremiumData._20xx et mettre a jour EnvironmentalTaxManager.cs + nanoxiSettings.config (champ releaseNewPrimesDate).

Detail : ../modules/customer-skins.md.

Contributors

No contributors

Changelog

No recent changes