I have a legacy-app in PHP which I want to migrate to a framework. There around a hundred files forming an admin-backend. Most of the code is not even object oriented, some has never been touched by me.
There is no time for a complete refactoring, but I have to add some features and need to rebuild others. I hope to rebuild component by component.
There is a need to keep everything working in the process - maybe without the users even noticing the changes. I plan to rebuild the UI in CodeIgniter, linking in the older parts until they have been replaced.
This is the directory-structure in short:
admin
includes -> the old code
images
css
js
index.php -> including other files depending on $_GET - parameters
my question is: Would it be the best to throw CI in that admin-folder, rename the old index.php and do some rewriting to enable both parts to work?
Is there a better approach to separate legacy and new code?
It would be better if you complete refactor the app, even just the admin part for start. If you plan to use the framework you need to apply the MVC pattern to your existing files which is not a simple copy paste.
Happy coding
I would have to say that trying to switch what you described to a framework is a bad idea and could lead to some hack jobs to make sure things are working. My suggestion would be to start from scratch.
If you were to start from scratch you could leave what is currently up untouched and upon, finishing the new app, upload it without having anything go down.
If you really need to start adding new features I would look into adding components (such as Symfony2 components), instead of adding an entire framework. Add it to a git repository and work on a developer branch so users can't see any changes until you merge in the (working) changes.
I realize this is a bit late, but I ran into the same type of issue. What I ended up doing is using Bonfire (which is based on CodeIgniter) in a sub-folder and calling it from existing pages using AJAX requests until we have time to complete a site redesign, which will use Bonfire throughout.
Of course, this was probably a little easier in my case, because the site I am working on had almost no dynamic or data-driven elements, or an administrative interface. Just years of pages thrown together in whatever fashion made sense at the time.
Related
I'm new with CakePHP and I want to convert an existing PHP project into CakePHP. This project is already written using MVC, however the structure is not clear, models are not match with databases,different logic... (e.g. When I need to find something I cannot know where to look for.)
My 1st option is to read and understand deeply the code, see the data flow and then re-write most of the code into Cake. => Will take very long time.
I would like to ask, if there is any procedure/steps I could take to make it a little easier, something like keeping the old MVC files and structure, write code to map with Cake, keep the re-write to minimum, etc.
Thank you!
Unfortunately there probably aren't a lot of options beyond thoroughly reading the code and transitioning it to the new structure. If the existing code is properly structured, you should be able to work to transition existing views to Cake views etc and so on.
The best practice would be to write tests before refactoring to make sure that you 100% understand the existing code and don't break anything.
You could probably use ur old app as 3th party library in cakephp 3.0.
But the cleaner and most likely easier way would be the port of application.
If you did your mvc job good it should be a lot of copy pasting.
Cakephp is convention over configuration so the first step you should probably do is adjusting your database to the cakephp convention: http://book.cakephp.org/3.0/en/intro/conventions.html .
When this is done you can use "cake bake all"(http://book.cakephp.org/3.0/en/bake.html) to generate the whole controller/model/view so you just have to adjust the files and don't have to create everything from scratch.
I have a large complex web site currently implemented using PHP and MySQL.
Some of the pages (about, contact us, etc) are largely static, but need to be updated from time to time. I'd like these updates to be able to be done by non technical admins, so I'm migrating the site to Joomla CMS. I've created a Joomla template to reproduce the banners, styling etc of my existing web site and have successfully reproduced the static pages by cutting and pasting into Joomla articles.
I'm now trying to embed my existing dyanamic php pages into the Joomla framework. I assume that I need to convert them into one or more Joomla components? I realize that I'll need to strip out the php code that currently generates banners, menus, etc, but I don't want to make major changes to these php pages, i.e. I don't want to re-implement them to follow an MVC pattern. I'm looking for a simple Joomla 3.2 hello world component tutorial. The tutorials that I've found are either too complex (i.e. MVC) or they're "too simple". By too simple I mean the component is not listed when I select Menu Item Type within the Menu Manager. Can anyone point me to any documentation that explains the minimal config that I need to include in a custom Joomla 3.2 component in order for the component to be listed when selecting Menu Item Type?
Also, should I create one big custom component to wrap my existing PHP application containing multiple pages("views"?)? Conceptually there the system could be considered as about 3 sub-systems, but there is some overlap between the MySQL tables used in these different sub-systems.
I don't need the implementation to be portable, i.e. I'm not trying to create a reusable component that others could use, I just need it to work on my site, using the least amount of work possible.
Thanks, Wayne.
I hope to clarify a bit and give you way out.
In response to your comment on #user3057084, the power of Joomla and its flexibility comes from it being MVC! If you want to wrap your existing code with little modifications, Wordpress will let you do all kind of nasty things! Nasty in the sense of mixing logic with data, i.e. copying and pasting your code and getting it to work quickly.
Joomla coding standards require that you separate models from views. And that you understand how the Joomla MVC implementation works. It will take longer, but you'll learn a useful skill that can and should be applied if you want to write portable maintainable code following Design Patterns.
Now about the way out.
Nothing keeps you from putting your raw php code in a Joomla view, including the database access. It's really ugly and I feel bad even suggesting this, but if it can be a small step towards using a great framework, then the end justifies the means.
The absolute easiest way for you in Joomla would be to create a template override (which you'll do from the admin with a few clicks in the template manager), then throw your code in, and it will run. Then, a little bit at a time, you might learn to separate the parsing of the input in the controller, store / retrieve the data in a model, and leave just the markup in the view.
But are you absolutely sure you need to code for this? There are thousands of (free) extensions out there that might do the job for you with no coding and little configuration, leaving you just a data migration to handle.
Have you had a look at Wordpress yet? In my experience, non-technical people find it easier to administer a wordpress website in comparison to a Joomla website.
When it comes to the menu structures,themes and contact forms and blogs - Wordpress takes the cake.
It would be worth your while to check it out? It might save you hours of frustration?
I already have a working OOP website. Most of the php is separated from the html. I was wondering if anyone had any tips on how to apply that site into the Yii Framework.
Edit
The website uses jquery, html, css, php, javascript. It also consists of a lot of libraries and classes I bought of code canyon. Like a geolocation library, phpthumb (image thumbnails), like and dislike system. How does one go about importing these libraries into Yii?
I had a similar task a year ago, but the code wasn't really OO at all. I created a new Yii project and placed the old site as a lib in the that project. I then set up the basics in Yii like database access, whichever session values were needed in both projects etc. I then ported route by route, feature by feature. It took some time, but it worked out really well. I just had a bootstrap script which routed requests based on "ported_routes".
When it comes to reusing classes that should not be a problem if they are well structured without dependencies on the old code. Yii places no restrictions on that stuff, so just add them as libs or browse through the Yii docs and see if it makes sense to refactor them into Yii components or subclass something in there.
As for CSS and JS that was redone from skratch, using LESS and newer JS libs. A lot had happened in the JS world since the original code was written. Yii does not require you to follow any predetermined structure for markup either, so in theory you should be able to use the old CSS unless you want to change markup fundamentals.
If your old code has a MVC-like structure the porting of actions and views will go smoother, but regardless you are pretty much left with a similar approach I think.
well there is no hard and fast convertor which will convert your site from traditional OOP model to Yii. You have to do all of it yourself. But you can opt to do it in stages though.
-at mathew commented I must clarify that you have to do it all by yourself and there is no easy way to convert your existing code to what Yii understands
i have a project i took over. it is an app that has been build over many years with PHP and mysql.
It currently has a sort of good folder structure but the code itself is very poor written.
There is php, sql statements and html code in almost every file.
There is javascript code generated using php echo for not reason and so on.
I will like to use for further development either CakePHP or CodeIgniter, even if that means that for the new features some code will be written that already exists (eg.: maybe utility functions) in the old code.
is it possible to integrate one of these frameworks into an existing app?
which one is easier?
do you have any links on how to do it?
thanks.
I have very little experience with CakePHP so my answer is going to be about CodeIgniter. I played with CakePHP for about a day and that was almost two years ago. In my opinion it will probably be easier to integrate with CodeIgniter although someone more experienced with CakePHP might prove me wrong.
Here is the approach I would take. I have never done this, but it seems like a logical way to approach the problem. I suppose this approach would also work with CakePHP.
First, start with a fresh CodeIgniter install using the latest version.
Next, create controllers and actions (controller methods) that mirror the current structure of the application. For example, if you had a page with the URL http://example.com/users/view you would create a Users controller with a view() method.
Next, create view files for each of the current files of the application and load them via the appropriate controller methods. The goal here is to get the application working using CodeIgniter's routing system although at this point you won't be utilizing any models, libraries, or helpers.
Once you have the application sitting on top of CodeIgniter, start refactoring it to fit into the MVC pattern. Pull out application logic (queries, form handling, etc...) from the view files and place them into the controllers. Keep all presentation logic and HTML in the views.
Next, refactor the controllers. This is where it gets tricky because controller code can be placed into models, libraries, or other controller methods. A good starting point would be to take all of the queries and put them into appropriate models. Compare your controllers and see if there is any code duplication. That is a good sign that you should remove it from the controller and place it elsewhere. Unfortunately I can't really tell you where because it differs in each situation.
Continue refactoring your application until you have it in a workable state that you are pleased with...
Hopefully this helps. I certainly missed some critical steps such as setting up and configuring CodeIgniter but if you're serious about doing this I would highly recommend reading through the CodeIgniter User Guide to get a good idea about how it works. You should also get familiar with MVC (model-view-controller) if you aren't already.
There's not really a one size fits all solution here but hopefully I've given you some ideas or at least a starting point to jump off of. If you have any questions or are a little confused drop a comment below and I'll get back to you.
In my opinion, it's easier just to write your controllers in CodeIgniter (I've never used CakePHP) and models, than you just copy paste with some adjustments the views.
There is a lot of good content on SO about MVC and getting started with MVC, but I'm having trouble finding anything about how best to implement MVC structure on a pre-existing, live website.
My site is a nasty mishmash of echos and concatenated HTML that would make any professional programmer throw-up, but it works.
I'd like to spend some time tackling the mounting technical debt, however, and that means moving to a much more sane MVC structure.
If at all possible, I'd like to avoid a let 'er rip! 100% rewrite and launch approach, and instead take it a section at a time. But it seems the basic controller's centralized structure is not suitable for such an approach?
If i understand what is the overall level of quality for that codebase , then there is no way to move to MVC in one step. It is just impossible. Another bad news is that frameworks will not help. They cannot magically transform a bad codebase into something resembling MVCish architecture.
Instead you should focus on incremental refactoring. Your goal should be code that is mostly following SOLID principles and LoD. And while you refactor your code , the architecture will emerge by itself. MVC has many variants and flavors.
One definite thing you might want to look at are the ways of using templates in php. Examine the code, and see what you has to change to fit your needs (it is more of a direction, not a complete solution). And remember that in MVC-like structures View is not a template, but it View uses multiple templates.
Another thing you might benefit from is learning more about datamappers. Implementing them would be a good step in direction of creating model layer.
Oh .. and then there are few general lectures you could take a look at ( all are 30min+ ):
Advanced OO Patterns
Clean Code I: Arguments
Clean Code III: Functions
Don't Look For Things!
Global State and Singletons
Inheritance, Polymorphism, & Testing
Oh , and this book has some insights into refactoring large php projects. Could be useful for you.
i agree with the other suggestions here, a framework isn't going to be a magic fix.
however it can help in the long run.
i have converted a number of mishmash sites to kohana framework now, and have had the following experiences.
initially i didn't know kohana well enough, so i was learning that while recoding mysite. I ended up stopping the rewrite and coding a completely new project from scratch to learn kohana, then went back to the rewrite project, now that i understood the framework better.
if you don't understand the framework, it is going to be a steep learning curve trying to use it to convert an old project
first step in the rewrite was to pull all the business/database logic embedded into the pages up to the top of each page (prior to the html output). So that i wasn't changing the flow/structure of the website, just separating business logic from display logic.
After that i had a site that had easily readable business logic, just in the old structure, and i had familiarised myself with the old codebase at the same time.
next step i did was to fix any database structure issues so that everything was in 3rd normal form (if possible).
i found it easier to modify the old code to the new database structure, then to work around and old database structure in the new framework. (kohana is largely a convention based framework, rather then configuration, so it was nice to follow those conventions, to ease long term maintenance)
having a good database structure makes life easier regardless of framework
next step was to pick a part of the website to replace. set up the routes in kohana and let kohana serve that part of the project. kohana (and other frameworks no doubt) have a fallback, if a file being requested via a url already exists on the site, then kohana won't handle that request
since you have separated the business logic from the display logic in your php files, it is a simple matter of splitting the code into a controller and a view. make the changes to both parts to suit the framework. you can split the business logic into model/controller after you have the controller/view working as expected
work your way through that part of the site, until complete. then test/launch/bugfix etc
then start again on the next part of the site.
eventually you will get there...
although it took a lot of time to rewrite, for me it was worthwhile, as the sites are far easier to maintain now. (obviously the amount of gain will be dependant on the quality of the original codebase)
good luck
it is possible to do. you can write your mod rewrites to only redirect to boot.php or whatever if no actual file is found at the requested path. this would allow you to do a section at a time. making sure all of your links are in order will be a nightmare however.
may wan to do a rewrite, and copy and paste peices you need out of the old application as you go.