Fábio

Fiz um teste na minha loja aqui e o pre?o no checkout sempre é alterado quando troco o CEP. N?o será problema com o template?

Fala Claudio,

desculpe a insistência, mas esse problema está cada vez mais complicado de lidar.
Hoje vou dar uma olhada no funcionamento todo pra tentar achar uma solu??o, mas se puder, dá uma help pra geral aê!

abs

Já tentou com classes de entrega?
Edit: Ops! Reli e acho que o que falei n?o tem a ver com sua dúvida.

• This reply was modified 7 years, 3 months ago by Fábio.

Fala pessoal,
Essa é realmente uma quest?o importante.
N?o sei se ajuda a resolver, mas seguinte.

O Frete Grátis assume a entrega em PAC, correto?

Como o Correios mudou o esquema de entrega deles e agora CEPs de localidades próximas aceitam apenas SEDEX, rola o seguinte impasse.

Cliente tem frete grátis acima de R$300.

Ent?o, Carrinho bateu R$300, op??o de Frete Grátis aparece.
Mas o CEP está dentro do range de CEPs que só aceitam SEDEX.

Teria que ter uma forma (talvez um filter) de verificar se está disponível a op??o de PAC e só aí apresentar a op??o de Frete Grátis.

Verifique todo o resto do site antes de apontar um plugin como responsável dos problemas do seu site. O plugin faz o que se prop?e a fazer de maneira clara e objetiva.

Sim, caso resolvido depois das configura??es alteradas.

Obrigado pela ajuda.

abs

Bingo, Alex.

O problema todo era o fato de n?o estar usando FastCGI no servidor.

Opa Alex,
ainda n?o testei essa última ideia sua, mas me ocorreu uma coisa.

Atualmente n?o uso FastCGI no servidor. Tive que usar certas configura??es que n?o s?o compatíveis com ele. Poderia ser este um motivo?

Passo pelo mesmo problema. Gera confus?o, cliente volta pra pagar e vez ou outra tenho que estornar um pagamento que foi duplicado. é curioso isso acontecer, já que o comportamento deveria ser proibir novo pagamento depois de já constar como pago. Talvez seja um problema de timing do script/envio/resposta do webservice.

O esperado é algo assim?

Inclui esses filtros que vc sugeriu no functions.php mesmo.
Aí no debug veio esses tempos:

[09-Nov-2017 04:51:35 UTC] hook http_request_args: 1510203095
[09-Nov-2017 04:51:46 UTC] hook http_response: 1510203106
[09-Nov-2017 04:51:46 UTC] PHP Notice: Undefined index: response in /home/puravida/public_html/wp-content/plugins/woocommerce-correios/includes/class-wc-correios-webservice.php on line 558
[09-Nov-2017 04:51:46 UTC] hook http_request_args: 1510203106
[09-Nov-2017 04:51:49 UTC] hook http_response: 1510203109
[09-Nov-2017 04:51:49 UTC] PHP Notice: Undefined index: response in /home/puravida/public_html/wp-content/plugins/woocommerce-correios/includes/class-wc-correios-webservice.php on line 558

Aí dei uma olhada no request e escolhei um dos filtros pra testar novamente. Foi o abaixo:

add_filter( ‘pre_http_request’, ‘test_http_3’, 10, 3 );
function test_http_3( $response, $r, $url ){
error_log( ‘hook pre_http_request: ‘ . time() , 0);
return $r;
}

Agora o comprar responde em 2 a 2,5s. Só por ter colocado esse filtro pre_http_request
Estou deixando tudo pronto para a requisi??o antes de fazer ela?
Faz sentido? o_O

Edit: A inclus?o no carrinho é rápida, porém descobri que o pedido n?o calcula mais o frete e n?o passa nenhum pedido por isso. N?o funcionou.

• This reply was modified 7 years, 3 months ago by Fábio.

Vamos lá… colhi mais alguns dados, agora usando o Query Monitor:

Eu achei que o problema era apenas nas chamadas com o add-to-cart com ajax na home, mas acontece qdo adiciono um produto diretamente na página do produto em si.

Veja o que ele me mostra quando adiciono um produto. Aqui levou certa de 25s até finalizar o carregamento, sendo que 23s é do correio.

Veja nessa imagem: https://camaleoa.com/chamada-correios.png

Curiosamente, se eu fa?o a chamada na API, a resposta é bem rápida. Abaixo est?o as duas para teste:

Essa é a primeira, que demora 20s
https://ws.correios.com.br/calculador/CalcPrecoPrazo.aspx?nCdServico=04669&nCdEmpresa=14448769&sDsSenha=12966706&sCepDestino=05414001&sCepOrigem=06612280&nVlAltura=2&nVlLargura=11&nVlDiametro=0&nVlComprimento=16&nVlPeso=1,5&nCdFormato=1&sCdMaoPropria=N&nVlValorDeclarado=0&sCdAvisoRecebimento=N&StrRetorno=xml

E essa é a segunda, que demora 2s
https://ws.correios.com.br/calculador/CalcPrecoPrazo.aspx?nCdServico=04162&nCdEmpresa=14448769&sDsSenha=12966706&sCepDestino=05414001&sCepOrigem=06612280&nVlAltura=2&nVlLargura=11&nVlDiametro=0&nVlComprimento=16&nVlPeso=1,5&nCdFormato=1&sCdMaoPropria=N&nVlValorDeclarado=0&sCdAvisoRecebimento=N&StrRetorno=xml

Algum ideia de onde vem essa lentid?o?

Obrigado pela resposta Alex,
De fato, estava ativo a depura??o, mas mesmo desativando, n?o mudou nada. Ativei a depura??o e n?o há qualquer men??o de erro relacionado ao plugin. Existem outros warnings do woocommerce que est?o aparecendo aos montes ultimamanete de fun??es depreciadas, mas mesmo assim n?o parecem ter rela??o com o problema.

Sim, Claudio. Já notei e desisti. Na verdade, fiz novos testes e o que parece é que o pagar.me está falhando na entrega (ou o plugin n?o trata um tipo de informa??o que ele manda)

Montei um log de tudo que entrada pelo pagar.me e notei que as transa??es que pagam um pedido, de fato n?o passaram pelo plugin.

O fluxo que entendi é o seguinte:
Cliente faz o pedido, paga e é recusado. Ent?o ele é informado por e-mail que o pedido teve o pagamento recusado e é enviar para a página onde se faz o pagamento do mesmo pedido. é criado uma nova transa??o e essa nova transa??o n?o é enviada pro woocommerce. Tenho criado alguns logs pra pegar mais info.

Aqui continuo com o problema.
Foi feita alguma atualiza??o no plugin?

A quem interessar, estou fazendo o que sugeri acima mesmo.
Modifiquei o arquivo /includes/class-wc-pagarme-api.php na linha 796 da seguinte forma:

case ‘processing’ :
//$order->update_status( ‘on-hold’, __( ‘Pagar.me: The transaction is being processed.’, ‘woocommerce-pagarme’ ) );
$order->update_status( ‘processing’, __( ‘Pagar.me: The transaction is being processed.’, ‘woocommerce-pagarme’ ) );

Mantive o original comentado até me certificar de que tudo corre bem, mas basicamente mudei o status no update_status para ‘processing’.
Rodei assim o dia todo aqui, o que deve dar em torno de uns 150 pedidos e n?o rolou nada estranho. Pelo contrário. Me parece que resolveu mesmo. Vários pedidos que antes iam de falhado para aguardando agora est?o indo para processando.

@claudiosanches, dá um salve aí pra confirmar, por favor.