WooCommerce · cerere salvată · stoc revalidatINDISPONIBIL → AȘTEPTAT → DISPONIBIL
Back In Stock Alerts: produsul revine în stoc, clientul revine la produs.
Construim notificări stoc WooCommerce pentru varianta exactă pe care clientul o așteaptă. Magazinul păstrează cererea, iar când ținta poate fi cumpărată din nou, sistemul programează mesajul și oferă o rută directă înapoi la produs.
- Produse simple și variații
- Înscriere cu email și telefon
- Action Scheduler sau WP-Cron
- Preview și control administrativ
Versiunea auditată 1.2.0 programează notificări prin infrastructura WordPress. Acceptarea mesajului de wp_mail nu garantează livrarea în inbox.
Semnalul corect, pentru ținta corectăvariație, cerere, stoc, coadă și mesaj
MODEL CONCEPTUAL- 01Țintă exactăProdus simplu sau variație
- 02Cerere verificatăValidare în interfață și pe server
- 03Stoc revalidatDisponibil și cumpărabil
- 04Operare vizibilăStare, moment și eroare
01 / PRODUS ȘI VARIAȚIESELECTEAZĂ · ÎNSCRIE · AȘTEAPTĂ
Clientul așteaptă varianta aleasă, nu o promisiune generică.
Pentru produsele variabile, formularul apare după selectarea unei combinații fără stoc, iar serverul verifică dacă variația aparține produsului și este încă indisponibilă. Cererea rămâne legată de perechea produs–variație.
Produs simplu
Ținta este identificată prin ID-ul produsului, iar butonul de cumpărare rămâne dezactivat cât timp articolul este fără stoc.
Variație exactă
Combinația selectată este păstrată prin ID-ul produsului părinte și ID-ul variației.
Schimbare coerentă
La o selecție disponibilă, starea și butonul nativ de cumpărare sunt restaurate.
Context vizibil
Modalul afișează eticheta atributelor alese înainte ca solicitarea să fie trimisă.
02 / MOTORUL DE STOC ȘI COADA
Mesajul este programat numai după o verificare de disponibilitate.
Evenimentele WooCommerce pentru produs sau variație pornesc verificarea. Ținta trebuie să fie atât în stoc, cât și cumpărabilă, iar disponibilitatea este verificată din nou chiar înainte de tentativa de trimitere.wp_mail, nu livrarea în inbox.- 01În așteptarecerere pentru o țintă OOS
- 02Revalidatăîn stoc și cumpărabilă
- 03În coadăAction Scheduler sau WP-Cron
- 04Verificată din noustare curentă la execuție
- 05Înregistratătrimis sau eroare
Produs ori variație
Pentru un produs variabil sunt evaluate separat țintele care au cereri în așteptare.
Două mecanisme
Action Scheduler este folosit când există; altfel se programează un eveniment WP-Cron după aproximativ cinci secunde.
Reverificare la execuție
Dacă ținta nu mai poate fi cumpărată, cererea revine din coadă în starea „În așteptare”.
04 / REGISTRU ȘI OPERAȚIUNISTARE · CĂUTARE · INTERVENȚIE
Fiecare cerere are o țintă, o stare și un moment.
Panoul rezumă cererile în așteptare, în coadă, trimise și cu eroare. Lista poate fi filtrată după stare și căutată după email sau telefon, păstrând produsul ori variația alături de momentele operaționale.
- 01Context de produs
Imagine, denumire, eticheta variației și legătură către editare.
- 02Stare lizibilă
În așteptare, în coadă, trimis sau eroare, cu momentul relevant și ultimul mesaj de eroare.
- 03Intervenție punctuală
Ștergere sau retrimitere manuală pentru o cerere pending/error când ținta este disponibilă.
- 04Acces protejat
Acțiunile administrative cer permisiunea WooCommerce și verificarea unui nonce.
05 / RUNTIME LA CEREREBAZĂ MICĂ · SEMNAL OOS · ÎNCĂRCARE
Interfața completă apare numai când există motivul să fie folosită.
Pe un produs variabil obișnuit, pagina primește inițial baza vizuală și un bootstrap. CSS-ul, scriptul complet și fragmentul modal sunt cerute la prima selecție fără stoc. Produsele simple deja epuizate pornesc runtime-ul imediat.
Doar pe produs
Resursele frontend sunt înregistrate numai în contextul paginii de produs WooCommerce.
Stări protejate
Excluderi dedicate păstrează stilurile dinamice pe care scanarea inițială nu le poate observa.
Execuție disponibilă
Scriptul runtime și bootstrap-ul sunt marcate pentru a nu fi amânate de optimizarea JavaScript.
Fundamente de dialog
Roluri ARIA, mesaj live, Escape, revenirea focusului și respectarea preferinței pentru mișcare redusă.
06 / CE LIVRĂM
Un sistem pregătit pentru identitatea și operațiunile magazinului.
Configurăm funcțiile confirmate, eliminăm valorile istorice din build și documentăm dependențele, limitele și pașii de operare.Hartă de disponibilitate
Produse, variații, surse de stoc, hook-uri, cron, temă și infrastructură de email.
PRODUS · STOC · TRANSPORTNeutralizare completă
Eliminăm expeditorul, footerul, destinatarul intern și fallback-urile istorice.
IDENTITATE · DESTINATAR · DATEStatus, CTA și modal
Stări pentru produse simple și variații, formular contextual și revenirea corectă la cumpărare.
OOS · FORM · VARIAȚIEReleu de stoc
Evenimente, coadă, revalidare la execuție și scenarii de eroare ori indisponibilizare.
HOOK · QUEUE · RECHECKȘablon și test
Identitate, conținut, variabile, preview și testare pe serviciul de trimitere real.
BRAND · PREVIEW · SMTPDate și proceduri
Roluri, retenție, ștergere, monitorizare, retry manual și documentație de predare.
PRIVACY · STATUS · HANDOVER07 / COMPATIBILITATE ȘI LIMITE
Notificarea funcționează în ecosistemul complet al magazinului.
Codul cere WooCommerce și declară compatibilitate HPOS, însă stocul, tema, swatch-urile, schedulerul, e-mailul și politica de date trebuie validate împreună.| Suprafață | Ce verificăm | Rezultat urmărit |
|---|---|---|
| WooCommerce | stoc, status și posibilitatea de cumpărare | țintă validă |
| Catalog | produse simple, variații și atribute | înscriere exactă |
| Scheduler | Action Scheduler și WP-Cron | execuție observabilă |
wp_mail, SMTP și autentificarea domeniului | tentativă testată | |
| Temă și cache | formulare, swatch-uri și optimizări frontend | interacțiune stabilă |
| Date personale | informare, acces, retenție și ștergere | politică documentată |
08 / IMPLEMENTARE
De la un produs epuizat de test la un flux monitorizat.
Activăm pe staging, folosim date demonstrative și verificăm fiecare ramură înainte ca mesajele să ajungă la clienți reali.- 01AUDIT
Inventariem ecosistemul
Verificăm tipurile de produs, variațiile, swatch-urile, sursele de stoc, cronul și serviciul de email.
- 02NEUTRALIZARE
Eliminăm valorile istorice
Curățăm identitatea și destinatarii sursă, apoi definim câmpurile și politica de retenție.
- 03CONFIGURARE
Definim formularul și mesajul
Setăm textele, expeditorul, șablonul, variabilele și ruta de trimitere.
- 04STAGING
Testăm toate ramurile
Validăm înscrierea, variația, restock-ul, revalidarea, Action Scheduler, WP-Cron și retrimiterea manuală.
- 05LANSARE
Predăm operarea
Documentăm stările, monitorizarea cozii, erorile, ștergerea datelor și verificările periodice.
10 / ÎNTREBĂRI FRECVENTEÎNAINTE DE IMPLEMENTARE
Ce urmărește modulul și ce trebuie confirmat în magazin.
Cele zece răspunsuri sunt preluate din registrul unic al portofoliului, astfel încât pagina și datele structurate să rămână aliniate.
01Când apare formularul Back In Stock?
Pentru un produs simplu, formularul este disponibil când produsul nu poate fi cumpărat din cauza stocului. Pentru un produs variabil, clientul trebuie să selecteze mai întâi o variație validă și epuizată; interfața nu înregistrează o cerere generică atunci când variația lipsește.
02Ce date solicită formularul verificat?
Versiunea auditată solicită obligatoriu adresa de email și numărul de telefon. Nu colectează cantitatea dorită sau localitatea, chiar dacă aceste câmpuri apar în capturi provenite dintr-o versiune mai veche.
03Notificarea pentru un produs variabil urmărește variația exactă?
Da. Înregistrarea păstrează separat produsul părinte și identificatorul variației selectate, iar serverul verifică dacă variația aparține produsului și este încă epuizată înainte de salvare. Mesajul include atributele variației și conduce către legătura acelei variante.
04Cum sunt tratate înscrierile repetate?
Pentru aceeași adresă de email, același produs și aceeași variație, o înregistrare existentă în starea În așteptare sau În coadă este actualizată în loc să fie duplicată. Formularul folosește și nonce, câmp capcană și o limitare temporară pentru repetarea imediată a cererii.
05Când intră o notificare în coadă?
Pluginul urmărește evenimentele WooCommerce pentru modificarea cantității, a statusului de stoc și actualizarea produselor sau variațiilor. O cerere este programată numai dacă ținta exactă este în stoc și poate fi cumpărată; pentru un produs variabil fără variație salvată este suficient să existe cel puțin o variație cumpărabilă în stoc.
06Disponibilitatea este verificată din nou înainte de trimitere?
Da. Jobul recitește produsul sau variația și cere simultan stare în stoc și posibilitate de cumpărare. Dacă ținta nu mai este disponibilă, înregistrarea revine în starea În așteptare și mesajul nu este trimis în acea execuție.
07Pot personaliza formularul și e-mailul?
Interfața permite configurarea textelor din formular, a expeditorului, logo-ului, subiectului, conținutului, culorilor, lățimii și fontului, plus previzualizare cu modificări nesalvate și trimitere de test cu setările salvate. Build-ul auditat păstrează însă numele expeditorului, unele elemente de footer și texte alternative legate de brandul sursă, deci necesită neutralizare white-label înainte de reutilizare.
08Numărul de telefon este folosit pentru SMS?
Nu. Telefonul este salvat împreună cu cererea și apare în registrul administrativ și în notificarea internă de înscriere, dar codul verificat nu trimite SMS, WhatsApp sau apeluri automate.
09Poate administratorul retrimite sau șterge o notificare?
Da. Registrul poate fi căutat după email sau telefon și filtrat după stările În așteptare, În coadă, Trimis și Eroare. Un rând poate fi șters, iar o cerere aflată în așteptare sau eroare poate fi reprogramată manual numai dacă produsul sau variația este disponibilă în acel moment.
10Cum este trimis e-mailul și ce obligații de confidențialitate rămân?
Mesajul HTML este predat prin wp_mail, folosind Action Scheduler când este disponibil și un eveniment WP-Cron ca rezervă; acceptarea de către wp_mail nu garantează livrarea în inbox. Emailul și telefonul sunt păstrate într-un tabel local, iar build-ul auditat nu include consimțământ bifabil, dezabonare automată sau politică de retenție, astfel că informarea, temeiul legal, ștergerea și perioada de păstrare trebuie stabilite pentru magazinul real.
11 / URMĂTORUL PAS
