fsanches.com – fsanchesdev

Categoria: Uncategorized

  • Dicas para montar um layout que não quebra #1

    Neste artigo vou apresentar 10 dicas de construção para layouts que eu como desenvolvedor back-end gostaria de ter aprendido logo quando comecei a me aventurar no front-end!

    Porém, vou deixar tudo aqui, resgistrado para você não sofrer com o que eu sofri.

    Dicas para a construção de um layout web que não quebra:

    Algura e largura com vh e vw

    Para acomodar blocos de layout de forma que ocupem a totalidade da página, ao invés de %, use as unidades de medida vh (viewport height) e vw (viewport width).

    Um elemento HTML <div> com width de 25vw, vai ocupar 25% da largura da área disponível no navegador.

    A questão com a unidade % é que ela é relativa, e ajusta as dimenões dos elementos filhos com base em seu elemento pai, o que nos obriga muitas vezes a ter de definir um tamanho explicito ao elemento pai.

    Já trabalhar com vw e vh vai ajustar sempre seus itens de layout com base no tamanho do viewport, bastante você calcular quando da altura e largura disponíveis na tela do navegador quer dar aos seus objetos, sem se preocupar com hierarquias para isso.

    Largura de colunas com ch

    Eu simplesmente adoro usar a unidade ch (character unit) para definir a largura das colunas de uma tabela, especialmente as colunas estreitas e de tamanho máximo previsível, como as de id numérico.

    Então suponhamos que você sabe que sua tabela vai retornar no máximo 4 dígitos de registros (1 – 9999), você pode usar 4ch na coluna id, para delimitar a largura desta coluna exatamente a quatro caracteres.

    Ou melhor ainda, você pode ajustar com js o css width desta coluna para a largura do maior registro retornado. Ou seja, se seu maior registro retorna do foi o id 57 que tem dois digitos, defina dinamicamente 2ch, se for 500 que tem três dígitos defina 3ch, e assim por diante.

    Já no caso de colunas mais largas, como as de nome e endereço, as quais faria menos sentido prever um tamanho de largura ideal, você pode dividir a porcentagem de 100% entre elas. Ou seja, divida 100% de largura entre todas as outras colunas que não usem ch.

    A melhor forma de sobrescrever estilos css

    Muitas vezes precisamos sobrescrever estilos CSS. A melhor forma de fazer isso é inserir um arquivo de estilos como custom.css após a chamada do arquivo principal de CSS.

    Porém se você não puder fazer essa chamada no local correto, que seria dentro da seção <head>, prefira então usar ccs inline direto no HTML.

    De forma alguma abra tags <style> no <body>, isso funciona mas é incorreto, por isso não há garantias de que os navegadores vão tolerar isso em futuras versões, além de é claro deixar o código estrutural feio e confuso.

    Por fim, você também pode usar JS para alterar o estilo desejado. Só recomendo sempre, evitar misturar todas as técnicas disponíveis, procure escolher um padrão.

    Como organizar seu arquivo CSS

    Não é raro começar a adicionar código ao seu arquivo CSS e de repente se perder em sua organização. Por isso abaixo deixa uma ordem para manter as coisas:

    • Reset ou normalize (margin, padding, etc)
    • Variáveis / root
    • Layout geral (header, footer, main)
    • Componentes reutilizáveis (menus, botões, cards, formulários)
    • Helpers/utilitários (classes prontas para diversos usos)
    • Media queries (repita tudo o que fez para a versão desktop, para o mobile)

  • w2ui Themes


    A abordagem básica para usar temas no w2ui é vincular o w2ui.css e então vincular algum tipo de w2ui-custom.css, onde você pode substituir os estilos básicos com base em suas necessidades.

    Tal abordagem brutamente simples é a indicada pelo criador do w2ui.

    Isso nos mostra que as vezes defender soluções complexas como as mais corretas, é puramente questão de gosto, e não necessariamente um fato.

    Sejamos simples!

  • Restringir menus para usuários do WordPress

    No WordPress pode ser útil restringir quais menus um usuário pode ter acesso. Não é difícil encontrarmos uma situação onde um usuário de um site deve ter acesso aos plugins WooCommerce, para gerenciar suas vendas e Easy Appoinments para gerenciar os agendamentos de seus clientes, mas não pode ter acesso aos menus Tools ou Settings, por exemplo.

    A questão é que o WordPress por padrão não faz esse tipo de gerenciamento de permissões, e assim sendo, nós temos duas formas de resolver isso, a primeira é usando algum plugin de terceiros, a segunda é criando nosso próprio plugin para gerenciar as permissões.

    Neste tutorial vamos desenvolver a segunda opção, eu a considero mais estável e segura, levando em conta que você terá total controle e conhecimento do que foi feito e do que está rodando no seu site.

    Mãos a massa!

    Antes de começarmos de fato, um alerta! É comum encontrar na internet instruções para pôr código personalizado no arquivo functions.php do seu tema ativo, porém isso é um equívoco, uma vez que o arquivo functions.php pode ser sobrescrito em uma atualização do seu tema, apagando assim qualquer código personalizado inserido nele.

    Mais uma vez então concluímos que uma melhor solução para inserir código personalizado em um site WordPress é criar seu próprio plugin, vamos fazer isso a seguir. E o melhor, é que isso é fácil de fazer!

    Dentro da pasta de plugins crie um diretório e um arquivo com o mesmo nome menu-filter/menu-filter.php

    Este diretório e arquivos não precisam ter o mesmo nome, porém para um plugin muito simples com somente um arquivo, como é neste caso, isso deixa as coisas mais claras.

    Adicione o código abaixo ao arquivo:

    <?php
/**
 * Plugin Name: My Website Admin Menu Filter
 * Description: Show only Appointments, WooCommerce e Products menus
 * Version: 1.0
 * Author: Fellipe Sanches
 */

function ocultar_menus_para_secovi_colaborador() {
  if (!is_user_logged_in()) return;

    $user = wp_get_current_user();
    $email = $user->user_email;

    $admins = array(
        "email1@provider.com", 
        "email2@provider.com"
        );

    if (!in_array($email, $admins, true)) {
       remove_menu_page('index.php');
       remove_menu_page('edit.php'); // Posts
       remove_menu_page('upload.php'); // Media
       remove_menu_page('link-manager.php'); // Links
       remove_menu_page('edit-comments.php'); // Comenetários
       remove_menu_page('edit.php?post_type=page'); // Pages
       remove_menu_page('plugins.php'); // Plugins
       remove_menu_page('themes.php'); // Appearance
       remove_menu_page('users.php'); // Users
       remove_menu_page('tools.php'); // Tools
       remove_menu_page('edit.php?post_type=project'); //Projetos
       remove_menu_page('options-general.php'); // Settings
       remove_menu_page('et_divi_options'); // Divi
    }
}

function ocultar_menu_novo_para_secovi_colaborador() {
  if (!is_user_logged_in()) return;

    $user = wp_get_current_user();
    $email = $user->user_email;

    if (!in_array($email, $admins, true)) {
        global $wp_admin_bar;
        $wp_admin_bar->remove_node( 'new-content' );
        $wp_admin_bar->remove_node( 'comments' );
        $wp_admin_bar->remove_node( 'woocommerce-site-visibility-badge' );
        $wp_admin_bar->remove_node( 'updates' );
        
    }
}

add_action( 'wp_before_admin_bar_render', 'ocultar_menu_novo_para_secovi_colaborador' );
add_action( 'admin_init', 'ocultar_menus_para_secovi_colaborador' );

    O plugin irá aparecer no seu menu de plugins:

  • Configuração para o NGINX

    Olá, hoje vamos ver aqui como confirgurar o servidor web Nginx, partindo de alguns conceitos básicos para o seu funcionamento, até sua configuração para produção.

    Neste exemplo vamos fazer a instalação do Nginx versão Open Source no Ubuntu Server (ver outras opções).

    Instalando o NGNIX

    No Linux:

    sudo apt-get update (para atualizar o repositório do Linux)

sudo apt-get install nginx (para instalar o Ngnix)

sudo nginx -v (para verificar a instalação)

curl -I 127.0.0.1 (para verificar se o Ngnix está rodando e acessível na loopback)
    # Default server configuration

#

server {

        listen 80 default_server;

        listen [::]:80 default_server;

        # SSL configuration

        #

        # Note: You should disable gzip for SSL traffic.

        # See: https://bugs.debian.org/773332

        #

        # Read up on ssl_ciphers to ensure a secure configuration.

        # See: https://bugs.debian.org/765782

        #

        # Self signed certs generated by the ssl-cert package

        # Don't use them in a production server!

        #

        # include snippets/snakeoil.conf;

        listen 443 ssl default_server;

        listen [::]:443 ssl default_server;

        ssl_certificate /etc/ssl/mywebsite.com.crt;

        ssl_certificate_key /etc/ssl/mywebsite.com.key;

        root /var/www/company_website;

        # Add index.php to the list if you are using PHP

        index index.php index.html;

        server_name *.amazonaws.com;

        #redirects para inscricoes nos formularios de eventos do site antigo

        rewrite ^(/events/internal/.*) https://old.mywebsite.com$1 permanent;

        rewrite ^(/events/commercial/.*) https://old.mywebsite.com$1 permanent;

        rewrite ^(/specific/report-july/.*) https://old.mywebsite.com$1 permanent;

        location / {

                # First attempt to serve request as file, then

                # as directory, then fall back to displaying a 404.

                try_files $uri $uri/ /index.php$is_args$args;

                add_header Access-Control-Allow-Origin 'https://checkout.mywebsite.com';

        }

        # pass PHP scripts to FastCGI server

        #

        location ~ \.php$ {

                include snippets/fastcgi-php.conf;

        #

        #       # With php-fpm (or other unix sockets):

                fastcgi_pass unix:/run/php/php8.1-fpm.sock;

        #       # With php-cgi (or other tcp sockets):

        #       fastcgi_pass 127.0.0.1:9000;

        }

        # deny access to .htaccess files, if Apache's document root

        # concurs with nginx's one

        #

        location ~ /\.ht {

                deny all;

        }

        location ~ ^/wp-admin {

                allow 1.2.3.4; # INTERNAL LINK COMPANY

                allow 2.3.4.5; # FELLIPE'S HOME OFFICE

                deny all;

        }

        location ~ ^/wp-login.php {

                allow 1.2.3.4; # INTERNAL LINK COMPANY

                allow 2.3.4.5; # FELLIPE'S HOME OFFICE

                deny all;

        }

        location ~ ^/login {

                allow 1.2.3.4; # INTERNAL LINK COMPANY

                allow 2.3.4.5; # FELLIPE'S HOME OFFICE

                deny all;

        }

        location ~ /?author=([0-9]*) {

                deny all;

        }

        location = /xmlrpc.php {

                deny all;
                
        }

}

  • API customizada no WordPress

    Olá, hoje vamos ver aqui como construir uma API customizada no WordPresss, de forma simples e correta, evitando os erros mais comuns ao se fazer tal trabalho.

    Introdução com uma história triste

    Um vez fiz uma API customizada no WordPress para que meu frontend feito com DIVI Theme, para que ele pudesse ler os dados enviados por esta API, que por sua vez consultava diversos outros recursos externos, tais como outras APIs externas.

    Normalmente todos os temas WordPress têm um arquivo functions.php, no caso do DIVI o functions.php fica em /wp-content/themes/Divi/functions.php. Este arquivo é fundamental para adicionar funcionalidade personalizada ao tema, e foi lá que coloquei minhas customizações, acrescidas nas últimas linhas.

    O problema é que este arquivo é todo sobreescrito a cada nova versão lançada daquele tema pelo desenvolvedor do tema, apagando assim também qualquer customização feita por você ali. 

    Foi isso que aconteceu comigo, e a dica para que isso não ocorra contigo, eu vou deixar aqui neste artigo, que é colocar o seu código em um plugin personalizado, o que inclusive vai deixar a solucão mais segura e elegante!

    Mãos à massa

    Vamos começar criando um plugin personalizado. Para isso adicione um arquivo em: 

    /wp-content/plugins/custom-api/custom-api.php

    Você pode renomear o nome do diretório e arquivo para ficar de acordo com sua criação.

    Feito isso, insira este código no arquivo:

    <?php

/*

Plugin Name: Custom API Modifications

Description: Custom APIs and endpoints

Author: Name

Version: 1.0

*/

add_action('rest_api_init', function () {

    register_rest_route('minhaapi/v1', '/teste/', [

        'methods'  => 'GET',

        'callback' => 'minha_funcao_personalizada',

    ]);

});

function minha_funcao_personalizada() {

    return ['mensagem' => 'Funcionando!'];

}

    Mais opções de valores para o header estão aqui

    Agora, quando você for a área de plugins do seu WordPress verá o seu plugin lá, ative-o, e faça uma chamada no browser para https://seusite.com/wp-json/minhaapi/v1/teste

    O retorno será: Funcionando!
    Pronto, você já tem um ponto em seu WordPress, pronto para se comunicar com o frontend e com recursos externos, de forma segura e organizada.
    Abaixo um exemplo completo de uma requisição usando o método POST, ele faz uma requisição a uma API externa, entregando os dados no backend do WordPress. Isso é útil para interligar o backend do seu WordPress a um serviço externo, e então ter os dados de retorno disponíveis para trabalhar no backend ou frontend do seu website.

    /*--------------------------------------

 Registra o endpoint consulta cliente 

--------------------------------------*/

function consulta_cliente(WP_REST_Request $request)

{

  $api_url = 'https://api.exemplo.com';

  $required_params = ['valor', 'tipo'];

  // Verifica se algum parâmetro obrigatório está ausente

  foreach ($required_params as $param) {

    if (!isset($request[$param])) {

      return new WP_REST_Response([

        'message' => 'parâmetro [' . $param . '] não fornecido.'

      ], 400);

    }

  }

  $valor = $request->get_param('valor');

  $tipo = $request->get_param('tipo');

  // Faz a requisição para a API externa

  $response = wp_remote_post($api_url, [

    'headers' => [

      'Content-Type' => 'application/json',

    ],

    'sslverify' => false,

    'body' => json_encode([

      'valor' => $valor,

      'tipo' => $tipo

    ]),

  ]);

  if (is_wp_error($response)) {

    return new WP_REST_Response([

      'message' => 'Erro ao se conectar com a API externa.',

      'error' => $response->get_error_message(),

    ], 500);

  }

  $http_code = wp_remote_retrieve_response_code($response);

  $body = wp_remote_retrieve_body($response);

  $data = json_decode($body, true);

  return new WP_REST_Response($data, $http_code);

}

// Registra o endpoint na API REST

add_action('rest_api_init', function () {

  register_rest_route('minhaapi/v1', '/cliente', [

    'methods' => 'POST',

    'callback' => 'consulta_cliente',

    'permission_callback' => '__return_true', // Permitir requisição sem autenticação

  ]);

});

  • Siglas, Gírias e frases do mundo dev br

    Aqui estão alguns termos como siglas e gírias usados no mundo dev no Brasil:

    PR – Pull Request

    Exemplo de uso: Fala sério! Aquele cara não cansa de fazer PR sem explicação…

    Update sem where

    20 Gírias, Frases e Siglas Usadas por Devs BR

    1. Commitar código
      Significado:Vem do uso do comando Commit, usado para enviar ou registrar no Git / GitHub alterações no código do projeto.
      Exemplo: “Já commitei aquela função nova, blz?”
    2. Go horse!
      Significado:Significa resolver o problema com um código improvisado, mal estruturado, que resolve o problema mas é difícil de manter ou escalar depois.
      Exemplo: “Terminei o projeto em 3 dias como o chefe pediu! Foi a base do Go Horse, mas tá no ar!”
    3. Baixar código / Pullar / Fazer Pull
      Significado: Baixar alterações do repositório remoto Git / GitHub.
      Exemplo: “Pulla a master antes de começar a mexer no código, tá?.”
    4. Subir
      Significado: Enviar código para o servidor ou repositório no Git / GitHub.
      Exemplo: “Acabei de subir a nova versão, já tá em produção!”
    5. Deployar
      Significado: Fazer o deploy, colocar a aplicação no ar usando o process de deploy.
      Exemplo: “Deployei agora pouco, vê se tá funcionando aí.”
    6. Dar pau
      Significado: Quando algo dá erro ou para de funcionar.
      Exemplo: “O sistema deu pau depois da última atualização.”
    7. Bugado
      Significado: Algo que está com defeito, não funciona como deveria.
      Exemplo: “Esse botão tá bugado, não tá clicando.”
    8. Refatorar
      Significado: Reescrever o código para melhorar sem mudar a funcionalidade.
      Exemplo: “Esse código tá confuso, vou refatorar ele todo.”
    9. Code smell
      Significado: Se diz quando há indícios de que o código tem potenciais problemas graves.
      Exemplo: “Cara, esse monte de if encadeado tá com um cheiro de code smell sinistro.”
    10. Dar merge
      Significado: Juntar duas versões do código (normalmente em Git).
      Exemplo: “Já dei merge na sua branch com a minha.”
    11. Dar rebase
      Significado: Reorganizar o histórico de commits.
      Exemplo: “Fiz um rebase pra deixar o histórico melhor.”
    12. Fullstack
      Significado: Programador que trabalha tanto no backend quanto no frontend.
      Exemplo: “Sou fullstack: conserto tanto o botão quebrado quanto o banco de dados!”
    13. Rollback (fazer rollback)
      Significado: Reverter alterações que deram errado.
      Exemplo: “O deploy deu ruim, tive que fazer rollback.”
    14. Legado (código legado)
      Significado: Código antigo, normalmente difícil de manter.
      Exemplo: “Cuidado com a manutenção desse sistema, é legado tá cheio de coisas que ninguém sabe como funciona há anos.”
    15. Buildar
      Significado: Compilar ou gerar a versão final do app.
      Exemplo: “Já buildei o projeto para versão de produção, pode testar.”
    16. Ficar em loop
      Significado: Quando o código ou o programador não sai do lugar.
      Exemplo: “Tô em loop com esse monte de tarefas, melhor sair pra tomar um café.”
    17. Codar
      Significado: Escrever código, programar.
      Exemplo: “Hoje eu só quero codar em paz, sem reunião.”

  • Programador: os 3 pilares da profissão

    Pensar

    programar

    negociar

  • A Engenharia do Site Confiável – Parte 1

    Introdução

    Nesta série de 4 artigos, quero mostrar com criar um site confiável, um que você possa dormir a noite sem preocupações ou que não te faça pensar se ele está travando muito depois que você deixou ele lá no seu ex-emprego.

    Exisitem metodologias prontas para isso, como a chamada DevOPs ou a Site Reliability Engineering – SRE, do Google. Obstante a implementá-las ou dizer que elas não funcionam, só tenho a certeza de que

    Talvez quando você pense em ter um sistema confiável, à prova de falhas, logo te venha a mente coisas como Testes Unitários ou Testes Integrados, QA, e tudo mais do que está na moda na tão badalada cultura DevOps, certo?

    Porém, é verdade que muitas vezes, mesmo com esteira CI/CD toda implementada, às vezes mesmo assim não nos sentimos seguros em relação ao funcionamento confiável do nosso sistema, e isso não é por acaso. Na verdade você sabe lá no fundo que sempre vai faltar um teste, ou o cara do QA vai deixar passar algo, e quando você menos esperar um problema ocorrerá no funcionamento do seu sistema.

    E o DevOps não ajuda? Ajuda… Mas não garante tanto a confiabilidade pois é focado na integração entre entre Dev e Ops, tendo como resultado final a entrega contínua, já o SRE foca justamente em manter sistemas escaláveis e confiáveis.

    SLO, um passo antes do SRE

    Para implementar uma solução de SRE precisamos definir primeiro os Service Level Objectives (SLOs), ou Objetivo de Nível de Serviço em português. Ok, agora temos uma nova sigla, mas então o que é SLO e porque o SRE precisa dele?

    O SLO é um documento que define a qualidade e o desempenho que um serviço deve ter, como um compromisso de nível de serviço, com o cliente, ou seja, o SLO define o que é aceitável para o usuário em termos de qualidade do serviço, para então o SRE ter um guia para agir.

    Afinal, como vamos criar nossos esforços com SRE sem saber onde devemos chegar ou o que queremos alcançar? 

    Coisas como: “Garantimos o tempo de disponibilidade da aplicação em 99,97% do mês” ou “As respostas do BD devem ter tempo de resposta máximo de 500ms” são objetivos que são definidos pelos SLOs.

    SREs usam SLOs para entender se uma métrica foi alcançada, e usam isso para:

    • Detectar problemas
    • Tomar decisões (lançar uma nova versão ou fazer um rollback)
    • Priorizar tarefas de engenharia de software 

    Se ainda não está claro, SRE é a engenharia para manter serviços confiáveis e o SLO são os objetivos de qualidade do serviço que o SRE deve obdecer.

    Por fim, vale ressaltar que para além de manter seu software confiável, o SRE deve usar o SLO para priorizar tarefas que estejam violando mais a SLO, assim se você tem dois problemas, você pode ver qual está violando uma SLO (ou qual está violando mais) e resolvê-lo primeiro.

    Por que SRE?

    Este tópico é útil para responder ao seu chefe, quando ele perguntar quais vantagens implementar o SRE traria para os negócios. E resposta é a seguinte:

    • Extinguir ou reduzir tempo de indisponibilidade da aplicação, evitando desgastes para a empresa
    • Ajudar em oferer uma boa expêriencia ao cliente, oferencendo uma aplicação estável
    • Melhorar a efeciência da equipe de tecnologia, automatizando tarefas operacionais, deixando assim os profissionais com mais tempo livre para atender demandas de negócio
    • Preservar uma boa reputação para a aplicação da empresa, através do seu bom funcionamento, evitando perda de clientes
    • Redução de custos a longo prazo alcançado através de menor indisponibilidade da aplicação e maior tempo disponível para atender o negócio.

    4 pontos a serem observados pelo SRE:

    Os 4 pontos principais ou como alguns preferem os 4 “golden signals” (pontos de ouro em português),  para o SRE observar são: Latência, Tráfego, Erros e Saturação. Vamos ver um resumo de cada ponto a seguir.

    Latência:

    Mede o tempo que aplicação, leva para responder uma solicitação, verificando se o tempo de retorno é considerado aceitável. Pode ser checado aqui desde o ping para o servidor, até o tempo de resposta de uma requisição para uma API, o retorno de uma query para o BD, ou mesmo o tempo de carregamento do front-end web.

    Tráfego:

    Indica a quantidade de solicitações que o sistema está recebendo, como já dito, o intuito é verificar se os valores são considerados aceitáveis, de acordo com o estabelecido.

    Erros:

    Mede o número de solicitações que não foram processadas com sucesso. 

    Saturação:

    Indica o nível de utilização dos recursos do sistema, como CPU e memória. 

  • 6 dicas para te ajudar a programar no dia que estiver sem motivação

    1 – Compartilhar uma solução do trabalho com o mundo

    Compartilhar a solução de um problema do seu trabalho em algum fórum como o Stack Overflow, Dev.to, Quora ou fazer uma publicação em um blog pessoal, podem

    2 – Lembrar que você está ajudando as outras áreas da empresa e fazendo bem indiretamente ao trabalho de outros

    3 – Pensar que quanto mais cedo você terminar algo, mais cedo se verá livre daquilo, obtendo tempo assim para tarefas mais agradáveis

    4 – Usar a estratégia da Deliberate Practice Conceito popularizado por Anders Ericsson.
    Envolve praticar de forma intencional e focada em aspectos difíceis ou desconfortáveis para melhorar habilidades.
    A recompensa é pensar que enfrentar o que você não gosta ou onde tem mais dificuldade vai te ajudar no crescimento pessoal ou profissional

    5 – Ir além do básico monótono .

    fazer todo o básico complementando com algo que agregue valor e te agrade

    6 – Quebrar seu trabalho em partes para nao ver como ama enorme tarefa massante

  • PHP: três décadas impulsionando a web

    Em 8 de Junho de 2025, o PHP (Hypertext Preprocessor) completa 30 anos de existência, consolidando-se como uma das linguagens de programação mais influentes e duradouras da história.

    O PHP me proporcionou o primeiro cliente de desenvolvimento web ainda em 2010, uma imobiliária na cidade Maricá – RJ. Na época, como era constume, eu desenvolvi o projeto com ajuda de um livro do tipo que te guia a fazer um projeto completo, chamado “Faça um Site Orientado por Projeto Php 5. 2 Com Mysql 5. 0 – Carlos A. J. Oliviero”. Boas lembranças!

    Criado em 1995 por Rasmus Lerdorf, o PHP nasceu como um conjunto de scripts em C para suprir suas necessidades pessoais de programação. O que começou como uma ferramenta pessoal rapidamente evoluiu para uma linguagem de código aberto, usada por milhões de desenvolvedores ao redor do mundo.

    Durante esses últimos 30 anos o PHP passou por diversas melhorias, até avanços modernos como os do PHP 8.x, com suporte a tipagem estática, compilação JIT e recursos orientados a objetos mais sofisticados, a linguagem acompanhou — e em muitos casos, antecipou — as demandas da web moderna!

    Plataformas como WordPress (incluindo WooCommerce), Drupal, Joomla e Magento têm PHP como base até hoje, o PHP também conta com frameworks modernos e robustos como o Laravel e o Symfony, e isso tudo faz com que nada menos que 3/4 dos sites na internet atualmente utilizem PHP como linguagem de server-side, segundo estatísticas da W3Techs.

    Sem dúvida a longevidade do PHP é graças a sua comunidade fiel e ativa, sua documentação completa e organizada, e sua facilidade de aprendizado, o que fez dela a porta de entrada para milhares de desenvolvedores iniciantes.

    Com 30 anos de história, o PHP continua evoluindo, provando que sair na frente e manter uma base sólida, é o segredo para se manter na liderança. Parabéns ao PHP e a todos que contribuíram para sua jornada até aqui! 

    <?php

// Define emojis usando unicode
$coracao = "\u{2764}\u{FE0F}";
$cone = "\u{1F389}";

echo "Parabéns pelos 30 anos proporcionados por\n todos que " . $coracao . " e usam o PHP! " . $cone\n;

    Resultado:

    Parabéns pelos 30 anos proporcionados por
    todos que ❤️ e usam o PHP! 🎉