O ThemeForest atualizou recentemente seus requisitos de envio de temas do WordPress para ser mais rigoroso e estar mais alinhado com as práticas recomendadas de desenvolvimento de temas do WordPress.
As diretrizes exigem o uso de vários dos principais recursos do WordPress, ganchos de tema padrão e não permitem funções PHP (como base64 e fopen) que realmente não deveriam ter lugar em um tema do WordPress.
Basicamente, é praticamente a política de Revisão de Temas do WordPress.org, com algumas exceções.
No geral, é um passo na direção certa e promove as práticas recomendadas em um dos mercados de temas do WordPress mais populares da rede. Há apenas um problema…
Shortcodes admissíveis
Um aspecto que me chamou a atenção, no entanto, foi a forma como certas funcionalidades de shortcode “admissíveis” eram permitidas (ou seja, incluindo-as diretamente no arquivo functions.php do tema). Os listados como “admissíveis” incluíam o seguinte:
- botões
- tabelas de preços
- contêineres de imagem
- dropcaps
- listas
Os códigos de acesso inadmissíveis incluem: mapas, acordeões e alternâncias, conteúdo em caixa, colunas, formulários de contato, gráficos.
O problema com códigos de acesso em temas
Não consigo explicar melhor do que Justin Tadlock já o fez. Um dos problemas mais perceptíveis é que, quando um usuário muda de tema, os códigos de acesso não são mais analisados.
Digamos que o tema "Super Awesome" tenha um recurso de shortcode que produziria um grande botão verde com um link quando você digitasse algo como [button url="http://example.com"]Big Green Button[/button].
Quando você muda para outro tema (convenhamos, as pessoas se cansam facilmente dos temas), não há mais o grande botão verde. Em vez disso, você vê o shortcode não analisado na postagem como se fosse qualquer outra parte do conteúdo, assim:
[button url=”http://example.com”]Big Green Button[/button]
A aparência é feia, confusa e fora do lugar, e é um incômodo para o usuário voltar e remover/substituir todos eles.
O outro problema com códigos curtos em temas
Algo que Tadlock abordou em seu artigo “Dealing with shortcode madness” (Lidando com a loucura dos códigos de acesso) é que muitos códigos de acesso são tão simples e parecidos com HTML que talvez seja até melhor instruir os usuários a escrever um pouco de código HTML real(*gasp*).
O mesmo shortcode [button url="http://example.com"]Button Text[/button] do meu exemplo acima poderia ser facilmente reescrito como algo como:
<a href="http://example.com" class="button">Texto do botão aqui</a>
Embora possa não haver código CSS estilizando o seletor .button em um novo tema, pelo menos um link normal será exibido. O que é uma grande melhoria em relação a um shortcode [button] não analisado que aparece no conteúdo de uma postagem.
Além disso, acredito que todo usuário do WordPress deve ter pelo menos algum conhecimento básico de código HTML. Ensiná-los, mesmo que em pequenas partes (como construir um link), ajudará. Se eles conseguirem entender um shortcode, não será preciso muito mais para que entendam o HTML básico.
Mas os usuários não se importam!
Um argumento comum que vejo defendendo todos os tipos de práticas ruins quando se trata de desenvolvimento de temas é que os usuários simplesmente não se importam. Quero dizer, talvez eles nunca queiram atualizar o tema e, nesse caso, essa questão do shortcode seria um ponto discutível.
O problema é que, inevitavelmente, alguns usuários desejarão trocar de tema algum dia. Alguns usuários desejarão instalar um plug-in que pode entrar em conflito com algum outro código mal pensado em um tema.
Nesse caso, eles provavelmente se preocuparão e se perguntarão se o tema que compraram com centenas de códigos de acesso incorporados e outros recursos supérfluos realmente valeu a pena.
A maneira correta de incluir códigos de acesso
Coloque-os em um plugin. Um plug-in realmente simples. Ele não precisa de um painel de opções separado. Basta copiar e colar literalmente tudo o que você iria incluir no arquivo functions.php do seu tema e colocá-lo em um plug-in.
Ele pode até ser incluído em um pacote com algo como o TGM Plugin Activation para torná-lo obrigatório na ativação do tema. Ou não. Um tema continua sendo um tema sem shortcodes.
Dessa forma, se o usuário mudar de tema, os códigos de acesso ainda funcionarão, pois essa funcionalidade é controlada pelo plug-in que ainda está ativo.
Talvez o plug-in também possa enfileirar estilos para os códigos de acesso. Dessa forma, os botões verdes grandes que você incluiu com o shortcode [button] continuarão sendo botões verdes grandes, independentemente do tema usado.
Por que o ThemeForest permitiu códigos de acesso “admissíveis”?
É difícil dizer qual foi exatamente o raciocínio por trás dessa decisão. Japh Thomson, um evangelista de WordPress da Envato (empresa controladora do ThemeForest), disse o seguinte sobre isso em um comentário no WPMU.org:
A funcionalidade complexa de shortcode realmente deve residir em um plug-in, não em um tema. Isso também faz sentido quando você considera que a maioria dos nossos autores tem vários temas.
Obviamente, ele entendeu. Portanto, é um mistério para mim por que haveria qualquer shortcode “admissível”. E sim, percebo que ele usou a palavra “complexo” na citação acima, e os códigos de acesso admissíveis tendem a ser bem simples (dropcaps, listas etc.).
Por mais simples que seja um shortcode, os problemas que descrevi acima ainda existirão. O ThemeForest tem se mostrado sensível ao feedback da comunidade, portanto, é possível que essa regra seja alterada no futuro.
Conclusão
Sei que esta postagem parece um pouco minuciosa, e essas novas diretrizes são definitivamente um grande passo na direção certa. Mas realmente não há motivo para que qualquer shortcode seja permitido em um tema, seja ele simples ou não.
Você consegue pensar em uma situação em que um tema lançado publicamente precise incluir a funcionalidade de shortcode por meio de seu próprio functions.php?
– Theme Lab (@themelab) 9 de julho de 2013
Alerta de spoiler: não recebemos nenhuma resposta a esse tweet com um exemplo real de um shortcode que precise ser incluído em um tema lançado publicamente.
Isso porque não é fácil para um usuário voltar e substituir centenas de códigos de acesso de botões depois de mudar para um tema que não tem exatamente o mesmo suporte a códigos de acesso.
Thanks so much for this post, I have just purchased a ThemeForest theme and I am having this same problem! When we uploaded theme, the pages say the shortcode is not compatible … what to do now to make it compatible? Thanks!
While I agree shortcodes should reside within a plugin instead of a theme, the unparsed code will still appear when the plugin is disabled or replaced by another shortcode plugin. Either way it can be a hassle for the person performing the changeover.
Learning basic HTML seems best.
Totally agree on this. Themes should handle layout and styles. Anything that adds some extra features must go in a plugin.
I have the same stance on shortcodes, but can see the reasoning for some themes including them for non tech savy users to add features easily and in turn helps sell more of developers themes.
here here.
It would also be nice if there was some sort of elegant degradation for shortcodes that are no longer active.
Thus, possible problems can be avoided with functions which may be added in the future in different theme. Issues of maintenance are important purchasing arguments – at least for me!
I completely agree with you. Very few people stick with one theme forever, unless it’s completely custom (and then you don’t have the themeforest problem) and shortcodes are a pain to deal with. I recently discovered this problem when I started changing from a theme-junkie theme to a studiopress/genesis theme. Now I’ve put the change on hold, despite spending $80 on it already, because there is too much to change even on my new site.
Hey Leland, great post, thanks for your thoughts!
We’ll be releasing an update to these requirements shortly, based on feedback from our authors, and I hope you’ll be pleased with some of the adjustments we’ve made (specifically in relation to shortcodes) 🙂
I think it’s not only a compatibility issue with other themes, but a content-related issue too. A shortcode should be just a helper to process content, and themes should only display pre-processed content, not process the content by themselves. When themes process shortcodes on their own, they’re treating that piece of text (or at least it looks like the developer does it) as a call to a visual element, not to a functional one (what it really is), like if the scope of what a theme is for was missing there. That practice shows a lack of clarity about what content, functionality and visualization are, and how those elements should be managed (i.e., content should be stored into DB, functionality should be managed via WP core and plugins, and visualization via themes; just as a very basic example). There’s no need to be a content expert, an experienced programmer or a great designer to know such things, just a little bit of attention and careful thought on what we’re offering to our users, and how easy or difficult will be for them to use our products. I think it’s OK if you don’t know the differences but you’re open to learn and improve, but, on the other hand, to know and have in mind all these things and offer shortcodes (and any other functionality-related stuff) in themes anyway, that seems to me like a disloyal practice that makes your users captives of your product. I know that sometimes the line between visualization and functionality is really thin, but in most cases the difference is non-discussable.
Shorry for the long reply, this is a topic that I’m really interested in. Great post 🙂
Hey Andrés, no need to apologize for the lengthy reply, you make some great points!
Thanks for this… I have ongoing issues with shortcodes in themes that I have bought. And when I retheme them, I have legacy code everwhere which needs replacing.
Peter, that’s a perfect example of the problem with shortcode in themes.
It gets even worse when other non-presentational functionality is also included in a theme, maybe something to talk about in a future post.