 Boa tarde, pessoal. Primeiramente agradecer a oportunidade de estar participando aqui no WordCamp Porto Alegre. Obrigado por terem ficado até o final. Eu sei que, na verdade, vocês querem o sorteio de brindes pela minha palestra, mas beleza. E, bom, me apresentando, a gente vai falar nessa palestra sobre plug-in territory, como o Donini introduziu. A gente vai discutir quais são as responsabilidades que um plug-in tem e o que o tema tem de responsabilidade em um projeto WordPress. Me apresentando um pouco. Meu nome é Alisson Souza. Eu sou formado, na verdade, em programação de jogos digitais, mas sempre ato aí com desenvolvimento web. Ato ano com WordPress desde 2013. Eu sou sócio Danissa, no Studio AST. Sou da Organização do WordCamp São Paulo. Aqui, galera de São Paulo, cadê o grito? E organizo. Ajudo a organizar os meet-ups e os eventos de WordPress, sempre tentando colaborar com o fórum, grupo do Facebook e tudo mais. E sou o criador do Oixavim. Mas, para mim, Redmi não é meu único plug-in. Eu e Anissa, a gente tem um plug-in para o commerce, bem legal também, para quem vende inscrições em cursos e eventos. Chama-se Registrations for Commerce, totalmente open source. Então, podem dar uma olhada lá no repositório oficial. Então, para introduzir um pouco a ideia de plug-in território, vou falar um pouco da arquitetura do WordPress. Como que o WordPress, como que é a separação do WordPress, suas partes? O WordPress, então, a gente sabe que ele tem o Core, que é o núcleo do WordPress, concentrado na pasta WPA de Min, quando você instala o WordPress, que cria o painel, cria os usuários, cria os posts, paginas, possibilita a estrutura inicial do WordPress. Além disso, você pode instalar temas, que modificam a cara do seu site e plug-ins. Aqui, só detalhando um pouco, temas são conjuntos de templates responsáveis pela exibição do site. Plug-ins são softwares adicionais que modificam ou adicionam novas funcionalidades ao WordPress. Então, o tema ele vai cuidar, como aquele conteúdo que você adiciona no painel será exibido e os plug-ins vão poder modificar o que o Core do WordPress já apresenta para você. E como que você modifica essas coisas? Através de hooks. Quem aqui sabe o que são hooks? Já trabalhou com hooks. Todo mundo já mexe alguma coisa, se você quer mexer alguma coisa de tema, você tem que trabalhar com hooks. Plug-ins, então, nem se fala. Tem dois tipos de hooks. Os hooks podem ser actions. Então, são eventos que você dispara, você determina uma função. Ali, primeiro, você tem a hora. Como você adiciona uma action, você usa a função add action do WordPress, especifica em que momento ela será executada, então o WordPress tem uma sequência de execução, você escolhe em que momento o WordPress e o segundo parâmetro é a função. Mas eu não vou entrar em muitos detalhes dos hooks, mas esse é o modelo pelo qual você modifica o Core do WordPress no tema e nos plug-ins. E tem os filtros que seriam para filtrar saída de conteúdo, coisas que o WordPress exibe. Então, essa é a estrutura base do WordPress. E aí a gente entra no Functions PHP, que é o arquivo dentro do tema pelo qual a gente insere os nossos hooks. E que eu coloquei essa questão. Functions PHP, ele é o herói ou vilão, porque ele é o arquivo em que você vai poder fazer várias coisas dentro do seu tema. Mas será que isso é tão bom assim? Functions PHP é o arquivo do tema que atua como se fosse um plug-in, um plug-in exclusivo para aquele tema. Então, dentro do Functions você vai poder colocar os hooks, você vai poder declarar funções personalizadas do seu tema que você mesmo criou, e fazer chamadas as funções do WordPress, que o Core do WordPress já disponibiliza. Então, aqui mais ou menos um exemplo de, não sei se dá para visualizar muito bem, um exemplo de Functions PHP do 27, porque você tem o setup, você define o carrega do text de domain, adiciona o suporte a title tag, post thumbnails e tudo mais. Então, ali é adicionando na Action After Setup Team. Então, os Functions vai permitir tudo isso, um plug-in dentro do seu tema. E aí, para que deve ser usado o Functions? Então, para definição de características relativas ao tema exclusivamente, que seriam definir tamanhos de imagens, você pode definir tamanhos de imagens que o seu tema vai utilizar personalizadamente, ou modificar os tamanhos de imagens que o WordPress oferece, pelo painel, quando você vai lá nas configurações, você pode ter as opções dos tamanhos, acho que thumbnail, medium e large. Você pode configurar isso através do Functions também, e adicionar novos tamanhos. Registrar sidebars, as widget áreas, áreas que você vai poder colocar widgets no seu tema. Dentro do Functions, você vai definir esse tipo de coisa. Carregar scripts e estilos, pelo WordPress, você não vai carregar o seu estilo CSS, colocando ele ali no header.php. Você vai usar as funções WordPress, WPink, Style, WPink e Scripts. Tudo isso você faz através do Functions PHP. E coisas como criação de opções no Customizer, opções de personalização do seu tema, você pode criar dentro do Functions, dentro do seu tema. Então, é para isso que o Functions serve. E aí a gente vai discutir um pouco o que eu devo incluir em um plugin, o que eu não devo incluir no Functions. Porque qualquer ideia, o Functions é um plugin dentro do tema. Então, basicamente, tudo o que você faz dentro do Functions, você pode fazer em um plugin e vice-versa. Então, por isso que as coisas são muito fáceis de se misturar e por isso que o Functions PHP pode ser um vilão. Você incluir coisas que são mais relacionadas a plugin dentro do seu tema e as coisas começarem a ficarem bagunçadas. Primeiro, short codes. Todo mundo que conhece short codes, quem conhece short codes? Quem já criou um short code? Bastante gente, o pessoal já criou um short code. Vocês criaram short code, quem criou short code no tema? Bastante gente. Quem criou um plugin? Plugins? Tá médio. Os short codes são aqueles pequenas porções de códigos entre colchetes para quem não conhece, que podem ser inseridas no conteúdo de uma publicação. E eles vão dar uma saída diferente ao que foi incluído. Então, aqui no caso é short code de galerias. Short code de gallery, você define as idês das imagens que você quer exibir e vai exibir a galeria. O short code vai ser processado para exibir a galeria, um HTML personalizado. E por que não definir isso no tema? Se você cria um short code novo no tema, quando você troca de tema, aquele short code se foi. Mas você tem 200 posts que você utilizou aquele short code. O que você vai fazer? É só recriar no tema novo, o mesmo short code. Não vai dar trabalho nenhum. Ah, mas, ok, vai dar algum trabalho já. Um short code. E se você criou 10 short codes no seu projeto, espalhado em 500 mil posts, você vai ter que recriar tudo isso em um tema novo. Então, por isso que não é recomendado criar short codes em temas. Porque se você troca o tema, eles se vão. E aí, o que o seu usuário vai ver? Cochete, gallery, ID. Ele vai ver isso no meio do conteúdo ali. Vai estragar o visualização do seu site. Então, short codes ganham o selinho plugin. Tente sempre priorizar os short codes para serem definidos em plugins. Outro tópico, formulários de contato. Quem já criou formulário de contato em tema? Eu já criei. Formulário de contato? É a mesma coisa. O que é, definição de formulário de contato? Por que não definir no tema? Seus formulários, da mesma forma, ficariam presos ao tema. Todo mundo pensa que não vai precisar trocar de tema. Ah, eu defini esse tema e vou usar por muito tempo. Mas, na verdade, você não sabe se aquele tema vai te atender por quanto tempo e se você pode fazer as coisas de forma modularizada sem se prender, é sempre bom priorizar isso. Então, se você trocar de tema, seu formulário se foi. E aí, outro retrabalho que você tem que fazer. Então, se você usa plugins como o Contact Form 7, ok, ele te dá o short code, ele cria o short code, você só precisa... Não vai parar de funcionar se você trocar de tema. Se o short code está inserido no conteúdo da página, por exemplo, e você só precisa... Você pode trocar de tema que ele vai continuar funcionando. Então, formulários também são coisas que entram no território de plugins. Outra coisa, opções de SEO e analíticas. Então, se você tem campos de opções para configurações do SEO do seu site, se tem campo para definir o ACode, do analíticas e tudo mais, faça isso no plugin. Ou utilizando um plugin, ou no seu plugin próprio. Por que? Imagina, você trocar de tema e você tem que se preocupar, porque o seu site não está mais com o código do analíticas. Aí, se você esquecer disso, aí você perdeu dois dias até você entrar no seu analíticas e lembrar que você tinha colocado o código dentro do tema. Quem já colocou o código do analíticas dentro do tema? Eu já fiz isso também. Então, sempre evitem isso, coloquem em plugins. Metabox, quem já criou Metabox? Criou no tema. Já criei muita Metabox no tema. Até quem já utilizou o Odin Framework, ele vinha com classes de Metabox, não ainda vem, ainda não saiu a versão 3. Então, ele vinha com classes de Metabox, então ele estimula a criar coisas do território de plugins, que é uma coisa que está sendo resolvida para a versão 3.0. Então, as Metabox são os campos adicionais para a inserção de conteúdo, definição de metadados relacionados à sua publicação. E por que não definindo o tema? Aqui, nas Metabox, a gente tem um porém. Se as suas Metabox forem para a inserção de conteúdo, é bom que você define ela em plugin, porque conteúdo você não quer perder ao trocar de tema. Porém, se você tem uma Metabox que é relativa à visual, por exemplo, eu vou criar uma Metabox dentro do meu post para definir, se eu quero um cabeçalho com a imagem FUIDIT ou com margens. Isso você pode definir no tema. Isso é uma Metabox válida de se definir no tema. Então, Metabox ganha o selo de, talvez, talvez plugins ou talvez temas. Vai do seu discernimento de saber qual o propósito daquela Metabox. E custa um post types. Quem já criou custa um post types? Quem já criou custa um post type no tema? Muita gente, eu inclusive. Os custa um post types é um exemplo mais básico. Eu estou falando desde o início, da grande divisão sobre do que entra no território de plugins e do que entra no território de temas. Como o próprio nome diz, custa um post types são tipos personalizados e publicação de conteúdo. Já matamos a charada. Não tem o que discutir. Isso não é relativo a temas. Se você coloca um custa um post type no seu tema, por exemplo, para submeter para o repositório oficial, tudo isso que eu estou falando não é aceito. Se você quer submeter um tema para o repositório oficial do Hortpress, ele não pode adentrar o território de plugins. E é que tem um motivo. Se você trocar de tema, imagina, você faz um site de notícias, igual a gente já fez, cria o post type receitas, para a sessão de receitas. O jornal decide que, passou quatro anos, cinco anos, o jornal quer trocar o layout. Desenvolve um novo tema. É a surpresa. Trocou o tema. Cadê as receitas? Sumiu todas as receitas do site e o custa um post type não está mais definido. Lógico, está no banco de dados. Mas você, para o usuário, a sensação de que ele perdeu aquele conteúdo. Se ele trocar de tema, o custa um post type sumir. É uma experiência muito ruim. E, apesar de ser válido, de ser necessário para o repositório oficial, quando você compra um tema nos marketplace, isso não é realidade. Tem muito tema que ainda cria custa um post type e adentra totalmente o território de plugins. Vamos falar um pouco mais para frente. Então, custa um post types não tem nem o que discutir do território de plugins. Da mesma forma que o custa um post types, custa um taxonomies. Acho que eu já criei custa um taxonomy no tema. Quem já criou também. Se você criou custa um post type no tema, é lógico que você tenha criado também a custa um taxonomy no tema. Para quem não sabe, deixei mais para registro esses detalhamentos porque o pessoal vê depois, a palestra. Tem todo o detalhe. Você tem que ser personalizado de taxonomia como categorias e tags que você pode criar novos categorizações. Como nesse exemplo que eu dei de receita, você pode criar a taxonomia de subeste. O primeiro seria categorias. Engredientes, você pode criar como se fosse tags. Engredientes vão na receita. Você cria um novo tipo de organização da receita. É o mesmo motivo. Você trocou o tema, perdeu todo o conteúdo. Selinho, plugin. E o widgets. Quem já criou um widget o próprio? Quem criou em tema? Quem criou em plugin? O widget está desenvolvido, está dividido. Então os widgets são aqueles módulos que você pode associar, uma saída de bar, você pode criar os seus próprios. E o widget, ele também ganha o selinho, depende. Por exemplo, quem já instalou um plugin de calendário de eventos, você... Eles geralmente dão um módulo de calendário para você colocar na sua saída de bar que ele vai exibir os eventos que vão acontecer. Não faz muito sentido. Esse widget, ele só tem que existir junto com o plugin, não tem como você vai definir no tema o widget, e aí o widget só vai aparecer se o plugin estiver ativo, enfim, não faz muito sentido. Então os widgets dependem. Você pode criar widgets no tema, é válido para o repositório oficial também, mas o widget, ele não pode depender de um conteúdo adicional. Então, se você faz um widget que vai exibir um custom post type e um custom taxonomy, isso já não é válido, porque você precisa de coisas do território de plugins. Mas seu widget se relaciona bem só com a base do WordPress sem problemas, pode definir no tema. E aqui eu fiz um pequeno gráfico para diagrama de Vane para mostrar a intersecção de territórios de temas e territórios de plugins para ficar bem claro. Então o tema são os templates, definição de características do tema, tudo isso. Então você vai colocar tamanhos de imagens se o seu tema suporta tão bineios. Na verdade, eu nunca vi um tema que não suporta tão bineios. Não sei por que que tem que colocar o ad suporte, mas beleza. E aqui, território de plugins de maneira bem clara, bem visual. E aqui é a massa cinzenta que você sempre vai se questionar aonde que faz mais sentido. Então, customizer meta boxes widgets são a grande dúvida que você tem que analisar caso a caso. E aqui tem exceções. Na verdade, será que a gente tem alguma exceção a regra do território de plugins? Então, como eu falei no repositório oficial do WordPress é um consenso de que você não pode adentrar o território de plugins. Porém, nos Market Places não. Alguns desenvolvedores WordPress, alguns artigos que vocês vão achar por aí, eles defendem que nesses dois casos, por exemplo, se você está desenvolvendo um tema de propósito específico, por exemplo, eu estou desenvolvendo um tema que é para uma plataforma de EAD. Então, tudo bem. Eu posso atacar a custom post type e funcionalidades de plugins, porque aquele tema tem um propósito muito específico. Ele precisa dessas funcionalidades senão o tema não tem sentido nenhum. E aí, temas desenvolvidos sobre medida. Você fez um tema para um cliente fechado ou distribuído. Você poderia desenvolver, você poderia incluir coisas do território de plugins. E aí, eu coloco esse questionamento. Mesmo que o tema seja feito sobre medida, ou tenha um objetivo específico, você não poderia desenvolver um plugin da mesma forma além do tema. E aqui um exemplo. Como você define um plugin, é tão fácil. O mesmo que você colocaria no functions PHP, você coloca em um arquivo do seu plugin. A única diferença é que você tem que definir o cabeçalho do plugin. Com plugin name, descrição, autor, versão e tudo mais. Mas o código é o mesmo. Se você copiar do seu functions e tacar no plugin, teoricamente tudo deveria estar funcionando. Vou acelerar um pouquinho aqui. E aqui o Pital falou um pouco de gerenciamento de dependências com o Composer. Aqui eu queria dar uma outra dica, que é o TGM. TGM plugin activation. Que é uma biblioteca PHP-HP. Posso correr um pouquinho só pra dois minutos. O TGM é uma biblioteca PHP-HP que permite a definição de plugins requisitados e recomendados. Então você pode colocar o TGM no seu plugin e dizer, esse plugin depende desse tema, depende desse plugin. Você coloca o TGM no seu plugin, no seu tema. Esse tema depende desse plugin, ou esse plugin é recomendado, mas não obrigatório. É super fácil instalar o TGM, vocês conseguem ver no site dele. Você baixa o pacote, insere a classe no diretório do seu tema, inclui a classe no seu functions e define quais são os plugins requeridos. Você coloca numa action e define quais os plugins do repositório. Ele já identifica o plugin do repositório oficial e já aparece desse jeito. Acho que quase todo mundo já instalou e tinha essa carinha de sugestão de plugins a serem ativados. Então você pode fazer isso. Tem algumas alternativas, que é o Composer. Tem esse MyPluggingManager, que eu não utilizei, que você pode utilizar para gerenciar dependências e dizer quais plugins são recomendados para o seu tema. E aqui umas considerações finais. Por que evitar entrar no território de plugins? São quatro motivos principais que eu separei. É que a separação de responsabilidades você não tem tudo concentrado, você tem mais modularidade e gerenciamento de dependências você consegue fazer isso se o código fica todo no seu tema você não vai saber o que depende do que e a manutenção fica muito mais fácil. Ou seja, um outro desenvolvedor que vai pegar isso no futuro eles vão agradecer que você fez de forma separada. E agora eu vou te dar umIndy e ele chegar no projeto ver lá vários custom post types criados no tema de forma confusa e ele ter que ficar dando manutenção nisso ou criando plugins que poderiam ter sido criados antes. Aqui algumas referências tem um artigo bem legal do Felipe Elia de Curitiba que fala exatamente isso que eu abordei na palestra e tem o link do make wordpress.org com tudo que entra no território e por que. E aqui minhas redes sociais podem me seguir basicamente e Allison Sousa em quase tudo só pesquisar também. É isso, obrigado pessoal. Tem espaço para perguntas perguntas ilustre Leal Baiano Leal Baiano tinha que estar palestrando vai perguntar. Então, Alisson, vou aproveitar esse tempo como eu não mandei palestra vou aproveitar esse tempinho da minha pergunta para fazer uma palestra aqui rapidinho brincadeira. Então você falou sobre os formulários de contato que eles deveriam estar no território de plugins eu até entendo por conta de fazer parte do modelo de negócio do projeto um formulário de contato, um formulário de cadastro de fornecedores e tal mas aí eu me preocupo com a parte visual que já faz parte do tema, já não deveria entrar na parte do território de plugins aí você pode me dizer mas você pode definir uma estrutura HTML no próprio plugin para dar a saída e a estilização, o CSS vai para o território do tema e aí quando mudar de tema é só estilizar quem trabalha com front-end sabe que muitas vezes a depender do layout o HTML também muda como ficaria nesse caso o cara precisou mudar o HTML ele vai sempre lá no plugin muda faz uma solução mista que de repente o formulário tenha trate o visual no tema mesmo e a parte de back-end fica no plugin o que você pensa disso daí como resolveria essa questão? Certo, eu vou recorrer para a fraseal de Roberto como a gente tem que seguir o que os grandes estão fazendo então como o commerce faz por exemplo você tem os templates criados dentro do commerce e você pode sobreescrever no seu tema lógico que a gente está falando de formulário de contato você não tem um template você tem que fazer um plugin bem feito você vai ter que colocar actions vai ter que colocar filters e aí possibilitar a manipulação do HTML seria uma forma de você ter um controle maior e acho que o resto é isso você ter uma definição básica de estilo básico que não inclui o estilo do plugin se você for estilizar pelo tema e é isso, você escolher se eu estilizar o estilo clássico do que o plugin oferece ou já saber que você utiliza aquele plugin e estilizar no tema mesmo acho que não tem muito o que fazer de diferente disso respondeu, meu twitter não é esse nossa, meu twitter não é esse não sou eu no twitter é a Alisson under sublinhado a S acho que no twitter eu não consegui agora a pergunta de desculpa aí pessoal vocês vão seguir um cara nada a ver aí Alisson, por favor falaste na questão que ocorre muito comigo que sou oriundo do design gráfico trabalho com ordem pré-has desde 2012 encontrei nos temas que tem um visual builder embutido uma solução para dar uma saída de melhor qualidade do que eu via naquele padrão cabeçalho, corpo sidebar, roda a pé então esses dias passei por um perrengue que era o seguinte usando um builder gratuito fui atualizar um tema estragou tudo tudo, tudo, tudo, tudo se perdeu, deu uma M geral e aí o que acontece os short codes foram parar todos dentro dentro do conteúdo existe alguma forma de limpar isso quando acontece esse problema eu não sei se eu sei que desinstalando o plugin o conteúdo ficou lá, todo estragado e aí o seguinte cara só vou te dizer esse site eu construí para um primo meu que é um músico que estava participando do The Voice olha o que aconteceu construir usando um tema grátis e tal passei para o Layers WP que é um negócio simples mas muito bem construído muito usual, muito prático e tal e um dia eu resolvi o site de volta e tal mas eu tenho outros clientes que eu vendi que são músicos é como se eu tivesse criado lá dentro do meu estúdio um tema para músicos para também ser músico, identifiquei algumas necessidades e tal, criei algumas coisas e boti lá invent calendar, não sei o que é e tal calendar esse tema especificamente que eu usei gratuito tem um builder chamado KC em cima do Ocean WP que também é gratuito justamente para fugir daquelas coisas tem temas que eu adquiro, pago lá pago 60 dólares no no Team Forest e tal tem um builder consistente robusto tem uma estrutura boa que eu sei que um dia se eu não sei lá para o Cargas da Água daqui a pouco o cliente trocar ele vai dizer para mim o site foi pro saco porque eu troquei lá e sumiu tudo sei o que vai acontecer justamente eu não sou um desenvolvedor o máximo que eu vejo é um CSS então neste caso assim acontecer e a codificação ficou toda dentro do post, toda dentro da página e foi pro saco para consertar isso eu não sei se tem muito tem um plugin que é shortcode remover alguma coisa assim no repositório oficial mas ele só vai remover os shortcodes do seu conteúdo então toda aquela estrutura que o construtor visual tinha de separar seções, vai ter seu conteúdo em texto planos seguido então por isso que construtor visual embutido no tema é uma péssima ideia a ideia é sempre você usar construtor visuais que sejam plugins e o tema independente dele que aí você pode atualizar o tema e não perder e o que a gente sempre fala isso é de não usar o construtor visual para construir o site inteiro que aí perde o propósito de tema o construtor visual é para você construir algumas lendes em pages, home pages páginas específicas mas para consertar mesmo não saberia dizer, é uma luta não, pode usar Elementor é um excelente construtor visual é, você teria que entrar no campo das expressões regulares mas aí tem aquela frase se você tem um problema de expressões regulares você tem dois problemas geralmente é isso mas sim, se você tiver conhecimento de expressões regulares mas mesmo assim você vai ter que ter uma luta, para saber qual shortcode ela é relacionada a que tipo de sessão para o que você vai substituir então um trabalho bem grande tinha mais uma pergunta aqui, Anissa só para acrescentar sobre os page builders page builder que usa shortcode é gambiarra, não tem outro nome é mal construído e acaba com o propósito do Wordpress a grande evolução que ele fez na web que é separar template de conteúdo shortcode embute o template dentro do conteúdo e vice-versa assim que dá algum problema no tema você perde conteúdo então isso já não é mais o Wordpress o Elementor que o Alice falou é gratuito, não usa shortcode se o plugin falha desinstala qualquer coisa assim o seu conteúdo volta para o Wordpress ele vai perder a formatação mas ele vai continuar existindo e vai continuar a salvo dentro do banco de dados então essa nova leva de que estão sendo criadas é que realmente estão podendo ser levados a sérios que usam shortcodes gambiarra mais alguma pergunta talvez mais uma tenha tempo se não a questão de utilizar os plugins vai aumentar um pouco o número de plugins dentro do site em relação a desempenho velocidade pode afetar alguma coisa eu não tenho um benchmark sobre isso mas se você precisa da funcionalidade você vai colocar ela no seu functions PHP que é um plugin embutido dentro do seu tema ou você vai criar um plugin então eu acho que não tem aí seria bastante técnico não ter esse conhecimento para saber se tem diferença em carregar um plugin ou executar o que está no functions mas eu acho que todos os outros benefícios pesariam sobre os milissegundos que a gente teria aí então se você precisa da funcionalidade você pode ter 100 plugins a quantidade não importa se a funcionalidade é realmente necessária não tem número limite seu site tem que ter no máximo 10 plugins 20 plugins não teve um cara que atualizou pegou uma instalação Wordpress atualizou Wordpress com 100 plugins ativos utilizou tudo funcionando lindamente se o plugin é bem feito confiável você não vai ter problemas e se você mesmo que desenvolveu aí é só a sua confiança ambiente de teste sempre bom a desenvolver local acho que é isso pessoal vamos partir para o Donin aqui para sorteio de Brindis obrigado