Which folders I'm supposed to mark as Sources/Resources/Excluded?
My own logic based on the PHPStorm guide
Sources
The root folder
reasoning: Your source code can be in mutliple folder inside the root.
alternative: Just mark the real folder you have your code inside app, bootstrap, config, routes, (more...)
Click this button to mark the selected folder as the root for
namespaces used in your project. Based on this setting, PhpStorm
suggests you the proper folder name when you want to create a new
namespace under another parent namespace during creation or moving a
PHP class, that is, when you are actually creating or moving a PHP
class to a non-existing namespace under another parent namespace. If
no Sources folder is specified, you will have to type the proper
folder manually.
Appointing a Sources folder is not mandatory but this helps you keep
your project structure in compliance with the PSR0 and PSR4 standards.
See Configuring PHP Namespaces in a Project for details.
Tests
tests
reasoning: For obvious reasons your tests live there by default. It might be possible you use some test library for your javascript code that lives in another folder.
Click this button to mark the selected folder as a test root.
Excluded
vendor, storage, node_modules
reasoning: All (composer) libraries we use in our project live in vendor, but are not our own code. We should not search trough it by default.
In storage live caching files, files that have no significant meaning to us, we do not track them in version control (like vendor). We could just delete them and the application would still work. Same for node_modules, but this directory is for javascript packages.
Click this button to mark the selected folder as excluded so PhpStorm
ignores it during indexing, parsing, and code completion.
Resource Root
public
reasoning: Your own frontend assets should be (somewhere) under the public folder to serve to the browser. Frontend assets are (mostly?) files, javascript and css.
Click this button to enable PhpStorm to complete relative paths to
resources under the selected folder.
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.
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.
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
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. ;-)
I can't find much information about Yii's AssetManager for the management of JS and CSS files. My question here is what is the point of using the AssetManager? I'm not sure what value it adds to my development process, in fact, it seems like it complicates my code... every time I change my scripts or css code, I have to go in and delete my assets folder to make sure I have the latest versions.
Seems it is much simpler to just put all Javascript files under /webroot/js/ and just use the tags to load the files instead of going through the trouble of AssetManager. Plus, Yii's registerCoreScript function always places script tags inside the header tag, instead of placing them at the bottom of the code, near the closing body tag, as recommended by YSlow.
I think there must be a gap in my understanding of Yii's AssetManager. Anybody have any ideas why using the AssetManager is better than hard-coding the script tags inside the PHP code? I'm a bit confused...
Thanks!
I'm sure someone can answer this better than myself, but basically it's so that your source JS and CSS files can remain in your Protected folder.
This is a little more secure for one thing, but the main benefit to me is that you can compress and minify and otherwise process your assets with the asset publishing system, and it makes it easier to host your JS and CSS on a CDN since it's separate from your codebase.
Also, here's an official response from qiang (the guy who wrote Yii) about this.
The main benefit of Yii's asset manager is that it allows you to structure your components in a self-contained manner.
A tale of a widget
Consider a component that is a UI widget. Let's assume the distribution includes a couple of assets along with the component implementation, for example these files:
SuperWidget.php
superwidget.css
superwidget.js
image_for_css.png
Consider how you would incorporate this widget into your application if the asset manager did not exist. Typical steps might include:
Copy SuperWidget.php somewhere inside the protected/ directory
Copy superwidget.js to your js/ directory
Copy superwidget.css to your css/ directory
Copy image_for_css.png to your images/ directory or perhaps also inside css/ to help reduce the relative path dependencies
Then at runtime SuperWidget would emit appropriate tags to include the CSS and JavaScript; to do this, it would need to know where exactly you have placed these assets. In other words: some choices regarding the installation can be made arbitrarily, but then they are set in stone unless you go and edit the source.
Is the widget reusable?
If this widget were highly customized and meant to be an inseparable part of your application then this approach would work fine and there wouldn't be much need to have an asset manager. But what if it's a broadly useful component that you want to distribute?
Problems start arising.
First of all the deployment scheme we have examined requires users of the widget to copy different files into different directories, complicating the installation procedure and increasing the chance of error.
But the greater issue is that your deployment scheme could conflict with that of any other component developed independently of yours. What if someone else decided to have a superwidget.js file too?
If the installation instructions for these two components conflict then obviously one of them cannot be installed as intended, and then you resort to changing some details and hacking the source code of the component to accommodate these changes. If you later upgrade to a newer version of that component you will be forced to carefully account for your customizations, making a "copy/overwrite" upgrade impossible.
All of this is really not pretty, and while it can be unlikely to happen in practice it certainly doesn't feel right.
Asset manager, make it so
Here's where the asset manager comes in. Let's assume you decide to structure your component like this:
superwidget/
SuperWidget.php
assets/
css/
superwidget.css
js/
superwidget.js
images/
image_for_css.png
You can directly copy this somewhere inside your protected/ directory no matter what other components you have installed; the worst thing that could happen here is that you'd have to rename superwidget/ to something else if there was a conflict.
Using the asset manager, SuperWidget.php publishes the whole superwidget/assets/ directory, with the copy ending up at e.g. assets/1337c0de/ where assets/ is your application's base asset path and 1337c0de/ is a random hash created by Yii and guaranteed to not conflict with any other published asset.
This means that the assets for SuperWidget cannot possibly conflict with those of any other component, making SuperWidget truly reusable. And since the directory structure inside 1337c0de/ will be the same as in your distribution, CSS can refer to images using the relative path ../images/ without needing to refer to the value of the random hash (which is only know after publishing).
What the asset manager is not
It's not a way to increase security. Your component source would be somewhere inside protected/ anyway (so no improvement there), and the assets need to be web-accessible no matter where they end up being copied (no security for them no matter what).
It's not a catch-all solution for processing your assets (e.g. minifying CSS). While it is possible to install a custom asset manager that does this, don't forget that assets included with reusable components will a small minority among all of your "base application" assets; if you want minification across the board, you 'll have to also process everything else and the asset manager will not help you there.
TL;DR
The asset manager allows you make components that are easily distributable and can be included in applications without the fear of creating conflicts with other components.
Another perk that I like about the asset manager, is that it allows you to update your asset files without having to tell your users to clear their cache.
http://www.yiiframework.com/wiki/311/assetmanager-clearing-browser-s-cache-on-site-update/