Alguns anos atrás existiam tantos frameworks nascendo e morrendo no mundo do PHP que era difícil apostar qual framework não seria descontinuado ou projetado de outra forma meses depois. Claro que o ZendFramework, Cake e Symfony, sempre foram uma boa aposta. Mas devido a imaturidade da própria linguagem, que melhora cada vez mais rápido e trás cada vez mais novidades fica difícil para frameworks de nomir porte acompanhar as features.

Hoje temos vários projetos bem consolidados que contam com o apoio de milhares de programadores do mundo e alguns são bem específicos para uma área de atuação. E como fazemos para escolher o melhor para estudarmos, ou implantarmos em um projeto ? Não tem como estudarmos todos (nem mesmo todos os mais usados) e identificarmos os pontos fortes e fracos de cada um. Até porque frameworks geralmente se atualizam, e as novas versões provavelmente melhoraram seus pontos fracos e construíram outros.

Para ajudar nessa tarefa, nada melhor do que contar com os próprios programadores que utilizam a ferramenta. O site socialcompare.com fornece maneiras de você comparar diversas coisas, dentre ela existe uma lista que compara os principais frameworks PHP disponíveis no mercado atualmente, por ser uma “rede social de comparação”qualquer pessoa pode ir lá e contribuir, especificando um ponto importante para o framework que está sendo comparado com o resto da listagem.

Aproveite, façam suas contribuições e coloquem ai nos comentários qual framework deveria está nessa lista.

Protegendo sua conta Admin

1. nunca use admin para o nome padrão de seu usuário administrador do wordpress, para alguém acessar o administrador do wordpress precisará de login e senha, os hackers sabendo o login já é meio caminho andado. Outra coisa importante é nunca exibir seu login nas postagens ou em algum lugar do site. O wordpress lhe dá a opção de qual nome exibir em suas postagens na área de configuração do usuário.

2. Nunca use uma senha que você use costumeiramente em outros sites, isso porque alguns sites não guardam as senhas criptografadas e os administradores deles podem vê-las ou esses dados podem ser acessados por hackers. Use senhas fortes, já consegui acessar grandes sites com o velho 1234. Evite salvar senhas no computador, a não ser que ele seja seu laptop pessoal e ninguém mais tenha acesso a ele.

3. Nunca use o endereço do seu usuário admin em outros sites, pelo mesmo motivocitado anteriormente.

Os três pontos citados acima são simplesmente para dizer a você que seu Usuário, e-mail e senha são as três coisas que você mais deve manter seguro.

Protegendo seu Blog

Seu wordpress e os arquivo mais importantes dele serão o próximo alvo de um hacker. Aqui vão algumas dicas para deixá-lo um pouco mais seguro:

1. Atualize sempre seu wordpress. Não seja preguiçoso e mantenha seu worpress atualizado, muitas vezes as atualizações são necessárias para própria segurança do site. A versão do wordpress em que seu site está rodando também deve ser um segredo, um hacker pode está vasculhando uma versão específica por já conhecer uma vulnerabilidade. Para ocultar a versão do WordPress vá em seu arquivo functions.php (dashboard -> Appearance -> Editor -> Functions.php) e cole o seguinte código:

[php]
remove_action(‘wp_header’, ‘wp_generator’);
[/php]

2. Você também pode utilizar o plugin Secure WordPress.

3. Se não for necessário o cadastro de usuários em seu site, retire-o. Concessão de acessos ao dashboard para um hacker pode ser fatal, mesmo ele sendo um simples assinante.

4. Nunca deixe os prefixos de tabelas o padrão wp_, se você pode alterá-los, faça agora, senão, ponha na sua lista de afazeres e troque-os o quanto antes.

5. Nunca use qualquer plugin anônimo, a não ser que tenha sido você que desenvolveu, procure utilizar os plugins do diretório de plugins do WordPress onde, teóricamente. apenas plugins seguros estão disponíveis.

6. Crie um arquivo .htaccess para o seu diretório admin também, normalmente encontamos apenas esse arquivo na raiz do site. Copier ele para a pasta wp-admin também.

7. Nunca use o CHMOD 777. se você não puder modificar as permissões dos arquivos para no máximo CHMOD 750, contacte o seu host e pergunte a eles como fazer isso.

Melhores Práticas

Mesmo se seu blog for racheado ainda há procedimentos para diminuírmos os danos causados pela invasão:

1. Backup de seus posts, comentários e páginas com uma regularidade semanal ou sempre depois de você publicar alguma coisa. Alguns hosts oferecem esse serviço de modo automático.

2. Backup do seu site sempre que tiver uma grande atualização ou for instalado um novo tema. Isso pode ser feito em intervalos maiores.

3. Sempre contate seu host quando achar que seu site foi hackeado. eles geralmente possuem processos de backup e podem lhe mostrar qual o melhor caminho seguir para sanar as vulnerabilidades do seu sistema.

4. Quando conseguir restaurar eu site, deve ser feito uma varredura para procurar possíveis malwares que o hacker possa ter instalado.

5. Faça uma busca com Copyscape para verificar se algum diretório foi roubado.

Acho que essas dicas são suficientes para garantir um relativa segurança ao seu wordpress. se você conhece outras dicas e macetes por favor compartilhe ai nos comentários.

O PHP oferece algumas constantes predefinidas que nós podemos usar em diversos dos nossos Scripts. Como bom programador, devemos prezar em manter um código limpo e legível, e as Constantes Mágicas podem nos ajudar a criar um código assim. PHP nos fornece oito Constantes Mágicas que eu apresentarei logo abaixo:

1. __FILE__

Exibe o caminho completo e nome do arquivo. É bastante útil para encontrar o arquivo no qual está sendo executado o script.

[php]
echo __FILE__;
// Imprime /var/www/projeto/index.php
[/php]

2. __LINE__

Exibe o número atual da linha na qual a constante está. É bastante útil para depurar o código. Com isso podemos obter facilmente detalhes sobre o número de linhas em arquivos.

[php]
echo __LINE__;
// Imprime 2
[/php]

3. __DIR__

Exibe o diretório atual do arquivo. Essa constatne mágica é realmente bastante útil e utilizada para nos dizer caminhos absolutos de diretórios.

[php]
echo __DIR__;
// Imprime /var/www/projeto
[/php]

4. __FUNCTION__

Exibe o nome da função que está sendo executada no momento da chamada da constante, foi adicionada no PHP 4.3.0

[php]
function fun_name()
{
echo __FUNCTION__;
}
[/php]

5. __CLASS__

Exibe o nome da classe onde a constante está sendo executada atualmente.

[php]
class testClass
{
public function __construct(){
echo __CLASS__;
}
}

$obj = new testClass();
[/php]

6. __METHOD__

Exibe o método da classe na qual a constante está sendo executada

[php]
class testClass
{
public function fun_test(){
echo __METHOD__;
}
}

$obj = new testClass();
$obj->fun_test();
// imprime testClass::fun_test
[/php]

7. __NAMESPACE__

Exibe o nome do Namespace atual, essa característica foi recém adicionada no PHP 5.3

[php]
namespace teste;

echo __NAMESPACE__;
// Imprime teste
[/php]

8. __TRAIT__

E por último, mas não menos importante a Constante Mágica TRAIT que foi adicionada na versão 5.4 do PHP

[php]
class A{
public function funcA(){

}
}

trait Test_trait{
public function funcA(){
parent::funcA();
echo __TRAIT__;
}
}

class B extends A{
use Test_trait;
}

$obj = new B();
$obj->funcA();
// Imprime Test_trait
[/php]

Esse código só deverá funcionar em PHP5.4, que ainda não está em uma versão estável, a versão atual ainda não implementa Traits, mas em breve escreveri um artigo explicando como esse recurso funciona. A grosso modo Traits nos dão a possibilidade de termos “heranças horizontais”.

O objetivo desse artigo é esclarecer o básico desse framework para que os desenvolvedores possam explorar cada vez mais desses recursos para construir melhor e de maneira mais eficaz suas aplicações. No início as coisas podem parecer bem complicadas, mas quando você começar a estudar a fundo o sistema logo elas irão se esclarecer.

Código Organizado em Módulos

Magento utiliza o seu código em módulos individuais muito parecido com o padrão HMVC. Diferente do típico padrão MVC utilizado na maioria dos frameworks conhecidos onde todos os controllers estão em uma pasta, models em outra, etc. No Magento os arquivos são agrupados por suas funcionalidades, criamos pacotinhos que são “independentes” uns dos outros e denominamos de módulos.

Códigos do Magento

Por exemplo, você encontrará todos os arquivos relacionados ao módulo de check-out do Magento (Controllers, Models, Helpers, Blocks, etc) no seguinte diretório:

[php]app / code / core / Mage / Checkout[/php]

Código da Comunidade

Sempre que você instalar uma extensão disponibilizada na comunidade pelo Magento Connect ele será colocado em um local específico, para não ser interferido por atualizações do core ou modificações de seus próprios módulos:

[php]app / code / community / Package / Modulename[/php]

Seu Código

Quando você quiser personalizar ou extender as funcionalidades do Magento, em vez de editar os arquivos diretamente no Core do sistema você deve trabalhar em um local específico para seus módulos em desenvolvimento:

[php]app / code / local / Package / Modulename[/php]

O Package (que é também muitas vezes se referida como Namespace) é um nome único que identifica a empresa (ou responsável pelo desenvolvimento). A intenção é que cada membro da comunidade utilize seu próprio nome em seus Packages para não haver conflitos com módulos de outros desenvolvedores.

Quando criamos um novo módulo no Magento, precisamos informá-lo sobre isso. Isso é feito simplesmente inserindo um arquivo XML na pasta:

[php]app / etc / modules[/php]

Existem dois tipos de arquivos nessa pasta, o primeiro informa ao Magento um módulo individual e é nomeado nessa forma: Packagename_ModuleName.xml. O segundo tipo é um arquivo que informa vários módulos de um mesmo Package / Namespace, e é nomeado da seguinte forma: Packagename_All.xml

 MVC baseado em Configuração (Configuration-Based MVC)

Conheço duas ótimas maneiras de trabalharmos com MVC. A primeira é a convention-based MVC (MVC baseado em convenção), onde se você quiser adicionar, por exemplo, um novo controller ou model, basta você criar o arquivo e o sistema irá reconhecê-lo automaticamente.

O segundo tipo é o Configuration-Based MVC (MCV baseado em configuração), que é como o Magento é baseado, além de adicionarmos um novo arquivo / classe, muitas vezes temos que informar explicitamente ao sistema sobre os novos recursos incluídos no sistema. No Magento, cada módulo tem um arquivo de configuração chamado config.xml. Esse arquivo tem todas as configurações relevantes para um módulo Magento. Todos esses arquivos serão carregados em uma arvore de configurações em tempo de execução.

Por exemplo, para utilizar um Model em seu módulo você terá que informar isso em seu config.xml, bem como o nome base das classes que todos os seus Models devem ter.

[xml]
<models>
<packagename>
<class> Package_Modulename_Model</class>
</packagename>
</models>
[/xml]

O mesmo vale para Helpers, Blocks, Routers para os Controllers, Event Handlers, etc. Quase sempre que for preciso adicionar um novo recurso no nosso módulo Magento teremos que modificar o arquivo config.xml.

Controllers

Quem conhece Zend Framework ou qualquer outro framework PHP sabe que a grande maioria deles iniciam com um arquivo de Bootstrap, como o Magento é baseado em ZF não poderia ser diferente.

Para entendermos melhor, vejamos qual o processo que se realiza quando fazemos uma chamada no Magento:

1 – É examinada a URL
2 – Com base em uma série de regras, essa URL é transformada em uma Classe Controller e um Método Action (o que chamamos de roteamento).
3 – É instanciado essa Classe Controller e executado o Método Action (o que chamamos de dispatching).

Analisemos, por exemplo, a seguinte URL:

http://www.example.com/catalog/category/view/id/25

catalog – front name

A primeira parte da URL é chamada de front name. Isso informa, mais ou menos ao Magento em qual módulo será encontrado o Controller. No exemplo acima o front name é catalog, que corresponde ao módulo localizado em:
[php]app / code / core / Mage / catalog[/php]

category – Controller Name

A segunda parte da URL informa ao Magento qual Controller deverá ser utilizado. Cada Módulo possui uma pasta (controllers) que contém todos os controllers do módulo. No exemplo acima, o nome category será traduzido para a chamada do arquivo correto:
[php]app / code / core / Mage / catalog / CategoryController.php[/php]

Que se parece com isso:
[php]
class Mage_Catalog_CategoryController extends Mage_Core_Controller_Front_Action
{

}
[/php]

view – Action Name

O terceiro lugar da nossa URL estará o nome da Action que deverá ser executada. No nosso exemplo esse nome é “view”, então a palavra view será transformada no método Action que será executado. Teremos então a execução do método “viewAction”:

[php]
class Mage_Catalog_CategoryController extends Mage_Core_Controller_Front_Action
{
public function viewAction()
{
}
}
[/php]

Quem estiver familiarizado com o Zend Framework entenderá essa nomenclatura.

id/25 – Parametro/Valor

Quaisquer porções da URL após a definição do método será considerada um par chave / valor para variáveis do tipo GET. Assim, em nosso exemplo, o “id/25″ significa que teremos uma variável “id” com valor “25″.

Como mencionado anteriormente, para usarmos controllers no nosso módulo teremos que configurá-los em nosso arquivo config.xml. Abaixo temos um trecho de configuração dos controllers do módulo Catalog do Magento:

[xml]
<frontend>
<routers>
<catalog>
<use>standard</use>
<args>
<module>Mage_Catalog</module>
<frontName>catalog</frontName>
</args>
</catalog>
</routers>
</frontend>
[/xml]

Não se preocupe muito em entender todos os detalhes agora, mas observe o nó <frontName> é ele que faz a ligação do módulo com o Frontname da URL. A maioria dos módulos do Core do Magento escolhem um frontname igual ao nome do módulo, mas isso não é exatamente necessário, você pode escolher qualquer frontname para seus módulos.

A rota descrita acima é a para a aplicação de carrinho de compras do Magento. Se o Magento não encontrar um Controller / Action válido ele tentará novamente dessa vez utilizando um segundo conjunto de regras para o Admin. Se ainda assim o Magento não encontrar um Controller / Action válido ele usará um Controller especial chamado Mage_Cms_IndexController.

Esse Controller irá verificar o CMS do Magento que definirá se há algum conteúdo que deva ser carregado. Se encontrar algum ele carregará, caso não ele trará uma página 404. Um bom exemplo disso é o próprio Index do Magento que utiliza essa página

Carregando Models baseado no contexto da URL

Agora que já descobrimos como o Magento encontra e executa nossos métodos, vamos começar a querer escrever nosso código, instanciar outras classes, etc. O Magento oferece uma maneira especial para instanciarmos Models, Helper e Blocks usanfo alguns métodos estáticos da classe Mage. Por exemplo:

[php]
Mage::getModel(‘catalog/product’);
Mage::helper(‘catalog/product’);
[/php]

A string ‘catalog/product’ é chamada de Grouped Class Name. A primeira parte da String determina em qual módulo ela se encontra, já a segunda parte determina qual classe deverá ser carregada. Assim, em nossos exemplo a primeira parte determina o módulo catálogo (app / code / Mage / catalog). E isso significa que no nome da classe irá começar com Mage_Catalog, e então a segunda parte determina o nome final da classe:

[php]
Mage::getModel(‘catalog/product’);
// Mage_Catalog_Model_Product

Mage::hleper(‘catalog/product’);
// Mage_Catalog_Helper_Product
[/php]

Essa regras são regidas pelo que está escrito no arquivo de configuração de cada módulo. Quando você criar seu módulo, criará também seu nome de classe agrupado para trabalhar com Mage::getModel(‘meuprefixo/modelname’);

Não precisamos usar esses “Grouped Class Names” para instanciar nossas classes, no entando veremos que existem inúmeras vantagens para isso.

Models no Magento

O Magento, como a maioria dos frameworks modernos, nos oferece um ORM(Object Relational Mapping) para trabalharmos. ORMs nos ajudam a deixar de escrever comandos SQLs e permitem que manipulemos dados do banco utilizando simplesmente códigos PHP. Por exemplo:

[php]
$model = Mage::getModel(‘catalog/product’)->load( 27 );
$price = $model->getPrice();
$price += 5;
$model->setPrice($price)->setSku(‘SK325724578′);
$model->save();
[/php]

No exemplo acima chamados os métodos “getPrice” e “setPrice” para nosso produto. No entanto, se você abrir a classe Mage_Catalog_Model_Product você não verá métodos com esses nomes. Isso porque o ORM do Magento utiliza os métodos mágicos __get() e __set() do PHP.

Para que isso aconteça pressupõe-se que não teremos os métodos getPrice e setPrice no Model Product. Se isso acontecer os métodos mágicos serão ignorados e serão executados os métodos da classe instanciada. Se tiver mais interessado em saber como isso funciona, dê uma olhada na classe Varien_Object, todos os Models devem herdar dela.

Uma ótima dica é se você quiser obter todos os dados disponíveis em um Model, você pode chamar o método $product->getData() e ele lhe retornará um array com todos os atributos.

Você notará que poderá encadear várias chamadas para o método set:

[php]
$model->setPrice($price)->setSku(‘SK83293432′);
[/php]

Isso porque cada método retorna a instância do próprio modelo. Esse é um padrão que poderemos observar na maioria do codebase do Magento.

O ORM do Magento também possui uma maneira de consultar multiplos objetos através de uma Interface Collections. O exemplo abaixo nos mostra como pegar todos os produtos que custam R$ 5,00:

[php]
$products_collections = Mage::getModel(‘catalog/product’)
->getCollection()
->addAttributeToSelect(‘*’)
->addFieldToFilter(‘price’,’5.00′);

foreach( $products_collection as $product )
{
echo $product->getName();
}
[/php]

Você deve está se perguntando para que o método addAttributeToSelect() serve. O Magento tem dois grandes tipos de objetos Model. Um deles é o tradicional “um Objeto = uma Tabela”. Quando instanciamos esse tipo de objeto, todos os atributos são automaticamente selecionados.

O segundo tipo é o Entity Attribute Value (EAV). Modelos EAV disseminam os dados em várias tabelas do banco de dados. Isso permite ao sistema proposcionar uma flexibibildade suficiente para oferecer a criação de diversos atributos para cada produto sem ter que fazer qualquer alteração no esquema do banco de dados. Ao criar um collection de objetos EAV o Magento é bastante cauteloso em relação as colunas que irão para a consulta, assim podemos utilizar o método addAttributeToSelect() para obter somente as colunas que precisamos, ou utilizar addAttributeToSelect(‘*’) para obter todas as colunas.

Helpers

Classes Helpers no Magento contém métodos utilitários que nos permite executar tarefas comuns em diversos objetos. Por exemplo:

[php]
$helper = Mage::helper(‘catalog’);
[/php]

Você vai perceber que deixamos de lado a segunda parte do nome da classe agrupada. Cada módulo tem sua própria classe Helper default. O código seguinte é equivalente ao de cima:

[php]
$helper = Mage::helper(‘catalog/data’);
[/php]

A maioria dos Helpers herdam da classe Mage_Core_Helper_Abstract, que trás vários métodos úteis por padrão.

Layouts

Bem, já vimos como funciona os Controllers, Models e Helpers. E em um sistema MVC típico, após manipularmos nossos dados na camada de Model nós:

1 – Definimos algumas variáveis para nossas Views.
2 – O sistema irá criar a saída HTML padrão.
3 – O sistema irá carregar nossa View dentro do layout padrão.

No entanto, se olharmos um Controller Action no Magento não veremos nada disso:

/**
* View product gallery action
**/

public function galleryAction()
{
if(!$this->_initProduct()){
if (isset($_GET['store']) && !$this->getResponse()->isRedirect()) {
$this->_redirect(”);
}elseif (!$this->getResponse()->isRedirect()) {
$this->_forward(‘noRoute’);
}
return;
}

$this->loadLayout();
$this->renderLayout();
}

Observe os dois últimos comandos executados no Controller Action. Veja que o “V” do MVC no Magento já é diferente do que estamos acostumados, aqui precisamos explicitamente executar a renderização do layout.

O layout também é bem diferente. Um layout no Magento é constituído por uma objeto que contém uma coleção aninhada de objetos do tipo “Block”. Cada objeto Block irá renderizar um pedaço de HTML. Objetos Block fazem isso combinando código PHP e incluindo arquivos .phtml de templates.

O objetos Block destinam-se a interagir com Magento buscando dados dos Models enquanto os arquivos .phtml se responsabilizam em em produzir o HTML necessário para uma página. Por exemplo, o Block do cabeçalho (app/code/core/Mage/Page/Block/Html/Head.php) usa o arquivo head.phtml (/html/head.phtml).

Outra maneira de entender isso é pensar que as classes Block funcionam como mini-controllers enquanto os arquivos .phtml funcionam como as Views. Por padrão, quando chamamos

[php]
$this->loadLayout();
$this->renderLayout();
[/php]

Magento irá carregar um estrutura como um esqueleto do site. Esses blocos estruturais trazem o básico do HTML, header, body, bem como a configuração para quantidade de colunas do layout e além disso, alguns blocos de conteúdo como navegação, mensagem padrão de boas vindas, etc.

Blocos estruturais e Blocos de conteúdo são designações arbitrárias no sistema de layout do Magento. Não temos como saber, programaticamente, se um bloco é do tipo estrutura ou conteúdo, mas é útil pensar neles como um ou outro.

Existem duas maneiras básicas de se adicionar conteúdo no Layout do Magento. A primeira maneira pode ser feita por programação em um Controller Action:

[php]
public function indexAction()
{
$block = $this->getLayout()->createBlock(‘adminhtml/system_account_edit’);
$this->getLayout()->getBlock(‘content’)->append($block);
}

mas mais frequentemente (pelo ao menos da aplicação do carrinho de compras), usamos o sistema de XML do Layout.

Os arquivos de XML do Layout em um tema, permitem que retiremos blocos que normalmente seriam renderizados ou adicionar novos blocos no esqueleto padrão do layout. Por exemplo, considere o layout do arquivo XML:

[xml]
<catalog_category_default>
<reference name=”left”>
<block type=”catalog/navigation” name=”catalog.leftnav” after=”currency” template=”catalog/navigation/left.phtml” />
</reference>
</catalog_category_default>
[/xml]

O XML informa que no Módulo Catalog, no Controller Category, no indexAction seja inserido o Block catalog/navigation dentro do Block de estrutura left, usando o catalog/navigation/left.phtml

Uma última coisa importante sobre Blocks. Muitas vezes veremos códigos em templates que se parecem com isso:

[php]
$this->getChildHtml(‘order_items’);
[/php]

Isso é como um Block renderiza um outro Block aninhado. No entanto, um Block só poderá renderizar um Block aninhado se o mesmo tiver sido declarado como um nó filho dentro do arquivo XML do layout. No exemplo acima nosso Block catalog/navigation não possui Blocks aninhados, isso significa que qualquer chamada $this->getChildHtml() retornará em branco. Porém, se tivermos algo como:

[xml]
<catalog_category_default>
<reference name=”left”>
<block type=”catalog/navigation” name=”catalog.leftnav” after=”currency” template=”catalog/navigation/left.phtml”>
<block type=”core/template” name=”foobar” template=”foo/baz/bar.phtml” />
</block>
</reference>
</catalog_category_default>
[/xml]

do Block category/navigation seriamos capaz de chamar $this->getChidHtml(‘foobar’);.

Observers

Como todo bom sistema orientado a objetos, Magento implementa um padrão Event/Observer para os usuários finais fazerem suas ligações. Como certas ações acontecem durante a requisição de uma página (um Model salva alguma coisa, um usuário pode fazer um login, etc.), então quando isso acontece o Magento envia um sinal de evento.

Ao desenvolver nossos módulos podemos criar métodos para “ouvir” esses eventos. Digamos que seja preciso enviar um e-mail toda vez que um determinado usuário efetue login na loja. Para isso basta ouvirmos o evento “customer_login”(setup no config.xml):

[xml]
<events>
<customer_login>
<observers>
<unique_name>
<type>singleton</type>
<class>mymodule/observer</class>
<method>iSpyWithMyLittleEye</method>
</unique_name>
</observers>
</customer_login>
</events>
[/xml]

e escrever o método que será executado toda vez que um usuário efetuar login:

[php]
class PackageName_Mymodule_Model_Observer
{
public function iSpyWithMyLitleEye($observer)
{
$data = $observer->getData();
// Código para verificar se é o seu usuário
// e enviar o e-mail se necessário
}
}

Sobrescritas de Classes

Finalmente, o Magento oferece a possibilidade de sobrescrever Models, Helpers e Blocks dos módulos do Core pelos códigos dos seus próprios Módulos. Essa é uma característica que é semelhante ao “Duck Typing” ou “Patching Monkey” na linguagem Ruby ou Python.

Aqui está um exemplo para nos ajudar a entender. A classe Model do Módulo product é Mage_Catalog_Model_Product. Sempre que o código a seguir é chamado um objeto Mage_Catalog_Model_Product é criado

[php]
$product = Mage::getModel(‘catalog/product’);
[/php]

Digamos que o que queremos é sobrescrever essa classe por uma classe do meu módulo. Então, o que temos que fazer é criar nossa classe extendendo da classe original:

[php]
class PackageName_ModuleName_Model_Foobazproduct extends Mage_Catalog_Model_Product
{
}
[/php]

Fazer dessa maneira nos permitirá mudar o comportamento de qualquer método da classe e manter o comportamento dos métodos existentes:

[php]
class PackageName_ModuleName_Model_Foobazproduct extends Mage_Catalog_Model_Product
{
public function validate()
{
// adiciona as funcionalidades aqui
return $this;
}
}
[/php]

E como já é de se imaginar, precisamos informar ao Magento sobre essa sobrescrita, e não há meneira melhor de se fazer isso do que em um arquivo config.xml:

[xml]
<models>
<!– Informa ao sistema que esse modulo tem Models –>
<modulename>
<class>Packagename_Modulename_Model</class>
</modulename>

<!– Aqui informo sobre a sobrescrita –>
<catalog>
<rewrite>
<product>Packagename_Modulename_Model_Foobazproduct</product>
</rewrite>
</catalog>
</models>
[/xml]

Temos que notar algo importante aqui. Quando sobrescrevemos um Model, não estamos sobrescrevendo um módulo inteiro, podemos simplesmente sobrescrever um único método de uma classe e o resto do módulo funcionará normalmente.

Bem, eu sei que é muita informação para se absorver logo de início, mas leia algumas vezes, efetue alguns testes e tenho certeza que logo estará apto a se tornar um brande programador Magento.

Esse é um artigo que eu adaptei do próprio site do Magento, acho válido termos um bom material como esses em português, para quem está iniciando. Deixem os comentários

Fonte: Magento Commerce

O MyWebSQL é tão eficaz quanto o PHPMyAdmin e ainda possui uma interface totalmente escrita para web 2.0. Além de tudo ele é uma aplicação Open Source e pode ser facilmente manipulada por você ou qualquer menbro da sua equipe para implementar qualquer coisa que atenda suas necessidades.

Vou listar algumas das características mais proeminentes do MyWebSQL que faz ele se sobresair em cima dos demais, espero que esse review possa ajudar os desenvolvedores encontrarem um cliente Web descente para MySQL.

• Velocidade: O MyWebSQL é substancialmente mais rápido que o PHPMyAdmin. A diferença é tão perceptível que eu tinha que mencioná-la como primeira vantagem sobre o PHPMyAdmin. Ele usa AJAX na execução das consultas e isso acrescenta muito a velocidade da aplicação.

• Simplicidade e interatividade: A interface é extremamente amigável e com um design decentemente minimalista e light. Isso também torna mais fácil para os novatos a terem uma melhor experiência. Os botões e menus são bastante parecidos com os de qualquer sistema operacional, portante, não há curva de aprendizagem para o usuário. O implementação do uso do botão direito do mouse em aplicativos web para mim, é o que torna a experiência bem mais próxima com as aplicações que usamos no desktop, e isso ele implementa muito bem.

• Fácil de instalar: É muito simples de se instalar seja em seu servidro de hospedagem ou em sua máquina local, ele praticamente não necessita de configurações. Basta ter instalado PHP5 e o MySQL (suporta as versões 4 e 5 do SGDB). Recentemente a equipe de desenvolvimento adicionou suporte ao SQLite também.

• Temas e Idiomas:Embora eja uma ferramenta para auxiliar no desenvolvimento web e, teóricamente, não seria necessário grandes aparatos visuais, os desenvolvedores capricharam nesse ponto. O pacote padrão já possui 6 temas para você escolher caso o tema padrão não agrade, e novos temas podem ser desenvolvidos utilizando o JQuery UI.
  

  MyWebSQL Themes

  Além dos temas, o pacote vem disponível com 39 idiomas diferentes para se escolher. Se você é desenvolvedor, seja bem vindo a contribuir com a tradução para qualquer idioma.

MyWebSQL Línguas

• Rápida execução de Querys:O MyWebSQL utiliza AJAX para executar as Querys, tornando o processo muito mais rápido e praticamente sem espera para exibir os resultados. Além disso a interface do Query browser é bem mais parecida com a de um aplicativo desktop, onde temos um painel na parte inferior para digitarmos nossas consultas e os resultados são exibidos na parte superior.
  

  Query Browser

   

• Rápida edição de registros:Essa é uma das melhores e mais originais características do MyWebSQL. Editar os registros é extremamente simples e rápido, você pode fazer isso simplesmente clicando duas vezes eles. Não há necessidade de navegar para outra página para editar um registro. Multiplas edições podem ser salvas com um simples cliques ou você pode gerar uma consulta para ser executada manualmente.
  

  Edição

   

• Editor WYSIWYG:Criar e editar tabelas é definitivamente mais agradável do que na maioria dos clientes de banco de dados que já usei. Você pode criar ou editar suas tabelas em uma grid e ele irá gerar os SQLs necessários para as alterções.
  

  WYSIWYG

   

• Sintax Highlighting:O MyWebSQL possui um ótimo Sintax Hightlighting deixando suas consultas muito mais legíveis, ao contrário da simples caixa de texto do PHPMyAdmin. e se você for programador PHP você pode escolher um editor de sua preferência e integrá-lo facilmente.
  

  Syntax Highlighting

   

• Multitarefa:Sim, o WebMySQL suporta multitasking, não há necessidade de abrir diferentes abas para verificar resultados de várias consultas. Você pode fazer tudo em uma única aba do seu browser utilizando as diversas formas de visualização disponibilizadas pelo sistema
  

  Multitarefa

   

• Import / Export & Multiplos servidores: MyWebSQL suporta importação e exportação de base de dados, tabelas e resultados DE e PARA diversos formatos. A exportação possui outra característica especial desse sistema onde você pode exportar grandes bases de dados sem ter que se preocupar com o limite de tempo (max_execution_time) do PHP, o que é um problema no PHPMyAdmin. O MyWebSQL também suporta conexões com multiplos servidores de banco de dados.

• Sessões personalizáveis: Diversas sessões podem ser escondidas ou exibidas de acordo com a necessidade do usuário. Além disso, da próxima vez em que você abrir o browser essas configurações serão preservadas.

• Ferramentas comuns / poderosas: Ferramentas comuns para o gerenciamento de bancos de dados como: Gerenciador de processos, Permissões para Users e Managers, checker/optimizer para tabelas, Database Text Search, Gerenciador de indices das tabelas, etc. Tudo isso está incluso na aplicação.

Bem, a lista acima mostra uma impressionante série de características para um Cliente Web de banco de dados. Se você não está satisfeito com o seu, sugiro verificar o MyWebSQL, ele fornece um demonstrativo on-line muito bom. Você pode enviar sugestões e relatório de erros para a equipe de desenvolvimento, eles são bastante ativos na resposta às suas perguntas.

Quando um SQL Injection ocorre, a estrutura de um comando SQL é comprometida com algum código sinistro inserido pelo usuário e como resultado você fica potencialmente a mercê dos hackers. Se há uma vulnerabilidade encontrada, os hackers podem explorar para obter acesso não só ao site e ao banco de dados como, em casos extremos, também a sua rede corporativa.

Porque SQL Injection ocorre com tanta frequência?

A resposta mais curta e simples é que programadores programam mal, muito mal. Hacker varrem a internet em busca dessas vulnerabilidades de código para fazerem um SQL Injection, infelizmente eles não precisam buscar tanto assim, as vulnerabilidades pulam na sua cara. É um tipo de vulnerabilidae em que o risco para inserção é mínimo e as recompensas são gigantes, exatamente o que qualquer racker quer.

Então, não relaxe com seu código achando que ninguém vai querer invadir seu site ou sua aplicação, existem outros interesses além de colocar seu site fora do ar ou buscar alguns dados em seu banco. Inseriri códigos maliciosos, obter acesso a rede onde está hospedado seu site, usar o espaç em disco para guardar arquivos e até mesmo usar o processamento da máquina para executar programas maliciosos.

A boa notícia é que, felismente,  SQL injection são relativamente fáceis de se evitar.

Medidas para se evitar um SQL Injection

Basicamente existem duas maneiras de se evitar  a todo custo um SQL injection:
1. Não use consultas de banco de dados dinâmicas
2. Não aceitar dados vindo dos usuários nas suas consultas

No entanto se seguirmos a risca esses dois passos nossos sites serão praticamente páginas estáticas sem nenhuma interatividade com os usuários, o que hoje na internet seria um absurdo. O que você pode fazer é minimizar os riscos ao usar consultas dinâmicas e entrada de dados do usuário. Aqui vão alguns princípios básicos que se aplicam a qualquer linguagem de programqação:

1. Corrigir o servidor de SQL regularmente.

Antes de falarmos de dicas e correções em nosso códigos existem coisas fundamentais que devem ser analisadas. SQL Injection é frequentemente resultado de uma má aplicação de código, mas não é a única maneira de ser invadido. Se você possue falhas em seu sistema operacional e servidor de banco de dados todo cuidado com o código da aplicação pode se tornar inútil. Então, sugiro que mantenha seu sistema sempre atualizado, principlamente o servidor de banco de dados.

2. Limitar o uso de consultas dinâmicas.

Como já mencionado, consultas dinâmicas são as portas de entrada para SQL Injection. Claro que temos que ser realistas e entender que não podemos descartar todas as consultas dinâmicas do sistema, mas temos algumas alternativas que podem ser utilizadas como: Stored Procedures, selects parametrizados, e acima de tudo – prepared statements. Abordagens específicas mudam de uma linguagem para outra mas qualquer linguagem de programação oferece alternativas para consultas dinâmicas.

3. Escapar entradas de dados dos usuários.

O segundo maior problema para abertura de SQL Injection são as entradas de dados por usuários. Como não podemos evitar completamente as interações com dados de usuário a melhor solução é sempre tratá-las. Escapar as entradas não é o trabalho ideal para as SQLs dinâmicas, mas é fundamental para evitar boa parte dos SQLs Injections. Por exemplo, se você estiver usando PHP, para GET e POST, use htmlspecialchars() para escapar caracteres XSS e addslashes(), no caso de você usar banco de dados. Alternativamente, você pode escapar de entrada do usuário de dentro do seu banco de dados, mas já que o códigovaria de um banco de dados para outro, você deve verificar na documentação do seu banco de dados a sintaxe exata para usar.

4. Armazenas as credenciais do banco de dados em um arquivo separado.

Pode parecer algo obvio, mas já vi diversas aplicações onde a conexão com o banco de dados era efetuada diretamente no arquivo, junto aos comandos SQL. Não vou nem entrar aqui no assunto de Design Pattens e padrão de desenvolvimento. Proteger a chave de sua casa deve ser um comportamento padrão para qualquer pessoa.

5. Use o princípio do menor privilégio.

O princípo do menor privilégio é a pedra angular  da segurança de sistemas, e isso também se aplica a SQL Injection. Se você tem a possibilidade de minimizar os privilégios do usuário do seu sistema (para apenas consultas ou para apenas algumas tabelas) faça isso, pois caso você sofra um ataque, seus danos serão minimizados.

6. Desligar o magic quotes.

Magic quotes é um recurso que o PHP “tinha” onde qualquer string passada que houvesse aspas simples ou duplas era automaticamente escapadas com uma barra invertida. Isso parece ser uma grande solução, mas o problema é que vários sistemas e frameworks já fazem esse tratamento sendo preciso desligar essa opção no servidor. Sem falar que essa opção pode ser desligada sem que você saiba deixando seu sistema vulnerável.

Na versão 5.3 do PHP esse é um recurso em “deprecated” e será removido no PHP 6.0

7. Desativar acesso a shell.

Vários bancos de dados dão acesso ao Shell, ou seja, se um hacker conseguir por SQL Injection as credenciais do seu banco e esse recurso estiver ativado ele poderá acessar via terminal todos os recursos do seu banco de dados. Então, leia a documentação do seu banco de dados e desabilite o acesso externo ao seu banco. Ensine a ele igual sua mãe fez: “Menino, não converse com estranhos”.

8. Desativar qualquer funcionalidade do banco que você não precisa

Há diversos recursos que um SGDB lhe oferece além de acesso ao Shell. A regra aqui é quanto menos melhor. Embora nem todos sejam um risco de segurança é melhor remover todos os recursos que você não utiliza, além de diminuir o risco de segurança, isso pode lhe proporcionar um melhor desempenho.

9. Teste seu código

Esse é um dos pontos fundamentais e mais negligenciados pela maioria dos programadores. Exixtem ferramentas para automatizar esse processo, acho que uma das mais conhecidas é a extensão do Firefox SQL Inject me. Essa ferramenta tem muitas opções e muitos testes, o melhor seria se tivessemos tempo para executar todas eles.

Todos esses passos são bem fáceis de se implementar, mas não fazê-los pode fazer uma enorme diferença. Se ater a essas regras fará você diminuir drasticamente o risco que seu site sofre sobre SQL Injections. Ainda assim, você nunca pode estar 100 por cento certo de que estará completamente protegido contra esse tipo de ataque (ou qualquer outro tipo de ataque, para ser mais preciso) e é por isso que você precisa manter o olho em seus logs, se uma violação ocorrer , você vai saber imediatamente e reagir adequadamente para minimizar os danos.

Fonte: developerdrive

Analista Programador em Plataforma Magento

- Desenvolverá funcionalidades na plataforma Magento;

Conhecimento exigidos:
- Integração com Magento e-Commerce
- Experiência em programação PHP5
- Bom entendimento de Design Patterns
- Experiência com desenvolvimento de Software: concepção, implementação de testes unitários e implantação em produção
- Controle de versão utilizando SVN, Git ou CVS
- Conhecimentos avançados de XHTML/CSS/Javascript/Ajax
- Detalhista, com excelente organização e habilidades de autogestão
- Capacidade de escrever especificações de projeto e documentação

Benefícios:
- Vale Refeição de R$ 440,00
- Vale Alimentação de R$ 150,00
- Vale Transporte, Estacionamento ou Ônibus Fretado.
- Assistência Médica – SulAmérica, sem carência.
- Assistência Odontológica – Amil Odonto, sem descontos e sem carência.
- Seguro de Vida Metlife.
- Cursos da Área de Atuação;
- Curso de idiomas;
- Participação nos Lucros;
- Auxílio Creche
- Frutas no Café da Manhã;
- Quick Massage;
- Lounge com Pebolim, Air Rock ,Wii.
- Yoga;

Enviar e-mail com CV para fabia.souza@buscape-inc.com

O problema é que nossos olhos nem sempre estão prontos para executar a atividade em frente ao computador. Pela manhã, quando acordamos, ou no cu da madrugada altas horas da noite nossa pupila está bem mais dilatada que ao meio dia ou no fim da tarde.

O f.lux é um programa que ajusta a instensidade e temperatura da luz do seu monitor de acordo com a hora do dia, fazendo você ter a impressão de que a luz do monitor segue a luz ambiente. Já estou usando faz umas duas semanas e notei uma grande melhoria no aproveitamento do meu tempo em frente ao computador.

O melhor, é que esse bicho roda em PC, Mac, Linux e em IOs com Cydia. Vale a pena testar.

f.lux

Se você precisa migrar sua instalação do Magento, o que acontece requentemente com quem está desenvolvendo, deve se atendar em modificar as URLs bases do Magento, que estão guardadas em seu banco de dados, abaixo segue um passo a passo para isso.

O Magento possui duas configurações de URL: uma “unsecure” e outra “secure”. Ambas são definidas no momento da instalação e podem ser modificadas no próprio painel administador. O problema é que, quando mudamos o diretório no qual o Magento foi instalado, modificando assim a URL, nada funciona como deve. Isso porque os caminhos para todas as imagens, arquivos css, javascript, etc. ficarão setados de forma errada.

Corrigir esse problema é bem simples – há inclusive duas maneiras de se resolver rapidamente. A primeira maneira, que vejo como mais simples, é acessar o banco de dados da sua aplicação e modificar direto as URLs nos campos“web/unsecure/base_url” e “web/secure/base_url”, que ficam na tabela “core_config_data”. Depois disso, basta apagar todo o conteúdo da pasta /var/cache e… voila!.

Há uma segunda maneira; essa não é necessário mexer no banco de dados. Simplesmente modifique o nome do arquivo /app/etc/local.xml. Ao fazer isso, abra o Magento no browser e veja que ele já irá rodar o instalador. Não se desespere! Continue a instalação como se fosse um Magento novo, modificando apenas os dados da base_url. E quando a instalação terminar, o Magento funcionará perfeitamente, já com todas as configurações efetuadas no antigo endereço.

*Magento: software open source de gerenciamento de e-commerce.