WOOT

get_table_data() è registrata per gli utenti connessi e anonimi. Scorre $_REQUEST con uno switch e mantiene solo le chiavi note: post_type, per_page, orderby, order, current_page, table_id, wp_columns_actions, filter_data, filter_provider, fields, lang, predefinition e shortcode_args_set. I numeri passano da intval, le chiavi da sanitize_key, i payload JSON da json_decode e da un sanitizzatore ricorsivo.

Due di queste chiavi sono nomi di hook. wp_columns_actions viene passata ad apply_filters() per caricare il profilo delle colonne, e filter_provider seleziona il filtro woot_filter_provider_{name} che aggiunge le condizioni di filtro. Entrambe sono sanitizzate come testo ma non verificate rispetto a un elenco di nomi registrati.

La stessa funzione viene chiamata da PHP con un array per le tabelle disegnate al caricamento della pagina, così il percorso del server e quello AJAX condividono un'unica implementazione. Ogni riga è prodotta chiamando la closure di rendering di ogni colonna richiesta, con l'ID del prodotto conservato come pid per le azioni della cella.

Una voce di colonna come price porta 'orderby' => 'meta_value_num' e 'meta_key' => '_price'. get_table_data() cerca la chiave di ordinamento richiesta nel profilo delle colonne e riscrive da essa gli argomenti della query.

Il menu a tendina di ordinamento usa chiavi proprie (price-desc, sku, stock-desc, sales e così via), tradotte in un filtro woot_wp_query_args. Gli ordinamenti per giacenza e vendite totali escludono i prodotti raggruppati ed esterni con una clausola product_type NOT IN, perché quei tipi non hanno un valore proprio di giacenza o di vendite. Per gli ordinamenti del menu a tendina il plugin chiama anche WC()->query->get_catalog_ordering_args(), che collega le clausole di ordinamento proprie di WooCommerce per popolarità, valutazione e prezzo, così questi ordinamenti coincidono con la pagina del negozio.

Per orderby=post_status una closure viene aggiunta a posts_orderby prima di WP_Query e rimossa dopo, così le altre query della stessa richiesta mantengono il proprio ordinamento.

Il preset dei più venduti ordina per total_sales e quello dei più recenti per post_date, entrambi con posts_per_page impostato a N. WP_Query riporta found_posts per tutti i prodotti corrispondenti, quindi dopo la query found_posts viene impostato al limite del preset e il paginatore mostra solo i primi N.

Una regola di preset è memorizzata come stringa, per esempio product_cat:25,26|pa_color:19|rel:AND. get_by_taxonomy() la trasforma in un unico gruppo tax_query annidato e salta le tassonomie che non esistono più.

Per la variante di esclusione ogni clausola usa NOT IN e la relazione viene scambiata (AND diventa OR e viceversa), ovvero la legge di De Morgan: escludere i prodotti che corrispondono ad A e B significa mantenere quelli fuori da A oppure fuori da B. I preset SKU mappano lo SKU di una variazione all'ID del suo prodotto genitore, perché la tabella elenca i prodotti genitore.

admin-ajax.php viene eseguito fuori dal contesto linguistico del front-end. draw_table_data() scrive get_locale() nel JSON della tabella, il browser lo rimanda come lang e get_table_data() lo fa passare dal filtro woot_current_lang.

La classe del vocabolario si aggancia a quel filtro e chiama $sitepress->switch_lang(), così WP_Query restituisce i prodotti nella lingua giusta. I titoli delle colonne e le etichette sono tradotti da WOOT_Vocabulary::get() dalla tabella propria del plugin, caricata una volta per richiesta e indicizzata per locale.

WOOT_WooCommerce::action() restituisce il profilo. Ogni chiave è un campo con un titolo, una closure action che disegna la cella per un ID di prodotto, i dati di ordinamento (order, orderby, meta_key) e, per i campi filtrabili, le closure get_filter_query_args e get_filter_draw_data. L'indice 0 contiene le impostazioni a livello di tabella: tipo di contenuto, stati consentiti, filter provider.

I profili sono registrati per nome e risolti con apply_filters sull'azione della tabella. Il carrello, le variazioni, la vista del singolo prodotto e persino le schermate di amministrazione del plugin (elenco tabelle, chiavi meta, vocabolario) girano sullo stesso motore con i propri profili.

product_type, product_visibility, product_shipping_class e translation_priority di WPML vengono rimossi dall'elenco. La cella mostra i termini propri del prodotto tramite build_taxonomy_tree() limitato agli ID dei termini assegnati, come link o testo semplice secondo l'opzione di colonna.

Il lato filtro aggiunge una clausola tax_query il cui operatore (IN, NOT IN, AND) proviene dalle impostazioni della tabella ed è verificato rispetto a quella lista consentita.

Le chiavi meta sono memorizzate per tabella in woot_tables_meta con un tipo. assemble_meta_for_system() trasforma ciascuna in un campo del profilo: il testo ordina per meta_value e filtra con LIKE; il numero ordina per meta_value_num e filtra con un BETWEEN numerico su un cursore di intervallo; il calendario filtra come DATETIME o come timestamp unix numerico, scelto per campo, perché plugin come ACF memorizzano le date in formati diversi.

I campi vengono uniti al profilo tramite il filtro ext_{action}, e ogni chiave compare anche nel menu di ordinamento con voci crescente e decrescente.

Ogni closure di colonna ha bisogno dell'oggetto WC_Product, quindi get_product() conserva una mappa statica dei risultati di wc_get_product(). Le opzioni della tabella sono decodificate dal JSON una volta per tabella, le righe dei meta sono messe in cache in base all'md5 della stringa SQL, e il costruttore dei filtri risolve il profilo una volta invece che per ogni campo.

install.php crea woot_tables, woot_tables_columns (indicizzata per table_id e is_active, ordinata per pos_num), woot_tables_meta e woot_vocabulary. L'ordine delle colonne trascinate arriva come elenco di ID e viene riscritto come pos_num.

clone() copia la riga della tabella, poi le sue colonne e chiavi meta sotto il nuovo ID di tabella. L'esportazione scarica le quattro tabelle e le opzioni come JSON; l'importazione svuota ogni tabella e inserisce le righe, dopo un controllo di capability e nonce.

Quando il modulo del filtro viene costruito, un campo calendario viene duplicato sotto una chiave ---to con le etichette Da e A. Al ritorno provider() vede una chiave sconosciuta che termina con ---to, ne rimuove il suffisso e chiama la stessa closure di colonna con un flag, così la closure confronta con <= invece di >=.

Se un campo di intervallo non ha minimo o massimo configurati (-1), get_field_drawing_data() esegue SELECT MIN o MAX(cast(meta_value as UNSIGNED)) su postmeta per la chiave meta del campo tramite $wpdb->prepare. Il nome della funzione proviene da una lista consentita interna, non dalla richiesta. Il cursore del numero di commenti legge i propri limiti dalla tabella dei post.

I campi ricercabili provengono dallo shortcode ma vengono filtrati su post_title, post_content e post_excerpt. Ognuno diventa LOWER(field) LIKE %s con il valore sottoposto a escape da esc_like e associato da prepare.

Nel browser una ricerca parte con Invio solo quando l'input raggiunge il suo minlength, e un Invio vuoto o Esc rimuove il termine, il che evita che parole parziali troppo corte raggiungano il server.

Con filter_provider=woof lo shortcode cattura i dati della richiesta di WOOF nel JSON della tabella. A ogni chiamata AJAX il provider ripristina $_GET da esso, chiede tutti i risultati, chiama woof_products_ids_prediction() e legge woof_wp_query_ids, accettando un array o una stringa separata da virgole e mantenendo solo interi positivi. Nessun ID significa post__in = [0].

Il parametro page_mdf viene decodificato e MDTF viene eseguito con mdf_get_query_args_only, così restituisce argomenti di WP_Query invece di HTML. La clausola meta mdf_hide_post e quella di product_visibility vengono rimosse (WOOT aggiunge le proprie), l'ordinamento viene scartato e la query viene eseguita con fields=ids. L'elenco di ID viaggia come dati del filtro e diventa post__in.

add_to_cart.php controlla is_purchasable() e is_in_stock() e, quando la giacenza è gestita, richiede una quantità diversa da zero. Per i prodotti semplici il descrittore porta ID, giacenza e SKU; il client costruisce un input numerico con max impostato alla giacenza, reso di sola lettura per i prodotti venduti singolarmente, più una checkbox per l'aggiunta multipla.

I prodotti variabili e raggruppati hanno un pulsante che apre un popup con una tabella dei loro figli. I prodotti esterni rimandano all'URL esterno. I tipi sconosciuti passano dal filtro woot_woocommerce_add_to_cart così altri plugin possono fornire il markup.

L'URL dell'endpoint viene preso da wc_add_to_cart_params quando WooCommerce lo stampa, così gli endpoint AJAX personalizzati continuano a funzionare. La quantità viene confrontata con max prima dell'invio. Dopo il successo il plugin attiva wc_fragment_refresh, aggiorna le proprie informazioni sul carrello e, a seconda di un'opzione della tabella, reindirizza al carrello o al checkout.

Una checkbox nell'intestazione della colonna del carrello seleziona tutte le righe. add_to_cart_some() scorre gli articoli inviati. Per una variazione ricostruisce la mappa attribute_* da get_attributes('edit') e chiama WC()->cart->add_to_cart() con l'ID del genitore, la quantità, l'ID della variazione e quella mappa, che è la forma attesa dal carrello di WooCommerce.

WOOT_WooCommerceVariations::filter_provider() imposta post_type a product_variation e post__in ai figli del genitore dopo aver verificato che il genitore sia visibile al visitatore. Le tabelle di upsell, cross-sell, raggruppati e correlati condividono la classe base WOOT_WooCommerceUniversal e differiscono solo per la sorgente degli ID.

Nelle righe delle variazioni il titolo riceve in coda i nomi dei termini di attributo, e le colonne di tassonomia leggono lo slug di attributo proprio della variazione invece dei termini assegnati al post.

Il profilo woot_cart combina le colonne di prodotto configurate con quantità, subtotale (WC_Cart::get_product_subtotal) e rimozione. Ogni modifica del carrello risponde con una tabella del carrello aggiornata, il numero di articoli e il subtotale. Rimozione e aggiornamento trovano la riga del carrello tramite product_id o variation_id.

Il popup del carrello assume lo stile della tabella che lo ha aperto: il blocco di stile del genitore viene copiato e il suo ID di tabella sostituito con l'ID della tabella del popup. Un'opzione della tabella può anche nascondere i prodotti già nel carrello tramite post__not_in.

__hash_object() serializza request_data in JSON e lo riduce a un hash a 32 bit usato come chiave della cache. La cache è disattivata nelle modalità JSON e load-more, dove i dati sono già locali. Estensioni come compare e favourites inviano table23-reset-cache quando i loro dati cambiano.

Con la modalità to_json il server restituisce ogni riga (posts_per_page -1). Dopo la prima risposta la tabella passa da sé alla modalità json, e draw_data() costruisce SELECT ... WHERE ... ORDER BY ... LIMIT ... OFFSET e lo esegue con AlaSQL sull'array. Una tabella di una sola pagina trovata nella cache viene cercata e ordinata allo stesso modo.

Ogni tabella mantiene il proprio AbortController corrente. Una nuova richiesta di pagina, ordinamento o filtro interrompe quella in sospeso, così una risposta precedente lenta non può più sovrascrivere la pagina più recente.

Ogni tabella ha il proprio compact_view_width. Il listener di resize confronta il nuovo stato con il precedente e ridisegna solo in caso di cambiamento; un flag di blocco gli impedisce di scattare di nuovo per 999 ms. Le colonne marcate hide-on-mobile vengono saltate quando si costruiscono le intestazioni, l'intestazione flottante viene disattivata in modalità compatta e le regole media-hide per colonna sono generate come CSS per l'ID HTML della tabella.

get_theme_css() legge lo skin prima dalla cartella woot-skins del tema e poi dalla cartella skins del plugin, sostituisce il segnaposto tid con l'ID HTML della tabella ed elimina commenti e spazi superflui. Ogni regola è limitata a una sola tabella, così gli skin non si propagano tra le tabelle della stessa pagina.

draw_table_data() codifica la configurazione con JSON_HEX_QUOT e JSON_HEX_TAG così può stare dentro l'HTML senza uscire dall'elemento. Dopo che le righe sono state disegnate, do_after_draw() trova le tabelle dentro le celle e crea per ciascuna un'istanza di WOOT_GeneratedTables, senza la barra di scorrimento orizzontale.

Subito prima che WP_Query venga eseguita, post_status viene riportato a publish per chiunque non abbia read_private_posts, qualunque cosa abbiano chiesto la richiesta, lo shortcode o le impostazioni della tabella. Uno stato proveniente dagli argomenti dello shortcode è rispettato solo per tali utenti.

I tipi di contenuto non visualizzabili (coupon, ordini, template) sono rifiutati per gli utenti senza edit_posts, a meno che la tabella salvata sia stata costruita per quel tipo di contenuto da un amministratore.

Una funzione decide se un visitatore può vedere i dati di un post: i post pubblicati di tipi pubblici sono aperti, i tipi non pubblici richiedono diritti di modifica, gli altri stati richiedono read_post, e una variazione è visibile solo quando lo è il suo genitore. Le tabelle del singolo prodotto, delle variazioni, degli upsell e degli altri popup, lo shortcode della galleria e le estensioni la chiamano prima del rendering.

Lo skin può provenire da ?woot_skin=, dagli shortcode, dalle estensioni o dalle impostazioni della tabella, e tutti passano da get_theme_css(). Lì il nome viene ridotto con basename() e un filtro di caratteri che rimuove punti e slash, così non può puntare fuori dalle cartelle degli skin. L'ID HTML della tabella, che viene scritto nel CSS stampato, è filtrato allo stesso modo perché parentesi graffe o angolari non possano uscire dal blocco style.

get_smth() è pubblica. Il suo ramo generico chiama apply_filters su un nome proveniente dalla richiesta solo quando il nome inizia con woot_, e il call_id che lo accompagna viene ridotto a lettere, cifre, trattino basso e trattino prima che qualsiasi query a valle lo veda. Il ramo shortcodes_set rimuove ogni shortcode non presente nella lista consentita del plugin prima di do_shortcode(). I rami di esportazione e importazione richiedono manage_woocommerce.

I gestori di tabelle, colonne, meta e vocabolario controllano manage_woocommerce e woot_settings_nonce prima di scrivere. L'estensione degli allegati aggiunge un controllo di login e controlli edit_post a livello di oggetto.

I nomi delle colonne, i campi ORDER BY e le chiavi WHERE non possono essere associati con prepare(), quindi get_rows() li riduce a un insieme di caratteri sicuro, limita l'ordine a ASC o DESC e la logica ad AND o OR, e associa solo i valori.