WordPress: Estrutura inicial do tema, padrões de codificação e uso do editor
Este é o primeiro post da nossa série Como criar temas para WordPress! É importante salientar que todos os posts serão hands on, então não adianta ficar só lendo! Para aprender de verdade é preciso praticar! Siga todos os passos citados nos posts, crie os arquivos conforme as orientações, que em breve você estará apto para criar seu próprio tema, combinado? ;)
Padrões de codificação
Para manter um padrão de codificação, vamos seguir os Coding Standards do WordPress para PHP, HTML, CSS e Javascript.
Editor
Eu irei utilizar o Sublime Text para codificar nosso tema, mas você pode utilizar qual você preferir, contanto que mantenha os padrões de codificação dos arquivos, não haverá maiores problemas em utilizar outro editor ou IDE.
Se quiser usar o Sublime Text nas mesmas configurações que eu uso, siga as instruções desse gist.
Estrutura inicial de arquivos
Nós vamos criando os arquivos conforme a necessidade das funcionalidades do tema, enquanto estivermos desenvolvendo. Então vamos começar apenas com a estrutura abaixo:
1 | . |
Já vimos no artigo de apresentação que essa é a estrutura base de um tema para WordPress. Nós iremos utilizar essa mesma estrutura para dar início ao nosso tema.
O único arquivo novo aqui é o .editorconfig
(se escreve assim mesmo, com um ponto no início). Com esse arquivo, nós conseguimos setar algumas configurações para criação de arquivos, para que não venhamos ter problemas ao usar editores diferentes.
Vamos usar a seguinte configuração no .editorconfig
:
1 | # editorconfig.org |
É necessário instalar o plugin do Editorconfig no seu editor. Para saber mais sobre o .editorconfig
, e ver como instalar o plugin para o editor de sua preferência, acesse http://editorconfig.org/
Nesse caso, nós definimos que todos os nossos arquivos serão salvos com o charset utf-8, o estilo de indentação será com espaços (indent_style = space
), com tamanho de indentação de 4 espaços (indent_size = 4
).
Nos Coding Standards do WordPress, ele diz que devemos utilizar tabs
, mas vamos utilizar espaços aqui. Se você for desenvolver algum tema ou plugin para subir no repositório do WP, você precisa seguir todos os Coding Standards corretamente, nesse caso, usando tab ao invés de space.
Não se preocupe, você não vai precisar ficar dando 4 espaços a todo momento que for indentar. A diferença é que, ao pressionar a tecla TAB, o que o seu editor faz é usar quatro \s
(que representa espaços) ao invés de usar um \t
(que representa tabulação) com tamanho 4.
A vantagem de utilizar espaços é que, em qualquer editor, o tamanho da indentação vai permanecer sempre igual. Se utilizarmos tab, esse tamanho pode variar para 8 ou 16, dependendo da configuração do editor (não tenho certeza se com o editorconfig instalado o problema continua, mas por garantia, vamos usar espaços).
Também não iremos deixar adicionar uma nova linha ao final do arquivo quando salvar (insert_final_newline = false
), e iremos remover espaços em branco sobrando no final das linhas (trim_trailing_whitespace = true
).
Quebrando a index
Feito isso, vamos quebrar nossa index em algumas partes. O header e o footer serão padrão para todos os templates, então iremos separá-los em mais dois arquivos: header.php
e footer.php
.
O header.php
vai ficar assim:
1 |
|
E o footer.php
assim:
1 | wp_footer() |
Isso porque nós iremos incluir o mesmo header e o footer em cada arquivo do nosso tema, então separamos em partials para que possamos aproveitá-los sem ficar repetindo código. Mais pra frente você vai entender a vantagem de usar o header e o footer dessa forma, quebrando a abertura / fechamento da tag body
.
Temos duas novidades aqui: as funções wp_head()
e wp_footer()
. Elas são usadas pelo WordPress como hooks (ganchos), para pendurar alguns códigos. Veremos o uso disso em posts futuros.
E a nossa index
vai ficar assim:
1 | get_header() |
Nas linhas 1
e 19
podemos ver duas funções novas: get_header()
e get_footer()
. Essas funções incluem os arquivos header.php
e footer.php
no nosso template.
Mas o PHP já tem uma função include
. Por que eu não posso usar o include
do PHP ao invés das funções do WordPress?
Em breve iremos falar sobre hooks, e, além da questão segurança, é por causa desses hooks que iremos utilizar as funções do WordPress, ao invés de usar o include
puro do PHP.
E como o WordPress sabe que são esses arquivos que ele precisa incluir, sendo que você acabou de criá-los?
O WordPress tem algumas funções que nos ajudam no desenvolvimento do nosso tema. Você pode ler mais sobre isso acessando http://codex.wordpress.org/Theme_Development
Falaremos com mais detalhes sobre cada uma dessas funções nos próximos posts.
Nossa estrutura inicial separada em partials está legal! Mas ainda temos um problema se segurança.
Ah é? Onde?
Tente acessar o arquivo index.php
diretamente pela URL do seu navegador, por exemplo.
O index do meu tema está localizado em:
1 | http://localhost/00-opensource/wordpress/wp-content/themes/wordpress-base-theme-da2k.com.br/index.php |
Será mostrado esse erro:
1 | Fatal error: Call to undefined function get_header() in /var/www/00-opensource/wordpress/wp-content/themes/wordpress-base-theme-da2k.com.br/index.php on line 1 |
O erro diz: _Chamada para função indefinida get_header() no arquivo [caminho do arquivo] na linha 1_
Por que deu esse erro?
A função não está definida, porque o WordPress começa a ser carregado a partir da index.php
na raiz do projeto. Ali ele vai incluindo os arquivos necessários para que todas as funções funcionem corretamente. Como nós adicionamos as funções get_header()
e get_footer()
em nossa index
, ao acessar o arquivo diretamente, o WordPress não foi carregado, e o PHP acusou esse erro.
E o problema maior é que ele mostra o caminho completo até o arquivo onde deu o erro! Se alguém com más intenções fizer isso no seu site em produção, ele poderá ter facilmente o caminho desde a raiz do seu servidor, até a sua pasta pública, para tentar atacar de alguma forma.
E como podemos contornar isso?
Se você abrir o arquivo index.php
do WordPress, na raiz do projeto, vai ver que ele faz um include (usando require
) do arquivo wp-blog-header.php
, e nesse arquivo, tem um include para wp-load.php
. Nesse arquivo, você verá uma constante definida chamada ABSPATH
no início do arquivo.
Como é o WordPress que define essa constante, nós podemos deduzir que, se essa constante não estiver definida, então o WordPress não foi carregado. Logo, podemos ir um pouco mais longe e deduzir que, se esse erro foi mostrado, algum safado-sem-vergonha está tentando acessar nosso site pra tentar encontrar alguma brecha de segurança, correto? Então vamos nos previnir disso!
O código abaixo você precisa colocar em todos os arquivos .php
dentro do SEU TEMA, ok?
Por enquanto temos só o header.php
, footer.php
e index.php
, mas quando tivermos mais, esse código deve ser adicionado a cada um deles, ok?
Coloque no início do arquivo:
1 | <?php |
O que nós estamos fazendo aqui?
Estamos verificando se o ABSPATH
está definido. Se não tiver, vamos redirecionar o safado-sem-vergonha para a home do site! O exit
diz ao PHP para parar de renderizar qualquer coisa que vier após esse código, pois se o redirect demorasse, ainda seria possível ver o erro na tela.
E se a constante ABSPATH
estiver definida, o PHP pula esse if
e segue o fluxo normal :)
Se o seu site estiver em uma subpasta, você precisa adicionar ela no lugar da barra. No meu caso, está em /00-opensource/wordpress/
, então vou colocar dessa forma:
1 | <?php |
Agora tente acessar novamente o arquivo index.php
e você será redirecionado para a home :D
Não esqueça que isso deve ser feito em todo arquivo .php
do seu tema, ok?
Por hoje é só! No próximo post daremos continuidade!
Até lá!
Link para o índice dessa série:
https://blog.da2k.com.br/2015/01/11/indice-da-serie-como-criar-temas-para-wordpress/Próximo post:
https://blog.da2k.com.br/2015/01/14/wordpress-o-arquivo-functions-php/
Sobre o #1postperday: https://blog.da2k.com.br/2014/12/31/um-post-por-dia/
Tem alguma sugestão para os próximos posts do #1postperday? Deixe ela aqui: https://github.com/fdaciuk/fdaciuk.github.io/issues/1