Arquivo da tag: cms

Como criar um aviso de dados não salvos

Sabe quando você está escrevendo um e-mail e tenta sair de tela, o browser te da um aviso, comunicando a possível perda de dados? Pois é sobre isso que vamos falar. O Gmail e o Rally fazem isso, mas muita gente ainda não sabe como isso é feito de fato.

Este recurso é muito interessante e pode evitar muita dor de cabeça por parte da pessoa que estiver utilizando o seu sistema. No meu caso, este recurso foi aplicado a um CMS. A finalidade da implantação era para que os jornalistas fossem avisados quando algum dado no formulário fosse alterado, e que se o usuário intencionalmente (ou não) tentasse mudar de página, o dado seria perdido. Se tratando de um CMS focado para jornalistas, no qual o conteúdo digitado é extremamente importante, todos recurso que for desenvolvido para evitar perda de conteúdo é extremamente bem-vindo.

onBeforeUnload Event

O evento onbeforeunload não tem uma finalidade exclusiva para ele. É um evento como outro qualquer, que é invocado sempre que o usuário tenta sair da página atual, mas quando ele não está setado, simplesmente nada acontece. O evento responsável por pedir para que o usuário confirme ou não a mudança de pagina é o evento onbeforeunload. Sempre que ele é setado, você vai ver um confirm dialog, igual o da imagem abaixo.

O problema

Se fosse só setar o efeito e ele fizesse todo o resto, seria fácil, não? Mas não é assim. Temos que fazer um script que peça a intervenção do usuário nas seguinte situações:

Ao fechar aba/navegador;

Ao clicar em qualquer outro link, senão o submit do formulário;

O alerta deve aparecer somente se algo for alterado no formulário.

A Solução

$(function(){
  var formObject = $('.new_materia, .edit_materia');
  formObject.data('original_serialized_form', formObject.serialize());

  $(':submit').click(function() {
    window.onbeforeunload = null;
  });

  window.onbeforeunload = function() {
    if (formObject.data('original_serialized_form') !== formObject.serialize()) {
      return "As mudanças deste formulário não foram salvas. Saindo desta página, todas as mudanças serão perdidas.";
    }
  };
});

Como funciona?

Utilizei o $.data() do jQuery porque eu não gosto do var para declarar variáveis globais;

Utilizei o $.serialize() do jQuery para serializar o formulário para comparar o estado do formulário no futuro. E foi a forma mais inteligente que encontrei para identificar se algo realmente foi mudado;

Por default, eu seto o evento onbeforeunload e dentro dele eu verifico se algo foi mudado no formulário;

O único caso em que eu tenho que remover o evento onbeforeunload é quando existe a intenção de salvar o dado. Aí eu utilizei o :submit com evento $.click() para remover o evento e cancelar o alerta, caso houvesse a intenção de salvar o formulário.

Bom, é isso!

Versão 2.5.4 do Joomla! é liberada

Fonte: IMasters

O projeto Joomla liberou esta semana a versão 2.5.4 do CMS, que é um release de segurança. O processo de atualização é bem simples, e instruções completas estão disponíveis neste link.

A versão traz correção para 157 problemas no gerenciador de acidentes e três novas funcionalidades: adição da opção de mostrar o número da versão no gerador de tag; implementação de níveis de acesso para Content Languages; e tornar o processo de autoatualização mais confiável entre hosts diferentes.

Detalhes sobre a nova versão podem ser encontrados no anúncio oficial de lançamento, e o download pode ser feito a partir do site do projeto.

Gerenciando seu ambiente com o RVM

Fonte: Uriel Juliatti/IMaster

Alguém de vocês possui apenas um projeto com Ruby? É impossível ter apenas um! Sabemos que cada projeto usa diversas gems, mas como gerenciar isso? Você já deve ter se perguntado: “como faço para organizar um projeto com Rails 3.1 e um outro com Rails 3.0?” ou “e se em um projeto eu quiser utilizar a gem devise 1.x.x e em outro o 2.x.x?”.

Pois bem, o RVM está aí e veio para faciliatr a sua vida!

O que é o RVM?

A sigla significa Ruby Version Manager, que para nós – resumidamente – seria algo como um “gerenciador de versões” para o Ruby. Ele criar ambientes isolados para desenvolver em Ruby, dando condições para usar várias versões de ruby e gems em uma mesma máquina de forma clara e sem conflitos.

Instalando o RVM

Para instalar o RVM, recomendo que você possua um ambiente UNIX e tenha o Git instalado – ele será usado tanto para instalar e atualizar o RVM, quanto para o Ruby.

Abra o seu terminal e digite:

$bash -s stable <<(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
# Existe uma exceção para quem utiliza o Lion OS, recomendo essa leitura: http://www.frederico-araujo.com/2011/07/30/installing-rails-on-os-x-lion-with-homebrew-rvm-and-mysql/.

Logo após a instalação, abra o seu .bash_profile ou .bashrc e acrescente esse comando:

echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile
source ~/.bash_profile
S1=”\$(~/.rvm/bin/rvm-prompt) $PS1

Esta segunda linha é para recarregar o seu bash com o RVM e a terceira é para que a versão do ruby que você está utilizando apareça no prompt.

Reinicie o seu console e digite “rvm”, pois a esta altura ele já deve estar funcionando regularmente

Instalando versões do Ruby

Com o uso do RVM, é possível instalar qualquer implementação Ruby. Com ele é possível instalar o próprio Ruby, o Ruby Enterprise e o Jruby. Para isso, vamos testar o RVM instalando o 1.9.2-p136. Faça isso no terminal e vá tomar um café, pois é provável que demore um pouco:

$ rvm install 1.9.2-p136

Você pode setar essa versão do Ruby como padrão do RVM dessa forma:

$ rvm --default 1.9.2-p136

E caso deseje voltar para a versão instalada no seu sistema (o Mac OSx costuma vir com a 1.8.7 já instalada), utilize o comando:

$ rvm use system

E para listar os rubies instalados, digite:

$ rvm list

# => ruby-1.9.2-p136 [ x86_64 ]

# ruby-1.9.2-p290 [ x86_64 ]
# ruby-1.9.3-preview1 [ x86_64 ]

Agora você está com a versão 1.9.2-p136 instalada e pronta para receber gems.

Instalando Gems

Digite no seu terminal o comando “gem list” e perceba que suas gems “desapareceram”. Não se assuste, é exatamente o que deveria acontecer, pois cada rubie tem seu ambiente totalmente separado.

Para ver todas as informações do seu rubie, digite “rvm info” e obterá algo do tipo:

$ rvm info

ruby-1.9.2-p136@adena:

system:
uname: "Darwin Uriel-MacbookPro.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64"
bash: "/bin/bash => GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin11)"
zsh: "/bin/zsh => zsh 4.3.11 (i386-apple-darwin11.0)"

rvm:
version: "rvm 1.8.3 by Wayne E. Seguin (wayneeseguin@gmail.com) [https://rvm.beginrescueend.com/]"

ruby:
interpreter: "ruby"
version: "1.9.2p136"
date: "2010-12-25"
platform: "x86_64-darwin11.1.0"
patchlevel: "2010-12-25 revision 30365"
full_version: "ruby 1.9.2p136 (2010-12-25 revision 30365) [x86_64-darwin11.1.0]"

homes:
gem: "/Users/uriel/.rvm/gems/ruby-1.9.2-p136@adena"
ruby: "/Users/uriel/.rvm/rubies/ruby-1.9.2-p136"

binaries:
ruby: "/Users/uriel/.rvm/rubies/ruby-1.9.2-p136/bin/ruby"
irb: "/Users/uriel/.rvm/rubies/ruby-1.9.2-p136/bin/irb"
gem: "/Users/uriel/.rvm/rubies/ruby-1.9.2-p136/bin/gem"
rake: "/Users/uriel/.rvm/gems/ruby-1.9.2-p136@adena/bin/rake"

environment:
PATH: "/Users/uriel/.rvm/gems/ruby-1.9.2-p136@adena/bin:/Users/uriel/.rvm/gems/ruby-1.9.2-p136@global/bin:/Users/uriel/.rvm/rubies/ruby-1.9.2-p136/bin:/Users/uriel/.rvm/bin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:/usr/local/bin:/usr/local/sbin:/opt/python/bin:/Users/uriel/lib/go/bin:/opt/android-sdk/tools:/opt/android-sdk/platform-tools:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/usr/local/git/bin"
GEM_HOME: "/Users/uriel/.rvm/gems/ruby-1.9.2-p136@adena"
GEM_PATH: "/Users/uriel/.rvm/gems/ruby-1.9.2-p136@adena:/Users/uriel/.rvm/gems/ruby-1.9.2-p136@global"
MY_RUBY_HOME: "/Users/uriel/.rvm/rubies/ruby-1.9.2-p136"
IRBRC: "/Users/uriel/.rvm/rubies/ruby-1.9.2-p136/.irbrc"
RUBYOPT: ""
gemset: "adena"

Este comando é muito importante e passa todas as informações sobre o ambiente da versão do seu Ruby: onde está instalado, se possui Gemset – e onde ele se encontra, onde as gems estão instaladas etc.

Vamos instalar a gem do Ruby on Rails nesse ambiente? Então utilize o comando:

$ gem install rails -v=3.1 --no-ri --no-rdoc

# Não utilize sudo! É considerado uma má prática, você já possui o RVM para gerenciar seus rubies, esqueça o sudo

Faça um teste após a instalação: liste as gems desse rubie e depois liste as gems instaladas de um outro ruby – pode ser a do próprio sistema. Você verá a diferença.

Gemsets

Essa é a parte mais interessante ao utilizar essas ferramentas. Vamos supor que eu esteja utilizando a versão 1.9.2-p136 para vários projetos, mas queira separar as gems de cada um: as Gemsets caem como luva. Talvez você não veja muita utilidade agora, mas eu as uso a todo momento. Na Giran utilizo um gemset específico para a plataforma Adena (logo, gemset @adena) e o mesmo rubie para meu outro projeto de CMS (logo, @zephyr), é assim que faço para utilizar a mesma rubie (1.9.2-p136) sem misturar as gems de cada projeto. Isso evita conflitos e logo você perceberá o quão é crucial. Além disso, você pode utilizar uma gemset como se fosse um sandbox, isto é, testar gems em uma mesma rubie. Vamos supor que eu quero testar uma versão específica do Rails (a mais atual, 3.2) nessa mesma rubie citada, por exemplo.

Na prática

Vamos lá, vamos criar uma gemset para um projeto específico: Um CMS.

$ rvm gemset create cms && rvm gemset use cms

Além de criar, você ainda setou essa gemset como padrão a ser utilizada. Fique à vontade para começar seu projeto de CMS com as gems que quiser – existe uma infinidade de gems para você brincar.

Para finalizar, vou dar duas dicas importantes: O uso da gemset global e como setar um arquivo .rvmrc em um projeto Rails.

  • Gemset global

E se você quiser que todos os seus projetos de uma rubie utilizem uma gem específica, como o rake, por exemplo? Você iria instalar em cada gemset o rake? E se você quiser que todos os seus projetos web sigam a evolução do rails?!

Bom, a solução é utilizar uma gemset global, que é responsável por compartilhar gems entre todas as gemsets de uma rubie. Caso precise de fazer isso utilize assim:

$ rvm gemset use global

$ rvm install rake --no-ri --no-rdoc

Arquivo .rvmrc

Se você é railer e usa RVM essa dica é essencial! Os arquivos .rvmrc são indispensáveis para realizar um “setup” do ambiente uma vez que você esteja na pasta de um projeto. Digamos que você tenha baixado um projeto ruby de um amigo em seu repositório online, se o projeto dele possuir esse .rvmrc é muito capaz que ele já prepare todo o ambiente em sua máquina a partir do momento em que você acessar o diretório do projeto.

Espero que você esteja com sua gemset do CMS criada; então como criamos esse arquivo .rvmrc?

$ rvm use 1.9.2-p136@cms --rvmrc --create

Provavelmente ele criará um arquivo .rvmrc com essas linhas:

#!/usr/bin/env bash

# This is an RVM Project .rvmrc file, used to automatically load the ruby
# development environment upon cd'ing into the directory

# First we specify our desired <ruby>[@<gemset>], the @gemset name is optional.
environment_id="ruby-1.9.2-p136@cms"

#
# Uncomment following line if you want options to be set only for given project.
#
# PROJECT_JRUBY_OPTS=( --1.9 )

#
# First we attempt to load the desired environment directly from the environment
# file. This is very fast and efficient compared to running through the entire
# CLI and selector. If you want feedback on which environment was used then
# insert the word 'use' after --create as this triggers verbose mode.
#
if [[ -d "${rvm_path:-$HOME/.rvm}/environments" \
&& -s "${rvm_path:-$HOME/.rvm}/environments/$environment_id" ]]
then
\. "${rvm_path:-$HOME/.rvm}/environments/$environment_id"

if [[ -s "${rvm_path:-$HOME/.rvm}/hooks/after_use" ]]
then
. "${rvm_path:-$HOME/.rvm}/hooks/after_use"
fi
else
# If the environment file has not yet been created, use the RVM CLI to select.
if ! rvm --create use "$environment_id"
then
echo "Failed to create RVM environment '${environment_id}'."
exit 1
fi
fi

#
# If you use an RVM gemset file to install a list of gems (*.gems), you can have
# it be automatically loaded. Uncomment the following and adjust the filename if
# necessary.
#
# filename=".gems"
# if [[ -s "$filename" ]]
# then
# rvm gemset import "$filename" | grep -v already | grep -v listed | grep -v complete | sed '/^$/d'
# fi

# If you use bundler, this might be useful to you:
# if command -v bundle && [[ -s Gemfile ]]
# then
# bundle install
# fi

p.s.: Reparem nas últimas linhas. Você pode instruir o seu arquivo .rvmrc a rodar um bundle install – caso o usuário já tenha a gem bundler instalada – e instalar todas as gems do Gemfile do projeto Rails. Interessante, não?

Pronto, você agora já pode ficar tranquilo. Se alguém der um git clone em seu projeto e após baixado ele acessar a pasta do projeto, o .rvmrc será responsável por criar a gemset para o rubie (tal como @cms).

Obs.: A única parte que arbitrariamente o .rvmrc vai cobrar algo ou possivelmente dará um erro é se o usuário não tiver uma rubie 1.9.2-p136. Porém, uma vez com a rubie instalada, o usuário terá a gemset criada (@cms) a partir do momento que estiver no diretório do projeto clonado.

Enfim, essa foi uma cobertura um pouco superficial do RVM. No entanto, ele possui uma documentação muito vasta. Confira os comandos e outras informações em seu site oficial.

Um abraço a todos!

O modelo de dados do Joomla

Olá pessoal. Neste artigo vou apresentar mais uma análise do modelo de dados utilizado em um CMS (Content Management System). Desta vez apresentarei o modelo de dados do Joomla, um dos CMSs mais populares.

Há algum tempo atrás escrevi um artigo sobre o modelo de dados do WordPress aqui no iMasters. Desta vez vou analisar e comentar o modelo de dados do Joomla, outro CMS que está se tornando muito popular aqui no Brasil não apenas para a construção de blogs, mas também para a criação de web sites inteiros e complexos.

Assim como o WordPress, o Joomla pode ser utilizado basicamente de duas formas:

Através da contratação e utilização de um hosting especializado que hospedará o site;

Através do download e instalação do Joomla disponível no site oficial do Joomla. Há também uma forte comunidade de usuários brasileiros representados no site oficial do Joomla no Brasil.

A utilização do Joomla através da contratação de um hosting vai depender das configurações que o serviço de hospedagem fornece.

É comum encontrar painéis de controle e outras interfaces que facilitam tanto a administração como a criação de conteúdo. Contudo, nestas situações geralmente o ambiente está montado e não é preciso interagir diretamente com o banco de dados.

Já a segunda forma de utilização envolve o download, instalação e configuração do Joomla. Neste contexto é preciso conhecimento técnico da instalação do Joomla e suas dependências, como o servidor de banco de dados MySQL, o PHP e o servidor Web escolhido.

Este artigo se concentra nos detalhes técnicos envolvidos no banco de dados. O público alvo deste artigo são profissionais que precisam lidar com instalação, configuração e manutenção do Joomla e não para quem apenas o usa para gerenciar conteúdo.

É razoável admitir que a maioria dos usuários não precise conhecer o modelo de dados devido à facilidade do uso de painéis administrativo e outras interfaces que permitem a publicação de conteúdo neste CMS. Porém, administradores, DBAs, desenvolvedores de plug-ins e quem resolve problemas de desempenho ou integração com o Joomla devem conhecer bem seu modelo de dados.

Uma vez que já foram explicadas as duas formas de se utilizar o Joomla vamos ao modelo de dados que este CMS utiliza.

A Figura 1 apresenta o modelo de dados (isto é, as tabelas e seus tipos de dados) utilizados pelo Joomla 1.6 e modelados na ferramenta de código aberta DBDesigner disponível em diversas plataformas.

Figura 1. Modelo de dados do Joomla 1.6 no DBDesigner

Já a Figura 2 apresenta o mesmo modelo de dados da Figura 1, porém modelado utilizando a ferramenta livre de modelagem e administração chamada MySQL Workbench.

Figura 2. Modelo de dados do Joomla 1.6 no MySQL Workbench.

Os modelos da Figura 1 e da Figura 2 não foram produzidos por mim. O crédito vai para Torkil Johnse, que disponibilizou estes modelos gratuitamente no seu blog nos formatos do MySQL Workbench(MWB), PNG, PDF e SVG.

Nota: as figuras representam um modelo de dados levemente modificado em relação ao modelo original, como o próprio Torkil comenta em seu blog. As principais diferenças são a mudanças de alguns tipos de dados e a colocação de relacionamentos, uma vez que o MySQL com MyISAM não os suporta. Também destaco que o modelo da Figura 2 não apresenta nenhuma informação sobre os índices das tabelas.

Oficialmente não encontrei nenhuma página que contém informações sobre este modelo inclusive com detalhes das tabelas e suas colunas. Mas encontrei uma página apresenta um fraco dicionário de dados sem muitas informações detalhadas a respeito de certas características do modelo como, por exemplo, justificativas a respeito dos tipos de dados. Acesse a página que contém este dicionário de dados simplificado para a versão 1.5.

Assim como o WordPress, o Joomla não possui um arquivo contendo todos os comandos SQL necessários para a criação do banco de dados, ou seja, é preciso fazer uma chamada a um arquivo .php após as configurações de acesso a banco de dados no painel administrativo.

Antes de começar a análise do modelo é preciso dizer que oficialmente o Joomla só pode ser instalado no MySQL e/ou a extensão MySQLi. Isso quer dizer que se a empresa já possui outro banco de dados, como o PostgreSQL, SQL Server ou Oracle por exemplo, é preciso configurar um ambiente multi-banco, o que possui implicações para quem administra os servidores.

Existem alguns esforços da comunidade para permitir que o Joomla suporte outros bancos de dados, porém estes esforços ainda não foram integrados oficialmente ao projeto. Para mais informações sobre o suporte a outros bancos de dados no Joomla recomendo os seguintes links:


De forma similar ao que acontece no WordPress, o modelo de dados do Joomla também não contém chaves estrangeiras. O motivo pela ausência de chaves estrangeiras provavelmente é por que ele foi criado utilizando o engine MyISAM do MySQL ao invés do engine InnoDB. Aqui repito o que já havia falado quando analisei o modelo de dados do WordPress:

O MySQL apresenta a criação de chaves estrangeiras com o engine InnoDB a partir da versão 3.23.43b. O MySQL já está na versão 6, porém há o famoso problema de compatibilidade com as base legada. Provavelmente escolheu-se o MyISAM por facilidade e por motivos de desempenho, o que NÃO quer dizer que um banco de dados com o InnoDB não possa ser ajustado para ter uma desempenho aceitável.

Sem entrar em uma discussão mais profunda, em geral muitas pessoas advogam que o engine MyISAM possui melhor desempenho que o InnoDB, porém este último possui suporte a transações, integridade e outros recursos que o MyISAM não possui.

A falta de chaves estrangeiras quer dizer que o relacionamento entre algumas tabelas não é mantido pelo banco de dados e sim pela aplicação. Isso permite que hajam dados inconsistentes no banco de dados como, por exemplo, um comentário de um blog que não tem nenhum post associado.

Apesar deste cenário ser fictício e ocorrer apenas quando alguém altera os dados diretamente pelo banco de dados e não pela opção de criação de conteúdo, esta possibilidade de inconsistência pode gerar problemas, principalmente quando se fala em migração de dados e segurança.

Existem várias características e pontos do modelo do Joomla que podem ser analisados. O próprio Torkil Johnsen já apresentou diversos aspectos do modelo que ele crê que podem ser melhorados no artigo chamado The Joomla database schema smells.

Os principais pontos que ele destaca são a falta de padronização e problemas de nomenclatura, tipos de dados, normalização e falta de completude do modelo. Concordo com muitos dos pontos levantados pelo Torkil e aqui vou colocar algumas considerações minhas e, quando possível, realizar pequenas comparações com o modelo de dados do WordPress.

O modelo do Joomla possui mais de 30 tabelas divididas em grupos como publicação de conteúdo, componentes, menus, templates e outros. Essas divisões foram destacadas em retângulos com nomes na Figura 1.

Já o WordPress é mais enxuto e contém 11 tabelas. Existe uma correlação entre a quantidade de tabelas e colunas de um modelo e a sua complexidade, especialmente em aplicações simples que não estão associadas a toneladas e toneladas de requisitos e casos de uso com diferentes tipos de usuários.

Ou seja, quanto mais tabelas/colunas em um modelo de dados provavelmente ele vai ser mais complexo de ser compreendido, vai dificultar tarefas de importação/exportação e possui e tendência de introduzir complexidade desnecessária.

A principal tabela do modelo do Joomla possui o sufixo _content e é responsável pelo armazenamento de informações sobre o conteúdo (como posts em um blog). Esta tabela concentra muita informação nela mesma e possui quase 30 colunas. Obviamente, nem todas as colunas são preenchidas quando se cria um novo post e muitas destas colunas possuem valores que claramente poderiam ser mais bem aproveitados se estiverem em outra tabela.

Por exemplo, a dupla de colunas publish_up e publish_down, ambas do tipo DATETIME, armazenam a data que o post foi publicado e a data em que ele foi retirado do ar. Porém somente duas datas são armazenadas e não há como armazenar o histórico de mais de uma data de publicação e retirada do post. Esta característica se repete ao longo de diversas outras tabelas do modelo.

Outro ponto que me chamou a atenção foi a falta de tipos de dados booleanos, que armazenam valores 0/1 ou VERDADEIRO/FALSE ou TRUE/FALSE. Em muitas tabelas existem colunas que, aparentemente, poderiam se beneficiar do tipo de dados booleano como, por exemplo, a tabela _contact_details, que contém uma coluna chamada published do tipo de dados TINYINT(1).

Além disso, destaca-se também o uso em excesso de colunas com o tipo de dados TEXT, algo que permite o armazenamento de dados limitado apenas pelos recursos do servidor e não por um número fixo de caracteres.

O uso em excesso de colunas do tipo TEXT pode eventualmente se tornar um problema devido à grande quantidade de caracteres armazenados e à necessidade de backups específicos por tabelas. Sem contar que a indexação e pesquisa para este tipo de dados devem ser especiais, algo que não é tratado no Joomla diretamente.

Do ponto de vista de modelagem, em algumas situações o modelo atende a certos requisitos relativamente bem, como é o caso do gerenciamento de usuários, grupos e permissões.

Por outro lado, algumas tabelas deveriam ser implementadas como plug-ins ou extensões e não diretamente no modelo padrão, como é o caso do gerenciamento de avaliação (rating) de um post cujos dados são armazenados na entidade _content_rating.

Outro exemplo de tabelas que seriam mais bem aproveitadas em plug-ins ou extensões está relacionado com a criação de enquetes (polls) cujos dados são armazenados nas tabelas_polls, _polls_menu e _polls_data.

Outro aspecto que me chamou à atenção no modelo foram as tabelas responsáveis pelo armazenamento de informações de propaganda (_banner, _bannerclient e _bannerfinish) que provavelmente vieram como resquício do modelo do banco de dados do Mambo, projeto na qual o Joomla se originou.

Atualmente o modelo de patrocínio em sites evoluiu muito em relação aos antigos banners e creio que estas tabelas acabaram ficando no esquecimento devido à funcionalidades e requisitos de campanhas com links patrocinados e integração com programas de afiliados.

Apesar de não ser difícil compreender o modelo uma vez que se acostume a ele, em algumas situações fica estranho não contar com a nomenclatura e termos já tradicionais.

Por exemplo, em nenhuma tabela/coluna existe o termo comentário. No modelo de dados esta forma de interação do usuário com o post é chamada de mensagens. Já a tradicional forma de taxonomia apresentada por tags é representada por seções e categoria em um post. Já template é utilizado estritamente para menus e não faz referência direta à forma de customização do layout do site.

Novamente, assim como no WordPress, o modelo de dados do Joomla não possui nenhuma outra integridade de domínio ou stored procedure que faça restrição ao que é inserido no banco. Apesar disso não ser obrigatório, esta prática abre margem para problemas como SQL Injection onde um usuário malicioso pode tentar invadir o site por meio de caracteres especiais.

Além disso, a falta desta integridade pode permitir dados que invalidem a aplicação como, por exemplo, colocar o valor -2 na coluna count da tabela _categories. Há também algumas colunas de tabelas onde o valor NULL é permitido, tornando necessária uma checagem adicional na aplicação.

Enquanto alguns podem argumentar que isso é responsabilidade da aplicação não é raro encontrar bancos de dados com este tipo de integridade de domínio implementada, fornecendo assim mais uma camada de segurança e consistência de dados.

Em resumo pode-se dizer que o modelo do Joomla é robusto e atende à sua necessidade, porém é um modelo que carrega muito do projeto Mambo. O destaque vai para o foco de armazenar no banco de dados informações tanto de conteúdo como de usuários, configurações, comentários, avaliações, menus, etc.

Com certeza este modelo pode ser melhorado nos aspectos de nomenclatura, padronização, tipagem, normalização e outros. E esta melhoria é responsabilidade da comunidade de desenvolvedores e usuários do Joomla. Infelizmente, melhorias profundas no banco de dados requerem tempo conforme o projeto vai ficando cada vez mais maduro.

Apesar destas ressalvas, o Joomla é um bom CMS que pode ser utilizada para montar muitos projetos e sites interessantes. Obviamente, ele precisa evoluir e continuar a inovar no aspecto de funcionalidades, customização e usabilidade.

Sugiro aos desenvolvedores e à comunidade que procurem também aprimorar o seu modelo de dados, o que pode trazer inúmeros benefícios à ferramenta tornando-a cada vez melhor.

Um grande abraço e até a próxima.

Fonte: Mauro Pichiliani/joomlaclube

Dicas para Aumentar a Segurança do seu Blog

Todos os dias Crackers, criminosos cibernético antigamente chamados de hackers, tentam invadir computadores, redes inteiras e também sites/blogs.

Nesse artigos focarei em uma das melhores técnicas de prevenção a invasão de sites hospedados na plataforma Linux rodando em php, como é o caso de vários CMS (Sistema de Gestão de Conteúdo, sigla em inglês) como WordPress, Joomla, PhpBB, Magento, dentre outros, a técnica consiste em bloquear o acesso a determinados arquivos via .htaccess.

O .htaccess são arquivos que permitem fazer modificações no padrão do php por diretório, inclusive bloquear o acesso a determinados arquivos.

Um dos arquivos mais críticos é aquele que faz conexão com o banco de dados, pois com a posse desse arquivo o Cracker faz o que bem entender com sua base de dados.

Então mãos a massa:

Abra o arquivo .htaccess que está na raiz do seu site (pasta / public_html / htdocs , caso não encontre consulte a empresa que hospeda seu site).

Agora basta colocar as regras abaixo modificando conforme sua necessidade.

//arquivo que você vai bloquear, no caso o wp-config.php, arquivo de configuração do WordPress

<Files "wp-config.php">
//essa regra bloqueia o acesso
deny from all
</Files>

//arquivo que você vai bloquear, no caso o configuration.php, arquivo de configuração do Joomla!

<Files "configuration.php">
deny from all
</Files>

*Você pode retirar os comentários acima, que estão entre as regras. Salve envie o arquivo de volta ao servidor.

Faça um teste, acesse: http://SEUSITE.com.br/wp-config.php (caso seu site rode pelo CMS WordPress) ou

http://SEUSITE.com.br/configuration.php (caso seu site seja Joomla!). O site deve mostrar uma mensagem de erro, geralmente “Forbidden“.

Pronto!

Com essa simples modificação seu blog estará mais seguro.

Este é um guest post escrito por Marcelo Thomaz do Portal Bragança (site de notícias)

Fonte: Celso Lemes/CriarSites

O modelo de dados do WordPress

Cometário SWX: O artigo é um pouco antigo (01/03/2010), mas não deixa de ser interessante. A versão do WordPress na data desta publicação é a 3.x.

Olá, pessoal. Neste artigo vou apresentar uma análise do modelo de dados utilizado no WordPress – o CMS (Content Management System), mais popular nos dias atuais. Além de analisar o modelo de dados, vou disponibilizar scripts, imagens, e o próprio modelo de dados em outros formatos para aqueles que precisem saber como os dados são armazenados no MySQL quando se utiliza o WordPress.

O WordPress pode ser utilizado basicamente de duas formas: 1) Através do domínio wordpress.com, onde é possível criar um blog gratuitamente e sem muito conhecimento técnico de seu funcionamento interno; e 2) Através do download e da instalação do WordPress disponível no site oficial http://wordpress.org/.

Vamos nos concentrar nos detalhes técnicos envolvidos no banco de dados e nosso foco é para aqueles que têm que lidar com este tipo de trabalho, e não para quem apenas usa o WordPress para gerenciar conteúdo. É razoável admitir que a maioria dos usuários não precisa conhecer o modelo de dados devido à facilidade do uso do painel administrativo do WordPress. Porém os administradores, desenvolvedores de plug-ins e quem resolve problemas de desempenho ou integração com o WordPress devem conhecer este modelo bem.

Vejamos o modelo de dados que este CMS utiliza. A Figura 1 apresenta o modelo de dados (isto é, as tabelas e seus tipos de dados) utilizados pelo WordPress 2.9 e modelados na ferramenta de código aberta DBDesigner disponível em diversas plataformas.

Figura 1. Modelo de dados do WordPress 2.9 no DBDesigner

Oficialmente há uma página que contém informações sobre este modelo, inclusive com detalhes das tabelas e suas colunas. Porém esta página apresenta um fraco dicionário de dados sem muitas informações detalhadas a respeito de certas características do modelo como, por exemplo, justificativas a respeito dos tipos de dados. A página oficial que traz a descrição do modelo de dados do WordPress é http://codex.wordpress.org/Database_Description. Aconselho a todos que desejam conhecer mais sobre este modelo visitar esta página regularmente devido às modificações implementadas a cada nova versão do WordPress. Aliás, a figura que contém o modelo de dados desta página oficial não contém a nova tabela wp_commentmeta.

Outro detalhe importante é que durante a instalação do WordPress pode-se escolher qual será o prefixo da tabela, ou seja, o prefixo wp_ é apenas uma sugestão. Um outro detalhe interessante da instalação do WordPress é que não existe um arquivo sql contendo todos os comandos necessários para a criação do banco de dados, ou seja, é preciso fazer uma chamada a um arquivo .php após as configurações de acesso a banco de dados no painel administrativo do WordPress. Devido a isso, neste artigo vou disponibilizar alguns scripts com a estrutura e os comandos de criação do modelo do WordPress 2.9.

A Figura 2 apresenta o mesmo modelo de dados da Figura 1, porém modelado utilizando a ferramenta livre de modelagem e administração chamada MySQL Workbench.

Figura 2. Modelo de dados do WordPress 2.9 no MySQL Workbench.

Nota-se que na Figura 2 é possível observar também os índices de cada uma das tabelas. Para fazer o download dos modelos do WordPress 2.9 no DB Designer e no MySQL Workbench basta clicar aqui. O arquivo compactado também contém as imagens no formato png e svg, os scripts sql de criação gerados pelo DBDesigner e pelo comando dump do MySQL, além de arquivos .pdf com as imagens. Estes recursos são ótimos para serem impressos e pendurados na parede, dando aquele toque de decoração geek especial para os ambientes de desenvolvimento.

Antes de começar a análise do modelo é preciso dizer que oficialmente o WordPress só pode ser instalado no MySQL. Isso quer dizer que se a empresa já possui outro banco de dados, como PostgreSQL, SQL Server ou Oracle por exemplo, é preciso configurar um ambiente multi-banco, o que possui implicações para quem administra os servidores. Na página oficial do WordPress há uma descrição dos motivos que levaram a equipe de desenvolvimento do WordPress a escolher apenas o MySQL como banco de dados e também quais são as possíveis abordagens para tornar este CMS mult-banco destacadas com argumentos a favor e contra cada uma das abordagens. De qualquer forma, existem projetos que se propõem a suportar o WordPress no PostgreSQL (http://wordpress-pg.sourceforge.net/ e http://sourceforge.net/projects/postgresqlword/files/), no SQL Server (http://www.ixalon.net/2008/10/wordpress-and-microsoft-sql-server/ e http://www.forestpointtechnologies.com/blog/wordpress-on-sql-server/) e em outros bancos de dados (http://wordpress.org/extend/plugins/pdo-for-wordpress/ e http://wordpress.org/extend/plugins/external-database-authentication/).

Mais um pequeno detalhe antes da análise do modelo: o próprio criador do WordPress, Matt Mullenweg, afirmou recentemente no evento CMS Brasil 2009, realizado pelo iMasters, que inicialmente todas as configurações e dados eram armazenadas em arquivos de configuração separadas, seguindo a tradição do ambiente Unix. Conforme o projeto foi crescendo, estas configurações foram inseridas no banco de dados, o que tornou a ferramenta dinâmica o suficiente para se tornar um CMS robusto. Contudo, esta inserção não foi algo muito planejado do ponto de vista formal de modelagem de banco de dados como veremos a seguir.

O primeiro ponto que chama a atenção no modelo do WordPress é a falta de chaves estrangeiras. Este modelo de dados não possui nenhuma chave estrangeira, provavelmente devido ao fato de que ele foi criado utilizando o engine MyISAM do MySQL ao invés do engine InnoDB.

O MySQL apresenta a criação de chaves estrangeiras com o engine InnoDB a partir da versão 3.23.43b. O MySQL já está na versão 6, porém há o famoso problema de compatibilidade com as base legada. Provavelmente escolheu-se o MyISAM por facilidade e por motivos de desempenho, o que NÃO quer dizer que um banco de dados com o InnoDB não possa ser ajustado para ter uma performance aceitável. Sem entrar em uma discussão mais profunda, em geral muitas pessoas advogam que o engine MyISAM possui melhor performance que o InnoDB, porém este último possui suporte a transações, integridade e outros recursos que o MyISAM não possui.

Mais uma vez, sem entrar em detalhes, existem diversas técnicas para otimizar um banco de dados do WordPress como configuração do cache do MySQL, reescrita de consultas, tipagem e outras. Os detalhes destas técnicas ficam como assunto para um outro artigo, pois neste me concentro apenas na análise do modelo, o que também pode afetar positivamente ou negativamente o desempenho

A falta de chaves estrangeiras quer dizer que o relacionamento entre algumas tabelas não é mantido pelo banco de dados e sim pela aplicação. Isso permite que haja dados inconsistentes no banco de dados como, por exemplo, um comentário de um blog que não tem nenhum post associado. Apesar deste cenário ser fictício e ocorrer apenas quando alguém altera os dados diretamente pelo banco de dados e não pelo painel de administração do WordPress, esta possibilidade de inconsistência pode gerar problemas, principalmente quando se fala em migração de dados e segurança.

Aqui temos outra característica da aplicação: caso haja necessidade de se programar algo no WordPress, deve-se utilizar a linguagem PHP e fazer uso de uma camada de abstração de dados implementada pela biblioteca ezSQL, responsável por criar classes que permitem o acesso aos dados. Se o desenvolvedor quiser, ele também pode enviar instruções SQL diretamente para o banco de dados, como estas 13 consultas SQL úteis para quem trabalha com blogs no WordPress.

Outro aspecto que pode afetar muito o desempenho do WordPress é a tipagem de dados. Já abordei este assunto em uma coluna anterior aqui do iMasters chamada Desperdiçando espaço em disco, porém basta dizer que os tipos de dados utilizados neste modelo são demasiadamente exagerados, o que pode gerar vários problemas de desempenho quando a base se torna carregada. Destaque especial vai par o tipo unsigned BIGINT(20) utilizado nas chaves primárias e nos índices: este tipo de dados armazena valores de 0 a 18.446.744.073.709.551.615 ou 18 quintilhões 446 quatrilhões 744 trilhões 73 bilhões 709 milhões 551 mil e 615 ou aproximadamente 10 elevada à 18 potência em 20 bytes. Suponho que raramente um blog ou outro tipo de aplicação chegue a este número de posts ou comentários. Isso implica em mais sobrecarga nas páginas de dados e de índices, uma vez que todas as tabelas do modelo contém uma chave primária com o tipo de dados BIGINT(20).

Além da tipagem exagerada, há também redundância de informação: praticamente toda a informação relacionada à data é armazenada em duas colunas com tipos de dados diferentes. Por exemplo, a tabela wp_comments que armazena os comentários dos posts contém as colunas comment_date e comment_date_gmt, ambas do tipo DATETIME. Se o objetivo é armazenar a data, bastaria apenas a coluna que armazena a data no formato GMT. Mais uma vez, provavelmente existem duas colunas devido à compatibilidade com o legado: é possível que inicialmente existisse apenas uma coluna e posteriormente adicionou-se a segunda. Porém remover a primeira coluna faria páginas anteriores do WordPress pararem de funcionar.

Outro aspecto do modelo é a falta de normalização. Isso mesmo, o modelo de dados do WordPress não está normalizado até a terceira forma normal. Isso se deve porque existem colunas que trazem dados agregados e repetidos como, por exemplo, a coluna comment_count da tabela wp_posts. Esta coluna armazena a quantidade de comentários do post, valor este que pode ser calculado contando-se as linhas da tabela wp_comments em uma instrução SQL. O motivo de armazenar esta informação que pode ser derivada do modelo provavelmente é o desempenho. Esta técnica é similar a modelos dimensionais utilizados em sistemas OLAP.

Outro detalhe interessante é que o modelo de dados não possui nenhuma outra integridade de domínio ou stored procedure que faça restrição ao que é inserido no banco. Apesar de isso não ser obrigatório, esta prática abre margem para problemas como SQL Injection onde um usuário malicioso pode tentar invadir o site por meio de caracteres especiais. Além disso, a falta desta integridade pode permitir dados que invalidem a aplicação como, por exemplo, colocar o valor -2 na coluna menu_order da tabela wp_posts. Há também algumas colunas de tabelas onde o valor NULL é permitido, tornando necessária uma checagem adicional na aplicação. Enquanto alguns podem argumentar que isso é responsabilidade da aplicação, não é raro encontrar bancos de dados com este tipo de integridade de domínio implementada, fornecendo assim mais uma camada de segurança e consistência de dados.

Outro aspecto a ser mencionado no modelo é o armazenamento de arquivo atachado em um post. De acordo com o modelo, os tipos de arquivos são armazenados na coluna post_mine_type da tabela wp_posts, a principal tabela do modelo. Contudo os arquivos em si são colocados em um diretório da instalação do WordPress. Enquanto existem vantagens e desvantagens de se colocar arquivos armazenados internamente no banco de dados, existem também questões de segurança, espaço em disco, acesso concorrente e atualização do conteúdo destes arquivos que ficam fora do banco de dados, gerando assim uma tarefa adicional para o administrador. Esta técnica de armazenar apenas o local de um arquivo no banco de dados ao invés de seu conteúdo é tão comum que foi classificada como um dos database anti-patters, que podem ser vistos nesta apresentação.

Em resumo, pode-se dizer que o modelo do WordPress atende a sua necessidade, porém não é um modelo ideal do ponto de vista da modelagem formal. Em diversas situações, como em uma consultoria de banco de dados recente, tive que efetuar mudanças no modelo de banco de dados visando resolver problemas de desempenho, especialmente em sites cujo volume de acesso é grande. Porém o WordPress ainda é uma aplicação relativamente nova e com o apoio da comunidade pode se tornar cada vez melhor, particularmente em relação ao seu banco de dados.

Fonte: Mauro Pichiliani/IMasters

WordPress, Drupal ou Joomla: qual a melhor solução para o seu projeto?

Com tantas opções de CMS’s disponíveis hoje em dia, com funcionalidades e finalidades diferentes, não faz muito sentido dizer qual deles é o melhor, mas sim qual deles atende melhor as suas necessidades. E, para chegarmos a essa resposta, nada melhor do que uma boa análise das opções que temos disponíveis.

Para começar a brincadeira, trago aqui um pequeno comparativo entre as principais opções livres em CMS’s, baseado em algumas informações do infográfico feito pela DeviousMedia, além de um bate-papo com três especialistas nessas soluções.

WordPress, joomla ou drupal?

Um breve histórico de WordPress, Drupal e Joomla

O mais velho entre os três sistemas é o Drupal, que foi criado pelo programador Dries Buytaert e lançado em 15 de janeiro de 2001. O nome Drupal vem da palavra holandesa “druppel”, que significa “gota”, e atualmente está na sua versão número 7, com uma frequência média de uma atualização a cada 36 dias, desde a sua versão 4.3, lançada em novembro de 2003, num total de 77 atualizações. Aproximadamente 1,6% dos sites da web usam o Drupal, entre eles o The Economist, The White House, MTV, London.gov.uk e The Onion.

Já o WordPress foi criado por Matt Mullenweg a partir do sistema B2/Cafelog, e teve seu lançamento em 27 de maio de 2003. O que começou como um simples sistema para blogs, hoje já na sua versão 3, está consolidado como um CMS bem completo, com uma frequência média de uma atualização a cada 17,8 dias, num total de 164 atualizações. Hoje ele é usado por aproximadamente 14,3% dos sites da web, entre eles o MTV Newsroom, The Ford Story, entre outros. Uma curiosidade é que, desde a sua versão 1.0, a maioria das versões do WordPress leva o nome de um cantor de jazz, como Coltrane ou Gershwin.

Por fim, temos o Joomla, criado a partir do CMS Mambo e lançado em 16 de setembro de 2005. Mantendo uma grande comunidade em vários países e línguas, o Joomla possui 6 versões lançadas, com uma frequência média de uma atualização a cada 49 dias na sua versão 1.5, e uma atualização a cada 25 dias na sua versão 1.6. São 27 atualizações (incluindo versões Beta) entre essas duas versões. Aproximadamente 2,7% dos sites da web usam o Joomla, entre eles estão sites como o Linux.com e o IHOP.

Ambos os sistemas são escritos em PHP, além de serem projetos de código aberto, distribuídos sob a GNU General Public License.

Plugins e Templates

Em praticamente todos os CMS’s, podemos acrescentar novas funcionalidades através de plugins ou módulos, que podem estender o uso do sistema para diversas finalidades. Nesse sentido, o WordPress leva vantagem, tendo os desenvolvedores um número de aproximadamente 14.629 opções disponíveis. No Drupal, esse número é de aproximadamente 8.039, enquanto o Joomla possui uma média de 8.000.

Para quem possui um projeto mais modesto, e pretende abrir mão de uma identidade visual personalizada, usando um modelo de site com funcionalidades definidas e layout pronto, são muitas as opções de templates disponíveis para os diferentes CMS’s. Considerando apenas os templates gratuitos disponíveis nos sites oficiais, temos uma marca de 1415 templates para WordPress e 878 templates para Drupal. No site oficial do Joomla, não constam informações referentes a templates.

Otimização para os mecanismos de busca

Elemento obrigatório na concepção de qualquer projeto web, as técnicas de SEO são hoje uma exigência de praticamente todos os clientes, até daqueles que não têm nem ideia do que isso venha a ser. Mesmo que hoje os principais influenciadores para a definição do posicionamento das páginas nos resultados de busca estejam relacionados à qualidade do conteúdo e à popularidade dos sites, podemos dizer que os primeiros passos para um bom SEO começam na estrutura do código HTML.

Por seguirem bem as práticas recomendadas pela W3C para o desenvolvimento web, ambos os sistemas possuem uma estrutura de código apropriada para o SEO. Contudo, o WordPress ainda leva uma pequena vantagem, por possuir uma estrutura um pouco mais semântica.

Ambos os sistemas possuem boas extensões para SEO, que buscam aprimorar a qualidade de elementos como títulos, sitemaps e URLs. Entre as extensões disponíveis, podemos destacar o WordPress SEO para WordPress, o Pathauto para Drupal, e as extensões AceSEF e sh404SEF para Joomla.

Tecnicamente falando

O WordPress, que ganhou popularidade como uma plataforma para blogs, vem se mostrando a cada dia como um dos CMS’s mais completos que existem. Para Leo Germani do Hacklab, o WordPress foi a ferramenta com a qual ele conseguiu obter os melhores resultados com maior eficiência. “No final de 2006 resolvi adotar um CMS para trabalhar, e experimentei as principais opções. O que me atraiu no WordPress desde o início foi sua simplicidade. Enquanto outros CMS’s demandavam uma curva aprendizado maior, o WordPress se mostrava direto e fácil, tanto do ponto de vista do usuário quanto do ponto de vista do desenvolvedor”, afirma Leo.

Nadir Alves da Bule Comunicação, que já trabalhou com CMS’s como o Plone e o WordPress, afirma que o Joomla possui um grande poder de customização de templates e uma curva de aprendizado muito leve. “As opções de expansão do Joomla sempre foram muito grandes, atualmente existem mais de 8.000 extensões no diretório oficial. Somando isso ao sistema de permissões de usuários e à facilidade de criar websites rápidos e completamente diferentes um do outro, o Joomla tornou-se uma escolha excelente e recomendada aos nossos clientes”.

Já o Drupal é considerando o mais complexo entre as três opções. Mas para Alex Piaz, que trabalha no Instituto Socioambiental (ISA), apesar de a curva de aprendizado do Drupal ser maior em relação aos seus similares, uma vez que você “pega o jeito” tudo fica muito claro, e o desenvolvimento passa a fluir sem maiores dificuldades. “Trabalho com o Drupal desde meados de 2006, pela facilidade de customização e construção de módulos, instalação multisite out of the box, localização e tradução com gettext totalmente desacoplados do core, comunidade atuante e extensa documentação. Tudo isso permite criar websites complexos com muito menos esforço de programação”, conclui Piaz.

As vantagens de cada CMS

Uma das maiores vantagens do WordPress é, sem dúvida, a sua facilidade. Leo Germani considera que esse CMS possui simplicidade e eficiência em todos os sentidos. “Do ponto de vista do usuário, temos um painel administrativo simples, bonito e fácil de usar. Do ponto de vista do desenvolvedor, temos uma arquitetura de templates muito fácil de entender e explorar, uma arquitetura de plugins muito eficiente, e uma estrutura de banco de dados muito simples e poderosa. Além disso, possui uma comunidade imensa e um desenvolvimento consistente, que se mantém firme aos seus princípios: manter o core simples e enxuto, deixando qualquer coisa mais específica para plugins e templates“.

Nadir acredita que a atual expansão e acesso ao Joomla para os novos desenvolvedores pode ser uma grande vantagem sobre os outros CMS’s. “Outra vantagem está no novo gerenciamento de usuários e permissões, que foi a funcionalidade mais esperada para a nova versão, e que agora (versão 1.7) está bem madura e extensível. Nesta nova versão, o sistema multilíngue nativo permite criação e administração de conteúdo para diversos idiomas de forma muito fácil para o cliente”.

Outras vantagens do Joomla levantadas são relativas aos templates e extensões. “A facilidade na criação de templates possibilita que, através de poucas linhas de HTML, seja criado praticamente qualquer tipo de layout em pouco tempo. Outro ponto muito importante são as extensões, que melhoraram muito desde a nova versão, integrando-se bem às novas funcionalidades do core do Joomla, e que possuem uma variedade de funções dificilmente alcançada por outros CMS’s”, conclui Nadir.

Para Piaz, estão nos módulos as maiores vantagens do Drupal. “A quantidade de módulos disponíveis é absurdamente grande, além de o roadmap ser muito claro quanto aos releases. Isso nos dá uma visão de longo prazo (cerca de 3 anos) sobre o caminho a seguir”.

Ainda sobre os módulos, o quesito “compatibilidade” é um dos pontos fortes do Drupal. “Temos praticamente 100% de garantia de que todos os módulos são compatíveis com a versão instalada, ou seja, um módulo feito para a série 6.x irá rodar sem problemas no Drupal 6.1, 6.2 e assim por diante. Um outro ponto importante é que o Drupal sempre oferece um upgrade path a cada nova versão lançada (6.x para 7.x, por exemplo). Assim, a nova versão só é declarada stable quando o upgrade path é disponibilizado”, afirma Piaz.

Para quais projetos cada CMS é indicado?

Muita gente considera que o WordPress é um sistema indicado apenas para a produção de blogs. Leo Germani considera que não há dúvidas de que o WordPress seja realmente a melhor plataforma para essa finalidade, mas que além disso ele é uma ótima solução para sites institucionais ou portais de notícias. “Se você tem um site que é 90% editorial, mas que necessita de funcionalidades como área restrita ou importação de conteúdos externos, o WordPress também é ideal, pois a sua arquitetura de temas e plugin facilita muito para que possamos usá-lo como uma espécie de framework, podendo desenvolver muita coisa sobre ele”.

Quanto ao Joomla, Nadir acredita que ele seja ideal para projetos que vão desde sites de pequeno porte até grandes portais. “Existem projetos específicos para Intranet muito facilitados pelo novo ACL nesta nova versão, e já vimos também uma excelente integração do CMS com o Magento. A gama de possibilidades é muito grande, inclusive diversos sites do governo que requerem muita segurança e estabilidade, hoje utilizam o Joomla“.

Piaz também considera que o Drupal é uma ferramenta ideal para sites e aplicativos web de todos os tipos e tamanhos. “O código do Drupal é bem estruturado, e permite um alto grau de customização sem que seja preciso alterar seu núcleo. Sua robustez pode ser atestada pela quantidade de websites de alto tráfego rodando Drupal“.

Conclusão

Ambos os CMS’s possuem pontos fracos e fortes. Muitos profissionais procuram optar pela ferramenta mais fácil, como é o caso do WordPress, o que pode ser bom em determinado projetos, mas deixar a desejar em outros. Considerando também a questão financeira, profissionais que trabalham com ferramentas mais complexas como o Drupal acabam por ser mais raros, e por isso mais caros.

A verdade é que muitas vezes o uso de um CMS acaba sendo condicionado pela identificação e pelo conhecimento prévio que os desenvolvedores têm na ferramenta. Mas o ideal é que, mesmo que você tenha preferência por um determinado CMS, ainda assim procure conhecer as possibilidades de outros sistemas.

Acredite, saber escolher a ferramenta ideal para cada tipo de projeto pode fazer a diferença.

Fonte: Edu Agni/IMaster

Frutily (loja virtual)

Objetivos do Projeto

Este projeto teve como objetivo desenvolver um site com visual leve, simples, bonito, fácil de navegar, amigo das ferramentas de pesquisa (Google), objetivando divulgação eficiente, voltada para o publico empresarial e pessoa física, sobre as atividades da empresa Frutily.

Comércio Eletrônico

A pedido do cliente, foi adicionado ao sistema gerenciador do conteúdo do site, um outro sistema, voltado para comércio eletrônico. Ainda a pedido do cliente, este sistema foi customizado para trabalhar apenas com pedidos, pois segundo o modelo de negócios, não havia interesse em pagamentos online.

Basicamente, o navegante visita o site, adiciona os produtos desejados nas quantidades desejadas ao carrinho e finaliza o pedido fornecendo seus dados de contato. A pedido fica registrado no sistema de vendas e, além disto, uma email de notificação com todas as informações referente ao pedido e aos dados de contato é enviada para a Frutily. O pedido é confirmado por telefone e em até 24horas os produtos são enviados ao cliente, que efetua o pagamento apenas ao receber os produtos.

Características:

  • Sistema de gerenciamento de conteúdo;
  • Sistema de Vendas Online
  • Otimização para ferramentas de Buscas;
  • Backup automático;
  • Controle detalhado dos perfis dos usuários;
  • Integração com o twitter;
  • Gerenciador de formulários;
  • Anti-span;
  • Otimização de desempenho (cache);
  • Estatísticas diversas;
  • Todo em português;
  • JQuery e Ajax;
  • 100% funcional em todos os navegadores, inclusive os mais antigos;