Estrutura de diretórios: organização de pastas do CodeIgniter 1.7.2
16 de novembro de 2009, em Passos Iniciais, por Tárcio Zemel

Estrutura de diretórios do CodeIgniter
Não dá pra trabalhar com o CodeIgniter sem conhecer sua estrutura de diretórios. É conhecendo como é a organização das pastas no CodeIgniter e sabendo sua função dentro do “todo” do framework que é possível mexer no CI com eficiência e consciência – também é importantíssimo conhecer o Fluxograma de Dados do CodeIgniter (se ainda não leu o artigo, leia antes de continuar).
Com um pouco mais de experiência é possível alterar a estrutura de diretórios do CodeIgniter, mas, para fins didáticos, será mostrada no tutorial a estrutura padrão de pastas do CI – dentro do momento histórico da atual versão do framework, CodeIgniter 1.7.2.
Não serão detalhadas as funções/possibilidades completas de cada pasta e seus respectivos arquivos; isso será feito, com o tempo, na medida em que novos artigos são publicados no blog. Portanto, não é preciso ficar frustrado caso encontre termos que ainda desconhece; assine o feed do CodeIgniter Brasil para não perder as atualizações. ;-)
Visão geral da estrutura de pastas do CodeIgniter
Como pode ser visto na imagem da estrutura de pastas acima, na raiz da estrutura do CodeIgniter existem 2 diretórios e 2 arquivos.
Diretórios
Os 2 diretórios existentes na raiz da estrutura do CodeIgniter são:
- system. Local onde os códigos das aplicações/softwares desenvolvidos ficam.
- user_guide. Contém o Guia do Usuário (User Guide) do CodeIgniter (cópia da documentação online).
Arquivos
Juntamente com os diretórios supracitados, na raiz do esquema de diretórios do CodeIgniter existem 2 arquivos:
- index.php. Primordial para o funcionamento do CI, contém informações para se alterar o nível de error reporting que se vai trabalhar; opcionalmente, também é possível alterar os nomes padrão da pasta “system” e “application” (mais a respeito: Instalação e configuração inicial do CodeIgniter).
- licente.txt. É o arquivo com a licença do CI que, como já foi tratado no artigo sobre requisitos de servidor e licença de uso, deve constar em todo software/aplicativo feito em CodeIgniter.
system
Na pasta system toda a “ação” do CI acontece. Para organizar a estrutura presente, há subpastas para segmentar e organizar os arquivos e fluxo de trabalho.
- application. Pasta onde os arquivos do aplicativo desenvolvido ficam. Praticamente toda a codificação em CI fica nesta pasta, que abriga seus models, views, controllers e outros que ainda serão tratados no blog.
- cache. No CodeIgniter existem maneiras de trabalhar com cache para servir aplicativos mais rápidos e robustos para quem os utilizam. É nesta pasta que arquivos condizentes ao cache feito são armazenados.
- codeigniter. Os arquivos de core ficam aqui. É nesta pasta que está o “coração” do CodeIgniter. Raramente é preciso mexer em algo nesta pasta, já que todo o desenvolvimento do software se dá na pasta “application”.
- database. Contém os core files (drivers e outras coisas) para trabalhar com bancos de dados. Assim como a pasta “codeigniter”, raramente será preciso mexer nela.
- fonts. Basicamente, esta pasta é para armazenar as fontes que podem ser usadas pela biblioteca de manipulação de imagens (que também será vista em outro momento aqui no CodeIgniter Brasil).
- helpers. Pasta que contém os helpers nativos do Code Igniter (para mexer com arrays, cookies, diretórios, e-mails, formulários e muitos outros).
- language. Contém arquivos de idioma (que são usados principalmente para mensagens das libraries e helpers).
- libraries. Pasta de armazenagem das libraries (bibliotecas) padrão do CI para códigos envolvendo e-mails, calendários, upload de arquivos e mais.
- logs. Como sugere o nome, esta pasta armazena todos os logs gerados pelo CodeIgniter.
- plugins. Contém os plugins default do CodeIgniter. Veremos com mais detalhes futuramente, mas a diferença básica entre helpers e plugins é que os plugins possuem somente 1 função (e geralmente são feitos com intenção de serem compartilhados com a comunidade CI).
- scaffolding. Contém os arquivos necessários para se trabalhar com scaffolding no CodeIgniter. Se ainda não sabe o que é isso, não se preocupe, ainda vamos abordar o scaffolding (e, temos certeza, você vai se surpreender).
system/application
Sem dúvidas, a pasta system/application é a mais importante para o desenvolvimento dos aplicativos e é a que mais vai exigir sua atenção/codificação. Já que a maior parte do seu trabalho vai ser aqui, é importante conhecer bem a estrutura de subdiretórios da pasta “application”:
- config. Contém diversos (e importantes) arquivos relacionados a configurações de seu CI. São arquivos de configuração de database, variáveis sobre URL, quais libraries e helpers serão carregados automaticamente e muitas outras coisas.
- controllers. Armazena os controllers que você cria para o seu software.
- errors. Vem com os templates de páginas de erros do CodeIgniter (erros genéricos, 404, conexão ao banco de dados, etc). É conveniente que tudo isso seja alterado para que os erros do aplicativo fiquem personalizados e consonantes com a finalidade deste.
- helpers. Para armazenar todos os helpers que você venha a criar/aprimorar.
- hooks. Para colocar os hooks que você cria. Em artigos futuros será mostrado que hooks são a maneira mais rápida e segura de você extender o core do CodeIgniter (geralmente feito por usuários avançados).
- language. Para aplicativos multi-idioma, esta pasta é bem usada por armazenar as mensagens nas diferentes escritas.
- libraries. Aqui ficam as libraries personalizadas, com funcionalidades para o programa a ser criado. Perceba que há diferença entre as pastas system/libraries e system/application/libraries.
- models. Armazena os models que você cria para seu aplicativo.
- views. Armazena os views que você cria para seu programa.
1 2 3 | RewriteEngine on RewriteCond $1 !^(index\.php|img|css|js) RewriteRule ^(.*)$ index.php/$1 [L] |
Basicamente as instruções fazem com que o CI reconheça as pastas “img”, “css”, “js” e, de quebra, ainda retiram “index.php” do URL (algo que será explicado em um momento mais oportuno).
O importante é a função de cada pasta
Principalmente quando se está começando, é bastante comum ficar em dúvida sobre a função de cada diretório e ter receio de criar arquivos no lugar errado. Estudando a estrutura de pastas do CodeIgniter, certamente esse não será um problema que irá travar seu processo de desenvolvimento.
O CodeIgniter foi projetado para manter seguros seus arquivos de core e é por uma razão que existe uma pasta específica para você criar os arquivos de seu software. Você deve concentrar seus arquivos em system/application, criando arquivos nos diretórios adequados – conforme foi abordado neste artigo – e somente criar/alterar arquivos de outras pastas caso você saiba exatamente o que está fazendo (e tenha um bom motivo pra isso).
6 comentários em "Estrutura de diretórios: organização de pastas do CodeIgniter 1.7.2"
Tárcio Zemel em 22 de novembro de 2009
@Fernando
Obrigado! Por enquanto estamos com o basicão do CodeIgniter, mas, em breve, vamos começar a abordar cada assunto mais detalhadamente, inclusive os hooks. Fique ligado para não perder! ;-)
Abraços!
Marcelo Diniz em 1 de fevereiro de 2010
Eu só não entendi muito bem uma coisa, vc diz para criar o arquivo .htaccess que eu imagino que fica na raiz do CI, junto com os dois diretórios (system e user_guide) e os dois arquivos (index.php, licente.txt).
Mas as pastas de css, img, js etc ficariam dentro da pasta system ou system/application?
Obrigado
Tárcio Zemel em 2 de fevereiro de 2010
@ Marcelo Diniz
Segundo essa técnica, tudo deve ficar na raiz, na pasta principal – não necessariamente "system", pois é possível alterar esse nome nas configurações.
- Controllers no CodeIgniter | CodeIgniter Brasil em 1 de fevereiro de 2010
- Diferença entre helper, library e plugin no CodeIgniter | Power Php em 19 de abril de 2011


Fernando em 16 de novembro de 2009
Achei interessante a abordagem da pasta “hooks”. Em alguns artigos no meu blog fiz algumas alterações/extensões diretamente no core do framework, principalmente por desconhecer o conceito dos hooks. Vou me aprofundar nisso, muito bom seu artigo! :)