Vulnerabilidade na versão 4.7 do WordPress

Uma das grandes features do WordPress lançada na versão 4.7, a API de REST possui uma vulnerabilidade. Se você utiliza esta versão corra já e atualize seu WordPress, nas versões 4.7 e 4.7.1 é possível injetar conteúdo em qualquer post, mesmo não estando logado. Alguns sites falam em 1.5 milhão de sites infectados.

A vulnerabilidade

Este bug foi corrigido na versão 4.7.2. A vulnerabilidade pode trazer um problema bem chato qualquer pessoa pode injetar conteúdo em seus posts através da WordPress REST API, um dos endpoints da API permite que os visitantes deslogados consigam editar, excluir e adicionar qualquer post do seu site ou blog.

Solução

Então fique de olho sempre deixe seu blog ou site atualizado e com backups em dia. Desde a versão 3.7 o WordPress possui updates do core automático, mas com um intervalo maior para realizar a atualizar nesse caso o melhor é antecipar a atualização para evitar dor de cabeça. Mais uma dica de segurança é seguir o WordPress security checklist, uma série de passos para evitar problemas com o seu site:

http://wpsecuritychecklist.org/br/items/

 

Foto: Tim Lee

WordCamp Europe Second day recap

The second day of WordCamp Europe I saw some familiar faces that I saw the last day, for example, Kat a Woocommerce employee, she is responsible for documenting the plugins and API inside Woothemes. Andres the guy that works at WPML, Julia a German girl works as a freelancer in Berlin. Theses things make the event easier because I started to know the people and know whom I asked what I need do.

My Task

Now was in the registration; this time was a little hard because, I needed to give many different pieces of information about the event, about the rules, how solved some small problems. But was good to practice my English.

After the registration, I finish my tasks in te second day and at 11 AM I went to Halle E to watch the lectures, the first that I saw was about rest API. I think this is the focus of Automatic in this time, Calypso, Rest API and REACT are present in all lectures about development. If you haven’t studied yet, you need look theses technologies.

When the second day ended, I was so tired but felt everything was good.

After the second day was the after party, I had to meet my friends in another party and just pass to say hello and decided to walk around the city before went to another place and this was the best idea. Wien at night is so beautiful, the architecture, the city centre, the lights everything creates a wonderful atmosphere. The city is incredible. After I was little walking through the city, I meet my Brazilian friend that works in Mailpoet, there we talked about work, life in Europe and remote jobs.

The contributor day

The last day was the contributor day, there were many tracks, that we could contribute to:

  • Community
  • Marketing
  • Theme Review
  • WordPress Core
  • Rest API
  • Translation

There we needed to choose one of these themes, and I decided Theme review was a good experience, in the first part, the Leader developer shows how to review a theme and give many tips. In the second part, we choose a Theme in the repository to review. For me was the first time that I reviewed a theme in the WordPress repository before I didn’t figure out this was so simple.

Last words

In resume work as a volunteer was the best thing that I decided to do in my time in Europe, I knew many people, getting touch with old friends. Was a big opportunity to know the European WordPress Community and was my first and biggest event as crew in Europe. Now I will start looking for another event here in Europe.

Wordcamp Europe first day recap

I finished my first experience as a volunteer in an IT event outside Brazil. Now I can say – It was amazing. Wordcamp Europe was a huge event with more than 1500 people from different nationalities. A crazy thing about Europe, here is easy to find different nationalities anywhere, imagine in a huge event like that. Many different cultures in a short distance if we compare it to Brazil. But sometimes language is not a real problem most of then speak english. It is possible speak with, Polish, German, Dutch, Finnish…

It is time

On Friday at 7:30AM some volunteers were there waiting to the doors open, some of them knew each others, because two days before happened some warm up events. When they opened the doors to us, we got the last instructions to start to work in the event: where the stages were, what our tasks were etc…. At 8:30AM the doors WERE opened for attendants. The same problem about registration happened in any WordCamp around the world, a huge group arrived at the same time and we needed to make the things go quickly. But always before the first lecture the groups were inside the event. This moment reminded of WordCamp São Paulo.

9:30AM I STARTED to WORK: door guard. What I need to do? Things like: Pass instructions about the Stage, informations about the schedule, show the directions to other stages and close the door when the place is full. Easy? A little. It was good because I started to speak a lot, I enjoyed the time to practice my english during two hours, The plan was to stays there only one hour, but the time passed by and I didn’t notice. When I finished I got another task: to organise the vegetarian line to the lunch. And my last task was inside the Swag station.

The lectures

After my work I could watch one lecture about Calypso the new react WordPress API, Matias presented this lecture, I met him in my first WordCamp São Paulo. The second lecture that I saw was with Erica she talked about the duties and challenges of being a “Happiness Engineer”.

The first day was little hard. When I arrived there I was tired because I went to another trip before and started working in sequence, the first day I needed to know many things about the event, many new words, new friends. But I love Wordcamps and this made things easier.

I was a Wordcamp organiser and volunteer in Brazil for a long time and the feeling is the same in another country, the first minutes when the people started to arrive, at the same time I started to think about all the things we need to do the best event, I started to feel the adrenaline to make things work.

Trabalhando com shortcodes no WordPress

Vamos falar sobre shortcode nesse post, mas antes vou contar uma história para vocês. Semana passada me deparei com um problemas, daqueles que você só enxerga em produção. Desenvolvendo um tema para um freela, tudo ok no ambiente de teste. Quando o site foi para produção nenhum vídeo carregava.

Entrei para verificar o conteúdo, nele tinha uma tag video.

quando bati o olho pensei duas coisas ou é um shortcode antigo ou é algo do jetpack. Primeiro passo, verificar os plugins se estão ativos, em seguida atualizar o WP, por fim atualizar o Jetpack. Resultado nada!

Você faz aquele exercício o que foi que eu fiz antes “desabilitei o tema anterior” quando fui olhar o código do tema antigo estava lá o shortcode video. Shortcode é um recurso muito útil para que está criando um tema ou plugin. Mas se está criando um short code para o tema ele deve ser totalmente vinculado ao tema, ou seja, um recurso que só faça sentido existir naquele tema ou plugin.

Exemplo, a tag vídeo estava presente em todos os posts mudou o tema, quebrou todo o site. Para alguns recursos hoje em dia não faz muito sentido, um caso é o youtube basta colar o link da url no editor visual que o WP já cria um embed. Optar por um recurso do WP independente do tem ou plugin a funcionalidade vai estar lá.

Ok, vamos para a parte legal. Como eu crio um shortcode?

Primeiro temos que adicionar em nosso function.php o seguinte hook:

add_shortcode( $tag , $func );

Ele espera dois parâmetros, nome da tag e a função que ele irá chamar na prática ele vai ficar da seguinte forma:

Exemplo acima criamos o shortcode “hello” quando a shortcode api encontrar a tag [hello] dentro do meu post saberá que tem que chamar a função say_hello, basicamente ela cria um html como o texto olá meu nome é “x”. Notem que concateno com um valor que passamos como parâmetro na função.

Ela espera que passamos um atributo nome, por exemplo, [hello nome="ze"]. Mas se caso o usuário não passar o valor o que vai acontecer ? ZICA!

Mas podemos definir um atributo default para resolver este problema:

No caso usei um exemplo simples só montar um texto p. Mas poderíamos montar um componente de share, um componente de sugestão de produtos, o componente de publicidade. Lembrando que o recurso fica atrelado ao tema ou plugin, quer saber mais? Também adicionei uma versão em português no codex do WordPress: https://codex.wordpress.org/pt-br:Function_Reference/add_shortcode

WordPress 3.9

Saiu no dia 16 de Abril a versão 3.9 do WordPress, intitulada SMITH o foco nessa versão foram as melhorias na parte de edição e controle de mídia.

Editor visual

Na parte de edição de conteúdo foram três mudanças significativas o editor visual com o foco em performance, acessibilidade e o suporte ao mobile também teve um cuidado especial nessa versão.

Edição de imagens

Agora o acesso a transformer, crop e ferramentas de rotação foram facilitados. Também é possível usar o recurso de drag and drop na tela de edição e não apenas na tela de upload de imagens.

Além das melhorias na parte de edição também foram implementadas as seguintes:

  • Preview de galerias recebeu melhorias na parte de design.
  • Player de Audio e vídeo agora possuem uma playlist nativa.
  • Agora na tela de edição do com preview do WordPress é possível personalizar a sessão de widgets.
  • A ferramenta de edição de header também passou por melhorias na parte de upload, crop e administração de headers.
  • A sessão de controle de temas passou por melhorias para tornar a experiência do usuário mais agradável.

Quer conferir a nova versão só acessar o link 

theme1
nova área de aparências dos WordPress
nova galeria da versão 3.9 do WordPress
nova galeria da versão 3.9 do WordPress

Padrões de código JavaScript no WordPress

Em busca da produtividade e legibilidade do código presente nos temas a equipe do Core do WordPress escreveu uma seção para falar sobre padrões de codificação para plataforma. Esse é o segundo post da sobre o assunto no post anterior falei sobre padronização de código CSS, Nesse post vamos abordar padrões de escrita para JavaScript.

JavaScript tornou-se uma das principais linguagens da atualidade e é um item chave no desenvolvimento de temas e plugins no WordPress. Claro que padronizar seu código JavaScript é essencial para manter consistência no projeto. Todo código base deve parecer escrito por uma única pessoa.

O “WordPress JavaScript Coding Standards” foi uma adaptação do “jQuery JavaScript Style Guide”, o padrão do WordPress difere do jQuery nos seguintes pontos:

  • WordPress usa aspa simples para declaração de string.
  • Instruções de Case são indentadas para indicar as mudanças de blocos.
  • Conteúdo de funções são constantemente indentadas, incluindo os empacotadores de fechamento de todo o arquivo.
  • Algumas regras para espaço em branco são diferentes, para manter consistência com o “WordPress PHP coding standards”.
  • 100 caracteres são o limite para uma linha de código jQuery, mas no WordPress não são rigorosamente aplicadas.

Espaçamento

Uso de espaços livremente em todo seu código. “Em caso de dúvida, tire o espaço.”

Estas regras incentivam o uso de espaço para melhorar a legibilidade do código. O processo de minificação cria arquivos otimizados para os browsers lerem e processarem os arquivos, mas não para os programadores. O ideal é utilizar uma versão minificada para produção e uma versão sem minificação para desenvolvimento.

Além deste quesito temos as seguintes recomendações para espaçamento:

  • Crie indentação com tab.
  • Retire os espaços em branco no final da linha e em linhas em branco.
  • As linhas não devem ser longas, não exceder o limite já especificado de 100 caracteres(contando tabs e espaço). Esta é uma regra “soft”, mas linhas longas geralmente apontam código desorganizado.
  •  if / else / for while / try, os blocos devem sempre utilizar chaves e quebras de linhas, evite utilizar condicionais em uma única linha com chaves.
  • Os operadores de “unários”, exemplo, ++ ou — não devem ter espaço entre seu operando, exemplo “contador++”.
  • Qualquer “,” ou “;” não deve preceder de espaço
  • Qualquer “;” utilizado como sinalizador de um final de uma operação deve estar sempre  ao final da linha, ou seja evite “contador++; a = contador;” na mesma linha.
  • Qualquer “:” depois de um nome de uma propriedade em uma definição de um objeto, não deve ser precedido de espaço, exemplo “valor: 9”.
  • A “?” e “:” de uma condicional ternária deve ter espaço em ambos os lados
  • Não utilize espaço em declarações de tipos vazios, exemplo, {} [] ou fn().
  • Toda “!” utilizada como operador de negação deve conter um espaço em seguida.*
  • Indente todo conteúdo de uma função, mesmo que todo o arquivo esteja contido dentro da função.*
  • Espaços podem podem alinhar comentários ou espaços dentro de uma linha de código, mas somente o TAB pode alinhar o início de uma linha de código.*

Os itens marcados com um “*” ao final da linha fazem parte do WordPress JavaScript standards, sendo um complemento ao padrão do jQuery. Essas aplicações são recomendadas para manter coerência com os padrões de escrita do PHP.

Os espaços em branco são facilmente acumulados no final de cada linha, evite isso utilizando JSHint,  Outra maneira de evitar esses espaços é definindo cores para os espaços no estilo do seu editor.

Objetos

Declarações de objetos podem ser feitas em uma única linha, mas isso não é aconselhável lembrem das recomendações do tamanho da linha. O recomendado é deixar uma propriedade por linha. Nome de propriedades precisam somente de aspas quando possuem uma palavra reservada ou caracteres especiais:

Arrays e Chamadas de Funções

Sempre adicione espaços extras em torno dos elementos e argumentos:

Exceções

Para manter a consistência com o padrão PHP, não inclua um espaço em torno strings ou inteiros usados como keys de uma array:

Função com callback, objetos ou array como um argumento único, sem espaço em ambos os lados do argumento:

Função com callback, objeto ou array no primeiro argumento passamos sem espaço o segundo argumento seguimos o padrão:

Essa regra se aplica caso a função/array/objeto for o último argumento, ela segue sem espaços e os primeiros itens seguem o padrão.

Um bom exemplo de uso de espaçamento:

Indentação e quebra de linhas

Indentação e quebra de linhas adicionam legibilidade para declarações complexas. Tabs devem ser usados sempre para indentação do conteúdo que estiver dentro das chaves, também usamos um tab para sinalizar o nível do conteúdo.

Blocos

IF, ELSE, FOR, WHILE e TRY devem sempre utilizar chaves e estar organizado em multi-lines. A abertura da chave deve estar na mesma linha da definição da função/condicional/loop. A chave de fechamento deve estar na linha seguinte da última declaração do bloco.

Exemplo:

Operações Multi-line

Quando uma operação é muito longa para uma única linha, utilizamos uma quebra de linha e tal deve ocorrer após um operador.

Métodos encadeados

Quando é utilizado um método encadeado ele pode criar uma linha muito longa, o remendado é ter uma chamada por linha, se o método muda o contexto ele deve ser aplicado um nível extra de indentação.

Atribuições e variáveis Globais

Declarando variáveis com var

Cada variável deve começar com a declaração “var” e as variáveis separadas por virgula. Na quebra de linha utilize indentação como no exemplo a seguir:

Variáveis Globais

No passado do WordPress o seu core fazia uso pesado de variáveis globais. Algumas variáveis globais ficam disponíveis por necessidade de integração com os plugins e não devem ser removidas. Outra recomendação é que todas as variáveis globais devem ser documentadas.

Bibliotecas Comuns

Backbone, jQuery, Underscore, e o “wp global” são todos registrados como itens “globais permitidos” no root do arquivo .jshintrc.

Backbone e Underscore podem ser acessados diretamente a qualquer hora. jQuery deve ser acessado $ passando por jQuery como um objeto de uma função anônima:

Isso irá evitar a chamada do “.noConflict()”, ou definir que o $ seja usado com outra variável. Os arquivos que adicionam ou modificam, o “wp object” acessa com mais segurança os itens globais isso evita a substituição previa do set de propriedades:

Convenções de nomenclaturas

  • Variáveis e nomes de funções devem ser palavras completas, utilizando camel case com a primeira palavra em caixa baixa. Esta é uma área que difere dos padrões do PHP para WordPress.
  • Construtores que utilizam “new” devem ter a primeira letra maiúscula.
  • Os nomes das variáveis e construtores devem ser descritivos, mas não excessivamente.
  • Exceções são permitidas para “interators”, tais como o uso de “i” para indicar o indice de um loop.

Comentários

Comentários vem antes do código a qual se refere e deve sempre ser precedido de uma linha em branco. A primeira letra do comentário deve ser maiúscula e inclua frases completas que descrevam a operação, não tenha preguiça de incluir comentários, eles são importantes para manter a fluidez do desenvolvimento. Após “//” inclua um espaço.

Igualdade

As verificações de igualdades estritas(===) deve ser utilizada no lugar da verificação de igualdade abstrata(==). Use somente (==) quando realmente deseja saber se o valor é null ou undefined.

Checando tipos

Para checagem de tipos utilize esse padrão:

  • String: typeof object === ‘string’
  • Number: typeof object === ‘number’
  • Boolean: typeof object === ‘boolean’
  • Object: typeof object === ‘object’ or _.isObject( object )
  • Plain Object: jQuery.isPlainObject( object )
  • Funções: _.isFunction( object) or jQuery.isFunction( object )
  • Array: _.isArray( object ) or jQuery.isArray( object )
  • Element: object.nodeType or _.isElement( object )
  • null: object === null
  • null or undefined: object == null
  • undefined:
    • Variáveis globais: typeof variable === ‘undefined’
    • Variáveis locais: variable === undefined
    • Propriedades: object.prop === undefined
    • Qualquer um dos anteriores: _.isUndefined( object )

Strings

Use aspas simples para string literais:

Switch

O uso de switch é geralmente desencorajado, mas pode ser útil para comparação de um grande números de casos, especialmente quando realizamos uma série de tratamentos e queremos incluir um tratamento para exceções com “default”.

Como usar o switch:

  • Use um “break” para cada “case” com exceção do “default”.
  • Indente o conteúdo dentro do case com um tab

Não é recomendado utilizar o return dentro do case, defina os valores de saída e utilize o return após o switch, podemos ver uma aplicação no código abaixo:

Boas Práticas

Arrays

Crie arrays com [] no lugar de new Array().

Objetos

Existem várias formas para criar um objeto com JavaScript. Notação do objeto literal, “{}”, é considerado o mais performático e de fácil leitura.

A notação literal de um objeto deve ser usado a menos que o objeto trabalhe com prototype, neste caso utilizamos o “new”

As propriedades do objeto devem ser acessados via “.” a menos que a chave da propriedade use o nome de uma palavra reservada, uma string não válida ou venha através de uma variável.

Condicionais “Yoda”

Para manter consistência com os padrões de código do PHP sempre compare com a variável no lado direito e a constante no lado esquerdo, essa regra vale para strings, booleanos, inteiros…

Interações

Quando queremos varrer uma coleção utilizamos o “for”, é recomendado armazenar o valor máximo em uma variável em vez de recalcular o valor máximo em casa interação.

Na documentação temos duas recomendações para underscore, jQuery e uma recomendação para o uso de JSHint. Esse itens eu prefiro tratá-los e um post separado a tradução desse artigo me ajudou bastante muitas recomendações desconhecia. Algumas recomendações tratam da parte visual do seu código um código organizado para mim é igual a uma boa caligrafia. Isso ajuda na legibilidade e claro uma padronização deixa o time bem entrosado.

O artigo original você confere aqui:

http://make.wordpress.org/core/handbook/coding-standards/javascript/

Os Padrões JavaScript coding do WordPress são baseados nos padrões do jQuery você pode conferir aqui:

http://contribute.jquery.org/style-guide/js/

Padrões de escrita de CSS

No último sábado dia 23 tivemos o WordCamp São Paulo evento oficial organizado pela comunidade WordPress. Uma das palestras que me chamou atenção foi a do Claudio Sanches, falou sobre padrões de codificação e dicas sobre desenvolvimento com WordPress, sua palestra teve o nome “Não é porque funcionou que significa que esta certo!”.

Uma das dicas do Claudio Sanches em sua palestra,  foi sobre o HandBook do WordPress documentação gerada pela equipe do Core do WordPress, nela contém dicas sobre codificação de CSS, HTML, JavaScript e PHP. Fiquei muito interessado no assunto e neste post vou traduzir os principais pontos do Handbook sobre CSS. Lembrando que esses padrões são especificados pela equipe do core do WordPress existem outros padrões definidos por outros times, mas muitas regras dessa guideline também podemos aplicar em projetos sem ser WordPress.

Estrutura

Uma estrutura limpa e legível é muito importante em um projeto com grandes equipes:

  • Para indentar use tabs, não use espaços.
  • Adicione duas linhas em branco para separar seções e uma linha para separar blocos da mesma seção.
  • Caso aplique uma mais de uma regra para um seletor colocar um em cada linha

exemplo:

Seletores

São muito importantes para eficiência do seu CSS, mas pode ter resultado inverso no projeto quando mau executado.

  • Semelhante ao padrão de codificação do WordPress para nomes dos arquivos use letras minúsculas e palavras separadas por hífens ao nomear seletores.
  • Evite camelCase ou sublinhados.
  • Use seletores legíveis quem descrevam qual é elemento e qual é o sua aparência.
  • Seletores por atributo devem usar aspas duplas amarrando o seu valor.
  • Evite seletores sobre-qualificados, por exemplo, “div.container” podemos utilizar apenas “.container”.

Exemplo:

Propriedades

Menos é mais, verifique se você não está repetindo o estilo ou introduzindo dimensões fixas(quando a solução fluida é mais aceitável).

  • Propriedades devem ser seguidas de uma coluna e um espaço
  • Todas propriedades devem estar em caixa-baixa, exceto para nomes de Font específicas.
  • Usar código hexadecimal para cores, ou utilizar rgba() somente quando necessitar de utilizar opacidade.
  • Evitar de utilizar a propriedade rga em letras maiúsculas
  • Quando possível encurtar os valores hexadecimais: #fff ao invés de #FFFFFF
  • Use shorthand(exceto para overriding styles) para background, border, font, list-style, margin e padding.

Ordenação de Propriedades

Ordenação aleatório de propriedades é um caos, isso não é poesia. No Core do WordPress, utiliza dois padrões de ordenação: a lógica ou ordenada por categoria. As propriedades dentro de uma categoria são também estrategicamente ordenadas para criar uma transição entre seções, por exemplo, a propriedade “background” escrita antes do “color”.

A ordenação por categorias tem a seguinte base:

  • Display
  • Posicionamento
  • Box model
  • Cores e tipografias
  • Outros

Exemplo:

Vendor Prefixes

São os prefixos para engine de cada browser, por exemplo,“-webkit”. Devem ser ordenados dos prefixos mais longos para os mais curtos. Valores devem ser alinhados a esquerda após os dois pontos os valores alinhas com tab com se fosse uma única coluna

Exemplo:

Caso especial CSS gradients:

Valores

Seguindo as guidelines abaixo podemos manter um alto grau de consistência em nosso arquivo CSS.

  • Espaço antes do valor e depois dos dois pontos
  • Sempre terminar com ponto e vírgula(claro)
  • Usar aspas duplas ao invés de aspas simples
  • Valor 0 não deve ter unidade(exemplo: 0%, 0px, 0em…)
  • Use o zero a esquerda para valores decimais, exemplo, evite usar valores como .5 o ideal é 0.5.
  • Em Múltiplos valores separados por vírgula, cada valor deve ser separado por vírgula ou uma nova linha.

Exemplo:

Media Queries

Media queries permitem adaptar o nosso DOM a diferentes tamanhos de tela. Não se esqueça de testar todas as regras para ter certeza que este será o esperado. Em geral, é aconselhável manter as media queries agrupadas na parte inferior de seu arquivo css. Uma exceção é feita para p arquivo wp-admin.css no core.

A regras para o media queries devem ser indentadas em um nível:

Exemplo:

Comentários

Caso tenha preocupações sobre o tamanho do arquivo, utilize arquivos minificados e constante SCRIPT_DEBUG. Comentários longos devem ser quebrados a partir de 80 caracteres.

Uma tabela de conteúdo deve ser utilizada para stylesheet extensos, especialmente os que são altamente seccionados para isso usamos um índice numérico(1.0,1.1,2.0, ect) que auxilia a busca, nesse caso repetimos o número do índice na seção, assim quando o usuário realizar a busca o apontador irá pular para o local correto.

Comentários devem ser formatados tanto quanto PHPDoc é. Cabeçalho de Seções e subseções devem ter novas linhas antes e depois. Comentários inline não devem ter linhas vazias separando o conteúdo de um item para cada relacionado.

Exemplo de seções e subseções:

Exemplos inline:

Considerações finais

  • Manter o código bem escrito desde o início, nos ajuda a manter a visão geral, deixando nosso código flexível a mudanças.
  • Se você está tentando resolver um problema, esforce para resolver o problema antes de adicionar mais.
  • Saiba quando usar a propriedade height. Isto deve ser usado para incluir elementos outside(como images). Caso contrário, use line-height para ter mais flexibilidade.
  • Não redefina propriedades default, por exemplo, display:block em elementos blocados.

Referências:

http://make.wordpress.org/core/handbook/coding-standards/css/
https://speakerdeck.com/claudiosmweb/nao-e-porque-funcionou-que-significa-que-esta-certo