Din versiunea API 2026-10, Shopify elimină câmpul static session.currentSession.staffMemberId din POS UI Extensions. Citirile se înlocuiesc cu session.staffMember.value?.id, iar reacția la schimbarea angajatului se face prin subscribe sau la render în Preact. Extensiile pe 2026-07 și mai vechi rămân neafectate. BaseData rămâne separat și neschimbat.

Asta este anunțul care contează dacă ai o extensie de POS în producție. Nu e o schimbare de marketing, nu e o funcție nouă de vândut. E o curățenie de API care îți poate rupe build-ul dacă o ignori. Cine lucrează cu POS UI Extensions știe deja că versiunile de API la Shopify nu sunt opționale pe termen lung. Le țintești, le migrezi, le lași în urmă. Sursa: Shopify Changelog.

Ce s-a schimbat, exact, și de ce

Câmpul session.currentSession.staffMemberId era o valoare statică. Îl citeai și primeai ID-ul angajatului activ la momentul respectiv. Problema e că POS-ul nu funcționează așa. Colegii se schimbă la casă, unul pinează, altul iese, tura se schimbă la mijlocul zilei. O valoare statică nu reflectă nimic din asta în timp real. Shopify a depreciat câmpul în 2026-07 și l-a înlocuit cu session.staffMember, un semnal reactiv care se actualizează când un alt angajat se pinează în POS. Acum, în 2026-10, câmpul vechi dispare complet.

Trei lucruri concrete de reținut:

  1. Citirile se rescriu ca session.staffMember.value?.id.
  2. Pentru reacție în timp real, te abonezi cu session.staffMember.subscribe((staffMember) => { ... }).
  3. Într-o componentă Preact, citești .value la render, cu @shopify/ui-extensions/preact importat, și re-render-ul vine automat.

Extensiile pe 2026-07 și mai vechi nu sunt afectate. Iar BaseData session.staffMemberId, cel disponibil pentru receipt targets, e un API separat și rămâne neschimbat. Asta e o distincție pe care mulți o ratează la citirea rapidă a changelog-ului și ajung să "repare" ceva ce nu e stricat.

Diferența dintre static și reactiv, pe scurt

Un câmp static e o fotografie. Îl citești o dată și aia e valoarea până reîncarci. Un semnal reactiv e un flux. Se schimbă când se schimbă realitatea, iar tu te abonezi la el. În practică, asta contează pentru orice extensie care afișează ceva legat de angajatul activ: comisioane, atribuire de vânzări pe persoană, permisiuni condiționate de rol, log-uri de audit, dashboard-uri de tură.

Dacă extensia ta doar citea ID-ul la inițializare și nu se actualiza niciodată, ai trăit cu un bug silențios. Pe 2026-10 nu mai ai opțiunea să trăiești cu el. Trebuie să decizi: fie citești .value la momentul de care ai nevoie, fie te abonezi și reacționezi.

Ce înseamnă pentru tine, antreprenor sau marketer român cu magazin pe Shopify

Să fim direcți. Majoritatea antreprenorilor români care vând pe Shopify nu au scris ei extensia de POS. Au cumpărat-o, au instalat-o sau au plătit un dezvoltator. Deci întrebarea reală nu e "cum rescriu codul", ci "cine îmi răspunde când se rupe".

Dacă ai un magazin fizic cu POS Shopify și o extensie custom care leagă casa de atribuirea vânzărilor pe vânzător, de rapoarte de tură sau de comisioane, schimbarea asta te privește direct. Nu pentru că pierzi bani azi, ci pentru că migrarea de versiune API e o decizie pe care o amâni până când te lovește.

Ce ai de făcut, în ordine:

Primul pas, inventarul. Ce extensii de POS rulezi, pe ce versiune de API sunt țintite și cine le-a făcut. Dacă răspunsul e "nu știu", acesta e momentul să afli. Nu e o verificare tehnică complicată, e o listă.

Al doilea pas, întrebarea către furnizor sau dezvoltator: "extensia citește session.currentSession.staffMemberId și pe ce versiune API e țintită?". Dacă răspunsul e da și 2026-10, ai o problemă de rezolvat. Dacă e da și 2026-07 sau mai vechi, ai timp, dar ai și o datorie tehnică.

Al treilea pas, testarea. Orice migrare de API se testează pe un magazin de test sau într-un flow controlat, nu direct în producție în mijlocul sezonului. Aici greșesc mulți: schimbă versiunea API și validează pe vânzări reale.

Un detaliu important de transparență: nu avem date despre câte magazine din România folosesc extensii custom de POS care ating acest câmp. Nu inventăm cifre. Dar dacă ești în categoria celor cu POS Shopify și extensii proprii, ai de verificat. Dacă nu ești, nu ai ce face și poți trece mai departe.

Cum se leagă de restul stack-ului tău Shopify

Această schimbare nu vine singură. Shopify mișcă constant limite și suprafețe de API. Recent, limita de 64 KB pentru bundle-ul extensiilor UI a forțat echipele să slăbească ce livrează în extensii. Acum, un câmp din Session API dispare. Direcția e clară: extensiile devin mai reactive, mai mici și mai strict versionate.

Dacă lucrezi cu date de catalog și feed-uri, filtrarea după tip de media în Catalog API e încă un punct de verificat în același val de schimbări. Iar dacă vinzi și prin Google, Google agentic commerce merită citit în paralel, pentru că feed-ul tău de produse depinde de cât de curat e catalogul din spate.

Ideea de fond: un magazin Shopify care scalează nu se mai administrează din interfață. Se administrează din integrări. Iar integrările au versiuni, deprecați și termene. Cine tratează asta ca pe o problemă de IT o face greșit. E o problemă de operare comercială, pentru că atunci când extensia de POS cade, vânzătorul nu mai vede comisionul corect și raportul de tură minte.

Ce verifici concret, în ordine

Lista de verificare pe care o propunem, ca recomandare a noastră, nu ca fapt din sursă:

  1. Identifică fiecare extensie de POS activă în magazinul tău.
  2. Notează versiunea de API țintită pentru fiecare.
  3. Caută în cod citiri ale session.currentSession.staffMemberId.
  4. Confirmă dacă extensia are nevoie de reacție în timp real sau doar de o citire punctuală.
  5. Alege între .value?.id pentru citire simplă și subscribe pentru reacție continuă.
  6. Testează schimbarea de tură și pinearea unui alt angajat, nu doar încărcarea paginii.
  7. Verifică separat că BaseData session.staffMemberId pentru receipt targets rămâne neatins, ca să nu modifici ce nu trebuie.

Punctul 6 e cel pe care îl sar echipele. Un test care nu schimbă angajatul activ nu validează un semnal reactiv. Dacă abonarea nu se declanșează, nu ai testat nimic.

Limite și scenarii ipotetice

Ipotetic, dacă ai o extensie care calculează comisionul vânzătorului la finalul vânzării și citea ID-ul static la încărcare, iar la tine la casă se schimbă oamenii des, ai putea avea atribuiri greșite pe ture, fără să știi. Nu afirmăm că se întâmplă. Semnalăm doar că un câmp static nu poate reflecta o schimbare care are loc după citire. Dacă vrei să știi dacă se întâmplă la tine, se măsoară: compari log-urile de tură cu vânzările atribuite.

Al doilea scenariu ipotetic: dacă folosești Preact și citești .value în render fără să te abonezi, re-render-ul automat te poate scăpa de subscribe în multe cazuri. Dar dacă logica ta rulează în afara ciclului de render, ai nevoie de abonare explicită. Decizia depinde de arhitectură, nu de preferință.

Al treilea: dacă extensia e întreținută de un terț și nu ai acces la cod, nu poți verifica singur. Atunci nu ai o problemă tehnică, ai o problemă de contract și de SLA. Întreabă, în scris. Nu presupune că furnizorul a văzut changelog-ul.

Aici e locul unde se vede diferența dintre un audit automat și o verificare reală. Un scanner care caută un string în cod poate raporta "găsit" sau "negăsit". Dar absența string-ului nu dovedește că extensia e sigură, și prezența lui nu dovedește că ești în pericol, atâta timp cât versiunea API țintită e 2026-07 sau mai veche. Concluziile se trag după ce te uiți la versiune, la flux și la comportamentul real, nu după un grep.

FAQ

Se rupe magazinul meu pe 2026-10 dacă nu fac nimic? Doar dacă o extensie de POS este țintită pe versiunea 2026-10 și citește câmpul eliminat. Extensiile pe 2026-07 și mai vechi rămân neafectate. Verifică versiunea țintită înainte de a trage concluzii.

BaseData session.staffMemberId este afectat? Nu. Potrivit sursei, este un API separat, disponibil pentru receipt targets, și rămâne neschimbat. Nu îl confunda cu câmpul eliminat din Session API.

Trebuie să folosesc neapărat subscribe? Nu neapărat. Dacă ai nevoie de o citire punctuală, session.staffMember.value?.id este suficient. Abonarea are sens când vrei să reacționezi la schimbarea angajatului cât timp extensia rulează.

Concluzia noastră

AI-ul te ajută să citești rapid un changelog, să identifici unde apare un câmp în cod și să schițezi un plan de migrare. Dar decizia despre ce versiune de API țintești, ce test faci și când muți în producție rămâne a unui om care înțelege fluxul din magazin, adică media buyer-ul sau operatorul care răspunde de rezultat. Un tool nu își asumă că raportul de tură e corect.

Pasul concret îl face ALLSoft Agency: inventar de integrări, verificare de versiuni API și un plan de migrare testat pe flux real, fără hype și fără cifre inventate.