Un plugin invece di venti: quanto costa uno zoo di estensioni WooCommerce?

Recentemente mi ha contattato il titolare di un negozio online di lubrificanti industriali. Sito web su WooCommerce, catalogo: circa quattromila prodotti, il traffico è abbastanza decente, gli ordini stanno arrivando. Ma la sua domanda non riguardava le vendite o la SEO. Ha letteralmente detto quanto segue: "Oleg, ho trentadue plugin sul mio sito e ho paura di fare clic sul pulsante "Aggiorna" su almeno uno di essi. L'ultima volta che ho aggiornato il filtro del prodotto, sono stati aggiunti il ​​carrello e il confronto. Il negozio è rimasto lì per due giorni. Cosa fare?" E sai, in quel momento mi sono sorpreso a pensare che ascolto questa storia circa una volta al mese. Nicchie diverse, dimensioni di business diverse, ma il problema è lo stesso: uno zoo di plugin che una volta veniva assemblato pezzo per pezzo per crescere, ma ora si è trasformato in un campo minato. Ogni aggiornamento è roulette russa. Ogni nuovo plugin è un potenziale conflitto con i tre già installati. E la cosa più triste è che il proprietario del negozio lo dà per scontato. Come un male necessario di WooCommerce. Dicono, beh, cosa puoi fare, una piattaforma del genere è modulare, sui plugin, è così che vivono tutti.

Beh, non tutto. E voglio parlare del perché “zoo” non è un’inevitabilità, ma una scelta. Una scelta costosa, una scelta rischiosa e nella maggior parte dei casi una scelta inconsapevole. Perché quando installi il primo plug-in della lista dei desideri per $ 99 all'anno, non pensi che in sei mesi avrai venti di questi abbonamenti e il controllo totale delle estensioni supererà di tre volte il costo dell'hosting stesso. Risolvi semplicemente un problema specifico: "Ho bisogno di una lista dei desideri". Quindi "Ho bisogno di un confronto tra prodotti". Poi “Ho bisogno di un modulo B2B”. E si parte. Ci sono passato io stesso, sia come proprietario di un negozio che come persona che costruisce questi negozi per i clienti. E ad un certo punto ho capito che non potevo più vivere così. Che è necessario un approccio fondamentalmente diverso. Ma parliamo di tutto in ordine.

Anatomia di un tipico negozio WooCommerce: cosa c'è sotto il cofano

Prendiamo un negozio online “medio” condizionale su WooCommerce. Non una landing page con dieci prodotti, ma un normale negozio funzionante: un catalogo di migliaia di articoli, diverse categorie, filtri, ricerca, carrello, checkout, account personale. Niente di esotico: un set base per l'e-commerce. Vediamo ora quali plugin sono disponibili su un sito del genere, e non sto parlando di scenari fittizi, ma di progetti reali che ho visto e su cui ho lavorato.

WooCommerce ti offre un catalogo, un carrello e un checkout immediato. Tutto il resto sono plugin. Filtraggio del prodotto - plugin. Ricerca nel catalogo che funziona normalmente e non come una ricerca standard di WordPress che restituisce pagine anziché prodotti: un plug-in. Confronto prodotti - plug-in. La lista dei desideri è un plugin. Mega menu in modo che il catalogo sia ben organizzato nell'intestazione - plugin. Funzionalità B2B: prezzi all'ingrosso, gruppi di clienti, richieste di preventivo: questo è già un intero set di plugin. Sicurezza: firewall, protezione dalla forza bruta, monitoraggio: plug-in. Analisi e audit SEO - plugin. Campi personalizzati per prodotti - plugin. Feedback e moduli di domanda - plugin. Consegna tramite SDEK, Boxberry, KIT: un plug-in per ciascun corriere. L'integrazione con 1C è un plugin separato. Il caricamento su Yandex.Market è un altro. Reindirizzamenti - altro. La mappa del sito XML è normale, comunque. E non ho ancora menzionato la memorizzazione nella cache, l'ottimizzazione delle immagini, una libreria multimediale con cartelle e una dozzina di piccole utilità.

Non sto esagerando. Ora aprirò uno dei progetti reali e farò i conti. Uno dei negozi che ho contattato l'anno scorso aveva ventisette plugin attivi, diciannove dei quali erano estensioni della funzionalità WooCommerce. Non “bei bottoni” decorativi, ma moduli funzionanti, senza i quali il negozio non può funzionare. Togline qualcuno e qualcosa si romperà. Il filtro smetterà di filtrare, la ricerca smetterà di cercare, i clienti B2B non vedranno i loro prezzi, 1C smetterà di caricare i saldi. Ogni plugin è una dipendenza. Ed è qui che inizia il divertimento: calcoliamo quanto costa.

YITH WooCommerce Wishlist Premium - $99/anno. YITH WooCommerce Confronta Premium - $79/anno. Filtro prodotto YITH Ajax: $ 99 all'anno. Wordfence Premium: $ 119 all'anno. ACF Pro: $ 99 all'anno (o $ 49 per una licenza personale, ma per un sito commerciale è necessaria un'azienda). SearchWP: $ 99 all'anno. WPForms Pro - $ 199 all'anno (o Contact Form 7 è gratuito, ma con un sacco di componenti aggiuntivi a pagamento). MaxMegaMenu Pro: $ 49 all'anno. Plugin di consegna SDEK: 3900 rubli all'anno. Plug-in Boxberry: 2500 rubli. Plugin per l'integrazione 1C: da 5.000 a 15.000 rubli all'anno, a seconda della funzionalità. Yoast SEO Premium: $ 99 all'anno. Plugin per feed Yandex.Market: da 2000 a 5000 rubli. Real Media Library per l'organizzazione dei media - $49. E questo non tiene nemmeno conto del tema, che di per sé può costare dai 59 ai 79 dollari all’anno per gli aggiornamenti.

Se sommi tutto, si aggira tra $ 900 e $ 1.500 all'anno solo per i plugin. Ad un tasso di cambio di 90 rubli per dollaro, si tratta di 81.000 - 135.000 rubli all'anno. Per gli abbonamenti ai plugin. Non per l'hosting, non per il dominio, non per il lavoro del programmatore, solo per il diritto di utilizzare il codice di qualcun altro. E ogni anno devi pagare di nuovo questo importo, perché se smetti di pagare, gli aggiornamenti non arriveranno più e, senza aggiornamenti, prima o poi il plugin si romperà su una nuova versione di WordPress o WooCommerce. Ho visto negozi che utilizzavano plugin vecchi di tre anni e funzionavano solo perché il proprietario aveva paura di aggiornare WordPress oltre una certa versione. Questa non è una strategia: è una bomba a orologeria.

Ma i soldi non sono poi così male. Il denaro può essere contato, pianificato, preventivato. Molto peggio è ciò che non può essere calcolato: perdite dovute a conflitti, tempi di inattività e degrado della produttività.

Venti plugin: venti punti di errore

Ecco cosa ho imparato negli anni di lavoro con i negozi WooCommerce: ogni plugin è un'unità di codice indipendente, scritta dal proprio autore, secondo i propri standard, con la propria architettura. Quando hai venti plugin sul tuo sito, hai venti approcci diversi per lavorare con il database, venti modi diversi per connettere JavaScript e CSS, venti diversi sistemi di hook e filtri che si agganciano agli stessi eventi WooCommerce. E prima o poi due di questi venti plugin iniziano a entrare in conflitto. Non perché siano scritti male: spesso entrambi i plugin sono di ottima qualità. È solo che i loro autori non si conoscevano e non potevano prevedere che il loro codice avrebbe funzionato sullo stesso sito contemporaneamente.

Ricordo un caso in cui il negozio di un cliente aveva YITH Compare e un plug-in per i prezzi B2B di un altro sviluppatore installati contemporaneamente. Separatamente, entrambi hanno funzionato perfettamente. Ma quello che è successo insieme è che quando un cliente B2B ha aperto una pagina di confronto dei prodotti, ha visto i prezzi al dettaglio invece dei prezzi all’ingrosso. Perché? Perché YITH Compare ha generato la sua tabella di confronto tramite una richiesta AJAX e il plug-in B2B ha intercettato i prezzi tramite l'hook woocommerce_product_get_price, che nel contesto della richiesta Compare AJAX ha funzionato in modo diverso rispetto a una normale pagina di prodotto. Il bug veniva riprodotto solo per i clienti B2B, solo nella pagina di confronto, solo con alcuni prodotti. Lo abbiamo cercato per tre giorni. Per tre giorni il programmatore si è seduto e ha capito il codice di due plugin, al cui codice sorgente avevamo accesso limitato, perché entrambi erano premium, con codice offuscato.

Ora immagina che non ci siano uno o due di questi potenziali conflitti sul sito, ma dozzine. Ogni coppia di plugin è un potenziale punto di intersezione. Se hai venti plugin, il numero di coppie possibili è centonovanta. Centonovanta potenziali conflitti. Naturalmente, non tutti vengono implementati, ma anche se uno su venti “spara”, si tratta di quasi dieci problemi reali, ognuno dei quali richiede tempo e denaro per diagnosticare e correggere.

E i conflitti non sono solo bug funzionali. Riguarda anche la produttività. Ogni plugin aggiunge le proprie tabelle al database. ACF ha le sue tabelle, la lista dei desideri ha la sua, il modulo B2B ha la sua, la ricerca ha la sua, l'integrazione 1C ha la sua. Su uno dei progetti ho calcolato: venti plugin hanno creato un totale di quarantasette tabelle aggiuntive nel database. Quarantasette tabelle oltre alle tabelle standard di WordPress e WooCommerce. E ogni plugin effettua le proprie query SQL sulle proprie tabelle quando la pagina viene caricata. Un plugin: da due a cinque richieste. Venti plugin: da quaranta a cento query SQL aggiuntive per ogni caricamento di pagina. E ognuno include anche il proprio file CSS e il proprio JavaScript. Venti file CSS, venti file JS: sono altri 500-800 kilobyte che il browser deve scaricare, analizzare ed eseguire. Su Internet veloce, potresti non notarlo, ma PageSpeed ​​​​lo noterà e anche Yandex lo noterà durante il posizionamento.

L'ho misurato su un progetto specifico. Negozio di oli e lubrificanti, ventitré plug-in. Il tempo di risposta del server (TTFB) è di 1,8 secondi. Il caricamento completo della pagina del catalogo è di 4,2 secondi. Abbiamo iniziato a disabilitare i plugin uno per uno e a misurare nuovamente. Ogni plugin disattivato ha impiegato in media 80–120 millisecondi dal TTFB. Quando abbiamo sostituito diciassette plugin con un'unica soluzione completa, il TTFB è sceso a 0,7 secondi. La pagina ha iniziato a caricarsi in 1,9 secondi. Due volte più veloce - senza cambiare hosting, senza CDN, senza altre ottimizzazioni. Semplicemente perché invece di diciassette pezzi di codice indipendenti, ognuno dei quali è stato inizializzato a modo suo, ha caricato le proprie risorse e ha effettuato le proprie richieste al database, ha iniziato a funzionare un plug-in con un'unica architettura.

Ma parliamo di un altro aspetto che solitamente viene dimenticato: gli aggiornamenti. Venti plugin significano venti autori diversi, venti programmi di aggiornamento diversi. Un autore rilascia un aggiornamento una volta alla settimana, un altro una volta ogni sei mesi. Uno verifica la compatibilità con l'ultima versione di WooCommerce, l'altro no. Uno scrive un registro delle modifiche dettagliato, l'altro si limita a laconiche "correzioni di bug". E ogni aggiornamento di ogni plugin è un potenziale rischio. Conosco proprietari di negozi che trascorrono due o tre ore alla settimana semplicemente controllando gli aggiornamenti disponibili, leggendo i registri delle modifiche, decidendo cosa aggiornare ora e cosa può aspettare, facendo un backup, aggiornando, controllando se qualcosa è rotto. Da due a tre ore settimanali equivalgono a centocinquanta ore all'anno. Per gli aggiornamenti dei plugin. Se traduci in denaro al ritmo di almeno un amministratore di sistema, si tratta di altri 150-300 mila rubli all'anno di spese implicite.

Quando ho deciso che bastava

La svolta per me è arrivata circa tre anni fa. Ho lavorato a un grande progetto B2B: un negozio di prodotti chimici industriali, mille e mezzo di prodotti, un sistema di prezzi complesso con gruppi di clienti e sconti individuali, integrazione con 1C, SDEK multi-consegna più KIT più linee Business, filtri per caratteristiche tecniche, liste dei desideri, confronto, moduli di richiesta preventivo. Set standard per un negozio B2B serio. C'erano venticinque plugin sul sito. E poi WooCommerce ha lanciato un grosso aggiornamento: non ricordo esattamente quale versione, ma l'aggiornamento era importante, con modifiche all'API. E si scatenò l'inferno. Tre plugin su venticinque si sono rivelati incompatibili con la nuova versione. Uno di questi, il plugin di integrazione 1C, ha semplicemente smesso di funzionare. L'autore ha rilasciato un aggiornamento due settimane dopo. Per due settimane il negozio ha funzionato senza sincronizzazione con 1C: i saldi non sono stati aggiornati, i prezzi non sono stati aggiornati, i nuovi prodotti non sono stati scaricati. Il secondo plugin, il filtro prodotto, ha iniziato a generare errori durante il filtraggio in base al prezzo. L'autore ha risposto al supporto quattro giorni dopo e ha rilasciato la correzione una settimana dopo. Il terzo plugin, il modulo dei prezzi B2B, non calcola più correttamente gli sconti all'ingrosso per uno dei gruppi di clienti. Non abbiamo notato subito questo bug, ma solo quando il cliente si è lamentato del fatto che gli era stato addebitato un prezzo al dettaglio anziché un prezzo all’ingrosso. Quanti ordini sono stati eseguiti con prezzi errati prima che lo scoprissimo? Ancora non lo so.

E allora mi sono posto la domanda: perché, infatti, dovrebbe essere tutto così? Perché un negozio ha bisogno di venticinque prodotti software indipendenti di venticinque autori diversi che non sanno nulla l'uno dell'altro? Perché non puoi avere un prodotto che copra tutte le esigenze del negozio? Non "un plugin che fa tutto male", ma un prodotto con un'architettura ben congegnata, in cui tutti i moduli funzionano in un'unica base di codice, utilizzano librerie comuni, un sistema comune di hook, tabelle comuni nel database?

Ho iniziato a cercare una soluzione del genere. E non l'ho trovato. Più precisamente, ho trovato diversi tentativi: plugin "tutto in uno" per WooCommerce, che promettevano di sostituire tutto nel mondo. Ma dopo un esame più attento, si è scoperto che si trattava di un insieme di moduli liberamente accoppiati incollati insieme in un unico file zip, oppure di prodotti con le funzionalità di ciascun modulo così ridotte che era ancora necessario fornire plug-in specializzati per funzionare effettivamente. Il "filtro prodotto" in tale combinazione è costituito da tre caselle di controllo e un cursore del prezzo. “B2B” è un campo in cui inserire uno sconto di gruppo. “Cerca” è una ricerca standard di WordPress con un modello diverso. Non puoi costruire un business serio su questo.

E poi ho deciso di costruirmelo da solo. Non perché io sia lo sviluppatore più intelligente o più esperto al mondo, ma perché conoscevo le esigenze specifiche dei negozi specifici con cui lavoravo. Sapevo quali funzionalità venivano effettivamente utilizzate e quali erano sciocchezze di marketing. Sapevo dove i plugin erano in conflitto e perché. Sapevo quali query del database erano killer delle prestazioni e come ottimizzarle. È così che è nato COS WP Woo, un plugin che è iniziato come strumento interno per i miei progetti ed è cresciuto fino a diventare un prodotto a tutti gli effetti.

Cosa significa in pratica “un plugin invece di venti”?

Non descriverò qui ogni pulsante e ogni casella di controllo: sono disponibili documentazione e pagine con le descrizioni dei singoli moduli per questo. Voglio parlare di un principio. Su cosa cambia quando passi da uno zoo di plugin a un'unica soluzione. E perché non è solo “più conveniente”, ma cambia radicalmente l’economia e l’affidabilità del tuo negozio.

Cominciamo con l'architettura. Quando venti plugin vengono sostituiti da uno, ciò non significa che venti basi di codice siano meccanicamente incollate in una. Ciò significa che viene creata un'unica architettura in cui tutti i moduli condividono un'infrastruttura comune. Caricatore automatico di classe generale: uno invece di venti. Sistema comune di registrazione degli hook: tutti i moduli sono collegati tramite un unico punto di ingresso, in un ordine prevedibile, senza conflitti di priorità. API REST comune: spazio dei nomi comune, sistema di autorizzazione comune, standard di risposta comuni. Tabelle condivise nel database dove ha senso: invece di ogni modulo che crea la propria tabella per la registrazione, una tabella comune Activity_log serve tutti i moduli. Un pacchetto JavaScript comune è un file invece di venti, compilato da webpack, minimizzato, con scuotimento dell'albero per rimuovere il codice inutilizzato. CSS comuni: un sistema di stile invece di venti file, ognuno dei quali porta la propria versione di Bootstrap o il proprio framework personalizzato.

In pratica, ciò significa che quando il modulo dei prezzi B2B calcola il prezzo all'ingrosso per un gruppo di clienti, questo prezzo è immediatamente visibile al modulo di confronto dei prodotti, al modulo della lista dei desideri, al modulo del carrello, al modulo di filtro dei prezzi. Non attraverso hook intermedi che un plugin può intercettare ma un altro no. Direttamente, attraverso servizi condivisi. Perché tutti questi moduli fanno parte di un tutto e si conoscono a vicenda.

Quando il modulo di ricerca indicizza un prodotto, lo indicizza con tutti i campi personalizzati definiti nel modulo Campi personalizzati. Non perché “abbiamo scritto l’integrazione con ACF”, ma perché Custom Fields e Search sono due moduli dello stesso plugin che utilizzano gli stessi servizi per accedere ai dati. Quando il modulo 1C aggiorna i saldi dei prodotti, questi dati aggiornati sono immediatamente disponibili per il modulo di filtro, il modulo feed Yandex.Market e il modulo di notifica della lista dei desideri (per inviare una lettera "il prodotto è di nuovo disponibile"). Tutto questo avviene all'interno di una richiesta, senza chiamate AJAX aggiuntive, senza caching intermedio, senza sincronizzazione tramite cron.

Permettetemi di mostrarlo utilizzando numeri specifici di un progetto reale. Il negozio di oli e lubrificanti è lo stesso che ho menzionato sopra. Prima di passare a COS WP Woo: 23 plugin, 47 tabelle aggiuntive nel database, circa 90 query SQL per caricare la pagina del catalogo, 18 file CSS e 15 file JS collegati sul front end, TTFB 1,8 secondi, pieno carico 4,2 secondi. Dopo la transizione: 1 plugin (più WooCommerce, ovviamente, e tema), 30 tabelle nel database (sì, COS WP Woo crea anche le proprie tabelle, ma ce ne sono meno, perché le funzioni comuni utilizzano tabelle comuni), circa 35 query SQL sulla stessa pagina, 3 file CSS e 2 file JS sul frontend, TTFB 0,7 secondi, pieno carico 1,9 secondi. PageSpeed ​​Insights ha mostrato un aumento di 23 punti su desktop e 18 punti su mobile. Senza nessun'altra ottimizzazione, solo sostituendo lo zoo di plugin con un'unica soluzione.

E ora parliamo di soldi. Gli stessi 23 plugin costano al cliente circa 1.100 dollari all’anno in abbonamenti. Inoltre circa 200 ore all'anno per manutenzione: aggiornamenti, controlli di compatibilità, risoluzione di conflitti, contatto con il supporto di diversi fornitori. Alla tariffa minima dell’amministratore di sistema di 1.500 rubli all’ora, si tratta di altri 300.000 rubli. Totale: circa 400.000 rubli all'anno per mantenere lo zoo dei plugin. Il prezzo di una licenza COS WP Woo - non fornirò qui cifre specifiche, perché abbiamo un sistema tariffario flessibile a seconda del numero di moduli - ma dirò questo: il risparmio annuale è almeno triplo. E questo non tiene conto delle perdite implicite dovute a tempi di inattività, conflitti e bassa velocità del sito.

Ma voglio essere onesto: passare da uno zoo di plugin a un'unica soluzione non è gratuito. Questo è un progetto. Devi migrare i dati: liste dei desideri degli utenti, impostazioni del gruppo B2B, campi prodotto personalizzati, cronologia delle ricerche, regole di reindirizzamento. Dobbiamo configurare nuovi moduli e verificare che tutto funzioni come previsto. Hai bisogno di trascorrere del tempo. In genere, la migrazione di un negozio medio richiede da uno a tre giorni di lavoro. Ma questi giorni ripagano nel primo mese, grazie al risparmio sugli abbonamenti, alla maggiore velocità, alla scomparsa dei conflitti.

Il lato oscuro dell'all-in-one - e perché COS WP Woo non è così

Capisco perfettamente lo scetticismo provocato dall'idea di "un plugin invece di venti". Perché questa idea ha un lato oscuro noto e bisogna parlarne apertamente. Le soluzioni monolitiche “all-in-one” sono spesso criticate per tre cose: vincolo del fornitore, dimensioni e complessità eccessive e il rischio che “se un plugin si rompe, si rompe tutto”. Esaminiamo ciascuno di questi argomenti in modo onesto, senza chiacchiere di marketing.

Vincolo del fornitore. Sì, quando passi da venti plugin indipendenti a uno complesso, diventi dipendente da uno sviluppatore. Se lo sviluppatore abbandona il progetto o va in bancarotta, hai un problema. Questo è un rischio reale e non farò finta che non esista. Ma guardiamo la cosa dall'altro lato. Quando hai venti plugin, dipendi da venti sviluppatori. E se almeno uno di loro abbandona il plugin, anche tu hai un problema, solo locale. Ho visto situazioni in cui l'autore di un popolare plugin WooCommerce ha semplicemente smesso di supportarlo, lasciando migliaia di negozi con codice morto che diventava sempre meno compatibile con ogni aggiornamento di WordPress. Nel caso di uno zoo, questo sembra essere meno critico: puoi sostituire un plugin morto con uno analogico. Ma anche la migrazione dei dati da un plugin della lista dei desideri a un altro è un progetto, anche tempo, anche denaro. Quindi in entrambi i casi esiste un vincolo del rischio da parte del fornitore, ma ha solo una forma diversa.

Per quanto riguarda specificamente COS WP Woo, distribuiamo un plugin open source. Ottieni PHP e JavaScript completi e non offuscati. Se domani sparissimo dalla faccia della terra (cosa che spero non accada), il tuo plugin funzionerà ancora e qualsiasi sviluppatore WordPress qualificato sarà in grado di mantenerlo e modificarlo. Questo ci distingue fondamentalmente dai plugin con codice crittografato, che senza licenza attiva si trasformano in una zucca.

Dimensioni gonfiate. Il secondo argomento classico è che se un plugin fa tutto, è inevitabilmente pesante e lento. Ho solo bisogno di una lista dei desideri: perché devo scaricare l'integrazione B2B e 1C? L'argomento è logico, ma ignora una sfumatura importante: viene caricato solo ciò che è attivato. COS WP Woo è costruito su un'architettura modulare a caricamento lento. Se non hai abilitato il modulo 1C, il suo codice non viene caricato affatto. Non è “caricato ma non eseguito”, ma non connesso fisicamente. Il caricatore automatico non carica classi di moduli inattivi, JavaScript utilizza la suddivisione del codice e il caricamento lento: il bundle di pagine attive non contiene il codice dei moduli inattivi. In pratica, se si utilizzano dieci dei moduli disponibili, la dimensione del codice caricato è approssimativamente uguale a dieci plugin individuali, ma con un'importante differenza: dieci plugin individuali hanno dieci copie di wrapper jQuery, dieci copie di utilità AJAX, dieci framework CSS diversi. Un plugin con un'architettura modulare ha un'infrastruttura comune per tutti i moduli. Pertanto, in realtà, dieci moduli COS WP Woo pesano meno di dieci plugin indipendenti simili.

Il terzo argomento è “se uno si rompe, tutto si rompe”. Qui sarò il più diretto possibile: sì, questo è un rischio, e ci abbiamo pensato fin dall'inizio. Pertanto, ogni modulo COS WP Woo è isolato nel proprio namespace, con i propri servizi, il proprio controller API REST e le proprie classi front-end. Se si verifica improvvisamente un errore nel modulo Mega Menu, ciò non influirà sul modulo B2B o sul modulo di ricerca. Ogni modulo è connesso tramite un wrapper try-catch nel punto di inizializzazione e un errore fatale in un modulo non provoca il crash dell'intero plugin. Questa non è una teoria: testiamo specificamente questo scenario: rompiamo artificialmente un modulo e controlliamo che il resto continui a funzionare. Inoltre, un'unica base di codice significa test unificati: testiamo la compatibilità di tutti i moduli tra loro con ogni versione, cosa impossibile con uno zoo di venti plugin indipendenti.

C’è un altro argomento che a volte mi viene dato: “Un plugin specializzato sarà sempre migliore di un modulo in una mietitrebbia”. E anche questo non è del tutto vero. Wordfence è un prodotto di sicurezza brillante, senza dubbio. Ma hai bisogno di tutto Wordfence se il tuo negozio necessita solo di WAF, protezione dalla forza bruta, monitoraggio dell'integrità dei file e autenticazione a due fattori? Il modulo Sicurezza di COS WP Woo copre esattamente queste esigenze: né più né meno. SearchWP è un ottimo plugin di ricerca. Ma se il tuo negozio utilizza già Typesense per la ricerca (e il nostro modulo di ricerca funziona specificamente con Typesense, il motore di ricerca open source più veloce), non hai bisogno di SearchWP con la sua ricerca basata su MySQL, che inizia a rallentare notevolmente con un catalogo di diecimila prodotti. A volte il "modulo in una mietitrebbia" risulta essere tecnologicamente più moderno di un plugin specializzato, semplicemente perché è stato scritto in seguito e tiene conto dell'esperienza dei suoi predecessori.

Non sto dicendo che COS WP Woo sia migliore di ogni singolo plugin in ogni caso. Wordfence sa più di noi sulla sicurezza di WordPress. Yoast ne sa più di noi sulla SEO. Ma per un tipico negozio WooCommerce che non necessita di un modulo, ma di dieci o quindici, il valore totale di una singola soluzione supera di gran lunga i vantaggi dei singoli plugin “migliori della razza”. Perché il migliore della razza isolatamente e il migliore della razza insieme ad altri diciannove migliori della razza sono due esperienze completamente diverse.

Vorrei esaminare i moduli principali e dirvi cosa sostituiscono esattamente. Non nel formato di un elenco secco - avevo promesso che non ci sarebbero stati elenchi - ma attraverso il prisma dei problemi reali che ciascuno di essi risolve.

Il modulo AI Content è probabilmente la parte più unica di COS WP Woo, perché praticamente non esiste un analogo diretto sotto forma di plugin separato. Sì, esistono plugin per la generazione di contenuti AI, ma la maggior parte di essi sono semplici wrapper sull'API ChatGPT che generano un testo alla volta. Il nostro modulo funziona in modalità batch: imposti i parametri, selezioni i prodotti e BatchProcessor elabora almeno mille posizioni in background tramite l'Action Scheduler. In questo caso, puoi scegliere un fornitore - Anthropic Claude o OpenAI - e creare suggerimenti specializzati per la tua nicchia. I test A/B delle descrizioni ti consentono di confrontare la conversione di diverse opzioni di testo sul traffico reale. Questo è uno strumento che non sostituisce un plugin, ma un intero dipartimento di copywriter. Uno dei nostri clienti, un negozio di oli per automobili, ha generato le descrizioni di dodicimila prodotti in una notte. A mano, questo è un lavoro da tre a quattro mesi per un team di tre copywriter.

Il modulo SEO e audit è la nostra risposta alla combinazione Yoast Premium più Rank Math. Audit completo delle schede prodotto basato su quindici o più criteri: lunghezza della descrizione, meta tag, testi alternativi delle immagini, collegamenti interni, dati strutturati. Generazione automatica di FAQ per ciascun prodotto con output in formato JSON-LD: si tratta delle stesse "domande e risposte" che appaiono direttamente nei risultati di ricerca e aumentano notevolmente il CTR. Il modulo di reindirizzamento sostituisce Reindirizzamento o Safe Redirect Manager. Il modulo Sitemap genera una mappa del sito XML ottimizzata per WooCommerce - con prodotti, categorie, immagini. E tutto questo è un unico ecosistema: l'auditor conosce i campi personalizzati, i reindirizzamenti sono integrati con la ricerca, la mappa del sito tiene conto della visibilità B2B dei prodotti.

Il modulo B2B è qualcosa che di solito è coperto da un gruppo di tre o cinque plugin: YITH B2B, WooCommerce B2B, plugin per i prezzi all'ingrosso, plugin per la richiesta di preventivo, plugin per l'account secondario. Il nostro modulo B2B comprende dieci sottomoduli: gruppi di clienti con prezzi multilivello, prezzi individuali, regole di visibilità del prodotto, quantità minime di ordine, portafoglio elettronico, sottoconti per i dipendenti dell'ufficio acquisti, flusso di lavoro per richieste di preventivo con corrispondenza e controproposte, registrazione personalizzata dei clienti B2B, documenti PDF per proposte commerciali, gateway di pagamento per B2B - pagamento fatture e ordine d'acquisto. Non conosco nessun singolo plugin che possa coprire tutto questo allo stesso tempo. In genere, un B2B completo su WooCommerce richiede da tre a cinque plugin, che inevitabilmente entrano in conflitto tra loro perché ciascuno modifica la logica dei prezzi di WooCommerce a modo suo.

Il modulo di ricerca funziona con Typesense, un motore di ricerca open source che è più veloce e più pertinente di qualsiasi ricerca basata su MySQL, inclusi SearchWP e Relevanssi. Ricerca istantanea con completamento automatico, filtro sfaccettato, sinonimi, analisi delle query, selezione della ricerca: tutto pronto all'uso. Inoltre integrazione con schede lubrificanti e tabelle applicative. Sostituisce SearchWP (99 dollari all'anno) o Relevanssi Premium (99 euro all'anno) ed è fondamentalmente più veloce.

Modulo di sicurezza - WAF (Web Application Firewall), protezione dalla forza bruta, monitoraggio dell'integrità dei file, autenticazione a due fattori, blocco geografico, URL di accesso personalizzato, registro attività, protezione XML-RPC, integrazione CAPTCHA. Sostituisce Wordfence Premium ($119/anno) o Sucuri ($199/anno) per le tipiche esigenze del negozio WooCommerce. Non pretendo che il nostro modulo sia un analogo completo di Wordfence con il suo database delle firme e l'intelligence sulle minacce. Ma per un negozio che necessita di una protezione di base contro le minacce standard, questo è più che sufficiente e, soprattutto, non entra in conflitto con altri moduli.

Il modulo Moduli è un generatore di moduli drag-and-drop che sostituisce Contact Form 7 (gratuito, ma con componenti aggiuntivi a pagamento) o WPForms Pro ($ 199/anno). Moduli di feedback, moduli di domanda, moduli di richiesta di preventivo: tutto viene raccolto in un visual builder, i record vengono archiviati in un database con registrazione completa. L'integrazione con il modulo Email consente di inviare notifiche tramite SMTP senza plugin aggiuntivo.

Il modulo Campi personalizzati sostituisce completamente ACF Pro (Campi personalizzati avanzati). Gruppi di campi, ripetitori, contenuto flessibile, gallerie, regole di layout, logica di visualizzazione condizionale. Per coloro che hanno utilizzato ACF, la transizione è quasi semplice perché abbiamo implementato un livello di compatibilità che comprende le funzioni ACF get_field() e the_field(). Perché cambiare ACF se funziona? Perché ACF è un altro plugin indipendente con le proprie tabelle, il proprio aggiornamento, i propri potenziali conflitti. E il modulo integrato dei campi personalizzati funziona in modo nativo con il modulo di ricerca (i campi vengono automaticamente indicizzati in Typesense), con il modulo di audit (il revisore controlla la completezza dei campi personalizzati), con il modulo 1C (i campi sono mappati sugli attributi 1C).

Il modulo Mega Menu sostituisce MaxMegaMenu Pro ($49/anno). Abbiamo letteralmente migrato da MaxMegaMenu al nostro modulo nello store funzionante: abbiamo disattivato MaxMegaMenu, attivato il nostro modulo e tutto ha funzionato. Sottomenu nidificati, schede nel catalogo, icone, adattamento mobile: tutto è a posto. Solo che ora il menu non richiede un framework CSS separato e un bundle JavaScript separato.

Modulo filtro - simile al filtro prodotto YITH Ajax ($99 all'anno). Filtraggio per attributi, prezzo, disponibilità, valutazione. Caricamento AJAX dei risultati senza ricaricare la pagina. Overlay mobile per filtri su schermi piccoli. L'indice di filtraggio nativo non è costituito da query SQL dirette sulle tabelle WooCommerce, ma da un indice precalcolato che viene aggiornato in background. Questo permette di filtrare in millisecondi anche su cataloghi di ventimila prodotti.

Modulo di spedizione - consegna multipla: SDEK, KIT, Business Lines, Russian Post, Boxberry. Un modulo invece di cinque plugin separati, uno per ciascun operatore. Un'unica interfaccia di configurazione, un'unica matrice per la selezione di un metodo di consegna al momento del pagamento e un unico sistema di tracciamento. Risparmio: da 10.000 a 25.000 rubli all'anno sugli abbonamenti ai plug-in dei singoli operatori.

Modulo 1C - Integrazione OData con 1C: Gestione commerciale. Sincronizzazione di prodotti, prezzi, saldi, categorie, attributi. Mappatura delle caratteristiche 1C sulla tassonomia di WooCommerce. Esporta gli ordini di nuovo a 1C. Sostituisce wc1c (da 5.000 a 15.000 rubli all'anno) o vari plugin CommerceML. La differenza fondamentale è l'integrazione OData invece di CommerceML. OData è un'API REST in esecuzione su HTTP, mentre CommerceML è una condivisione di file su FTP/HTTP obsoleta e inaffidabile. OData consente la sincronizzazione in tempo reale, CommerceML consente solo il caricamento periodico.

Modulo YandexFeed: generazione di un feed di prodotto per Yandex.Market. Sostituisce un plugin separato che costa da 2.000 a 5.000 rubli all'anno. Integrazione con il modulo B2B: puoi escludere dal feed i prodotti visibili solo ai grossisti. Integrazione con il modulo Campi personalizzati: i campi prodotto personalizzati vengono visualizzati nel feed come parametri.

E non ho ancora menzionato i moduli Confronta (confronto di prodotti), Lista dei desideri (lista dei desideri con notifiche su riduzioni di prezzo e resi in magazzino), Carrello Popup (carrello a comparsa), Menu inferiore (menu inferiore mobile), Editor CSS (editor CSS visivo), Cartelle multimediali (organizzazione di una libreria multimediale in cartelle), Pagina di accesso (pagina di accesso personalizzata), Inserisci codice (inserisci codice personalizzato - un analogo di frammenti di codice), Email (SMTP e registrazione email), Carica altro (scorrimento infinito del catalogo), Store Customizer (personalizzazione delle pagine WooCommerce), Swatches (campioni di colori per gli attributi), Activity Log (registro delle attività), Document Gallery (galleria di documenti e certificati sulla pagina del prodotto).

Non lo nasconderò: ciascuno di questi moduli ha funzioni che i concorrenti specializzati non hanno e funzioni che i concorrenti implementano in modo più approfondito. Questo va bene. Ma il punto non è battere ogni concorrente individualmente: il punto è dare al negozio un insieme funzionante invece che un insieme di parti disparate. E in questo “insieme” ogni modulo rafforza gli altri.

Quando un acquirente aggiunge un prodotto a una lista dei desideri, il modulo Lista dei desideri lo registra nel database, il modulo Analisi ne tiene conto nelle statistiche, il modulo Email si prepara a inviare una notifica quando il prezzo scende, il modulo Ricerca tiene conto della popolarità del prodotto quando classifica i risultati. Quattro moduli funzionano in modo sincrono, senza ritardi, senza duplicazione dei dati, senza conflitti. Prova a ottenere lo stesso risultato con quattro plugin indipendenti: ti auguro sinceramente buona fortuna.

Sapete cosa mi ha convinto di più della correttezza dell'approccio “un plugin invece di venti”? Non risparmiando denaro, non aumentando la produttività, ma semplificando gli aggiornamenti. In passato, quando veniva rilasciata una nuova versione di WooCommerce, iniziavo aprendo un elenco di venticinque plugin e verificando la compatibilità di ciascuno. Poi ho aspettato che tutti gli autori rilasciassero gli aggiornamenti. Poi ho aggiornato uno alla volta, controllando dopo ognuno. L'intero processo potrebbe richiedere una settimana. Ora sto aggiornando un plugin. Uno. Testiamo la compatibilità con la nuova versione di WooCommerce prima del rilascio, rilasciamo l'aggiornamento e il client fa clic su un pulsante. Se qualcosa va storto: un punto di contatto per il supporto, un registro delle modifiche per la verifica, un ripristino alla versione precedente. Non venticinque lettere a venticinque diversi servizi di supporto: una richiesta, una risposta, una soluzione.

Ho pensato a lungo a come concludere questo articolo e ho deciso di non chiuderlo con un bel “totale”, ma di dire questo. Lo zoo di plugin su WooCommerce non è un bug della piattaforma e non è inevitabile. Questo è il risultato di come l’ecosistema WordPress si è evoluto storicamente: ogni sviluppatore ha risolto un problema, ha confezionato la soluzione in un plugin e lo ha venduto. Ciò ha funzionato quando i negozi avevano bisogno di due o tre espansioni. Ma oggi, quando il negozio WooCommerce medio ha bisogno di quindici o venti estensioni, il modello “plugin per attività” sta iniziando a esplodere. Conflitti, prestazioni, costi di manutenzione: tutto questo cresce in modo non lineare con ogni plugin aggiunto. Due plugin: quasi nessun problema. Dieci sono tollerabili. Venti: passi più tempo a mantenere lo zoo che a far crescere la tua attività.

Non sto dicendo che ogni negozio WooCommerce dovrebbe immediatamente eliminare tutti i plugin e installare COS WP Woo. Se hai un piccolo negozio con cinque plugin e tutto funziona, per l’amor di Dio, non toccarlo. Ma se ti riconosci in questo articolo - se hai più di quindici plugin, se hai paura degli aggiornamenti, se ogni mese si rompe qualcosa, se la velocità di caricamento delle pagine lascia molto a desiderare, se paghi di più gli abbonamenti che l'hosting - pensa se è il momento di mettere le cose in ordine.

Prova COS WP Woo gratuitamente per 14 giorni. Installa, attiva i moduli necessari, guarda come funzionano nella tua combinazione. Migra i dati dai plugin attuali: per la maggior parte di essi abbiamo strumenti di migrazione direttamente nell'interfaccia. E se dopo due settimane ti rendi conto che un plugin può davvero sostituirne venti, rimarrai sorpreso di non averlo fatto prima. E se non funziona, non perderai nulla tranne un paio d’ore per i test. Ma sono disposto a scommettere che andrà bene.