Depois do post e vídeo com as novidades do WordPress 5.4 para os usuários, chegou a hora de falarmos sobre as novidades para os desenvolvedores. Toda nova versão do WP é acompanhada de um Field Guide, um documento com todas as alterações feitas no código da ferramenta. Os três itens que decidi trazer para esse post foram retirados do Field Guide do WP 5.4.

Gradientes

Gradientes predefinidos

Semelhante ao que temos para as paletas de cor personalizadas, que eu comentei naquele post sobre como tornar seu tema compatível com o Gutenberg, agora é possível criar gradientes predefinidos através do código. Segundo esse post no make, tudo o que você precisa é usar o seguinte no seu arquivo functions.php:

add_theme_support(
    'editor-gradient-presets',
    array(
        array(
            'name'     => __( 'Gradiente 1', 'themeLangDomain' ),
            'gradient' => 'linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%)',
            'slug'     => 'gradiente-1'
        ),
        array(
            'name'     => __( 'Gradiente 2', 'themeLangDomain' ),
            'gradient' => 'linear-gradient(135deg,rgba(0,208,132,1) 0%,rgba(6,147,227,1) 100%)',
            'slug'     =>  'gradiente-2',
        ),
    )
);

No CSS você vai precisar criar realmente o gradiente, chamando o selector no formato “has-“, o slug e “-gradient-background”. Mais ou menos assim:

.has-gradiente-1-gradient-background {
    background: linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%);
}

Não permitir gradientes personalizados

Como eu falei no vídeo da parte 1, esses gradientes tem o potencial de trazer um carnaval fora de época. Se você não quer permitir seu usuário de criar gradientes personalizados você pode usar este código no seu functions.php:

add_theme_support( 'disable-custom-gradients' );

Desabilitar os gradientes

Se você não quer nada dessa nova funcionalidade no site, você pode desabilitá-la completamente. É só chamar o seguinte código:

add_theme_support( 'disable-custom-gradients' );
add_theme_support( 'editor-gradient-presets', array() );

do_shortcodes() agora é apply_shortcodes()

Antes de mais nada, calma. A função antiga vai continuar funcionando.

Por uma questão de semântica, agora o WordPress disponibiliza a função apply_shortcodes(), que deve ser usada no lugar de do_shortcodes() sempre que possível. O motivo é o seguinte: outras funções com o prefixo do_, como do_action(), por exemplo, imprimem seu conteúdo. Como a do_shortcodes() na verdade retorna seu conteúdo, ela deveria seguir o mesmo padrão que a apply_filters(), ou seja, ter o prefixo apply_.

Funções que imprimem tem do_, funções que retornam têm apply_. Padrões ajudam a memorizar e entender as coisas mais rapidamente.

Outro padrão no core são as funções com prefixo the_ (the_title(), the_content(), the_expert(), etc.), que imprimem seus resultados, e funções com o prefixo get_the_ (get_the_title(), get_the_content(), etc.), que retornam seus resultados. A função get_permalink era a única que não seguia esse padrão, algo que foi corrigido no WordPress 3.9, com a criação da função get_the_permalink().

Você pode ver a explicação original neste outro post do make.

A barra de administração mudou de lugar

É um dos princípios de acessibilidade ter os elementos com a mesma ordem tanto no código quanto na tela. A barra de administração não seguia essa regra: ela aparece no começo da tela, mas era um dos últimos elementos no HTML. Com a chegada da action wp_body_open, que eu comentei no vídeo da versão 5.2, isso agora pôde ser corrigido. O código foi feito de maneira que nada vai quebrar em temas antigos, mas se você estava usando a ordem dos elementos em algum seletor CSS, por exemplo, é bom saber que isso aqui mudou.

Esse item é do post do make que tem várias pequenas mudanças. Vale muito a pena dar uma olhada no texto inteiro.

E as novas actions para campos nos itens de menu?

É, eu sei que teve isso também. Mas isso vai ficar para um vídeo separado. Não esqueça de se inscrever no canal e assinar aqui a newsletter para não perder!