Kada radiš sa velikim WooCommerce prodavnicama, vrlo brzo shvatiš jednu stvar: problem nije samo napraviti webshop. Problem je održavati ga čistim, stabilnim i upotrebljivim kada broj proizvoda počne da raste.
Kod malog sajta sa 50 ili 100 proizvoda, ručno uređivanje kataloga još uvek ima smisla. Ali kada katalog poraste na hiljade ili desetine hiljada proizvoda, stvari se menjaju. Tada svaki “mali” problem postaje ozbiljan operativni teret: proizvodi bez slika, proizvodi kojih nema na stanju, proizvodi kojima lager nije dugo ažuriran, i gomila proizvoda koji završe u Trash-u, ali nikada ne budu trajno obrisani.
Upravo iz tog problema je nastao moj dodatak: Geos – Product Cleanup Manager for WooCommerce.
Njegova osnovna ideja je jednostavna: napraviti alat koji administratoru WooCommerce prodavnice omogućava da bezbedno, kontrolisano i u batch režimu čisti katalog proizvoda — bez ručnog kliktanja, bez preopterećenja servera i bez rizika da se sve operacije pokrenu odjednom.
Problem: veliki WooCommerce katalog nije samo “više proizvoda”
Na prvi pogled, katalog od 20.000 proizvoda deluje kao samo “veći katalog”. U praksi, to je potpuno drugačiji nivo održavanja.
Kod velikog kataloga najčešće se javljaju četiri problema.
Prvi problem su proizvodi bez validne featured slike. Oni ruše vizuelni kvalitet prodavnice, stvaraju loš utisak kod kupaca i često prave problem u feedovima, oglasima i indeksiranju. Ako korisnik dođe do proizvoda bez slike, taj proizvod ne deluje pouzdano, čak i ako je sam proizvod ispravan.
Drugi problem su proizvodi kojih više nema na stanju. U WooCommerce okruženju to može značiti različite stvari: _stock = 0, _stock_status = outofstock, ili situaciju u kojoj eksterni dobavljač više ne šalje proizvod kroz feed. Ako takvi proizvodi ostanu javno dostupni, katalog postaje zagušen i prodavnica gubi operativnu jasnoću.
Treći problem je zastareo lager. To je posebno važno kod prodavnica koje rade sa dobavljačkim XML feedovima, WP All Import-om ili custom sinhronizacijama. Ako proizvod nije ažuriran 7, 15, 30 ili više dana, to je signal da možda više nije pouzdan za prodaju.
Četvrti problem je Trash. WordPress proizvode prvo prebacuje u Trash, što je dobro jer je nedestruktivno. Ali ako hiljade proizvoda ostanu u Trash-u, to dugoročno pravi teret bazi i administraciji. Zato je potreban poseban alat koji može da prazni Trash u kontrolisanim batch-evima.
Ovo nije apstraktan problem. Ovo je tipičan problem realnih WooCommerce prodavnica koje uvoze proizvode iz više feedova i moraju da održavaju katalog u životu.
Prva verzija: dodatak samo za proizvode bez slike
Prva ideja je bila mnogo uža: napraviti dodatak koji pronalazi WooCommerce proizvode bez featured slike i prebacuje ih u Trash.
Zato je i prvobitni naziv bio vezan za “Products Without Image Cleaner”. Ideja je tada bila jasna: ako proizvod nema validnu sliku, on treba da se skloni iz aktivnog kataloga.
Ali već posle prvih testova postalo je očigledno da problem nije samo u slikama.
Ako već imam sistem koji može da:
- pronalazi problematične proizvode,
- radi u batch režimu,
- prikazuje progress,
- vodi log,
- koristi WP-Cron,
- i bezbedno prebacuje proizvode u Trash,
onda nema smisla da se alat ograniči samo na slike.
Tu je dodatak počeo da prerasta iz malog utility plugina u ozbiljniji alat za održavanje WooCommerce kataloga.
Druga faza: od “image cleaner”-a do “cleanup manager”-a
Kako se ideja razvijala, dodao sam nove operacije:
- Products without valid featured image
Prebacuje u Trash proizvode bez validne featured slike. - Out-of-stock / zero-stock cleanup
Prebacuje u Trash proizvode kojih nema na stanju. - Stale stock cleanup
Prebacuje u Trash proizvode kojima lager nije ažuriran više od X dana. - Trash Cleaner
Trajno briše proizvode koji su već u Trash-u. - Stock timestamp backfill
Inicijalizuje timestamp za postojeće proizvode, kako bi stale stock logika imala na čemu da radi.
U tom trenutku postalo je jasno da stari naziv dodatka više nije dobar. Ako dodatak briše samo proizvode bez slike, naziv “Products Without Image Cleaner” ima smisla. Ali ako dodatak upravlja slikama, lagerom, zastarelim proizvodima, Trash-om i batch obradom, onda takav naziv postaje netačan.
Zato sam ga preimenovao u:
Geos – Product Cleanup Manager for WooCommerce
To bolje opisuje šta dodatak zaista radi: nije samo cleaner za jedan problem, nego mali menadžer za higijenu WooCommerce kataloga.
Najvažnija odluka: svaka operacija mora imati posebno dugme
Jedna od ključnih lekcija tokom razvoja bila je da dodatak ne sme da radi “sve odjednom”.
Prva logika je mogla da ide u smeru: korisnik uključi pravila, klikne Start, a dodatak odradi sve što je uključeno. Tehnički, to je moguće. Ali za realan rad to nije dovoljno dobro.
Zašto?
Zato što administrator mora da zna šta tačno pokreće.
Ako želi da očisti proizvode bez slike, ne sme usput da pokrene i brisanje proizvoda kojih nema na stanju. Ako želi da testira stale stock cleanup, ne sme da rizikuje da mu se paralelno isprazni Trash. Ako želi da obriše proizvode iz Trash-a, to je permanent delete i mora biti potpuno odvojena operacija.
Zato sam svaku funkciju razdvojio u posebnu komandu:
- posebno dugme za proizvode bez slike,
- posebno dugme za out-of-stock proizvode,
- posebno dugme za stale stock,
- posebno dugme za Trash Cleaner,
- posebno dugme za stock timestamp backfill.
To nije samo UI odluka. To je sigurnosna odluka.
Kada dodatak može da utiče na hiljade proizvoda, korisniku mora biti jasno šta se tačno izvršava.
Batch processing: zašto nije dovoljno “obrisati sve odjednom”
Na shared hostingu, pogotovo kod velikih WooCommerce prodavnica, ne možeš samo da pokreneš brisanje 10.000 proizvoda i očekuješ da server to mirno izdrži.
Zato sam dodatak gradio oko batch logike.
Umesto da sve odradi u jednom zahtevu, dodatak radi u “tick”-ovima:
- skenira određeni broj kandidata po tick-u,
- radi operaciju,
- upisuje progres,
- zakazuje sledeći tick,
- i nastavlja dok ne dođe do cilja ili dok nema više kandidata.
Korisnik može da podesi:
- koliko proizvoda se skenira po tick-u,
- na koliko sekundi ide sledeći tick,
- koji je target za “Run now”,
- i kada želi da zaustavi ili resetuje job.
Ovo je mnogo bolji pristup za realne hosting uslove. Ne pokušavaš da pobediš server silom. Radiš u ritmu koji server može da izdrži.
WordPress.org dokumentacija za plugin readme posebno naglašava važnost pravilnog readme.txt formata, stable tag-a i kratkog opisa, dok WordPress.org SVN workflow zahteva da plugin bude strukturisan kroz trunk, tags i assets, što je dodatno uticalo na način na koji sam pripremao release pakete.
Progress bar, log i “Last run summary”
Kako je dodatak rastao, shvatio sam da nije dovoljno samo izvršiti operaciju. Korisniku moraš pokazati šta se dešava.
Zato sam dodao:
- progress bar za svaku operaciju,
- status job-a,
- broj skeniranih proizvoda,
- broj obrisanih/prebačenih u Trash,
- broj preskočenih,
- stop reason,
- last error,
- debug log,
- i posebno “Last run summary” po operaciji.
Ovo je mnogo važnije nego što izgleda.
Kada klikneš dugme koje može da obradi 20.000 proizvoda, ne želiš da gledaš prazan ekran. Hoćeš da znaš:
- da li se job pokrenuo,
- da li radi,
- koliko je već prošao,
- koliko je ostalo,
- i zašto je nešto preskočeno.
Kasnije sam dodao i throughput / ETA:
- koliko se proizvoda skenira po minuti,
- koliko se akcija izvrši po minuti,
- i grubu procenu preostalog vremena.
To dodatku daje osećaj ozbiljnog administrativnog alata, a ne samo skripte koja “nešto radi u pozadini”.
Najteži deo: stale stock cleanup
Na papiru, “obriši proizvode kojima lager nije ažuriran X dana” zvuči jednostavno.
U praksi, to je bio najkomplikovaniji deo.
Zašto?
Zato što WooCommerce nema uvek pouzdan standardni timestamp koji kaže: “lager ovog proizvoda poslednji put je ažuriran tada i tada”.
Ako se lager menja kroz WooCommerce API, mogu se hvatati hook-ovi. Ali ako se lager menja kroz importer, custom sync, WP All Import ili direktno kroz post meta (_stock, _stock_status), onda se ti hook-ovi možda neće okinuti.
To je bio realan problem tokom testiranja.
Zato sam morao da dodam dodatno praćenje:
- kada se menja
_stock, - kada se menja
_stock_status, - kada se menja varijacija,
- i kada se mora inicijalizovati timestamp za postojeći katalog.
Tako je nastao Stock timestamp backfill — posebna operacija koja može da upiše početne vrednosti za stare proizvode, kako bi stale stock cleanup imao na čemu da radi.
Ovo je jedna od onih stvari koje ne vidiš u prvoj verziji. Otkriješ je tek kad dodatak testiraš na realnom katalogu.
Trash Cleaner: lekcija iz realnog bug-a
Trash Cleaner je posebna priča.
Ideja je bila jasna: proizvodi koji su već u Trash-u mogu da se trajno obrišu, ali kontrolisano, u batch režimu.
Međutim, tokom testiranja se pojavilo nešto zanimljivo: klik na Trash Cleaner nije uvek pokretao pravi trash_cleaner job. U logu se videlo da se umesto toga pokreće generički cleanup job, koji je stalno vraćao trashed=0, processed=0, remaining=4000.
To je bio klasičan routing bug.
Dugme je trebalo da pokrene specifičnu komandu, ali backend je u određenoj situaciji padao na legacy cleanup logiku.
Rešenje je bilo da se Trash Cleaner zaštiti na više nivoa:
- dugme šalje poseban command,
- forma šalje hidden job type,
- handler eksplicitno prepoznaje
start_trash_cleaner, - i postoji safety stop koji sprečava da Trash Cleaner target završi u pogrešnom job-u.
To je važna lekcija: kod alata koji briše podatke, ne smeš da se osloniš na “valjda će dugme poslati dobru vrednost”. Moraš da napraviš defanzivnu logiku.
WordPress.org review: drugi deo razvoja
Jedna stvar koju mnogi potcene jeste da izrada dodatka nije završena kada kod proradi.
Ako želiš da dodatak pošalješ na WordPress.org, počinje drugi deo posla:
- pravilno ime dodatka,
- pravilan slug,
- validan WordPress.org contributor username,
- odgovarajući plugin header,
Requires Plugins,Text Domain,- readme format,
- kratki opis do 150 karaktera,
- assets folder,
- SVN struktura,
- Plugin Check,
- escaping,
- sanitization,
- nonce provere,
- i komunikacija sa review timom.
U mom slučaju, morao sam da prilagodim naziv dodatka jer “Woo” na početku može da deluje kao da je plugin zvanično povezan sa WooCommerce-om. Zato sam prešao na naziv:
Geos – Product Cleanup Manager for WooCommerce
To jasno kaže da je dodatak namenjen za WooCommerce, ali ne pokušava da izgleda kao zvanični Woo dodatak.
Takođe sam dodao Requires Plugins: woocommerce, što je uvedeno kao deo WordPress plugin dependencies mehanizma u WordPress 6.5, kako bi WordPress mogao da zna da dodatak zavisi od WooCommerce-a.
Morao sam da sredim i readme.txt. WordPress.org dokumentacija jasno navodi da readme kontroliše prikaz plugin stranice, da Contributors treba da budu WordPress.org korisnička imena, da tagova treba biti 1–5, i da kratki opis treba da bude najviše 150 karaktera.
Morao sam da sredim i plugin assets: banere, ikonice i strukturu fajlova. WordPress.org ima posebna pravila kako plugin assets funkcionišu i gde se stavljaju u SVN strukturi.
To je možda najmanje glamurozan deo posla, ali je neophodan ako želiš da plugin bude javno dostupan i ozbiljno predstavljen.
Uloga ChatGPT-a i Codex-a u procesu
Ovaj dodatak nije nastao tako što sam samo napisao prompt i dobio gotov proizvod.
To bi bila lepa priča, ali ne bi bila istinita.
Realni proces je izgledao ovako:
- ja definišem problem iz prakse,
- ChatGPT predloži arhitekturu,
- Codex ili ChatGPT pomognu u pisanju koda,
- ja testiram u realnom WordPress/WooCommerce okruženju,
- log pokaže gde nešto ne radi,
- ponovo analiziramo,
- pravimo hotfix,
- testiramo opet,
- pa tek onda pakujemo verziju.
Najveća vrednost AI alata nije bila u tome što “sam napiše plugin”. Vrednost je bila u brzini iteracije.
Umesto da satima tražim gde je greška u routing-u, logika se mogla brzo izolovati. Umesto da ručno pišem svaku varijantu readme-a, changelog-a i commit poruke, mogao sam brzo da generišem verzije i uskladim ih sa WordPress.org zahtevima. Umesto da sam držim sve edge case-ove u glavi, mogao sam da testiram hipoteze i brzo ih pretvorim u kod.
Ali ključna stvar ostaje: AI nije zamena za testiranje.
AI može da predloži kod. Ali samo realan test na WooCommerce prodavnici pokaže da li taj kod stvarno radi.
Šta sam naučio iz ovog procesa
Prva lekcija: naziv dodatka mora da raste zajedno sa funkcionalnošću. Ako plugin počne kao alat za jednu stvar, a kasnije postane širi menadžer, naziv mora da se promeni.
Druga lekcija: batch processing nije luksuz. Kod velikih WooCommerce prodavnica to je obavezno.
Treća lekcija: svaka opasna operacija mora biti odvojena. Naročito permanent delete.
Četvrta lekcija: log nije dodatak. Log je alat bez kog ne možeš ozbiljno debagovati plugin koji radi u pozadini.
Peta lekcija: WordPress.org compliance je deo proizvoda. Nije “administracija posle koda”. Ako želiš javni plugin, moraš ga tretirati kao proizvod od prvog dana.
Šesta lekcija: AI ubrzava razvoj, ali ne uklanja odgovornost. Na kraju ti moraš da razumeš šta dodatak radi, šta briše, kako se ponaša i gde može da zakaže.
Zaključak
Geos – Product Cleanup Manager for WooCommerce je nastao iz vrlo konkretnog problema: kako održavati veliki WooCommerce katalog bez ručnog rada, bez preopterećenja servera i bez opasnosti da se pogrešna operacija pokrene nad hiljadama proizvoda.
Počeo je kao jednostavan cleaner za proizvode bez slika. Vremenom je prerastao u alat za:
- image cleanup,
- stock cleanup,
- stale stock cleanup,
- Trash Cleaner,
- stock timestamp backfill,
- progress tracking,
- logging,
- i batch obradu.
Najvažnije od svega: dodatak je nastao iterativno. Svaka verzija je rešavala jedan konkretan problem iz testiranja.
To je, po meni, najzdraviji način da se pravi softver: ne od apstraktne ideje, nego od stvarnog bola.
A ako se taj bol ponavlja kod mene, velika je šansa da postoji i kod drugih WooCommerce administratora.
Zato ovaj plugin nije samo još jedan dodatak u nizu. On je rezultat realnog rada sa velikim katalogom, realnih grešaka, realnog testiranja i jasne potrebe da WooCommerce administracija postane brža, sigurnija i manje ručna.