I wrote a web app in Laravel. The repo doesn't store a whole Laravel installation - it only has app and public directories.
I'm trying to figure out a good solution to allow other devs to easily spin up a local version of my code for them to try/work on. Someone suggested that I set up a symlink between the cloned repo and my Laravel installation, which sounded like a good solution to me (allows them to push/pull from my repo without needing to copy files endlessly).
However, when I set up the symlink, Laravel starts looking for its files (bootstrap, vendor, etc.) in the repo's directory, but they don't exist there, so I just get a blank screen.
Any ideas?
Related
When uploading images I realize FIRST I can use store method which saves images in the storage/app/public by default then I'll have to create a symbolic link from public/storage to storage/app/public to access the image.
SECOND, I can still use move method and have the image saved in the public/images directly.
I feel like the first way is longer for no reason, is there scenarios of when to use one over the other or it's just a matter of preference ?
Yes it's better in some cases, but it might not be relevant to you, let me explain.
The storage folder is usually considered a "shared" folder. What I'm trying to say with that is that the contents usually should not change when you deploy your application and most of its contents are usually even ignored in git (to prevent your uploads from ending up in your git repository).
So storing your uploads in this case inside the storage/app/public directory means the contents are not in git and the storage folder can be shared between deployments.
This is useful when you are using tools like Envoyer, Envoy or other "zero downtime" deployment tools.
Most (if not all) zero downtime deployment tools work by cloning your application to a fresh directory and running composer install and other setup commands before promoting that fresh directory to the current directory which is used by your webserver to serve your app. Changing a symlink over to a new directory is instant and thus you have zero downtime deployments since all setup (installing dependencies etc.) was done in a folder not yet serving traffic to your users.
And since each deployment starts with a fresh clone of your repository that also means that your public and storage folder are empty again... which is not what you want because you of course want to retain uploads between deployments. A way to work around that is that those deployment tools will have the storage folder stored in another folder and with every deployment it clones your git repo and symlinks the storage folder to that shared storage folder so all your deployments share the same storage directory making sure uploads (but depending on the drivers you use also sessions, caches, and logs) are the same for every deployment.
And from there you can use php artisan:link to symlink the storage/app/public to public/storage so that the files are publicly accessible.
(Note: with the symlink in place it doesn't matter to which path your write, storage/app/public or public/storage because they point to the same folder on the disk).
So this seemingly overcomplicated symlink dance is to make deployments easier and having all your "storage" in a single place, the storage dir.
But when you are not using those zero downtime deployment tools this all seems like a lot of nonsense. But even there it still might be useful to have a single place where all your app storage lives for backups for example instead of having to backup multiple directories.
from laravel documentation https://laravel.com/docs/5.4/filesystem:
move method may be used to rename or move an existing file to a new location
Laravel makes it very easy to store uploaded files using the store method on an uploaded file instance.
So, use storeAs() or store() when you are working with a file that has been uploaded (i.e. within a controller), and move() only when you've already got a file in the disk to move it from one location to another.
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.
I did the following steps:
I have created a new Umbraco instance by using the nuget package and visual studio.
I have deployed to Azure, using Azure DB as backend.
Installed the articulate package.
Added my project to version control (including App_Plugins folder, articulate dlls and so on).
I am able delete the umbraco installation and I can restore it completely from version control including Articulate.
Now I am starting to add content, articles, pictures and so on.
Think I do not need to backup the whole folder on the web server. I am doing regular backups of my Azure DB and I need some folders which are also filled with new content, like
media (filling with pictures which I am adding to my articles)
App_Plugins (keeping installed packages in umbraco)
App_Data/packages (file directory for installed packages)
App_Data/umbraco.config (keeping some content for Articulate)
So, is this everything I need to be able to restore the whole system by using the version control part, azure db backup and the listed folders?
Ideally for data/contents you should backup media and App_Data folders. However, if you want to backup Umbraco site (including cache files) then I would recommend App_Plugins, App_Data, Bin, Config, Umbraco & Umbraco_Client folders.
Hope this information helps!
Basically I follow the approach as described in the question. I have added the following files and folders to the Visual Studio project and then later to version control (I have just expanded the more interesting folders which are not part of the project file by default, but needed when you redeploy the solution from scratch):
As described the backend is hosted on Azure SQL.
Open Live Writer makes it very easy to host article content on another ftp server.
By following this approach it is very easy to redeploy the complete solution, e.g. for umbraco upgrades or major changes on the site.
I am running Joomla 3.1.5. I have a custom component installed and I have made some minor changes to some of the files. How do I create an uploadable/installable zip file to install these changes to my production Joomla site?
Please disregard the discussion on templates in the comments above.
You don't need to rename your component it seems.
If you need to install on a single site:
on the prodution site, install the installer you first installed on
your development site
sync the files with a version control system
such as git / rsync / scp / sftp / ftp whichever you're most
comfortable with
If you need to install on multiple sites:
You need to repackage it, and add to the xml manifest any files/folders you added.
Simply explode the original zip installer somewhere on your drive, and figure out the folder structure (could be admin,site,media for example).
For each browse the custom_component_name.xml section and ensure it contains the files you added, if any.
Then copy the updated files over the folder structure, zip it, and upload it to production.
Once you do this the component will be registered in the other Joomla installation. You can also keep the copies aligned between the two servers with a code versioning system such as git.
If it's a component you plan on distributing, create a script to package it, look at the Joomla docs there's plenty of info, you could use a bash script, phing, ant, maven, choose one that suits you any will do the job
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.