Zakaj sinhronizacija podvaja slike artiklov in kako to pravilno preprečiti
Predstavnost v WooCommercu se polni sama, imena datotek se nizajo z -1, -2, -3 in disk se polni. Zakaj REST vmesnik ob vsaki sinhronizaciji naloži novo priponko in kaj mora preverba znati, da se slika poveže, ne podvoji.
Simptom: predstavnost se polni sama
Trgovina ima tri tisoč artiklov in pet tisoč slik. V predstavnosti jih je trideset tisoč. Imena se ponavljajo: izdelek.jpg, izdelek-1.jpg, izdelek-2.jpg, izdelek-3.jpg. Avtor vseh je uporabnik, ki je nekoč vpisal podatke za povezavo z zalednim sistemom.
Datum nalaganja je vsak dan, pri pogostejši sinhronizaciji vsako uro. Slike izgledajo enako, ker so enake. Galerija artikla kaže eno sliko, strežnik hrani štiriindvajset kopij na dan.
To ni napaka WordPressa in ni napaka strežnika. Je posledica tega, kako REST vmesnik razume polje images, in te posledice ne odpravi noben vtičnik za čiščenje. Čiščenje odpravi nakopičeno; vzrok ostane in jutri naloži novo serijo.
Zakaj se slike nalagajo in ne samo povežejo
Ko zaledni sistem prek REST vmesnika pošlje artikel s poljem images, v katerem je vnos s ključem src in brez ključa id, WooCommerce tega vnosa ne razume kot povezavo na obstoječo sliko. Razume ga kot navodilo: prenesi datoteko s tega naslova in jo dodaj v predstavnost.
Posledica je nova priponka. Nova številka, nov zapis v bazi, nova datoteka na disku, nove izpeljane velikosti. Pri vsaki sinhronizaciji znova, ker vnos s src in brez id pomeni vedno isto.
Z vidika WooCommerca je to pravilno vedenje. Vmesnik nima načina, da bi uganil, katero obstoječo priponko ste mislili, in zato naredi to, kar ste napisali. Napačna je predpostavka pošiljatelja, da bo prejemnik sliko prepoznal.
Cena za strežnik je sorazmerna s pogostostjo sinhronizacije, ne z velikostjo kataloga. Trgovina s petsto artikli in urno sinhronizacijo naredi več datotek kot trgovina s petimi tisoč artikli in dnevno.
Zakaj se imena nizajo z -1, -2, -3
WordPress ne dovoli dveh datotek z istim imenom v isti mapi. Ko naložena datoteka naleti na obstoječe ime, funkcija za edinstveno ime pripne števec: izdelek-1.jpg, nato izdelek-2.jpg.
Prav ta števec naredi težavo nevidno. V galeriji artikla je ena slika, ker galerija kaže zadnjo. V predstavnosti jih je toliko, kolikor je bilo sinhronizacij. Niz z vezajem in naraščajočo številko nad isto osnovo imena je zato najbolj zanesljiv znak, da nekaj nalaga slike programsko in brez preverbe.
Števec pomeni tudi, da primerjava po točnem imenu datoteke ne zadošča. Preverba mora prepoznati, da je izdelek-7.jpg ista slika kot izdelek.jpg, drugače bo ob osmi sinhronizaciji naložila še eno.
Pozor tudi na izpeljane velikosti. Poleg izvirnika WordPress zapiše datoteke z dimenzijami v imenu, na primer -300x300. Te niso podvojitve in se ne smejo obravnavati kot kopije.
Kaj se zgodi, ko slike v zahtevi izpustite
Druga past je nasprotna in dražja. Polje images, ki ga pošljete, galerijo ZAMENJA. Ne dopolni je.
Če artikel v trgovini ima pet slik in pošljete eno, bo imel eno. Če pošljete prazno polje, bo brez slik. Zato odgovor na podvajanje ni, da slike preprosto nehate pošiljati; to iz galerij odnese tudi tisto, kar je urednik dodal ročno.
Pravilen odgovor je, da pošljete celotno galerijo, v kateri so obstoječe slike navedene z id in brez src, nove pa s src. Vnos z id in brez src obstoječo priponko samo poveže in ne naloži ničesar.
Posledica tega pravila je, da mora pošiljatelj poznati stanje galerije v trgovini, preden jo pošlje. Sinhronizacija, ki samo piše in nikoli ne bere, tega ne more narediti pravilno.
Shopify se vede enako, z drugimi besedami
Shopify ima drugačno poimenovanje in isto logiko. Posodobitev izdelka, ki vsebuje polje slik, nabor slik zamenja. Vnos s src in brez id ustvari novo sliko.
Razlika je v tem, da Shopify izvirnik hrani na svojem omrežju za dostavo vsebin in ne v mapi, ki jo vidite prek protokola za prenos datotek. Zato se težava ne pokaže kot polna diskovna particija, ampak kot naraščajoče število slik na izdelku in počasnejše nalaganje strani izdelka.
Ker je logika ista, mora biti ista tudi preverba. Trgovini, ki ima oba kanala, se ne izplača pisati dveh rešitev. Smiselna je ena preverba, ki vrne isti odgovor za obe platformi, in dva tanka prevajalnika v obliko, ki jo posamezni vmesnik pričakuje.
Kako ločiti sinhronizacijo od ročnega urejanja
Preden krivite sinhronizacijo, preverite. Trije pokazatelji so dovolj in vse tri vidite v predstavnosti.
Avtor. Priponke, ki jih je naredila sinhronizacija, imajo za avtorja uporabnika, s čigar podatki je bila povezava postavljena. Pri ročnem nalaganju je avtor tisti, ki je datoteko naložil.
Ritem. Časi nalaganja v enakomernih presledkih, na primer vsako uro ob isti minuti, so stroj. Človek ne nalaga ob 3.00, 4.00 in 5.00.
Ime. Niz z vezajem in naraščajočo številko nad isto osnovo imena je programsko nalaganje. Urednik, ki sliko zamenja, datoteko običajno poimenuje drugače.
Če se vsi trije pokazatelji ujemajo, vzrok ni pri uredniku in čiščenje predstavnosti ni rešitev.
Kako je preverba narejena pravilno
Preverba mora odgovoriti na eno vprašanje: ali v predstavnosti že obstaja priponka za to sliko. Zanesljiv odgovor je mogoč brez primerjave vsebine datotek.
Osnova je ime datoteke iz naslova slike, normalizirano enako, kot ga normalizira WordPress ob nalaganju: brez končnice, brez diakritike, male črke, ločila zamenjana z vezajem. Normalizirani ključ je tisto, kar se primerja.
Nato se odstrani sled podvajanja: zaporedni števec na koncu imena. izdelek-7 in izdelek sta isti ključ, izdelek-7-sivi in izdelek pa nista.
Kadar preverba najde obstoječo priponko, vnos v galeriji nosi njen id in nima src. Kadar ne najde nobene, vnos nosi src in nova priponka nastane enkrat, ne vsako uro.
Celotna galerija se sestavi pred pošiljanjem, ker polje images nabor zamenja. Ročno dodane slike se tako ohranijo, obstoječe se samo povežejo, nova datoteka pa nastane samo takrat, ko je slika res nova.
Tri pasti pri primerjavi imen datotek
Prva je normalizacija. WordPress ob nalaganju ime očisti: odstrani diakritiko in posebne znake. Slika Čevlji Rjavi.jpg v predstavnosti ni Čevlji Rjavi.jpg. Primerjava z neobdelanim imenom iz naslova zato ne najde ničesar in naloži novo datoteko.
Druga so izpeljane velikosti. Poleg izvirnika obstajajo datoteke z dimenzijami v imenu. Te niso kandidati za ujemanje in preverba jih ne sme ponuditi kot obstoječo sliko artikla.
Tretja je zamenjava končnice. Vtičniki za stiskanje slik ob nalaganju ustvarijo različico v novejšem formatu. Osnova imena ostane, končnica se spremeni, zato se primerja osnova brez končnice, ne celotno ime.
In ena past, ki ni vezana na imena: razčlenjevanje naslovov z večbajtnimi znaki. Standardne funkcije za razčlenjevanje naslova in poti niso varne za večbajtne znake, zato naj ključ nastane z izrazi, ki delajo na bajtih, ki so gotovo znotraj nabora ASCII.
Kaj narediti s podvojitvami, ki so že nastale
Popravek vzroka ustavi nastajanje novih, obstoječih ne odstrani. Odstranjevanje je brisanje podatkov, zato ni stvar skripta, ki teče mimogrede.
Postopek, ki se ne konča s praznimi galerijami: najprej naredite varnostno kopijo mape z nalaganji in baze. Nato sestavite seznam priponk, ki ustrezajo vzorcu podvajanja in na katere se ne sklicuje noben artikel, noben zapis o vsebini in nobena galerija. Seznam preglejte, preden karkoli izbrišete.
Brisanje naj gre prek WordPressove funkcije za brisanje priponke, ne z brisanjem datotek v mapi. Brisanje datoteke pusti zapis v bazi in galerija pokaže prazen okvir.
Delajte po serijah in med serijami preverite nekaj artiklov v trgovini. Deset tisoč brisanj v eni transakciji je slaba zamisel tudi takrat, ko je seznam pravilen.
Kako pogosto naj sinhronizacija teče
Pogostost je odločitev o tem, kaj se mora res osvežiti. Zaloga in cena se spremenita večkrat na dan in se morata sinhronizirati pogosto. Slika artikla se spremeni, ko jo nekdo zamenja.
Zato ločite tokove. Pogosta sinhronizacija naj nosi zalogo in ceno. Slike naj gredo samo takrat, ko se je galerija res spremenila, kar sistem ve iz časa zadnje spremembe artikla.
To ni optimizacija zaradi hitrosti. Je zmanjšanje površine za napake: tok, ki slik ne pošilja, jih tudi podvojiti ne more.
Ko slike vendar pošiljate, naj preverba teče vedno in brez možnosti izklopa. Nastavitev, ki preverbo izklopi, je pot do iste polne predstavnosti čez pol leta.
Primerjava
| Vnos v images[] | Kaj naredi WooCommerce | Posledica |
|---|---|---|
| src brez id | prenese datoteko z naslova in ustvari novo priponko | nova slika pri vsaki sinhronizaciji |
| id brez src | poveže obstoječo priponko | nič se ne naloži |
| id z name ali alt | posodobi opis obstoječe priponke | brez nove datoteke |
| en vnos namesto cele galerije | galerijo zamenja s tem enim vnosom | izguba ročno dodanih slik |
| prazno polje [] | izbriše slike artikla | artikel ostane brez slike |
Poglejte, kako Entexia pred vsako sinhronizacijo preveri, ali slika v trgovini že obstaja, in jo poveže namesto podvoji.
Začni brezplačno →