1. Pelican

    É isso aí, wordpress é legal, tem um painel administrativo e tudo mais, mas está na hora de ser um dos caras legais, resolvi trocar o wordpress por um gerador de sites estático, e entre vários, escolhi o Pelican.

    Pra mim, a grande vantagem é o tempo de carregamento, sem a necessidade de processamento e acesso ao banco, o blog ficou bem mais rápido.

    A grande maioria dos meus posts aqui acabaram sendo sobre o próprio blog, técnicas mirabolantes para manter o wordpress atualizado e plugins bizarros para conseguir postar usando o vim (bizarro mas legal).

    Queria um tema simples, o mais minimalista possível, principalmente porque não sou muito bom na parte de design. Então montei o layout usando o Toast, um framework CSS bem simples, que o próprio autor considera como apenas framework para facilitar a criação de wireframes, mas que eu gostei muito da simplicidade, sem a necessidade de colocar algo enorme como um bootstrap (o código do Toast tem apenas algumas regras bem simples.).

    Para atingir essa simplicidade o mesmo não funciona no IE7, mas tudo bem, não espero que ninguém acessando isso daqui esteja usando ele.

    Considerei em colocar os comentários do Google Plus, gosto do modo como eles se misturam com as postagens na rede social (de forma muito melhor do que a do facebook, por exemplo), mas por padrão o widget do Google não é responsivo, além de ser necessário ter conta para comentar.

    E como o Pelican já tinha tudo pronto para uso do Disqus, resolvi utilizá-lo, tinha trauma do mesmo pela lentidão que apresentava anos atrás, mas isso parece ter se resolvido.

    Outra coisa que aproveitei para fazer foi adicionar as tags semânticas do schema.org, agora os posts tem definido corretamente autor, conteúdo e data de postagem, o que já é um bom começo e que o Google já entende do que se trata na hora de indexar.

    Então é isso, não cheguei a fazer uma comparação muito exata, mas tenho certeza que o blog está por volta de 3 vezes mais rápido para carregar, e aguentando uma quantidade muito maior de visitas sem problemas, agora é fazer mais postagens, se possível sem ser apenas sobre o próprio blog.

  2. Wordpress e temas padrão

    A versão 3.8 do  wordpress está realmente diferente, o admin está com um visual novo, e o tema padrão apresenta novo segue a mesma linha flat que tem feito muito sucesso.

    Gostei tanto do tema padrão que resolvi usá-lo para esse blog, só com algumas pequenas mudanças, talvez eu “fuce” mais no decorrer do tempo, mas está bem aceitável. O suficiente para que eu cancelasse os planos de fazer algo baseado no temas roots.

    No caso, as alterações que fiz no CSS foram as seguintes:

    1
2
3
4
5
6
7
8
    .entry-title {
text-transform: none;
}

.site-content .entry-header,.site-content .entry-content,.site-content .entry-summary,.site-content .entry-meta,.page-content {
margin: 0 auto;
max-width: 674px;
}

    O primeiro para remover o estilo que deixa o título dos posts todo em maiúsculo, e o segundo para aumentar um pouco a largura do espaço de postagem.

  3. ScribeFire

    Acabei de descobrir que o ScribeFire agora também tem uma extensão para o Opera, e já estou usando-a, o que facilita bastante na hora de escrever um post, já que é possível usá-la mesmo estando sem acesso a internet e a mesma tem suporte a markdown (mesmo eu não tendo conseguido usar ainda.

    Vou tentar novamente me acostumar a usar o ScribeFire, já que ás vezses usar o editor do Wordpress fica meio complicado por causa da conexão (ou falta dela)

    O único real problema para mim é a falta do “preview”, mas para usar apenas para realmente escrever, parece uma boa opção.

  4. Desenvolvimento e Implantação do Wordpress usando Git

    Nesse post vou detalhar a estrutura de desenvolvimento e implantação do wordpress usando git que estou usando para este blog, onde consigo enviar mudanças feitas no ambiente de teste para produção usando um simples “git push prod”.

    Eu irei detalhar apenas os passos que dei para criar esse ambiente, sem me aprofundar nos conceitos do git.

    Meu objetivo é usar ao máximo as funcionalidades do git para fazer a implantação do blog, para isso, vou usar um repositório do wordpress mantido no github, originalmente o código do wordpress é mantido em um repositório svn, mas felizmente exite um clone no github, que é atualizado de 30 em 30 minutos.

    Clonando o repositório do wordpress, selecionando a versão que será usada e criando um branch de desenvolvimento a partir dela:

    1
2
3
    git clone https://github.com/markjaquith/WordPress.git blog.daniloshiga.com
git checkout origin/3.3-branch
git checkout -b dev

    Adicionando o tema “roots” como um “submódulo falso” (ou seja, sem o uso dos “submodules”) do git.

    1
2
3
    cd wp-content/themes
git clone https://github.com/retlehs/roots.git
git add roots/

    Fiz desse modo para facilitar a implantação, de modo que tanto o wordpress quanto o tema fiquem no mesmo repositório, sem haver a necessidade de executar comandos para ativação e uso dos submódulos.

    quando ativado, o tema roots gera um .htacess na base da instalação do wordpress, talvez seja interessante adicionar o .htaccess no .gitignore para evitar sobrepor o arquivo que será gerado na ativação do tema em produção com o usado durante o desenvolvimento.

    É necessário criar um repositório onde será feita a implantação, o uso do comando “git init —bare” faz com que o repositório seja criado na pasta atual, e não criada uma outra pasta .git com ele.

    1
2
    mkdir blog.git && cd blog.git
git init --bare

    O ponto central da implantação será o uso de um “hook”, no caso o post-receive, que é um script que irá executar quando novos dados forem recebidos no repositório.

    o script é o blog.git/hooks/post-receive

    1
2
3
4
5
6
7
8
    #!/bin/sh
LIVE="[caminho para pasta do wordpress em produção]"
read oldrev newrev refname
 if [ $refname = "refs/heads/dev" ]; then
 echo "===== DEPLOYING TO LIVE SITE ====="
 GIT_WORK_TREE=$LIVE git checkout -f dev
 echo "===== DONE ====="
 fi

    Detalhando: ele limita o envio de dados para produção para apenas quando for um push do branch “dev” dando um checkout no repositório na pasta de produção, a vantagem de executar um checkout assim é que o repositório em si não fica nessa pasta, não sendo necessário adicionar alguma regra no servidor para bloquear o acesso ao repositório.

    Feito isso, basta adicionar o repositório

    1
2
    git remote add prod ssh://[usuario]@[host]/[caminho_repositório]/blog.git
git push prod +dev:refs/heads/dev

    Para a implantação, farei uso do post-receive hook, ou seja, irei permitir que, ao executar o git push para um repositório remoto (mantido no servidor de produção) os arquivos sejam colocados na pasta pública utilizando um checkout.

    Vantagens dessa técnica:

    Facilidade na implantação de novidades, e também na reversão das mudanças caso necessário.

    A pasta .git não fica na pasta pública, não sendo necessário assim retirar o acesso a ela através do .htaccess.

    O uso do submódulo falso simplifica a implantação, evitando a necessidade de usar os comandos “git submodule init” e “git submodule update” para conseguir obter os submódulos, adicionando-os diretamente dentro do repositório faz com que um único checkout já os traga também.

    Desvantagens:

    As alterações que forem realizadas em desenvolvimento relacionadas a ativação e configuração de temas e plugins vão precisar ser reaplicadas no servidor de produção, já que cada ambiente está usando um banco separado, tornando o controle das alterações complicado nesse sentido.

    Referências:

    Parte da solução, só que usa git pull

    Solução usando checkout

    Speed Up Your WordPress Development Cycle With Git

    Git Fake Submodules

Página 1 / 1