Can we delete the Resources folder in Laravel after building the project? - php

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.

Related

Using external css/js files stored outside the public folder in laravel

I downloaded a laravel source code, and I have been told that the CSS/js files of your application should be stored in the public folder but I noticed that the CSS/js files that the downloaded laravel application used were stored outside the public folder and even outside the entire laravel application folder, and these CSS/js files were accessed within the laravel application. And I also noticed that some of the files that originally comes out of the box with laravel in the public folder were taken out of the public folder and placed outside the application. So my question is,
Is this accepted?
How do I do it?
Laravels public folder is where your website access files. be it request to API's, CSS, js, html files, images.
It's not a good idea to place your css/js directly into the public folder. Unless you are just doing it for learning purposes or your just doing a fairly simple project.
CSS and JS files that are stored into the public folder should be the compiled and minified versions of it.
You did not clarrified what exactly you are doing. But if that's a fresh laravel install with Vue.js, you should place your css/scss/sass files into /resources/sass folder and js files into /resources/js and let webpack compile it for you. Webpack will be the one to put this compiled versions into the public folder.
Check webpack.mix.js file into your laravel root folder. It should provide you some info on how to compile your assets/css/js files accordingly.

Laravel within a wordpress application

Context:
I have a customer who wishes to have two small web applications built within his current WordPress application. Since I always work with a combination of Laravel / VueJS, I decided to integrate this application into WordPress. The size of the application is so small, that it would be a waste of time for me to dive into an other framework or using bare php.
Problem:
The web applications have to reside in the public_html folder, see below. Laravel sets the public path, which in this case is not correct. Packages/plugins also rely on this, as does Laravel mix. Because WordPress also resides in the public_html folder, this folder already contains an index.php, and some other php files. While I can place the Laravel folder structure outside public_html (security measures), I need to find a place for Laravel's index file, which also needs the adjustments so everything that needs to be accessible, is accessible.
Just to be clear. The applications will have 2 URL's which will reroute to Laravel.
xxx.com/declaraties/yyy
xxx.com/rapportages/yyy
Folder structure:
/root folder (welcome to shared hosting....)
/app
/bootstrap
/config
/database
/node_modules
/public_html
/wordpress folders
/declaraties (web app 1)
favicon
assets etc
/rapportages (web app 2)
favicon
assets etc
/resources
/routes
/storage
/vendor
laravel related files (env, artisan, server.php, etc)
Any help towards a solution would be greatly appreciated.
I think you can have a try with Laraish, a WordPress theme that uses Laravel.

Updating public/assets vs. resources/assets folder in Laravel, managing assets with Bower / Gulp

I am just starting to learn Laravel and have some questions about the directory structure, updating with composer, gulp, bower, the "public" folder, "resources", etc. Sorry, I am a newbie.
I got a Laravel Admin template online, so the setup there may be different than the raw install, but it seems basically the same:
app
bootstrap
config
database
public
resources
storage
tests
vendor
My question regards the assets folder under public and the assets folder under resources. The template that I have uses gulp and bower, so my question is if I change some css or javascript for one of my files, should I do that in the /resources/assets path or the /public/assets path ? Seems like you should update the resources and then do update with bower and gulp, otherwise your changes could get overwritten. Does that apply to everything in the /resources/assets path ? Update there and then update your /public/assets path ?
It does seem a little strange that the resources folder is essentially your development assets that can be compiled, but the views are in the resources folder, not the public folder. Is that because they are xxx.blade files.php files, development files and are sort of compiled into xxx.php virtual files in the public directory at runtime ?
You use Gulp and Bower to compile your custom assets in a more efficient way. If the template you downloaded makes use of these tools then you need to make your changes in the source files you feed Gulp/Bower and they take care of the rest and place the results in /resources/assets.
The /public/assets folder is where you or the template you downloaded save assets won't be edited by Gulp/Bower and can be accessible from the root path of your project. What ever you edit here will be kept like that until you make any manual modification again.

Yii's asseets folder with no write access

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.

Where should my system and addons folders reside for PyroCMS?

I have just completed a fresh install of PyroCMS on a dev server and it appears that the system and addons folder reside above the document root folder within "public_html".
PyroCMS is based off of CodeIgniter and every time I did a CodeIgniter install it always had me place the system folder below the document root for security purposes. Shouldn't this be true with the PyroCMS install?
Modules require assets, which of course means HTTP access is required. We plan to eventually improve the Asset helper to GZIP/minify/combine everything and pass it through an "asset" controller, meaning images can be cached and resized, javascript can be squashed, etc.
Putting everything through a PHP file in this way means eventually you'll be able to have everything outside of the public folder, but for now you need direct access or you are entirely screwing with your chances of having a theme with images, css, javascript or icons.
Just don't tell Apache to serve PHP files as text/plain and you'll be absolutely fine. ;-)

Categories