Retrofitting App to use CodeIgniter

[eluser]dcunited08[/eluser]
I currently have an application with about a hundred scripts that I would like to slowly change to use CodeIgniter, in the mean time, it has to be able to work. My first guess would be to create forward requests for old parts to the old app and handle new requests basically by URL rewriting using the CI_URI class. Has anyone done something similar?

-DCUNITED

[eluser]sophistry[/eluser]
hey dcunited,

welcome to CI.

i just completed the same kind of migration, but with a few dozen pages.

to get it done, i wrote a little teeny controller that handles migration of static pages to CI driven site.

check it out in this post for pages in the HMVC thread - i wrote it as a module, but you can use it as a standard controller.

the thread posting where i introduced the code.

the wiki page that hosts the code and has instructions

[eluser]Crafter[/eluser]
I used apache's htaccess

Code:

# If the file or directory exists, show it
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^(.+) - [PT,L]

    # Blank queries get sent to the index
    RewriteRule ^$ /index.php [L]

    # All other queries get sent to the index as index.php/whatever
    RewriteRule ^(.*)$ /index.php/$1 [L]

In this way i had a directory stucture
application --> CI's directory
admin --> old app
somefile.php --> oldapp

[eluser]Michael Wales[/eluser]
Crafter's solution is how I would tackle this problem as well. You know your current code works - so you always want to fall back on it. Let the server issue those older files until you are confident your code is working flawlessly on your development machine. Deploy to production, perform a few tests to make sure it works there, then delete the older application file - Apache will automagically issue the same request to your new CI implementation.

[eluser]sophistry[/eluser]
one requirement that you might be faced with (which i was):

URIs must remain the same between old site and new site. that is, even though CI will be serving the new site, all the same "pages" (static HTML and PHP scripts) need to get called up without any 301 redirects.

so, it may not be sufficient to just rebuild the site with all new URIs and then "cutover" to the new CI site. in my case, few months before i even planned to rebuild the existing site, i dropped in CI at the root of the domain serving all the *new* content. with an htaccess file similar to crafter's, apache checks if an *actual file* exists before handing off control to CI. when i added new URIs for new site capabilities apache determined that there was nothing for it to serve directly and so it called up CI via the index.php rewrite (see crafter's submission above).

as MW says, that lets you keep serving the static pages without CI involved.

in my case, i needed to migrate all of the HTML and PHP pages *without changing the static pages at all* AND *without building a bunch of CI cruft (controllers and views) around them*. it almost worked like that; only a few things had to change in the static pages once i put them behind my "pages" module/controller.

i think this is going to be a central project of a lot of new CI coders as they figure out how to use CI and then want to convert old stuff to live in CI-land!

let us know how it goes.

[eluser]dcunited08[/eluser]
Thank you for all the suggestions! Well, I have followed sophistry's idea and found it not to work for me. The code did not work well with multiple folders and direct compression calls and the like. I have gotten the application setup using the htaccess you suggested and it works rather well. My next step will be to figure out how to use some of CIs libraries in the non-CI files. One of my goals through this is to update the header part and put it in as a view to be called, currently it is an include file. I like the idea that the code is there and working until I write something to replace a page and remove the old page. It will allow me to move over to CI at my leisure, or on new things, without having to redesign the old at all. Thanks for the assistance.

-dcunited

[eluser]sophistry[/eluser]
great feedback. thanks for pointing out some of the limits of the (very simple, but nonetheless useful - IMO) "pages" module:

Limits:
1) for multiple folders you can set up some amount of routing in the routes.php file to make sure that the files are targeted properly
2) not sure what you mean by "direct compression" - when i google it i get lots of information on how to make pills - assume you mean "output compression" like the PHP gzencode function is this what you are using?

I am looking into building in some nested folders support because that was one thing i simply worked around instead of solving - it was faster for me to write routes for the few folders than it was to write directory support into this little module.

i don't currently use any output compression, so i am curious to hear more about what calls you used and what happened... i'll set up a similar problem and see if i can figure out what the problem is since i'll eventually have to do some output compression but just haven't had the need so far.

[eluser]dcunited08[/eluser]
Currently, I am using ob_gzhandler to compress the output on javascript files, I guess custom is not the right description, per page is more like it. I did, though, like the idea of using routes because my next issue is how to use CI code within the legacy part of my application. I.E. I would like to create a view that is the header for all the pages, simple enough for the CI part (all one page of it currently) but how can I use it in the non-CI parts? I have been attempting to load CI as described in the manual for Libraries but I have yet to find how to include all the files without it trying to serve up a page. I think Pages works well for a few files but I was quickly running into the issue of altering my site drastically to work within CI. The site is primarily scripts that are interlaced together and I want to transfer over the site a little at a time, not all at once. I attempted it and then saw the htaccess path which got me up and running faster.

[eluser]sophistry[/eluser]
i posted an updated version of "pages" to the wiki...

i basically rewrote it to support nested folders in the views directory. it is no longer an HMVC module because the 4.2 version of HMVC doesn't support nested views inside modules.

now, it should support more sites, better, without extensive re-routing. don't get me wrong.... it's a long process to migrate a site, but this should help.

http://ellislab.com/forums/viewthread/91182/

[eluser]dcunited08[/eluser]
sophistry,

Thanks for the assistance, I tried your new fixes and got it working rather well (with some htaccess to hide the index.php and routing everything to my default controller). I made some changes to include an 'old' folder to segregate everything out of the default folder and keep the main structure intact.

Code:

class Site_migrate_base extends Controller {

    var $default_view_and_method = 'index';
    var $oldDir;
    
    function Site_migrate_base()
    {
        parent::Controller();
    }
    
    function _remap()
    {
        $view_or_method = $this->uri->rsegment(2,$this->default_view_and_method);
        
        // if the method exists in any parent/child class, run it
        // else load the view file (even nested views by uri string)
        if (method_exists($this,$view_or_method))
        {
            $this->$view_or_method();
        }
        else
        {
            $local_view_path = rtrim($this->uri->ruri_string(),'/');
            if(isset($this->oldDir))
            {
                $local_view_path =  str_ireplace('tirome', 'TIRomeOld', $local_view_path);
                
            }
            
            $view_file_full_path = APPPATH.'views/'.$local_view_path;
            $view_file = (is_dir($view_file_full_path)) ? $local_view_path.'/'.$this->default_view_and_method : $local_view_path;
            
            $activeDir = getcwd();
            $worked = chdir(dirname($view_file_full_path));
            $this->load->view($view_file);
            chmod($activeDir);
        }
    }

I used a route to send everything ending in '.php' to the default controller so that anything new will not end in '.php'.