BEAR

woobe_get_products() recebe start, length e order do DataTables e passa-os a WOOBE_PRODUCTS::gets(), que constrói a WP_Query. A ordenação por uma coluna meta passa a meta_value_num para os tipos number, timestamp e unix, e a meta_value nos restantes.

O tamanho da página está limitado a 100 linhas no modelo de definições, com o comentário de que páginas maiores causavam HTTP 500 em servidores fracos; na versão gratuita está fixo em 10. Quando a opção de variações está ativa, as variações de cada produto variável são consultadas e inseridas como linhas logo a seguir ao produto-pai.

woobe_get_fields() descreve cada coluna: field_type (field, meta, prop, taxonomy, attribute, downloads, gallery, upsells e outros), tipo de valor, vista de edição, sanitizador, tipos de produto a que não se aplica e visibilidade para gestores da loja. Os atributos globais e todas as taxonomias de produto são acrescentados em tempo de execução a partir de wc_get_attribute_taxonomies() e get_object_taxonomies().

update_page_field() despacha por field_type: update_post_meta para meta, setters de WC_Product mais save() para props, wp_set_post_terms para taxonomias, listas WC_Product_Attribute reconstruídas para atributos. As células da grelha, as reversões do Histórico e a maioria das escritas em massa terminam nesta função. As edições em massa de taxonomias e atributos escrevem os termos diretamente e disparam o mesmo hook do Histórico antes de escrever.

woobe_meta_get_keys() lê todas as chaves meta de um produto de amostra e subtrai as chaves internas do WooCommerce. Essa lista é uma propriedade protegida do data store de produtos, pelo que WOOBE_PDS_CPT estende o data store apenas para a devolver, acrescentando _button_text e _product_url.

As chaves meta são aparadas, mas não convertidas para minúsculas nem sanitizadas, porque as chaves reais escritas por outros plugins, como _woocs_sale_price_USD, distinguem maiúsculas de minúsculas.

woobe_extend_fields() transforma cada definição de meta guardada numa coluna; o tipo number recebe o sanitizador floatval e ordenação numérica. A mesma definição alimenta woobe_filter_numbers (intervalo de/até), woobe_filter_text (LIKE, =, !=, NOT LIKE, vazio, não vazio), filtros de interruptor e woobe_bulk_number (definir, aumentar ou diminuir por valor ou por percentagem).

Uma coluna de interruptor pode guardar valores diferentes de 1/0 (por exemplo yes/no) através de uma regra de substituição por chave lida por over_switcher_swicher_to_val(). A versão gratuita mantém os primeiros 2 campos meta.

process_jsoned_meta_data() reconstrói um valor meta a partir de pares keys/values para arrays e keys2/values2 para objetos, descodificando valores JSON aninhados, e recorre ao valor bruto para strings e números simples. O Histórico guarda esses valores como JSON com JSON_HEX_QUOT e JSON_HEX_TAG para que sobrevivam à ida e volta.

Os filtros e as configurações de edição em massa são mantidos entre pedidos por WOOBE_STORAGE. Com Redis ou Memcached, um transient vive apenas na cache de objetos e perde-se numa limpeza, pelo que o armazenamento por defeito é uma linha de opção woobe_memory_<user id>: cada chave tem a sua própria validade, as chaves expiradas são eliminadas na escrita, o autoload está desligado e a linha é apagada com o utilizador. Os modos session, transient e cookie continuam disponíveis através do filtro woobe_storage_type.

woobe_filter_products() guarda o formulário de filtro analisado em woobe_filter_<key>, onde a chave é uma string aleatória gerada em cada filtragem, de modo que a edição em massa por filtro funciona em vários separadores do navegador em simultâneo. Cada chamada a WOOBE_PRODUCTS::gets() passa os seus args por woobe_apply_query_filter_data(), que lê o filtro guardado e devolve tax_query, meta_query, post__in e post_status, e acrescenta hooks posts_where para o resto.

A paginação da grelha, a contagem da edição em massa, a contagem da exportação e as ferramentas de variações chamam todas gets(), pelo que não podem discordar sobre que produtos um filtro designa.

regular_price_where(), sale_price_where(), stock_quantity_where() e dimensions_where() consultam o postmeta tanto de product como de product_variation, depois leem o post_parent das variações encontradas e restringem a consulta principal aos pais mais as variações com ID IN (...).

Quando nada corresponde, a cláusula passa a ID = -1, de modo que uma correspondência vazia não devolve produtos em vez de devolver todo o catálogo, o que importa a um clique de uma edição em massa.

Os intervalos numéricos personalizados usam meta_query do tipo DECIMAL(30,20): um DECIMAL sem mais tem escala 0, pelo que uma pesquisa de 100 a 150 encontraria também 99.xx. O SQL de preços faz cast para DECIMAL(30,10).

Um peso vazio é guardado como '' e o MySQL lê '' como 0, pelo que os intervalos de preço e dimensões exigem meta_value <> '' e uma caixa vazia nunca conta como 0. Um extremo em falta de um intervalo fica aberto (substituído por -999999999 ou 999999999), e de igual a até significa exatamente esse valor.

posts_txt_where() divide o texto em ^; um prefixo ~ liga a parte com AND, um prefixo ! transforma-a em NOT REGEXP dentro de um grupo AND separado. Os comportamentos exact, begin, end, not e empty correspondem a = e a REGEXP ancorado; parênteses retos e chavetas de regex são escapados. Aplica-se ao título, conteúdo, excerto e slug.

O filtro de SKU aceita uma lista separada por vírgulas e constrói condições LIKE preparadas com esc_like, OR para os modos de correspondência e AND para 'not'.

Para o operador AND, cada termo torna-se a sua própria cláusula tax_query sob relation AND, porque uma única cláusula com operator AND pode não devolver produtos. Os operadores estão numa lista branca: IN, NOT IN, AND, EXISTS e NOT EXISTS; o WordPress ignora uma cláusula com operador desconhecido e corresponderia a todos os produtos.

A visibilidade no catálogo é traduzida em combinações dos termos de product_visibility exclude-from-catalog e exclude-from-search, e um filtro de estado de stock limita também product_type aos tipos que têm estado de stock.

woobe_bulk_products_count() guarda a configuração da edição em massa sob um bulk_key aleatório de 16 caracteres e devolve todos os IDs filtrados (fields=ids, sem paginação). __woobe_bulk_products() em bulk.js fatia essa lista e envia um lote após outro, atualiza a barra de progresso e chama woobe_bulk_finish no fim; o utilizador pode abortar o pedido em curso.

O tamanho do lote é number_posts_processed, de 10 a 100 por pedido, 30 por defeito, de modo que um servidor fraco pode trocar velocidade por estabilidade.

Paginar a consulta filtrada entre lotes saltaria produtos: uma edição de preço retira um produto de um filtro de preço e todos os offsets seguintes se deslocam. A lista de IDs obtida no início é mantida pelo cliente e cada pedido de lote envia os seus IDs explicitamente, sem a chave do filtro.

Após a execução, as linhas marcadas que já não aparecem na tabela redesenhada são retiradas da seleção, para que a ação seguinte não atinja produtos que o utilizador já não vê.

_process_number_data() aplica definir, aumentar ou diminuir por valor ou percentagem, e regras entre campos, como preço de saldo = preço normal menos uma percentagem. Depois uma fórmula opcional com outro campo meta (+, -, *, /, com proteção contra divisão por zero), depois um valor aleatório opcional num intervalo com casas decimais definidas.

update_page_field() arredonda nas casas decimais de preço da loja: a unidades inteiras, para cima até 0.05, até 0.1, ou para uma terminação fixa de cêntimos como .99. Os campos de texto aceitam acrescentar no fim, acrescentar no início, substituir (com ou sem distinção de maiúsculas) e marcadores como {TITLE}, {SKU}, {meta:key} e {attribute:pa_size}.

Numa execução em massa, um preço de saldo calculado que atinja o preço normal é ignorado e um valor de zero ou menos elimina o saldo. Uma escrita individual de um preço de saldo igual ou superior ao normal é limitada ao normal menos a menor unidade de preço.

Quando as datas de saldo são escritas, _price é definido de imediato para o preço que se aplica agora (saldo ainda não iniciado, em curso, terminado) e os transients do produto são limpos, em vez de esperar pela tarefa agendada de saldos do WooCommerce.

O WooCommerce lê os preços de um produto variável a partir das suas variações, pelo que um preço escrito no pai é ignorado e uma escrita de limpeza remove qualquer preço residual do pai. Um stock de 0 ou menos normalmente ativa a gestão de stock; isto não se faz num pai variável que não controla stock, onde deixaria sem stock todas as variações sem stock próprio, nem numa variação que vende a partir do stock do pai, que ficaria desligada dele.

O WooCommerce limpa quantidade, encomendas em espera e quantidade de stock baixo quando a gestão de stock é desligada. keep_stock_on_switch() guarda-os na sua própria meta e restaura-os quando a gestão é ligada de novo.

generate_combinations() constrói o produto cartesiano dos termos de atributo selecionados. Ao aplicá-lo, associa os atributos como atributos de variação, ignora as combinações que o produto já tem, copia os preços do pai, atribui a cada nova variação o SKU parent-SKU-<id> para evitar duplicados, e reordena as variações através do data store.

Editar, eliminar e exportar um subconjunto de variações compara os atributos de cada variação com as combinações escolhidas: chaves e valores ordenados, entradas '-1' tratadas como qualquer valor, e ambos os lados descodificados de URL porque os slugs de atributos não latinos são guardados codificados.

update_page_field() dispara woobe_before_update_page_field e WOOBE_HISTORY::write() lê o valor atual e codifica-o por tipo: IDs de termos, atributos, galeria e relações como JSON, downloads como nome/ficheiro/hash, estado de stock como 1/0, datas de saldo como datas ISO com o desvio do fuso horário, para que uma reversão restaure o calendário exato.

As linhas contêm field_key, product_id, prev_val, mod_date, bulk_key, user_id e via_mcp, indexadas por produto, bulk key e utilizador. Uma segunda tabela guarda uma cabeça por execução em massa: estado (concluída ou terminada), início, fim, número de produtos e as chaves dos campos.

Ligar a gestão de stock, ou um stock de 0 num produto sem controlo, faz o WooCommerce derivar o estado de stock; desligar a gestão elimina também a quantidade. update_page_field() regista stock_status, e stock_quantity quando necessário, como linhas extra logo a seguir ao campo editado.

stock_status_pair() e stock_row_at() encontram estas linhas por IDs adjacentes (+1, +2) e exigem o mesmo produto, autor, canal (manual ou através de um agente) e bulk key, e um tempo de escrita próximo. Depois revert() restaura a quantidade antes do estado, porque o WooCommerce deriva o estado a partir da quantidade enquanto o stock é gerido. Um stock anterior vazio significa 'sem controlo', pelo que untrack_stock() desliga a gestão em vez de escrever 0.

No separador Histórico, woobe_history_revert_bulk_portion() reverte 10 linhas por pedido AJAX com uma barra de progresso, e a linha de cabeça é eliminada quando o contador atinge o total. Cada reversão elimina a sua linha, pelo que a porção seguinte pega simplesmente no que sobra.

A ferramenta de reversão do MCP é um caminho separado: revert_bulk_portion() reverte até 200 linhas por chamada e comunica as linhas realmente removidas, porque as duas linhas de uma alteração de stock são revertidas em conjunto e uma porção pode levar mais uma linha do que o seu limite.

revert() remove primeiro todos os listeners de woobe_before_update_page_field, para que as próprias escritas da reversão não sejam registadas como novo histórico.

Cada linha tem user_id e via_mcp. A chave MCP de toda a loja escreve como utilizador -777, que nunca pode colidir com um utilizador real nem com 0 (sem sessão iniciada). scope() devolve uma única condição SQL usada por cada listagem, reversão, eliminação e limpeza, pelo que nenhuma consulta se pode afastar da regra.

Os handlers verificam solo_in_scope() ou bulk_in_scope() e respondem 403 a um pedido construído à mão para uma linha que o utilizador não pode ver. Os nomes dos autores para a lista são lidos numa única consulta.

CREATE TABLE IF NOT EXISTS nunca altera uma tabela que já existe. maybe_upgrade_schema() corre uma vez por versão do esquema (agora 2), verifica SHOW COLUMNS antes de cada ALTER para que um pedido concorrente não falhe, repete no carregamento seguinte se o ALTER falhar, e marca as linhas antigas do utilizador -777 como escritas através de um agente.

Na versão gratuita, prune_author() mantém as duas alterações individuais mais recentes e as duas execuções em massa mais recentes de um autor. As linhas que pertencem a uma alteração de stock mantida são mantidas com ela através de stock_change_rows(). A limpeza corre no shutdown após uma escrita, e abrir o separador nunca elimina linhas de outro utilizador.

woobe_export_products_count() limpa os ficheiros anteriores, escreve o cabeçalho CSV ou o esqueleto XML e devolve os IDs filtrados. woobe_export_products() acrescenta um lote por pedido com fopen(a+) e fputcsv, dado que o WP_Filesystem não consegue gravar linha a linha; para XML carrega o documento WXR e acrescenta nós item.

As variações são adicionadas depois do respetivo pai, opcionalmente sem as esgotadas, e podem ser limitadas ou excluídas por combinações de atributos.

get_csv_titles() escreve 'Attribute N value(s)', 'name', 'visible' e 'global' por atributo e 'Download N name' e 'URL' por posição de ficheiro, as colunas que o importador do WooCommerce lê; as colunas de meta chamam-se 'Meta: key'.

flatten_export_value() reduz arrays e objetos (termos, atributos, objetos de dados WC) a escalares unidos por '|', de modo que um tipo de coluna que o plugin nunca viu, incluindo um de terceiros, não escreve a palavra 'Array'.

O sufixo do nome do ficheiro tem de corresponder a um carimbo de data/hora ao minuto e recebe uma cauda de 12 caracteres de hash_hmac('sha256', postfix, wp_salt('auth')): idêntica em todos os pedidos de uma exportação, de modo que todos os lotes acabam num só ficheiro, mas impossível de adivinhar do exterior. A cauda importa no nginx, que ignora a regra deny do .htaccess.

woobe_export_download() verifica o nonce e a capability, aceita apenas nomes que a extensão gera, limpa todos os buffers de saída e envia com readfile() sem Content-Length. Os ficheiros com mais de 8 horas são eliminados, com verificação no máximo uma vez por hora.

Um clique no navegador não consegue enviar um cabeçalho Authorization, e a chave MCP é mantida fora dos URLs. A ferramenta de exportação guarda o nome do ficheiro sob um token aleatório num transient com 900 segundos de vida, e /woobe/v1/mcp/export/<token> serve apenas esse ficheiro.

woobe_find_products corre o filtro uma vez e guarda os IDs numa opção sem autoload (até 200,000 IDs, válida durante 24 horas). A resposta traz selection_id, count, uma amostra e whole_catalogue, medido contra uma consulta sem filtro, de modo que um filtro que não restringe nada é comunicado como tal.

woobe_apply_bulk não aceita qualquer filtro. Recusa, a menos que confirm_count seja igual ao tamanho da seleção, pelo que um agente que não leu o número não o consegue adivinhar. Os produtos criados depois do find não fazem parte da seleção.

O motor de filtros lê os campos do formulário do próprio editor e ignora qualquer outra chave. Um agente pode enviar uma chave com erro ortográfico ou uma data como {from, to}, e uma condição ignorada alargaria a seleção. WOOBE_MCP_FILTER verifica cada chave contra a lista de campos que o motor lê, recusa com a chave indicada e a forma aceite, e entrega o resto na forma que o ecrã envia.

O motor associa hooks posts_where que permanecem durante o resto do pedido, o que no ecrã é um carregamento de página mas pode ser vários finds num único lote JSON-RPC. release_filter_hooks() remove-os após cada consulta MCP, de modo que um find nunca herda as condições de outro. Os tipos dos argumentos são verificados contra o inputSchema de cada ferramenta, pelo que a string 'maybe' não é uma confirmação.

simulate() copia literalmente _process_number_data(), e run_chain() passa o resultado de cada operação à seguinte, de modo que um preço de saldo definido em conjunto com um novo preço normal é verificado contra o novo. A aritmética aplica-se apenas aos campos numéricos sobre os quais o motor calcula; qualquer outro campo é mostrado como uma simples substituição.

A pré-visualização devolve três contagens (seleção, afetados após expandir os pais para variações, graváveis) e avisos: percentagem de um campo vazio ignorada, pais variáveis sem preço próprio, stock sem controlo.

O ciclo de aplicação divide a fila em blocos de 25 e chama WOOBE_BULK::do_bulk(), o motor que o ecrã usa, até terem passado 20 segundos. Devolve next_offset e bulk_key; uma continuação escreve na mesma cabeça do Histórico, de modo que uma única reversão desfaz o trabalho todo. As caches são limpas uma vez após as escritas, não por bloco.

Na versão gratuita o bloco encolhe até ao limite de escrita restante: um token bucket de 100 produtos que se recarrega continuamente ao longo de 30 minutos, com tokens fracionários e um teto rígido, de modo que o tempo parado não pode pagar uma execução grande.

include_variations 'all' acrescenta todos os filhos dos pais encontrados; 'matching' mantém os filhos cujos valores de atributo correspondem a todos os termos pa_ do filtro ('amarelo e pequeno' é uma variação, não a união), contando um valor vazio como 'qualquer'. As categorias e etiquetas não conseguem restringir os filhos.

As chaves de atributos são construídas com sanitize_title(), como o WooCommerce as constrói, porque os nomes de atributos não latinos são guardados codificados em URL e sanitize_key() eliminá-los-ia. No modo matching, os pais variáveis são removidos da seleção para que um variations_only posterior não os expanda de novo a todas as variações.

WOOBE::init() corre em init, antes de REST_REQUEST estar definido, pelo que numa chamada REST não vê nem admin nem REST e não faria nada. bootstrap.php liga-se a rest_api_init por si e levanta o plugin; is_should_init() permite REST apenas para as rotas do próprio plugin, não para todo o tráfego REST do site.

Os conversores de moeda filtram os getters de preço, pelo que o agente lia preços convertidos; strip_price_filters() remove esses filtros apenas para o pedido MCP. Um produto colocado numa subcategoria é também colocado nas categorias ascendentes através de um listener de set_object_terms, dado que ninguém marca as caixas dos pais numa conversa.

Após um relatório do WPScan, todo o conjunto de handlers AJAX foi auditado, não apenas os assinalados, e todos os handlers passaram para WOOBE_HELPER::check_ajax_access(). Verifica o nonce, depois a capability, depois current_user_can('edit_post') para cada ID de produto.

As variações são verificadas contra o produto-pai: o WooCommerce mapeia edit_post numa variação para o simples edit_products, que ignora a propriedade, e as variações têm post_author 0. get_request_array() rejeita um escalar onde se espera um array em vez de o converter. Os papéis não administradores são ainda limitados por campo.

Com o MCP desligado, register_routes() devolve antes de registar o que quer que seja, pelo que o endpoint não existe. permission() exige a chave em cada pedido, incluindo o handshake MCP, de modo que quem chama sem autenticação não fica a saber nada sobre o endpoint. A chave é lida de Authorization: Bearer ou X-WOOBE-KEY, com o recurso REDIRECT_HTTP_AUTHORIZATION do Apache, e comparada com hash_equals.

As recusas usam 403, não 401: no MCP um 401 inicia a descoberta OAuth e o cliente comunica o servidor como avariado. As ligações de descarregamento e de carregamento usam tokens próprios de finalidade única porque um clique no navegador não consegue enviar um cabeçalho.

O assistente pede um token, composto por quatro grupos de oito letras e dígitos de random_int, e é confirmado por uma pessoa com sessão iniciada no WordPress: um administrador para a chave de toda a loja, o proprietário da chave nas suas próprias definições para uma chave pessoal. Para a chave de toda a loja este segundo fator é uma definição; para as chaves pessoais está sempre ativo. Apenas o seu hash sha256 é guardado, com as horas de confirmação e de último uso. check_connection() compara com hash_equals e termina a ligação após 3600 segundos sem uma chamada; a hora do último uso é escrita no máximo uma vez por minuto.

As ligações são por proprietário: um token confirmado para uma chave pessoal é recusado com qualquer outra chave.

Uma chave pessoal é woobe_<40 hex>-<user id>. personal_key_owner() lê e compara sempre a chave guardada com hash_equals, usando um valor fictício do mesmo comprimento quando o utilizador não tem nenhuma, e só consulta a lista de concessões e a capability depois de uma correspondência total, de modo que o tempo de resposta não diz a um estranho quem tem acesso. Os IDs com zeros à esquerda seguem o caminho do valor fictício.

O pedido corre depois como esse utilizador através de wp_set_current_user(), de modo que o seu papel e a visibilidade de campos se aplicam exatamente como no ecrã, e a ligação de dois fatores está sempre ativa nas chaves pessoais.

Cada ferramenta declara um setor e annotations.readOnlyHint. O proprietário devolve um mapa a partir do filtro woobe_mcp_permissions; '*' define o valor por defeito, pelo que funciona como lista de permissões. As entradas inválidas são registadas e ignoradas, e um '*' inválido recorre a full, tal como na ausência de callback. Para uma chave pessoal, cada setor é restringido de novo pela capability que o WooCommerce pede nesse ecrã (edit_products, edit_shop_orders, view_woocommerce_reports e outras).

As ferramentas que a identidade não pode chamar nem sequer são listadas. Uma escrita que cai noutro setor, como uma reversão que reescreve produtos, chama require_access() para esse setor antes de escrever. O filtro woobe_mcp_tool_allowed só pode restringir ainda mais. Nenhuma chave MCP, de toda a loja ou pessoal, pode escrever post_author ou ID; esses são editados no wp-admin por uma pessoa.