Erro no campo telefone about full-checkout HOT 13 CLOSED

@Marusso Também tive esse problema, não sei se é o mesmo, mas ele não deixa digitar o último dígito do celular.
Não sei se é um problema do módulo de checkout ou do Magento.
De momento, eu resolvi escondendo esse campo com o "hide" e deixei o campo "fax" para captar o número de celular ou fixo.
E coloquei essa informação editando o "label"...

Só que resolvi isso usando um módulo que possibilita a edição desses campos.

from full-checkout.

Não é o mesmo problema e eu também não resolvi. O campo de telefone fica sem me deixar inserir o nr de ceular...
E acho que isso foi ocasionado pela instalação desse módulo que já desabilitei, mas deve ter criado alguma coisa no banco de dados que não conseguir achar...

from full-checkout.

@LuizSantos1
Como pode ver no conteúdo do módulo ele não tem nenhum db_schema.xml ou mesmo diretório de Setup, em outras palavras, nada é feito em seu banco de dados.

@Marusso Sobre o problema que reporta por favor verifique primeiro a sessão de suporte da Wiki do módulo, lá você encontrará orientações.

from full-checkout.

Ola Elisei

Já revisei todas as configurações da Wiki, porem continuo com o problema ainda

from full-checkout.

@LuizSantos1
Como pode ver no conteúdo do módulo ele não tem nenhum db_schema.xml ou mesmo diretório de Setup, em outras palavras, nada é feito em seu banco de dados.

@elisei Descobri que esse problema com a máscara vem do módulo BRAutocomplete, uma das empresas que desenvolveu esse módulo é a TechnoBR ou algo assim...

Eles criaram esse módulo (BRAutocomplete) com preenchimento de endereço via CEP e com as máscaras de telefone,
já para os campos CPF/CNPJ o módulo é o BRCustomer...

Mas eles por algum motivo, limitam o formato no campo "telephone" em (99) 9999-9999 e não permite
o formato (99) 99999-9999, este vai para o campo "cellphone"

Isso gera dois problemas
1 - O cliente que não tem telefone fixo, vai ficar tentando preencher o campo "telefone" como se fosse de celular,
e não vai conseguir.
2 - Se colocarmos esse campo como "opcional" ou escondê-lo, como eu tentei, aí temos problemas com módulos
de pagamento como o do RicardoMartins-PagSeguro, que vai pedir para preencher esse campo que é obrigatório.

Se o seu módulo de alguma forma se baseou nesses módulos, ele terá os mesmos problemas no campo "telephone"
porque essa máscara tem esse bug.

Acho que é por isso que vários clientes estão relatando o mesmo problema.

Eu fui verificar se era o seu módulo, desinstalei tudo e usei os módulos "BRAutocomplete" e "BRCustomer" para fazer a parte do autocompletar via CEP, em conjunto com o módulo Firecheckout e tive o mesmo problema no campo "telephone"...
Inclusive pensei que a máscara era deles, abri uma issue e eles me disseram que não usam máscara nesse campo... Inclusive vi na demo deles e realmente não tem essa máscara... Investiguei e descobri que vem desse módulo...

Infelizmente não tenho conhecimentos técnicos o suficiente para editar esse problema ou desabilitá-lo.

Então se o seu módulo se baseia nele de alguma forma, retifique esse problema ou desabilite a máscara de telefone.

Talvez você não consiga ver esse erro, porque não está usando um sistema de pagamento que exige o campo "telephone" original do Magento 2. Tente instalar o módulo do Ricardo Martins -Pagseguro, e você verá o problema.

Att
Luiz Santos

from full-checkout.

Um complemento:

Único modulo que estou utilizando é esse: https://github.com/m2-systemcode/BrazilCustomerAttributes

from full-checkout.

@Marusso
Então, eu não sei se esse módulo em questão, toca no campo "telephone" nativo do Magento.
Nos módulos da TechSpot que eu mencionei, ambos fazem isso. A minha pergunta ao @elisei
é se ele ao desenvolver o módulo dele, de alguma forma se baseou nos módulos da TechSpot, que são:
https://github.com/techspotbr/Techspot_Brcustomer
E
https://github.com/techspotbr/mage2_brautocomplete

Se ao criar o módulo fullcheckout ele incorporou esses módulos e não editou o bug da máscara,
com sistemas de pagamento que exigem o campo "telephone" nativo do Magento, ele irá ter problemas.
Pois por mais que você torne opcional ou até esconda e deixe apenas as extensões do campo "telephone" que são "custom_telephone" e "cellphone" criadas por esse módulo como padrão, não irá funcionar com sistemas de pagamento como o do RicardoMartins-PagSeguro, pois o módulo dele exige o campo "telephone" nativo do Magento.

O que eu também acho um exagero, pois nem é preciso telefone pra aprovar ou não uma compra e um fraudador
quando quer, cria um telefone qualquer, eles nem checam muito isso.

Mas enfim, relatei o problema ao RicardoMartins e pedi para ele ver se tem como remapear esse campo para algum outro qualquer, como ele fez no Magento 1.

O grande problema todo, é que não quero abrir mão dessa função, eu até tenho o autocompletar do Google no Firecheckout, mas ele é muito ruim.

Resumindo, tente desabilitar esse módulo e veja se o problema segue, se seguir, acredito que o módulo do Elisei já venha com o preenchimento de endereço via CEP com esse módulo incorporado, e esse bug no campo telefone seguirá.

Atenciosamente,
Luiz Santos

from full-checkout.

@LuizSantos1

Não, nosso módulo não se baseou nesses módulos. Ele baseado lá da nossa versão do nosso para magento 1...

Ajude-nos a manter esse código aberto e livre a todos na comunidade.
Leiam os tópicos de nossa Wiki analisem a aplicação do módulo em um ambiente limpo para somente então abrirem Issues como esses... Na prática ambos tentam usar 2 módulo para fazer a mesma coisa há de se esperar algum conflito.

from full-checkout.

@elisei
Oi, tudo bem?
Então, eu não abri a issue, mas achei a mesma pertinente, pois foi investigando a mesma e já sem
o seu módulo no meu site, que vi que um problema semelhante estava ocorrendo no meu ambiente de testes

E vi que o que está em comum são esses módulos.

Agora após a investigação, já indiquei de onde vem o problema e isso encoraja outros clientes
a testar seu módulo sabendo que o problema não é dele, mas de outros módulos.

Eu entendo que você diz pra testar o Fullcheckout sem outros módulos, mas entenda que num ambiente
de testes, nem sempre há como ter esse ambiente ideal, afinal, estamos sempre testando outros módulos,
como o preenchimento de CEP, campos CNPJ/CPF, meios de pagamento, etc...
Então nem sempre há como saber se um problema é de um determinado módulo ou outro.

Por exemplo, só fui identificar esse bug na máscara nesse módulo, quando fui testar com o meio
de pagamento PagSeguro do Ricardo Martins, e o motivo? É o único meio de pagamento que exige o campo telefone nativo do Magento.

Sendo assim, essa issue foi pertinente e importante, pois assim, outros clientes que venham a instalar
seu módulo, já saberão o motivo desse "bug". E não chutará o balde imaginando que o problema é com o Fullcheckout! kkkkkkkkk

SUGESTÕES DE MELHORIAS PARA O SEU MÓDULO

1 - Inclua um setup/config que permita habilitar e desabilitar o módulo pelo backend.
2 - Explique melhor na documentação como customizar o mesmo em temas de terceiros,
onde aparece "Como personalizar o layout
Em seu tema crie as pastas O2TI_FullCheckout/web/css/source e copie e edite o arquivo _module.less"
Criar essas pastas onde no tema? Explique melhor onde deveria ir essa estrutura de pastas e ficheiros
por exemplo, seira assim: "app/code/SeuTema/2TI_FullCheckout/web/css/source/_module.less"?
Pode parecer algo "óbvio" para quem lida com isso, mas para leigos ou pessoas não muito familiarizada,
isso pode nos confundir.

OFF TOPIC

Seu módulo no Magento 1, pelo menos para clientes brasileiros, é simplesmente o melhor que existe no mercado,
inclusive bem melhor que os pagos, pois eu já testei o da Amasty, Aheadworks, Ficheckout", "One Step Checkout", "IWD", etc...

No Magento 2, eu acho que o Firecheckout, ainda que a personalização no CSS não seja tão óbvia quanto
no da Amasty ou da Aheadworks, é o melhor até o momento. Simplesmente se integrou ao meu tema (Ultimo)
quase como se fosse "nativo". E tem um js bundling próprio que ajuda no carregamento da página de checkout que é um
pesadelo no Magento 2 nativo.

Aos brasileiros que estão pensando em gastar um rim no módulo a Aheadworks, já adianto, não façam essa besteira,
apesar de ser altamente customizável, ele simplesmente não permite sistemas de pagamento que não estejam autorizados
na lista deles. Pode ser que seja possível editar isso no módulo, eu não encontrei.
Além de ser bem pesadinho na minha opinião.

O da Amasty é muito bom, mas acho que cria campos em excesso sem necessidade no backend. Além de ficar
criando icones no menu e links para o marketplace deles, eu acho isso um pé no saco, você compra uma
módulo de checkout caro, e "ganha" de presente propaganda dos caras e um monte de ícones no menu, grids, fields
e tabelas desnecessárias. A minha ideia é deixar o admin panel mais clean possível, e não transformá-lo numa
escola de samba ou de outdoor de propaganda. Um dia eles vão aprender isso.

from full-checkout.

@LuizSantos1 Sim vejo que não foi você por isso o comentário é amplo a todos.

Grato pelas dicas, a primeira não vejo como adequada, o correto método desativar o módulo é pela bin da magento ou melhor ainda remover pelo composer. A segunda será adicionada.

OFF
A filosofia desse módulo não é nem de perto similar aos mencionados e não tem a menor intenção de ser nem no futuro. Nosso módulo não é um módulo para "One Step Checkout" e razão e medida em número de vendas de um modelo vs outro. Sobre aceleramento em um js bundling te recomendo a não buscar isso em um módulo de checkout e sim na aplicação inteira Magento Baler tá ai para isso.

from full-checkout.

@elisei
Já vi sobre o Magento Baler, inclusive estou monitorando com os dedos cruzados...
Mas ainda está em "early alpha", tem 22 issues, de momento vou ficar com as minhas dores de cabeça cotidianas... rs

Quanto ao js bundling, ele não é um requisito e nem tem pretensão de ser um padrão, a Firecheckout incluiu como um plus e uma opção, aí o cliente testa os dois cenários e vê o que mais lhe é benéfico. Não é padrão de empresas de módulos One Step Checkout, aliás, foi o único que vi com essa opção se não me engano.

Quanto a opção de habilitar e desabilitar via admin panel, de novo, acredito que você está pensando com a cabeça de desenvolvedor num cenário ideal de desenvolvimento e com procedimentos que são "ideais" ou mais "recomendáveis".

Do meu ponto de vista, ao cliente devemos sempre prever cenários não ideais onde o que é mais recomendável não é
possível ser seguido.

Por exemplo, o cliente/logista tem um problema com seu módulo ou com um módulo de pagamento ou qualquer outro módulo...
Se falo pra ele desabilitar via admin panel até que possa investigar e resolver tudo, dou as instruções, ele/a entenderá porque é um painel gráfico e intuitívo. É por isso que Windows que é muito pior que Ubuntu em termos de estabilidade e segurança, é mais popular e usado que outros sistemas operacionais. Simplicidade.

Se falo para abrir um terminal/putty, inserir o usuário ssh, password, ir até a root da instalação magento 2, digitar linhas de comando CLI para deixar a loja no modo developer, digitar a linha de comando para desabilitar, limpar blocos estáticos, dar um compile, outra pra limpar cache, e mudar isso tudo para production, etc... O logista vai achar que estou falando chinês e me xingará até a 3a geração da minha família...

from full-checkout.

@LuizSantos1

22 issues é nada o m2 tá com 1.7k, vá em frente, isso não deveria te assustar...

Esse módulo não está no marketplace da magento e sim github, um local para desenvolvedores, recomendo que nunca desative módulos pelo painel pois será parcial (vá no seu checkout e procure por paypal você o verá por lá) por isso um composer fazendo replace em alguns "modulos de core" é essencial para o bom tempo de carregamento da sua loja, métodos de pgto (ou de envio) tb geram isso mas de fato acaba sendo viável e por isso se faz necessário manter essa opção...

Um abraço, até!

from full-checkout.

@elisei
Obrigado por me dizer que o módulo não está no marketplace, e sim no Github, se não prestasse um pouco mais de atenção, teria me confundido... rs...
Eu até abro um sorriso quando vejo essa mania que alguns developers no Brasil tem de quase tomar como uma ofensa uma sugestão ou crítica
de um não-developer ou um "leigo"... Me lembro de um episódio que perguntei algo para o Mário Sam e ele me deu uma patada... Nunca mais
perguntei ou sugeri nada pra ele... Estranho que com o tempo esse temperamento dele o deixou menos relevante no que toca Magento no Brasil.

Gente, entenda uma coisa, developers desenvolvem ferramentas para facilitar a vida dos usurários, se um mecanismo pode facilitar
a vida do usuário pode ser implementado, por que não implementar? Ou simplesmente deixar claro, vamos implementar ou não vamos implementar
por falta de tempo pra desenvolver, ou porque não queremos desenvolver, etc...

Sim, eu sei que Paypal, e outros sistemas de pagamento mesmo desabilitados no admin, muitas vezes rodam em background, e o que é pior,
muitas vezes na página do produto ou nas categorias, home, etc... Esse é um erro na minha opinião do Magento 2, que deveria vir com
essa separação já de cara: JS, CSS ou HTMLs de sistemas de pagamento carregar só no checkout ou carregar na página do produto
somente quando tem a função "one-click" ou somente após o cliente clicar em "comprar". Isso tornaria o carregamento
das páginas mais rápido.

Agora mesmo tenho um Magento 1 sem muita otimização, que carrega com 3-4 segundos, e usa js externos da Yotpo e Elevio.
Ou seja, sem esses js, ela poderia carregar ainda mais rápido.

No Magento 2, mesmo sem nada disso, com um monte de ferramenta de otimização, o máximo que consegui foram 6 segundos, ou seja,
Magento 2 mesmo lançado em 2015, ainda não conseguiu resolver isso. Sim, se usar um servidor dedicado super poderoso, com 3GB de RAM,
etc... Vai rodar em menos de 2 segundos, mas é impressionante como uma ferramenta que supostamente é mais modular e robusta, consegue
ser 50% mais lenta em servidores menos potentes que o Magento 1...

Enfim, deixei as sugestões como forma de melhorar, você é dono do módulo, fica livre em adotá-las ou não.
Até porque, pode-se adotar a filosofia do: Quem não estiver satisfeito, que faça uma fork e implemente.

Apenas sugeri porque na minha opinião, ficaria um produto melhor acabado.

Um abraço e boa noite a todos!

Att
Luiz Santos

from full-checkout.