Framework for transitioning a bespoke application

[Paul Waring]

I'm currently working on a medium-sized bespoke PHP application (tens of
thousands of lines of code) which has been built up over 7+ years. At
some point I'd like to move this over to a framework, mainly so that
things like changes to the models (e.g. a user) don't have to be made in
half a dozen places (database, form template, PHP processing, client
side validation etc.). I'd also like things like CSRF protection to be
built-in instead of having to remember to add them to every form.

However, I've noticed that most of the PHP frameworks seem to assume
that you will use them exclusively and do everything the way they want.
This is great for new projects, or existing applications which can be
ported in one go, but not so much for larger applications where a
gradual transition is needed.

Is there a good framework out there which caters for this scenario? I'm
sure I'm not the only developer in this position. :-)

Thanks

Paul

--
Paul Waring
Freelance PHP developer
http://www.phpdeveloper.org.uk

[Anthony Sterling]

Hi Paul.

Fabrice Bernhard (@theodo) did a talk called "Modernisation of legacy PHP applications" at @phpne in 2013 where he addressed this, here are the slides for that talk: http://www.slideshare.net/fabrice.bernhard/modernisation-of-legacy-php-applications-using-symfony2-php-northeast-conference-2013

His example uses Symfony, but the approach could easily be applied to a different framework.

--
You received this message because you are subscribed to the Google Groups "PHPNE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-north-eas...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Anthony Sterling
Twitter: @anthonysterling
Web: http://anthonysterling.com

[oli wood]

That was a tremendous talk.
My only advise, is two fold.

Don't be tempted to improve and enhance on the way past. It's always tempting to bolt on tiny features as you go, concentrate on replacing like with like to begin with (of you're going to move the whole thing). We did this replatforming Wishlist.

Secondly, if possible, so it in tiny bits, possibly using a "wrap and hand off" style. The last thing you want is the "unleash the new version!" day, especially if it involved a data migration too.

O

[James]

Oli's advice is very sound. Adding functionality as you refactor is a great way to turn your code into a bag of angry cats. Building tests is the only exception I'd make.

I've recently been adding some structure to a legacy project. I intend to re-hang it on Laravel - pretty much the only PHP framework I'd use now, and I'll base my advice on that.

There's a long way to go still for me, but I've been able to add in some good structure relatively easily by setting up Composer and moving my models across to Eloquent:

http://laravel.com/api/5.0/Illuminate/Database/Eloquent.html

If you wire up the namespaces properly, you can use this independently of the full Laravel framework and - certainly in my case - that has really helped clean up database cruft.

You could also streamline your views - I prefer Twig to Laravel's native Blade and again, Composer makes it a relatively easy job to mix that in. Moving that across to Laravel should be relatively straightforward.

I'm not sure if form/CSRF can be cherry-picked from Laravel, but, again, there are a few Composer-able CSRF libraries, and likely some appropriate form builders.

The other thing that helped in a big way was to set up database migrations. I'm using Phinx on this project - again, not sure how possible it is to cleave out Laravel's own migration scheme (I'd prefer to have that).

Another part of the puzzle for me was sorting out deployment - I put together some Vagrant/Ansible scripting to help rationalise my environment and automatically copy over config files into the right places- useful for setting up Phinx's db config (YAML if I remember) to mirror the main codebase.

Lastly, make sure you use your repo wisely. Ensure you still have the flow to fix something urgently on the live site while you're refactoring and also propagate that change to your refactor branch.

J

On Tuesday, 1 September 2015 13:12:48 UTC+1, oli wood wrote:

...

[Paul Waring]

Thanks, that looks like a really useful talk. :)

Paul

On 01/09/15 12:58, Anthony Sterling wrote:
> Hi Paul.
>
> Fabrice Bernhard (@theodo) did a talk called "Modernisation of legacy
> PHP applications" at @phpne in 2013 where he addressed this, here are
> the slides for that
> talk: http://www.slideshare.net/fabrice.bernhard/modernisation-of-legacy-php-applications-using-symfony2-php-northeast-conference-2013
>
> His example uses Symfony, but the approach could easily be applied to a
> different framework.
>
>
>
> On 31 August 2015 at 10:15, Paul Waring <pa...@phpdeveloper.org.uk

> <mailto:php-north-east%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Anthony Sterling

> Twitter: @anthonysterling <http://twitter.com/anthonysterling>
> Web: http://anthonysterling.com <http://anthonysterling.com/>

>
> --
> You received this message because you are subscribed to the Google
> Groups "PHPNE" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to php-north-eas...@googlegroups.com

> <mailto:php-north-eas...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.


--