You have some usernames and passwords (to what looks like production servers) sprinkled throughout your app. May need to change those ASAP, wipe your history, or something.
Lots of suggestions:
* Don't write your own cron scripts, use Symfony Commands.
* Delete the Acme Bundle.
* Don't store your vendor directory in Git! Completely unnecessary and waste of 47MB.
* Don't commit parameters.yml, that's what parameters.yml.dist is for.
* Use a migration tool (Doctrine Migrations are fine) instead of one big SQL dump.
* Not sure what mongodb/example.php is for.
* Why is all the plivo stuff in web/plivo/ instead of being a callable controller?
* Are you manually generating your Doctrine entities?
* Don't commit your asset directories (they should be symlinks).
* No need to use PHPMailer (or include the entire project in your repository), Symfony comes with Swiftmailer which is great.
The design looks great, but I wouldn't trust a lot of this (especially after seeing how many hosts and usernames and passwords you left scattered about).
If it works, does any of this matter right now? He's trying to make his business survive, not craft a work of technical art. Shouldn't he spend his time on marketing if the thing works?
actually, there's no big big items but opensourcing isnt magic, you want people to look at it.
if the project looks nicely managed, its a lot more attractive :)
Hey man, thanks for existing. The amount of money I make from cleaning up after dipshits who think "just throw some spaghetti at the wall, we'll deal with making it sustainable and secure later" keeps me almost embarrassingly busy. Of course, I'm as often as not the last money they spend, because if that's how you're running your business, you're screwed anyway. Keep being ignorant; keep writing me checks.
This is precisely the type of attitude that would cause me to not want to even start on a side project. I'm floored whenever someone puts up a side project for feedback, and then a flood of high-quality technical feedback comes on how to improve things. That is cool. This is not.
It's not the attitude of saying that security isn't taken seriously that gets me upset. It's the condescension. Let people learn by making mistakes, sometimes there's no other feasible way. Think of how to be helpful, not condescending.
And I think the attitude that "screw security...shipping is all that's important" is monumentally condescending, and shows incredibly poor business skills. It's saying "look, fuck the customers and whatever data we may collect about them, as long as we launch". And it's not a zero-sum game; you get a long way to "good security" with "good coding practices" and some "good testing". The only real up side to having to clean up the mess after some snotty brogrammers who's only response to "you just dumped the PII for 25k customers into the black-hat market" is "So? We got 25k customers!" is being able to respond "not any more".
> Don't store your vendor directory in Git! Completely unnecessary and waste of 47MB.
While 47MB is indeed a bit large, storing vendor libraries alongside your code makes sure you have a working version when you pull down the repo. Nothing more frustrating than hunting down why the code you just checked out doesn't work.
> Don't commit your asset directories (they should be symlinks).
That depends on what you mean by assets. If there are binary assets needed for the app to run, they must be included. Imagine downloading a web app with all the icons and textures missing. Not good. And if source files exist for these assets, they should be in the repo, too (like PSDs or Inkscape SVGs)
All of my repo's have a 'build-dev' script in the root of the repository (see here: https://github.com/brightmarch/picto/blob/master/build-dev). Run that after you pull it down and it builds the environment for you (minus setting up Vagrant).
You should commit your asset files in the Bundle, but not the ones in web/bundles/ because those are created by copying or symlinking the assets in your Bundle.
or use composer, and commit composer.lock to ensure when composer install is run you'll get the dependency versions that are meant to ship with the release.
There is a composer.json and composer.lock file in the repository. All you'd need to do to download all the dependencies is have composer installed and run "composer install".
"application build process" or simply the checkout process? I'd suggest your deployment process shouldn't include a public git repo others can change. Instead, use your own fork on Github, or alternatively host a git repo local to your deploy network. After all, you're trying to avoid dependencies on things like Github working/failing, right? ;-)
I know what you are meant to do is check in your composer.json and composer.lock then do a composer install on the server.
But then you have a external dependency on your install process on live servers, which is a terrible idea. To got around this, I've seen companies say "we have our own package mirror". Or you could just check in the vendor folder?
Another reason I do it: My software package is used by people who aren't PHP programmers and I want them to be able to just grab the files and go with no fuss.
I do appreciate having the vendor folder in git takes space and is a pain ... but I think the trade off is worth it.
Thank you, this is fantastic feedback. Sorry for not applying sooner, but my account was blocked from making comments (apparently I was trying to post too frequently!).
Passwords were changed the second you mentioned them, and we'll be making all of these changes as soon as possible.
This is the thing about open source. Any one can make these improvements. Maybe you could open github issues for these suggestions and someone could have a go at making the patches.
How would you synchronise between versioning the symlinked assets and the app itself? Or do you just keep all images, for example, until you're simply sure you don't need them anymore?
Lots of suggestions:
* Don't write your own cron scripts, use Symfony Commands.
* Delete the Acme Bundle.
* Don't store your vendor directory in Git! Completely unnecessary and waste of 47MB.
* Don't commit parameters.yml, that's what parameters.yml.dist is for.
* Use a migration tool (Doctrine Migrations are fine) instead of one big SQL dump.
* Not sure what mongodb/example.php is for.
* Why is all the plivo stuff in web/plivo/ instead of being a callable controller?
* Are you manually generating your Doctrine entities?
* Don't commit your asset directories (they should be symlinks).
* No need to use PHPMailer (or include the entire project in your repository), Symfony comes with Swiftmailer which is great.
* Same with src/Phone, add that library through Composer (https://packagist.org/packages/practo/libphonenumber-for-php).
The design looks great, but I wouldn't trust a lot of this (especially after seeing how many hosts and usernames and passwords you left scattered about).