BEAR

woobe_get_products() riceve start, length e order da DataTables e li passa a WOOBE_PRODUCTS::gets(), che costruisce la WP_Query. L'ordinamento per una colonna meta passa a meta_value_num per i tipi number, timestamp e unix, altrimenti a meta_value.

Nel modello delle impostazioni la dimensione della pagina è limitata a 100 righe, con il commento che pagine più grandi causavano HTTP 500 sui server deboli; la versione gratuita è fissa a 10. Quando l'opzione delle variazioni è attiva, le variazioni di ogni prodotto variabile vengono interrogate e inserite come righe subito dopo il loro genitore.

woobe_get_fields() descrive ogni colonna: field_type (field, meta, prop, taxonomy, attribute, downloads, gallery, upsells e altri), tipo di valore, vista di modifica, sanitizzatore, tipi di prodotto a cui non si applica e visibilità per i shop manager. Gli attributi globali e tutte le tassonomie dei prodotti vengono aggiunti a runtime da wc_get_attribute_taxonomies() e get_object_taxonomies().

update_page_field() smista in base a field_type: update_post_meta per i meta, i setter di WC_Product più save() per le proprietà, wp_set_post_terms per le tassonomie, elenchi WC_Product_Attribute ricostruiti per gli attributi. Le celle della griglia, i ripristini dalla cronologia e la maggior parte delle scritture di massa finiscono in questa funzione. Le modifiche di massa a tassonomie e attributi scrivono direttamente i termini e attivano lo stesso hook della cronologia prima di scrivere.

woobe_meta_get_keys() legge tutte le chiavi meta di un prodotto campione e sottrae le chiavi interne di WooCommerce. Quell'elenco è una proprietà protetta del data store dei prodotti, quindi WOOBE_PDS_CPT estende il data store solo per restituirla, aggiungendo _button_text e _product_url.

Le chiavi meta vengono ripulite dagli spazi ma non convertite in minuscolo né sanitizzate, perché le chiavi reali scritte da altri plugin, come _woocs_sale_price_USD, distinguono maiuscole e minuscole.

woobe_extend_fields() trasforma ogni definizione di meta salvata in una colonna; il tipo number riceve il sanitizzatore floatval e l'ordinamento numerico. La stessa definizione alimenta woobe_filter_numbers (intervallo da/a), woobe_filter_text (LIKE, =, !=, NOT LIKE, vuoto, non vuoto), i filtri a interruttore e woobe_bulk_number (imposta, aumenta o diminuisci per valore o per percentuale).

Una colonna a interruttore può memorizzare valori diversi da 1/0 (per esempio yes/no) tramite una regola di override per chiave letta da over_switcher_swicher_to_val(). La versione gratuita mantiene i primi 2 campi meta.

process_jsoned_meta_data() ricostruisce un valore meta dalle coppie keys/values per gli array e da keys2/values2 per gli oggetti, decodificando i valori JSON annidati, e ripiega sul valore grezzo per stringhe e numeri semplici. La cronologia memorizza tali valori come JSON con JSON_HEX_QUOT e JSON_HEX_TAG, in modo che sopravvivano al passaggio di andata e ritorno.

I filtri e le configurazioni di modifica di massa vengono mantenuti tra le richieste da WOOBE_STORAGE. Con Redis o Memcached un transient vive solo nell'object cache e va perso a ogni svuotamento, quindi l'archiviazione predefinita è una riga di opzione woobe_memory_<user id>: ogni chiave ha la propria scadenza, le chiavi scadute vengono eliminate alla scrittura, l'autoload è disattivato e la riga viene cancellata insieme all'utente. Le modalità sessione, transient e cookie restano disponibili tramite il filtro woobe_storage_type.

woobe_filter_products() memorizza il modulo del filtro analizzato in woobe_filter_<key>, dove la chiave è una stringa casuale generata a ogni filtraggio, così la modifica di massa per filtro funziona in più schede del browser contemporaneamente. Ogni chiamata a WOOBE_PRODUCTS::gets() passa i propri argomenti da woobe_apply_query_filter_data(), che legge il filtro salvato e restituisce tax_query, meta_query, post__in e post_status, e collega gli hook posts_where per il resto.

La paginazione della griglia, il conteggio della modifica di massa, il conteggio dell'esportazione e gli strumenti per le variazioni chiamano tutti gets(), quindi non possono discordare su quali prodotti un filtro indichi.

regular_price_where(), sale_price_where(), stock_quantity_where() e dimensions_where() interrogano postmeta sia per product sia per product_variation, poi leggono post_parent delle variazioni corrispondenti e limitano la query principale ai genitori più le variazioni con ID IN (...).

Quando nulla corrisponde, la clausola diventa ID = -1, così una corrispondenza vuota non restituisce alcun prodotto invece dell'intero catalogo, il che conta a un clic da una modifica di massa.

Gli intervalli numerici personalizzati usano meta_query di tipo DECIMAL(30,20): un DECIMAL semplice ha scala 0, quindi una ricerca da 100 a 150 troverebbe anche 99.xx. L'SQL dei prezzi esegue il cast a DECIMAL(30,10).

Un peso vuoto è memorizzato come '' e MySQL legge '' come 0, quindi gli intervalli di prezzo e dimensioni richiedono meta_value <> '' e una casella vuota non vale mai 0. L'estremo mancante di un intervallo è aperto (sostituito da -999999999 o 999999999), e da uguale a a significa esattamente quel valore.

posts_txt_where() divide il testo su ^; un prefisso ~ unisce la parte con AND, un prefisso ! la trasforma in NOT REGEXP dentro un gruppo AND separato. I comportamenti exact, begin, end, not ed empty corrispondono a = e a REGEXP ancorati; le parentesi quadre e graffe delle regex vengono sottoposte a escape. Si applica a titolo, contenuto, riassunto e slug.

Il filtro SKU accetta un elenco separato da virgole e costruisce condizioni LIKE preparate con esc_like, OR per le modalità di corrispondenza e AND per 'not'.

Per l'operatore AND ogni termine diventa una propria clausola tax_query con relation AND, perché una singola clausola con operatore AND può non restituire alcun prodotto. Gli operatori sono limitati a una lista consentita: IN, NOT IN, AND, EXISTS e NOT EXISTS; WordPress scarta una clausola con operatore sconosciuto e corrisponderebbe a ogni prodotto.

La visibilità nel catalogo viene tradotta in combinazioni dei termini product_visibility exclude-from-catalog ed exclude-from-search, e un filtro sullo stato di magazzino limita anche product_type ai tipi che hanno uno stato di magazzino.

woobe_bulk_products_count() memorizza la configurazione della modifica di massa sotto un bulk_key casuale di 16 caratteri e restituisce ogni ID filtrato (fields=ids, senza paginazione). __woobe_bulk_products() in bulk.js divide quell'elenco in porzioni e invia un lotto dopo l'altro, aggiorna la barra di avanzamento e chiama woobe_bulk_finish alla fine; l'utente può interrompere la richiesta in corso.

La dimensione del lotto è number_posts_processed, da 10 a 100 per richiesta, 30 per impostazione predefinita, così un server debole può scambiare velocità con stabilità.

Paginare la query filtrata tra un lotto e l'altro farebbe saltare dei prodotti: la modifica di un prezzo sposta un prodotto fuori da un filtro sul prezzo e tutti gli offset successivi scorrono. L'elenco di ID preso all'inizio è conservato dal client e ogni richiesta di lotto invia esplicitamente i propri ID, senza la chiave del filtro.

Al termine dell'esecuzione, le righe selezionate che non compaiono più nella tabella ridisegnata vengono rimosse dalla selezione, così l'azione successiva non riguarda prodotti che l'utente non vede più.

_process_number_data() applica imposta, aumenta o diminuisci per valore o percentuale, e regole tra campi come prezzo in offerta = prezzo di listino meno una percentuale. Poi una formula facoltativa con un altro campo meta (+, -, *, / con protezione dalla divisione per zero), poi un importo casuale facoltativo in un intervallo con decimali impostati.

update_page_field() arrotonda nei decimali di prezzo del negozio: a unità intere, per eccesso a 0.05, a 0.1, oppure a una terminazione fissa in centesimi come .99. I campi di testo supportano accoda, anteponi, sostituisci (con o senza distinzione tra maiuscole e minuscole) e segnaposto come {TITLE}, {SKU}, {meta:key} e {attribute:pa_size}.

In un'esecuzione di massa, un prezzo in offerta calcolato che raggiunge il prezzo di listino viene saltato e un valore pari o inferiore a zero elimina l'offerta. Una singola scrittura di un prezzo in offerta uguale o superiore al listino viene ridotta al listino meno la più piccola unità di prezzo.

Quando vengono scritte le date dell'offerta, _price viene impostato subito sul prezzo valido ora (offerta non iniziata, in corso, terminata) e i transient del prodotto vengono cancellati, invece di attendere il job pianificato delle offerte di WooCommerce.

WooCommerce legge i prezzi di un prodotto variabile dalle sue variazioni, quindi un prezzo scritto sul genitore viene saltato e una scrittura di cancellazione rimuove qualsiasi prezzo residuo del genitore. Una giacenza pari o inferiore a 0 di norma attiva la gestione del magazzino; ciò non avviene su un genitore variabile che non tiene traccia della giacenza, dove metterebbe esaurita ogni variazione priva di giacenza propria, né su una variazione che vende dalla giacenza del genitore, che verrebbe così scollegata.

WooCommerce azzera quantità, ordini arretrati e soglia di scorta bassa quando la gestione del magazzino viene disattivata. keep_stock_on_switch() li salva in un proprio meta e li ripristina quando la gestione viene riattivata.

generate_combinations() costruisce il prodotto cartesiano dei termini di attributo selezionati. Applicandolo, gli attributi vengono collegati come attributi di variazione, si saltano le combinazioni che un prodotto ha già, si copiano i prezzi del genitore, a ogni nuova variazione si assegna lo SKU parent-SKU-<id> per evitare duplicati e le variazioni vengono riordinate tramite il data store.

Modificare, eliminare ed esportare un sottoinsieme di variazioni confronta gli attributi di ciascuna variazione con le combinazioni scelte: chiavi e valori ordinati, voci '-1' trattate come qualsiasi valore, ed entrambi i lati decodificati dall'URL perché gli slug degli attributi non latini sono memorizzati codificati.

update_page_field() attiva woobe_before_update_page_field e WOOBE_HISTORY::write() legge il valore corrente e lo codifica per tipo: ID dei termini, attributi, galleria e relazioni come JSON, download come nome/file/hash, stato di magazzino come 1/0, date delle offerte come date ISO con il proprio offset di fuso orario, così un ripristino riporta l'esatta pianificazione.

Le righe contengono field_key, product_id, prev_val, mod_date, bulk_key, user_id e via_mcp, indicizzate per prodotto, bulk key e utente. Una seconda tabella conserva una testata per ogni esecuzione di massa: stato (completed o terminated), inizio, fine, numero di prodotti e chiavi dei campi.

Attivare la gestione del magazzino, o una giacenza di 0 su un prodotto non tracciato, fa sì che WooCommerce ricavi lo stato di magazzino; disattivare la gestione elimina anche la quantità. update_page_field() registra stock_status, e stock_quantity quando serve, come righe aggiuntive subito dopo il campo modificato.

stock_status_pair() e stock_row_at() trovano queste righe tramite ID adiacenti (+1, +2) e richiedono lo stesso prodotto, autore, canale (a mano o tramite agente) e bulk key, e un tempo di scrittura ravvicinato. revert() ripristina poi la quantità prima dello stato, perché WooCommerce ricava lo stato dalla quantità finché la giacenza è gestita. Una giacenza precedente vuota significa 'non tracciata', quindi untrack_stock() disattiva la gestione invece di scrivere 0.

Nella scheda Cronologia, woobe_history_revert_bulk_portion() ripristina 10 righe per richiesta AJAX con una barra di avanzamento, e la riga di testata viene eliminata quando il contatore raggiunge il totale. Ogni ripristino elimina la propria riga, quindi la porzione successiva prende semplicemente ciò che resta.

Lo strumento di rollback MCP è un percorso separato: revert_bulk_portion() ripristina fino a 200 righe per chiamata e riporta le righe effettivamente rimosse, perché le due righe di una modifica di giacenza vengono ripristinate insieme e una porzione può prendere una riga in più del suo limite.

revert() rimuove prima tutti i listener di woobe_before_update_page_field, così le scritture del ripristino stesso non vengono registrate come nuova cronologia.

Ogni riga porta user_id e via_mcp. La chiave MCP valida per tutto il negozio scrive come utente -777, che non può mai collidere con un utente reale né con 0 (non connesso). scope() restituisce un'unica condizione SQL usata da ogni elenco, ripristino, eliminazione e svuotamento, così nessuna query può discostarsi dalla regola.

I gestori controllano solo_in_scope() o bulk_in_scope() e rispondono 403 a una richiesta costruita a mano per una riga che l'utente non può vedere. I nomi degli autori per l'elenco vengono letti con un'unica query.

CREATE TABLE IF NOT EXISTS non modifica mai una tabella già esistente. maybe_upgrade_schema() viene eseguita una volta per versione dello schema (ora la 2), controlla SHOW COLUMNS prima di ogni ALTER perché una richiesta concorrente non fallisca, riprova al caricamento successivo se ALTER fallisce, e segna le vecchie righe dell'utente -777 come scritte tramite un agente.

Nella versione gratuita prune_author() conserva le due modifiche singole più recenti e le due esecuzioni di massa più recenti di un autore. Le righe che appartengono a una modifica di giacenza conservata restano con essa tramite stock_change_rows(). La potatura viene eseguita allo shutdown dopo una scrittura, e aprire la scheda non elimina mai le righe di un altro utente.

woobe_export_products_count() cancella i file precedenti, scrive l'intestazione CSV o lo scheletro XML e restituisce gli ID filtrati. woobe_export_products() aggiunge un lotto per richiesta con fopen(a+) e fputcsv, perché WP_Filesystem non può scrivere in streaming riga per riga; per l'XML carica il documento WXR e aggiunge i nodi item.

Le variazioni vengono aggiunte dopo il loro genitore, facoltativamente senza quelle esaurite, e possono essere limitate o escluse tramite combinazioni di attributi.

get_csv_titles() scrive 'Attribute N value(s)', 'name', 'visible' e 'global' per ogni attributo e 'Download N name' e 'URL' per ogni slot di file, ossia le colonne lette dall'importatore di WooCommerce; le colonne dei meta si chiamano 'Meta: key'.

flatten_export_value() riduce array e oggetti (termini, attributi, oggetti dati di WC) a scalari uniti con '|', così un tipo di colonna che il plugin non ha mai visto, anche di terze parti, non scrive la parola 'Array'.

Il suffisso del nome del file deve corrispondere a un timestamp al minuto e riceve una coda di 12 caratteri da hash_hmac('sha256', postfix, wp_salt('auth')): identica per ogni richiesta di una stessa esportazione, così tutti i lotti finiscono in un solo file, ma non indovinabile dall'esterno. La coda conta su nginx, che ignora la regola deny di .htaccess.

woobe_export_download() controlla nonce e capability, accetta solo i nomi che l'estensione genera, svuota tutti i buffer di output e trasmette in streaming con readfile() senza Content-Length. I file più vecchi di 8 ore vengono eliminati, con un controllo al massimo una volta all'ora.

Un clic nel browser non può inviare un'intestazione Authorization, e la chiave MCP viene tenuta fuori dagli URL. Lo strumento di esportazione memorizza il nome del file sotto un token casuale in un transient con durata di 900 secondi, e /woobe/v1/mcp/export/<token> serve solo quel file.

woobe_find_products esegue il filtro una volta e memorizza gli ID in un'opzione senza autoload (fino a 200,000 ID, validi 24 ore). La risposta contiene selection_id, count, un campione e whole_catalogue, misurato rispetto a una query non filtrata, così un filtro che non restringe nulla viene segnalato come tale.

woobe_apply_bulk non accetta alcun filtro. Rifiuta l'operazione a meno che confirm_count sia uguale alla dimensione della selezione, così un agente che non ha letto il numero non può indovinarlo. I prodotti creati dopo la ricerca non fanno parte della selezione.

Il motore dei filtri legge i campi del modulo dell'editor e ignora qualsiasi altra chiave. Un agente può inviare una chiave scritta male o una data come {from, to}, e una condizione ignorata allargherebbe la selezione. WOOBE_MCP_FILTER controlla ogni chiave rispetto all'elenco dei campi che il motore legge, rifiuta indicando la chiave e la forma accettata, e consegna il resto nella forma inviata dalla schermata.

Il motore collega hook posts_where che restano per il resto della richiesta, che sulla schermata equivale a un caricamento di pagina ma può essere composta da più ricerche in un solo batch JSON-RPC. release_filter_hooks() li rimuove dopo ogni query MCP, così una ricerca non eredita mai le condizioni di un'altra. I tipi degli argomenti vengono controllati rispetto all'inputSchema di ciascuno strumento, quindi la stringa 'maybe' non è una conferma.

simulate() copia letteralmente _process_number_data(), e run_chain() passa il risultato di ogni operazione alla successiva, così un prezzo in offerta impostato insieme a un nuovo prezzo di listino viene verificato rispetto a quello nuovo. L'aritmetica viene applicata solo ai campi numerici su cui il motore calcola; qualsiasi altro campo è mostrato come semplice sostituzione.

L'anteprima restituisce tre conteggi (selezione, interessati dopo l'espansione dei genitori alle variazioni, scrivibili) e avvisi: percentuale di un campo vuoto saltata, genitori variabili senza un prezzo proprio, giacenza non tracciata.

Il ciclo di applicazione divide la coda in porzioni di 25 e chiama WOOBE_BULK::do_bulk(), il motore usato dalla schermata, finché non sono trascorsi 20 secondi. Restituisce next_offset e bulk_key; una continuazione scrive nella stessa testata della cronologia, così un solo rollback annulla l'intero lavoro. Le cache vengono svuotate una volta dopo le scritture, non a ogni porzione.

Nella versione gratuita la porzione si riduce alla quota di scrittura residua: un token bucket di 100 prodotti che si ricarica in modo continuo in 30 minuti, con token frazionari e un tetto rigido, così il tempo di inattività non può pagare una grande esecuzione.

include_variations 'all' aggiunge ogni figlio dei genitori trovati; 'matching' mantiene i figli i cui valori di attributo corrispondono a tutti i termini pa_ del filtro ('giallo e piccolo' è una sola variazione, non l'unione), con un valore vuoto che vale 'qualsiasi'. Categorie e tag non possono restringere i figli.

Le chiavi degli attributi sono costruite con sanitize_title(), come le costruisce WooCommerce, perché i nomi di attributo non latini sono memorizzati con codifica URL e sanitize_key() li eliminerebbe. In modalità matching i genitori variabili vengono rimossi dalla selezione, così un successivo variations_only non li espande di nuovo a tutte le variazioni.

WOOBE::init() viene eseguita su init, prima che REST_REQUEST sia definita, quindi in una chiamata REST non vede né l'admin né REST e non farebbe nulla. bootstrap.php si aggancia da sé a rest_api_init e avvia il plugin; is_should_init() consente REST solo per le route del plugin, non per tutto il traffico REST del sito.

I selettori di valuta filtrano i getter dei prezzi, quindi l'agente leggeva prezzi convertiti; strip_price_filters() rimuove quei filtri solo per la richiesta MCP. Un prodotto inserito in una sottocategoria viene inserito anche nelle categorie antenate tramite un listener di set_object_terms, dato che in una chat nessuno spunta le caselle dei genitori.

Dopo una segnalazione di WPScan l'intero insieme dei gestori AJAX è stato sottoposto ad audit, non solo quelli segnalati, e ogni gestore è stato spostato su WOOBE_HELPER::check_ajax_access(). Questa controlla il nonce, poi la capability, poi current_user_can('edit_post') per ogni ID di prodotto.

Le variazioni vengono controllate rispetto al prodotto genitore: WooCommerce mappa edit_post su una variazione a un semplice edit_products, che ignora la proprietà, e le variazioni hanno post_author 0. get_request_array() rifiuta uno scalare dove è atteso un array invece di convertirlo. I ruoli non amministratori sono inoltre limitati per campo.

Con MCP spento, register_routes() ritorna prima di registrare qualsiasi cosa, quindi l'endpoint non esiste. permission() richiede la chiave a ogni richiesta, compreso l'handshake MCP, così un chiamante non autenticato non apprende nulla sull'endpoint. La chiave viene letta da Authorization: Bearer o X-WOOBE-KEY, con il ripiego Apache REDIRECT_HTTP_AUTHORIZATION, e confrontata con hash_equals.

I rifiuti usano 403, non 401: in MCP un 401 avvia la scoperta OAuth e il client segnala il server come guasto. I link di download e di upload usano propri token monouso perché un clic nel browser non può inviare un'intestazione.

L'assistente chiede un token, composto da quattro gruppi di otto lettere e cifre generati con random_int, e questo viene confermato da una persona connessa a WordPress: un amministratore per la chiave valida per tutto il negozio, il proprietario della chiave nelle proprie impostazioni per una chiave personale. Per la chiave valida per tutto il negozio questo secondo fattore è un'impostazione; per le chiavi personali è sempre attivo. Viene memorizzato solo il suo hash sha256 con gli orari di conferma e di ultimo utilizzo. check_connection() confronta con hash_equals e chiude la connessione dopo 3600 secondi senza chiamate; l'orario dell'ultimo utilizzo viene scritto al massimo una volta al minuto.

Le connessioni sono per proprietario: un token confermato per una chiave personale viene rifiutato con qualsiasi altra chiave.

Una chiave personale è woobe_<40 hex>-<user id>. personal_key_owner() legge e confronta sempre la chiave memorizzata con hash_equals, usando un valore fittizio della stessa lunghezza quando l'utente non ne ha una, e interroga l'elenco delle autorizzazioni e la capability solo dopo una corrispondenza completa, così il tempo di risposta non dice a un estraneo chi ha accesso. Gli ID con zeri iniziali prendono il percorso del valore fittizio.

La richiesta viene poi eseguita come quell'utente tramite wp_set_current_user(), così il suo ruolo e la visibilità dei campi si applicano esattamente come sulla schermata, e la connessione a due fattori è sempre attiva per le chiavi personali.

Ogni strumento dichiara un settore e annotations.readOnlyHint. Il titolare restituisce una mappa dal filtro woobe_mcp_permissions; '*' imposta il valore predefinito, quindi funziona come lista consentita. Le voci non valide vengono registrate nel log e ignorate, e un '*' non valido ripiega su full, come nessuna callback. Per una chiave personale ogni settore viene ulteriormente ristretto dalla capability che WooCommerce richiede per quella schermata (edit_products, edit_shop_orders, view_woocommerce_reports e altre).

Gli strumenti che l'identità non può chiamare non vengono affatto elencati. Una scrittura che finisce in un altro settore, come un rollback che riscrive i prodotti, chiede a require_access() quel settore prima di scrivere. Il filtro woobe_mcp_tool_allowed può solo restringere ulteriormente. Nessuna chiave MCP, valida per tutto il negozio o personale, può scrivere post_author o ID; questi si modificano in wp-admin da una persona.