e-commerce

Reglați Drupal Commerce

Java Script vă poate distruge viteza de încărcare

  1. Verificați dacă comportamentele Drupal din tema dvs. sunt făcute corect

Formularul de adăugare în coș este greu

  1. Înlocuiți standardul existent de adăugare în coș cu linkul de adăugare în coș https://www.drupal.org/project/commerce_add_to_cart_link

Ați construit vreodată blocuri sau pagini care conțin liste de produse, cum ar fi pagini de categorie, blocuri de bestselleruri sau blocuri de produse conexe? Ați inclus în acestea formularul de adăugare în coș, pentru a putea adăuga articole direct din pagina de prezentare generală? În prezent, construirea blocurilor de liste de produse este adesea însoțită de unele bătăi de cap din cauza limitărilor existente în Drupal Core, atunci când doriți să includeți formularul. De aceea am scris modulul Drupal Commerce Add To Cart Link. Iată o prezentare generală a limitărilor despre care vorbesc:

Dispariția formelor

Cea mai mare problemă este că formularele Drupal nu vor funcționa atunci când acestea dispar la trimiterea cererii, ca în următorul scenariu:

Doriți să construiți un bloc "produse conexe", care să afișeze până la 4 produse conexe. Să spunem că există 20 de candidați posibili pentru un anumit produs și doriți să alegeți aleatoriu cele 4 produse. Totuși, este posibil să doriți să setați anumite condiții Cache, dar chiar și atunci cele 4 produse afișate sunt supuse schimbării.

Deci, ce se întâmplă, dacă folosiți un formular pentru a afișa butonul de adăugare la coș, iar produsul selectat nu mai este afișat în acea cerere în care ați apăsat butonul "adăugare la coș"? Nimic, pur și simplu nu se întâmplă nimic. Nici un mesaj, nici un avertisment, nici o eroare, dar nici un produs în coș. Acesta este modul în care funcționează API-ul de formulare în Drupal și Commerce nu poate face nimic sau aproape nimic pentru a preveni acest lucru.

Oferirea unui link dedicat "add to cart" în loc de utilizarea Form API previne această problemă.

Vizualizările Ajaxified Views vă deturnează formularele

Ați încercat vreodată să construiți un View cu Ajax activat (de exemplu, pentru paginare infinită) și să listați produsele, inclusiv formularul de adăugare în coș? Veți eșua. Formularele vor funcționa doar la încărcarea inițială a paginii. După ce primul link Ajax din Views a fost apăsat, veți da peste erori 404, deoarece Views a "furat" formularele de la Commerce. Acest lucru este, de fapt, foarte rău, deoarece s-ar putea să supravegheați această defecțiune, dacă mai întâi construiți și testați vizualizările, mai târziu adăugați paginarea Ajax și doar încercați rapid, mai întâi adăugând ceva în coș, apoi faceți o paginare - nu veți vedea asta imediat, probabil.

În mod normal, acum aveți doar două opțiuni: puteți acum fie să dezactivați Ajax pe acea vizualizare, fie să eliminați complet formularul de adăugare la coș din modul de vizualizare teaser și să creați doar un link către pagina de detalii.

Din nou, eliminarea formularului de aici și înlocuirea lui cu un link nu va strica nimic și permite coexistența pașnică a unei vizualizări activate Ajax și a butonului de coș.

Consultați aceste linkuri pentru mai multe informații despre acest subiect:

Afișați numai variația implicită în vizualizarea catalogului

Nu este o problemă, dar este ceva ce va trebui să faceți în mod normal cu modificarea formularului: dacă aveți produse cu mai multe variante, probabil că nu veți dori să aveți selectorul de variante pe paginile de prezentare generală și pe alte liste de produse. Este ușor totuși să ascundeți selectorul, dar trebuie să implementați un hook_form_alter(), ceea ce poate fi o problemă pentru cei care nu sunt dezvoltatori. Utilizând modulul Commerce Add To Cart Link, puteți realiza acest lucru cu o singură configurare de vizualizare a entității.

Prezentarea modulului Commerce Add To Cart Link

Problemele descrise mai sus au fost principala motivație care a stat la baza implementării modulului Commerce Add To Cart Link. Modulul adaugă un pseudo-câmp "add_to_cart_link" (prin intermediul hook_entity_extra_field_info()) atât la entitățile Produs, cât și la cele de Variație a produsului. De ce ambele? Pentru că, din punct de vedere semantic, aparține variației, iar faptul că se află acolo oferă cea mai mare flexibilitate, dar este, de asemenea, mai complicat de configurat corect și aduce o supraîncărcare inutilă pentru cazuri de utilizare foarte simple. Este mai flexibilă, deoarece în cazul produselor cu mai multe variații se tipărește un link pentru fiecare variație în parte. Cu ajutorul preprocesoarelor sau al implementării view alter, se poate decide oricând să se afișeze doar un singur link. Dar, din nou, acest lucru ar necesita ceva codare suplimentară. Mai mult, nu ar apărea în câmpurile de variație injectate în șablonul produsului, astfel încât ar trebui să setați un mod de vizualizare personalizat pentru variații, care să conțină doar câmpul de link și să configurați câmpul de referință pentru variații pentru a reda variația în acel mod de vizualizare -> complexitate inutilă.

Așadar, dacă aveți doar referințe 1:1 la variații sau, oricum, doriți să afișați un singur buton de "adăugare în coș" doar pentru variația implicită, configurarea câmpului în afișarea vizualizării entității Produs este mult mai simplă: trageți câmpul în vizibilitate în afișarea vizualizării produsului dorit și ați terminat! Btw, câmpurile sunt disponibile în mod automat pentru toate pachetele de produse și variante de produse.

Twigs

Pentru a oferi cel mai bun confort și flexibilitate, legătura este redată prin intermediul șablonului Twig, ceea ce vă permite să personalizați cu ușurință aspectul legăturii. Aveți putere Twig completă și puteți extinde și îmbogăți marcajul după cum doriți. Textul linkului face parte, de asemenea, din șablon și, prin urmare, este ușor de schimbat. Folosiți o pictogramă? Nicio problemă, inserați-o în șablonul Twig și gata. Puteți chiar să furnizați șabloane diferite pentru fiecare tip de variație sau ID.

Drupal Commerce Performance
Drupal Commerce