Laravel 4 - cloning the local project on the VPS

Question

I use Laravel 4 to develop my projects.

I develop on my Mac, commit to Git, then clone it on the server (linode 1G VPS).

Since "vendor" folder is by default "GIT-ignored", I usually do "composer install" after cloning the project on the server.

After that, any other packages I install locally, I do "composer update" on the server.

Yesterday, I reported this problem - PHP Composer update "cannot allocate memory" error (using Laravel 4)

So far, I have not found a solution. I even tried to do a "fresh" cloning and "composer install", it's giving me the memory error. This is extremely frustrating.

My question is then, is it ok to just upload my entire project to the server? Since "vendor" folder is only thing that is "git-ignored", if I just copy everything there, would it work? (I haven't tried it since my server is alive at the moment and I don't want to damage anything).

What is the actual role of "compiled.php" file? Is it platform dependent? Can I copy that file too?

I've seen this memory issue quite a few times now and read other people reporting the similar issue. I hope I can just upload the entire project folder and cross my fingers that it will work.

Thanks for your help!

Answer 1

I do not have VPS, or even shell access to my custom/shared hosting from my provider, but I can run git and composer commands without that.

Use sshfs http://osxfuse.github.io/
sshfs actually does SFTP connection to your server and mounts server to local directory.
This way, you can run git and composer commands localy. You do not depend on your VPS/hosting server. sshfs sends files in background to remote server.

To mount VPS to local dir, run this

sshfs user@serverip:. /path/to/existing/local/dir // to mount root dir
cd !$ // to get into mounted dir

// or

sshfs user@serverip:foldername /path/to/existing/local/dir // to mount specific dir
cd !$ // to get into mounted dir

Now you can do whatever you want.

Answer 2

a good thing to know for you - it is possible to set up Laravel config in such a way, that the same app (the very same copy of code) can act differently on different servers (environments).

I am wrtiting that, because if you sync your remote server with a local copy of the code sooner or later you will stumble upon issues like changing the db credentials or app setup after every sync - which of course doesn't make sense :)

Check out Laravel 4 Docs Environment configuration to read more about that, or follow this tutorial by Andrew Elkins - How to set Laravel 4 Environments

The environment is based on url matches.

You’ll find that configuration in /bootstrap/start.php

$env = $app->detectEnvironment(array(

'local' => array('your-machine-name'),

));

Now say you are developing locally and use the prefix/postfix local. E.g: my-new-site.local or local.my-new-site

$env = $app->detectEnvironment(array(

'local' => array('local.*','*.local'),

));

That sets the environment, now to use it you’ll need to create a local folder in /app/config/

1 mkdir app/config/local

And so you want to have a different database configuration for local. Just copy the database config file in to the local directory and modify it.

1 cp app/config/database.php app/config/local/database.php

To sum up and answer your question:

1) I guess it's OK to copy the whole project dir to remote server (although, if your copying vendor it might take a lot of time - it usually contains a big number of files)

2) if you do so, remember to have the updated composer.json on remote server (to reflect all the necessary requirements)

3) If you are using different database servers local and remote - you obviously have to run migrations and seeders on the remote server (this concernes also package migrations/seeds)

4) after you migrate all your files, do

composer dump-autoload
php artisan optimize --force --env=YourProductionEnvironmentName

which should rebuild the bootstrap/autoloaders

5) if you are using the Laravel Environments setup mentioned above, remember to have your remote server seen as production (if your local is testing/staging).