In Laravel 4.2 is it possible to create a package which automatically registers the ServiceProvider without the user adding the path manually to the app.php file?
This way one could just run composer update after adding a package to the composer.json file and would be ready to go.
I think that there is no way to register your main service provider than putting it in the app.php file. In fact you can, but it will always require something from the developer. You can't get away with it with a simple composer update.
You can register sub service providers with App::register('MyApp\Providers\MyServiceProvider'); inside your package.
No, there is no way for a package to register itself.
Related
I'm relatively new to Laravel; using 8.26.1
just after creating a project, I noticed that I have RouteServiceProvider.php exists in two locations:
app\providers\ and \vendor\laravel\framework\src\Illuminate\
can someone explain which one should I use to make my changes or guide me to a document where I can read about how and which file is used by Laravel ?
You would be using the one in your application which is everything that isn't in vendor as that is all packages and you should not touch any of that. The App\Providers\RouteServiceProvider (app/Providers/RouteServiceProvider.php) is the provider that is loaded by your configuration in config/app.php. This extends the base one from Laravel to give it the features it needs.
I've set up a fresh installation of Laravel in Homestead and I've installed PhpRedis as recommended in the Laravel docs https://laravel.com/docs/7.x/redis#phpredis.
I followed this guide for installing PhpRedis https://webstoked.com/install-phpredis-laravel-ubuntu/
In both the Laravel docs, and the guide I've linked for installing PhpRedis, I'm instructed to rename the Redis alias in config/app.php.
If you plan to use PhpRedis extension along with the Redis Facade alias, you should rename it to something else, like RedisManager, to avoid a collision with the Redis class. You can do that in the aliases section of your app.php config file.
- Laravel Docs
To further add to my confusion, the Laravel docs then go on to say that you should remove the alias entirely.
To avoid class naming collisions with the Redis PHP extension itself, you will need to delete or rename the Illuminate\Support\Facades\Redis facade alias from your app configuration file's aliases array. Generally, you should remove this alias entirely and only reference the facade by its fully qualified class name while using the Redis PHP extension.
- Laravel Docs
My main questions are:
What does, "If you plan to use PhpRedis extension along with the Redis Facade alias", mean?
When should I rename the alias, remove it, or leave it as-is?
Depending on if I rename or remove the alias, how will this affect using Redis?
There are two different configurations/ways to use redis in a laravel project.
First one is to use predis and it is in your vendor folder. This one is "Flexible and feature-complete Redis client for PHP and HHVM" located here. It is a package/library written in php.
The other way to do is using PhpRedis, it is an extension written in C and located here.
protected function connector()
{
switch ($this->driver) {
case 'predis':
return new Connectors\PredisConnector;
case 'phpredis':
return new Connectors\PhpRedisConnector;
}
}
What does, "If you plan to use PhpRedis extension along with the Redis Facade alias", mean?
In the framework there is a check. While creating the PhpRedis client of Redis, it is checking whether the new Redis instance is Facade because PhpRedis is also using Redis name is you can see from here. So if you want to use PhpRedis in your laravel framework you better rename your facade because it will cause collision.
When should I rename the alias, remove it, or leave it as-is?
If you are going to use predis as client, then you can leave it as-is. If you are going to use PhpRedis as client, then you need to rename alias.
Depending on if I rename or remove the alias, how will this affect using Redis?
You will use RedisManager::someMethod() if you choose PhpRedis. You will use Redis::someMethod() if you use predis.
Please point out any naivete or incorrect assumptions I'm making about Laravel, Composer, PHPUnit, etc.
I had a class called SpeechToTextHelper that was inside a Laravel project, and it used facades like this:
use Cache;
use Log;
use Storage;
Then, since I wanted to share it between multiple Laravel projects, I moved it into a separate repo and required it (into the first project) as a dependency via Composer.
The code all seems to run fine.
My question is different from Using Laravel Facades outside Laravel
What I want to know is:
Now that I also want to write PHPUnit tests for SpeechToTextHelper in my new tools repo, I see errors like RuntimeException: A facade root has not been set. and Error: Class 'Log' not found, presumably because this tools repo has no awareness of Laravel. I guess this means my production code has been working just by side-effect.
In my new tools repo (where my SpeechToTextHelper now is), how am I supposed to indicate (maybe somewhere in composer.json?) that the code will only work if Laravel's facades exist and are initiated properly?
How can I fix my separate repo's code so that its tests can run and also so that it ensures that it can only be "required" by a Laravel project?
P.S. https://laravel.com/docs/5.7/facades says "When building a third-party package that interacts with Laravel, it's better to inject Laravel contracts (https://laravel.com/docs/5.7/contracts) [which live in their own GitHub repository] instead of using facades." "If you are building a package, you should strongly consider using contracts since they will be easier to test in a package context."
But I do not see contracts for Log or Storage at all.
I think you are looking for Laravel component repositories
Cache - This component shows how to use Laravel's Cache features in non-Laravel applications.
Log - This component shows how to use Laravel's Log features in non-Laravel applications.
This video shows, how you can use eloquent outside laravel, I think that will give you better idea.
I'm not positive that this is the best approach, so I'd love if others
would provide better answers.
For production code
My composer.json still has this in the "require" section: "laravel/framework": "5.7.*",.
I plan to only ever require this tools library from within a Laravel app. I'm not sure that this is the right way to make that a rule, but my production code at least seems to be working.
For tests
As for tests, what seems to have been necessary was to add these files from https://github.com/laravel/laravel/tree/2a1f3761e89df690190e9f50a6b4ac5ebb8b35a3:
app/Console/Kernel.php
app/Providers/AppServiceProvider.php
app/Providers/AuthServiceProvider.php
app/Providers/EventServiceProvider.php
app/Providers/RouteServiceProvider.php
bootstrap/cache/.gitignore
bootstrap/app.php
bootstrap/autoload.php
config/app.php
config/database.php
config/logging.php
config/view.php
storage/logs/laravel.log
tests/CreatesApplication.php
tests/TestCase.php
Perhaps those are the minimum set of barebones Laravel files without which tests can't run.
Then I made sure that each test class extended tests/TestCase.php. And I adjusted the namespaces.
I'm starting a new project and I want to reuse some parts of it, mainly the stuff related to user registration and authentication. I can copy and paste all of the code but I want to use again. I know there is Package Development in Laravel but it's not easy and feel like there must be a better way.
Some days ago I find a pingpong/modules but I don't know about it. It's third party plugin and don't trust it.
Use this plugin is true? Is this plugin is updated later? What's different between Embedd Package Laravel and pingpong/modules? or Do you have any suggestion?
Pingpong modules seems to be build for the earlier version of Laravel 5 and in how far they are compatible with future versions (and maybe current 5.1.11) I cannot say.
There isn't much activity going look the commit history for 2.1, as of today(18 dec) the last commit was over 6 months ago.
But is the package specifically designed for Laravel? It seems to. They offer a bunch of features which are useful for development. The only unfortunate thing is you get a LOT of code within your own git environment (is it a good thing? I don't know, what do you prefer).
Personally I don't like it in this way for development, I prefer them in the vendor/ folder else it's a pain to update it to newer a version.
Since Laravel 5 Taylor wanted to make package development not too specific anymore, like in Laravel 4. The only thing what you can do (but not have to) to make your package using Laravel is using the ServiceProvider's. The ServiceProvider is the bootstrap into the Laravel application.
If you want to extend or implement your own functionality, fork the repo and build it yourself on top off it and host it (through github/packagist or a private repo using Satis).
Pingpong modules (2.1) is build for Laravel 5 and they you described (Embedded Laravel Package) is more for Laravel 4, because the more specific way you have to write the package.
But, there is alternative?
Whenever you want a more active project/package for development you should tryout Asgard CMS. They are pretty modular and I thought I read somewhere it was inspired by this package (totally not sure).
How about building yourself?
Of course you can build your own packages to achieve the same result. And create it as modular as you want. I created a lot modules for my company and we can create pretty easy a entire system and using and extending/overriding modules. Even small parts from a module can be overwritten to project specific needs.
We have chosen for almost the same structure as the app/ folder which Laravel projects, in case of CMS/API modules.
A packages look like:
tests/
src/
Acme/
Controllers/
Requests/
Models/
Module.php // contains some specifc calculations for example
ModelServiceProvider.php
composer.json
In the composer.json file we autoload: "Module\\": "src/"
And in the config/app.php we register the ModuleServiceProvider. Now we injected the functionality into Laravel's container and can we use it through the app() instance.
But whenever we only want to use the Models with in another project or standalone, we can still use it because the autoloaded features from composer and the way we build the package. Possible to use:
<?php
require_once __DIR__ .'/vendor/autoload.php';
use Module\Models\Module;
$module = new Module;
Edit
The package structure we like to use, to have a section for API or CMS stuff:
tests/
src/
Cms/
Controllers/
Requests/
Api/
Controllers/
Transformers/
Models/
Module.php // contains some specifc calculations for example
Providers/
CmsServiceProvider.php // includes `ModuleServiceProvider`
ApiServiceProvider.php // includes `ModuleServiceProvider`
ModuleServiceProvider.php // contains global stuff like commands etc.
composer.json
and instead of registering ModuleServiceProvider in config/app.php we register the ApiServiceProvider or CmsServiceProvider depending on the wishes of the client/project.
To reuse your classes simply use php namespaces or use to call back your clases.
Using the namespace
namespace Acme\Tools;
class Foo
{
echo "me";
}
You can the call class foo
<?php
$foo = new \Acme\Tools\Foo();
Using Use.
You can also use use Statement as below :
<?php
use \Acme\Tools\Foo;
$foo = new Foo();
Use Middleware
You should also use middleware to filter who should use the scripts ie the Auth middle-ware , which will help you in filtering users , registrations , logins READ MORE http://laravel.com/docs/5.1/middleware
Use Eloquent
Use ORM to create REST apis to your models , its very simple , always let your controller class extend eloquent use Illuminate\Database\Eloquent\Model; ie as :
use Illuminate\Database\Eloquent\Model; .Read More http://laravel.com/docs/5.1/eloquent
Lastly Use Laravel In built Helper functions
There are numerous Laravel In built Helper functions , to use simply go over the documentation to help you
I've used pingpong modules. It a pretty cool package. I'm not sure if it's updated much. But it's a very simple package. The only thing it does is create a folder with almost the same structure as in the app folder + views. But these are modules. You can reuse it if you program them right. The same goes for the other answer from jimmy if you have a good structure you can reuse anything.
EDIT
In the image below you'll see an example of pingpong modules. As you it's pretty much the same structure as the app folder. Maybe more the root folder. Normally it runs start.php and you have a routes.php file int he Http folder. I customized mine a bit. And load the frontend and backend routes within the RouteServiceProvider. This is build with laravel 5.1.
How to run package in laravel 5?
I have downloaded one chat package from INTERNET. And, I have run command vendor:publish and it successfully published.
Now I don't know how to run that.
First you need to check whether the package ships with any service provider and facade. If so, add them in your config/app.php file. Package's service provider should go under providers array and facade should go under aliases array.
As soon as you specify providers under providers array, Laravel now know that you have called an external package, so it will load them. Thus, the package now will be available for your usage.
The easy way to run a package in laravel is:
add the package to composer.json file
then in terminal write composer dump-autoload