Vários Snippets htacces para você!

Olá, hoje estou trazendo alguns snippets(pedaços de código) para htacces, neles estão incluídos pedaços de código para cache, gzip, redirecionamentos e etc.

Performance com htacces

# Disabilitar ETAGS
<FilesMatch "\\.(ico|pdf|flv|jpe?g?|png|gif|js|css|swf|txt|mp3|avi|mpe?g?|wmv)$">
 FileETag none
</FilesMatch>

# Compressão de arquivos
<IfModule mod_deflate.c>
 AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript
 BrowserMatch ^Mozilla/4 gzip-only-text/html
 BrowserMatch ^Mozilla/4\.0[678] no-gzip
 BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>

Snippets canonicos

# CANONICAL ROBOTS.TXT
<IfModule mod_alias.c>
 RedirectMatch 301 ^/(.*)/robots\.txt http://seusite.com/robots.txt
</IfModule>

# CANONICAL SITEMAP
<IfModule mod_alias.c>
 RedirectMatch 301 /sitemap\.xml$ http://seusite.com/sitemap-press.xml
 RedirectMatch 301 /sitemap\.xml\.gz$ http://seusite.com/sitemap-press.xml.gz
</IfModule>

# MULTIPLE SITEMAPS
<IfModule mod_rewrite.c>
 RewriteBase /
 RewriteCond %{REQUEST_URI} !^/sitemap\-(categoria1|categoria2)\.xml(.gz)?$ [NC]
 RewriteRule /sitemap\-(.*)?\.?(.*)?(.*)? http://seusite.com/sitemap-$1.$2$3 [R=301,L]
</IfModule>

# CANONICAL XMLRPC
<IfModule mod_alias.c>
 RedirectMatch 301 /press/(.*)/xmlrpc\.php$ http://seusite.com/xmlrpc.php
</IfModule>

# FORCE TRAILING SLASH
<IfModule mod_rewrite.c>
 RewriteCond %{REQUEST_URI} /+[^\.]+$
 RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]
</IfModule>

# ROOT CANONICALIZATION
<IfModule mod_rewrite.c>
 RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php [NC]
 RewriteRule ^index\.php$ http://seusite.com/ [R=301,L]
 RewriteCond %{HTTP_HOST} ^www\.seusite\.com$ [NC]
 RewriteRule (.*) http://seusite.com/$1 [R=301,L]
</IfModule>

# CANONICALIZATION
<IfModule mod_alias.c>
 # REMOVE INTITIAL INDEX.PHP
 RedirectMatch 301 index.php/(.*) http://seusite.com/press/$1
</IfModule>
<IfModule mod_rewrite.c>
 # REMOVE ADDITIONAL INDEX.PHP
 RewriteBase /press/
 RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /([^/]+/)*index\.(html|php)\ HTTP/
 RewriteRule ^(([^/]+/)*)index\.(html|php)$ http://seusite.com/press/$1 [R=301,L]
 # FORCE TRAILING SLASH
 RewriteCond %{REQUEST_URI} /+[^\.]+$
 RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]
</IfModule>

# REDIRECT PAGE QUERIES
<IfModule mod_rewrite.c>
 RewriteCond %{REQUEST_URI} !seusite.com [NC]
 RewriteCond %{REQUEST_URI} !^/$ [NC]
 RewriteCond %{QUERY_STRING} ^p\= [NC]
 RewriteRule (.*) http://seusite.com/? [R=301,L]
</IfModule>

 # REDIRECT SUBDIRECTORIES
<IfModule mod_rewrite.c>
 RewriteBase /
 RewriteCond %{REQUEST_URI} ^/(dir1|dir2)/?$
 RewriteRule .* http://seusite.com/ [R=301,L]
</IfModule>

# CLEAN EXTERNAL LINKS
<IfModule mod_rewrite.c>
 RewriteBase /
 RewriteCond %{QUERY_STRING} scamdex [NC]
 RewriteRule .* http://seusite.com/$1? [R=301,L]
</IfModule>

Snippets de segurança

# HOTLINK PROTECTION
<IfModule mod_rewrite.c>
 RewriteCond %{HTTP_REFERER} !^$
 RewriteCond %{REQUEST_FILENAME} -f
 RewriteCond %{REQUEST_FILENAME} \.(gif|jpe?g?|png)$ [NC]
 RewriteCond %{REQUEST_FILENAME} !/hotlink\-(01|02).gif$ [NC]
 RewriteCond %{HTTP_REFERER} !^https?://([^.]+\.)?seusite\. [NC]
 # RewriteRule \.(gif|jpe?g?|png)$ - [F,NC,L]
 RewriteRule \.(gif|jpe?g?|png)$ http://seusite.com/wordpress/hotlink-02.gif [R,NC,L]
</IfModule>

# BLOCK EVIL REQUESTS
<IfModule mod_rewrite.c>
 Options +FollowSymLinks
 RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
 RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
 RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
 RewriteRule .* blacklist.php [F,L]
</IfModule>

# BLOCK SCUM REFERRERS
<IfModule mod_rewrite.c>
 RewriteCond %{HTTP_REFERER} (.*)secondchanceranch(.*) [NC]
 RewriteRule .* - [F,L]
</IfModule>

# DENY ACCESS TO NO-REFERRER REQUESTS
<IfModule mod_rewrite.c>
 RewriteCond %{REQUEST_METHOD} POST
 RewriteCond %{REQUEST_URI} .wp-comments-post\.
 RewriteCond %{HTTP_REFERER} !.*seusite\. [OR,NC]
 RewriteCond %{HTTP_USER_AGENT} ^$
 RewriteRule .* - [F,L]
</IfModule>

# REDIRECT URL (fafich.ufmg.br)
<IfModule mod_rewrite.c>
 RewriteCond %{REQUEST_FILENAME} .*
 RewriteCond %{HTTP_REFERER} ^https?://([^.]+\.)?ufmg\. [NC]
 RewriteRule .* - [F,L]
</IfModule>

Fonte: http://perishablepress.com/code-snippets/

Veja! 40 Tutoriais para construir ótimos aplicativos em CodeIgniter

Pra compensar um pouco a falta de posts no blog, desta vez irei apenas repassar um link com 40 tutoriais para criar aplicativos em CodeIgniter!

40 Tutoriais CodeIgniter

O motivo da falta de posts na verdade é a falta de tempo (leia-se World of Warcraft)! Fim de ano é uma correria danada, mas em breve mais posts!

O futuro do CodeIgniter

CodeIgniter

No último mês, muito se falou sobre o abandono do CodeIgniter por parte da EllisLab, empresa mantedora do CodeIgniter que o usa em seus 2 principais produtos, O CMS ExpressionEngine, e o MojoMotor. Estava-se falando que a mesma só pensava nos produtos dela e não estava nem ai pra comunidade, e realmente parece verdade.

O CodeIgniter não recebe uma boa atualização a tempos, ainda está faltando coisas básicas que encontramos em outros frameworks, como integração nativa a testes unitários, ORM, ACL, e etc.

Realmente, o CI pode não ser o mais robusto, mais completo dos frameworks, porém é leve, rápido e possui uma ótima comunidade. A EllisLab sabendo disso logo agiu, resolveu então criar o CodeIgniter Reactor, um branch do CI mantido por 6 “CodeIgniter Engineers” como eles estão chamando estes branches da comunidade, esses “CodeIgniter Engineers” serão responsáveis por atender a comunidade e fazer as mudanças que acharem necessárias para o CodeIgniter se manter vivo e atualizado, enquanto o branch oficial continuará sendo mantido pela EllisLab porém com menos frequência e mais testes, pois o mesmo é usado pelos seus produtos.

Mas a pergunta que fica é afinal, isto é bom ou ruim?
Ao meu ver, isso é muito bom pois esses “CodeIgniter Engineers” não só contribuirão com o código do CodeIgniter como irão verificar códigos da comunidade, inclusive já estão planejando um clone para o GIT para que as pessoas que não conhecem/gostam do mercury poderem contribuir para o CI.

Eu mesmo penso em usar o “CodeIgniter Reactor” que eu acredito que será atualizado mais frequentemente, e mais utilizado o que acarretará em mais recursos e correção de bugs. Porém os proprios “CodeIgniter Engineers” já avisaram que não irão fazer coisas mirabolantes, como implantar um ORM de cara ou algo do tipo, eles irão seguir a tendência, pois o CodeIgniter já é famoso pelo fato de se você precisa de algo é so instalar, ou seja, não tem ORM? Utilize o Datamapper ou o Doctrine, não tem Unit Testing? É fácil implementar o PHPUnit ou algo do tipo.

Além disso a própria EllisLab já tomou algumas decisões em relação ao CI 2.0 por exemplo, o suporte ao PHP4 finalmente foi totalmente excluído, agora os controllers e models são extendidos pela seguintes classes, CI_Controller e CI_Model, todos construtores de classes foram renomeados para __construct, seguindo o padrão do PHP5.

Conclusão

Acredito que com o CodeIgniter Reactor, o CodeIgniter só tem a ganhar! Só espero que os Engineer’s como estão sendo chamados levem com seriedade essa estória de serem os responsáveis pela comunidade, pois eles terão grande parte no futuro direto e indireto do CodeIgniter, enquanto a EllisLab deverá atualizar somente o que for necessário para seus produtos, o Reactor deverá receber o que é necessário para comunidade, independente de um produto ou não.

Mais informações: http://codeigniter.com/news/codeigniter_in_2011_reactor_core_uservoice/
http://philsturgeon.co.uk/blog/2010/12/ellislab-react-with-codeigniter-reactor