My freelance business has grown, and reached a critical decision point for my future development. I've been puzzling over this for a while - why not puzzle it out in public!?
I need to pick a PHP framework. Or maybe not pick one. But my dilemma is kind of unusual. I'd love the opinions of other experienced PHP devs! But hear me out, my situation is a bit unique.
Unhelpful Metrics
Extensive research has given me endless comparisons of Laravel vs Symfony & others, using completely useless (to me) metrics like:
- Number of GitHub stars.
- Google search popularity.
- Job postings.
- Number of StackOverflow questions.
- Millisecond differences in speed.
- Etc.
These comparisons aren't helpful. Let me explain why.
My Situation
I build websites & web applications for small to medium sized businesses. Most start as a basic website with a contact form, Google Map, and that's it. Many never grow past this. Some eventually add custom dynamic elements. Say a work-order status page. A searchable directory, etc. A few have grown bigger.
But, and this is key... I also provide hosting, so ongoing maintenance is on me. I don't deliver a project & wash my hands of it. I make future text changes, fix bugs, add things & keep it running - for sometimes many, many years. My oldest PHP project in production is over 10 years old!
Over time I will end up with DOZENS of these projects to take care of.
I don't have the luxury of one, beautiful application to keep front-of-mind.
And so, stability over time is a key. Easy upgrades are key. This is why WordPress replaced my internal CMS for clients who fit that use-case: one-click upgrades baby! That's gold.
Until recently I was using a simple, custom MVC framework that I built. Most of my existing projects are on that. But it's over 8 years old, pre-Composer, and time for a new direction. To give that old workhorse some credit though- it has needed almost zero updates over that time (likely due to stagnating on PHP v 5.6).
I have a few months of experience & learning with Laravel, it's nice. But ongoing updates are a concern. Backward compatibility isn't a priority for Laravel. And it's overkill for 90% of what I do.
I've built a few things with SlimPHP.
I'm intrigued by Symfony because it starts as a micro-framework & grows with you. Awesome!
I'm also considering sticking a few stable Composer packages together for a light version of a 'framework' that will cover all but my few large projects. Maybe Slim is exactly that?
Maybe 90% of what I do doesn't need a framework at all.
It all boils down to not wanting to regret my choice 10 years from now. My youngest child starts school next year & when that happens I'll be throwing my efforts into my business full time. Between now & then I want my ducks in a row & to do the necessary learning.
TL;DR - My Priorities
- PHP based.
- Stability over time.
- Well documented & clear upgrade process.
- Grows with my needs over time.
- Doesn't break backward compatibility on a whim.
- Ok to have one option for small stuff and one for big projects.
Thoughts?
Do you have experience maintaining several framework-based projects over time? What do you use? Is it painful?
Am I crazy for thinking everything even needs a framework?
How does your company handle the time spent maintaining & upgrading a client's project? Do you bill them for the time? Offer a Support Licence with a monthly fee that covers this type of work? Bundle it in the hosting fee?
Thanks everyone!
Top comments (79)
No matter what project, I would go with Symfony and Symfony only. Especially with Symfony4 (and Flex) you can put together the pieces you want and omit ones you don‘t need.
I think there is no better framework in terms of architecture and design than Symfony. I do not lile the stuff Laravel does (did?) with static methods and a lot of magic.
In terms of maintainability and co., you always go better when using a framework. I honestly don‘t want to write code handling HTTP requests/responses - somebody else will do it way better than myself.
I agree wholeheartedly. Seeing as I do have some experience with Symfony (3-4 years worth), I can say that it gives you a well-structured codebase, all the joys of MVC and minimal BC breaks. You're only limited by the PHP version on your server. Regarding the cost of maintaining the codebase, I'd go with a monthly fee.
Then you surely should try ZendExpressive )
It really depends on your goals and how much you care about the architecture/maintainability of your codebase over time...
I'm a DevOps engineer working with teams of php Devs. If it were up to me we'd be using symfony, but the Devs need to make their own choices (and possibly mistakes) and chose laravel.
The biggest reason for choosing symfony over laravel for me is that, although laravel is alot quicker to build with (there's alot less 'plumbing' to be done). It makes it far too easy to write code that is very hard to maintain, and has poor separation of concerns.
For instance, the facades and app->make function in laravel allow you to utilise any service, be it a database, a queuing system, or a redis cache from ANYWHERE in the application. Without highly experienced developers keeping an eye on this, you'll tend to see things like database calls being made from blade templates. This is horrible to debug and pretty much destroys the concept of MVC (which most php Frameworks are designed to follow).
Also, eloquent is a huge pain due to model class structures not being very explicit. What I mean here is that if I wanna know which fields exist in an object, I can't just look in the class definition and see the class properties; I end up having to look in migration files to see the name of the public property that needs changing (if your lucky there may be a few arrays, with some strings in which are the property names). Also if you have alot of business logic associated with your models such as when I set X value on this model it should affect its y value, you're gonna have to create a lot of wrapping services to encapsulate logic which should actually exist in the model itself (normally in setter methods). Otherwise you find yourself duplicating logic all over the shop.
Dont get me wrong, laravel can be an awesome framework to use, but you need to learn to ignore some of the more standard practices in laravel...and use doctrine instead of eloquent. Seriously, I can't state enough how much better doctrine is.
The way I always try to explain why I'd choose symfony over laravel is this: symfony requires more plumbing than laravel, but this plumbing is a necessary evil which helps ensure a healthy codebase. When using symfony you have to think alot more about 'how do I access that service from here', and then do it through proper channels (i.e. dependency injection) as symfony only really allows things to be done in certain ways, whereas in laravel you can just use a facade from anywhere.
I know I'm slating laravel alot here, but I do see laravel being suitable for an agency that will throw a site up somewhere and then forget about it...if you're gonna be maintaining it yourself forever and are bothered about a well structured codebase, symfony is the one.
As a bit of background, I've worked on large scale e-commerce sites in both symfony and laravel. The symfony site, was pretty standard symfony (with some problem areas mostly due to poor oversight and rushjobs; not the framework). The laravel one required quite alot of restructuring to meet the requirements for speed of delivery whilst keeping clean code (try implementing Domain driven design in laravel;not fun). And oh yeah, you can probably guess, we replaced eloquent with doctrine.
This right here is a fantastic comment. This is very helpful, and mirrors some of my own thoughts.
Thank you kindly for taking the time to write this. I think this really tipped the scales for me toward Symfony.
😁👌
A Great saying.
No framework can help lame developers from writing terrible code.
I've seen people without experience tricking Java & Spring. It was blood and sweat, but they did it :)
Hi, to give a bit of background I have more than 15 years experience in PHP, started by doing small business website and hosting (pretty much what you are doing) and now developing full backend application that have millions of users. I also did a master's degree about PHP framework for startup.
That being said I'll make some assumption:
Base on that and reading the other comments here are some thoughts.
API Platform is not for you. If you are not building SPA/Mobile application that need a API there is no reason to use this.
Laravel have a history of bug, low quality, breaking backward compatibility and I agree that thy push wrong programming practices. They might have put a LTS for their version 6 but this is pretty new.
Never heard of ZendExpressive but heard of ZendFramework that it's based on, not a good track record either.
So to keep it for the last Symfony would be my recommendation. Learning curve is a bit hard but they have the track of building the best component/libraries (Laravel is base on Symfony component and probably a few tools mention bellow). It's impossible to not update your stack for 10 years, Symfony have probably the best track to be backward compatible, even some bundle (how to provide extension to the framework) from version 2 are still compatible with version 4 and most of the time they provide tools to upgrade their major release but for sure a good UPGRADE documentation. They are really transparent about the roadmap (LTS) symfony.com/roadmap
If you have a admin to build you could use those to bundle:
A more light one but will still cover most of you need
symfony.com/doc/current/bundles/Ea...
Or a more complex but flexible solution. They also have some CMS extension
symfony.com/doc/current/bundles/So...
If one of your customer project become bigger or want to have a mobile app (or progressive web app) with symfony you will be ready (there is plenty of bundle to do this event the API platform could be add later). There is also a HTTPCache layer that can be easily configure with file if you just have one server and don't have access to a cache proxy like Varnish (building your site thinking about how to cache it could increase drastically the response time going from hundreds of ms to less than 90 ms)
On a more long term point of you I would use Symfony and be really careful about which bundle you use. I encourage you to develop your own bundle (when you have specific needs) and release them open source and manage them via packagist so it will be easy to maintain. There is also a way to have a private package hosting solution if you don't want them to be open source. For the hosting part of your business I suggest you to find a great hosting solution (shared in your case) and open the your customer account on it, there is legal issue (ssl, data privacy security, etc) up time, etc. That you don't want to be responsible for. You are still the point of contact for your customers and charge for the application maintenance but it's a lot easier, the time you save on hosting issue can be put in finding other customers.
Thank you for your very helpful feedback! You're correct in your assumptions - most projects are small and low traffic. I do resell robust shared hosting to my clients with the whole suite of their needs (email, SSL, etc).
I too am leaning toward Symfony. I love that it starts as a microframework and can grow with my needs, and focuses on backward compatibility. :)
You're comparing Laravel 3 with Symfony 2. And telling symfony 2 is compatible with v4 is anything but true. Our team put ~ 100hrs (!) upgrading a medium sized symfony 3.3 project to v3.4.
The problem is that most of the comments here are based on random rants found on the net and vague, vague experience.
This Laravel encourages bad practice vs. symfony is the enterprise php framework mantra is super outdated in 2019 and is also very superficial.
Both systems are very mature, very similar and have their pros and cons. Not to mention that they're copying each other a lot.
There's no jolly joker. The less upgrades you want the more you should think about managed platforms. Do you really have to actually write code to solve your client's problems?
Why do you stick to php?
The requirements you define put you in a position where there's no right choice for you. And the more seasoned you become, the more you'll see.
I suggest to start the requirements from the client needs and not from your preferred tech stack.
I don't see the comparison of Laravel 3 with Symfony 2... Never said that everything in symfony 2 is compatible with 4 but on a lot of thing are backward compatible and dependent of the bundle it might be compatible (if composer requirement allow it). In any case if the bundle is not about modifying core behaviour or advance stuff they are pretty easy to update following the guideline that are normally provided.
I have put less effort to migrate a medium size project (we should define medium) from Symfony 3 to 4...
But yes I do fount that Laravel enforce bad practices, never check the version 6 maybe the "fix" this but this is more a design choice than anything else. I do agree that they do copy each other, the same way Symfony did copy concept from Spring framework in Java and that Doctrine is greatly inspired from Hybernate too (at least a while ago).
For the "stick with php" I would make the point of knowing a stack on the tips of your finger help a lot. Maybe if you have a "expert" in every stack you may be able to pick the best stack every time but most of the time the best choice is to pick the stack that you have the resource to with. Than it's just a question of being professional and being able to let potential client that the stack you know and use is not well suited for there needs and refer someone else. From what I understand of the use case he might be alone in the company, having a lot of different technology may not be a option.
And if you have only one project a rule of thumb is to put the lowest amount of different technology in it, it's easier to maintain, document and find new employee if you need too. I am not saying that we should do "standard" web site rendering html because we don't want to add Angular in you stack, but you don't want to have php, node js, python in your backend stack just because you could. The same way you should not try to force php in to do a socket server for a real time application (like a game) even if it's possible, it's not made for that.
What I wanted to point out is that we could solve many of the problems without writing a single line of code.
I've been struggling with developers (incl myself) to open their minds and take a fresh look at the requirements without opening the IDE first.
Programmers have an obsession to the code. We should write much less code. Static sites don't necessarily require code (wix, managed wp, etc). Data processing and visualization doesn't require code (AWS Glue, Athena, QuickSight). Many many webshops don't require code (shopify, hosted magento, woocommerce).
I was surprised at my current work how many brilliant things were solved without writing code. It just needed non-programmers in the room.
Back to Laravel: I've been working with Symfony since 2007 and used to say this Laravel bad practice mantra as well. The reason was I never did a single project with Laravel, just opened the Laravel doc saw some static calls, went to some random forums, read ppl ranting about it and called it a day. Then we were kinda forced into a Laravel project and after a few months I've realized I knew nothing about Laravel before.
And then when I saw the new features of Symfony 4 at SymfonyCon in 2017 I was nodding because quite a few were concepts existing in Laravel. Dotenv, FQCN as service name in the DI container, Interface binding to implementation, class name based injection, the updated folder structure just to name a few.
We should be much more pragmatic about our profession and be less obsessed with the choice of technology.
Yes you are right about using tools that are not related too coding. He does it by using wordpress (pantheon offer and self hosted solution) and it would be worth to expand those solution with the tools you mention. Having a few tools predetermined for some use case to pick from is a good idea and evaluate where the project will go and the plan if it need to grow is the way to go. I am personally only working on project that is worth using symfony it's more a "if you could do it with word press or shopify, (or something else) go for it since it's the best solution but this is not what I do/work on."
For the laravel point I have been force to work with Laravel (version 4.*) and mhy opinion didn't change. I do agree that Symfony did bring some feature from Laravel, I think they did it better, but we could look at it another way Angular2 was doing injection with FQCN detection on service, did they do it before Laravel ? (I honestly don't know and don't care really) my point is that everything is getting better (I do hope so) and it's hard to know who did it first but having some serious competition help to push things further.
Why would you want to call yourself a programmer if you don't even code, if you want to do content management / admin work, be a data input guy.
Is there something you didn't like about Slim? I'm a massive fan of this microframework because it is minimal and has a good history of sticking close to accepted community standards. Then again, it doesn't include much, so if you are looking for a framework with a lot of pre-built pieces to throw together, it would not be the right choice.
Slim 4 is on board with PSR-15 and seems like the right choice for a seemingly good DIY developer such as you have presented here with a brief description of your projects.
All three are good choices. Our team of two has been maintaining 9 NOT small Laravel applications ( thousands of lines of application code ) for years. I gotta say it checks off everything on your TLDR; list. Straightforward upgrades, no blockers to being on most recent PHP, fabulous stability, and maximum ease of development for everything from a two page site to a beefy Enterprise web app. Again you probably are in good shape with Slim or Symfony as well and ultimately I think you should go with the one that you have the most fun using but I think Laravel would be an excellent choice that will make your work easy for years to come.
Do you use Shift for your updates?
We do for side projects but for work we can't let stuff out of the network per company security policy so we do manual upgrades on all our projects and packages every year. Takes about a week for one of us, it's really not bad once you've done it once. His upgrade guides are very thorough and we've never had a problem that wasn't addressed by the community within 24hrs or so, usually some obscure function signature that got changed that's used by a very small portion of the total install base and we just happen to be one of them. Having robust test coverage saves us from deploying it if it's not working. Almost never an issue on small projects that are using basic Eloquent features. But Shift is great if you can use it.
See that's a big concern of mine. If each upgrade takes a week. If I have 6 projects, that's a month & a half for every release. Yikes.
Oh, sorry, no, that's 10 apps and 12 private packages all in a few days for all of them. The individual migrations are maybe an hour max. With Shift it's even faster.
Oh, thank god! LOL
That's really good to hear actually. Thank you for sharing your experience!
Both Laravel and Symfony are awesome frameworks with their pros and cons.
Laravel is very easy to get started and has a lot of functionality ready for you.
This does not mean that Symfony is harder but it needs more work and initial configuration.
Having said that I would choose Symfony for 3 main reasons:
What I don't like in Laravel is the fact that you can access everything (container, request, session etc.) anywhere in the application code just by using Facades and helper functions. This will lead to poor and difficult to maintain code in my opinion.
In the end I would advise to study both frameworks. They have many similarities and you never know when that knowledge will come handy.
P.S.: To learn Symfony I highly recommend symfonycasts.com tutorials. Ryan Weaver is an awesome teacher and he is the lead for Symfony documentation.
Doctrine is a huge + for Symfony.
I am have maintained a legacy Laravel based solution (5.5), looking to start a green field project with Laravel 6, had a Symfony 4.1 solution and lost on which framework to use for a side project that I have been putting off for too long.
My heart is with API Platform (based on Symfony), but Laravel currently seems to be doing all the right things with developer experiences simplifying usages.
You are not crazy to leverage frameworks, because the more years you work with tech, the less code you want to write (since you will need to test, maintain and evolve it), as you get slower and have more responsibilities
The maintenance fees approach vary:
Oh I was never going to write what a framework does myself. Rather, just use a few stable packages for the small stuff.
I did the build my own framework thing 10 years ago. It's still in use. All this research is me moving away from the internal framework. :D
Great tips!
API Platform (based on Symfony) is the best thing that happened to me this year. I would be putting up a post with my experience on it soon 😎
Working with API platform on a real project was really painful for us. We got rid of it completely in the latest version of our api. (Still running on the previous version).
What were the blockers that you faced? How did it not fulfil your needs? I am keen to learn as I keep an eye on it for a future API driven project
Shameless advertisement, but if you like slim but you're prefer something smaller (Lines of Code) and less complex (Cyclomatic Complexity), please take a look at github.com/chubbyphp/chubbyphp-fra...
PS: Go for a microframework expressive, slim or mine (PSR7, PSR15 based). Not only are they easier to understand, but thanks their not event driven, easier to debug.
I would recommend laravel :
Thanks for your comment. Though to be honest, Laravel's instability is the root cause of my dilemma, or I would have jumped on Laravel without hesitation. I recently learned Laravel and created a college course on it - so I'd choose it if I could. But I get the impression that backward breaking changes are a frequent part of Laravel's updates. And things are changed and removed on a whim.
I hear that v6 is going to start using SemVer. Which is nice... but Taylor has expressed that this won't slow down the pace or style of updates for Laravel - so I suspect the major version number will jump up frequently which doesn't really solve the problem.
I think it's great that Laravel is going through this rapid evolution. I'm sure this is leading Laravel quickly to a really awesome state (it's already awesome), and if I had only one giant project to focus on I'd choose Laravel in a heartbeat. But since will potentially have many, many projects on the framework I choose, I can't be going through BC breaking updates so frequently.
LTS versions for laravel are supported for 2-3 years (bugs-security)
Symfony has 3-4 years of updates on their LTS versions
symfony.com/roadmap
Personally I use laravel (4.2 + 5.5) and never had problems with backwards incompatibility.
Upgrade paths are clearly documented, and there are also free and payed upgrade tools available.
If backward compatibility is that important, go for laravel LTS, which is either 5.5 or 6.0... That should settle your mind a bit...
I'm (actually) a fan of Rails, so if I translate that to the PHP world then that would be Laravel, which is indeed what I tend to use when I need to use PHP. However, I'm mostly building "applications" meaning that I definitely benefit from what Rails or Laravel have to offer.
Now, first thing that came to my mind as a was reading your post is "Laravel is probably overkill for 90% of the author's projects". But then at the end of your post I was reading "Ok to have one option for small stuff and one for big projects". So that made me think "Laravel" again.
(or did you actually mean two different options, one for small site and one for bigger sites?
In that case, for the small/simple website - why not forego PHP completely and go with a static site generator, Gatsby or Jekyll or Nextjs or whatever, and Github pages or Netlify instead?)
Anyway ... do most of your projects (even the simple ones) use a database (and for instance login)? If so then I'd say don't worry about 'Laravel is overkill'. If you have php 7.2 or higher installed, and you type this in your terminal:
then 30 seconds later you'll have created a simple and lightweight website called "blog". Next run the following command:
and you can view your site in the browser, a simple page with some links (instead of
php artisan serveyou can of course just use Apache or Nginx instead).Now, the app as just generated comes with authentication and database connectivity, however if you view your newly generated app (see above), then it will actually not hit the database or show a login screen. So it just works without a database, until you try to activate the authentication functionality.
As for the size of the generated app, most of it is in the "vendor" directory which is around 62MB. However, in production you can cut this in half (32MB) by running:
So that's going down to 32MB on the server (most of which would not be loaded or executed at all, and none of which would be downloaded by a user) - not a lot of overhead for your 'simple' site, and the good thing is that:
if ever your simple site needs to grow and become more complicated, Laravel has you covered, and for the smaller site it arguably doesn't get in your way
you get to utilize your Laravel experience for both the smaller and the bigger projects - call it leverage
One critical note:
I was referring to Ruby on Rails in the beginning. While it's undeniable that Laravel was inspired by Rails, I always get the feeling that Rails keeps it just a bit more simple and lightweight (call it elegant).
When I write Rails code I can do it pretty intuitively, with Laravel however I more often wonder "isn't this more complicated than it needs to be". But maybe that's just me, or it's the syntax of PHP which is more convoluted than Ruby.
By the way, I don't have experience with Symfony. I've read articles explaining that Symfony promotes "better architecture" than Laravel, however I believe Laravel is a bit simpler and easier to get stuff done. Symfony might be beneficial when you need to build really big and complex stuff.
I'm seeing some posts here about rolling your own framework, I'd like to advise against this for something that holds your client's personal data.
Have you thought of all the security implications of what your doing? Well you can be pretty sure that the developers of Symfony, Laravel, etc. have and are continuously testing their code for vulnerabilities. I'm also seeing posts about frameworks being slow, what's the scale of these web sites? If its not something humongous I don't think performance should stop you from using a framework...
I'm not saying that rolling your own framework isn't fun or a good learning experience, I'm just saying it's a lot of work to cover all the bases.
I have zero intention on rolling my own framework. That was my situation prior to this, and my research today is on replacing my internal framework.
Closest I would get is assembling some solid 3rd party packages for small projects.
Okay that's what I thought, I was more saying that for others who may be tempted to roll their own.
Have you considered using Drupal 8?
I manage a lot of WordPress and Drupal sites in my job and I have a similar experience to your own. Many of the sites I work with started off small, but later grow into something much larger. In my experience WordPress is not good at adapting to this sort of growth without using lots of badly built and vulnerable plugins. Drupal 8 on the other hand is actually based on Symfony and while it has a steeper learning curve it really encourages good code which helps with maintenance over time. It also has a dedicated security team that regularly review plugins (modules in the Drupal world). You should give Drupal 8 a shot.
I may be a little late to the game, but...full disclosure I have about 20 years experience with PHP, I've used Cake (large oil & gas company and large computer manufacturer), CodeIgniter (also at o&g company), and for the past 4-ish years Symfony (3.x) for a smaller HR company (we're now migrating to 4.x and it's pretty painless). None of what I've developed would equate to a small site with little traffic. We're (small dev team) tasked with keeping things current/up to date and Symfony has been the easiest to update relative to the other frameworks (very few bc breaks). With the built in debugger, extensive logging, and well written framework error messages, pinpointing a problem is much easier in Symfony than the other frameworks though that may have changed over time.
It's completely possible to wire your ORM or heavy business logic into a Twig template if you work at it in Symfony - but you shouldn't. Symfony doesn't so much enforce good coding as it encourages it. You can bloat up your controllers with business logic, forms, and all sorts of junk or you can spin your business logic off into services, put your queries in reusable libraries, write a mess of reusable twig filters, and get your controllers down to a scant dozen or so lines of code.
I only have about 2 months of experience with Laravel - just long enough to know it's just too tempting for me to wire things incorrectly "just to test something out". I know I'd be coming back in 6 months to try to fix that little shortcut and it would be pinned in place by 20 other things that grew off of it in the meantime. Laravel to me seemed like it would be a great framework to knock together a quick prototype/proof of concept.
My vote would obviously be for Symfony - it's not really a beast to set up, you can spin up a default Symfony project in a minute or two with composer. In a few more minutes you can have a workable prototype - a few views and matching controllers, some queries/repositories/tables using Doctrine. Symfony 4 with Flex is really nice. I imagine you could say most frameworks are overkill if you're doing simple websites but I'd still use Symfony - if the site starts to grow you've got the ability to bolt on all sorts of stuff, if not, you're good where you are. Look into the Symfony LTS versions - read up on their release processes, backwards compatibility promise, how frequently they release, etc. symfony.com/doc/current/contributi...
Good luck with the decision if you haven't already made one.
Thank you. This was a very nicely detailed reply. And very much in line with the conclusion I came to as well.
Hey, I work at a small dev agency and we primarily switch between 2 PHP technologies depending on the requirements. These tend to boil down to how large the project is and how much editing the client will do.
We will use laravel for a bigger web application, where the client won't be doing much editing. Obviously laravel is not a one click upgrade but if you use pick a LTS version to build on (6 has just been released) then it'll be supported for a few years with security patches and bug fixes.
The other route we go down is Craft CMS. We use this when a great authoring experience is key and there's lots of client editing. Think if it as a pretty version of WordPress that is built on a stable PHP framework, Yii. This makes it easy to extend as your client requirements grow, it has a one click upgrade and is extremely developer focused. It also has the benefit of only needing to maintain one system, not a separate PHP application and a WordPress installation
Check it out! Hope this helps.
Symfony 4 I think is good choice now, it's getting simple and faster, thanks to PHP 7.x as well.
I have old legacy PHP web that use no framework, but after I using Symfony, I try create my own framework by using some key components from Symfony, what is that? The Twig templating system and the routing component, plus composer ready, the rest code is my own PHP way, even still use mysqli_* functions hahah. Search on GitHub called Brutal PHP Framework but it still work in progress but maybe you can get the idea.