this is not a code question about laravel 5.*, it's more like to know if you guys develop your applications using packages ("package driven development" ? Not sure if this is the right definition).
What I mean is: Instead of building an application and create controllers in app/Http/Controllers/, you wrap everything in a package and then 'require' that package using composer (like a wordpress plugin).
I'm trying to think in a way to isolate the core Laravel from my specific application and save time later when it's time to upgrade when a new Laravel version is available.
In my case I'm having some issues moving from version 5.2 to 5.3 because I have some customization in the registration and login process - It might be because I'm not using the right approach to write the code (patterns), so I'd like to hear from more experienced Laravel developers.
Thanks!
The great thing about Laravel, there's almost always a package for what you want to do. You can either create your packages as packages on composer, or you can install a module package and create them as modules.
For my projects I tend to use caffeinated/modules. I've tried a few and IMO it's the easiest to use.
Related
I have an existing laravel project with AlpineJS. I wanted to integrate authentication but not able to find a proper solution having in mind I DONT USE VUE. I have done this with Vue but just wanted to know if there's an updated guide for Laravel with Alpine JS. I tried to look into documentation but wasnt able to find something related.
composer require laravel/ui
php artisan ui:auth
Do I still need to do this? Any suggestions for best practices?
Alpine is just a lightweight framework for DOM manipulation, it's not going to provide any authentication functionality alone so you will need to add something to your project.
If you're wanting to add authentication to your application, you'll want to consider something like Laravel Fortify which is a headless front end agnostic authentication solution. There are starter kits such as Breeze or Jetstream, however, adding either of these boilerplate start kits to existing projects can have issues. Some people recommend starting a new project, installing one of them and them porting your existing functionality across (this will obviously depend on the scale of your project).
I have been developing in Codeigniter for awhile now. I have recently read that Laravel is currently the most modern and best framework. I am interested in learning it for my next project. I'm hoping that someone could help to answer some questions that I have about Laravel.
1) How would I host it? Laravel seems to rely on composer a lot and that requires a terminal. For CI, I just download a folder and load it up to my Webserver and I can run it.
2) Dev environment. I have been using Netbeans that is connected to my server and it can push updates instantly. I want to connect it to git soon for some versioning as well. Is it the same for Laravel? How would I update it?
Same here, I have been developing Applications in Codeigniter 2,3 for past 5 years and now I am learning Laravel and have starting making beginners level application in Laravel Here are my findings which might help you
Difficulties
For Codeigniter Developer, Instantly playing everything by using router is kind of difficult. Although router is used in codeigniter as well
Installing and setting up Laravel seems like a tricky and very lengthy job especially the use of composer which is an extra thing as compared to codeigniter which is just download and uncompress or copy paste installation procedure.
But Why Laravel?
Object Relation Modeling - Eloquent ORM
We can easily create relations and joins with query builder or active records in codeigniter but to enforce referential integrity in database, we have to write triggers in our database or define relations. Luckily in Laravel the relations are made with one line of code and does a lot of job. Whereas in Codeigniter that's a lot of manual code writing.
Integration of off the self Packages.
There are thousands of developed packages readily available on packagist, which is a repository composer uses to download software packages. You just have to write one or two lines of code at composer terminal and it does all the rest, create models, controllers, views. All you have to do is include them or change the styling as per your layouts.
Think of Laravel as a PHP framework for extremely lazy developers who want to write very less and re-usable code and do lot of work from it.
Learning Resources
Laravel 5.2 from Scratch that's the one I started with, excellent course and Modern Web Development with Laravel
Uploading on Shared hosting
Click here for tutorial
First of all, I'm a complete newbie to Composer. I've been trying it out since it's a sounds awesome and mainly because Zend Framework 2 uses it.
Zend Framework 2 is actually also the reason for this thread.
It get the basics of Composer. But with my current server setup I have a request, which I can't seem to figure out if possible.
Let me explain.
I have multiple Zend Framework 2 projects:
/home/morten/sites/Project-1/
/home/morten/sites/Project-2/
/home/morten/sites/Project-3/
All of these projects should be running ZF2. When running composer in each project - each of them get their own separate download of the ZF2 Library files. Which is a bit redundant with my setup.
I have a complete and up-to-date download of ZF2 Library located at:
/var/www/shared/Zend/
And my php.ini has that path added to PHP's include_path, so the whole ZF2 library is available for all the three projects.
IS IT POSSIBLE to make Composer use in it's setup. Because if I try to change stuff and try things out in the composer files, then it just re-downloads Zend because it's a required component for other modules.
Can this be done? And if yes, how can I do it?
Hope I have explained myself good enough for you guys to understand what I'm trying to do and want :)
Thanks a lot in advance!
Regards,
Morten
You might be able to have one composer.json file stored in /var/www/shared/Zend, where you would put your dependencies and use Composer do manage them. Then all projects could include the same autoloader.
However, I wouldn't recommend that approach:
Your project's dependencies (composer.json) should be stored with your project. If you want to install your project somewhere else (for instance if you want to move one project to another server), you are missing the composer.json to install the required dependencies.
It will not be possible to update the dependencies of one project, without updating the dependencies of all other projects. If you want to introduce a new feature in Project 1, which requires a new version of a certain dependency, all other projects will get this new version as well - which might introduce backward compatibility breaks if an older feature that Project 2 relies on, is no longer supported. Since you can only have one version of each dependency, it is not possible for two projects to have different versions of the same dependency.
This approach might be useful if all projects will have the exact same functionality and code, but in that case you should probably merge them into one project.
In all other cases, I would suggest to use Composer the way it's supposed to be used: give all projects their own composer.json file and let Composer download the dependencies per project, in each project's vendor directory. The downside is that it'll cost you a little more disk space, but you'll get a lot of flexibility for it in return.
I looking for some plugin structure for Laravel based applications.
For example a forum software, a cms or a e-commerce application can benefit from a plugin structure.
My question is what is the best way to implement this plugin system so that third party plugins can extend the application. The main issue is that it should be dynamically extendible and users should be able to install these plugins easily without messing with the app code.
This question also extends to themes but thats another question. Any ideas?
Laravel is a framework, not a CMS like Wordpress or Joomla, so plugin system that fits everybody may be quite hard to create as Laravel can be used in many ways, but I can really see the benefit of easy packages in some contexts.
The Packagist has been already mentioned and it doesn't solve directly your problem but how about:
Find good usable packages from Packagist for the purposes you need
Define common plugin architecture (common API for binding things together, installer, package format, migration, updates etc) on top of Packagist packages
Create installer that fetches packages via Packagist/Composer and adds sets sane default settings and configuration for the packages and integrates them into the defined plugin architecture
Document and plan this really well and the others will soon follow
I'm a little confused about the question, but I believe what you are looking for is already implemented in Laravel 4. They are just called Packages, and can be found at http://www.packagist.org and easily installed and autoloaded into your application using Composer.
This may look like a trivial question, but it isn't.
Being new to composer, I find myself wondering about how to pick a decent package for a common feature on its main repo packagist.
Say I am using Laravel 4 for a recent project and would like to add mongodb support for document storages and indexing. A simple search for mongodb on packagist will yield 8 pages of results, searching for mongodb laravel yield 24 pages.
But here comes my question: most packages have their target framework, should I pick the ones that are less popular but designed for Laravel, or should I go with the popular package in hope of future maintenance?
My assumption is that: composer, along with PHP-FIG standards, are attempting to reduce repeat development of common features across frameworks. So eventually there maybe only a handful of popular package left active for a certain common tasks.
But for now, how to choose the right package on packagist for framework X? Should we just search on github instead?
(I should note that Laravel already use a handful of Symfony/doctrine packages in core, but there are no guarantee that doctrine/mongodb will also work in Laravel without modification right?)
When I'm searching on Packagist, I try to avoid packages that depend on frameworks that are not Laravel or sometimes Symphony. Of course, no framework dependencies is okay.
When L4 was still in alpha, I wanted to play around with image manipulation. After some investigation, I chose sybio/image-workshop. At the time, there were no packages that interfaced with Laravel perfectly. After created a service provider and facade, all was good.
On packagist.org, try the search terms "mongodb AND laravel" without quotes. This narrows the search to one page, in this case.
Chris Fidao (#fideloper) tweeted on May 2nd about the following MongoDB package for Laravel. It looks interesting as it uses Eloquent.
https://github.com/jenssegers/Laravel-MongoDB
For package specific for laravel framework, please check packalyst. Packalyst is a directory of Packages for Laravel projects, It pulls package names from Packagist that have a "laravel" tag (composer package that have 'laravel' in the keyword array in composer.json).