Shopify CLI 4.8: magazine dev create și șterse din terminal

Shopify CLI 4.8 introduce comenzi dedicate pentru magazinele de dezvoltare: shopify store create dev, shopify store list, shopify store info și shopify store delete, disponibile după actualizare. Se adaugă și o limită de 250 de magazine dev per organizație din Dev Dashboard, care nu se aplică magazinelor transferate către clienți sau colaboratorilor, conform changelog-ului Shopify.

Ce s-a schimbat, concret

Până acum, crearea unui magazin de dezvoltare însemna, de regulă, navigare prin dashboard, câmpuri completate manual și liste greu de urmărit când lucrezi în paralel la mai multe aplicații sau teme. Noua versiune mută o parte din administrare în CLI, acolo unde lucrează deja echipele tehnice.

Pe scurt, ce acoperă comenzile:

• shopify store create dev creează un magazin dev în organizația din Dev Dashboard, pentru testarea de aplicații, teme și funcționalități Shopify.
• shopify store delete șterge un magazin dev, dar numai când comanda este rulată de un proprietar de magazin, proprietar de organizație sau administrator de organizație.
• shopify store list afișează magazinele dintr-o organizație.
• shopify store info returnează detalii despre un magazin anume.

Partea interesantă nu e neapărat comanda în sine, ci combinația cu Admin API și suportul de bulk operations deja existent. Aici se deschide scenariul de automatizare: creezi un mediu, îl populezi cu date, îl resetezi și îl recreezi la nevoie, fără intervenție manuală. Este infrastructură de test tratată ca infrastructură, nu ca o colecție de sandbox-uri împrăștiate.

Limita de 250 de magazine dev și ce se întâmplă cu organizațiile mari

A doua schimbare importantă este plafonul: 250 de magazine dev per organizație. Shopify spune explicit că organizațiile care depășesc deja acest număr au primit o limită extinsă, deci nu este o tăiere brutală aplicată retroactiv peste noapte.

Merită citită nuanțat:

• Limita se aplică doar magazinelor dev dintr-o organizație din Dev Dashboard.
• Magazinele transferate către clienți și cele de colaborator nu intră în calcul.
• shopify store delete există tocmai pentru curățenie, iar shopify store list poate fi folosit scriptat pentru a identifica ce e vechi și de șters la scară.

Aici apare o întrebare operațională pe care nimeni nu o rezolvă cu o comandă: cine decide ce magazin e încă folosit? Un sandbox abandonat acum un an poate să fie exact mediul în care un client își testează tema înainte de lansare. Ștergerea scriptată fără criterii clare transformă curățenia în risc. Recomandarea mea, ca proces, nu ca fapt din sursă: înainte de orice cleanup automatizat, definește o convenție de nume și un criteriu de inactivitate. Comanda șterge, dar nu gândește.

Cum arată un flux de lucru rezonabil

Nu vreau să prezint ca testat ceva ce nu am rulat. Ce urmează e un scenariu propus, explicit ipotetic, de verificat în propriul mediu, nu o rețetă dovedită.

Un flux plauzibil, pentru o echipă care lucrează cu teme sau aplicații:

1. Actualizezi la Shopify CLI 4.8 sau mai nou. Fără asta, comenzile nu există.
2. Actualizezi AI Toolkit în agentul de cod, dacă folosești unul, ca să nu ai discrepanțe între ce știe agentul și ce poate CLI-ul.
3. Stabilești o schemă de denumire pentru magazinele dev: client, proiect, data, eventual un identificator de scop.
4. Rulezi shopify store list și analizezi ce ai. Nu ștergi nimic înainte să înțelegi inventarul.
5. Populezi mediul prin Admin API și bulk operations, dacă ai nevoie de date repetabile.
6. Automatizezi ștergerea doar pentru magazinele care respectă criteriul tău de abandon, cu o perioadă de grație.

Pasul 3 este cel pe care majoritatea echipelor îl sar. Fără o convenție de nume, shopify store list îți returnează o listă de string-uri care nu spun nimic, iar automatizarea devine imposibil de auditat.

Ce înseamnă pentru tine, ca antreprenor sau marketer român

Dacă ai un magazin pe Shopify și lucrezi cu o agenție sau cu un dezvoltator, această schimbare te privește indirect, dar real. Marja de eroare în testare scade.

Ce înseamnă, tradus în viața ta:

• Modificări pe temă, aplicații noi, integrări de plată sau de livrare pot fi testate într-un mediu izolat, nu pe magazinul live. Asta reduce riscul de coșuri stricate în plin sezon.
• Dacă vinzi și în afara României, testarea de fluxuri multi-piață, taxe, valute devine mai ușor de repetat.
• Un dezvoltator care îți spune că „nu se poate testa” are acum mai puține scuze tehnice.
• Viteza de livrare pentru lucrări mici crește pentru echipele care automatizează corect, nu pentru cele care doar apasă butoane mai repede.

Ce NU înseamnă: nu îți crește automat conversia, nu îți scade CPA-ul și nu îți rezolvă problemele de feed. Sunt instrumente de dezvoltare, nu de marketing. Confuzia asta costă. Am văzut prea des echipe care confundă „avem mediu de test” cu „testăm campanii”.

Pentru partea de vizibilitate, există o legătură indirectă pe care merită să o ai în minte. Dacă lucrezi cu URL-uri, variante de produs și pagini duplicate, mediul de dezvoltare este locul în care testezi structura, nu producția. Despre de ce contează URL-urile clare am scris în analiza despre vizibilitatea în AI și lecția Bing despre duplicate. Iar pentru momentele în care schimbi componente de interfață înainte de un sezon, contextul din Shopify Polaris CDN și versionarea semantică e util, pentru că aceeași logică de „ce alegi pentru producție” se aplică și la mediile de test.

Ce verifici înainte să automatizezi

Aici e partea pe care o recomand, nu o constatare din sursă. Tratează lista ca pe o listă de verificat, nu ca pe niște certitudini.

• Cine are drepturi de ștergere în organizație? Comanda merge doar pentru anumite roluri. Dacă nu e clar cine e administrator, automatizarea se blochează sau, mai rău, rulează sub un cont greșit.
• Cât de vechi e „vechi”? Alege o fereastră de inactivitate și documenteaz-o.
• Ce faci cu backup-ul de date de test, dacă ai nevoie de ele după ștergere?
• Cum raportezi ștergerile? O listă de magazine eliminate, cu cine a rulat scriptul și când, îți salvează discuții.
• Organizația ta are deja peste 250 de magazine dev? Dacă da, sursa spune că există o limită extinsă acordată, dar nu presupune că e permanentă. Verifică situația.

O verificare incompletă nu dovedește că ceva nu funcționează. Dacă nu ai testat dacă shopify store delete respectă exact rolurile din organizația ta, nu concluziona că e blocat. Testează, apoi trage concluzia.

FAQ

Pot folosi aceste comenzi fără să actualizez CLI-ul? Nu. Comenzile shopify store create dev, list, info și delete sunt disponibile după actualizarea la Shopify CLI 4.8 sau mai nou, potrivit changelog-ului Shopify.

Limita de 250 se aplică și magazinelor clienților? Nu. Limita vizează doar magazinele dev dintr-o organizație din Dev Dashboard. Magazinele transferate către clienți și cele de colaborator nu sunt contorizate.

Ce fac dacă organizația mea are deja mai mult de 250 de magazine dev? Conform sursei, organizațiile care depășesc deja acest număr au primit o limită extinsă. Nu trata asta ca pe o garanție pe termen lung și inventariază ce ai cu shopify store list.

Concluzia ALLSoft Agency

AI-ul ajută real aici, la analiza inventarului de medii, la generarea scripturilor de curățenie și la planificarea fluxurilor de test. Dar decizia despre ce magazin se șterge și de ce rămâne a omului, adică a media buyer-ului și a omului tehnic care răspunde de proiect. O comandă nu știe care sandbox susține un test de sezon și care e praf.

Pasul concret îl face ALLSoft Agency: punem la punct procesul, nu doar comanda. Dacă vinzi pe Shopify și vrei să separi clar testul de producție, fără hype și fără să strici ce funcționează, hai să vorbim.

Notă editorială: articol adăugat retrospectiv la 2026-09-12, în ediția din 2026-09-09. Data ediției nu reprezintă data lansării anunțului.