Palestra sobre o WP-CLI no WordCamp BH 2014

Hoje dei uma palestra sobre o WP-CLI no WordCamp Belo Horizonte 2014.

O WP-CLI é um conjunto de ferramentas para gerenciar o WordPress na linha de comando.

A apresentação foi muito parecida com a que dei ano passado no WordCamp São Paulo. Fiz algumas pequenas modificações nos slides e publiquei eles no link abaixo:

http://rodrigoprimo.github.io/wp-cli-wordcamp-bh-2014/

Palestra sobre o WP-CLI no WordCamp São Paulo 2013

Amanhã vou dar uma palestra sobre o WP-CLI no WordCamp São Paulo 2013.

O WP-CLI é um conjunto de ferramentas para gerenciar o WordPress na linha de comando.

Segue abaixo o link para os slides que fiz para a apresentação:

http://rodrigoprimo.github.io/wp-cli-presentation/

Relato do WordCamp San Francisco 2013

Na última semana de julho, eu, Leo e Catia fomos, representando o Hacklab, para San Francisco para participar do WordCamp San Francisco 2013, o maior evento da comunidade do WordPress. Foi uma ótima oportunidade para conhecer alguns dos desenvolvedores da Automatic e saber quais são os planos para o futuro do projeto e da comunidade.

Os dois primeiros dias do evento foram dedicados a palestras dividas em duas trilhas. A primeira tinha como público alvo desenvolvedores e designers e a segunda usuários e empreendedores. O terceiro e último dia foi reservado para o Contributor Day, onde os interessados tem a oportunidade de contribuir diretamente com o WordPress.

Saguão de entrada do WordCamp San Francisco 2013
Saguão de entrada do WordCamp San Francisco 2013

Do primeiro dia destaco as palestras Confident Commits, Delightful Deploys do Mark Jaquith (slides) e a Writing Code as User Experience Design do Nikolay Bachiyski.

A palestra do Mark Jaquith tratou de boas práticas para todos os desenvolvedores e sysadmins que trabalham com WordPress, em especial na hora de publicar uma nova versão do código. Ele reforçou algumas coisas que já deveriam ser senso comum (e que infelizmente ainda não são), como o uso de um sistema de controle de versão. Também citou algumas ferramentas que facilitam bastante o fluxo de trabalho como o WP Stack ou o Capistrano-WP para fazer deploys, Puppet ou Chef que são ferramentas para o gerenciamento das configurações dos servidores e, por fim, o Vagrant para criar um ambiente de desenvolvimento semelhante ao servidor onde o site está publicado.

Na palestra do  Nikolay Bachiyski, ele explorou o que os desenvolvedores podem aprender da experiência de quem estuda user experience designConsiderando que um desenvolvedor passa mais de 70% do seu tempo de trabalho lendo código e não escrevendo, quando criamos código temos que nos preocupar com a experiência do usuário, que neste caso serão os outros desenvolvedores que terão contato com ele. Além de sugerir algumas boas práticas para criação de código, ele mostrou alguns vídeos da tela e cara de alguns desenvolvedores enquanto estes criavam uma página usando a Settings API do WP.

Já do segundo dia destaco as palestras Three Security Issues You Thought You’d Fixed do Mike Adams e a Magical WordPress Management using WP-CLI do Mike Schroder (slides).

No último dia teve ainda o State of the Word 2013 do Matt Mullenweg. Nele o fundador do WordPress falou do crescimento do software que agora representa 18,9% de todo o conteúdo da web (ano passado era 16,7%), do uso crescente a partir de plataformas móveis e de um novo modelo de desenvolvimento para o core. A ideia é implementar ciclos mais curtos de release com o lançamento das versões 3.7 e 3.8 ainda esse ano e organizar os desenvolvedores do core em pequenos times que trabalhem em plugins. Quando um plugin estiver pronto ele é incorporado ao código principal. Este novo modelo já está sendo testado com o desenvolvimento da nova interface para o admin.

No Contributor Day trabalhei na automatização dos testes unitários do core do WordPress utilizando o Travis CI junto com o Bryan Petty e com a ajuda do Nikolai Bachiyski. Criamos um fork do repositório do WordPress no github e nele configuramos o serviço de integração continua que pode ser visto neste link. Nas próximas semanas o Andrew Nacin deve integrar o que fizemos no repositório do WordPress.

Contributor Day no novo escritório da Automattic
Contributor Day no novo escritório da Automattic

O arquivo de configuração que criamos para o Travis CI pode ser visto neste link. Ele roda os testes do WP usando PHP 5.2, 5.3 e 5.4 e para cada uma dessas versões com o modo multisite habilitado ou desabilitado. Por enquanto, o Travis só é chamado quando há um commit no core e não quando há um commit no repositório de testes. O próprio Nacin disse que a intenção é juntar os dois num único repositório.

Uma vez com a integração dos testes do WordPress com o Travis CI funcionando partimos para resolver os testes que estavam falhando. Conseguimos resolver cerca de dez testes, não deu tempo de resolver apenas um que foi resolvido uns dias depois. Após o WordCamp descobrimos mais três testes que falham quando executados com o PHP 5.2. Estes ainda estão pendentes e podem ser vistos na página do repositório no Travis CI.

Plugin do WordPress para usar o OpenID Delegation

No final do ano passado publiquei um plugin para WordPress que permite utilizar a URL de um blog rodando o WP como uma identidade OpenID.

Para usar o OpenID Delegation é necessário ter uma identidade OpenID em algum serviço como o myopenid.com.

Com este plugin ao invés de usar como identidade OpenID a URL fornecida pelo provider, é possível usar a URL do WordPress. No meu caso uso como identidade OpenID https://rodrigo.utopia.org.br ao invés de http://rodrigoprimo.myopenid.com/.

Para mais informações vejam a página do plugin: http://wordpress.org/extend/plugins/wordpress-openid-delegation/

Para quem estiver procurando um provider e/ou consumer OpenID vejam o plugin WordPress OpenID.

 

Como manipular metadados de fotos no Linux com o exiv2

Atualização 21/06/2011: o Xavi comentou abaixo que o Shotwell tem uma opção para editar os metadados em lote. Fica a dica para quem prefere a interface gráfica. Para mais informações http://yorba.org/shotwell/help/edit-time-date.html

Algumas vezes quando viajo mais de uma pessoa leva câmera fotográfica. Quando volto, gosto de juntar todas essas fotos em um único diretório e renomear elas de acordo com a data de criação para poder vem as fotos em ordem independente da câmera. Para fazer isso uso a ferramenta para renomear em lote do software digiKam. Para fazer isso, usava o digiKam mas não encontrei essa opção na nova versão que vem com o Ubuntu 9.10. Utilizei então o Krename.

Porém, algumas vezes a data e o horário de uma das câmeras não está certo e, por tanto, o metadado referente a data de criação das fotos está errado. Para poder renomear as fotos levando em conta a data de criação é necessário então primeiro corrigir o metadado. Para isso utilizo o exiv2, uma ferramenta de linha de comando para linux para editar metadados de fotos.

Para instalar o exiv2 no Ubuntu basta rodar o seguinte comando:

sudo aptitude install exiv2

Para ver os metadados de uma foto basta passar o nome do arquivo como primeiro parâmetro para o software (onde foto.jpg deve ser trocado pelo nome do arquivo):

exiv2 foto.jpg

Também é possível inserir, deletar, modificar ou renomear metadados. Informações sobre como utilizar esses recursos podem ser obtidas na man page do programa:

man exiv2

Existe ainda o recurso de ajustar a data e horário de criação de uma ou mais fotos passando um número de horas, ou dias, ou meses (etc). Com isso basta descobrir em quanto a data da câmera que tirou as fotos estava errada (comparando por exemplo os metadados de duas fotos tiradas com câmeras diferentes mais ou menos no mesmo horário) e utilizar o recurso de ajustar data e horário do exiv2.

A opção para ajustar é a ad e ela depende de pelo menos mais um parâmetro que pode ser (tradução livre da man page):

  • -a tempo – Ajustar tempo no formato [-]HH[:MM[:SS]]. Essa opção só pode ser usada com a ação de ajustar (ad). Exemplos: 1 adiciona uma hora, 1:01 adiciona uma hora e um minuto, -0:00:30 subtrai trinta segundos.
  • -Y anos – Ajuste de tempo com base num número positivo ou negativo de anos.
  • -O meses – Ajuste de tempo com base num número positivo ou negativo de meses.
  • -D dias – Ajuste de tempo com base num número positivo ou negativo de dias.

Por exemplo, para arrumar em uma hora e meia o horário de todas as fotos da extensão JPG que estão em um determinado diretório:

exiv2 ad -a 1:30 *.jpg

Ou então para subtrair duas horas, quarenta minutos, quinze dias e dois meses:

exiv2 ad -a -2:40 -D 15 -O 2 *.jpg

Ps: alguém conhece alguma interface gráfica para Linux que permite fazer esse tipo de manipulação de fotos?

Dois vídeos e fotos do TikiFest em Barcelona

No começo de agosto estive em Barcelona para mais um encontro da comunidade do Tikiwiki, o TikiFest Barcelona (http://tikiwiki.org/TikiFestBarcelona). Enquanto eu trabalhava no meu projeto para o Google Summer of Code, o restante do pessoal estava lá para desenvolver um novo recurso para o Tikiwiki: workspaces.

O Luci publicou muitas fotos do encontro quase todas com legendas engraçadas nesse link aqui http://picasaweb.google.com/mindbro/TikiFestBarcelona2009

Além das fotos, foram feitos dois vídeos do encontro. O primeiro foi feito pela Vladislava, mulher do Luci, ela é Tcheca e trabalha para uma televisão chinesa independente (é uma televisão chinesa proibida na China). É um vídeo com um carater mais institucional, de divulgação do Tikiwiki, com entrevistas com alguns dos membros da comunidade (mais informações sobre a matéria http://english.ntdtv.com/ntdtv_en/ns_europe/2009-08-13/093675925612.html).

O segundo vídeo foi feito pelo Xavier, ele é de Barcelona e foi quem organizou toda a logística do encontro. O vídeo dele é mais longo e mostra um pouco mais da dinâmica do encontro.

[flv]http://media.ntdtv.com/ebrief/news/20090813-wn-15-tikifest in barcelona.flv[/flv]

[blip.tv ?posts_id=2588156&dest=-1]

GSOC TikiFest in London

In the first week of July I was in London for the GSOC (Google Summer of Code) TikiFest. TikiFests are a tradition in the Tikiwiki community. It is when two or more Tiki contributors get together to code, discuss about free software etc.

This time the main reason for the TikiFest was to gather together all the students from GSOC who are working in the Tikiwiki projects. This is the first year Tikiwiki is participating in GSOC and there are four students involved, including myself.

dsc01365-copy

Two students from Spain, Aldo and Ben, are working together to create the new workspaces feature (the ability to have collections of items/objects that allow different set of users to have different kinds of access in a single Tikiwiki installation). For more information on their project see the wiki page http://dev.tikiwiki.org/workspaces. At the TikiFest they presented their work done until that moment and we discussed some tricky aspects of the implementation. The development of the workspaces is of great interest for the Tikiwiki community and there are more people working on it at present besides the two GSOC students. On the first week of August there will be another TikiFest in Barcelona just to discuss and develop some parts of the workspaces.

Another student from India, Nagendra, was there to present his project which will allow online video edition in Tikiwiki using the Kaltura API. Maybe in the future we will be able to edit video the wiki way using this.

dsc01357-copy

And finally I presented my project to create a migration script from Mediawiki to Tikiwiki. As my mentor on this project, Nelson Ko, was at the TikiFest I had a great opportunity to make some crucial decisions for the project. Mainly to leave phpBB for another project and focus only on the migration from Mediawiki to Tikiwiki.

Beside the presentation of the projects, we also discussed some interesting aspects of the free software world. Aldo and Amette showed some of the great features Git has over SVN and we discussed how the Tikiwiki community could benifit from moving to Git (for example merging branches is much easier with Git). It was agreed that as an expemeriment the workspaces development would be done using Git.

dsc01360-copy

Jonny talked about the recent development of the Tikiwiki profiles and Jean-Marc showed some inconsistencies between the administration page of different Tikiwiki features and we discussed possible interface standards for those pages.

Olaf-Michael brought the discussion about Tiki as an open translation tool. He told us about http://translatewiki.com/, a place to centralize and make the translation of different open source wiki softwares as easy as possible. They are interested in putting Tikiwiki in the pool of softwares they translate and Olaf is in contact with them to make this happen. Although the way Tikiwiki handles with translations at present (a PHP array for each language with key/value pairs) is accepted by TranslateWiki I mentioned at the TikiFest that it would be a good idea for the Tikiwiki community to switch to a standard open source tool for translation like gettext.

dsc01358-copy

At present it is hard for a non-technical person to start helping with Tikiwiki translation. As I host several sites using Tikiwiki for different Brazilian social movements I am very interested in making it easier to translate. I think that using a standard tool for that purpose is a great first step. We can take advantage of all the tools built around gettext that already exist. I plan to look at this question in the next weeks, so if anyone else is also interested please do let me know. Apparently it is not that hard to convert to gettext. PHP has gettext built-in support and there is already a script to convert from Tikiwiki language.php files to gettext. Before moving, as mentioned by Jean-Marc, it is a good idea to talk with people from other projects that already use gettext to learn from their experience.

On the last day of the meeting, Aldo, Ben and I (unfortunately Nagendra had to leave the day before) talked about the difficulties we had with Tikiwiki when we started our projects. We agreed that the lack of technical documentation and tests were the two most difficult aspects.

Without technical documentation we had to read the code to understand what a function does and without tests it is much harder to know if the change you are making will break something elsewhere in the code. With this in mind we are using in our projects phpDocumentor and PHPUnit. By using phpDocumentor we can have some day, as proposed by Aldo in the devel list, api.tikiwiki.org. Very similar to http://api.joomla.org/ or http://api.cakephp.org/. Which can help to atract more contributors. PHPUnit is already used in a few parts of Tikiwiki. Louis-Phillipe created on trunk the directory lib/core. All the code there have tests. Alain Desilets and Marta Stojanovic are using PHPUnit with Selenium to write acceptance tests for Tikiwiki.

dsc013611

This is what I remember from the discussions we had during the five days of GSOC TikiFest. If I forgot to mention something please leave a comment.

How to run phpt tests with PHPUnit

In this post I will explain how to run phpt tests with PHPUnit.

For my GSOC project I will use (and contribute to) the PEAR package Text_Wiki (more about my contributions on this package on another post). This package use phpt tests for unit testing. I’m not familiar with phpt tests as I’m with PHPUnit and phpt tests didn’t give me a good impression (its difficult to understand feedback and its syntax mixing PHP code and plain text statements lead to improper syntax highlighting in Emacs :-D).

So I proposed the main developer of Text_Wiki to switch to PHPUnit. He had no objections if I were able to provide a solution that made possible to run the old phpt tests with the new PHPUnit tests at the same time.

I found that there is a PHPUnit extension that does exactly what I was looking for. As I wasn’t able to find a tutorial explaining how to use it, I decided to write this post to share the way I used that extension.

I’m using version 3.3.17 of PHPUnit and it came with two phpt related extensions located in the directory PHPUnit/Extensions (if you use Ubuntu as I do the full path will probably be /usr/share/php/PHPUnit/Extensions): PhptTestCase.php and PhptTestSuite.php

The first one implements the class PHPUnit_Extensions_PhptTestCase. The constructor of this class receive as a parameter the path to a single phpt file. I did not use this one.

The other file implements the class PHPUnit_Extensions_PhptTestSuite. You can instantiate this class in your test script passing as the first parameter the root directory where your phpt files are located. The constructor of the class will recursively look for all files with the extension .phpt.

On the link below you can view the code I used to integrate the old Text_Wiki phpt tests with the new PHPUnit classes I’m writing:

http://cvs.php.net/viewvc.cgi/pear/Text_Wiki/tests/tests.php?revision=1.2&view=markup

First day of GSOC 2009

English version below

Há algumas semanas atrás saiu a lista de projetos aprovados para o GSOC 2009 (Google Summer of Code) e meu projeto de implementar um importador de MediaWiki e phpBB para Tikiwiki foi aceito.

Hoje foi o primeiro dia de trabalho, entrei em contato com o Nelson Ko (o mentor do meu projeto) e definimos alguns objetivos para essa primeira semana. Vou pesquisar alguns importadores feitos anteriormente pela comunidade do Tikiwiki e que nunca foram finalizados bem como outros scripts para importar o MediaWiki para outros softwares. Além disso pretendo dar uma olhada na documentação da sintaxe do MediaWiki (a idéia é começar por esse software e deixar o phpBB para uma segunda fase).

Para o fim da semana pretendo ter uma avaliação das implentações existentes para ter uma idéia do caminho que o software que vou criar vai seguir. E também ter uma tabela comparativa entre a sintaxe do MediaWiki e do Tikiwiki indicando quais sintaxes serão fáceis de suportar, quais serão difíceis e quais não serão suportadas.

Pretendo publicar de vez em quando algumas atualizações aqui no blog sobre esse projeto, quem quiser acompanhá-lo de perto pode monitar a página wiki usada para documentação.


A few weeks ago Google released the list of approved projects to GSOC 2009 (Google Summer of Code) and my project (a script to import MediaWiki or phpBB content to Tikiwiki) was accepted.

Today was my first GSOC working day. I talked with Nelson Ko (my mentor for this project) through Skype (he lives in Canada and I in Brazil) and we decided the goals for this first week. I’ll research some old importers made by the Tikiwiki community and some scripts to import MediaWiki content to other software. I am also going to read the syntax documentation of MediaWiki (the plan is to start with MediaWiki and leave phpBB to a second stage).

By the end of the week I intend to perform an evaluation of the old scripts to start planning my implementation and I will produce a comparative table of TikiWiki and MediaWiki syntax to define what is simple to import, what is difficult and what is not going to be imported.

Occasionally I plan to update this blog with news about the GSOC. If you are interested in the project I suggest that you monitor the wiki page used to document my progress.

Como impedir que o editor do WordPress (TinyMCE) remova quebras de linha

Atualização (21/12/2010): Não utilizo mais o TinyMCE Advanced pois simplesmente mudando para o modo de edição HTML e apertando enter consigo gerar uma quebra de linha. Não sei se isso já existia no WordPress antes e eu nunca reparei ou se é algo de alguma versão recente.

Atualização (15/10/2009): o Rafael Biriba deixou um comentário falando do PS Disable Auto Formatting, um outro plugin do WordPress que também server para impedir a remoção automática das tags “br” e “p”.

Mais de uma vez quis formatar o texto de um post do WordPress usando algumas quebras de linha (enter) para separar dois blocos de texto ou então um bloco de texto de uma imagem. Porém, por padrão o editor do WordPress, o TinyMCE, remove qualquer tag “br” ou “p” que ele considere que esteja “sobrando”.

Talvez exista uma forma mais inteligente de se fazer isso sem usar quebra de linha, porém eu desconheço e já perdi um bom tempo tentando enganar o editor.

Ontem, encontrei o TinyMCE Advanced um plugin que tem uma opção para que as tags “br ”

e “p” não sejam removidas e além disso permite customizar os itens que aparecem na barra de edição. Abaixo um screenshot de parte da tela de administração:

Parte da tela de administração do TinyMCE Advanced