Novo plugin de loja online do WordPress

Algum tempo atrás, eu precisava criar uma loja online no WordPress. Existem muitas boas soluções no repositório oficial. Entre eles, o líder - Woocommerce há muito se destaca. Eu acho que ele não precisa de introdução. Um exército de milhões de usuários, centenas de extensões pagas e gratuitas e flexibilidade incrível. É por isso que o Woocommerce possui mais de 5 milhões de instalações ativas e cobre uma grande parte das lojas online em todo o mundo.

Ainda assim, decidi inventar minha bicicleta. Em parte, para aumentar as habilidades, em parte para tentar criar um plug-in de comércio eletrônico que não exige recursos e seja rápido o suficiente. Eu o publiquei recentemente no repositório oficial , portanto, convido todos a testá-lo. Neste artigo, não farei uma visão geral das possibilidades, mas falarei apenas de algumas soluções técnicas interessantes.

Permalinks Problem

Em geral, os links permanentes no WordPress são um dos sites mais difíceis, pois exigem a solução de vários problemas de conexões e dependências. O WpStore tem a capacidade de gerenciar links permanentes. Por exemplo, você pode remover o slug do product URL do product , mudar para o seu próprio país ou adicionar o slug da categoria ou até o aninhamento da categoria. Os links para produtos podem ser assim: ./-/---/---/-/ . Nada mal.

Eu tive que suar muito para aninhar as categorias. Usando a função wp_get_object_terms, obtemos as categorias do produto especificado e, no ciclo, coletamos os pontos fracos e formamos o URL de acordo com a hierarquia de pai para filho. Para exibir os links necessários, usamos o filtro post_link. Aqui está apenas parte do código (você pode ver o código completo na fonte):

 add_filter( 'post_link', 'wpsl_post_type_permalink', 20, 3 ); add_filter( 'post_type_link', 'wpsl_post_type_permalink', 20, 3 ); function wpsl_post_type_permalink( $permalink, $post_id, $leavename ) { .... /** * Works only in the admin panel when changing the structure of permanent links or creating/updating the product * In the frontend to display links to products using $post->guid * Relevant if the structure of permalinks are used %category% or %categories% */ if ( is_admin() ) { // get all terms (product categories) of this post (product) by hierarchicaly // change %category% if ( strpos( get_option( 'product_permalink' ), '%category%' ) !== false && $terms = wpsl_get_terms_hierarchicaly( $post->ID, 'product_cat' ) ) { $custom_slug = str_replace( '%category%', isset( $terms[0] ) && is_object( $terms[0] ) ? $terms[0]->slug : '', $custom_slug ); } // change %categories% if ( strpos( get_option( 'product_permalink' ), '%categories%' ) !== false && $terms = wpsl_get_terms_hierarchicaly( $post->ID, 'product_cat' ) ) { foreach( $terms as $term ) { $hierarchical_slugs[] = $term->slug; } $custom_slug = str_replace( '%categories%', implode( '/', $hierarchical_slugs ), $custom_slug ); } else { $custom_slug = str_replace( '%categories%', 'product', $custom_slug ); } } .... return $permalink; } 

Mas, nesse ponto, surgiu um problema de desempenho. O site começou a funcionar mais devagar, principalmente na página de saída de vários produtos. Por exemplo, na página de categoria com a saída de apenas 16 produtos, quase 90 consultas foram feitas no banco de dados e o tempo de resposta do servidor aumentou dramaticamente em cerca de 25 a 30%.

Aconteceu que, ao chamar a função _permalink, o WordPress realiza muitas operações: obtém o tipo de CNC e coleta os dados da postagem, dependendo desse tipo. Para exibir 1 link, o WordPress produz várias solicitações não armazenadas em cache no banco de dados. Além disso, o processo de obtenção de taxonomias e hierarquias de mercadorias não é o mais rápido.

Como a geração constante do link não nos convém, é lógico armazená-lo em algum lugar e depois puxá-lo a partir daí. Foi decidido usar o campo guid especial da tabela guid . Embora os desenvolvedores do WP não recomendem alterá-lo, ainda podemos ignorar esse aviso por vários motivos:

• O guid é usado para gerar RSS, e poucas pessoas o usam.
• somente as entradas são exibidas em RSS e nosso tipo de postagem é produto.

Para manter os links no banco de dados corretamente, penduraremos no evento save_post uma função que atualiza o campo guid:

 add_action( 'save_post', 'wpsl_guid_rewrite', 100 ); function wpsl_guid_rewrite( $id ) { if( !is_admin() ) return; if( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) return false; if ( strpos( get_option( 'product_permalink' ), '%category%' ) !== false || strpos( get_option( 'product_permalink' ), '%categories%' ) !== false ) { if( $id && get_post_type( (int)$id ) == 'product' ){ global $wpdb; $wpdb->update( $wpdb->posts, [ 'guid' => ( get_permalink( $id ) ) ], [ 'ID' => intval( $id ) ] ); } clean_post_cache( $id ); } } 

Resta interceptar a saída do link no gancho post_type_link e gerar a saída do link gerado:

 add_filter( 'post_type_link', 'wpsl_get_permalink_change', 10, 4 ); function wpsl_get_permalink_change( $post_link, $post, $leavename, $sample ){ if ( isset( $post->guid ) && $post->guid && $post->post_type == 'product' && ( strpos( get_option( 'product_permalink' ), '%category%' ) !== false || strpos( get_option( 'product_permalink' ), '%categories%' ) !== false ) ) { return $post->guid; } return $post_link; } 

Aqui, verificamos a abrangência do campo guid, tipo de post e tipo CNC. Se os valores dos três parâmetros forem adequados, exiba o link salvo anteriormente.

Agora, a melhor parte é: veja os resultados. O número de consultas ao banco de dados diminuiu quase duas vezes - de quase 90 para 44! E o tempo de resposta do servidor na hospedagem de teste caiu para 0,24 segundos aceitáveis.

A atualização do campo guid ocorre não apenas durante a criação e edição de mercadorias. O plug-in possui um sistema interno para importar mercadorias por meio do csv, portanto, a atualização também ocorre quando a importação é concluída.

Atualização: documentação do plugin