The main Laravel application object has two methods, booting and booted. These methods allow you to configure callbacks. The application object will call these callbacks before and after it boots.
Where, as a Laravel application developer, can I hook into these events? Looking at the framework it seems like
bootstrap/start.php
is the obvious place — but if I put code here it'll be zapped in the next update. There's also
start/global.php
statt/{$env}.php
but these files are actually required in by a booted callback, which means the booting callback point would be unavailable.
Is there an intended place for me to hook into these events as a Laravel application developer? Or are booting and booted there for the core framework developers? Or has I made an incorrect assumption that I'm not even aware of? Laravel 4.2.6, but if there's context from additional versions I'd love to hear about it.
New to Laravel, not new to programming. Not asking for a specific task (yet), just getting a feel for what best practices/intended use is and is not.
As a formal answer, there's no defined place for this behaviour. But a note against your comments about start.php, this file will not be "zapped" when you update laravel.
As long as a file is not within the vendors folder, any laravel updates won't change your files. start.php is generated when you create a base project, but should not be changed with further updates.
composer create-project is responsible for creating your base "skeleton" application, and any composer update that you do will just modify files in the vendor folder. Just remember, do not modify files in the vendor folder and you will be fine!
Related
I am trying to bootstrap a simple microservice type of application with the Symfony router and DI component, but without using the symfony/skeleton package as a starting point.
Routing works, but DI does not. Looking at the documentation of the service container, it is unclear of how my app would actually use the config/services.yaml file. I don't understand when is it loaded, how it is loaded, and how I would tell Symfony to use a services.php instead?
Similarly, if I install new composer packages, they dump some .yaml config files in config/packages/. Would I then have to load these files manually, using the config component?
All this typically happens (in a Symfony application) in the application Kernel, which is instantiated and booted by the "front-controller" script (e.g. public/index.php).
In the default Symfony 5 provided kernel you'll find this:
protected function configureContainer(ContainerConfigurator $container): void
{
$container->import('../config/{packages}/*.yaml');
$container->import('../config/{packages}/'.$this->environment.'/*.yaml');
if (is_file(\dirname(__DIR__).'/config/services.yaml')) {
$container->import('../config/services.yaml');
$container->import('../config/{services}_'.$this->environment.'.yaml');
} elseif (is_file($path = \dirname(__DIR__).'/config/services.php')) {
(require $path)($container->withPath($path), $this);
}
}
This loads all *.yaml files in the config/packages directories, and load the file config/services.php but only if the file config/services.yaml does not exist.
If you are building your own application without using the framework, you'll have to load these files wherever it makes sense for you application.
With the reduced footprint of Symfony 5, building your own is likely not particularly cost-effective, you can use the minimal symfony/skeleton and you would already have a very "micro" starting point, without having to spend time deciding these things.
If you are set on "building your own", either because of specific requirements or as a learning exercise, I recommend you reading this part of the documentation: Create your own PHP Framework. It's a very useful way of learning how the many pieces fit together.
I have a new symfony project. By default it contains
-/AppBundle
-AppBundle.php
--/Controller
--/Default Controller
Since I am going to have more bundles I would like it to be under a VendorName called MyProject where I have my ApiBundle.
I have tried moving AppBundle manually, then changing namespaces in the files, yml files and AppKernel. But I still get an error
Expected to find class "AppBundle\AppBundle" in file "/Applications/MAMP/htdocs/healthy-living/src/HealthyLiving/AppBundle/AppBundle.php" while importing services from resource "../../src/HealthyLiving/AppBundle/*", but it was not found! Check the namespace prefix used with the resource.' in /Applications/MAMP/htdocs/healthy-living/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Loader/FileLoader.php:133
Is there any console commands for doing this, if not what should be the procedures of moving it.
Thanks in advance
There's no console command or procedure to do it because it's not what vendor folder was designed for. vendor folder is meant to store 3rd-party code so keeping your own bundles, which you are developing, in vendor is not a good idea.
Since I am going to have more bundles
There is no reason that you can't keep more than one bundle inside your src folder. In fact, when Symfony introduced Bundle system it was very common that src folder contained a lot of bundles.
(note that vendor folder is almost always added to .gitignore - that's because what I wrote before)
EDIT after clarifying what the question is about:
It looks like command to generate bundles has/had some issues with creating bundles without Vendor folder:
Issue
Pull request
I don't know which version of Symfony are you using but either way creating bundle manually is always a good idea and it solves your problem too. (you can create it without vendor name)
You can upload your API bundle to a repository (Github, Gitlab, Bitbucket, etc.) and then import it as an external dependency with Composer.
Since moving was too complicated because of the config files that has to be changed so I decided to do a workaround and remove it and then install via console under the same parent. Works like a charm. Althoug could be a method in cli for this.
I'm a bit confused about where something like this belongs to Laravel.
I want to write a web service client wrapper in laravel, and I want to access it like this:
\MyWSClient::getSomeInfoAbout($someId);
then the code will connect to the web service to http://www.someapi.com/api/getSomeInfoAbout?id=$someid&type=json with OAuth2 or some token requests, then fetch the data, keep token information until it expires, refresh token if needed etc.
But where will I put the code? In the vendor directory as a new package? I'm moving this code from a computer to another computer except vendor,storage and node_modules folders, because they are huge and when I do this, I will have to move only one folder in the vendor directory. And I'll need to publish a package under development to composer if I want portability etc.
Is there any other way to do something like this?
I think I've found the answer.
First I needed to use jeroen-g/laravel-packager package to create a new package using artisan console. I could've done that by hand, but I didn't know the required files.
Second, I've created a new package in the packages folder with my desired class name.
Third, I've added the provider and the alias for the class in app.php.
After that, I've created a test method in my controller and wrote a route for that. I called the static method I've written in the SkeletonClass the packager created for me.
And it worked with some tweaking after creation.
I've used php artisan packager:new tpaksu mypackage --i command for an interactive package creation which is cool.
Note: I've just learned the existence of this package, I'm not advertising it :)
After some fiddling building a package for a project we've realised there's some issues with doing what we need to achieve as per Laravel 5 package development clarity
Maybe I should rather explain my goal and someone can suggest a direction to head in.
We've built a Laravel 5 application that now needs to be "re-used".
We had to modify Laravel and implement an Eloquent type base model as our data-source is actually C# Web Services. At the point the call would be made to a database we intercept this and make an "API" call to SOAP.
The major difference will be CSS, maybe some JS & content but all the routes/controllers/models will remain the same across all projects. Most configuration comes from endpoints.
Initially we considered creating multiple asset repositories for each site's styling and have a base repo which is the core Laravel project that gets included. This seemed to get quite complex as we couldn't simply just have a repo in a repo due to branching and multiple directory issues.
We then started experimenting with the idea of building the "core" as a Laravel package but we seem to constantly hit walls. The latest problem being including models in the package. For the models to be called we are using the root projects config/composer to access these models instead of just the service provider. It feels like the package is becoming to tightly coupled to the project config.
Are there any better ways of going about what we are trying to achieve?
Edit:
I forgot about the multiple branch solution on 1 repo but wouldn't this get ugly when it comes to feature development? Example:
master (core with releases that get pulled into _site*)
dev (master dev)
feedback-form (eg. master branch feature)
_site1 (root site with releases)
_site1-dev (_site1 dev)
_site1-reskin (eg. _site1 feature)
_site2 (root site with releases)
_site3 (root site with releases)
This leaving quite a bit of destructive merge power in the developers hands? Read access with pull requests maybe a solution to this?
So after some R&D it seems the best solution right now is to have 1 repo with multiple branches. Developers have read access and have each developer creates his own fork. Developers create pull requests and sync to parent repo through "upstream" remote and developers sync each others forks through additional remotes.
Seems a little clumsy but probably "cleanest" option.
I have created a handler class that derives from AbstractProcessingHandler. I've seen that I can put it in src/MyNamespace/MyBundle/Monolog/, but it worries me a bit because this handler is used in several others bundles where I log data. So the other bundles will need MyBundle to work properly, only because of this handler.
I tried to put my handler class in lib/ but it does not seem to work (maybe I have to do something special with Autoload?).
Or should I create a new bundle specifically for this handler?
Edit: I can't really place my custom handler class in vendor/monolog/monolog/src/Monolog/Handler because then I would not be able to add it to my git repository: there is a conflict because this folder is managed by another git repository (created by Composer)
On Monolog's end there is really no restriction on where to put it or how you call it. The key is only that it implements monolog's HandlerInterface or extends from one of the existing handlers.
Now it depends what your handler is, if it's generic stuff that other people could use you could submit it as a pull request to monolog.
If not, you can either create an own composer package for it, or put it in src/Acme/Monolog/FooHandler or something like that, so it stays in your application but is clearly out of a bundle. The downside is that you need to configure it as a service in one of your bundles, so you still have some sort of dependency on a bundle there.
Maybe having it as its own bundle would make sense then. But it's quite a lot of boilerplate for just one class.
If all your bundles are application specific and very unlikely to be extracted out of it, having cross-bundles dependencies is fine though IMO.
The dependency is anyway not very strong since one bundle could contain the handler and configure it. The other bundles can still log to monolog, even if the handler isn't present, they can log. It just won't go to that specific handler. Nothing should break.
As you see, it's just a lot of trade-offs, and it's hard to say which solution is the most fitting without knowing more about your project.
If you want to have your handler class in lib/ you will need to add the lib/ folder to your composer.json autoload section. For example:
"autoload": {
"psr-0": { "": ["src/", "lib/"] }
}
Take a look at the Composer documentation:
Basic Usage
Autoload
I think the common approach here is to use a "Bridge" dir in your Bundle with a clear dependency. If you have other bundles that rely on this, what we've done is create a ServiceBundle which is basically for all shared services across all bundles within the application. This might not work well for you if you have plans of distributing this bundle, but may otherwise.