[Symfony] Alterando o diretório padrão

O Symfony é indicado para o desenvolvimento de aplicações onde o principal recurso é o próprio framework, pois exige que quase todas as suas pastas estejam abaixo do diretório public_html ou www.

Entretanto quando temos já alguma aplicação rodando na raiz, pode se tornar confuso misturar as pastas das aplicações ou caso já tenha alguma aplicação rodando em outra versão de symfony se tornará impossível a coexistência.

Colocar a aplicação inteira dentro da pasta public também não é uma opção, pois os arquivos de configuração com as senhas do banco de dados ficariam expostos.

Pensando nisso, pesquisei como é possível alterar a estrutura de diretórios para organizar melhor as aplicações.

Com base na nova versão 3 do Symfony temos a seguinte estrutura

[ftp root]
+- app
+- bin
+- src
+- tests
+- var
+- vendor
+- web (public_html/www)

Se a aplicação for instalada diretamente no servidor, basta inserir o conteúdo da pasta web na pasta pública do host e as demais no mesmo nível

Para o nosso caso eu alterei para a seguinte forma

[ftp root]
+- symfony3
+--- /app
+--- /bin
+--- /src
+--- /tests
+--- /var
+--- /vendor
+- public_html
+--- minha-aplicacao (antiga pasta web)

Para que o serviço reconheça é preciso alterar os paths dos arquivos app.php e app_dev.php que estão dentro da pasta minha-aplicacao

$loader = require __DIR__.'/../../symfony3/app/autoload.php';

// esta linha existe somente no arquivo app.php
include_once __DIR__.'/../../symfony3/var/bootstrap.php.cache';

E alterar no composer.json a linha referente à antiga pasta web

[...] 
"symfony-web-dir": "../public_html/minha-aplicacao",
[...]

Até este ponto é possível encontrar na documentação do symfony em http://symfony.com/doc/current/configuration/override_dir_structure.html mas o que não está na documentação e que atrapalha o processo são os seguintes passos necessários:

Para testar no server local

  1. Atualize as dependências do composer
    composer update
  2. Não utilize o php built in server utilize o server do symfony, afinal é nele que você está desenvolvendo.
  3. Acrescente o argumento  –docroot=../public_html/minhaaplicacao/ (Esse endereço é com base na pasta bin da estrutura)
  4. php bin/console server:run  --docroot=../public_html/minhaaplicacao

Para upload no servidor:

  1. Atualize as dependências do composer
  2. composer update
  3. LIMPE O CACHE!
    $ php bin/console cache:clear --env=prod --no-debug
  4. Faça o upload.

 

Projeto base em Zend Framework 2

Estrutura

Clone a estrutura básica (o esqueleto) utilizando GIT

git clone https://github.com/zendframework/ZendSkeletonApplication.git

Atualize com o composer

composer self-update
composer install

Para que o Zend funcione a partir da pasta raiz da aplicação, copie tudo que está em public para a raiz e comente no index.php a linha com a instrução

//chdir(dirname(__DIR__));

Banco de Dados

Na pasta config/ renomeie o arquivo local.php.dist para local.php

Em global.php adicione os serviços

return array(
     'db' => array(
         'driver'         => 'Pdo',
         'dsn'            => 'mysql:dbname=database;host=localhost',
         'driver_options' => array(
             PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES 'UTF8''
         ),
         'username' => 'user',
         'password' => 'password',
     ),
     'service_manager' => array(
         'factories' => array(
             'ZendDbAdapterAdapter' => 'ZendDbAdapterAdapterServiceFactory',
         ),
     ),
 );

E em local.php coloque o login e senha do banco de dados local

return array(
     'db' => array(
         'username' => 'user',
         'password' => 'pass',
     ),
 );

Perda de Sessão no Internet Explorer

Desenvolvi uma aplicação que ao ser exibida via iframe perdia todas as sessões do PHP.

Pesquisei exaustivamente sobre o assunto, pensando que o problema estava no meu código, até que finalmente encontrei a explicação no site https://poliglotabinario.wordpress.com/2010/08/27/problema-com-session-em-frame-iframe-no-internet-explorer/

Trata-se de um problema com a diretiva de segurança do IEca e se tiver interesse, poderá se aprofundar no link acima, mas para adiantar, a solução encontrada pelo Adler Parnas foi utilizar este trecho de código nas páginas que serão exibidas (não no iframe).

<?php
header('P3P: CP="IDC DSP COR CURa ADM ADMa DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT PHY ONL COM STA"');
?>

 

Linha de comando com proxy

Para poder utilizar a linha de comando em uma rede que necessita de autenticação via proxy, você deve configurar as variáveis de ambiente do sistema.

  1. Vá em Painel de Controle / Sistema e Segurança / Sistema e clique em Configurações Avançadas do Sistema.
  2. Clique no botão “Variáveis de Ambiente”
  3. E na parte inferior, onde temos variáveis do sistema, crie uma entrada nova
  4. Nome da Variável: http_proxy
  5. Para o valor da variável, você deve utilizar um dos seguintes modelos:
    • Proxy sem login e senha: http://proxy.com.br:porta
    • Proxy com login e senha: http://login:senha@proxy.com.br:porta

Para https, execute o mesmo procedimento substituindo http por https.

Tive problemas com a utilização de caracteres especiais no login ou na senha, as sugestões que encontrei foi para substituir por exemplo “@” por “%40” mas não houve sucesso.

Para utilizar a linha de comando você deve digitar

set http_proxy=http://your_proxy:your_port
set http_proxy=http://username:password@your_proxy:your_port
set https_proxy=https://your_proxy:your_port
set https_proxy=https://username:password@your_proxy:your_port

Comandos de terminal que facilitam o trabalho via SSH

Quando se trabalha via SSH e você é o responsável por administrar a hospedagem, se faz necessário conhecer bem o Sistema Operacional afim de configurar corretamente os serviços.

Alguns comandos são imprescindíveis para manter o sistema atualizado e promover melhorias. Os comandos a seguir são baseados em Debian v.7.x

# Atualizar o SO
$ apt-get update
$ apt-get upgrade

# Instalar / remover pacotes
$ apt-get install nome_do_pacote
$ apt-get remove nome_do_pacote
$ apt-get remove --purge nome_do_pacote # remove e limpa
$ apt-get autoremove # limpa dependencias de pacote

# Verificar pacotes instalados
$ dpkg #lista todos os pacotes 
$ dpkg -l php* # lista os pacotes que iniciam com php

# Descompactar arquivo .tar.gz
$ tar xvf arquivo.tar.gz

# Montar arquivo ISO
$ sudo mount -t iso9660 -o loop /caminho/para/o/seu/arquivo.iso /media/cdrom/

A lista ainda é muito maior e conforme a necessidade irei atualizando, mas para o problema pontual de configurar a VM com os pacotes necessários para o seu trabalho, já é suficiente.

 

 

Testando o desempenho do servidor com ApacheBench – Benchmarking

Quando se produz uma aplicação/site e se iniciam os testes locais, normalmente tudo corre bem, pois somente uma pessoa está utilizando, a conexão local é rápida, você segue o roteiro que foi concebido como o roteiro lógico da sua aplicação e tudo dá certo.

Você então decide publicar e desencadeia uma série de reclamações com erros nunca vistos antes.

Tirando o fator “usuário” que é o mais recorrente para se quebrar uma aplicação, você talvez não contasse com o fator “servidor” onde sua hospedagem não consegue aguentar a quantidade de acessos e requisições e começa a quebrar sua página com diversos erros como timeout da aplicação, negação de serviço e até os erros 404 e 500.

Como esse problema é relacionado ao hardware e otimização do sistema, nem sempre é possível garantir os 100% de uptime do servidor, mas em muitos casos é possível detectar possíveis falhas antes de laçar o sistema.

Existem diversas soluções disponíveis no mercado, de acordo com o tipo de servidor usado. Neste post estou tratando somente do Apache.

Acesse o terminal via SSH e utilize o seguinte comando

ab -n 1000 -c 10 http://www.seusite.com.br/index.php

Nessa linha temos:

  • ab: nome do comando
  • n: número de requisições
  • c: requisições concorrentes

Para este exemplo pedimos para que sejam efetuadas 1000 requisições ao servidor sendo 10 ao mesmo tempo. Este é um exemplo mínimo, acesse o manual do apache para conhecer as outras opções de verificação.

O relatório exibido deve ser avaliado para que você saiba se a sua aplicação vai aguentar a quantidade de acessos. É com base nesse resultado que é possível até evitar um ataque DDos

Para mais informações acesse http://www.vivaolinux.com.br/artigo/Testes-de-stress-no-Apache-com-o-comando-ab

Problemas com o envio de email pelo plugin Contact Form 7

Em algumas hospedagens, após algumas atualizações o plugin Contact Form 7 parou de funcionar corretamente, enviando os emails como deveria ser. Aparentemente se deve a um bloqueio a função mail() do PHP nessas hospedagens.

A forma que encontrei para continuar enviando emails por meio deste plugin foi adicionando mais um plugin à hospedagem. O WP-Mail-SMTP (http://wordpress.org/plugins/wp-mail-smtp/). Existe um aviso que o plugin não é atualizado a mais de dois anos, mas continua funcionando.

A instalação é simples como qualquer plugin wordpress, após a instalação basta configurar com os dados de smtp do seu domínio, os mesmos usados quando você configura sua conta de email em um aplicativo como o mail, outlook, entourage, etc.

É possível testar na própria página de configuração.

Se conhecer algum plugin mais atual qie p WP-Mail-SMTP ou algum que seja melhor que o Contact Form 7, mande sua sugestão!

Importar base de dados MySQL em localhost

O modo mais fácil de importar um arquivo .sql para o seu banco de dados sempre foi via PHPMyAdmin, entretanto com arquivos pesados sempre encontramos erros ou temos que subdividir os arquivos em importações menores, o que também gera problemas pois algumas tabelas que contém dependências ou chaves estrangeiras acusam diversos erros na importação.

Um modo mais simples que descobri recentemente é a partir de um comando muito simples no terminal mysql.

Pegue o seu arquivo .sql e salve em alguma pasta como desktop por exemplo, mas grave bem o caminho.

Acesse via terminal o seu banco de dados MySQL

mysql -u***** -p;

Crie o banco de dados que você importará o arquivo .sql

mysql > create database exemplo_xpto;

Abra a base de dados

mysql > use exemplo_xpto;

Faça a importação por meio do comando:

mysql > source /Users/meu-usuario/Desktop/arquivo.sql

Lembrando que o endereço /Users[…]/arquivo.sql deve ser substituído pelo caminho no seu computador.

Pronto, verifique se não houve nenhum erro e a sua base já está completamente funcional.

Caso você use o XAMPP, eu li algumas observações dizendo que o seu arquivo tem que obrigatoriamente estar na pasta bin, dentro da pasta XAMPP, mas isso eu não testei.

Esse exemplo serve para importações locais. Para fazer o caminho inverso continue usando os comandos já conhecidos:

#Exportar
mysqldump -u**** -p**** nomedobanco > nomedobanco.sql

#Exportar o banco com bzip2
mysqldump -u**** -p**** nomedobanco | bzip2 > nomedobanco.sql.bz2

#Exportar o banco com gzip
mysqldump -u**** -p**** nomedobanco | gzip > nomedobanco.sql.gz

#Importar  (.sql)
mysql -u**** -p**** nomedobanco < nomedobanco.sql

 Referência

http://www.alexweber.com.br/artigos/mysql-como-exportar-importar-backups-pelo-terminal

Erro [SymfonyComponentProcessExceptionRuntimeException] The process timed-out.

Após atualizar o Zend Framework 2.x e pedir update via composer.phar, eventualmente me deparava com a mensagem:

[SymfonyComponentProcessExceptionRuntimeException] 
 The process timed-out.

A culpa desse erro normalmente é relacionada à sua velocidade de conexão, mas eu acredito que tem mais relação com a disponibilidade do serviço, pois mesmo em uma conexão de 10MB em um domingo eu tive esse problema.

A forma mais fácil que encontrei é aumentando o timeout utilizando o seguinte comando:

COMPOSER_PROCESS_TIMEOUT=4000 php composer.phar update