We are deploying a new Laravel 5 installation and our client has said that they are unable to provide a writable directory on the web space that we are running on.
Is there any way that the storage folder can be by-passed when deploying the Laravel installation as I can only see logs and session based data that I am storing in MySQL anyway.
From Laravel official documentation
The storage directory contains compiled Blade templates, file based sessions, file caches, and other files generated by the framework. This folder is segregated into app, framework, and logs directories. The app directory may be used to store any files utilized by your application. The framework directory is used to store framework generated files and caches. Finally, the logs directory contains your application's log files.
You could prevent laravel from using the storage folder only if you modify the core files of the framework, because this is how laravel is set up to work.
I strongly advise you against that. Just migrate to another enviroment and get write permissions for that folder.
I know that this is not a proper solution, but it seems more harmful to your application structure and integrity to do core level modification.
By the way, you can move the storage to somewhere else... To the temp folder?
If that's a good opportunity for you, you can use:
$app->useStoragePath("/tmp/laravel_storage/");
Don't forget to build up the folder structure there (i.e. creating sessions, files, ...)
Related
In Laravel 9 where it uses Vite to bundle the js and css files, after running
npm run build
it created the bundled js and css files inside public/build folder.
Can we now delete the original js and css files that are created inside resources? or to upload the project to hosting without this resources folder?
Also, if I have other css/js files but not inside Resources folder, should I add them manually to the input array inside the vite.config.js file to get them compiled and bundled ?
Thanks
It depends on the assets you have in resources directory.
This directory can hold un-compiled front-end assets such as CSS or JavaScript - those will be bundled and available in public folder and served from there, therefore it's safe to delete them on the shared hosting.
However, this directory can also hold backend assets like views, and those files will be read by Laravel directly on shared hosting. If you delete them, your Laravel application will crash.
Therefore, if the only assets you have in the folder are frontend ones that are bundled and served from public, it is safe to remove this directory, howevever there won't be any performance improvement coming from that.
Let's say I have a Job that generates an avatar image through Intervention with the username on top of a static default background image. This background image should be available for each project member, so it should life somewhere in the repo.
My question is: where does this static background image life?
When I take a look at the Laravel docs about the Directory Structure I conclude that:
It should not life in the public directory, since it does not have to be publicly accessible (the image itself is never used without the username on it)
The public directory contains the index.php file, which is the entry point for all requests entering your application and configures autoloading. This directory also houses your assets such as images, JavaScript, and CSS.
It should not life in the storage directory, since this folder seems to be for generated stuff (and is subject to overwrites)
The storage directory contains your compiled Blade templates, file based sessions, file caches, and other files generated by the framework. [...]
It could maybe life in the resources directory, since this directory contains "raw, un-compiled assets". But the fact that images are not used as an example it makes me doubt.
The resources directory contains your views as well as your raw, un-compiled assets such as LESS, SASS, or JavaScript. This directory also houses all of your language files.
What are your opinions on this question?
First off, your application shouldn't depend on the file being in the same filesystem. You should use the Laravel Storage API, since that way you can easily store the files on a third party storage solution such as Amazon S3 without having to change anything other than a config setting.
With the local driver, the files would default to being stored under storage/app, which I would consider the correct location. It's actually recommended that if a file needs to be publicly accessible, it should be stored in storage/app/public/, which should be symlinked to public/.
As you have observed, the public directory is for anything that needs to be publicly accessible, including compiled Less/Sass, JavaScript and images. The resources directory is for their uncompiled counterparts, so your Less/Sass files and JavaScript should go there before being processed by Mix. The storage folder is for more general file storage use, but I would have a look at the possibility of storing these files with a third party service.
Can somebody explain in brief the use of assets folder in yii framework. I am new to yii framework
Many newcomers ask: "What do we do with the assets folder?", and the answer is "Mostly nothing".
It's important that the directory be writable by the webserver user so that Yii can publish the resources there when needed.
When a project has multiple versions (production, testing, development, etc.) do not copy the assets/ folders from one area to another; allow Yii to deploy them automatically in each area.
Do not manually edit any file under assets/ - if you have a real need to make a change, find the publishing module, edit the source, delete the subfolder under assets/, and let Yii re-publish the updated files.
Do not reference names under the assets/ folder directly (say, to get at some other module's assets). If you need to use that
Do not add the contents of the assets/ folder to any source-code control system; these files have master source in other places.
It is safe to delete everything under assets/. Yii will re-publish the assets if they are not found under assets/.
Additional info
Yii makes assets accessible by Web clients, so the goal of copying assets to a Web-accessible directory is fulfilled and returns the corresponding URL for accessing them.
Read it from http://www.yiiframework.com/doc/api/1.1/CAssetManager
Am I correct in thinking, a dist directory and a build directory are both production directories that contain the files that need to be deployed to the web server.
Which to use?
A dist directory could have both files that are used during development (.php, etc), and files that are generated from a build script (.min.js, etc).
A build directory, however is entirely made up of files from a build script, and no development should take place within the build directory.
So, are these assumptions correct? Also, I realize that if you are using a framework, you'd use their conventions. I am just wondering, what these naming conventions are generally, if you were to create say a php project from scratch.
In a generic sense - a dist dir is for distribution. It is prod ready and can be distributed to other users who want to try it for beta testing, production use, whatever. A build dir is when you have ran you pre-deployment script manually or automatically and created a resource that can now be deployed (usually not distributed) into one or multiple production servers. This could contain sometimes just a tarball which can then be un-tarred and installed on the server.
Annoying naming practices..varies from people to people and organization to organization and technology to technology
I am trying to deploy a PHP Yii app to Orchestra (https://www.engineyard.com/products/orchestra/). The platform, like I think many cloud-based platform, doesn't allow write permissions.
I've managed to get around the 'runtime' directory that Yii requires by putting it in the system's tmp folder. However I'm stuck with the 'assets' folder. Yii requires a writable AND publicly accessible folder.
Is there a way around this?
Yii requires somewhere to put the files from within the core or modules to be publicly accessible.
If this isn't possible you might have to go through and manually grab each js/css file your going to want, place them in the folders required and use scriptMap to map these back or block them and include them yourself.
There's lots of documentation around Client Script which is what handles all this.