Jean Moura

OK! Obrigado

Olá Pessoal, Como faço para não exibir no cPanel dos meus clientes aquela opção (informações do servidor) que exibe: numero de cores, memoria usada e disco usado do servidor. Abraço Jean

mudou a versão do seu whmcs ou continuou a mesma?

Olá @daniloafk Conseguiu resolver o problema de lentidão no login da área de cliente? se conseguiu ensina qual foi a solução! Abraço

depois que loga na area do cliente, a navegação na area do cliente quando abre alguma opção continua lenta a navegação?

no meu caso apenas essa parte de acesso da area de cliente que estava lento para logar, depois que logava era rápido, mas para logar demorava muito

conseguiu atualizar o banco de dados?

no seu WHM vá no menu: Software » Upgrade do MySQL/MariaDB porem antes de atualizar o banco de dados, faça um backup completo do seu site via cPanel, para caso aconteça algum erro na atualização vc não ter dor de cabeça. também acesse seu admin do whmcs e mande otimizar TABELAS do banco de dados do seu whmcs através do menu abaixo: Utilitários > System > Status da Base de Dados

estava com este problema e atualizei meu banco do mysql 5.6 para MariaDB 10.1 e agora está rápido e normal o login da minha área de cliente

Esse golpe deve ser de algum politico tentando levantar dinheiro para a campanha de 2018, já que caixa 2 foi banido!

Olá @Otavio Pode me enviar! Abraço

Olá @Otavio Como vai? Vc fez o serviço de SEO conforme o amigo citou? Abraço

Pessoal, Aguem conhece ou já fez serviço com alguma empresa de SEO que não cobra uma fortuna para colocar o site nas primeiras paginas do google? Obrigado, Jean

apaga os cadastros inativos e os cadastros fechados?

Pessoal, 1 - Os cadastros inativos dos seus clientes no WHMCS, que são aqueles cadastros onde o cliente não tem mais uma hospedagem ativa porque a hospedagem foi cancelada do servidor por falta de pagamento ou o próprio cliente pediu o cancelamento, nestes cadastros no campo (Produtos/Serviços) vocês apagam o serviço que o cliente tinha ou deixa lá? 2 - E os cadastros com status de fechado, que são aqueles cadastros onde o cliente estava utilizando a hospedagem para alguma coisa ilícita e aí você cancelou a hospedagem e fechou o cadastro desta pessoa. Vocês apagam o cadastro desta pessoa do WHMCS ou deixa o cadastro lá com o status de fechado? Obrigado

@Rodrigo Henrik CPF e data de nascimento no formulário de pedido. Vc já afasta 99% dos picaretas, pois muitos conseguem CPF mas não tem a data de nascimento correta do CPFe qualquer novo pedido de hospedagem é só verificar manualmente no site da receita federal se o CPF e o nascimento estão corretos, caso não esteja, suspenda imediatamente a hospedagem informando que o CPF ou Nascimento está divergente. Pois pode existir algum futuro cliente que errou algum digito na hora do preenchimento das informações e provavelmente depois da suspensão da hospedagem irá corrigir o digito. Se ele não se manifestar quando vc suspender a hospedagem, já cancele a hospedagem e o cadastro pois é picareta e vai usar a sua hospedagem para coisas ilícitas. É assim que eu faço! Inclusive eu já informo no formulário de pedido que se o CPF ou Nascimento estiverem divergente o cadastro será automaticamente cancelado, assim eu reduzi 99% dos picaretas que mesmo com os campos CPF e Nascimento colocavam o CPF ou Nascimento errado pensando que não seria checado e a hospedagem seria liberada. Hoje eu recebo uma vez na vida um cadastro com CPF ou Nascimento errado de alguma pessoa que iria usar a hospedagem para coisas ilícitas, achando que não seria checado. Abraço

@Jorge Marcelino Na verdade eu não preciso nem dizer nas regras do Nginx as paginas pre-definidas que não devem entrar em cache EX: (/signup|/register|/logout|/user|/cadastro|/login|/carrinho|/cart|/pedido|/checkout|/cliente|/adm|/admin|/administracao|/administrator|/financeiro|/wp-admin|/wp-login.php|/minhaconta|/minha-conta|/conta|/myaccount|/my-account|/account) Pois essas linhas abaixo já informa nas regras do Nginx que paginas geradas através de (POST e STRING) não devem entrar em cache, então qualquer pagina dinâmica que muda informações constantemente são geradas com (POST e STRING) como carrinho de compras, área admin, área cliente, algumas paginas do site de fórum, algumas paginas do site de comercio eletrônico, dentre outras paginas que mudam valores a todo momento, não vão entrar em cache e assim evitar problemas com os clientes que possuem algumas paginas em seus sites que não podem entrar em cache. ----------------------------------------------- } # POST requests and urls with a query string should always go to PHP if ($request_method = POST) { set $CACHE_BYPASS_FOR_DYNAMIC 1; # Disables micro-caching set $CACHE_BYPASS_FOR_STATIC 1; # Disables static file caching } if ($query_string != "") { set $CACHE_BYPASS_FOR_DYNAMIC 1; # Disables micro-caching set $CACHE_BYPASS_FOR_STATIC 1; # Disables static file caching } -----------------------------------------------

Essa linha que vc está alterando não deve ser alterada o valor, pois é a linha que vai dar um bay passe no cache nas paginas que vc não quer que entre em cache como no exemplo abaixo. no meu exemplo abaixo não entra em cache esses diretórios já pre-definidos abaixo e nem as paginas dinâmicas geradas com (POST e nem string) ou seja, qualquer pagina que é gerada dessa forma não entra em cache, pois são paginas que mudam constantemente como paginas de fóruns, comercio eletrônico etc.. e não podem entrar em cache. EX: Edit your custom_rules for Nginx ----------------------------------------------- if ($SITE_URI ~* "/signup|/register|/logout|/user|/cadastro|/login|/carrinho|/cart|/pedido|/checkout|/cliente|/adm|/admin|/administracao|/administrator|/financeiro|/wp-admin|/wp-login.php|/minhaconta|/minha-conta|/conta|/myaccount|/my-account|/account") { set $CACHE_BYPASS_FOR_DYNAMIC 1; # Disables micro-caching set $CACHE_BYPASS_FOR_STATIC 1; # Disables static file caching } # POST requests and urls with a query string should always go to PHP if ($request_method = POST) { set $CACHE_BYPASS_FOR_DYNAMIC 1; # Disables micro-caching set $CACHE_BYPASS_FOR_STATIC 1; # Disables static file caching } if ($query_string != "") { set $CACHE_BYPASS_FOR_DYNAMIC 1; # Disables micro-caching set $CACHE_BYPASS_FOR_STATIC 1; # Disables static file caching } ----------------------------------------------- Você deve alterar o tempo do cache nas linhas das paginas dos menus abaixo? Edit proxy_params_dynamic proxy_cache_valid 200 10m; Edit proxy_params_static proxy_cache_valid 200 301 302 10m;

Olá @Jorge Marcelino Depois de vários testes eu cheguei no melhor tempo de 10 min para o cache dinâmico e estático, pois mesmo um site com poucas visitas, se tiver apenas 5 visitas a cada 10 minutos, apenas 1 visita será processada fora do cache o restante será entregue do cache e será 500x mais rápido . E não entra em cache carrinho de compras, área de admin, cliente e qualquer outra pagina que é atualizada a todo momento como fóruns, comercio eletrônico dentre outras paginas. E qualquer pagina que entra em cache e precisar ser atualizada pelo cliente em 10 minutinhos já estará atualizada no cache. Abraço

@Leonardox Valeu! Obrigado!

Você conhece algum tutorial que ensina como fazer essa integração para o WHMCS instalar o wordpress automaticamente na hospedagem? Já fucei tudo e não achei como configurar!

Olá Pessoal, Existe alguma forma de quando o whmcs criar a hospedagem, automaticamente já criar a hospedagem com o wordpress instalado? Existem algumas empresas que oferecem a hospedagem wordpress com 30 dias grátis e quando eu terminei a contratação a hospedagem foi criada e liberada automaticamente e já veio com o wordpress instalado! Abraços

1 min vem como padrão para os arquivos estáticos e 1s para os arquivos dinâmicos. A melhor configuração que achei e configurei para mim foi de 10 min para estáticos e dinâmicos Apague tudo do ( Edit your custom_rules for Nginx ) e cole tudo abaixo a partir do ######### ##################################################################### # === Place your custom Nginx rules here === # # [comments used below updated for Engintron v1.7.3] # # Some examples: # - HTTP to HTTPS redirect when using CloudFlare # - Setting up domains with dedicated IPs on the system # - Any other global rule (redirect or process) # ##################################################################### # === FOR USE WITH CLOUDFLARE === # For up to date info see the Engintron wiki at: https://github.com/engintron/engintron/wiki # # a) If your server has a single shared IP ONLY and you wish to use CloudFlare for any (or all) of your sites # you will have to specify this shared IP address below otherwise you'll get errors from CloudFlare. # This change will simply tell Nginx to skip DNS resolving and simply forward traffic to the shared IP. # Uncomment the following line if all your sites on the shared (main) IP of your server are on CloudFlare: # #set $PROXY_DOMAIN_OR_IP "XXX.XXX.XXX.XXX"; # Use your cPanel's shared IP address here # # b) If you utilize CloudFlare on a cPanel server with BOTH a shared IP and dedicated IPs for domains, you will # have to set the IP ONLY for each such domain at the "WHEN TO SPECIFY A DOMAIN IP" section lower in this file. # # c) It is possible to force-redirect all your domains on CloudFlare to HTTPS if you have SSL enabled # in CloudFlare's "Crypto" settings page. Make sure you use "Flexible SSL" there so CloudFlare proxies # traffic from HTTPS to Nginx's HTTP port (80). This way you can utilize Nginx's caching & performance # benefits to the fullest. If you use "Strict SSL" in CloudFlare's "Crypto" settings page, then CloudFlare # will proxy all HTTPS requests to your Apache's HTTPS port (443) and therefore you will miss any benefits # from Nginx's caching & overall performance features. # To redirect to HTTPS, simply remove ONLY the FIRST # character from each line of the following block # and make sure you set the domains you DO NOT want to automatically redirect to HTTPS. # # # === Protocol redirect handling when using CloudFlare [start] === # # set $redirToSSL ""; # if ($http_cf_visitor ~ '{"scheme":"http"}') { # set $redirToSSL "on"; # } # # # Set each domain you DO NOT want to automatically redirect to HTTPS when using CloudFlare only below # # and repeat the process with additional "if" blocks for more domains # # if ($host ~ 'domain-to-exclude-from-redirect.com') { # set $redirToSSL "off"; # } # if ($redirToSSL = "on") { # return 301 https://$host$request_uri; # } # # # === Protocol redirect handling when using CloudFlare [finish] === # === WHEN TO SPECIFY A DOMAIN IP === # By default, Nginx will redirect requests to the right domain IP by using DNS resolving. # However there are cases where you want to specify an IP for use with Nginx: # - When you use CloudFlare for certain domains only on your server, # regardless of whether these domains use the server's shared IP or a dedicated IP. # - When you are working on a domain which does not yet (DNS) resolve to your server, # but you want to access it by modifying your computer's "hosts" file. # # To specify the domain IP in such cases, simply enter a domain or subdomain in an "if" block # (as shown below) and inside that block set the appropriate shared or dedicated IP to point to. # # To specify the IP for a domain simply uncomment the following 3 lines and make sure you replace # example.com with your actual domain or subdomain and also replace XXX.XXX.XXX.XXX with the actual # IP assigned to that domain. To specify the IP for more domains, simply copy that "if" block # (per domain) and change accordingly. # #if ($host ~ "example.com") { # set $PROXY_DOMAIN_OR_IP "XXX.XXX.XXX.XXX"; #} # === DOMAIN AND URL PATH EXCLUSIONS FROM CACHING === # If you wish to exclude certain domains, subdomains or even full URL paths from micro-caching and/or # static file caching, simply specify them below and use a colon (|) character as a separator. # Remember that if you specify a "naked" domain name, e.g. mynicedomain.com, every subdomain e.g. # support.mynicedomain.com will also be excluded from caching. Decide wisely! # If you wish to disable ONLY micro-caching, then comment the line "set $CACHE_BYPASS_FOR_STATIC". # If you wish to disable ONLY static file caching, then comment the line "set $CACHE_BYPASS_FOR_DYNAMIC". # # Note: Don't include the "http://" portion of a URL. # if ($SITE_URI ~* "/signup|/register|/logout|/user|/cadastro|/login|/carrinho|/cart|/pedido|/cliente|/adm|/admin|/administracao|/administrator|/financeiro|/wp-admin|/wp-login.php|/minhaconta|/minha-conta|/conta|/myaccount|/my-account|/account") { set $CACHE_BYPASS_FOR_DYNAMIC 1; # Disables micro-caching set $CACHE_BYPASS_FOR_STATIC 1; # Disables static file caching } # POST requests and urls with a query string should always go to PHP if ($request_method = POST) { set $CACHE_BYPASS_FOR_DYNAMIC 1; # Disables micro-caching set $CACHE_BYPASS_FOR_STATIC 1; # Disables static file caching } if ($query_string != "") { set $CACHE_BYPASS_FOR_DYNAMIC 1; # Disables micro-caching set $CACHE_BYPASS_FOR_STATIC 1; # Disables static file caching }

Olá, Na opção: Edit your custom_rules for Nginx

OK Thiago! Agradecido pela ajuda!