SFB Toolkit v1.8.6 — coloana Masurare fara pictograma-rezumat

Scoasa pictograma din fata lui G:/F:. Era doar suma celorlalte doua si facea randul sa para ca are trei verdicte. Restul randului ramane neschimbat.

SFB Toolkit v1.8.5 — verdictul Meta: drumul de server se verifica primul

Comanda #32142 (22 august, 849 lei) era raportata „lipsa din Facebook" desi Meta o primise.

Cauza: in regula care judeca fiecare comanda, intrebarea „pixelul a trimis alte evenimente, dar nu vanzarea?" se punea INAINTEA intrebarii „a trecut prin releul de server?", si nu se mai cadea mai departe. Asa ca o comanda unde pixelul a fost activ, dar vanzarea a plecat prin gateway/releu, era declarata lipsa. Comparatie din acelasi raport: #32141, cu dovezi de server identice (4 releu + 4 gateway) dar pixel complet tacut, primea corect „doar server".

Verificat pe date reale, nu dedus:

• A/B intre regula veche si cea noua pe 10 comenzi cu marcaj: se schimba exact 1 verdict — al lui #32142, din „NU" in „doar server". Nimic altceva nu se misca.
• Meta confirma independent: in ora comenzii au intrat 3 evenimente Purchase, iar din cronologia rapoartelor rezulta ca nicio alta pagina de multumire nu a raportat activitate in acel interval.

Formulare corectata. Nu mai spunem „pixelul din browser blocat":

• unde Gateway-ul Meta e activ, evenimentul de browser pleaca spre *.on.aws, nu spre facebook.com/tr, iar Meta il contorizeaza tot ca „browser" (corelatie 5/5 pe orele din 22 august). Pixelul e functional — doar marcajul nostru nu-l poate citi pe drumul acela;
• fb_tr_purchase = 0 NU mai e tratat ca dovada ca pixelul a tacut;
• textul distinge acum gateway de releu si arata cate cereri catre facebook.com/tr s-au vazut.

⚠️ Contoarele de releu/gateway numara CERERI, nu evenimente de vanzare — de aceea eticheta ramane „doar server", nu „DA".

SFB Toolkit v1.8.4 — separare vizuala cookie-uri in coloana Masurare

In lista de comenzi WooCommerce, coloana Masurare afisa consimtamantul la cookie-uri lipit de bifa Facebook: F:✅ REFUZATE se citea ca „cookie-uri acceptate".

Datele erau corecte — verificate 1 la 1 pe toate comenzile cu marcaj de pe special-plus. Problema era doar de citire.

Ce se schimba (doar afisare):

• consimtamantul sta acum separat, dupa o linie verticala, marcat cu 🍪 si colorat: verde acceptate, rosu REFUZATE, portocaliu partial, gri necunoscut;
• partial (publicitate da, terti nu) se scurteaza la partial in coloana; textul intreg ramane in tooltip si in caseta de pe comanda;
• tooltip-ul primeste etichete explicite: Google: … | Facebook: … | cookie-uri: …;
• in caseta de pe comanda, randul Cookie-uri primeste aceeasi culoare si pictograma, iar legenda spune ca bifele ✅/⚠️/❌ sunt ale Google si Facebook, nu ale consimtamantului.

Logica de determinare a consimtamantului si datele salvate pe comenzi raman neschimbate.

SFB Toolkit v1.8.3 — consimtamantul din primul raport

1.8.3 — consimtamantul din primul raport

Caseta „Masurare” si raportul zilnic iau alegerea la cookie-uri din PRIMUL raport (momentul cumpararii). O reincarcare ulterioara a paginii de multumire (de catre admin sau de catre noi) nu mai rescrie alegerea cumparatorului.

SFB Toolkit v1.8.2 — Tracking Health: pixel Facebook prin formular + caseta in admin

1.8.2 — Tracking Health: pixelul Facebook prins corect + afisare in admin

• fbevents.js trimite Purchase catre facebook.com/tr ca POST de formular intr-un iframe ascuns (cand datele de potrivire nu incap in adresa) — invizibil pentru fetch/XHR/sendBeacon/Resource Timing. 1.8.1 raporta fals „doar server”. Acum observatorul prinde si HTMLFormElement.submit + iframe/img adaugate in DOM.
• Buffer Resource Timing marit la 2000 (pagini grele).
• Caseta „Masurare (marcaj tehnic Safebiz)” in ecranul comenzii WooCommerce + coloana „Masurare” in lista de comenzi (HPOS si clasic), in romana, doar citire.

Modulul ramane OPRIT implicit (bifa per site).

SFB Toolkit v1.8.1 — Tracking Health (marcaj tehnic pe comanda, OPRIT implicit)

1.8.1 — Tracking Health OPRIT implicit

Modulul Tracking Health din 1.8.0 se activează acum per site, din Setări → SFB Toolkit → bifa „Tracking Health (marcaj pe comandă)". 1.8.0 îl pornea pe orice site care se actualiza automat (release retras).

1.8.0 — NOU: modul Tracking Health (marcaj tehnic pe comandă)

Marcaj tehnic pe fiecare comandă WooCommerce, scris din browserul cumpărătorului pe pagina de mulțumire: GTM încărcat? purchase în dataLayer? cerere GA4 cu purchase (sendBeacon)? conversie Ads? pixel Meta cu Purchase? releu PixelYourSite? Conversions API Gateway? erori JS? ce a ales la cookie-uri (Moove / WP Consent API / SureCookie)? Plus numărătoarea randărilor în PHP, independentă de JS.

• Observator în <head> (prio 0, înaintea oricărui tracker) — înfășoară navigator.sendBeacon, fetch, XMLHttpRequest.open; citește Resource Timing.
• Raport la T+3s, T+8s și la părăsirea paginii: POST /wp-json/sfb/v1/tracking-health, autorizat cu HMAC derivat din cheia comenzii.
• Meta _sfb_tracking_health (JSON, doar bool/int) + _sfb_th_renders. Citire admin: GET /sfb/v1/tracking-health?order_id=.
• Oprire de urgență SFB_TRACKING_HEALTH_DISABLE. Nimic trimis către terți; fără date personale în marcaj.

Testat cap-coadă pe safehost.safebiz.ro (#3542 consimțământ acceptat + trackere simulate, #3543 cookie Moove refuzat). Consumator: wat/tools/purchase-truth.js ⇒ verdicte „dovedit".

SFB Toolkit v1.7.6 — Order Received Alias (+ 1.6.0 și 1.7.0-1.7.5)

Primul release după v1.5.9 — aduce tot ce s-a acumulat între timp: v1.6.0 (comis, dar netaguit) și v1.7.0–1.7.5 (rulate deja în producție pe o parte din flotă, dar niciodată comise).

1.7.6 — NOU: modul Order Received Alias

Punte peste gateway-urile de plată care hardcodează endpointul englez order-received în adresa de întoarcere, pe site-uri unde woocommerce_checkout_order_received_endpoint e tradus (ex. comanda-primita).

Fără el, cumpărătorul e trimis înapoi de la procesator pe o adresă care dă 404:

1. nu vede confirmarea comenzii și nici numărul ei — imediat după ce a plătit;
2. evenimentul Purchase nu se declanșează niciodată, nici pentru Meta, nici pentru GA4/Ads, fiindcă ambele stau pe pagina de mulțumire.

Caz măsurat cu fusion-pay-ro-tbi v3.0: 100% din comenzile prin acel gateway au rămas fără eveniment pe o fereastră de 30 de zile. Bugul e prezent pe toate căile de cumpărare (checkout, coș, pagină de produs), deci trecerea pe pop-up nu îl ocolește.

Cum funcționează: un cârlig pe template_redirect (prioritate 1, înaintea redirect_canonical), 302 către adresa construită de WC_Order::get_checkout_order_received_url().

Siguranță:

• no-op dacă endpointul site-ului e deja order-received — nu face nimic pe site-urile fără problema asta;
• acționează exclusiv pe adrese care altfel ar da 404 — nu schimbă nicio adresă existentă;
• verifică cheia comenzii cu hash_equals înainte de redirect, altfel ar deveni cale de enumerare a comenzilor;
• 302, nu 301 — puntea nu rămâne memorată în browsere după ce vendorul repară bugul;
• oprire de urgență: define( 'SFB_ORDER_RECEIVED_ALIAS_DISABLE', true ); în wp-config.php.

Incluse și versiunile 1.7.0–1.7.5 (WPML + SureRank)

1.7.5	masterc/v1/wpml-set-terms — pune categoriile pe o traducere, în perechea de termen din limba postului (WPML remapează ID-urile de termen după limbă, la citire și la scriere)
1.7.4	aceiași pași aplicați și termenilor
1.7.3	SEO-T6: repară hreflang-ul din sitemapul SureRank — două defecte upstream, prezente identic în 1.9.3 și 1.10.0
1.7.2	wpml-map-urls acceptă și attachment_ids (traducerile moșteneau imaginile cu textul din limba sursei)
1.7.1	masterc/v1/wpml-map-urls — echivalentul linkurilor interne în limba țintă
1.7.0	masterc/v1/wpml-link — leagă o traducere de original (translation_of prin REST nu leagă nimic)
1.6.0	modul URL Bases — paritate Rank Math la migrarea spre SureRank

Impact la actualizare

Toate modulele noi sunt inerte pe site-urile care nu le folosesc:

• bifele URL Bases sunt oprite implicit — nu se schimbă nicio adresă;
• filtrul de hreflang iese imediat la ! defined( 'ICL_SITEPRESS_VERSION' ) — inactiv fără WPML;
• rutele WPML se înregistrează, dar sunt inerte cât timp nu le cheamă nimeni;
• modulul nou de redirect e no-op pe site-urile cu endpoint netradus.

---

Notă (2026-08-20), ca să prevină o confuzie: pe site-ul public tbibank.ro e oferit un modul WooCommerce cu versiunea 3.4.2, care într-adevăr nu are acest bug. Nu este însă o versiune mai nouă a aceluiași plugin — e o integrare diferită: slug tbicreditro („tbi bank RO", autor Ilko Ivanov, 17 fișiere, alt flux de întoarcere), față de fusion-pay-ro-tbi („Fusion Pay by tbi bank", 58 fișiere), care e cel afectat. Numerele de versiune nu sunt comparabile între ele, iar trecerea de la unul la celălalt ar însemna schimbarea gateway-ului, nu o actualizare.

SFB Toolkit v1.5.9 — /masterc/v1/performance + REST hardening

NOU: GET /masterc/v1/performance (read-only, manage_options) — diagnostice backend pentru auditul lunar: autoload bloat, object cache persistent, transients, sănătate cron, igienă DB, flag-uri debug. Metodologie: skill oficial wp-performance (P1.6).

REST hardening (P0.3): args schema cu validate/sanitize pe /option, /options-list, /write-lang-file; fix $_GET direct în callback; headers License URI/Update URI/Text Domain.

PHPStan level 5: autoload 'no'→false (×3, incl. opțiunea secretului HMAC), cod mort eliminat. Gate static pre-deploy activ.

Conține integral v1.5.8 (rankmath-redirect).

SFB Toolkit v1.5.8 — /masterc/v1/rankmath-redirect (F6)

Endpoint nou: POST /masterc/v1/rankmath-redirect

Paritate F6 cu SureRank /redirection pentru site-urile RankMath fără SSH.

Inserează un redirect 301 determinist în wp_rank_math_redirections prin clasa oficială RankMath\Redirections\DB::add (serializare corectă a sources, 301 servit imediat fără flush). Idempotent — nu dublează un pattern exact existent. Auth: current_user_can(manage_options) (Application Password, fără nonce).

Body: { "from": "/old-slug/", "to": "/target/", "header_code": 301 }

Validat live pe monitorstup (apply end-to-end via wat/tools/fix-404-redirect.js: old=301, target=200; idempotency POST#1 created, POST#2 skip).

Pur aditiv — niciun endpoint/ comportament existent neschimbat.

SFB Toolkit v1.5.7

Fix: login_page_exposed hardening no longer conflicts with WPS Hide Login. The defined('WPS_HIDE_LOGIN_VERSION') guard is now evaluated at runtime (init) instead of include-time, so the custom login slug (e.g. /beleppo) is no longer redirected to home when WPS Hide Login is active. Includes consolidated 1.5.2-1.5.6 changes (article tracker, settings page, write-lang-file, security headers + hardening module).