Como atualizar o CodeIgniter 2.2.x para o 3.0.0
Vamos ver neste post como como atualizar o CodeIgniter 2.2.x para o 3.0.0. Atualmente a última versão estável disponível para download.
Devo lembrar que não cheguei a testar este procedimento, estou me baseando na documentação que o próprio CodeIgniter fornece.
Não se assuste, realmente são vários passos a serem feitos, pois muitas funções foram retiradas ou alteradas. Por isso, pelo menos dê uma olhada rápido pelo texto abaixo para tentar identificar se você precisa ou não alterar algo em seu sistema antigo.
Passo 1: Atualize seus arquivos do CodeIgniter
Atualize todos os arquivos e diretórios da sua pasta system e substitua seu arquivo index.php. Se você fez alguma alteração no seu arquivo index.php você deverá fazê-las novamente na versão nova.
Nota: se você tiver algum arquivo ou pasta criados por você dentro da estrutura do CodeIgniter, você deverá fazer uma cópia deles antes.
Passo 2: Atualize os nomes dos seus arquivos de classe.
Na versão 3.0 do CodeIgniter, todos os arquivos de classe (bibliotecas, drivers, controllers e models) devem ser nomeados seguindo a maneira Ucfirst, ou seja, eles devem começar com a primeira letra em maiúscula.
Por exemplo, se você tiver uma biblioteca assim:
application/libraries/mylibrary.php
então, você deverá renomeá-la para:
application/libraries/Mylibrary.php.
O mesmo vale para a arquivos de drivers e extensões que sobrescrevem as bibliotecas do core do CodeIgniter.
Exemplo:
application/libraries/MY_email, application/core/MY_log.PHP
Os arquivos acima deve ser respectivamente renomeados para:
application/libraries/MY_Email.php, application/core/MY_Log.php.
Controllers
application/controllers/welcome para application/controllers/Welcome.php
Models
application/models/misc_model.php para application/models/Misc_model.php
Atenção! Perceba que isto não afeta os diretórios, arquivos de configuração, views, helpers, hooks e qualquer outra coisa. Esta regra só é aplicada para as classes.
Passo 3: Substitua o arquivo config/mimes.php
Este arquivo de configuração foi atualizado e contém agora mais mime-types.
Passo 4: Remova o $autoload[‘core’] do seu arquivo config/autoload.php
O uso do array de configuração $autoload[‘core’] foi descontinuado desde o CodeIgniter 1.4.1 e agora na versão 3.0 foi totalmente removido.
Mova qualquer entrada que você tiver aqui para $autoload[‘libraries’].
Passo 5: Mova suas classes de Log ou extensions que substituem as do CodeIgniter.
A classe de Log é considerada agora parte do core do sistema e por isso está localizada no diretório system/core. Portanto para que suas classes de log possam realmente sobrescrever as do sistema, você precisa movê-las para application/core.
application/libraries/Log.php -> application/core/Log.php application/libraries/MY_Log.php -> application/core/MY_Log.php
Passo 6: Atualize o uso da biblioteca Session
A biblioteca Session foi totalmente reescrita no CodeIgniter 3 e agora vem com várias novas características, o que também significa que você precisará fazer algumas alterações.
Uma alteração importante é que agora a Classe Session utiliza os próprios mecanismos do PHP para gerenciar sessões personalizadas, o que significa que os dados da sua sessão são agora acessíveis através da variável superglobal $_SESSION, no entanto, mantivemos a possibilidade de você usar userdata como você tem feito até agora.
Algumas opções de configuração foram removidas e algumas outras inseridas. É altamente recomendável que você leia o manual da biblioteca Session para maiores detalhes, mas aqui vai uma pequena lista das alterações.
- Você pode escolher o driver de sessão que irá utilizar através de: $config[‘sess_driver’]
Por padrão, ‘files’ será utilizado, a menos que você já esteja usando a opção database em $config[‘sess_use_database’] - Informe um valor personalizado em $config[‘sess_save_path’].
Para o driver ‘database’, a configuração será lida de $config[‘sess_table_name’], mas caso contrário, você precisará ler o manual par especificar um driver de sua escolha. - Atualize a tabela ci_sessions. (Somente para o driver ‘database’)
A estrutura da tabela foi alterada um pouco, mais especificamente em:- O campo session_id foi renomeado para id
- O campo user_agent foi removido
- O campo user_data foi renomeado para data e no caso do MySQL agora é do tipo BLOB
- O campo last_activity foi renomeado para timestamp
- Estas alterações são acompanhadas por umas pequenas mudanças também nos índices da tabela, por isso, por favor, leia o manual sobre o uso do Driver Database Session para maiores informações.
Importante! Somente MySQL e PostgreSQL são oficialmente suportados agora. Outros bancos de dados podem ainda funcionar, mas devido a falta da funcionalidade de locking, eles são inseguros para requisições concorrentes e você deveria considerar utilizar outro driver de sessão.
- Remova o item $config[‘sess_match_useragent’]
A informação do user-agent é fornecida pelo navegador do usuário, ou em outras palavras: pelo lado cliente. Como tal, esta é uma característica ineficiente e por isso ela foi removida. - Remova o item $config[‘sess_expire_on_close’]
Esta opção é ainda utilizável, mas somente para questões de retrocompatibilidade e por isso deveria ser removida. O mesmo efeito é obtido ao configurar o item $config[‘sess_expiration’] para 0. - Procure por conflitos entre flashdata e userdata
Flashdata é agora a mesma coisa que userdata, somente marcada para ser excluída na próxima requisição. Em outras palavras: você não pode ter ao mesmo tempo dois valores em userdata e em flashdata com o mesmo nome porque eles são a mesma coisa. - Verifique o uso de session metadata
Antes, você poderia acessar os metadados: session_id, ip_address, user_agent e last_activity como índices do userdata. Isto não é mais possível e você deverá ler os documentos sobre a Session Metadata se sua aplicação realmente precisar destes valores. - Verifique o uso de unset_userdata()
Antes, este método costumava ser usado como uma matriz de associação onde key => valor eram usados para várias chaves. Isto, no entanto, não faz sentido e agora você deve passar apenas as chaves como os elementos de uma matriz.// Antes $this->session->unset_userdata(array('item' => '', 'item2' => '')); // Agora $this->session->unset_userdata(array('item', 'item2'));Finalmente, se você escreveu sua própria extensão da Session, você deve movê-la agora para application/libraries/Session/, embora as chances são de que ela irá agora também ter que ser reformulada.
Passo 7: Atualize seu arquivo config/database.php
Devido à mudança de nome de Active Record para Query Builder na versão 3.0 do CodeIgniter, dentro do seu arquivo config/database.php você precisará renomear a variável $active_record para $query_builder:
$active_group = 'default'; // $active_record = TRUE; $query_builder = TRUE;
Passo 8: Substitua seus templates de erros.
No CodeIgniter 3.0, os templates de erro são agora considerados views e foram movidos para o diretório application/views/erros.
Além disso, agora foi adicionado suporte para templates de erros em CLI em texto-plano que, como não acontece com HTML, tem intenção de ser utilizado em linha de comando. Isto, é claro, requer outro nível de separação.
Não há problemas mover seus templates antigos de application/erros* para application/views/errors/html*, mas você deverá copiar a pasta application/views/erros/cli* dos arquivos do CodeIgniter.
Passo 9: Atualize seu arquivo de rotas config/routes.php
Rotas contendo: :any
Historicamente, o caracter :any é somente um apelido para uma expressão regular e configurado para ser executado desta maneira .+. Isto é considerado um bug, já que também contempla a barra /, que é um delimitador de segmento URI e esta nunca foi a intenção desta função.
No CodeIgniter 3, o caractere :any agora representa [ ^/]+, assim, ele não irá mais achar uma barra.
Com certeza existem muitos desenvolvedores que tem utilizado este bug como uma característica. Se você é um deles e deseja continuar encontrando a barra/, por favor, use a expressão regulart: .+.
(.+) // encontra QUALQUER COISA (:any) // encontra qualquer coisa, exceto a barra '/'
Diretórios e ‘default_controller’, ‘404_override’
Como você deve saber, as configurações $route[‘default_controller’] e $route[‘404_override’] aceitam não somente um nome de controller, mas os pares controller/method. Entretanto, um bug na lógica de roteamento tornou possível para alguns usuários usar esta configuração assim: diretório/controller.
Como já foi dito, este comportamento foi acidental e nunca tivemos a intenção de adicioná-lo, ou não documentá-lo. Se sua aplicação usa este tipo de configuração, então ela vai parar de funcionar se você atualizar para o CodeIgniter 3.0
Outra alteração importante na versão 3, é que as configurações ‘default_controller’ e ‘404_override’ são agora aplicadas por diretório. Para você entender melhor, vamos ver este exemplo:
$route['default_controller'] = 'main';
Agora, considerando que seu site esteja localizado em exemplo.com, você já deve saber que se um usuário visitar http://exemplo.com, a configuração acima vai fazer com que seu controller chamado ‘Main’ seja carregado.
Porém, o que acontece se você tiver um diretório assim: application/controllers/admin e o usuário visitar: http://exemplo.com/admin? No CodeIgniter 3, o sistema de rotas irá procurar por um controller chamado ‘Main’ dentro do diretório /admin. Caso não encontre, então o CodeIgniter irá subir um diretório acima, como na versão 2.x.
A mesma regra se aplica para a configuração ‘404_override’.
Passo 10: Muitas funções irão retornar NULL agora em vez de FALSE quando algum parâmetro obrigatório não for passado.
Muitos métodos e funções irão retornar NULL agora em vez de FALSE caso os itens obrigatórios não existam.
- Funções Comuns
- config_item()
- Classe Config
- config-item()
- config->slash_item()
- Classe Input
- input->get()
- input->post()
- input->get_post()
- input->cookie()
- input->server()
- input->input_stream()
- input->get_request_header()
- Classe de Sessão
- session->userdata()
- session->flashdata()
- Classe URI
- uri->segment()
- uri->rsegment()
- Array Helper
- element()
- elements()
Passo 11: Uso do filtro contra XSS
Muitas funções no CodeIgniter permitem que você use sua funcionalidade de filtro XSS quando necessário ao passar um parâmetro TRUE ou FALSE. O valor padrão do parâmetro é FALSE, mas agora ele foi alterado para NULL e será dinamicamente determinado pelo valor que constar em:
$config['global_xss_filtering'];
Se você costumava passar manualmente um valor BOOLEAN para o parâmetro $xss_filter ou se você se você sempre manteve a configuração acima setada para FALSE, então você não vai precisar se preocupar com esta alteração.
Caso contrário, por favor, reveja o uso das seguintes funções:
- Biblioteca Input
- input->get()
- input->post()
- input->get_post()
- input->cookie()
- input->server()
- input->input_stream()
- Cookie Helper
- get_cookie()
IMPORTANTE! Uma outra alteração importante é que as variáveis superglobais: $_GET, $_POST, $_COOKIE e $_SERVER, não são mais verificadas automaticamente quando o filtro global XSS está habilitado.
Passo 12: Verifique possíveis problemas relacionados ao filtro XSS nas suas URIs
A biblioteca URI costumava converter automaticamente alguns tipos de “caracteres de programação” para entidades HTML quando eles eram encontrados em um segmento URI.
O objetivo disto foi fornecer um certo tipo de proteção automática contra XSS, além da configuração existente em $config[‘permitted_uri_chars’], mas isto provou ser problemático e por isso esta funcionalidade não existe mais no CodeIgnite 3.0
Se sua aplicação utiliza esta funcionalidade, você deve atualizá-la para filtrar os segmentos URI através da opção $this->security->sxx_clean() toda vez que você enviar estas informações ao browser.
Passo 13: Verifique o uso da regra de validação ‘xss_clean’
Uma regra amplamente desconhecida sobre o filtro XSS é que ele deve ser usado somente para saída de dados, nunca para entrada de dados.
Nós mesmos cometemos este engano com nossa funcionalidade de filtragem automática XSS global, (veja o passo anterior sobre XSS), por isso como um esforço para desencorajar esta prática, nós também decidimos remover a opção ‘xss_clean’ da lista de regras oficiais de validação suportadas na biblioteca form validation.
Por que a biblioteca Form Validation geralmente valida dados de entrada, e a regra ‘xss_clean’ simplesmente não tem utilidade alguma para dados que estão entrando.
Se você realmente, mas realmente mesmo deseja aplicar esta regra, você deve agora utilizar o Security Helper, o qual contém uma função regular chamada xss_clean(), e por isso pode também ser usada como uma regra de validação.
Passo 14: Atualize o uso o método get_post() pertencente à classe Input
Anteriormente o método get_post() estava procurando primeiro em dados enviados via POST, e então em dados enviados via GET. Este método foi modificado e agora ele primeiro procura em GET e então em POST, como seu próprio nome sugere.
Um método que foi adicionado, post_get(), procura primeiro em POST e depois em GET, assim como o get_post() fazia antes.
Passo 15: Atualize o uso da função directory_map() do helper Direcory
Em uma array de resultados, os diretórios agora terminam com um separador à direita, como uma barra, geralmente.
Passo 16: Atualize o uso da função drop_table() da classe Database Forge
Até agora, a função drop_table() inseria uma cláusula IF EXISTS por padrão ou então ela não funcionava com alguns drivers. No CodeIgniter 3, a condição IF EXISTS não é mais adicionada por padrão e tem um segundo parâmetro opcional que permite isto e que está setada para FALSE por padrão.
Se sua aplicação realmente precisa do IF EXISTS, você terá que mudar seu código como segue abaixo:
// Agora, produz somente DOP TABLE 'table_name'
$this->dbforge->drop_table('table_name');
// Produz DOP TABLE IF EXISTS 'table_name'
$this->dbforge->drop_table('table_name', TRUE);
Nota: O exemplo acima utiliza uma sintaxe específica do MySQL, mas deverá funcionar sem problemas em qualquer driver de banco de dados, com exceção do ODBC.
Passo 17: Altere o uso da biblioteca Email quando trabalhar com vários emails
A biblioteca Email irá automaticamente zerar os parâmetros de configuração após enviar emails com sucesso. Para sobrescrever este comportamento, passe o valor FALSE como primeiro parâmetro no método send():
if ($this->email->send(FALSE))
{
// Parâmetros não serão zerados.
}
Passo 18: Atualize as linhas de idioma da biblioteca Form_validation
Duas melhorias foram adicionadas nos arquivos de idioma da biblioteca Form Validation e no formato das mensagens de erro.
Os índices de cada linha agora devem ser prefixadas com form_validation_ com o intuito de evitar confusões.
// Antes $lang['rule'] = ... // Agora $lang['form_validation_rule'] = ...
O formato das mensagens de erro foi alterado para usar parâmetros de nome, assim permitindo maior flexibilidade do que a função sprintf() oferece:
// Antes
'The %s field does not match the %s field.'
// Agora
'The {field} field does not match the {param} field.'
Nota: O formato antigo ainda funciona, mas as linhas índice que não são pré-fixadas foram DESCONTINUADAS e está agendada para a remoção na versão 3.1 e posteriores do CodeIgniter. Por isso, é altamente recomendável que você atualize seu uso o quanto antes e evite deixar para depois.
Passo 19: Remoção do uso de funcionalidades previamente descontinuadas.
Aqui eu resolvi somente listar as opções que foram totalmente removidas ou serão removidas em futuras versões do CodeIgniter. Caso precise de mais detalhes, sugiro que dê uma olhada neste link, que informa mais detalhadamente cada item abaixo.
Além da opção de configuração $autoload[‘core’], existe um número grande de funcionalidades que foram removidas no CodeIgnite 3.0
- A biblioteca SHA1
- A constante EXT
- Helper Smiley
- A biblioteca Encrypt
Devido a várias notificações de vulnerabilidade, é altamente recomendável que você utilize na nova biblioteca Encryption Library. - A biblioteca CART
- Drivers de Banco de Dados: ‘mysql’, ‘sqlite’, ‘mssql’, ‘pdo/dblib’
O driver mysql utiliza uma extensão antiga do mysql para PHP, conhecida pelo seu código antigo e de muitos problemas. Por isso, utilize os driver ‘mysqli’ ou ‘pdo/mysql’. - Helper de segurança do_hash()
- A configuração da opção $config[‘global_xss_filtering’]
- Helper de arquivo: read_file()
- Helper de string: repeater()
- Helper de string trim_slashes()
- Helper de formulário form_prep()
- Função do helper de e-mail
O helper de email agora tem somente duas funções;
– valid_email()
– send_email() - Helper de datas standard_date()
- Helper de HTML, nbs(), br()
- Configuração chamada anchor_class na biblioteca de paginação
- Helper de string random_string() com os tipos unique e encrypt
- Separadores do Helper de URL url_title() chamados dash e underscore
- Biblioteca de Sessão. Método all_userdata()
- Método add_column() com a cláusula AFTER da biblioteca Database Forge
- Métodos fetch_direcotry(), fetch_class(), fetch_method() do helper de roteamento URI
- Método is_cli_request() da biblioteca Input
- Método system_url() da biblioteca config
- Biblioteca javascript
Passo 20: Verifique o uso do helper de Texto chamado highlight_phrase()
A tag padrão de HTML usada pela função Text Helper highlight_phrase() foi alterada de <strong> para a nova tag HTML5 <mark>
A menos que você use suas próprias tags de destaque, isso pode causar um ceto problema para seus visitantes que usam navegadores web como o Internet Explorer 8. Por isso, nós sugerimos que você insira o seguinte código no seu arquivo de CSS para evitar problemas de compatibilidade em navegadores antigos:
mark {
background: #ff0;
color: #000;
};
—
Bom é isso. Nestes simples 20 passos, você consegue atualizar seu a versão do seu CodeIgniter para a última disponível neste momento, a 3.0.
Caso tenha alguma sugestão com alguma dica que esqueci de colocar aqui, fique à vontade em escrever nos comentários.
Abraços
Fábio S. Reszko
