Post actualizado el día September 27, 2026 by DeiviSanzPlay
Meu problema foi ao projetar o site. Eu disse a algo mal configurado. Depois cai na real.
É o de -viagens. .
category. php. archive. php, que serve para arquivos em geral. para cada quarto ( (block themes), os mais modernos. A lógica é a mesma, mas as peças mudam: - Os arquivos já não são
. php, são . html. Contêm blocos, não código PHP complexo. - Não ficam soltos na pasta principal, mas em uma subpasta chamada
/templates/. - Aquí há uma reviravolta: o WordPress pode salvar temas diretamente no banco de dados. Se você criar um tema personalizado a partir do editor de site, esse é salvo ali e tem prioridade máxima, acima de qualquer arquivo
. html da pasta.
Este último ponto é uma arma de dois gumes. É potente porque você pode modificar layouts sem tocar em arquivos, mas também pode causar confusão. Sua alteração não aparece? Veja se há um tema "personalizado" salvo no banco de dados que esteja assumindo o controle.
Se você usar um tema filho (child theme) para fazer modificações sem quebrar o tema principal, a hierarquia se duplica. O WordPress verificará primeiro se o arquivo que procura (por exemplo, single. php) existe na pasta do tema filho. Se estiver, ele o usa e pronto. Se não, então vai buscá-lo no tema pai. Isso lhe dá controle, mas também significa que às vezes o tema pai pode ter um tema mais específico (como single-receta. php) que anule seu single. php genérico no tema filho.
No final, entender isso é o que separa o "dar tiros no escuro" do "consertar com critério". Não é magia negra, é um sistema previsível. Na próxima vez que uma página não aparecer como você espera, pergunte-se: qual arquivo o WordPress estará procurando em sua hierarquia, e qual é o primeiro que ele realmente encontra? Aí costuma estar o cerne da questão.