I have a Laravel 4.2 application and it in production environment.
Sometime i have bug fixes or updates for it in the local edition, I want to know how do i move these changes from local to production.
Replacing just the file/class that was changed doesn't work. I tried replacing just the controller file but it doesn't work.
Does Laravel compile the code somewhere that i need to upload to production server, What all do i need to change/upload in production to reflect the changes?
By default, PHP is not a compiled language, so changed and uploaded files will work without any special process. Laravel is just PHP, so it follows the same rules.
However, Laravel uses an autoloader that keeps track of all of your classes. When you add a new class, you need to tell the autoloader that it exists by running:
composer dump-autoload
This will scan the available classes and update the autoloader list.
If the problem persists after you run composer dump-autoload, or if you did not add any new classes, there are three potential problems to consider:
Did you upload the files correctly?
Log onto the production server and look at the timestamp of the uploaded files. Do they match your expectation? Consider opening the files in production to see if they contain your latest changes.
Do you have a caching or compiling system in place?
While PHP is not compiled by default, there are tools available that allow you to compile it, and other tools that allow you to cache the output of the scripts. Ask your server administrator if any of these tools are being used.
Do your changes perform as expected?
Finally, check to see if your changes are in production, but not operating in the way that you expect.
Related
I am trying to make changes to the Spark Laravel BillingPortal.vue page. After making a change I know the the app.js is being compiled but I see no change in the billing page.
I have cleared the cache in Laravel and the browser and still not luck.
I can completely delete all code on the page and still nothing happens. It is still the same in the browser.
Please tell me how to change this file.
The BillingPortal.vue file compiles into Spark's /public/js/app.js file, so in order to see any updates you'll need to rebuild Spark's JavaScript separately from your application's assets.
cd vendor/laravel/spark-stripe (or vendor/laravel/spark-paddle if you're using Spark Paddle)
npm install
npm run dev
That being said, it's not recommended that you make changes to Composer packages because the changes will be overwritten when the package is updated. Instead choose one of the options mentioned in these answers
I'm following the installation docs for Backpack 4.1 for Laravel. The backpack:install Artisan command adds front-end assets to the /public/packages directory of my project. Usually, front-end package managers (NPM, Yarn, Bower, etc.) recommend not to add the actual package contents to a project's repository, and instead add a dependency lockfile that can be re-installed by a CI/CD pipeline. Backpack does this differently, as it pulls the front-end dependencies directly and there was no mention if one needs to add /public/packages to source control. Should I add these package assets to source control, or should I execute php artisan backpack:install in the CI/CD process instead?
Yes - you should include the public/packages directory in your source control. That’s what Backpack assumes you’ll do.
However, if you would rather NOT do that, you can create an alias to the directory in the package. You can find instructions on how to do that here, as method 3 - https://backpackforlaravel.com/articles/tips-and-tricks/once-in-a-while-re-publish-backpack-s-css-and-js-assets
There are several reasons why you might want to do commit the public assets to the source control:
You may not have write access to your production file system.
You may be deploying to more than one server, and want to avoid duplication of work.
You may be doing frequent deploys that do not include asset changes.
Generally, I think it is a good idea to put precompiled assets into source control unless you have a specific reason not to do so.
This may be a stupid question but after a fair bit of googling i and still unsure weather i should be removing the the composer.phar file after installation. Is the files just part of the installation or required to run the application ?
The Composer executable is used to manage your dependencies, which is mostly "update" and "install". The result is an autogenerated autoloader and a complete tree of files from the required packages of the application.
The executable itself is not part of the application and therefore is not needed to run it. For security reasons it should not be present on the live servers unless you really know it has to be there, because it seems like a good idea to not give an attacker some useful tools into their hands.
The proper places to have the executable are your development environment (in order to add new packages and update the old ones) and the deployment server that puts the application onto the live server (otherwise you cannot install the packages that your application runs with).
I know that people tend to create a workflow that simply pushes a branch to production, and a post-transmit hook then runs composer install, but this is dangerous from a reliability standpoint: What if Github has an unexpected downtime and you push to production, unable to download the new packages? In this scenario, the server doing the deployment actually is the production server and so requires a copy of the Composer executable, but I explained that this is no ideal setup.
Although I'm new to Laravel 4, there has been one question on my mind since day one which I cannot seem to understand, nor find any information on.
My plan is to build an open source web application, which other users will be able to download and use on their own server. Now my current way of working is:
Install Laravel with composer
Add packages to composer than I need for the application
Start coding: editing files directly inside of app/ (global.php, routes, controllers, views, migrations etc).
Keep all of my assets within /public/assets/
This works fine for me, and I have no problems with it. However the question is:
How will I deploy the application to users if I build it this way? If they install Laravel via composer, all of the files within /app will be default (obviously), so how would I go about getting my edited + custom files into their install of Laravel?
Do I have to build the whole application as part of my own bundle? Or is there some kind of way composer can pacakge what I've done to solve this problem I can see happening?
I'm just throwing words out, if someone could explain and point me in the right direction that would be great.
Thanks.
You can just chuck all your files on github. You dont need to include composer. People can download composer and run it from the install directory (or if they have it globally run it from there)
If you run a composer install with laravel 4 only, it will download all fresh. In your case you just have all the library's in place already. So for future updates you as a developer can easilly upgrade to a newer version. The "users" can simply say "git pull" to update their instance. You still need composer to do your initial install (db seed, post install steps etc)
At least that is my point of view. Just look at a simple laravel 4 bootstrap example https://github.com/andrew13/Laravel-4-Bootstrap-Starter-Site it also holds all the files.
I wonder what I should be carefull of updating PHP on Windows(with Apache). My current version is 5.2.9-2
My php folder is simply under C:\php
If I simply download and unzip the new version, 5.3, which is a little more significant than going from 5.2.8 to 5.2.9, I'm thinking I need to be carefull not to overwrite some files.
I'm thinking 5.3 will have some changes in the .ini file. My .ini file allready has some modules activated and such, but if I leave the old .ini file, I might have some incompatibilities.
So, what incompatibilities and other risk do I need to look out for? I don't have any experience updating this, and I fear I might loose things and will just end up having to delete and make a clean install and then edit everything again, which is painfull.
Don't do it on a live environment until you've tested.
Php 5.3 contains enough changes/new stuff that i would be wary of either issues with the server config, as you've suggested, but also enough that I'd want to test my app to check it still worked correctly under 5.3 as well.