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.
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 use symbolic links in my web project. There is a source folder and an additional folder for an email task which is executed by a service.
Both the website and the task are written in PHP and use my util.php, sql_functions.php and config.php files.
Rather than hardcoding the locations of these three files, I created symbolic links to these three utility files and some directories so that they are available from each of my subdirectories. The code works.
I also created a batch file which automatically creates these links and documented the installation procedure.
Below you can find a screenshot of the folder that contains my email task. sql_functions.php loads the configuration data and is being used by email.php to access the SQL Server. The symlink to the sql folder also helps.
All of these folders are in the same repository, so there is no real risk that any dependencies might not be loaded.
It just feels like dirty programming.
Although symbolic links by themselves shouldn't be harmful to the understanding and maintaining of the codebase, your case in kind of brutal. Puting a symlink in everyone of your files looks like overkill there. There are more options than just choosing betwen hardcodes paths and such a violent solution.
For example, you could set the path of these files in a constant that is loaded at the begining of each files through a require(), or many others solutions. In the end, it depends on the way your website works, but I doubt your solution is the most flexible you could come up with.
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.
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 am developing a Joomla Component which will allow visitors to download a sound file (be it mp3, or wave, does not matter). Those files are managed in the admin interface and can be unpublished in there.
Therefore, it seems that placing them in the assets section is not an option, as it would make them accessible directly from the server. I want to avoid direct access and only serve them through my MVC structure (usnig RAW document type) after verifying that the requested file is published.
Are there any conventions on the placement of those files inside my component's directory structure?
My first idea is to create a folder inside the administrator/components/com_mycomponent and keep the files there. Do I need to restrict access to this new folder with a new .htaccess file, or is it already taken care of by Joomla with a global .htaccess?
you should place the files in the media directory. It is supported by the installer and is much better place. The logic is to have code in com_mycomponent for site and admin and both of those will share media (images/css/js), downloads, etc...
/media/com_mycomponent/
Restrictions are up to you.
Here is Joomla installation structure, http://docs.joomla.org/Components:xml_installfile