I have a question, I am still getting to grips with Laravel (came over from CI)
I'm looking to implement modules into my application in a similar style to say, wordpress plugins. I took a look at some of the HMVC libraries available but they all seem to require you to explicitly declare each service in the app/config/app.php
I'm wondering if there's a more plug and play approach I can take, where I am able to drop in a folder and it works off the bat, is there an appropriate way to implement this?
Thanks
I don't think there's a "drop in folder and it just works" solution for Laravel, but Packages is probably the closest to what you are describing:
http://laravel.com/docs/packages
Usually after you install a package, you run an artisan command to publish configurations and potentially run some database migrations, and then you're good to go.
I would start there if you want to create some additional self-contained functionality without wading into the existing site..
I've written a Laravel 5 package that manages modules. You can "drop in folder and it just works".
There is also a artisan module generator.
l5-modular have fun, save some time ;)
Related
Is there an easy way to incorporate changes to the main Laravel app, when there are framework updates, other than manually incorporating the changes described in the documentation (http://laravel.com/docs/5.1/upgrade)?
I'm thinking some kind of composer command that patches the main app and not only the vendor dir. Does such a thing exist?
Thanks in advance.
Apparently, Shift is exactly what you're looking for, although it's still in its alpha. You can contact its creator if you want to help him test the tool.
Reference: http://jason.pureconcepts.net/2015/11/laravel-automated-upgrade-tool-shift/
I'm wondering what the best way (if there is a way) for an application to auto-discover [relevant] PHP "packages" installed by Composer.
My use case specific scenario:
I have a PHP app that includes my "framework" (for lack of a better word). This framework brings some basic functionality (routing, admin etc).
I'm slowly building in more advanced functionality, say, a blog module. This module is entirely self contained in it's own directory (but obviously has dependencies on the framework).
I'd like this blog module to be a self contained Composer package, so that I can selectively require the package in my app's root composer.json file.
Now, I need for the framework to know that it's there so that it can, for example, set the routing correctly and load up any admin functionality that the module requires.
What I've thought so far:
I'm relatively experienced in PHP, but "proper" OOP and autoloading is a little bit beyond my knowledge at the moment, so please forgive if there are inbuilt functions to do this. I don't even know what terms to Google!
I have thought I could maybe read the installed.json file which composer puts at vendor/composer/installed.php but I'm not sure how to set up my packages (e.g. blog) so they announce what they are. I'd like to future proof it so that I'm not looking for known module names (or regexing vendor or package names), but rather looking for packages to say "hey framework, I know you! You can use me!"
Maybe I can somehow instruct Composer (through the package's composer.json file) to stick in an arbitrary key/value pair in installed.json?
Any suggestions welcome, or directions as to what sort of Googling I should be doing.
Oh welcome to the world of managing dependencies on your framework.
I have some experience with auraphp, where we dealt with similar issue. You can read the blog post Composer-Assisted Two-Stage Configuration .
So what we finally ended-up adding https://github.com/auraphp/Aura.Web/blob/a3870d1a16ecd3ab6c4807165ac5196384da62cd/composer.json#L26-L36 these lines in the packages that need to understand to load by the framework.
You can also see how this bundle can also get autoloaded with the configurations.
in your composer.json
https://github.com/harikt/Aura.Asset_Bundle/blob/6ea787979390e69bf6ecb1e33ce00ed90f306e2f/composer.json#L21-L27
and the config/Common.php ( https://github.com/harikt/Aura.Asset_Bundle/blob/223126cedb460e486c4f0b242719c96c14be5385/config/Common.php ) , note we have other development modes also. For a detailed look check https://github.com/auraphp/Aura.Web_Project or https://github.com/auraphp/Aura.Framework_Project
Hope that helps a bit to look into the code and work on your own solution.
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'm building a new project on top of CodeIgniter MVC framework, but now that i'm looking at the design, i will actually not use most of the framework features except for 1.form validation, 2.router and 3.session/cookie/input handling, and 4.views generation
even for database i will use Redbeans php ORM.
So my question
how can i glue these components that i fetched with composer from other frameworks so i can inject them into my project and be good to go without other extra stuff that i don't need ?
would it be a wise decision ? or is there any risks of depending on components rather than whole framework ?
i have googled a lot but it seems like i'm using the wrong keywords or something, i could not find any tutorial except for this one -which dictate symphony- that teach you how to do this and what are the risks of doing it
You can take a look at Packagist to explore which components Composer offers, RedBeanDB is definitely in there. However, in contrast to Symfony, CodeIgniter is not really Composer-friendly. So if you are looking for a proper way to just load these few CodeIgniter components as a dependency, I guess you're out of luck.
To keep from digressing, I'm simply going to answer your two main questions:
1) There are plenty of tutorials out there on how to use composer to grab your packages, so I wont do a full writeup, but basically what you need to do is download composer, create a composer.json file, then run composer to have it download all those packages and their dependancies. All you then need to do is in one of the already loaded codeigniter files, autoload the autoload.php file
`require 'vendor/autoload.php';`
Check the composer documentation here on how to download composer and setup your json file.
2) Definitely. The Laravel framework is actually built this way under the hood, instead of writing everything themselves, they use composer to pull in packages from other projects like Symfony to do certain tasks.
I'm currently planning out on how to maintain several thin projects which shares a bunch of thick modules in Kohana.
The plan is to have some modules, like "blog", "forum" etc. And then a bunch of separate projects which shares some modules.
As you can image, most of the modules will have a database dependency.
So, when a module is deployed to a project, the back-end database must be updated accordingly. (Also note that when an update of a module is deployed, the database might have to be altered.)
A good solution to this is Migrations, I've seen some implementations of them for Kohana, but almost all of them are application-specific and can not be used with mere modules. (Please correct me if I'm wrong)
What I really want to know is:
Is there a good way to automatically update the back-end database on deploy with Kohana?
First thing you need to address is what migrations module you are going to use. There's a nice one based off a module called Minion, see the tasks-migrations repository. You can specify migration locations which are directories inside your migrations directory.
classes/migrations/[location]
So passing the argument --location=module would only execute migrations inside that directory, that's how you'd separate and run per module migrations.
If you leave off --location then all migrations are run (need to double check this)
The neat thing about minion is each location can use a different database group if you specify it, allows for a lot of flexibilty.
The next thing you have to deal with is deployment. I personally do this with Capistrano, so on a new deployment I'd run the minion command to bring up the database to the latest version.
Take a look at these two code samples to see how you might integrate running migrations with Capistrano.
http://pastie.org/459506
https://gist.github.com/410363